自动化测试异常处理与用例管理系统.pdfVIP

实用标准文案 测试用例的前置条件和后置条件 除 了第二点中谈到的数据需要准备外，在测试用例这个 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 格式的扁平组织结构，不利于管理和阅读。 使用用例管理工具。