软件测试规范

一、测试场景设计：

1、UI测试：

①跟原型，UI设计一致；

②字体是否统一；

③字号是否符合规定；

④界面布局是否合理，整体效果如何；

2、功能测试：

①正常情况；

②异常情况；

③边界情况；

④破坏性测试；

⑤用户友好性测试；

⑥输入值测试：

a、数据类型；

b、数据长度（截取方式限制长度）

c、约束条件是否满足，是否完整；

d、枚举值停用测试（后面添加（已停用），老数据不处理，新增编辑时选择不到已停用的枚举值）；

3、接口测试（根据功能是否需要做接口测试）：

①业务功能正常场景，异常场景；

②输入输出边界测试，参数必填非必填；参数排序，个数，类型；参数包含特殊字符；

推荐用的接口工具：postman，jmeter

4、性能测试（根据项目排断是否需要做性能测试）：

①系统的大用户压力；

②系统的并发用户压力；

③系统的数据库压力；

④系统的稳定性等；

⑤输出《性能测试报告》，主要包括：性能指标，平均响应速度，吞吐量，系统用户的压力等数据；

5、兼容性测试：

①web兼容性测试：

a、浏览器支持包括IE8/9/10/11、360浏览器、火狐浏览器、Chrome 19.0以上版本；

②APP兼容性测试：

a、根据项目要求，关注安卓，IOS系统不同版本，手机型号，屏幕大小的兼容；

6、安全性测试（根据项目需求进行测试）：

①功能性的安全测试：

a、密码输入掩码；

b、密码加密传输；

c、定时强制修改密码；

d、http和https协议测试；

②攻击类的安全测试：

a、SQL注入等；

二、用例编写规范：

1、按照提供的模板，有层级的编写测试用例；

2、根据设计的测试场景全部写入用例，并且标记好用例的优先级；

3、用例里面需要写清楚数据的流向，以备后续查阅。

三、测试规范：

1、需求提测之后，测试用优先级为高的用例进行冒烟测试，冒烟测试通过之后，方可进行整个需求测试，若冒烟测试不通过，写清原因打回给开发，让开发自验修复达到提测的质量再次提测；

2、文本框长度的测试：非特殊要求，以截取的方式处理；

3、停用的枚举值测试：原数据不变，后面写加（已停用），新增编辑的时候不能选择已停用的枚举值；

4、数据类型边界值测试：前后端都需要校验，鼠标移开之后，给出提示；

5、必填校验测试：前后端都需要校验；

6、唯一性测试：后端校验；

7、导入模板：根据表头校验，数据合法性校验，并且表头要有提示信息，有模板说明；

8、导入的时间格式为XXXX/XX/XX

四、Bug级别定义标准：

五、Bug修复紧急程度：

1、致命：立马修复，优先级最高；

2、严重：当天修复，优先级高；

3、一般：两天内修复，优先级一般；

4、细微：本迭代内修复完成，优先级低；

5、建议：根据时间选择性修复。

六、交叉互测质量保证：

1、如何判断那些需求需要进行交叉互测（由质量负责人根据该需求的难易程度，以及业务程度进行判断）?

2、交叉互测的内容必须保证发现的BUG级别在一般或者一般以上的问题全部修复完成之后，才可以进入交叉互测；

3、交叉互测的泄漏率不能超过20%（交叉测试bug数/bug总数）。

七、需求开发质量定义：

1、质量非常好：需求功能全部实现，0个bug。

2、质量较好：需求功能全部实现，需求缺陷密度不大于0.2（bug数/用户故事）；

3、质量一般：需求功能全部实现，需求缺陷密度不超过0.4（bug数/用户故事）；

4、质量差：需求极小部分功能实现，需求缺陷密码不超过1（bug数/用户故事）；

5、质量极差：需求大部分功能实现，需求缺陷密度大于1（bug数/用户故事）。

八、系统测试：

1、如何判断本迭代需要进行系统测试不？

①一般情况都需要进行系统测试；

②如果测试时间紧，可以根据迭代需求范围来判断，是否进行全系统系统测试还是部分模块进行系统测试。

2、系统测试力度：

①测试时间充足，可以进行所有功能测试；

②测试时间一般，可以进行未牵扯的老功能的冒烟测试，有关联关系的老功能进行系统测试；

③测试时间紧张，可以进行本迭代需求以及周边功能的系统测试。

九、部署用户环境标准：

1、一般及一般以上级别的BUG全部修复完成；

2、不存在影响使用的严重问题；

3、剩余的问题以及优化方案不影响基本功能使用，可以在优化阶段完善；

4、98%及98%以上的模块，达到“稳定”状。

十、遗留问题处理：

1、遗留的bug需要跟产品，研发主管，质量负责人进行评估，是否会影响用户使用，以及修复的时间；

2、遗留的问题如果是方案问题，产品需要提供最新方案。