3. 测试用例的前置条件和后置条件
除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件 满足，您才能开始执行它。比如准备一个初始设置条件下的IE 浏览器和已安装过老版本该软件的XP系统。这些可重用的准入条件，可以考虑不作为特定用例的Step，而是把它提取出来，作为Setup Section或叫Pre-Condition。
对于后置条件或Post-condition，往往我们用它 来做一些处理或恢复，比如在上面的取款例子中，如果我们要用相同的帐号重复测试，在正好取完所有金额，余额为零的情况下，可以通过一些步骤或数据库脚本重 置帐号余额。同样，您为某个用例设置浏览器禁用了Cookie，执行完该用例后，是不是也是需要回复到默认设置的状态 呢？
集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和 在多处复用。
顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏 览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可 以。
4. 常用业务操作(Knowledge Base)
对于一个大型的应用，比如银行系统，开发和测试工作是长期的，持续的一个过程，这样的系统很适合引 入自动化测试。它业务逻辑复杂，测试技术性要求高，往往使用了不同厂商的工具和多种脚本语言（如Shell，Python等），也存在了很多可用的遗留脚 本。
这些完成一些预定业务操作的脚本单元，是可以直接借用的。为了在公司和产品层面，管理好这些可复用的资 源，一种好的方式是给它们标上号，如KB_PRJ01_Module02_XXX，集中管理起来，以后的用例中只要调用即 可。
举例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试帐号向外汇款，取得响应信息，并保存结 果，这可能是个复杂而底层的处理过程，对一般员工是不需要，也没有权限去深入掌握的。这时，将他们包装成一个个Shell脚本或小工具，做好使用说明和统 一建档，在以后的项目测试中，只要调用就可以了。如此，可以大大提高各个有相关接口的模块的自动化测试工作效率。
根据以往工作中常见的一些问题，对于如何写好测试用例（不仅针对自动化测试），做以下做几点补充：
推荐 | 不推荐 |
| 将用例的内容描述清楚，强调怎么操作，验证什么，然后期待的结果是什么。 | Copy需求和设计文档中的内容；描述成：什么条件下，逻辑会是怎样。这样对测试用例的阅读和执行人员，不具有可操作性。 |
| 期待的结果要写具体，如：系统反应是什么；结果数字是多少；用户被带到什么页面；显示什么成功信息；后台或数据库中该记录的修改后结果是怎么样的。 | 描述成：”验证系统返回正确结果“；”页面元素显示跟SPEC一致“；”操作成功“等 比较抽象的说法。 |
| 业务逻辑性较强的应用软件，做到以业务流为主线，来组织用例。 | 以页面形式组织用例。 |
| 以Module、Function、测试类型、基本业务流、备选业务流的树状结构形式，分层次组织用例；使用用例管理工具。 | Word格式的扁平组织结构，不利于管理和阅读。 |
| 用一个属性字段，建立用例和Spec等文档的某个章节间的映射。 | 无法和需求对应，以后难以计算 用例覆盖率，测试执行覆盖率。 |
| 每个Module、Function、特定业务的一组测试用例，之间做到独立、没有耦合。 | 用例之间有依赖，无法做到：挑选30%的用例做回归测试。 |
| 在时间和成本允许的情况下，尽量做到：用例粒度为“一种不同的操作，得到不同的结果，就单独写一个用例“。 | 在用例中的操作步骤中，甚至期待结果中，仍然存在条件分支。 |
| 对于复杂的业务操作过程，如”一次顺序的表单签核过程“和”一次完整的信贷手续“，单独增加一些贯穿整个业务流的大型测试用例。 | 对于一个长业务操作，只存在比较零散的细节用例。 |
| 将用例分优先等级，便于在回归测试时挑选核心业务或用户操作密集的用例。 | 用例 没有优先级和重要程度的定义。 |
本文出自51Testing软件测试博客，转载请注明出处。
