软件测试：软件测试基础笔记（1）

测试基础
开发模型分类
瀑布模型
快速原型模型
螺旋模型
一、测试模型-v模型（重要）
需求分析➡概要设计➡详细设计➡编码 ➡单元测试➡集成测试➡系统测试➡验收测试
1、单元测试：又称模块测试，针对单一的程序模块进行的测试
2、集成测试：又叫组装测试，在单元测试的基础上进行的测试
3、系统测试：将整个软件看作一个整体来进行测试包括功能、性能、兼容性
4、验收测试
（1）内测版（alpha）内部交流版本，可能存在很多bug，不建议用户安装
（2）公测版（beta）面向所有用户，通过用户反馈，再去修改细节
（3）候选版（gamma）与正式软件相差无几
优点：
01 测试V模型即包含了底层测试又包含了高层测试；
底层测试：检验源代码质量的测试，如：单元测试；
高层测试：检验整个系统的需要，如：系统测试；
02 V模型清楚地标识出了软件开发的阶段。
03 它采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，
因此便于控制开发过程。当所有的阶段都完成之后，该软件的开发过程也随之结束。
缺点：
V模型一大缺点正是它自身的顺序性所导致的。到了测试阶段，程序已经完成，错误已经产生，
很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了。
同时实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复，
而且都要重复需求、设计、编码、测试等过程，返工量非常大，模型灵活性比较低。
二、w模型
优点：开发和测试伴随着整个开发周期，需求和设计同样要测试；更早的介入测试，可以发现初期的缺陷，修复成本低；分阶段工作，方便项目整体管理。
缺点：开发和测试依然是线性的关系，需求的变更和调整，依然不方便；如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！
定义：开发一个v；测试一个v组合起来的模型（w模型也叫双v模型）
总结：v模型适用于中小企业，w模型适用于中大型企业（因为人员要求高），h模型人员要求非常高，很少有公司使用。
三、软件测试分类（重要）
1、按测试阶段划分：单元测试、集成测试、系统测试
2、是否覆盖源代码：
（1）白盒测试
（2）黑盒测试：1、功能测试 2、性能测试
3、是否运行：静态测试（不运行程序）、动态测试（运行程序）
4、其它：1、回归测试 2、冒烟测试 3、随机测试 4、验收测试（内测、公测、候选版）
5、是否自动化：1、人工测试 2、自动测试

黑盒测试：又称数据驱动测试，完全不考虑程序内部结构和内部特性，注重于测试软件的功能需求，只关心软件的输入数据和输出数据
白盒测试：把盒子打开研究里面的程序结构和源代码；
黑盒测试分类：（背）
一、功能测试：
1、逻辑功能测试
2、界面测试
3、易用性测试
4、安装测试
5、兼容性测试
二、性能测试：
1、时间性能
2、空间性能
3、一般性能
4、稳定性
5、负载测试
6、压力测试
随机测试：
针对重要功能、新增加的功能、特殊情况、以前发现过重大bug的模块进行二次测试；也叫探索测试，它可以结合回归测试来使用；
四、测试用例
测什么，怎么测
五、等价类划分法：
属于黑盒测试，它将不能穷举的测试过程进行分类，从而保证完整性和代表性；
思考步骤：
1、确定有效等价类和无效等价
2、有效等价类划分（题目条件，还要注意边界值（极值），中间再随意找个值）
3、无效等价类划分（跟有效等价类相反，其它特殊情况（中文、英文、特殊符号、空格、空））
注意：两个框要一个正确，一个错误，这样才能准确的判断；一定要根据需求来判断预期结果；
等价类细节
1、 考虑输入长度
2、 考虑输入类型
3、 组成规则
4、 是否为空
5、 是否区分大小写
6、 是否重复
7、 是否去除空格
六、边界值
我们在测试过程中，一定要小心边界值（极值），因为在程序中这些边界最容易出问题；具体测试用例书写思路：找到边界值和它两端的值，分别进行测试；
总结：边界值思想应该是选到边界和刚超过的值，来进行测试，也要根据实际情况来选择；边界值和等价类是相辅相成的关系，配合使用的。
七、因果图
因：输入条件
果：输出条件、出结果
适用于输入条件之间有相互制约、相互依赖的情况；
因果图中的符号：
1、恒等—有因就有果，没有因就没有果
2、非—有因没有果，没有因有果
3、或—条件有一个是真，结果就是真，条件都是假，结果才是假
4、且（与）–条件都为真，结果才是真，一个条件为假，结果就是假
判定表
根据因果图来制作判定表（因果图可以不画）
组成部分：
1、 条件桩：所有条件
2、 动作桩：所有结果
3、 条件项：针对条件桩的取值
4、 动作项：针对动作桩的取值
书写步骤：
1、 列出所有条件和动作桩
2、 填写条件和动作桩中的项目
3、 简化判定表
注意：如果出现“-“代表此选项不影响最终结果。
八、场景法
要用来测试业务流程；分为基本流（正确流程）和备选流（错误流程）
注意：还要补充一些异常情况；
在冒烟测试中主要采用场景法来测试；
九、流程分析法
适用于有先后顺序的测试；常用于业务流程、安装流程等等。每个流程就是一条测试用例，它只是在测试整体流程是否正确，细节还需要使用等价类、边界值等方法进行完善；
十、错误推断法
凭着直觉和经验来设计测试用例，它是根据之前项目相关的bug数据总结来的；
十一、正交表
从全面试验中挑选出有代表性的点进行测试（均匀分散，整齐可比）；高效率、快速、经济的方法；
十二、正交表概念
正交表：一种特制的表，一般的正交表记为：Ln（mk）
-n是表的行数，也就是需要测试组合的次数
-K是表的列数，表示控件的个数（因素的个数，或因子个数）
-m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）
如： L9（34）
有4个控件
每个控件有3个取值
9为需要测试的组合个数
叫4因素3水平
十三、正交表使用方法
1、 根据控件和取值数选择一个合适的正交表
2、 列举取值并编号，生成取值表
3、 把取值表与选择的正交表进行映射
十四、混合正交表工具
在实际工作中，很多情况都是因素（控件个数）和水平（每个控件的可选个数）不同，我们在现成的正交表中找不到对应的表格，此时我们就需要使用混合正交表工具来生成混合正交表；
使用步骤：
1、 制作取值表（不需要编号，列出数据即可）

2、 复制表格中的数据放在一个新建的txt文本文档中，保存到allpairs文件夹中（例如：test2.txt）
3、 Win+r再输入cmd进入控制台界面
4、 使用控制台代码进入allpairs文件夹中（例如： e: 回车 cd 复制文件夹路径 回车）
5、 再输入allpairs.exe test2.txt>chenggong.txt （test2.txt是我们刚新建的文件，chenggong.txt是我们最终生成出来的正交表文件）
十五、测试方法的选择
• 通常在确定测试方法时，有以下几条参考原则（1/2）：
– （1）拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法。
– （2）需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价划分，将无限测试变成有限测试。
– （3）在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。
– （4）如果程序的功能说明中含有输入条件的组合情况，则一开始就应考虑选用因果图和判定表法。
– （5）对于参数配置类的软件，需要考虑参数之间的组合情况，考虑使用正交排列法选择较少的组合方式（最少的测试用例获得最大的的测试覆盖率）。
– （6）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例。
– （7）采用错误推断法再追加测试用例——依靠测试工程师的经验和智慧。
十六、软件缺陷
定义：缺陷就是软件的问题，最终表现为没有满足用户的需求。
哪些属于软件缺陷
1、软件未达到规格说明书表明的功能
2、软件出现了规格说明说中指明不会出现的错误。
3、软件功能超出了规格说明书指明的范围
4、软件未达到规格说明书虽未指明但应该达到的目标
5、软件测试人员或用户觉得不好
缺陷的表现形式
1、功能、特性没有实现或者部分实现
2、设计不合理、功能不明确、逻辑不清楚或存在矛盾
3、实际结果和期望结果不同
4、没有达到规格说明说要求的性能指标
5、运行出错、崩溃、中断、界面混乱
6、数据不正确、精度不够、不完整或格式不统一
7、用户不能接受的其它问题，如存取时间过长、界面不美观
8、硬件或软件存在其它问题
缺陷的状态（重要）
1、提交—测试人员提交了一个缺陷给程序员
2、打开—待处理
3、拒绝—程序员认为不是缺陷或者重复，就可以修改状态为拒绝
4、修复—程序员修复缺陷后提交的一个状态
5、关闭—测试人员经过回归测试后，认为此缺陷已经解决，将其关闭
6、推迟—可以放在后续版本解决的问题，但是要详细写出修复的日期或版本