自动化测试异常处理及用例管理.doc

.. -

测试用例的前置条件和后置条件

除了第二点中谈到的数据需要准备外，在测试用例这个 ，必须有一些条件满足，您才能开场执行它。比方准备一个初始设置条件下的

浏览器和已安装过老版本该软件的  系统。这些可重用的准入条件，可以考虑不作为特定用例的 ，而是把它提取出来，作为 

 或叫 。

对于后置条件或 ，往往我们用它来做一些处理或恢复，比方在上面的取款例子中，如果我们要用一样的  重复测试，在

正好取完所有金额，余额为零的情况下，可以通过一些步骤或数据库脚本重置  余额。同样，您为某个用例设置浏览器禁用了 ，执行完

该用例后，是不是也是需要回复到默认设置的状态呢？

这些完成一些预定业务操作的脚本单元，是可以直接借用的。为了在公司和产品层面，管理好这些可复用的资源，一种好的式是给它们标

上号，如  %&'()%*(+%，集中管理起来，以后的用例中只要调用即可。

举例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试  向外汇款，取得响应信息，并保存结果，这可能是个复杂而底层的

处理过程，对一般员工是不需要，也没有权限去深入掌握的。这时，将他们包装成一个个 # 脚本或小工具，做好使用说明和统一建档，在以后

的工程测试中，只要调用就可以了。如此，可以大大提高各个有相关接口的模块的自动化测试工作效率。

根据以往工作中常见的一些问题，对于如写好测试用例〔不仅针对自动化测试〕，做以下做几点补充：

推荐 不推荐

将用例的容描述清楚，强调怎么操作，验证什

么，然后期待的结果是什么。

$ 需求和设计文档中的容；描述成：什么条

描述成：〞验证系统返回正确结果“；〞页面元

素显示跟  一致“；〞操作成功“等比拟抽象

的说法。

业务逻辑性较强的应用软件，做到以业务流为

主线，来组织用例。

以页面形式组织用例。

以 *、,、测试类型、根本业务

流、备选业务流的树状构造形式，分层次组织

用例；使用用例管理工具。

- 格式的扁平组织构造，不利于管理和阅

.. -

在时间和本钱允的情况下，尽量做到：用例粒

度为“一种不同的操作，得到不同的结果，就单

独写一个用例“。

在用例中的操作步骤中，甚至期待结果中，仍

然存在条件分支。

对于复杂的业务操作过程，如〞一次顺序的表

单签核过程“和〞一次完整的信贷手续“，单独增

加一些贯穿整个业务流的大型测试用例。

对于一个长业务操作，只存在比拟零散的细节

用例。

.. -

.. -