软件测试流程及规范

一、概述

本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准以及测试流程进行总体规范，以有效保证软件产品的质量。

项目软件测试是对软件设计的一种控制手段，是对软件产品质量的一种检查和审核手段，项目测试人员应按本规范要求对软件进行检查、测试。

二、测试目的

1. 为了确保软件产品质量，使产品能够顺利交付和通过验收；

2. 测试是为了发现程序中的错误而执行程序的过程；

3. 好的测试用例是极可能发现迄今为止尚未发现的错误的用例；

4. 成功的测试是发现了至今为止尚未发现的错误的测试。

三、测试流程

无规矩不成方圆，做好项目就是做正确的事情，而正确地处理事情才能更好地提高效率。测试人员在接到一个新的项目或需求版本后，需要按照以下流程逐步开展测试工作，该流程在实际的工作中，可根据实际情况进行补充和完善。

（1）.测试参考文档

在测试人员开展工作之后，需要借助产品人员和开发人员提供的文档，形式的文档可以给测试工作带来依据。具体参考文档包括：产品需求说明书、产品设计原型、UI设计稿、数据库设计方案、接口说明文档、开发人员（前端和后端）任务分配表等。

（2）.测试工作流程

1.参与需求原型评审

工作内容：一方面，便于了解需求进而更好地开展之后的测试工作；另一方面，提出符合实际的建议，以完善产品功能和提高用户易用性为目的优化产品需求；需求理解透彻，评审会上短时间尽量举一反三，提出测试异常场景。

时间节点：需求原型评审会议上

结果产出：无

2.制定测试计划

工作内容：需求原型最终定下来之后，根据项目情况制定测试计划。包含测试人员分配、测试工时的评估、测试范围规定、测试方法罗列。

时间节点：需求原型评审会议后

结果产出：禅道上测试版本、测试单的创建

3.设计编写测试用例

工作内容：根据需求版本优先级，设计编写测试用例。

时间节点：功能开发阶段，一般情况下同步于开发

结果产出：初版测试用例

4.用例评审

工作内容：参与本次版本的测试人员用例评审（采用交叉测试，互相评审修改用例），以便查漏补缺，尽可能使用例覆盖更全面。

时间节点：测试用例设计完成后，一般赶到开发完成之前，便于开发时可以进行参考

结果产出：补充完善的测试用例（用例终版完成后上传至禅道）

5.接口测试

工作内容：根据API文档，提前介入测试，通过入参出参，流程测试，尽早发现后端Bug。

时间节点：待后端接口开发完成，给出API文档后，根据需求判断是否需要做接口测试

结果产出：禅道上提交的接口Bug

6.功能测试

工作内容：执行测试用例，跟踪Bug的生命周期（发现--提交--开发修改--回归测试--关闭）。

时间节点：一般情况开发联调结束，完成所有需求功能后提测；视整体项目开发周期，可能存在开发完成一个模块就进行提测

结果产出：禅道上提交的功能BUG

7.测试报告

工作内容：根据测试结果编写测试报告

时间节点：执行完成所有测试用例，测试通过后

结果产出：禅道上的测试报告

四、测试用例规范

（1）.测试用例模板

根据项目版本实际情况，自由选择excel格式或者xmind思维导图格式；如果版本是由多人协作共同完成，需提前沟通选择同一格式编写用例。

1. EXcel格式

2.xmind思维导图

（2）.测试用例设计方法

根据项目需要，目前主要进行的有功能测试和接口测试。现阶段以功能测试为主，目前使用最多的测试用例设计方法有等价类划分法、边界值分析法和错误推测法。这三种都属于最常用、最典型、也是最重要的黑盒测试方法。其他的方法还会涉及到因果图法、流程分析法、正交分析法、场景法、判定表法等。

1.等价类划分法

将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。

2.边界值分析方法

选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。从方法论上可以看出来，边界值分析是对等价类划分的补充，所以这两种测试方法经常结合起来使用。

3.错误推测法

在很大程度上是凭经验进行的，是凭测试人员对过去所作的测试工作结果的分析，对所揭示的缺陷的规律性作直觉的推测来发现缺陷的。

示例：针对“用户登录”功能，基于等价类划分和边界值分析方法，设计的测试用例包括：

1.输入已注册的用户名和正确的密码，验证是否登录成功；

2.输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；

3.输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；

4.用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；

5.用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；

6.如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；

7.如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。

如果再加上错误推测法（因人而异），会再增加以下的测试用例：

1.用户名和密码是否大小写敏感；

2.页面上的密码框是否加密显示；

3.后台系统创建的用户第一次登录成功时，是否提示修改密码；

4.忘记用户名和忘记密码的功能是否可用；

5.前端页面是否根据设计要求限制用户名和密码长度；

6.如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；

7.刷新页面是否会刷新验证码；

8.如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；

9.用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；

10.不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；

11.页面默认焦点是否定位在用户名的输入框中；

12.快捷键 Tab 和 Enter 等，是否可以正常使用。

4.非功能性测试

一个质量过硬的软件系统，除了显式功能性需求以外，其他的非功能性需求即隐式功能性需求也是极其关键的。显式功能性需求的含义从字面上就可以很好地理解，指的是软件本身需要实现的具体功能。比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等，这都是属于典型的显式功能性需求描述。从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。

示例：继续完善“用户登录”的测试用例。

在安全性方面补充的测试用例包括：

1.用户密码后台存储是否加密；

2.用户密码在网络传输过程中是否加密；

3.密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；

4.不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重 新定向到用户登录界面；

5.密码输入框是否不支持复制和粘贴；

6.密码输入框内输入的密码是否都可以在页面源码模式下被查看；

7.用户名和密码的输入框中分别输入典型的“SQL注入′ or 1=1”字符串,验 证系统的返回页面；

8.用户名和密码的输入框中分别输入典型的“XSS跨站脚本 <script>alert(“xx”)</script>”字符串，验证系统行为是否被篡改；

9.连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；

10.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否 符合设计预期；

11.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

站在性能压力测试的角度测试用例包括:

1.单用户登录的响应时间是否小于 2 秒；

2.单用户登录时，后台请求数量是否过多；

3.高并发场景下用户登录的响应时间是否小于 5 秒；

4.高并发场景下服务端的监控指标是否符合预期；

站在兼容性测试角度测试用例补充包括：

1.不同浏览器下，验证登录页面的显示以及功能正确性；

2.相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；

3.不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确 性；

4.不同分辨率的界面下，验证登录页面的显示以及功能正确性。

对于高质量的软件测试，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等一系列的非功能性需求，这些非功能性需求对软件系统的质量有着举足轻重的作用。但软件测试的用例设计是不可穷尽的，工程实践中难免受制于时间成本和经济成本，所以测试人员需要兼顾缺陷风险和研发成本之间的平衡。

五、缺陷规范

（一）.BUG的严重性定义

根据所提交Bug的严重性，本规范定义以下四个级别。

A/B/C/D四种级别分别对应禅道的1/2/3/4四种级别：

A类：严重错误，包括以下各种错误：

1.由于程序所引起的死机，非法退出

2.崩溃、闪退、应用未响应

3.主流程报错/不通畅，或者涉及金钱交易错误

4.死循环

5.数据库发生死锁

6.因错误操作导致的程序中断

7. 功能未实现或者功能错误

8.与数据库连接错误

B类：较严重错误，包括以下各种错误：

9.接口直接报错

10.支流程不通畅

11.次要功能错误

12.页面交互错误

C类：一般性错误，包括以下各种错误：

13. UI显示错误，文案错误

14. 刷新机制

15.功能易用性不高

16.功能操作前端或者后端无提示，或者提示错误

17.限制未放在前端或后端进行控制

D类：测试建议，包括以下各种错误：

18.指UI美化，文案优化

19.辅助说明描述不清楚

20.报错提示文案不友好

21.可输入区域和只读区域没有明显的区分标志

（二）.BUG的优先级定义

根据所提交BUG的优先级，本规范定义以下四个级别。

Highest/High/Medium/Low四种级别分别对应禅道的1/2/3/4四种级别：

1. Highest：表示问题必须马上解决，否则软件主流程发生堵塞，影响测试进度。

2. High：表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。

3. Medium：表示有时间就要解决，否则系统偏离了需求或预定功能不能正常实现。

4. Low：表示可以稍缓解决，表示问题不影响需求的实现，但是影响其他使用方面，比如UI不美观、文案提示不清晰等。

（三）.提BUG规范

1. 关联正确的测试版本

2. 关联正确的功能模块

3. Bug描述：

• 明确bug存在哪一个客户端

• 明确bug存在哪一个功能页面

• 描述完整清晰

• 若复现需要测试数据（如：姓名/token/手机号/岗位等），需在描述中标注

• 辅助开发便于理解的图片、备注

4. 若文字描述困难，可多种形式表达（当面描述、制作视频/gif等）

六、测试通过标准

（一）.测试通过的准则

1. 测试用例执行率100%，无不支持测试的测试用例；

2. 测试提交文档：测试计划、测试用例、测试报告；

3. 所有未关闭的Bug数量必须符合以下标准：

• 严重错误：无

• 较严重错误：无

• 一般性错误：小于1%

• 测试建议缺陷：小于5%

以上比例为错误占总测试用例数量的比例。

以上几项其中之一不满足要求，视为不合格，不允许上线发布。

（二）.测试报告

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

测试报告内容：

• 测试结论（测试是否通过/是否满足发布要求/是否能够发布）

• 测试内容（测试范围）

• 测试用例执行情况（一共多少，执行了多少，未执行多少，通过多少，失败多少，多少不支持）

• 有效BUG率（测试版本中，解决方案为已解决的Bug数÷状态为已关闭的Bug数）

• 本测试版本中出现高频次Bug（大于等于2次）

• 发现的严重缺陷有哪些（仅仅罗列严重级别的Bug）

• 遗留Bug（需一一罗列）

测试报告在禅道上提交，以上内容为基本要求，需在禅道测试报告中查漏补缺。

禅道测试报告：

七、C端项目规范

1. 针对学员常用功能，例如考勤相关，订单相关，助学金相关，每次版本迭代均须走一遍测试用例；

2. 针对可预见的并发场景，必须进行压力测试，压测不过关的必须即时反馈至后端进行性能优化；

3. 测试过程不可放过任何一个细节，不论是功能层面还是UI层面；

4. 测试用例必须尽可能的穷举可能出现的业务场景，不遗漏任何可能出现的逻辑漏洞；

5. 测试必须包含主流机型的兼容性测试；

6. 测试时间不够须即时向上反馈，切勿为了保证上线时间放弃测试质量。

八、测试必测点

日常测试工作中，根据测试经验与踩过的坑，总结出一些适合我们团队的必测点。

1. 开发修改完bug后，一定再次主流程测试

2. 兼容性测试

1. app，安卓与ios一起测试（样式、组件是否正常）

2. 移动端h5，安卓与ios一起测试（样式、组件是否正常）

3. 笔记本小屏样式兼容性测试

3. 分页问题

1. 分页查询

2. 分页多选框

3. 分页后切换tab，分页未重置分页

4. 分页只查询了limit10

4. 时间问题

1. 搜索当天，默认时间范围00.00-59.59

2. 定时时间触发/修改状态，时间默认xx日0点

3. 结束时间默认结束日期当天23：59：59

4. 跨日/月/季度/年，边界测试

5. app专项测试

1. 弱网测试（在弱网环境下，会发现一些不友好的处理和显示）

app弱网测试推荐软件：QNET

2. 兼容性测试

使用的手机品牌方提供的远程真机（vivo、oppo、华为），测试系统中学员使用手机型号前10。