许多测试新人在工作中面对测试用例时一筹莫展，各种测试用例设计方法学了很多，但编写好测试用例以后，在实施测试时却发现编好的测试用例基本用不上，在测试用例的执行范围之外，需要做很多的操作。这导致测试结果与测试用例中的预期结果差别很大，团队合作项目尤为明显。团队内部的成员各自为战，无沟通、不交流、思路不同，资料无呼应，最终一塌糊涂。

在设计测试用例时，应通盘考虑并对数据加以利用，才能做到事半功倍的效果，也才能让测试用例的作用真正发挥出来，体现出测试工程师的价值。

拿一个常见的数据维护功能“会员管理”来说，此类模块无外乎增删改查四项功能，那么测试用例的思维方式如下：

1. 我们首先要设计“添加”功能的测试数据，从各个角度来满足等价类、边界值等测试用例设计技术的要求，例如用到“张三”和“李四”这两项数据。

2. 随后设计“修改”功能的测试数据，此时应查阅上一步的测试数据，尽可能利用现有的（添加功能）数据来完成当前功能的测试用例。

3. 若现有的（添加功能）数据不够，则在“添加”功能中用例中补上需要的数据，例如添加上“王五”。

4. 以此类推，每一个功能在设计数据时，首先考虑利用现有的数据来设计，例如设计“删除”功能时就可以考虑使用“王五”。

5. 当前设计出的测试数据主要包含贯穿性极高的业务数据，在当前测试数据的基础上为每一个功能添加上功能等测试数据后，即可形成一套完整可实施的测试用例。

总结一下，每一个后续功能在设计测试数据时，都应首先考虑现有数据的使用，这样就保证了测试数据的连贯性和一致性。只有现有数据无法满足使用时，才在数据录入的地方录入所需的新数据。

思维方式的延申。将上述的功能模块扩大为一个系统呢？

在团队合作中，每个人都需要考虑自己所设计的数据对后续任务负责人的可用度，同时也要了解上一个环节的数据详情，并加以利用。这样，整个团队的测试用例即可成为完整的一套，对于业务的测试，尤其是报表、统计图表功能非常有效。

笔者在任职某大型公司测试经理期间，推广这种做法，效果非常的好。测试工程师在实践过一个版本后均非常喜欢这种做法。

声明：该文章仅用于学术交流

感兴趣的小伙伴

扫描下方二维码