测试评审初试

测试案例是贯穿了整个测试流程和项目研发流程的，用例也同时起着指导测试、保证质量度作用，因此用例至关重要。对于如何提高用例设计的质量，评审是必不可缺的一环。

很多测试同学都知道应该做测试案例评审，并且也乐意做需求评审，但是很少有测试同学总结过如何做案例评审。那么最基本的案例评审应该从哪些方面着手呢？

 

在开始之前，再回顾一下测试案例的几个要素。

测试案例的几个要素分别是：测试环境、测试数据、测试目的、测试步骤、测试结果。这些要素缺一不可。另外还有案例分级、案例类型（UI、功能、兼容等）、案例执行的阶段（比如准入阶段、集成阶段等）。

不同的公司的案例模版会稍有差别，有的公司还会将案例跟自动化覆盖程度结合，每一条案例对应的自动化覆盖情况，以及自动化类型是基于代码层的，还是接口层的，以及UI层的等等。这样更容易评估公司的自动化覆盖率。

评审的内容也基本上和测试案例的几大要素相关，但是不管是什么样的案例模板，案例评审的第一步都应该是设计框架的评审。

 

设计框架
案例的整体设计框架，也就是案例的结构和模块划分。一般我们都是以xmind来提前定结构，这样评审时更容易直观的看到结构树和层级关系。如果一个案例管理平台缺少可视化的结构树，那么基本上可读性是非常差合效率极低的。

设计框架可以从哪几个维度看？

1、模块划分合理性：即能包含所要测试的全部对象，又能够不重复。
2、逻辑链路流畅性：一个业务流程是顺畅的，没有阻断的。

3、子属关系正确性：主类、子类，并行关系、从属关系要区分，不能在同一层级展现。

4、需求覆盖完整性：显性需求应该100%包含，隐形需求也应该能够挖掘出来。开发实现涉及到的每个环节也需要考虑容易出错的点。总之，不能只局限于表面交互看到的东西。简单来说，就是DB层、代码层、接口层和UI层，前后端均要覆盖。

5、类型覆盖全面性：前端、后端、UI、功能、性能、兼容、埋点、接口、数据库等。

拿一个简单的例子来讲：通常的登录功能，包含账户密码、手势、人脸三种方式。

模块划分：主类是登录，三种登录方式应该是互相并行的，并且归属于登录模块。

逻辑链路：对于任意一种登录方式，一定要包含输入、校验、结果整个完整的业务流程。

子属关系：如果将手势登录归到注册层级下面，明显是不合理的。

 

测试目的
1、唯一性

一条案例应该有唯一一个测试目的。

比如不能在测试字符类型是否合法的同时，再测试字符长度是否符合标准。原因很简单，因为如果有多条测试目的，那么一条通过，一条不通过时，你是打Pass合适，还是打Fail合适呢？如果打了fail，又怎么根据案例数来评估回归测试工作量呢。

2、明确性

比如希望测试一个播放次数的功能，为零次是则不显示播放次数，每一次播放后播放的次数会有增加，未播放完就结束时，次数仍然不变。则可以写成：

播放_次数测试_为零时显示
播放_次数测试_播放完成时变化
播放_次数测试_播放未完成时变化
播放_次数测试_刷新页面
一目了然的看到我想测试的点是什么。

3、简洁性

比如继续拿上个例子来讲，有的小伙伴会将测试目的写成：

测试播放功能_看播放次数为零时次数的显示_不显示播放次数
测试播放功能_看播放完成时播放的次数是否有增加_播放次数增加
测试播放功能_看播放未完成时播放的次数是否有增加_播放次数不增加
测试播放功能_看页面刷新时播放的次数是否有增加_播放次数不增加
对比之下，孰好孰坏，显而易见。

另外，小编一直不建议在测试目的中体现详细的测试结果，因为这样就和预期结果列的内容重复，并且测试目的非常长。不过不同项目的实施情况不一样，这点大家就见仁见智了。

 

案例详情
1、测试环境：是充分必要的环境条件。

2、操作步骤：步骤需要具备连贯性、可执行性。

3、案例分级：P0-P4，一般来说，P0、P1、P2、P3案例的占比分别为15%，35%，40%，10%，每一分级的案例占比偏差不能大于5%。

新项目而言，P0为流程案例，P1为基本功能案例，P2深入逻辑规则测试的案例，P3为极限值、异常特殊场景案例。

4、预期结果：保证明确性、准确性，以及和需求一致性。

5、操作步骤：一般应该是3步左右，绝对不能超出5步。操作步骤超出3步时，就应当要思考案例是否有多个测试目的和多个对应的预期结果，已经不符合案例设计规范。

6、案例顺序：应该将优先级高重要模块的案例放到前面，异常和分级低的案例放到后面。优先级越高的案例，执行的顺序应该越优先。这样一方面可以快速暴露问题，二是减少后期测试的压力。优先级通常是核心功能>次要功能，正向案例>逆向案例，常规场景>异常场景。

另外要注意语言的简洁：简洁的语言即能让评审的听众快速读懂案例，也能够提高执行案例的效率。

对于详细内容的审核，很多初学小伙伴容易混淆测试环境和操作步骤，这一点我是如何理解的呢？

假设用户上传一个照片到相册中，需要测试上传的功能本身，还需要考虑对不同网络的兼容，还需要测试到不同网络的性能。

那么除了针对网络兼容测试的case，网络的类型和设定是作为操作步骤以外，其他的非专门测试网络的case中应该将网络连通性作为测试环境而非作为操作步骤。试想如果每一条案例里都将网络连通性作为第一个测试步骤，冗余量是得有多大，并且稍微有常识的用户都知道，我要上传成功，我的前提是网络连通。

 

【示例】

下方是项目中之前进行案例设计时做到一个小练习。

较好

较差

较差一版脑图存在的问题：

 

评审流程
结合到评审流程和参与的人来看。

 

设计框架评审：一般来说要求测试全组参与、项目组全部参与，一方面能够快速看到设计者的测试思路，另一方面避免出现大的设计遗漏。

测试目的、案例详情评审：一般来说要求项目组全部参与，确认细节规则和测试结果的准确性。
————————————————
版权声明：本文为CSDN博主「alice_tl」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/alice_tl/article/details/80218379