软件测试流程及规范_测试规范

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

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

二、测试目的
为了确保软件产品质量，使产品能够顺利交付和通过验收；

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

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

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

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

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

（2）.测试工作流程

1.参与需求原型评审

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

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

结果产出：无

2.制定测试计划

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

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

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

3.设计编写测试用例

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

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

结果产出：初版测试用例

4.用例评审

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

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

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

5.接口测试

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

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

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

6.功能测试

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

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

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

7.测试报告

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

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

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

四、测试用例规范
（1）.测试用例模板

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

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跨站脚本 ”字符串，验证系统行为是否被篡改；

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四种级别：

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

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

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

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

（三）.提BUG规范
关联正确的测试版本

关联正确的功能模块

Bug描述：

明确bug存在哪一个客户端

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

描述完整清晰

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

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

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

六、测试通过标准
（一）.测试通过的准则

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

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

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

严重错误：无

较严重错误：无

一般性错误：小于1%

测试建议缺陷：小于5%

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

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

（二）.测试报告

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

测试报告内容：

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

测试内容（测试范围）

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

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

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

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

遗留Bug（需一一罗列）

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

禅道测试报告：

七、C端项目规范
针对学员常用功能，例如考勤相关，订单相关，助学金相关，每次版本迭代均须走一遍测试用例；

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

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

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

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

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

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

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

兼容性测试

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

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

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

分页问题

分页查询

分页多选框

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

分页只查询了limit10

时间问题

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

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

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

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

app专项测试

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

app弱网测试推荐软件：QNET

兼容性测试

使用的手机品牌方提供的远程真机（vivo、oppo、华为），测试系统中学员使用手机型号前10。
————————————————
版权声明：本文为CSDN博主「酸菜猫的家」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/B15025311845/article/details/128834619