不要这样写测试用例（Tips for New and Experienced Testers）

测试用例的编写是QA团队的主要活动之一，我们的大部份时间都花在了编写、审查、执行和维护这些用例上。很不幸的是，测试用例仍然是最容易出错的地方。

由于理解上的差异，测试实践组织方式的不同，以及时间的缺乏等等原因，我们经常看到一些难以让人满意的测试用例。

网上有很多关于要怎样写测试用例的文章，但这篇文章却是告诉你不要这样写测试用例——几个将有助于创造独特、优质且有效的测试用例的技巧。

现在，让我们开始。请注意，这些技巧不只适用于测试新手，它们同样适用于有经验的测试人员。



先说最重要的——什么是测试用例？如何编写测试用例？

测试用例是指导测试人员验证一个特定的指标或目标的一组指令，随后可以告诉我们，系统行为是否与预期一致。

有关如何编写测试用例的基本说明，请参阅下面的文章：
通过需求规格说明书（SRS）编写测试用例

并观看这个很赞的视频，它介绍了一些编写良好的测试用例的要诀和技巧：
https://youtu.be/9abf1eQephA

上述资源带给了我们测试用例写作过程的基本知识。

测试用例中最常见的三个问题：

这些天，从我的学生和工作中的同事那儿，我看到的最常见的测试用例中的问题是：
1. 步骤混合
2. 将应用程序行为作为预期行为
3. 一条用例中包含多个条件

在我记录的测试用例编写过程中最常见的问题列表中，这几条被列在了前三的位置。

有趣的是，这些既发生在测试新手身上，也发生在有经验的测试人员身上。我们只是一味地遵循着相同的存在缺陷的过程，却从来没有意识到，一些简单的措施就可以很容易解决这些问题。

我们来逐个讨论下细节。

#1. 步骤混合

首先，什么是步骤混合？

例如，你正在给别人指从A点到B点的方向：如果你说“去XYZ，然后去ABC”，这并没有多少意义，因为我们需要思考——“首先，我如何到达XYZ”——而“从这里左转，直行1英里，然后在第11号路右转就可以到达XYZ”可能会取得更好的效果。

同样的规则也适用于测试用例及其步骤。

例如：我正在为Amazon.com写一条测试用例 - 订购任何产品

以下是我的测试用例步骤（注：我只是写的步骤，而不包含测试用例的其他部分，如预期结果等）
a. 访问Amazon.com
b. 通过在屏幕顶部的”搜索”栏输入产品关键字或名字搜索产品
c. 从显示的搜索结果中，选择第一个
d. 在产品详情页，单击“添加到购物车”
e. 结算并支付
f. 检查订单确认页

现在，你能指出哪一步混合了多个步骤吗？对了，就是e.

记住，测试用例总是关于“如何”来测试，所以，在你的测试用例中写出“如何检查和支付”的确切步骤是非常重要的。

因此，这条用例如果写成下面这样会更有效：
a. 访问Amazon.com
b. 通过在屏幕顶部的”搜索”栏输入产品关键字或名字搜索产品
c. 从显示的搜索结果中，选择第一个
d. 在产品详情页，单击“添加到购物车”
e. 在购物车页面点击“结算”
f. 输入信用卡信息、物流信息和账单信息
g. 单击”结算”
h. 检查订单确认页

因此，一个混合了多步的步骤可以被分解成若干个单独的步骤。下一次我们写测试用例的时候，请大家都注意这一点，我相信你们会同意我的，因为我们在无意中经常这么做。

#2. 将应用程序行为作为预期行为

近来，越来越多的项目不得不得处理这种情形。

缺乏文档、极限编程、快速的开发周期，这些原因迫使我们依赖于旧版本应用程序来编写测试用例或将其作为测试的基础。通常,这是一个糟糕的实践——但并不总是这样。它是无害的,只要你保持开放的心态并明白——“应用程序可能是有缺陷的”。只有当你不这么认为的时候,事情才会变得不好。

像往常一样，我们通过实例来说明。如果你正在为下面这个页面编写/设计测试步骤：



用例1：

如果我的测试用例步骤是下面这样的：
1.打开购物网站
2.单击”配送和退货”——期望结果：”配送和退货”页显示“在这里填写你的信息”和一个“继续”按钮。

那么，这是不对的。

用例2：
1.打开购物网站
2.单击”配送和退货”
3.在屏幕上显示的“输入订单号”文本框中，输入订单号。
4.单击“继续”——期望结果：显示订单相关的配送和退货详情。

用例2更好，因为即使作为参考的应用程序行为不正确，我们也只不过是用它来指导我们做进一步研究并按照预期的正确功能来编写期望结果。

注意：将应用程序作为参考是一条捷径，但是有风险。只要我们足够小心，它可以产生令人吃惊的结果。

#3. 一条用例中包含多个条件

我们再次从例子中学习——来看下面的步骤：这是一个登录功能的测试用例中的步骤。
a. 输入有效的详情信息，然后点击“提交”
b. 保持“用户名”字段为空，点击“提交”
c. 保持“密码”字段为空，点击“提交”
d. 使用已经登录的用户名/密码，点击“提交”

将4个不同的测试用例组合成了一个。你可能会说“这有什么不好？”不但节省了纸张，而且只用了1个用例就把原本用四个用例才能做的事情都做了，不是更好吗？好吧，不那么好。为什么？往下看：

如果其中一个失败了会怎么样？——我们不得不将整条用例标记为“失败”。如果我们将整条测试用例标记为“失败”，就意味着四种情况都不工作，但事实并非如此。

测试用例必须有一个流向。从预置条件到步骤1，然后是所有步骤。如果我遵循这个测试用例，如果第一步（a）成功，我将在登录后的页面，那里不会再有“登录”选项。所以当我到了第二步（b）的时候，测试人员在哪里输入用户名？看，流向乱了。

因此，要将测试用例模块化。这听起来好像挺麻烦的，但是你需要做的只是将事情分解，并使用 Ctrl+C 和 Ctrl+V。

总结

这是对一些测试用例文档中的常见问题的简单总结，如果你遇到了其他问题并且愿意让我们在以后的文章中讨论，请告诉我。

您的反馈、意见、问题、阅读和参与是对我们最好的赞赏。

原文：http://www.softwaretestinghelp.com/how-not-to-write-test-cases-tips-for-new-and-experienced-testers/