一、概述
本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准以及测试流程进行总体规范，以有效保证软件产品的质量。
项目软件测试是对软件设计的一种控制手段，是对软件产品质量的一种检查和审核手段，项目测试人员应按本规范要求对软件进行检查、测试。
二、测试目的
为了确保软件产品质量，使产品能够顺利交付和通过验收；
测试是为了发现程序中的错误而执行程序的过程；
好的测试用例是极可能发现迄今为止尚未发现的错误的用例；
成功的测试是发现了至今为止尚未发现的错误的测试。
三、测试流程
无规矩不成方圆，做好项目就是做正确的事情，而正确地处理事情才能更好地提高效率。测试人员在接到一个新的项目或需求版本后，需要按照以下流程逐步开展测试工作，该流程在实际的工作中，可根据实际情况进行补充和完善。
（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跨站脚本 <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四种级别：
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后，一定再次主流程测试
兼容性测试文章来源：https://www.toymoban.com/news/detail-638795.html
app，安卓与ios一起测试（样式、组件是否正常）
移动端h5，安卓与ios一起测试（样式、组件是否正常）
笔记本小屏样式兼容性测试
分页问题
分页查询
分页多选框
分页后切换tab，分页未重置分页
分页只查询了limit10
时间问题
搜索当天，默认时间范围00.00-59.59
定时时间触发/修改状态，时间默认xx日0点
结束时间默认结束日期当天23：59：59
跨日/月/季度/年，边界测试
app专项测试
弱网测试（在弱网环境下，会发现一些不友好的处理和显示）
app弱网测试推荐软件：QNET
兼容性测试
使用的手机品牌方提供的远程真机（vivo、oppo、华为），测试系统中学员使用手机型号前10。文章来源地址https://www.toymoban.com/news/detail-638795.html
到了这里，关于软件测试流程及规范的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
