【质量管理】测试流程规范

测试流程及规范

一、目标

制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化、标准化。

二、测试流程说明

三、需求评审（需求澄清）

参与人员，包括：产品、ui、开发、测试。
产品人员提出需求，对照产品文档进行需求宣讲。
开发人员考虑功能实现的方案与可行性。
测试人员对需求的理解提出疑问，以便根据需求写用例，测试。

四、开发人员排期

开发人员需要根据需求功能点进行排期，然后同步开发排期。

五、测试计划排期

测试根据当前需求内容，确定需要测试的内容、范围、颗粒度，有针对性的进行进行测试计划制定。根据项目开发计划，安排测试的具体测试时间，然后同步测试排期。

六、编写测试用例

根据详细的需求文档，开始进行用例的编写。
用例需要标注模块、用例名、用例操作步骤、预期结果、用例执行状态。
根据项目需求也可以使用xmind脑图书写测试点。
用例应当覆盖产品文档中的所有功能点。
在用例集中选取p0级主流程用例形成冒烟用例集，作为提测准入门槛。

七、用例评审

用例评审前，先将用例发送给相关人员，以便他们事先了解用例将对哪些功能进行验证以及验证的细节。
在用例评审中，参与人员需要对用例中与实际功能不符合的用例或者格式不规范规用例提出修改建议。
与会为开发产品人员时，测试人员可以摘取主要或复杂逻辑用例进行重点评审；与会为测试组成员时，需要对全部用例进行评审。

八、提测

开发人员完成所有功能后，对提测功能进行一个自测。
测试人员针对冒烟用例进行测试，如果冒烟测试不通过，打回，开发组修复后再提测。
冒烟用例定义：主流程主要功能用例，应当简洁可读可执行。

九、测试

冒烟测试通过，测试组进入测试阶段
执行所有测试用例，根据实际情况，对测试用例进行增改。发现缺陷提交问题单，问题单跟踪提交给开发人员进行修复处理，测试复测。有异议的bug及时与相关干系人沟通处理（产品、前后端开发）
每日汇报测试进展：模块测试进度百分比、当前主要问题。
根据版本计划内容，在上线前进行当前未关闭状态bug处理会。由与会人员标注bug处理意见：当前版本上线前必须修复、可上线后小版本迭代修复、归档下个版本修复、不处理。
测试执行完毕，版本发布前，无紧急严重级别bug时，可以交由产品、需求方进行用户体验测试。

十、测试通过

经过两到三轮测试后，至未发现新的问题、已知问题已沟通确认处理完毕后，通过上级确认，可以通过测试，准备上线。
上线前、上线后，需要进行所发布版本的主流程功能回归测试。
线上进行业务的每日拨测，前期可予新上功能分配较多测试资源。

附：

bug等级划分：

bug严重程度一般可分为4个等级，根据问题的实际影响正确填写，严禁不区分问题的实际影响随意填写，对应级别如下：

一、致命的Bug

导致用户没法使用，包括不限于服务端瘫痪、App Crash等，包括但不仅如下：

1. 服务端资源配置（如内存泄露、其他资源占用不合理等）导致大面积用户受影响的Bug
2. 涉及用户财务相关的Bug
3. 数据库发生死锁
4. 用户高并发场景下的服务端性能问题，导致大面积用户受影响的Bug
5. 服务端严重的计算错误
6. 客户端内存泄漏导致的数据错误
7. 由客户端操作所引起的程序死机,非法退出，Crash，通讯中断（如云信密码错误、登录失败）
8. 重要功能未实现或实现的与需求不相符
9. 用户权限问题
10. 程序引起的安全问题
11. 其他影响大面积用户、出现几率高的问题
12. 严重的兼容性问题

二、严重的Bug

系统关键功能、关键环节出现问题，严重影响用户使用

1. 客户端性能低下，如卡顿、耗电量高、流量消耗高等问题
2. 轻微数据计算错误
3. 功能不符
4. 严重地影响系统要求或基本功能的实现，但存在合理的更正办法
5. 界面严重错误
6. 配置文件错误

三、一般的Bug

不影响用户使用，包括前端业务逻辑错误、后端业务逻辑错误

1. 简单的输入限制未放在客户端进行控制
2. 数据输入没有边界值限定或不合理
3. 错误操作没有任何提示
4. 使操作者不方便或遇到麻烦，但它不影响执行工作或功能实现
5. 辅助说明描述不清楚
6. 显示格式不规范
7. 操作界面不规范
8. 界面错乱/重叠
9. 错别字
10. 描述提示语与需求不符

四、建议类

优化用户体验的建议。响应方式：由运营整理并定期与产品讨论

1. 不利用用户操作的改进建议
2. 功能需要增加的建议
3. 界面显示问题的建议

bug紧急程度：

优先级说明
1-紧急：必须在一个工作日内修复，立即处理，插入到当前的产品迭代版本中，高于其他需求开发。
2-高优：在三个工作日内修复，快速处理，插入到当前的产品迭代中，但是低于部分本次迭代需求开发任务。
3-中优：五个工作日内修复，处理，可以考虑随着下一次产品迭代进行处理。
4-低优：有时间再修复，选择性处理，根据迭代进度可放入下次迭代或者下几次迭代中进行处理。