测试理论
软件开发过程模型
瀑布模型、快速原型模型、螺旋模型
瀑布模型
是线性模型中的一种，是所有原型的基础。
瀑布模型的阶段：
- 需求分析
- 设计
- 编码
- 实现
- 软件测试
- 完成（上线）
- 维护
瀑布模型的优缺点：
优点：
每个阶段都清楚明了。
按照阶段进行执行，每个阶段完成后在进行下一阶段的任务。（按部就班）
缺点：
不适应需求的变化
问题往往在后期才能发现，错过了及早纠正的机会
错误前期没有发现，可能导致项目失败
快速原型模型
快速开发一个基本产品，快速占领市场，根据用户的反馈和需求在对自己的产品进行功能的开发和完善。
快速原型模型优缺点：
优点：
克服了瀑布模型的缺点，减少不明确的需求，根据用户需求进行相应功能的开发。
缺点：
不适合大型系统开发(适合小型系统)，不一定会有用户提出相应的反馈，导致用户不在使用该产品。好比理想是丰满的，现实是骨感的。
螺旋模型
其实增加了一个风险分析，减少项目开发的失败风险。
螺旋模型优缺点：
优点：
降低项目开发的失败风险，每个阶段都会提前做风险评估分析
缺点：
增加了风险分析，需要有专业的人员来做这个事情。
增加开发成本和开发时间。
测试模型
V模型、W模型、H模型
V模型的阶段：
- 需求分析
- 概要设计
- 详细设计
- 编码
- 单元测试
- 集成测试
- 系统测试
- 验收测试
V模型的优点：
每个阶段都清晰明了。
V模型包含两种测试：
底层测试：对代码层面进行测试
高层测试：对功能层面进行测试
W模型（双V模型）
第一个V：
需求分析
概要设计
详细设计
编码
集成
实施
交付
第二个V：
- 系统测试设计
- 集成测试设计
- 单元测试设计
- 单元测试
- 集成测试
- 系统测试
- 验收测试
W模型的优缺点
优点：
伴随整个开发周期，不仅限对程序进行测试，还可以对需求文档、概要设计、设计图等进行相关测试。
让测试人员提前参与测试，尽早发现初期问题，便于尽早解决，减少开发成本。
缺点：
对测试人员要求提高了，不仅要测试程序，还要测试需求文档，对测试人员的业务能力要求比较高
在执行过程中，可能没有需求文档或者概要设计，无法使用w模式参与测试。
H模型
可以交叉进行测试，测试更加灵活，不一定要按部就班的进行测试，具体测试条件后就可以进行测试了。
H模型的优缺点
优点：
H模型要独立形成一个完整的测试流程，可以和其它流程并行执行
测试更加灵活，满足测试条件则可以进行测试，不需要等到所有功能开发完成以后再测试
可以提前准备测试数据，达到测试就绪点即可提前完成测试执行，及早发现问题，解决问题。
缺点：
管理型要求高
技术能力要求高
测试就绪点分析困难
软件测试分类
按照测试阶段分类
- 单元测试
- 集成测试
- 系统测试
- 验收测试
按照是否查看源代码
- 白盒测试
对程序源代码进行测试，对逻辑和程序结构进行测试
- 黑盒测试
对软件功能进行测试，不关心程序内部结构，只关心输入和输出的结果
- 灰盒测试
介于白盒和黑盒之间的一种测试，不仅对功能进行测试还需要对内部代码进行测试。
- 按照是否执行
静态测试
不运行程序，只对源代码、界面、文档进行测试
动态测试
运行程序，对功能进行测试
- 其它
探索性测试
随机测试
黑盒测试的分类
- 功能测试
- 界面测试
- 逻辑功能测试
- 易用性测试
- 安装与卸载测试
- 性能测试
- 时间性能： 时间响应效率上
- 空间性能： 系统资源使用上
- 压力测试
- 负载测试
测试用例
为特定功能而准备的一组测试（输入数据、执行条件、预期结果），以便验证是否符合特定需求。
说明：测试用例是测试人员进行测试的重要依据，也是测试人员工作量的体现。
*测试用例的8要素
- 用例编号
- 用例标题
- 测试项目
- 用例级别
- 预置条件（执行某个功能的前提条件）
- 测试输入
- 执行步骤
- 预期结果
测试用例设计方法
等价类划分法
输入具有代表性数据的子集。
等价类划分法分为：
有效等价类：满足需求的数据
无效等价类：不满足需求的数据
等价类划分法的设计步骤：
1、明确需求
2、确定有效等价类和无效等价类
3、根据有效等价类和无效等价类编写测试用例
提示：每一个无效等价类要分别对应一条测试用例，一个有效等价类测试用例要尽量覆盖多条有效等价类。
边界值分析法
边界值分析法是对等价类划分法的补充，增加对边界的测试。
边界：
上点：边界上的点
内点：边界内的点
离点：边界附近的两个点
边界值分析法的设计步骤：
1、明确需求
2、确定有效等价类和无效等价类
3、找到条件中的边界值
4、根据有效等价类和无效等价类和边界值编写测试用例
判定表法
有多个输入条件和多个输出结果，多个输入条件之间可以进行组合，多个输出条件和多个输出结果之间有相应的制约和依赖关系。
判断表法的四个组成部分：
条件桩：输入的条件分类
条件项：具体条件对应的值
动作桩：输出结果的分类
动作项：具体输出结果对应的值
判断表法的设计步骤：
1、明确条件桩
2、明确动作桩
3、将条件桩进行全组合
4、明确每个组合对应的动作桩
5、编写测试用例，每列具体的数据就是一条测试用例。
因果图法（了解）
使用图解法的方式形成判定表，其实是判定表的一种升华表现，无非在判断表法的基础上增加了画出因果图，来展示条件与条件之间的因果关系。
适用范围：
它的使用范围和判定表法的使用范围一致，当有多个输入条件和多个输出结果，输入条件与输入条件之间可以全组合，输入条件和输出结果之间有相应的依赖和制约关系时，则可以使用判定表和因果图法。
因果图法的设计步骤：
1、明确输入和输出(找到条件桩和动作桩)
2、画出因果图
3、将因果图转成判定表
4、判断表中的每列条件项数据就是一条测试用例。
场景法
模拟用户操作软件的场景，主要用于测试多个功能之间的组合使用情况。一般会分为正确的操作流程和错误的操作流程。
正确的操作流程称为基本流
错误的操作流程称为备选流
提示：以后基本流和每一个备选流都对应一条测试用例即可
场景法的适用范围：
1、多个功能之间的组合测试，比如： 成功购买商品，要测试登录功能、测试加入购物车功能、支付功能、生成订单功能。
2、冒烟测试的时候也会用到场景法，测试主功能和主流程是否可用，比如：登录、注册、购物。
正交法
使用最小的测试集合来获得最大的测试覆盖率。
正交法也称为正交排列法，正交实验法。
使用场景：
有多个输入数据组合的时候，并且使用最新的测试集合来获得最大的覆盖率的时候即可使用正交法
正交表：
是一个特定表，表达方式：Ln(m^k)
- n: 行数 ，计算公式: k * (m - 1) + 1
- k: 控件的个数，也称为因素数
- m: 每个控件的取值个数，也称为水平数
- 正常读法: k因素m水平
allpairs的使用：
- 把测试的控件及控件索取的值写入到excel里面
- 把excel文件中的数据拷贝到input.txt文件中（不要修改内容）
- 进入到allpairs目录中，打开终端，输入：allpairs.exe input.txt > ouput.txt
- 查看生成好的测试用例ouput.txt
错误推测法
根据测试人员自身的经验和直觉来测试软件中可能出现错误的功能。
比如： 范围的边界，数据的组成规则，非法数据等。
使用场景：
1、任务紧张，时间不够用，不能对测试工作按部就班执行，则可以使用错误推测法。
2、开发的类似模块，之前模块错误比较多，对类似模块的重点测试。
测试用例设计方法总结
- 等价类划分法
当具有单个输入功能且没有长度或范围要求的时候，此时可以使用等价类划分法。
- 边界值分析法
当具有单个输入功能且具有长度或范围要求的时候，此时可以使用边界值分析法。
- 判定表法 / 因果图法
当具有多个输入和多个输出，多个输入之间可以进行组合，多个输入和多个输出之间相互制约或依赖，此时可以使用判定表法或因果图法。
简单理解：当有多个输入条件进行组合产生不同结果的时候，我们就可以使用判定表法或因果图法。
- 场景法
当测试多个功能之间组合测试的时候需要使用场景法。
冒烟测试（一般是对基础的一些功能进行测试）的时候也会用场景法。
- 正交法
当具有多个输入数据组合测试的时候，并且想要使用最小测试集合来获取最大测试覆盖率的时候，可以使用正交法。
- 错误推测法
当软件经历几轮测试后，凭借测试人员自身的经验和直觉对可能出现问题的功能模块进行错误推测法测试。
软件缺陷
软件在使用过程中没有按照指定的需求正常运行，而产生的错误我们就认为是缺陷(bug)。软件缺陷不仅仅包含软件程序，还包含需求文档，设计图上的错误，这些错误也是缺陷(bug)。
软件缺陷的表现形式：
总结一句话就是没有按照指定的需求来完成就是有软件缺陷。
具体表现:
1、软件未达到需求规格说明书标明的功能
2、软件出现了需求规格说明书指明不会出现错误的地方
3、软件的功能超出了需求规格说明书指明的范围
4、软件出现了需求规格说明书虽未指明，而应该达到的目标
5、软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好
软件缺陷产生的原因：
需求文档描述不清楚，有歧义
设计文档有错别字或者错误
编码有错误，导致功能有缺陷
软硬件问题
软件缺陷产生的根源：
需求变化
交流不充分
软件的功能复杂
开发人员自身编写代码的错误
周期短、进度比较赶，无法保证代码质量
软件缺陷要素信息(11要素)
- 缺陷编号
- 缺陷标题
- 缺陷所属模块
- 缺陷严重程度
S表示严重程度的标识字母，一般级别分为1-5，数字越大严重程度越高，但是要以所在公司的标准为主。一般写S3
- 缺陷优先级
P表示优先级的标识字母，一般级别分为1-5，数字越大优先级越高，但是要以所在公司的标准为主。一般写P3
- 缺陷重现步骤
缺陷产生的操作步骤。
-
缺陷状态
- new：新建状态，测试新提交一个bug
- open：打开状态，程序员查看缺陷信息后
- fixed：修复状态， 程序修改完bug
- closed：关闭状态， 验证程序员修改后的功能，没有问题则关闭bug
- reopen：重新打开，如果验证后还有问题，会重新打开bug
- rejected：拒绝状态，程序员认为不是一个bug，或者 bug描述不清楚，bug无法重现
- postpone：拖延状态，这个bug需要延期解决，经过了产品的同意
-
缺陷类型
- 系统缺陷
- 数据缺陷
- 数据库缺陷
- 接口缺陷
- 功能缺陷
- 安全性缺陷
- 兼容性缺陷
- 界面缺陷
- 性能缺陷
- 建议
提示：一般如果确定不了缺陷的分类，可以使用功能缺陷，比较通用。
-
预期结果：产品需求里面要的结果
-
实际结果：表示软件使用实际产生的结果
-
附件
图片、视频
缺陷报告的重要性
清晰的缺陷报告，能够清楚的告诉开发人员错误的重新步骤，提高开发人员工作效率，减少定位错误的时间
清晰的缺陷报告，能够提高测试人员的可信任度，能够让开发及时修改提出的错误。
缺陷报告的注意事项
尽量保证缺陷可以重现
缺陷描述要简洁、准确、完整
一个缺陷报告里面只能包含一个缺陷。
缺陷的跟踪
新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。
如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开；
如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”。
还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期。
对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷。
项目测试流程
- 需求分析
- 需求评审
- 快速熟悉项目
- 编写测试计划
- 编写测试方案
- 设计用例
- 编写用例
- 用例评审
- 执行用例
- 跟踪和管理bug
- 测试报告
