如何做测试用例评审

测试案例是贯穿了整个测试流程和项目研发流程的，因此用例显得至关重要。如何提高用例的质量，用例评审是必不可缺的一环。

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

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

测试案例的四要素分别是：测试环境、测试目的、测试步骤、测试结果。这四要素缺一不可。另外还有案例分级、案例类型。

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

因此评审的内容也基本上和测试案例的几大要素息息相关，但是案例评审的第一步应该是设计框架的评审。

设计框架

案例的整体框架，也就是案例的结构和模块划分。一般我们都是以xmind来提前定结构，这样评审时更容易直观的看到结构树和层级关系。

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

扫描二维码关注公众号，回复： 3011605 查看本文章

1、模块划分合理性：大类、子类，并行关系、归属关系要区分，不能在同一层级展现。
2、子属关系正确性：比如正常来说一个登录的方式，从归属关系上看大致是这样：账户体系》登录》指纹登录，如果将指纹登录归到注册层级下面，那自然是不合理到。

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

（关于如果针对开发原理，来完善案例设计可以参考这一篇文章，举的例子很典型：https://blog.csdn.net/alice_tl/article/details/79601697）

4、类型覆盖全面性：前端、后端、UI、功能、性能、兼容、接口等。

测试目的

1、测试目的的唯一性

一条案例应该都唯一一个测试目的，比如不能在测试字符类型是否合法的同时，再测试字符长度是否符合标准。原因很简单，因为如果有多条测试目的，那么一条通过，一条不通过时，你是打Pass合适，还是打Fail合适呢？并且容易干扰测试结论，以及不方便评估回归测试工作量。

2、测试目的的明确性

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

可以一目了然的看到我想测试的点是什么。

3、测试目的的简洁性

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

对比之下，孰好孰坏，显而易见。

小编一直不建议在测试目的中体现测试结果，因为这样就和预期结果的内容重复了，并且结果的描述通常文字较多，会导致测试目的非常长。不过不同项目的实施情况不一样，见仁见智了。

案例详情

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

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

3、案例分级：P0-P4，需要满足要求10%，25%，30%，25%，每一分级的案例占比偏差不能大于5%。

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

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

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

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

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

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

结合到评审流程和参与的人来看，我的理解是这样，欢迎拍砖。

评审流程：

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

测试目的、案例详情评审：一般来说要求项目组全部参与，确认细节规则和测试结果的准确性。