现在是自动化测试时代。越来越多的项目再将手工测试转为自动化测试来提高生产效率和覆盖率。
启动自动化测试最关键的一步是—–选择合适的测试用例并计算ROI(投资回报率)
你可以从这边文章学到什么?
在文章中，根据我以往的经验，我将如何选择正确的自动化用例的关键点记录了下来，并将影响ROI的一些因素也裂了出来，一球获得较好的测试结果和获取较大收益。
为什么要做自动化测试?
自动化测试不是万能的，而且它也取代不了手工测试，它是手工测试的一种补充方式。和手工测试类似，自动化测试也需要适当的规划、监控和控制。自动化测试，若是执行合理，会团队，项目，甚至整个组织来说，都是一项资产。
自动化测试有很多的优势；现在我把一些重要的列出来：
- 对执行一些常规用例来说，如冒烟测试和回归测试来说很有效；
- 对准备数据很有效；
- 执行一些包含复杂业务逻辑的用例很有效；
- 对跨平台的用例很有效（比如不同的OS，或浏览器等）
- 执行一些手工执行很难执行的用例；
- 执行一些迭代次数不确定的用例。
- 很长一段时间，老板们只是把自动化测试当成手工测试的一项辅助工具，重要的是要明天自动化测试时提高生产效率，提高产出率和测试覆盖率的最好方式。相比手工测试的费时和可能引入认为的错误来说，自动化测试不止节约时间，还可以提高用例重复执行时的准确率。
自动化测试用例候选集
要避免的基本错误：
一个测试人员经常犯的错误是没有选择合适的自动化测试用例。
不是所有的测试套都适合自动化的。需要对每个测试用例的ROI进行分析。首先，我们需要找到获取最高收益产出率的方法。
ROI-收益产出率—计算成本，效率和质量的公式。
这里没有什么是正确的自动化用例的统一标准。这取决于你正在测试的应用。
基于我的经验，我总结了我的经验来获得最大的ROI。
可以点击How to Translate Manual Test Cases into Automation Scripts? 查看如何将手工测试用例转换成自动化脚本
怎样选择合适的自动化测试用例
第一步：
确定自动化测试用例的评测参数
现在，我确定的参数如下，你可以基于你自己的应用来确定你自己的参数。 - 用例执行时需要不同的数据集
- 用例执行时需要不同的浏览器
- 用例执行时需要不同的环境
- 用例执行时依赖复杂业务逻辑
- 用例执行时需要不同的用户集
- 用例包含大量的数据
- 用例是独立的
- 用例需要特殊数据
第二步：
将应用分成模块级别。对于每一个模块，根据上面提到的评测参数分析是否适合做自动化测试用例。下面的列表你可以改一下拿来用。
对于其他的模块，操作也是类似的。
第三步：
将不同模块的自动化用例合并在一个表格中
上图很简明易懂。下面我会量化一些细节，然后对用时进行估算。
第四步：
当你都将这些粒度性的信息详细列出来后，你可以将他们这些列在表格中，然后计算ROI
我们在计算ROI时，需要考虑到以下点： - 买工具或者买整数的开销；
- 开发脚本的时间
- 维护脚本的时间
- 人工或自动分析执行结果的时间
- 训练资源的时间和金钱花费
自动化测试ROI计算例子：
大多数情况下，计算ROI是考虑5年期的，但不绝对。根据上面提到的，我们来计算5年期的ROI。你可以对此做下调整。
ROI=（累计收益/所有的投入）*100
手工转自动化测试—过程中有哪些挑战 Manual to Automation Testing – What are the Process Challenges?
我在自动化一个测试套时,将遇到的一些大的挑战记录如下:
**#1.自动化需求.**每个测试团队都是独一无二的,对自动化的需求也是独特的。我们不可能开发出一个标准，但是我们可以定一个适用的准则。鉴于此，自动化需要管理人员及开发团队的支持。
#2将应用完全自动化，100%自动化是个大的挑战。之所以不太可能，是因为她需要相当合理的规划和监督以及需要时间。有n个认证和属性需要验证，有数据的多项排列组合需要验证，因此自动化时需要考虑策略，如何将这些都覆盖进来。
#3. 手工和自动化思维： “我们一般将重要的和重复性的工作自动化，但是我们将重要的功能手工测试。”觉得很困惑?我也困惑，但是这是事实。我们需要定个规则来确定什么是重要的测试用例。这些参考标准可以是有复杂的业务逻辑，客户特别感兴趣的功能，容易出bug的地方等。
#4.考虑测试框架:设计自动化测试框架是自动化话测试时中最重要的方面。比起脚本来，在设计自动化框架上更应该多花心思。涉及框架，做个框架的组成清单。当框架足够健壮时，写脚本和维护才会变得容易。
#5.团队的知识构成。当我们想到自动化时，我们直接就跳到学习编程语言或脚本语言上了。学些编程语言确实有用，但是更多的重点应该放在构建和维护逻辑上。自动化不是少数人的责任，而是整个团队的责任。这不止可以提升少数人的技能，也可以激发他们的动力。
#6. 报告:每个工具对测试报告都有标准。定制它是一项大的挑战。测试报告需要整合和维护，这也增加了成本。
#7.信任。我们需要信任自动化测试人员。我们花了工时来写自动化测试套，但是我们不相信测试结果。我们还需要维护自动化测试用例。我们需要将测试该应用的功能测试人员加入到自动化测试中来，因为他们更懂应用。大多数情况下，自动化团队是单独出来的，其他的功能测试团队不关系自动化测试脚本，跑完用例就结束了，因为他们觉得跟进脚本增加了他们的工作量。
可以看=> 手工和自动化的挑战。
结论：
大多数情况下，我们喜欢将回归用例自动化(在敏捷环境中这有些挑战)因为回归用例包含大量的用例，我们可以将这些回归用例分解成多个小的测试套，然后在不同的环境下运行不同的测试用例。假设一个回归用例集含有1500条用例，我们可以分成3个用例集，每个用例集含有500条用例，然后分别自动化。
相比完全自动化，我们可以选择逐步自动化。也就是说，我们可以根据原型模型来涉及自动化用例集。创建一个结构或框架，刚开始开始时只写少量的自动化用例，然后逐步加入用例来完善它。
自动化测试也要遵循戴明环(PDCA闭环)。作为一项持续活动，重心应该放在搭建一个合理的框架，这样在维护或新增功能时会比较容易。它需要来自管理层和研发团队的支持。我们要鼓励功能测试团队来做大部分的自动化测试工作因为他们是最懂产品的人。
关于作者:Shilpa Chatterjee Roy.专注测试领域8.5年
英文原文: https://www.softwaretestinghelp.com/manual-to-automation-testing-process-challenges/