接触到了一些POC测试的东西。这篇文章翻译的真不错。转载过来看一下~~
译者是：海燕。
如何实现在自动化测试中的概念验证（POC） ？
每个团队都有不同的测试过程和步骤，手工测试是重要的、不可代替的，然而，自动化测试正加快它的发展脚步。
向一个团队介绍自动化测试是一个挑战，以下的要点将决定他们是否需要自动化测试：
-
项目持续时间
短期项目还是长期项目–长期项目更适合自动化测试
-
每轮测试要进行多少次的回归验证？
对具有重复性和冗长回归测试的项目进行自动化测试，降低了整体的测试时间，同时确保了完全覆盖。
-
应用程序的稳定性
应考虑对不受频繁变动的应用程序进行自动化测试。不稳定的产品，其图形用户界面/功能、页面元素或者XPath在不断变化 ，不应该实行自动化，不应在稳定之前对其进行自动化测试。
-
项目数据是否安全，测试是否需要一些复杂的过程？
在这种情况下，最好是做手工测试
-
团队有自动化测试的预算吗？
自动化测试将给团队增加额外的支出，例如：自动化工具成本、资源成本以及用于框架开发和编写/维护自动化测试脚本所需的时间成本 。
对于自动化测试来说，漏测、认为测试结果是理所当然的情况将永远不会发生。它100%保证每个给定的模块的覆盖率并且每一次的测试都是相同的。同时，它也将有助于在多个浏览器和多个平台上，多次执行相同的测试。
以下的图片，将帮助你了解自动化测试的过程
从技术测试的角度来看，QA团队需要从以下几个方面了解他们的自动化工具：
- 平台和操作系统矩阵测试
- 数据驱动能力
- 报告能力以及报告可移植性
- 易于调试和日志记录
- 支持版本控制
- 可扩展&可定制（能够与其他工具集成，如Ant，TestNG）
- 连续整合
- 电子邮件通知（当测试成功/失败/任何网络故障时， 可以收到相应自定义邮件）
- 如果需要跨浏览器测试和多个平台的测试，是否支持分布式测试环境
选择正确自动化测试工具：
1. 被测的应用程序是一个网络应用程序还是桌面应用程序
2. 选择一个开源工具还是付费工具
3. 工具应满足应用程序的测试要求
4. 使用该工具—根据团队的专业知识以及适合级别来使用和学习工具
5.是否支持报告？如果不支持，没有其他的报告可供选择（开源或付费），如果支持的话，它是如果从介绍和内容的角度来传递正确的数据 **另外：工具评估包括：**
在选择自动化工具时，有一点是非常重要的，那就是要考虑它是否支持应用程序图形用户界面 GUI 的实现。
1、GUI的实现，是使用传统的HTML或Ajax或其他Web开发工具
2、GUI是否包括视频，图像或大量的文本？
3、它是交互性的还是静态信息
4、浏览器测试
通过上面几点来评估测试工具，用来了解该工具是否真的符合项目的测试要求是很重要的。
实施 **自动化测试（POC） **是至关重要的，最常用的是向一个团队介绍一个工具的一种方法。一旦决定做自动化测试，选定了工具，就是时候为POC创建原型，然后提交给管理层来展示它的实时使用情况以及效益。
要做到这一点：
1、决定在POC中我们将用到的测试用例
2、选择客户最感兴趣的领域可以帮助更好的展示
3、通过一种方式来计划显示手工测试VS自动化测试，证明选择自动化测试在质量上没有退化
4、添加一个运行失败并继而找到缺陷的测试用例–这有助于进一步证实该工具确实可以找到缺陷
5、在任何需要的地方使用断言和验证点
6、明确哪些可以和不能自动化测试的地方。通常，以下几个方面不能自动化测试：
7、高亮显示，如果该工具满足以下要求：
- 它可以自动完成应用程序的所有的关键功能
- 是否在项目中要求的同一浏览器中进行自动化测试
- 自动化测试会在每一次应用程序里调用而变化？（就比如：对自动化测试而言最重要的在于每一个元素标识符是唯一的、不会因为在网页中被调用而改变）
POC的结果 -通常是下列之一：
1、工具符合项目要求–进一步的细节，例如，实施成本-谈判价格是必要的，最后确定的许可费、培训以及支持成本，咨询和实施支出等。在开源工具的情况下，确定工具的成熟度和学习曲线，以及是否可以获取学习资源和后续支持，不论是授权的工具还是开源工具，都需要考虑维护成本。需要牢记的是，这些好处在很长一段时间内才是巨大的。
2、工具不符合要求且有其局限性，则不再考虑该工具。
3、工具部分符合要求–重新审视和检查假如有一个能更好的满足要求，或完全与自动化无关。
一旦我们向管理层提出我们的概念证明，并得到了他们的批准。下一步就是在试点项目上尝试该工具。
POC模板：
没有一个完美的POC模板。它的模板一般包括：
1、POC要求
2、POC备选项（所有的自动化工具）
3、项目要求
4、基于项目需求的每一种工具的优缺点
5、POC的结果
这里有几个参考自动化POC模板：
= > POC模板1
= > POC模板2
实施试点项目：
我们应该确定我们的试点项目：
- 量化商业案例，这将决定我们是否应该使用这个工具。
- 定义命名规则和应用工具的各种指南。
- 工具的好处，包括财政及其他各方面的好处。什么可以做，什么不能做，以及可能的解决方法。
第1步# 选择测试案例
- 从客户端角度的重要的模块或功能
- 容易证明的功能
- 测试用例难以手动测试，但自动化将简化那些测试
- 破碎的功能，用来演示自动化如何帮助识别失败的测试案例
第2步# 自动化框架开发
测试自动化框架是一组概念、过程、程序、实践和环境的集合。这只不过是一个集成的系统，由规则组成，来自动化测试任何给定的产品。该系统包括一系列的功能库、API、测试数据、对象库以及各种其他模块。用于测试自动化的框架和方法脚本，对它本身的成本有影响。
以下的脚本技术可以使用：
使用上述任何技术，都可以设计一个测试框架，以帮助实现一个特定的格式来推动测试，简化测试执行和报告。
确定模板、对象的命名规则、测试用例、测试套件、数据仓库等。
第3步# 脚本开发与执行
第4步# 报告
该工具是否具有内置的报表功能？内置的报告能够准确地传送所有需要的信息吗？我们需要另一个工具，如水晶报表，reportNG等来达到报告的目的吗？
第5步# 维护自动化脚本
向利益相关者说明：
正如概念证明和实施试点项目十分重要一样，将其以正确的方式呈现也同样重要。以下几点将有助于用一种积极的方式呈现：
1、通过描述在每个测试周期中，手动测试有多么耗费精力，手动测试中面临的挑战以及如何通过自动化测试来解决问题来开始说明。
2、解释基于概念证明如何选择工具
3、自动化工具的突出特点及其如何满足测试要求
4、同时通过自动化运行，说明自动化工具如何不仅更快的测试执行，同时还有它执行验证和错误识别的能力。
5、演示报告如何显示测试用例的执行状态
6、突出报告功能，如通过彩色的图例来显示不同的测试状态，不同的测试情况下，失败的测试案例的快照，并报告可移植性
7、最后展示每一个测试周期减少的测试时间
8、解释如何实现你已经开发的整个自动化框架，以及它在使用和维护方面的好处。
做好回答一个简单的、关键的功能将需要多少时间来自动化的问题的准备 。除此之外，如果应用程序发生一个小的变更，将需要多少脚本变更以及需要多少时间来修改。
我们希望本指南能帮助你开始写一个自动化测试POC文件。
【英文原文：http://www.softwaretestinghelp.com/implement-proof-of-concept-poc-in-automation-testing/】
参考资料
