标签：manager   了解   兼容性   避免   开始   职责   tps   blank   测试风险   

工作以来，大大小小参与的项目也有十几个了，涵盖财务类、保险类、OA办公类软件。

从测试流程上看，基本也都大同小异，这里将常见的测试流程做一些梳理，

供刚入行的朋友学习参考，也欢迎大家完善补充。

一、需求答疑评审

参与人员：

产品、开发、测试、需求提出人、其它相关人员

主要内容：

对需求文档进行评审，对于有疑问或者有错误的地方，进行讨论沟通，来保证对需求理解的准确性和一致性。

需求文档中最好有业务流程图，能够较好的帮助相关人员快速的了解业务需求。

目标达成：

通过此次会议了解到各模块对应开发人员，以此来确定测试时间

二、罗列测试点

主要内容：

需求评审通过后，测试根据定版的需求或UE构造测试脑图。

通过脑图列出测试点以及测试方法，然后再根据脑图整理测试方案。

脑图工具：

Xmind、MindManager等

测试方案包含：

测试环境，测试数据，测试模块，测试点，测试方法，测试风险等

目标达成：

这个环节，输出测试点和测试方案，指导接下来的测试工作。

强烈建议：

测试任务紧急来不及写用例的情况下，一定要列测试点并进行Review。
避免无序测试，思路混乱，丢三拉四。

三、制定测试计划

主要内容：

根据开发计划制定测试计划

测试计划包含：

测试范围、测试目标、测试出入口、通过标准、测试人力安排（角色及职责）、测试进度安排

（用例设计评审开始结束时间、用例执行开始及结束时间、回归测试时间计划、测试交付时间等）、测试交付物、测试风险。

目标达成：

输出测试计划

四、用例编写、评审

主要内容：

测试工作最重要的环节就是设计产出测试用例，一定要严谨专业。
用例的可读性要强，不仅仅是写给自己看的，要做到任何人拿起来都可以执行。
用例设计完以后，要开展用例评审，查漏补缺，不断完善用例；也可以采取用例结对编写的方式，提高用例设计质量。

测试用例组成：

编写人、用例编号、用例名称、前提条件、测试数据、优先级、操作步骤、预期结果、实际结果、测试人等

用例设计思路：

UI测试、权限测试、功能测试、数据测试、流程测试（包括正常流程与异常流程）、接口测试、兼容性测试、性能测试、安全测试等

设计方法应用：

一般边界值和等价类常用，其次场景法、因果图、错误推测。
针对不同的需求，测试点的选择或侧重点可能不一样。

目标达成：

通过用例设计、评审，输出较为完备的测试用例。

五、冒烟测试

开发提测后，正式测试前，先验证一下主流程或主要实现功能是否存在问题。

没有问题后再进行系统的测试，避免测试相关工作已经准备开展，而核心业务却执行不下去的情况。

六、执行测试用例

冒烟测试结束后，按照测试计划开展测试。

这个阶段也可采取交叉测试的方法，即：A写的用例B执行，B写的用例C执行。

过程中如遇到不可控因素或问题，影响到测试计划落地的，一定要尽早报备。

七、编写测试日报

主要内容：

根据测试需求的具体情况，发布测试日报（一般邮件形式较多，也有在看板或需求平台上备注的）。

测试日报包含：

用例总数、执行用例数、未通过数、发现BUG的数量、关闭BUG的数量、遗留BUG的数量、问题等级、影响程度、BUG趋势以及其它建议等。

收悉人员：

相关产品、开发、测试或需求人员。

八、测试报告总结

在整个需求或版本测试完成后的总结。

主要反应测试过程中的问题以及对应版本的质量情况，是否满足发布标准、遗留的问题的情况、是否影响相关使用、特殊的注意事项等。

之前写过一篇如何进行版本总结的文章，可以参考【如何编写测试总结】

【经验分享】常见软件测试流程

标签：manager   了解   兼容性   避免   开始   职责   tps   blank   测试风险   

原文地址：https://www.cnblogs.com/panda-sweets/p/12984546.html