版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自51Testing软件测试网，感谢会员土土的豆豆在每周一问（08-04-07）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　这个话题要拆分开来分析。

　　一、编写完整的测试用例

　　二、有效的测试用例

　　三、在有限的时间内

　　第一、个人认为，没有一个测试人员可以做到百分之百“完整”！何为“完整”？是测试路径覆盖率100%么？不是！即便覆盖了测试需求的全部功能，又如何保证100%的测试需求不变更、亦或满足了客户的需求呢？测试是保证软件产品的质量。而最“完整”的质量保障或者说测试覆盖，其实应该是满足了客户的当前需求。说白了，其他不是客户想要的质量，可以弱化点，要切入要点进行测试，从而在要害关卡编写测试用例。

　　第二、何为“有效”？是测试方法正确还是测试策略高深？不是！

　　1、是基本的测试规则。如同游戏一般需要定义规则，测试需要用标准规范来约束。没有良好的测试规则，恐怕难以称之为“有效”。我以为，从分析测试需求起，就可以同步建立测试模型/模式，开发有他们自己的模型/模式，测试当然也可以使用。譬如用UML来画流程图、活动图，理清测试步骤。或者用RUP的迭代测试，是否会比普通的模型要好些呢？

　　2、测试用例的根本是设计如何测试，不是测试什么。很多人仅简单把测试操作步骤记录在案，以为就是测试用例，那就错了。测试用例必须应用用例设计思路，保证其有效的结构性，可读性，渗透性。

　　3、依然是需求变更。倘若测试组无法从项目组及时获取到变更的信息，更有甚至连开发组织也没有对变更做出响应，那么用例肯定是无效的了。

　　4、测试用例必须进行交流评审。在开发组、测试组和项目总体组负责人员和相关分管岗位人员开会讨论后，最终拍板定案。

　　第三、时间限制。“有限时间内”这一说法，其实又得看具体情况。一周可以算有限时间，一天亦可以做有限时间结点。具体情况具体分析。通常的做法是：

　　1、测试管理。我们必须从测试管理机制上考虑，努力改善测试的环境，调整项目的管理流程，为有效的测试争取出时间。

　　2、工作效率。通过建立测试用例库来节省编写测试用例时间。现在都提倡复用的思想，不是仅代码可以复用、构件可以复用，公用测试用例的复用，可以极大程度，提高测试执行的效率。若把测试用例集应用于自动化工具中，这才是真正的会用工具，减少人工劳动力。

　　3、明确测试范围，严格按测试计划工作，利用有限的资源做有限的事情，使价值最大化。

　　4、规避风险。类似需求变更等是最大的风险，当然会影响工作效率，应该趁早定义清楚。

　　综上，要在有限的时间内编写完整有效的测试用例，所涉及到整个软件开发测试过程的方方面面，不是一两个知识点或者有些经验就可以定义的。而关键还是要明确需求，尽量减少需求变更，否则后续编写的用例，也只是做无功用罢了。

　　个人拙见，请指正。