#2. 将应用程序行为作为预期行为
近来，越来越多的项目不得不得处理这种情形。
缺乏文档、极限编程、快速的开发周期，这些原因迫使我们依赖于旧版本应用程序来编写测试用例或将其作为测试的基础。通常,这是一个糟糕的实践——但并不总是这样。它是无害的,只要你保持开放的心态并明白——“应用程序可能是有缺陷的”。只有当你不这么认为的时候,事情才会变得不好。
像往常一样，我们通过实例来说明。如果你正在为下面这个页面编写/设计测试步骤：
用例1：
如果我的测试用例步骤是下面这样的：
1.打开购物网站
2.单击”配送和退货”——期望结果：”配送和退货”页显示“在这里填写你的信息”和一个“继续”按钮。
那么，这是不对的。
用例2：
1.打开购物网站
2.单击”配送和退货”
3.在屏幕上显示的“输入订单号”文本框中，输入订单号。
4.单击“继续”——期望结果：显示订单相关的配送和退货详情。
用例2更好，因为即使作为参考的应用程序行为不正确，我们也只不过是用它来指导我们做进一步研究并按照预期的正确功能来编写期望结果。
注意：将应用程序作为参考是一条捷径，但是有风险。只要我们足够小心，它可以产生令人吃惊的结果。
#3. 一条用例中包含多个条件
我们再次从例子中学习——来看下面的步骤：这是一个登录功能的测试用例中的步骤。
a. 输入有效的详情信息，然后点击“提交”
b. 保持“用户名”字段为空，点击“提交”
c. 保持“密码”字段为空，点击“提交”
d. 使用已经登录的用户名/密码，点击“提交”
将4个不同的测试用例组合成了一个。你可能会说“这有什么不好？”不但节省了纸张，而且只用了1个用例就把原本用四个用例才能做的事情都做了，不是更好吗？好吧，不那么好。为什么？往下看：
如果其中一个失败了会怎么样？——我们不得不将整条用例标记为“失败”。如果我们将整条测试用例标记为“失败”，就意味着四种情况都不工作，但事实并非如此。
测试用例必须有一个流向。从预置条件到步骤1，然后是所有步骤。如果我遵循这个测试用例，如果第一步（a）成功，我将在登录后的页面，那里不会再有“登录”选项。所以当我到了第二步（b）的时候，测试人员在哪里输入用户名？看，流向乱了。
因此，要将测试用例模块化。这听起来好像挺麻烦的，但是你需要做的只是将事情分解，并使用 Ctrl+C 和 Ctrl+V。
总结
这是对一些测试用例文档中的常见问题的简单总结，如果你遇到了其他问题并且愿意让我们在以后的文章中讨论，请告诉我。
您的反馈、意见、问题、阅读和参与是对我们最好的赞赏。
