做测试一定要知道的——软件测试流程和测试规范标准文档

目录

1、目的

2、工作范围

3、工作职责

4、测试的流程  

5、测试准备阶段

6、测试方法制定阶段

7、测试执行阶段

8、bug管理

9、标准文档

总结感谢每一个认真阅读我文章的人！！！

重点：配套学习资料和视频教学

---

1、目的

通过制定公司测试流程规范，确保测试工作的规范性和有效性，以保证软件产品的质量满足用户的需求。测试作为质量控制的一种有效手段，运行测试用例找出软件中潜在的各种缺陷，通过协助开发人员修正缺陷来提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患和降低质量成本。通过测试管理为产品与过程改进提供可靠的数据分析，起到缺陷预防的作用。 

2、工作范围

测试人员在软件开发过程中的任务： 
1)参与评审需求，评审通过后，编写测试计划；
2)根据根据用户需求相关的产品需求说明文档、原型设计文档、交互视觉设计文档、开发设计文档，编写软件测试用例；
3)在开发人员完成单元测试后，进行集成测试，尽早发现bug；
4)根据软件测试用例，执行功能测试，寻找尽可能多的bug； 
5)对bug进行追踪与分析，保证bug及时得到修复；
6)对软件质量进行衡量，并进行测试总结，提交软件测试报告书

3、工作职责

1）每天对自己的工时进行记录

2）参与需求文档的评审、UI设计文档的评审

3）查看公司网盘中的需求文档、UI设计文档、开发设计文档

4）编写测试有关文档如：测试计划、测试用例、测试报告

5）组织评审测试计划、测试用例

6）根据测试用例执行测试

7）提交BUG、管理bug、bug验收

8）线上测试

                                

4、测试的流程  

4.1：需求文档编写

需求文档由产品经理制定，细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。

4.2：需求文档评审
所有参与项目人员进行，产品经理、开发人员、测试人员、UI设计、运营。开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。

测试人员主要根据需求文档的理解提出疑问，或补充遗漏的条件和场景，以便才能根据需求写用例。

UI人员主要根据需求文档的理解，确定是否要写交互视觉设计文档

4.3：开发人员排期

开发人员对需求的功能点进行排期。然后将计划转交给测试人员

4.4：测试人员排期

测试人员根据开发计划，对测试拟定具体测试时间，也就是开发功能完成后的时间，执行测试所需要的时间。然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。

4.5：编写测试用例

仔细阅读需求文档，归纳出需求文档的功能点、测试点。思考编写测试用例的方法，列出有效等价列、无效等价列，分析场景、边界值。开始进行测试用例的编写

4.6：测试用例的评审

在用例进行评审之前，先将用例发送给产品经理与开发人员，以便他们事先了解测试用例。

然后进行用例评审，开发人员与产品经理对测试用例中遗漏的测试点、场景进行补充。

如果测试用例不通过，测试人员增加遗漏的功能点和场景后，组织第二次用例评审，直到用例评审通过为止

4.7：执行测试

测试人员按测试用例进行第一轮测试，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复。然后进行第二轮测试，第二轮会对第一轮中发现的问题的模块进行重点测试。

4.8：测试通过

经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。

                              

 

5、测试准备阶段

5.1测试计划
根据评审通过的需求文档和项目计划制定测试计划。测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、工作规范等。测试计划在策略和方法方面说明如何计划、组织和管理测试项目。测试计划完成后应该在项目组内进行评审。

5.2测试用例
测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。解决要测什么、怎么测和如何衡量的问题。

依据用户需求分析说明书、概要设计文档和开发详细设计说明书来设计测试用例，发现需求与设计中的问题后，与需求者及时沟通确认。
5.3：测试用例设计方法

1. 等价类划分法
2. 边界值法
3. 错误推断法
4. 因果图法
5. 场景法

5.4：测试用例操作步骤 
1)在设计编写测试用例时，首先要从测试用例库中选择相应功能的测试用例，在原有测试用例的基础上依据系统需求文档对测试用例的进行修改、更新，评审通过后将使用该测试用例测试被测系统。 
2)在测试的执行过程中和进行回归测试后，对已设计的测试用例进行维护更新。

5.5：配置测试的环境

1. APP测试

操作系统：Windows（7、8、10）、macOS 10.9以上、Android 4.0以上、iOS 9.0以上

Windows配置虚拟机，在各个虚拟机上装配不同的国外用户常用的杀毒软件

1. Web网页测试
   浏览器：Chrome、Firefox、Opera、Safari、Edge、IE

6、测试方法制定阶段

6.1兼容性测试 --测试人员
兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，如在win10环境下可以运行，在win7环境下是否也可以正常运行。

6.2用户界面测试-UI测试  --测试人员
用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

6.3：随机测试

随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例 没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些bug所在的模块进行测试。可以结合回归测试一起进行

6.4：功能测试

  软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。

如：登录功能测试,主要输入正确的账号和密码或错误的账号密码验证是否能登录成功

7、测试执行阶段

7.1测试准入的条件

1. 不接受无详细需求文档和开发说明的项目；
   2)需要测试的项目至少提前2个工作日提交测试进行需求分析 ；
   3)开发人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是可以正常使用。 

7.2版本测试功能迭代测试

功能测试

1. 在测试用例库中导入和版本有关的全部测试用例
2. 按软件的功能顺序分布依次测试
3. 注册模块：验证注册的邮箱或号码是否有效、验证码是否有效、验证码是能正常获取、密码是否按需求限制、使用条款是否勾选、注册成功后是否能正常登录
4. 登录模块：账号密码不正确是否能登录、密码能否显示、是否能记住密码
5. 忘记密码模块：验证码能否正常收发、密码是否按需求限制、修改过后新密码能否正常登录
6. 首页模块：各个列表的服务器信息是否能正常显示、收藏功能是否正常、线路在各种网络环境下是否可以连接、服务器连接之后是否起到作用、服务器连接断开是否正常、线路收索功能是否能正常搜索、协议切换是否正常、协议作用是否发挥出来
7. 购买模块：套餐是否可以正常购买、付费用户是否可以购买别的套餐、退款用户能否直接购买、支付页面是否可以正常的跳转
8. 用户信息模块：手机号码&邮箱号码是否可以正常绑定或更换、是否可以绑定或更换成无效的手机号码&邮箱、密码更换是否按需求限制弹出
9. 其他模块：页面显示是否清晰、链接跳转是否正常、消息弹窗是否能正常
10. 版本迭代新增模块：按需求文档以及更新的测试用例测试进行重点测试

兼容性测试：Windows（7、8、10）、macOS 10.9以上、Android 4.0以上、iOS 9.0以上等设备进行安装，进行随机测试

Win操作系统下安装是否被杀毒软件警告测试：

在另一台设备或者虚拟机上安装国外的杀毒软件如：

美国：Symantec（赛门铁克）、McAfee（麦克菲）、Fortinet（飞塔）、Windows Live OneCare（微软）
日本：PC-cillin（趋势）
韩国：Ahnlab（安博士）、Virus Chaser（驱逐舰）
英国：Sophos（牛津）、Prevx1
芬兰：F-Secure
德国：Antivir（小红伞）
西班牙：Panda（熊猫）
印度：Rudra

然后进行安装使用测试，观察是否会被查杀

7.3：web网站测试：测试首页与各个页面的链接是否可以正常跳转、

链接跳转位置是否正确、页面是否正常、在各种浏览器（如：Chrome、Firefox、Opera、Safari、Edge、IE）上显示是否正常、在不同分辨率下显示是否正常

                  

8、bug管理

BUG状态

●未打开 

1)新创建的bug； 

2)已解决但未验证的bug；

●打开 

正在讨论的bug

●已确认 

通过讨论已确认的bug

●修复中

开发打开bug，正在修复

●挂起 
开发打开等待修复
●待测试
等待测试人员进行验收测试
●已解决 
测试人员验收测试结束后，没有问题 
●重新打开 
测试人员验收测试后，发现并未修复重新打开给开发 
●已完成

测试人员验收后没有问题，开发人员将状态改成已完成

BUG优先级

●高
阻止与此密切相关功能的进一步测试，需要立即修复。

如：验证码收不到
●中 
必须修改，不一定马上修改，必须修改，发版前必须修正。

如：密码位数没有限制
●低 
对系统的影响较小，如果时间允许应该修改。

如：文字错误

BUG严重等级

●严重（一类）

不能执行正常工作功能或重要功能，因软件原因导致系统死机等，须马上修正致命错误。

通常有如下情况：

1)系统停机（含软件、硬件）或非法退出，且无法通过重启恢复；

2)系统死循环；

3)与数据库连接错误；

4)数据库发生死锁或程序原因导致数据库断连；

5)数据通讯错误或接口不通；

6)重要功能无法正常使用、功能不符合用户需求。

●一般（二类）

影响系统功能或操作，应用模块错误使业务中止无法进行后续操作，主要功能存在严重缺陷，影响到产品的使用，但不会影响到系统稳定性。

具体基本上可分为：

1)业务流程错误或不完整；

2)业务数据来源不正确、业务数据紊乱或丢失；

3)业务数据保存不完整或无法保存到数据库；

4)部分功能使用存在问题，不影响业务继续开展，但造成使用障碍；

5)初始化未满足客户要求或初始化错误；

6)功能点能实现，但结果错误；

7)缺少数据有效性检查或检查不合理；

8)删除操作不给提示；

9)日志记录信息不正确或应记录而未记录；

10)数据库的表、业务规则、缺省值未加完整性等约束条件；

11)在产品声明支持的不同平台下，出现部分一般交易无法使用或错误；

12)系统某些查询、打印等实时性要求不高的辅助功能无法正常使用。

●轻微（三类)

使操作者不合理或者不方便或操作遇到麻烦，但它不影响执行工作功能或重要功能，次要功能，对产品使用影响不大。例如：程序在一些显示上不美观，不符合用户习惯，或是一些文字的错误。 

具体基本上可分为：

1)缺少产品使用、帮助文档、系统安装或配置方面需要信息；

2)联机帮助、脱机手册与实际系统不匹配；

3)系统版本说明不正确；

4)提示说明未采用行业规范语言；

5)显示格式不规范；

6)界面不整齐；

7)软件界面、菜单位置、工具条位置、相应提示不美观，但不影响使用；

8)辅助说明描述不清楚；

9)提示窗口描述清楚；

10)输入输出不规范;

11)可输入区域和只读区域没有明显的区分标志。

BUG书写规范

测试人员BUG提交 

1)主题

●用一个简短的句子描述问题，不要写成一大段

●描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦

●不要夸大或缩小问题的严重程度

2)步骤 

●用数字编号，一步步的描述重现问题的所有操作步骤

●尽量用动词作为开头，描述每个步骤。如：打开、点击、设置、选择、插入、双击等

●提供bug产生的每个步骤的截图 

9、标准文档

《测试计划》

《测试用例》

《测试报告》

总结
感谢每一个认真阅读我文章的人！！！

如果下面这些资料用得到的话可以直接拿走：

1、自学开发或者测试必备的完整项目源码与环境

2、测试工作中所有模板（测试计划、测试用例、测试报告等）

3、软件测试经典面试题

4、Python/Java自动化测试实战.pdf

5、Jmeter/postman接口测试全套视频获取

6、Python学习路线图

                                

重点：配套学习资料和视频教学

那么在这里我也精心准备了上述大纲的详细资料包含：电子书，简历模块，各种工作模板，面试宝典，自学项目等。如下，需要的点击下方名片加我VX免费领取。