但是，仍然有不少的测试团队和测试人员认为没有必要编写和设计测试用例，尤其是当敏捷开始盛行后，很多人更是认为编写和设计测试用例是浪费时间。
为什么要写测试用例？
测试用例的创建至少会有两个用途或目的：
（1）如果顾客有要求的话，测试用例会是交付给顾客的产品中的一部分。测试用例在这里充当了提高可信度的作用。
（2）测试用例只作为内部使用。在这里测试效率是目的。在代码尚未完成时，我们基于设计编写测试用例，以便一旦代码准备好了，我们就可以很快地测试产品。
但是随着敏捷的盛行，第二点逐渐受到很多人的置疑。“预先设计好的测试用例对指导测试执行有多大的作用呢？而且我们采用的是探索性测试方法，不写测试用例也能做测试。”
没错，预先写好的测试用例很可能要在测试执行的过程中不断地修改，尤其是在那些需求不明朗的项目中。但是预先的设计就好比提前的探索，除了能学习到软件涉及的业务知识外，还能对即将出现的软件进行一次测试的“演练”，在这个“演练”的过程中，往往能发现需求分析和设计的很多缺陷，将可能由此引致的BUG“扼杀”在萌芽期。
探索性测试虽然很少写正式的测试用例，但是并不意味着没有对测试进行设计。只是测试的设计是在探索过程中、测试过程中进行的，测试的设计与测试的执行同步进行。并且根据Jams Bach介绍的基于Session的探索性测试管理的方法，是要写测试用例的，只不过不被称为测试用例，而是被称为“探索任务”。
基于Session的测试管理把测试过程划分成多个Session，或者叫“探索任务”，每个Session都是目的驱动的，每个Session由一名测试员负责执行，在一个Session结束后，测试员提交一份session报告，附上关于测试过程的重要信息。
“探索任务”可包括如图1所示的任务矩阵中列出的方面。
图1 探索性测试任务
由此可见，探索性测试也有测试的设计，也有测试用例，只是相比起传统意义的测试用例编写而言，其测试用例更偏向于“设计”，并且其设计是与测试执行和探索行为同步进行的。
测试永远也无法保证发现所有的错误。测试用例的“设计”如此重要正是因为完整的测试是不可能的，任何项目的测试都是不完整的，因此，很显然我们需要通过设计测试用例，让测试尽可能的完善。在有限的时间和资源下，测试的关键问题是：哪些测试用例是最有可能发现最多错误的呢？
图2 某个程序的结构流程图
某个程序的结构流程图如图所示，这样一个少于100行Pascal代码的程序，却有100,000,000,000,000种可能的路径需要遍历，如果尝试遍历所有可能的路径，假设每秒钟执行1000个测试用例，也需要3170年的时间来完成所有测试。
详尽地遍历所有测试的可能路径、场景、输入条件和数据是不可能的，因为它们的组合接近无限，但是时间和资源都是有限的。以有限“拼”无限，无异“以卵击石”。因此有些人在这些困难面前妥协了，仅仅使用随机的输入来测试程序，这种测试方式无异“缴枪投降”。
正确的方法是设计合理有效的测试策略，建立合理有效的测试用例库，选择合理有效的测试用例来执行。
文章来源于领测软件测试网 https://www.ltesting.net/