自动化测试异常处理与用例管理.doc
版权申诉
10 浏览量
2022-07-08
10:56:54
上传
评论
收藏 562KB DOC 举报
.
1 / 18
测试用例的前置条件和后置条件
除 了第二点中谈到的数据需要准备外，在测试用例这个 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 一致“；”操作成功“等 比较抽象的说
法。
剩余17页未读，继续阅读
资源评论
