规范：测试的一些规范

1. 测试用例整体要求

测试用例编写应严格根据原型图、流程图以及需求文档进行，要求覆盖全部需求功能点。

测试用例编写当前直接使用PingCode 平台的用例模版。

测试用例中要写清楚测试的操作步骤和预期结果，能被不同人员理解和执行。

同一个功能点的测试用例，移动端和PC端需要单独编写，因为他们的界面和操作不同。

2. 用例设计步骤

测试需求分析：

从原型图中，找出待测模块的需求，通过自己的分析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点。

业务流程分析：

对被测模块的业务流程要进行全盘的整理，主要包含该业务流程的主流程、备选流程、数据流向、关键判断条件以及完成该操作的条件。

测试用例设计：

测试用例设计的类型主要包括功能测试、边界测试、异常测试。

测试用例评审：

由测试用例设计者发起，参加的人员需包括测试、产品、开发。

测试用例完善：

测试用例编写完成之后需不断完善，产品新增功能或更新需求后，测试用例必须配套修改更新；

在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；

在交付使用后客户反馈的缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

3.bug建立与关闭规范

测试：

bug建立：BugTracker 对应版本的测试环境bug收集中建立子任务

bug关闭：状态改为已关闭 备注已验证

上线：

bug建立：BugTracker  对应版本的生产环境bug收集中建立子任务

bug关闭：状态改为已关闭 备注已验证 在对应版本的生产环境bug发布中进行编辑 记录所关闭的bug号以及修改端

4.bug编写规范

bug建立要写标题 指派人 产品线 计划完成日期

bug标题应该包括三个部分：现象(what) 地点(where) 条件状态(how) 发生了什么 哪里出现的 如何发生的 要重点描述问题现象 让开发人员能够看到问题的所在

可以在描述中写清楚必要步骤 既不要太啰嗦 也不要太简略 如果可以截图 一定要截图

一般情况下 一个bug只记录一个缺陷 一个功能点有多个缺陷 可以记录在一条bug 相同功能点相同问题 在多端产生 可以记录在一条bug

在bug回归时出现问题 沟通后可以将状态改为反馈 在备注中写明反馈原因 缺陷解决验证情况 以便后续回归 直至验证无误

5.生产事故分级

P0-紧急：整个系统无法使用

P1-高:系统的某个功能或者独立模块无法使用

P2-中:系统中的功能有异常 但通过其他方式仍能正常使用

P3-低:系统中的前端显示有问题但功能正常