软件测试学习day3

因果图

定义：从程序规格说明书的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表，最后为判定表中的每一列设计一个测试用例

适用范围：适合于不同条件组合对应不同的结果状态，根据条件不同组合的情况输出不同的测试用例

标识：

约束符号：

场景法

概念：事件触发时的情景形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流

场景法一般包含基本流和备选流

猜错法

概念：猜错法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法

基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例

缺陷

概念：软件缺陷是指存在于计算机程序中的错误、失效，或者由于程序中故障令计算机无法正常工作或产生不正确的结果

符合四个规则之一就是软件缺陷：

1. 软件未实现产品说明书要求的功能
2. 软件出现了产品说明书指明不应该出现的错误
3. 软件实现了产品说明书未提到的功能
4. 软件难以理解、不宜使用、运行缓慢或者——从用户角度体验不好

缺陷的属性：

1. 缺陷表示：缺陷表示是标记某个缺陷的一组符号，每个缺陷必须有一个唯一的标识
2. 缺陷类型：缺陷类型是根据缺陷的自然属性划分的缺陷种类
3. 缺陷严重程度：缺陷严重程度是指缺陷引起的失效对软件产品的影响程度
4. 缺陷优先级：指缺陷必须被修复的紧急程度
5. 缺陷状态：指缺陷通过一个跟踪修复过程的进展情况
6. 缺陷起源：指缺陷第一次被检测到的阶段
7. 缺陷摘要：用一句话概要地描述缺陷的现象
8. 缺陷描述：详细的描述缺陷重现的环境、前置条件、步骤、期望结果、实际结果等
9. 指定的负责人：通常是负责修复该缺陷的开发人员，在有的系统中也支持开发人员修复好缺陷修改其在缺陷跟踪系统中的状态后把它指定给相关的测试人员
10. 缺陷出现版本：缺陷被发现的版本
11. 缺陷解决版本：缺陷被修复的时候由开发人员填写
12. 解决办法：由开发人员修复缺陷的时候填写
13. 验证版本：反映缺陷的修复在哪个版本被验证了
14. 附件：附加的屏幕截图、服务器或客户端日志等相关文件，便于开发人员定位缺陷的原因

缺陷类型：

• 代码错误
• 系统错误
• 需求变更
• 界面优化
• 其他

缺陷严重程度：

• Critical（致命）：主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用
• Major（严重）：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。例子：功能未实现、功能存在报错、数值轻微的计算错误
• Minor（一般）：界面、性能缺陷。例子：边界条件下错误、容错性不好、大数据测试容易无响应、大数据操作时没有提供进度条
• Cosmetic（建议）：易用性及简易性问题