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

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

很多公司在实施自动化测试的过程中，往往会把所有的手工测试用例作为自动化测试用例，并且直接进行脚本的开发工作，甚至有些公司不写自动化测试用例，直接想当然地开发测试脚本，这些都是极其不规范的做法，甚至很有可能是导致最后自动化测试项目失败的最大原因。那么问题就来了，为什么不能使用手工测试用例完全替代自动化测试用例呢？有以下几点原因，同时也是自动化测试用例的设计原则

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

　　在选取自动化测试用例范围时，很多测试工程师或者上级领导可能心里会过分依赖自动化测试，会认为自动化测试就应该覆盖所有的手工测试用例，自动化测试的覆盖率就应该达到百分之百。其实恰好相反，这样的想法往往会导致自动化测试最终失败。在一些大型项目中，往往测试用例的数量会很庞大，而且如果遇到一些繁杂的被测程序（特别是C/S架构），脚本开发工作往往会相当耗时间，并且很多测试用例甚至根本就不能通过自动化来实现。举些例子，现在很多公司自动化测试都是刚起步，对自动化测试的了解程度只是停留在字面上，在公司对测试也不是非常重视的情况下，当然不太愿意去花精力招一个具有自动化测试开发经验的工程师，很多还是停留在使用工具的录制回放功能来完成自动化测试。正是存在这样的技术限制情况下，往往在实施中，会出现很多录制回放不能解决的问题，测试工具完全无法识别测试对象，无法识别一些特殊的加密测试控件。还有，如果项目的变更频率，测试用例数量大的话，增加了后期的维护工作量等，都是造成最终失败的一些隐患。投入越大，损失越大。因此，往往我们会选取最核心的一些业务路径或者是重复执行率较高的一些手工测试用例进行自动化测试，这样能够充分发挥出自动化测试的优势。

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

　　手工测试用例分正常情况和异常情况，在设计的时候，可能往往会去设计很多异常情况来验证程序是否有Bug，并且一个正常情况的测试用例往往会对应几十个非正常情况的测试用例，而每种异常情况的测试用例都会有各种各样的预期结果。在自动化测试中，很多人喜欢将正常情况称为“正向”；反之，异常情况则称为“反向”。下面，我们试想以下，如果将这些异常情况全部转化、反应到自动化测试脚本中，那肯定需要非常繁琐的判断才能做到。这个对于自动化测试工程师来说，其现有的工作量还是今后的脚本维护量都是不可小视的。对于整个自动化测试项目来说，如果每个异常情况都要写进脚本中，那真的是花了大价钱买一堆小东西，小东西真正能发挥大作用的毕竟很少。因此，真正在自动化测试项目实施中，往往会舍弃反向用例，个别比较重要的除外。使每个东西都能发挥其最大的作用才是企业最想看到的。功能自动化测试主要还是用于回归测试，回归测试的目的就是保证新增功能后老功能是否能够正常继续运作。而自动化测试则是让测试人员从繁琐又枯燥的重复手工测试中解放出来，这就是目的和目标。

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

　　这里纠正许多测试从业人员的一个错误观念，刚接触测试自动化的普遍都会认为手工测试用例全部要转化为自动化测试用例，但是在真正实施的时候，却发现很多测试用例是自动化无法实现的，或者有些测试用例根本就没有必要去自动化的。例如，有些用例会牵涉到硬件设备辅助的，最简单的例子就是用例执行过程中需要使用刷卡机才能获取卡号信息（如果有技术能力，当然不排除自行开发接口供测试工具调用，但毕竟能有技术实力做到这一步的不多，能有这样的重视程度的更不多）；再比如，有些测试用例是需要与合作机构进行互动联调，联调时是需要和对方实时沟通，以及根据具体情况给予响应的，这些情况多数还是只能使用手工人为地来完成。当然，决定是否转化为自动化测试，必须事先有一个规范文档来定义哪些是需要转化为自动化测试哪些是不需要的，否则测试工程师就会不知所措，没有一个标准。一旦有了这个标准，自动化测试工程师就可以严格按照文档里的流程去完成需要转化部分的自动化测试用例的脚本开发工作了。

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

　　很多有经验的自动化测试从业人员一定有这样的经历，很多时候脚本写完后，第一次执行没有任何问题，而第二次执行时立刻就会报错，原因就是没有回归原点。所谓回归原点就是执行的测试用例最终需要恢复其在执行前的初始状态，如果没有回归原点，就会把此脚本称之为死脚本。举个最简单的例子，比如添加用户功能，我们都知道每个用户名都是唯一的，当写完一个添加用户的脚本之后，执行第一次没有问题，因为执行前此用户还不存在，但是当执行第二次时，程序就会出现用户重复而报错，此时这个添加用户的脚本就失去了它的价值，在这种情况下，我们就需要在自动化测试用例的最后加上删除这个用户的步骤，这样在下次执行用例时就不会出现用户重复的情况了。当然，除了回归原点，还可以使用另一种方式进行，那就是初始化数据，比如ATM机取款，假设需要执行取款100元的操作，而银行卡余额是120元，当测试脚本第一次执行时可能没有任何问题，但是第二次系统就会报余额不足，这样就成为了死脚本，解决方案有两种：一种是直接进行初始化数据，每次执行用例之前都重置下余额（只需大于100即可）；第二种方法可以在用例执行前，先查询下余额是否大于100，若大于等于则继续，若小于则做一笔充值100的操作，这样即可解决。两种方式可以看具体情况使用，数据初始化方便，但有时候初始化之后可能会影响到其他自动化测试用例的执行，而第二种方式相对在脚本上需要稍微花点功夫。究竟使用哪种方式还需要具体情况具体分析。总之，在执行自动化测试用例之前做好数据准备，这也是自动化测试的关键步骤。

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

　　在手工测试用例的设计过程中，几乎每一个测试步骤都有一个预期结果。但是，在自动化测试用例的设计中并不采用，在自动化测试用例中，只有准备在测试脚本中设置成检查点的步骤才有预期结果，其他所有的步骤只将它看作一个步骤，这样做的好处是一目了然、目的明显、层次分明，以后写测试脚本直接跟着自动化测试用例就行了。因为经过前面的探讨应该已经知道，自动化测试中并不是所有的东西都需要验证的。所以，作者在前面的章节中也提到过，基本上手工测试用例多多少少都要进行一些转换的，就是因为它们之间的格式是不一致的。举一个简单的例子，假设需要设计一个注册页面的自动化测试用例，有10几个表单需要填写，在手工测试用例中，每个表单的填写都一定会有预期结果，因为它的确在检查每一项是对了还是错了，只是用的是你的眼睛在检查而已，所以速度非常的快，甚至你自己潜意识都忽略了其实你已经检查了。但是，在自动化测试中，我们知道如果你要检查，那一定需要写代码，如果每项都检查，那代码量有多大是可想而知的，不是说做不到，只是这样做根本不符合自动化测试的特点。所以，绝大部分时候，这些在自动化测试中可有可无的检查，我们全部“不检查”，只当做一个业务流程和步骤，是不需要设立预期结果的。