如何编写更好的测试用例(二)[2]

　　如何编写更好的测试用例(二)[2]    测试用例设计　

    　用语言提高可测试性

　　测试步骤应该编写在生动的用例中。告诉测试者做什么。例如：

　　● 做这个。做那个。

　　● 浏览购物车页面。

　　● 对比车中物品和屏幕捕获的物品。

　　● 点击。

　　应始终明确的是，是测试者做一些事，还是系统做它。如果一个测试者读到， “按钮被按下，”这意味着他或她应该按下按钮呢，还是它意味着已经按下后验证系统显示它?搞乱测试者最好的一种办法是混淆活动和结果。比如，活动总是在左侧，结果在右侧。测试者做什么总是一个活动。系统显示什么或者做什么始终是一个结果。

　　如果我们知道一个对象的内外，养成一个简单的习惯，就是以不同的方式提及相同的事情。测试语言要一丝不苟地命名显屏、字段、服务器、Web网页、或其他测试对象。在一个开发团队，我们习惯于在某些对象甚至是原型以前，一般就提到它，如“电子邮件答复屏幕，”而它的标签实际将指：“订单确认。”或者我们可能用数字指一个显屏，无论测试者在哪儿看它，数字都不会出现。测试必须有精确的参考来指导测试者。

　　如果您为了测试者注意以后将核实的输入，建立了结构化的字段，测试可能加速。例如，如果你正在测试一个审核日志，你事先不能知道测试者将完成一个审核活动的确切分钟。如果你告诉他们注意它，它可能被胡乱地写在测试中，纸片上，或加进一个临时文件。他们可能不会找麻烦来标明什么是什么，并可能不得不到处搜寻来找到它。最好是在测试中留下一个标记的空格，在这里，他们可以写下输入，示例：

　　删除条目日期：________时间： _______

　　条目编号：________

　　测试者登录ID ：________

　　通过控制长度来提高可测试性

　　一个测试用例应该多长?一个好的分步用例长度是10-15步，除非测试者不节省他们的工作。保持测试这么简短有几个好处：

　　● 简短的用例用更少的时间来测试每一个步骤

　　● 测试者不太可能受迷惑，犯错误，或需要帮助。

　　● 测试经理可以准确估计需要多少时间来测试

　　● 结果更容易追踪

　　不要试图在10-15个步骤的标准上作弊，把很多活动填满一个步骤。

　　一个步骤应该是一个明确的输入或测试任务。您总可以在相同的步骤中添加一个简单的完成标志，如单击或按。同样，一个步骤可以包括一套逻辑相关的输入。您不必对每个步骤都有结果，如果系统不响应某一步的话就不需用。

　　保持单个测试简短的目标并不是不符合用最少数量的测试来测试应用系统的传统的目标。传统目标标准的目的是要精巧，当合理的测试业务场景或用例(use case)和需求一样多时，会工作到10-15步。该标准的目的还在于避免重复，即在一些测试中测试相同的需求。你可能不想通过使每一个测试都很长，来创建最低数量的测试，因为对于测试或维护来说，这将是一个恶梦。看老的“最低数量的测试，”的更好的方法是，衡量是否是一个“最低数量的步骤。”那么通过将50个步骤放入一个中以创造较少的测试是感觉不到好处的。

　　对于一个矩阵，一个好的长度是可以测试约20分钟。

　　自动化脚本的长度不是一个测试执行问题，因为测试通常是几秒钟。相反，问题是内容、维护和缺陷跟踪的管理。每个脚本一个业务场景或用例是足够的。它可以根据需要循环多次来加载数据或执行变量组合。

原文转自：http://www.ltesting.net