软件测试的生命周期：
之前说过软件的生命周期（6阶段）：需求分析，计划，设计，编码，测试，运行维护
软件测试的生命周期（6阶段）：需求分析，测试计划，测试设计，测试开发，测试执行，测试评估
软件测试&软件测试的生命周期
- 需求阶段
测试人员了解需求，对需求进行分解，得出测试需求
- 计划阶段
根据需求编写测试计划/测试方案
- 设计阶段
测试人员适当了解设计，搭建测试用例框架，编写测试用例，编写自动化测试
- 编码阶段
测试人员一般不需要编码，需要对需求进行测试
- 测试阶段
软件测试人员最重要的一个阶段，编写测试报告
- 运行维护
测试人员需要参与项目的实施工作，需要参与用户使用软件的培训
如何描述一个bug
一个合格的bug描述应该包括以下几个部分：
- 发现问题的版本
开发人员需要知道出现问题的版本，才能获取到对应版本的代码来重现故障。并且版本的标识也有利于系统和分析每个版本的质量
2.问题出现的环境
环境分为硬件环境和软件环境：如果是web项目:需要描述浏览器版本，客户机操作系统等；如果是app项目：需要描述机型，分辨率，操作系统版本等
3.错误步骤
测试用例的最短操作步骤
4.预期行为的描述
要让开发人员知道怎么阳才是正确的，尤其要以用户的角度来描述程序的行为是怎样的，如果是依据需求提出的故障，能写明需求的来源是最好的（测试人员是最懂需求的）
5.错误行为的描述
可以上层日志或者截图
6.其他
Bug的级别
每个公司的定义都不一样，但大致为以下几个级别
- 崩溃（Blocker）:测试中出现较少，一旦发现应立即终止对版本的测试
造成系统奔溃，死机，死循环，导致数据库数据丢失，以及数据库连接错误，主要功能丧失，基本模块缺失等问题
- 严重（Critical）：在不影响其他功能测试的情况下可以继续测试该版本
系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，一级菜单不能使用三十奴一下其他功能的测试。功能设计与需求严重不符，模块无法启用或调用，程序重启，自动退出，关联函数间调用冲突，安全问题，稳定性等。软件数据保存后，数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等
- 一般（Major）：在实际测试中存在最多
功能没有完全实现但是不影响使用，功能菜单存在缺陷但是不会影响系统稳定性。如：操作时间长，查询时间长，格式错误，边界条件错误，删除没有确认框，数据库表中的字段过多等
- 次要（Minor）：在测试初期较多，优先程°较低，在测试后期出现较少，应及时处理
界面，性能缺陷，建议类问题，不允许操作功能的执行，可以优化性能的方案等，如：错别字，界面格式不规范，页面显示重叠，不该显示的要隐藏，描述不清楚，提示与丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等
bug的生命周期：
每个公司，每一个工具对bug生命周期的定义不一样，但是大致为以下几个过程
测试人员应该跟踪一个bug的整个生命周期，从New到Closed
- New:新发现的bug，未经评审决定是否指派给开发人员修改
- Open：确认是bug，并且需要进行修改，指派给相应的开发人员
- Fixed：开发人员进行修改后标识成修改状态，带测试人员的回国测试验证
- Rejected：如果认为不是bug，则拒绝修改
- Delay：如果暂时认为不需要修改或暂时不能修改，则延后修改
- Colsed：修改状态的Bug经测试人员的回归测试验证通过，则关闭BUG
- Reopen：如果经验证bug仍然存在，则需要重新打开Bug，开发人员重新修改
注：open->closed,open->rejected->closed
软件测试的二八原则：80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度
开发人员的二八原则：80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度