软件测试的生命周期

需求分析 – 测试计划 – 测试设计、测试开发 – 测试执行 – 测试评估

需求分析：需求是否完整，是否正确
测试计划：确定软件由谁测试，什么时候开始，什么时候结束，测试哪些模块
测试设计、测试开发：写测试用例（手工测试用例、自动化测试用例），编写测试工具
测试执行：执行测试用例
测试评估：测试人员产生测试报告

如何描述一个bug

1. 发现问题的版本
   开发人员需要知道出现问题的版本，才能够获取对应版本的代码，来重现故障。版本的标识也有助于统计和分析每个版本的质量。

2. 问题出现的环境

3. 错误重现的步骤

4. 预期行为的描述

5. 错误行为的描述

6. 其他

7. 不要把多个bug放在一起

如何定义bug的级别

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

1. Blocker（崩溃）
   阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环、数据库数据丢失、数据库连接错误、主要功能丧失、基本模块缺失等问题。
   如代码错误，死循环，数据库死锁，重要的一级菜单功能不能使用等。（这种问题在测试中很少见，一旦出现了，立即中止当前的版本测试）— 测试打回

2. Critical（严重）
   系统主要功能部分丧失，数据库保存调用错误，用户数据丢失。模块无法启动或调用。

3. Major（一般）
   功能没有完全实现，但不影响使用，功能菜单存在缺陷，但不影响系统稳定性。
   如操作时间过长，

4. Minor（次要）
   界面、性能缺陷、建议类问题，并不影响操作功能的执行，属于可以优化性能的方案。

bug的生命周期

new：发现问题，还没有指派给开发
open：确认是bug，将bug指派给开发
fixed：开发人员将bug修复结束后，标识称修改状态，等待测试人员的回归测试验证。
reopen：测试验证后bug仍然存在，打回，开发再次修改
closed：修改状态的bug在测试人员回归测试通过，修改完成，这个bug的生命周期结束。
rejected：认为不是一个bug，拒绝修改
Delay：认为暂时不需要修改或者暂时不能修改，延后修改

产生争执怎么办（处理人际关系）

1. 首先，测试人员需要确保操作没有问题，确保自己对需求的理解没有问题。
2. 好好交流
3. 站在用户的角度考虑
4. 不光要发现问题，提出解决问题的方案。
5. 第三方会议
   • 开会前：明确问题的产生原因，问题是什么，解决方案是什么
   • 开会后：问题要不要解决，什么时候解决，如何解决。

如何开始第一次测试

1. 充分理解需求
   文档（产品文档 + 技术文档）
   项目功能问题：问产品；
   模块底层如何实现：问开发
   尽可能参加各种项目会议，

2. 确定测试计划

3. 执行测试
   bug开发修复之后，一定要进行验收

4. 项目上线 + 维护

测试的执行和bug管理

如何发现更多的bug

1. 软件测试存在二八原则，80%的故障集中于20%的模块
2. 开发人员存在二八原则，80%的故障集中于20%的开发人员
3. 多进行逆向思维和发散性思维（依赖于测试人员的经验）
4. 不局限于用例和需求文档
5. 尽早介入项目。