测试基础篇

软件测试的生命周期

软件测试的生命周期：需求分析→测试计划→测试设计、软件开发→测试执行→测试评估

软件测试&软件开发生命周期

1）需求阶段
测试人员了解需求，对需求进行分解，得出测试需求
2）计划阶段
根据需求编写测试计划/测试方案
3）设计阶段
测试人员适当了解设计，对设计测试用例设计很有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例
4）编码阶段
测试人员一般不需要编码的额，但已经编码的模块，专业的白盒测试人员可以计划单元测试，完善、细化测试用例及调整测试计划和方案。
5）测试阶段
测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告。
6）运行维护
测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达 能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人。

测试用例设计

如何描述一个bug

如何创建一个Bug

创建 Bug 的要素：问题出现的版本、问题出现的环境、出现步骤、预期结果、实际结果等

案例

Bug的级别

1. Blocker（崩溃）

2. Critical（严重）

1. Major（一般）

1. Minor（次要）

Bug的生命周期

测试人员在执行测试的过程中，如有发现 Bug，需要在对应的 Bug 管理平台来创建 Bug

• New：测试人员创建了一个 Bug
• Open：开发人员要去确认是否是 Bug，是 Bug 状态就改为 Open，不是 Bug 就拒绝 （rejected）
• Fixed：开发人员在修复完成之后将 Bug 状态改为 fixed
• Rejected：如果认为不是 Bug，则拒绝修改
• Delay：确认是 Bug 之后，如果 Bug 优先级比较低且开发人员不能立即修复 Bug，状态改为 delay
• Closed：Bug 确认修复完成，测试人员将 Bug 改为 closed
• Reopen：Bug 确认修复未完成，测试人员将 Bug 状态改为 Reopen

• 测试人员和开发人员产生争执了怎么办？

• 多反思自己，是不是 Bug 创建的时候描述不太清楚
• 开发人员对 Bug 级别不认可，Bug 定级一定要有理有据，测试人员需要明确企业 Bug 定级规范，拿着规范和开发人员沟通，为什么这样定级
• 合理友好的进行沟通，站在用户的角度反问，如果你是用户，你能接受这样的功能吗，提 Bug 必定会增加开发人员的工作量，小问题不想解决
• 不仅能够发现问题，最好也能够提出解决方案给开发参考
• 如果确实是 Bug，友好沟通已经不能解决问题了，那就召开 Bug 评审，需要有相关的代表来参加：产品代表、开发代表、测试代表等 （1. 如何解决 Bug 2. 如何预防类似的 Bug 再发生）