测试用例的设计

关注

原创最新推荐文章于 2024-09-13 16:38:32 发布 2.2k 阅读 AI 写同款· GEO 优化 ›

【测试用例】测试用例设计的关键点总结 测试用例设计的关键点 测试用例设计是每位软件测试工程师必须的基本技能之一。无论是靠测试经验，还是靠理论，在时间充足的情况下，最好一一设计测试点，避免在执行测试时部分测试点被遗漏；在时间紧急的情况下，也应以思维导图的方式列出测试点。 1 测试用例基本概念 测试用例，即执行测试之前编写的指导测试过程的文档，主要包括：用例编号、测试目的、用例描述、预期结果。其编写原则：准确性、层次性、简洁性、可重用性... 阅读详情

测试用例这种东西对于刚入行的人来说是一种诱惑，初入测试的人急于掌握这门学问，所以一开始就会问测试用例怎么写，问的同时或许还包含了一些期望。其实测试用例就是一个测试矩阵，任何人没有必要注重形式问题，如果你现在或者未来的公司有套非常完善的文档管理体系，那么你可以参考标准模版，如果没有你们大可跟我一样使用下面的格式：

---------------------------------------------------------------
- ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE
---------------------------------------------------------------

我认为没有什么问题，ID代表用例标号。ACT代表一种动作，因为测试动作非常复杂，如果手动执行或者自动执行，或者是一种异常状态都可以占用此位置。DATA代表数据，很多的测试类书籍中虽然没有直接讲明测试数据的划分，但是通常我们引用三种数据“正常”、“异常”、“错误”，分别对应关键字“PASS”、“ERROR”、“FAIL”，对于数据的划分我不细说了。为什么会在一个文档中体现这些内容——主要是为了以后的测试自动化，一个不能将手动测试转为自动测试的人员注定是平庸的。EXPECTED、ACTUAL分别代表期望和实际，我们做这一行的经常对这两种值的差异感到困惑，是不是“正常”、“异常”、“错误”就看个人的经验了。T/F的引入是因为有这样的一种情况介入，如果EXPECTED、ACTUAL是不同的，但是我们还是要给个T，因为对于单项的是否通过测试人员有着使用权，但决定权在于市场或者高层决策。DATE是一种好习惯，通常记为发现“PASS”、“ERROR”、“FAIL”的时间，很多人会忽略这个值，当然对于我们来说没什么损失，对于QA团队来说，仅仅提供给他们T/F是不够的。
》qiuyangzh：不过在我看来，还是要把ACTUAL-T/F-DATE部分抽取出来，因为这部分不能算是测试用例的内容，而是在后面实际执行测试的时候填写的。当然，可以使用同一个格式，在编写测试用例的时候，ACTUAL-T/F-DATE部分的内容空着，在每次执行这些用例的时候，将实际情况填写进去，当然，测试用例和每次的测试执行要写在不同的文档里。

我觉得这就是一种构造朴实的测试用例的方式，不要过于在意一份文档的表现形式，如果你有很多的时间，如果你一年才写一次测试用例，你当然可以从互联网上下载很多的资源把文档修饰的像APPLE的产品一样。
》qiuyangzh：测试用例要简洁、有效，这一点我非常同意。也许你和我一样，也曾经看到过那些格式复杂的测试用例，不能说它们不好，但不一定适合组织的情况。我认为在很多情况下，应该保持测试用例简洁和朴实的风格。简洁不等于简单，真正简洁、朴实的测试用例，仍然是非常有效和实际的。
不过上面的测试用例格式有些过于单薄，比如测试用例的设计者和对应的测试需求，还是需要写上的。而且我的看法一直是：应该将测试用例和测试用例执行的记录分开，不要混在同一个部分，这样便于工作的进行。

入行的人员会更进一步的发挥测试偏执狂的能力，这时候的他们急需一种数量，例如：我们一个动态库的测试用例就有3000多个，厉害吧？厉害，我当然说你厉害，你难道不厉害吗？我记得有个500强的面试题就是你能为登录的动作写多少测试用例？我想了半天说就三个，或者四个，在听到了一声深深叹息后，我惶恐的说大概我能写5个吧？当然我自己也没底，我就能写出三个：LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的测试用例就是他们的衍生，一种本源的问题。我们继续讨论3000多个测试用例的事情，有人明眼就会说：这家伙肯定是微软的，没错，除了这种大公司有了充足的资源和技术支持，哪家公司能跟他们一样呢？当然了，写3000个我想入行久了谁都可以，并且跟你对系统的熟悉程度，工作经验有莫大的关系，但是这里我又想说说关于构造朴实的测试用例的问题了。
当你开始测试的时候，实际上最终是对代码设定路径的一种验算，如果我们都生活在单线程、无UI的年代你可以更清楚的看到“PASS”、“ERROR”、“FAIL”三种状态，可我们已经错过了这个年代，我们有了包装的UI，有了封装的API，有了各种各样的MESSAGE，所以你就要承受更多ERROR的打击。这个时候有人就会通过增加测试用例的数量来回避这些陷阱，出发点是好的做法是累死人的，如果你愿意你可以为机器码写1亿个测试用例，如果你还是很偏执，你可以为门电路写上1万亿个测试用例，你有时间执行吗？
》qiuyangzh：如果资源充分，当然测试用例的数量多一些对于检验产品的质量是有好处的。但实际情况往往是资源有限的，这种情况下，就必须挑选出那些最有价值的测试来执行。

我通常不愿意写太多的测试用例，很多人认为我工作态度有问题，我认为这更能说明我的态度：我愿意朴实的构造我的测试用例，但是我有原则来保证我的测试用例的质量：
   1。接到任务不急于作而在于多思考，首先在纸上构造好业务流图
   2。业务流程图构造好，快速挑选出公用的测试用例
3。构造测试用例，先写符合主路径的三种“PASS”、“ERROR”、“FAIL”
   4。精化测试用例，努力为ERROR多构造1-7种假设
   5。执行测试用例，增加FAIL的标准化失败的测试，但是对应减少PASS测试用例
   6。进一步精化测试用例，使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10
》qiuyangzh：就是因为上面这段话，更确切的说是第4、5、6条，使我决定把这篇文章放到我的Blog中来。根据我的经验，在设计和执行测试的时候，应该按照这种比例来操作。

我将继续我的朴实理论，多出来的时间，我可以看看蓝天，享受享受生活！