测试用例评审：开拓、产品、测试人员都覆盖了哪些内容？

为了肃清误解，让开发理解到底测试都覆盖了哪些内容，双方更好的合营，保障线上版实质量，测试用例的评审就显得十分主要。

测试用例评审的参与职员是：开拓、产品、测试职员。

产品职员参与，可以方便核对测试用例是否覆盖产品需求，在评审的过程中完善产品解释文档，完善产品的逻辑。

开拓职员参与用例评审，可以从代码实现角度给出建议，防止漏测或过度测试，担保测试的全面性，减少无效测试，增加重点模块的测试。

测试职员参与用例评审，可以审查用例是否规范，对付交互模块的用例覆盖的是否完好。

评审前的准备

预审时须要供应xmind思维导图文件，xmind思维导图须要包含全部用例的设计思路及测试功能点，并重点标注出有疑问的测试点。

在评审前一天提前发出给干系与会人，预留韶光给研发和产品先过下用例的内容，留神会议侧重点。

评审中的哀求

对付敏捷开拓项目，会议韶光一样平常建议掌握在半小时以内，超过这个韶光就须要中场安歇了，由于人持续集中把稳力的韶光基本只有二十分钟。
为了保障评审效果，须要采纳一些有效策略。

测试用例评审利用xmind软件，这样评审时更随意马虎直不雅观的看到构造树和层级关系，方便参评职员一览无余，更快的搞懂设计者要表达的意思。

繁芜的功能在开始前先概述下文档构成，然后按照文件顺序讲解。

牢记不可一马平川读到底，该当重点抓用例设计时存疑的地方，然后三方确认，这个时候预审是标注的有迷惑的地方就派上用场了。

简言之，对功能点划分优先级，优先评审优先级高的用例，再针对疑问多的用例评审，末了对付功能大略的用例可大略带过。

时候记住我们用例的评审目标，不能流于形式。
对付评审过程中，一时半会没有结论的问题，可以记录下来，作为会后谈论跟进的重点。

功能举例如下：在商品详情页，进行中的拼团列表，点击“去拼团”会进入拼团详情页。

原始版的用例如下图：

评审内容如下：该用例考虑的点过于狭隘，基本等同于抄需求文档的。

实际上还应考虑一些瞬时场景和一些非常情形：比如点开页面后团购结束，点击页面时小程序账号还未登录等。

其余，由于测试用例评审和开拓代码设计是同步进行的，以是在评审过程中，轻微繁芜的没有把握的功能可以与开拓确认实现办法。

比如，哪些数据是从接口获取的，哪些数据是从其他页面的接口要求带过来的，哪些是前端写去世的，哪些页面有必要实时刷新，哪些页面无需已进入就刷新。

通过磋商，明确可能的bug重灾区，设计一些合理的处理办法，从根源上遏制bug的涌现。

评审后的扫尾

用例评审完成之后，须要及时整理会上的评审见地，形成会议纪要并发送邮件。

同时测试职员须要根据会议上各方建议进行测试用例的修正完善，再将整理补充后的用例同步给项目干系职员，试详细情形确定是否有必要进行二轮评审。

若无其他问题则将用例整理后即可定稿等待实行。
该用例经由评审的群策群力之后，补充如下：

评审的流程

末了：

1）关注+私信回答：“测试”，可以免费领取一份10G软件测试工程师口试宝典文档资料。
以及相对应的视频学习教程免费分享！
，个中包括了有根本知识、Linux必备、Mysql数据库、抓包工具、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高等持续集成、测试架构开拓测试框架、性能测试等。

2）关注+私信回答："入群" 就可以约请你进入软件测试群学习互换~~