|
一、自动化项目的选型 尽管软件人员对自动化技术趋之若鹜，但是自动化技术本事不是万能的，并不是所有的项目都是适合自动化的，如果盲目的开展自动化，反而会造成资源的浪费，所以在选择自动化项目的时候，就要进行一下赛选，看下是否满足进行自动化的条件。这样才能让自动化技术带来实实在在的效益。下面给大家总结了一些个人对于项目选项的思考。 1、项目周期长且稳定 项目本身是一个长期的规划，而不是一个短期的或者新的项目，以为开发测试脚本也是需要时间的，需要成本的，而这个成本是需要在后期反复的回归测试时补回来的，如果项目周期不够长的话，可能脚本没开发完项目就结束了，或者花了大量的经历去开发，结果只运行了一次；稳定指的是在项目长期的进行过程中，不会出现大量且频繁的改动需求，因为需求的改动一定会使测试脚本不可用，需要重新积累测试脚本。 2、模块功能能够进行回归测试 自动化脚本的目的是提高测试效率，节约成本。只有测试脚本反复的被使用，测试效率才能够得到最大化的提升。所以测试项目对功能模块的回归需求很大程度上决定了实施自动化测试的意义，回归的需求越多，自动化能够产生的收益越大 3、场景易用于自动化 这里的易用于自动化指的是某些特殊的场景，人为的测试很难实现，比如反复操作、大量的文本输入、大量的数字计算、精确的单击等。这些操作人为去做，很麻烦也很难实现，那么自动化技术就是不二的选择 4、考虑成本和效益 在公司，一切讲究的就是收益、价值，如果自动化没有能够提高效率和节约成本，那表示自动化就是失败的。因此我们需要优先计算投资回报率，而不是直接陷入自动化的大坑里，简单的理解就是： 自动化测试工程师总人数<自动化单次平均节约人天数*执行次数 也就是说： 1、执行次数越多越好 2、有一个收回成本的临界点 3、执行次数至少大于这个临界点才能节约成本 所以为什么说，项目周期要足够长且稳定的项目比较适合做自动化，因为项目周期长，意味着可以回归的次数更多。自动化脚本执行的次数越多，回报也就越高。 二、自动化测试的进行 1、选择合适的工具 目前市面上的工具太多了，而且自动化包括：功能、性能、安全等，不同的自动化类型肯定选择不同的工具。而且是否收费也可以划分：商业、开源；测试阶段可以分为：白盒测试工具、接口测试工具、GUI工具等，因此，根据你的业务功能、预算等选取的工具肯定也是不一样的。 2、提高被测系统的可测性 一个自动化能不能测，不仅取决于测试人员的能力和测试工具能否实现，还要取决于系统框架和开发对可测性的支持；对于标准的控件而言，需要开发在设计和编码阶段提供良好的自动化命名规范，例如id、name 3、没有必要完全的进行自动化 一个系统需要进行自动化测试，很多刚开始做的朋友会想着，我既然做自动化了。就应该尽可能的吧全部的自动化，哪怕有些场景不适合自动化，例如某个结果是动态的，或者是跨平台的，这种需要花费大量的精力的去沟通和处理。也就没必要非得做成自动化了。 4、尽可能的优化时间 对于单一的测试而言，不用考虑这个问题，因为执行的很快，但是当自动化用例变多了。就需要考虑这个问题了。因为总是希望能够越早的获取到自动化测试的反馈结果，一般我们晚上开始跑自动化脚本。如果一次自动化的执行需要超过一夜，早上拿不到结果，就会很烦。这个时候测试脚本的执行时间会成为你的一个瓶颈，需要你去考虑。但是这个问题就具体问题再去分析吧。一般情况下我们可以从以下几个角度去优化： 1、取消等待时间，替换为waitFor函数 2、尽可能的减少步骤 3、一个用例可以多设计几个检查点，避免一个用例一个检查点 4、尽可能的做分布式，防止一天机器执行 5、最少步骤的进入到被测场景 正常情况下，人工执行测试都是按照业务场景来进行的，如果到达被测场景需要10步，人工测试的时候会正常的进行这10步，在进行的过程中，因为人是有自主能动性的，所以，我们不仅仅是检测这最终结果，其中的过程，我们也会顺便测试一遍。但是自动化不一样，他是没有人的主观意识的。自动化需要自己加断言，但是也不能一步一个断言，这样是不利于维护脚本的，并且会让你的自动化脚本很累赘，很大，不好整理。所以自动化用例都是一个单独的场景。在设计用例的时候就要求保证覆盖了手工场景的前提下，要以最少的步骤进入到正式的北侧场景 |
|
|
