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

《自动化测试异常处理与用例管理.doc》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、测试用例的前置条件和后置条件除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。比如准备一个初始设置条件下的IE浏览器和已安装过老版本该软件的XP系统。这些可重用的准入条件，可以考虑不作为特定用例的Step，而是把它提取出来，作为SetupSection或叫Pre-Condition。对于后置条件或Post-condition，往往我们用它来做一些处理或恢复，比如在上面的取款例子中，如果我们要用相同的帐号重复测试，在正好取完所有金额，余额为零的情况下，可以通过一些步骤或数据库脚本

2、重置帐号余额。同样，您为某个用例设置浏览器禁用了Cookie，执行完该用例后，是不是也是需要回复到默认设置的状态呢？集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在TestSet这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。4.常用业务操作(KnowledgeBase)对于一个

3、大型的应用，比如银行系统，开发和测试工作是长期的，持续的一个过程，这样的系统很适合引入自动化测试。它业务逻辑复杂，测试技术性要求高，往往使用了不同厂商的工具和多种脚本语言（如Shell，Python等），也存在了很多可用的遗留脚本。这些完成一些预定业务操作的脚本单元，是可以直接借用的。为了在公司和产品层面，管理好这些可复用的资源，一种好的方式是给它们标上号，如KB_PRJ01_Module02_XXX，集中管理起来，以后的用例中只要调用即可。举例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试帐号向外汇款，取得响应信

4、息，并保存结果，这可能是个复杂而底层的处理过程，对一般员工是不需要，也没有权限去深入掌握的。这时，将他们包装成一个个Shell脚本或小工具，做好使用说明和统一建档，在以后的项目测试中，只要调用就可以了。如此，可以大大提高各个有相关接口的模块的自动化测试工作效率。根据以往工作中常见的一些问题，对于如何写好测试用例（不仅针对自动化测试），做以下做几点补充：推荐不推荐将用例的内容描述清楚，强调怎么操作，验证什么，然后期待的结果是什么。Copy需求和设计文档中的内容；描述成：什么条件下，逻辑会是怎样。这样对测试用例的阅读和执行人员，

5、不具有可操作性。期待的结果要写具体，如：系统反应是什么；结果数字是多少；用户被带到什么页面；显示什么成功信息；后台或数据库中该记录的修改后结果是怎么样的。描述成：”验证系统返回正确结果“；”页面元素显示跟SPEC一致“；”操作成功“等比较抽象的说法。业务逻辑性较强的应用软件，做到以业务流为主线，来组织用例。以页面形式组织用例。以Module、Function、测试类型、基本业务流、备选业务流的树状结构形式，分层次组织用例；使用用例管理工具。Word格式的扁平组织结构，不利于管理和阅读。用一个属性字段，建立用例和Spec等文档

6、的某个章节间的映射。无法和需求对应，以后难以计算用例覆盖率，测试执行覆盖率。每个Module、Function用例之间有依赖，无法做到：挑选30%、特定业务的一组测试用例，之间做到独立、没有耦合。的用例做回归测试。在时间和成本允许的情况下，尽量做到：用例粒度为“一种不同的操作，得到不同的结果，就单独写一个用例“。在用例中的操作步骤中，甚至期待结果中，仍然存在条件分支。对于复杂的业务操作过程，如”一次顺序的表单签核过程“和”一次完整的信贷手续“，单独增加一些贯穿整个业务流的大型测试用例。对于一个长业务操作，只存在比较零散的细节

7、用例。将用例分优先等级，便于在回归测试时挑选核心业务或用户操作密集的用例。用例没有优先级和重要程度的定义。 自动化测试用例设计的原则很多公司在实施自动化测试的过程中，往往会把所有的手工测试用例作为自动化测试用例，并且直接进行脚本的开发工作，甚至有些公司不写自动化测试用例，直接想当然地开发测试脚本，这些都是极其不规范的做法，甚至很有可能是导致最后自动化测试项目失败的最大原因。那么问题就来了，为什么不能使用手工测试用例完全替代自动化测试用例呢？有以下几点原因，同时也是自动化测试用例的设计原则　● 原则1：自动化测试用例的范围往往

8、是核心业务流程或者重复执行率较高的。　　在选取自动化测试用例范围时，很多测试工程师或者上级领导可能心里会过分依赖自动化测试，会认为自动化测试就应该覆盖所有的手工测试用例，自动化测试的覆盖率就应该达到百分之百。其实恰好相反，这样的想法往往会导致自动化测试最终失败。在一些大型项目中，往往测试用