本文主要是介绍设计测试用例的小禁忌，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
设计测试用例就好比程序员编写代码。程序员讲究的是代码是否有很高的可读性、逻辑是否完整无漏洞。测试人员也一样，也需要讲究用例是否有很好的可读性，逻辑是否完整清晰。
禁忌1. 设计的用例逻辑性差
一个模块，若干个测试点需要用几十甚至上百条用例来全面覆盖到。逻辑性差的用例，浏览完这若干条用例后，给人的感觉是想到了什么测试点就写了什么，并不能很快总结出哪些测试点未覆盖到。因为整个浏览的过程你的思维是紧跟着设计者走的，设计者思路不清晰，读者也会没有头绪。而逻辑性强的用例，阅读时你能马上找到设计者是思维过程，条例清晰，知道他在设计用例时思考的顺序是什么。这点不光对评审用例者、阅读用例者帮助很大，对设计用例人员来说，也能更全面的覆盖测试点，减少遗漏点的发生。
禁忌2. 用例标题概括性不足
标题可以说是整条用例的核心。它告诉了阅读者这条用例的测试点是什么，设计目的是什么。甚至熟悉该产品的人，不需要看用例的步骤就知道如何执行这条用例。但是在评审用例时，发现了大量的用例，存在标题概括性不足，甚至标题和步骤中的测试点并不匹配的情况。比如一个用例中包括了测试点A1、A2、A3，但标题中只能体现出A1，甚至B1。
禁忌3.用例设计不合理
这个属于进阶一级的要求了。用例标题准备，思路清晰且覆盖了全部的测试点，这就已经达到了标准。如果你想高要求，让你的用例更完美，就需要考虑如何设计你的用例才更合理，可执行性更高，效率更高。比如功能A，有3个测试点A1、A2、A3，但执行时，想要测试A3，所包含的必经步骤就一定会完成A2。你可以设计3条用例分别对应A1、A2、A3。但更好的方式一定是设计2条用例A1和A2_A3。这样设计，提高了执行用例者的工作效率。尤其是一些太基础的测试点，没必要单独设计成一条用例，如下拉框中有值，下拉框中的值可以被选择这些。
当然如果是自动化测试用例，有可能就另当别论了。因为A2_A3这样的用例，在执行自动化测试时，会造成失败分析相对复杂。你不能直观的判断是A2出错还是A3出错。
**************************个人公众号：测试手账********************************
这篇关于设计测试用例的小禁忌的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
