一、软件测试基本流程

1、测试需求分析阶段：理解需求、分析需求点，参与需求评审会议

2、测试计划阶段：编写测试计划、参考软件需求规格说明书、项目总体计划、测试范围、进度、人力物力分配、测试策略、风险评估与规避措施制定、测试人员参与相关评审工作

3、测试设计阶段：编写测试用例，参考需求文档（原型图）、概要设计、详细设计文档等，完成后需要进行评审

4、测试执行阶段：（编译完成提交代码包）搭建测试环境、执行预测（冒烟测试）--- 判定当前版本可测与否，ok正式进入系统测试，遇到问题提交bug到缺陷管理平台，并对bug进行跟踪，直到达到测试需求，无重大bug，测试结束。（完全测试是不可能的，测试达到客户需求即可终止）-------完善测试用例

提交bug后要进行2 到3轮回归测试

5、测试评估阶段：出测试报告，对整个测试过程与版本质量做一个详细评估（有多少个bug，），确认是否能上线。----项目发布总结会议

6、版本线上验证测试阶段：测试闭环-及时跟进线上系统发版本后存在的隐患（测试环境无法复现的问题等）

二、bug缺陷级别分类

1、测试BUG等级划分标准

• Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等
• Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
• Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)
• Minor（轻微）：界面、UI，建议类问题，不影响操作功能业务流程的执行，如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好

2、BUG状态标准

• 待处理（new）：测试人员或用户发现新问题后提交的状态
• 已确认（open）：经测试人员及研发人员讨论后确认是BUG，提交的状态，由测试人员来设置。
• 已处理（fixed）：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。
• 已修改（closed）：测试人员认为问题已经修改，通过验证，由测试人员设置。
• 仍存在（reopened）：测试人员认为BUG未修复成功，问题仍然存在，由测试人员设置。
• 不是问题（reject）：研发人员确认不是BUG，或者建议与意见决定不采纳。
• 暂不处理（hold）：当前版本不做修改，后续版本再考虑，由研发人员或测试人员设置。