自动化测试异常处理与用例管理文档格式.docx

自动化测试异常处理与用例管理文档格式.docx

《自动化测试异常处理与用例管理文档格式.docx》由会员分享，可在线阅读，更多相关《自动化测试异常处理与用例管理文档格式.docx（22页珍藏版）》请在冰豆网上搜索。

它业务逻辑复杂，测试技术性要求高，往往使用了不同厂商的工具和多种脚本语言（如Shell，Python等），也存在了很多可用的遗留脚本。

这些完成一些预定业务操作的脚本单元，是可以直接借用的。

为了在公司和产品层面，管理好这些可复用的资源，一种好的方式是给它们标上号，如KB_PRJ01_Module02_XXX，集中管理起来，以后的用例中只要调用即可。

举例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试帐号向外汇款，取得响应信息，并保存结果，这可能是个复杂而底层的处理过程，对一般员工是不需要，也没有权限去深入掌握的。

这时，将他们包装成一个个Shell脚本或小工具，做好使用说明和统一建档，在以后的项目测试中，只要调用就可以了。

如此，可以大大提高各个有相关接口的模块的自动化测试工作效率。

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

推荐

不推荐

将用例的内容描述清楚，强调怎么操作，验证什么，然后期待的结果是什么。

Copy需求和设计文档中的内容；

描述成：

什么条件下，逻辑会是怎样。

这样对测试用例的阅读和执行人员，不具有可操作性。

期待的结果要写具体，如：

系统反应是什么；

结果数字是多少；

用户被带到什么页面；

显示什么成功信息；

后台或数据库中该记录的修改后结果是怎么样的。

”验证系统返回正确结果“；

”页面元素显示跟SPEC一致“；

”操作成功“等比较抽象的说法。

业务逻辑性较强的应用软件，做到以业务流为主线，来组织用例。

以页面形式组织用例。

以Module、Function、测试类型、基本业务流、备选业务流的树状结构形式，分层次组织用例；

使用用例管理工具。

Word格式的扁平组织结构，不利于管理和阅读。

用一个属性字段，建立用例和Spec等文档的某个章节间的映射。

无法和需求对应，以后难以计算用例覆盖率，测试执行覆盖率。

每个Module、Function、特定业务的一组测试用例，之间做到独立、没有耦合。

用例之间有依赖，无法做到：

挑选30%的用例做回归测试。

在时间和成本允许的情况下，尽量做到：

用例粒度为“一种不同的操作，得到不同的结果，就单独写一个用例“。

在用例中的操作步骤中，甚至期待结果中，仍然存在条件分支。

对于复杂的业务操作过程，如”一次顺序的表单签核过程“和”一次完整的信贷手续“，单独增加一些贯穿整个业务流的大型测试用例。

对于一个长业务操作，只存在比较零散的细节用例。

将用例分优先等级，便于在回归测试时挑选核心业务或用户操作密集的用例。

用例没有优先级和重要程度的定义。

自动化测试用例设计的原则

很多公司在实施自动化测试的过程中，往往会把所有的手工测试用例作为自动化测试用例，并且直接进行脚本的开发工作，甚至有些公司不写自动化测试用例，直接想当然地开发测试脚本，这些都是极其不规范的做法，甚至很有可能是导致最后自动化测试项目失败的最大原因。

那么问题就来了，为什么不能使用手工测试用例完全替代自动化测试用例呢？

有以下几点原因，同时也是自动化测试用例的设计原则

　● 

原则1：

自动化测试用例的范围往往是核心业务流程或者重复执行率较高的。

　　在选取自动化测试用例范围时，很多测试工程师或者上级领导可能心里会过分依赖自动化测试，会认为自动化测试就应该覆盖所有的手工测试用例，自动化测试的覆盖率就应该达到百分之百。

其实恰好相反，这样的想法往往会导致自动化测试最终失败。

在一些大型项目中，往往测试用例的数量会很庞大，而且如果遇到一些繁杂的被测程序（特别是C/S架构），脚本开发工作往往会相当耗时间，并且很多测试用例甚至根本就不能通过自动化来实现。

举些例子，现在很多公司自动化测试都是刚起步，对自动化测试的了解程度只是停留在字面上，在公司对测试也不是非常重视的情况下，当然不太愿意去花精力招一个具有自动化测试开发经验的工程师，很多还是停留在使用工具的录制回放功能来完成自动化测试。

正是存在这样的技术限制情况下，往往在实施中，会出现很多录制回放不能解决的问题，测试工具完全无法识别测试对象，无法识别一些特殊的加密测试控件。

还有，如果项目的变更频率，测试用例数量大的话，增加了后期的维护工作量等，都是造成最终失败的一些隐患。

投入越大，损失越大。

因此，往往我们会选取最核心的一些业务路径或者是重复执行率较高的一些手工测试用例进行自动化测试，这样能够充分发挥出自动化测试的优势。

　　● 

原则2：

自动化测试用例的选择一般以“正向”为主。

　　手工测试用例分正常情况和异常情况，在设计的时候，可能往往会去设计很多异常情况来验证程序是否有Bug，并且一个正常情况的测试用例往往会对应几十个非正常情况的测试用例，而每种异常情况的测试用例都会有各种各样的预期结果。

在自动化测试中，很多人喜欢将正常情况称为“正向”；

反之，异常情况则称为“反向”。

下面，我们试想以下，如果将这些异常情况全部转化、反应到自动化测试脚本中，那肯定需要非常繁琐的判断才能做到。

这个对于自动化测试工程师来说，其现有的工作量还是今后的脚本维护量都是不可小视的。

对于整个自动化测试项目来说，如果每个异常情况都要写进脚本中，那真的是花了大价钱买一堆小东西，小东西真正能发挥大作用的毕竟很少。

因此，真正在自动化测试项目实施中，往往会舍弃反向用例，个别比较重要的除外。

使每个东西都能发挥其最大的作用才是企业最想看到的。

功能自动化测试主要还是用于回归测试，回归测试的目的就是保证新增功能后老功能是否能够正常继续运作。

而自动化测试则是让测试人员从繁琐又枯燥的重复手工测试中解放出来，这就是目的和目标。

　　原则3：

不是所有手工测试用例都可以使用自动化测试来实现的。

　　这里纠正许多测试从业人员的一个错误观念，刚接触测试自动化的普遍都会认为手工测试用例全部要转化为自动化测试用例，但是在真正实施的时候，却发现很多测试用例是自动化无法实现的，或者有些测试用例根本就没有必要去自动化的。

例如，有些用例会牵涉到硬件设备辅助的，最简单的例子就是用例执行过程中需要使用刷卡机才能获取卡号信息（如果有技术能力，当然不排除自行开发接口供测试工具调用，但毕竟能有技术实力做到这一步的不多，能有这样的重视程度的更不多）；

再比如，有些测试用例是需要与合作机构进行互动联调，联调时是需要和对方实时沟通，以及根据具体情况给予响应的，这些情况多数还是只能使用手工人为地来完成。

当然，决定是否转化为自动化测试，必须事先有一个规范文档来定义哪些是需要转化为自动化测试哪些是不需要的，否则测试工程师就会不知所措，没有一个标准。

一旦有了这个标准，自动化测试工程师就可以严格按照文档里的流程去完成需要转化部分的自动化测试用例的脚本开发工作了。

　　原则4：

手工测试用例可以不用回归原点，而自动化用例往往是必须的。

　　很多有经验的自动化测试从业人员一定有这样的经历，很多时候脚本写完后，第一次执行没有任何问题，而第二次执行时立刻就会报错，原因就是没有回归原点。

所谓回归原点就是执行的测试用例最终需要恢复其在执行前的初始状态，如果没有回归原点，就会把此脚本称之为死脚本。

举个最简单的例子，比如添加用户功能，我们都知道每个用户名都是唯一的，当写完一个添加用户的脚本之后，执行第一次没有问题，因为执行前此用户还不存在，但是当执行第二次时，程序就会出现用户重复而报错，此时这个添加用户的脚本就失去了它的价值，在这种情况下，我们就需要在自动化测试用例的最后加上删除这个用户的步骤，这样在下次执行用例时就不会出现用户重复的情况了。

当然，除了回归原点，还可以使用另一种方式进行，那就是初始化数据，比如ATM机取款，假设需要执行取款100元的操作，而银行卡余额是120元，当测试脚本第一次执行时可能没有任何问题，但是第二次系统就会报余额不足，这样就成为了死脚本，解决方案有两种：

一种是直接进行初始化数据，每次执行用例之前都重置下余额（只需大于100即可）；

第二种方法可以在用例执行前，先查询下余额是否大于100，若大于等于则继续，若小于则做一笔充值100的操作，这样即可解决。

两种方式可以看具体情况使用，数据初始化方便，但有时候初始化之后可能会影响到其他自动化测试用例的执行，而第二种方式相对在脚本上需要稍微花点功夫。

究竟使用哪种方式还需要具体情况具体分析。

总之，在执行自动化测试用例之前做好数据准备，这也是自动化测试的关键步骤。

　　原则5：

自动化测试用例和手工测试用例不同，不需要每个步骤都写预期结果。

　　在手工测试用例的设计过程中，几乎每一个测试步骤都有一个预期结果。

但是，在自动化测试用例的设计中并不采用，在自动化测试用例中，只有准备在测试脚本中设置成检查点的步骤才有预期结果，其他所有的步骤只将它看作一个步骤，这样做的好处是一目了然、目的明显、层次分明，以后写测试脚本直接跟着自动化测试用例就行了。

因为经过前面的探讨应该已经知道，自动化测试中并不是所有的东西都需要验证的。

所以，作者在前面的章节中也提到过，基本上手工测试用例多多少少都要进行一些转换的，就是因为它们之间的格式是不一致的。

举一个简单的例子，假设需要设计一个注册页面的自动化测试用例，有10几个表单需要填写，在手工测试用例中，每个表单的填写都一定会有预期结果，因为它的确在检查每一项是对了还是错了，只是用的是你的眼睛在检查而已，所以速度非常的快，甚至你自己潜意识都忽略了其实你已经检查了。

但是，在自动化测试中，我们知道如果你要检查，那一定需要写代码，如果每项都检查，那代码量有多大是可想而知的，不是说做不到，只是这样做根本不符合自动化测试的特点。

所以，绝大部分时候，这些在自动化测试中可有可无的检查，我们全部“不检查”，只当做一个业务流程和步骤，是不需要设立预期结果的。

难以对于UI样式或UI逻辑进行断言

以上图为例，有一个UI样式类的缺陷（左侧菜单树的根节点“console”下面多出来一条虚线）和一个UI逻辑类的缺陷（右侧用户列表只有一页，但“下一页”和“最后一页”图标依然是可以点击的，即没有灰显）。

此类缺陷即使对于经验丰富、心思缜密的测试人员，在人工测试时也是很可能发现不了的，并且在自动化测试过程中也很难进行断言。

即使存在上述问题，测试脚本中是否有充分的断言，依然是评判自动化测试有效性的一个重要指标。

但实施过自动化测试的人应该都会有这样的体会：

“大部分