现在我们来一起回想下，在写测试用例的时候是否有这些困扰：
- 测试用例写了很多条，感觉有冗余，要精简又无从下手；
- 测试用例写了很多条，但是总感觉还少了点啥；
如果你不能同意更多，就请继续看看我们是怎么解决这两个问题的。
一、用例条数过多
很久之前，我有专门制定过测试用例改进计划，两步走策略。
第一步，保证全面性，能考虑到的测试点都进行罗列，尽量全的罗列，保证没有遗漏。
第二步，在全面性有保障的前提下，适当进行用例的删减，保证用例的针对性。
但是随着计划的推进，我们就一直在处在第一步的边缘，迟迟无法跨越到第二步。
主要原因有两个：
一个是和开发人员的持续信任感没有建立，特别是测试过程中如果发现一些提测说明中没有提到的修改点的问题时，这种不信任感尤其强烈，既然是这样的现状，就说明我们用作测试用例编写范围判断的依据已经不可靠，当然就没法确定说哪些用例是可以删减的了。
另一个是作为测试的责任心使然，宁可自己多跑一些场景，多做一些回归，也绝不让问题漏出，那么每删除一条用例，在不确定修改内容的情况下，就增加了漏出问题的确定性，大家当然就很忐忑了。
但是一直这样持续，终究不是办法，有问题还是需要解决的。
现在我们的解决方案是从自动化着手，不敢精简用例的核心原因是怕漏掉测试点，那么我们就借助自动化来保证回归范围的覆盖，手工去保证本次明确修改范围的覆盖，在不减少覆盖率的情况下，去解决因为测试用例过多而造成的人力损耗。
至于自动化为什么没有早就完成覆盖，主要是实现过程中碰到了各种各样的问题，这是另一个比较大的话题了，以后详聊。
二、针对性用例偏少
上一个问题说的用例条数过多，主要指的是在全面性有保障的情况下的过多，目前很多人在全面性的保证上都还存在问题，所以更不敢贸然的推进用例精简了。
所以这里说的针对性用例偏少，区分了如下两种情况：
一个是用例全面性本来就不够，特别是一些明确提测修改影响范围的点的用例覆盖率不够，而这里面绝大部分是异常场景的覆盖度欠缺，还有一部分是没有区分哪些是测试重点，一味在自己熟悉的逻辑上增加用例，而忽略了自己不熟悉但是应该是重点的逻辑覆盖，关注点的偏差就体现为测试点的偏差。
另一个是全面性足够的情况下，没有针对性的做深度挖掘的测试，比如新增一个通用接口，我们就找个调用方去做下联调测试，没有针对接口做接口逻辑层的测试，比如新调用了一个系统 API，我们只停留在知道这个 API 名称的程度，没有去考虑这个 API 的特性，和针对性的测试点等等。
目前用例评审过程中，对于全面性的关注偏多，对于针对性的关注偏少。
为了解决关注点偏差的问题，我们建议编写测试用例的同学，从需求和逻辑实现本身出发去考虑用例设计，暂时搁置用例执行的问题，只需要考虑我们的测试目的，测试点是测试目的的显式表述。
为了解决深入度不够的问题，我们强调分层测试的概念，所有涉及逻辑实现的地方，都引导大家考虑逻辑层和数据层的测试点，进一步做深度挖掘。
目前来看，这两方面都还略有成效，但这个不像自动化是一个显式可见的效果，这个需要测试人员的能力到了一定的程度才能更好的发挥效用，所以目前处理第一个问题的优先级最高。
以上，通过自己的测试实践和对外界的部分观察，针对测试用例设计过程中发现的两个问题进行了简单的复盘，不知道你在实际项目中是否碰到了类似的问题，欢迎留言说说你是怎么解决的。
源自公众号 sylan215