软件测试基准
目录
一、软件测试人员的主要职责
测试人员最本质的工作就是寻找bug，提交bug、验证bug、推进bug的解决，直至软件达到发布的标准，提高软件的质量及研发的工作效率和质量。
二、软件测试工作流程：
1、流程图
2、简述测试流程：
1) 软件测试人员进行测试需求分析（根据产品输出的需求文档、MRD、PRD、GUI等）
2) 软件测试负责人编写测试计划
3) 测试人员根据测试需求分析设计和编写测试用例并进行测试用例评审会议
4) 测试人员搭建测试环境、创建测试数据、执行测试用例、并且提交缺陷报告并进行跟踪、记录、复现测试事件
5) 进行测试评估和总结，输出测试报告、提交风险评估等
三、bug的生命周期
1、简易流程：
生命周期中缺陷状态：新建–>指派–>已解决–>待验–>关闭
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG
2、细节流程：
l 创建缺陷：当测试人员发现新的缺陷时。他应该向开发团队提供一份适当的缺陷文档，来帮助重现和修复缺陷。在此状态下，测试人员发布的缺陷状态为“创建”
l 指派分配：处于创建状态的缺陷将通常由测试负责人/项目负责人分配给开发团队。一旦分配了缺陷，缺陷的状态就变为“已指派”或者“已分配”。
l 确认(打开)缺陷：开发团队开始分析确认缺陷并开始修复工作。
l 已解决：当开发人员进行必要的代码更改并验证更改通过时，缺陷的状态将更改为“已修复”或“已解决”，缺陷将传递给测试团队。
l 验证测试：在开发人员修复错误后，测试人员将重新验证该缺陷。如果在软件中没有检测到缺陷，将更改其状态为“已验证”。
l 关闭缺陷 在验证通过后，那么bug的状态将被更改为“关闭”。
l 重新打开：测试人员将重新验证该缺陷。如果在软件中没有检测到缺陷，将更改其状态为“重新打开”。
l 重复缺陷 如果有相关缺陷已提交两次以上，或者缺陷与缺陷的概念或者深层次的起因相同，开发团队将状态更改为“重复BUG”。
l 无法复现：如果缺陷提交后开发人员根据缺陷复现步骤无法复现，并与测试人员沟通后测试人员仍然无法复现则将状态更改为“无法复现”
l 不予解决：开发人员确认该缺陷在技术层面无法解决，则将状态更改为“不予解决”
l 需求确认：缺陷问题引起测试及开发有争议的，转给产品经理确认需求是否需要处理。将状态更改为“需求确认”并指派给产品经理。
l 需求变更：缺陷问题经过产品经理确认后需要开发人员更改的，则将状态改为“需求变更”，并附上更新后的需求文档，将缺陷指派给对应开发
l 延期处理：开发人员确认缺陷后，与项目经理确认当前版本暂不更改，则将缺陷状态改为“延期处理”，并指派给项目经理作为延期版本缺陷处理记录
l 设计如此：缺陷问题在需求文档中体现了，则附上需求文档中的相关资料，放入jira备注中，将状态更改为“设计如此”并指派给对应提交缺陷人员
四、BUG的类型：
u 代码错误
u 设计缺陷
u 界面缺陷
u 性能问题
五、BUG的严重等级：
P0（致命的）：致命错误，造成系统崩溃、死机、造成数据丢失、主要功能完全丧失等
P1（严重的）：严重错误，功能模块或特性未实现，主要功能丧失，次要功能完全丧失，或错误的生命等
P2（一般的）：不太严重的错误，次要功能模块丧失，提示信息不够准确，用户界面布局差，功能相应时间过长等
P3（轻微的）：错别字、文字排版不整齐、UI界面小问题、软件功能仍然可以使用等
六、BUG优先级：
P0最高优先级（紧急的）：缺陷很紧急且严重，需要立即修复，block测试、功能丢失、必现崩溃等
P1较高优先级（严重的）：软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷等
P2高优先级（中等的）：影响软件功能和性能的一般缺陷，功能实现不稳定等
P3较低优先级（一般的）：本地化软件的字体翻译，错别字，UI问题等
P4最低优先级（轻微的）：对于软件使用影响非常轻微的或出现几率非常低的不重要缺陷
