浅谈软件测试人员不要这样写测试用例（给测试新手和老鸟的提示）

chenhuai

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

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

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

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

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

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

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

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

并观看这个很赞的视频，它介绍了一些编写良好的测试用例的要诀和技巧：

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

这些天，从我的学生和工作中的同事那儿，我看到的最常见的测试用例中的问题是：

步骤混合
将应用程序行为作为预期行为
一条用例中包含多个条件
在我记录的测试用例编写过程中最常见的问题列表中，这几条被列在了前三的位置。

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

我们来逐个讨论下细节。

不要这样写测试用例（给测试新手和老鸟的提示）(3)
发表于：2016-12-07来源：kiford作者：翻译：wisp点击数：32720 标签：测试用例
#1. 步骤混合 首先，什么是步骤混合？ 例如，你正在给别人指从A点到B点的方向：如果你说去XYZ，然后去ABC，这并没有多少意义，因为我们需要思考首先，
#1. 步骤混合

首先，什么是步骤混合？

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

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

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

以下是我的测试用例步骤（注：我只是写的步骤，而不包含测试用例的其他部分，如预期结果等）

a. 访问Amazon.com
b. 通过在屏幕顶部的”搜索”栏输入产品关键字或名字搜索产品
c. 从显示的搜索结果中，选择第一个
d. 在产品详情页，单击“添加到购物车”
e. 结算并支付
f. 检查订单确认页

现在，你能指出哪一步混合了多个步骤吗？

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

因此，这条用例如果写成下面这样会更有效：

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

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

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

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

像往常一样，我们通过实例来说明。如果你正在为下面这个页面编写/设计测试步骤： 用例1： 如果我的测试用例步骤是下面这样的： 1.打开购物网站 2.单

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

houxuejian

优秀

houxuejian

优秀

Star1

优秀

Miss_love

优秀