误区一、好的用例是能发现未知BUG的用例
首先必须说明，这句话其实是很有道理的，然而很多测试人员都曲解了这句话的原意。他们把测试用例看作孤立的个例，盲目追求设计“难于发现的缺陷”的用例，忘记了测试的目标是尽可能发现程序中存在的缺陷。
软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合,对它的评价也只能对测试用例的集合来进行，测试本身是一种验证加确认(validation &verification)的活动，测试需要保证程序做了它应该做的事情,且没有做它不该做的事情。
测试用例的好坏应以是否完整有效覆盖需求为依据，我们不应针对单个的测试用例去评判其好坏，而应对某次测试的用例集合总体作评价。
误区二、测试用例应该详尽,使得未接触系统的人也能进行测试
测试用例描述的详细程度困扰着许多测试人员。描述简单的用例不利于用例的传递，而描述复杂的用例的设计和维护需要耗费大量的时间。然而很多测试主管或者测试工程师本身，强调测试用例“越详细越好”，全然不顾实际的测试资源不足的事实，一定要写出“没有接触过系统的人员也能进行测试”的用例。
这种做法无疑会耗费了很多的时间和资源，从而极大的压缩测试实施的时间和人力，没有足够的测试执行时间，就无法发现更多的软件缺陷，测试质量也就无从谈起。
测试活动应需要结合自身的资源(测试人员对系统熟悉程度、测试工程师数量、测试时间等)和项目的需求来进行综合考量，以实现质量、时间和成本的最佳平衡。我们建议给测试设计安排30%-40%左右的测试时间，测试工程师可以根据项目的具体情况确定测试用例的颗粒度，在测试用例的评审阶段由相关人员对其把关即可。
误区三、测试用例设计是一劳永逸的事情
很多测试人员(尤其是对测试技术不太了解的主管)认为设计测试用例是一次性投入，片面追求测试用例设计一步到位，导致设计的测试用例与需求和设计不同步的情况在实际开发过程屡屡出现。
这种认识造成的危害性在于使得设计的测试用例缺乏实用性，误报很多不是软件缺陷的BUG，误导测试用例执行人员，同时也浪费了开发人员的解决BUG的精力和时间。
几乎所有软件项目的开发过程都处于不断变化(随着需求的变更)过程中。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整和数量的增减，增加一些针对软件新增功能的测试用例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。
误区四、测试用例不包含实际的数据和明显的验证手段
测试用例是通常是一组输入、执行条件、预期输出结果的组合，毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具备可执行性。例如我们常用的边界值法就对数据提出了明显的要求。
很多测试工程师(尤其是测试新手)编写的测试用例中，“预期输出”仅描述为程序的可见行为，实际上，“预期结果”的含义并不只是程序的可见行为。例如，对一个代表信息管理系统，输入代表信息，点击“保存”按钮后，系统提示“保存成功”，这样是不是一个完整的用例呢?是不是系统输出的“保存成功”就应该作为我们唯一的验证手段呢?显然不是，保存是否成功需要查看相应的数据记录是否在数据库中更新：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。
因此，在测试用例中，还应该包含实际的测试数据和对测试结果的显式验证手段。
文章来源于领测软件测试网 https://www.ltesting.net/
