测试自动化与自动化测试

"测试自动化"与"自动化测试"通俗的理解上都是一个意思，我并不想咬文嚼字，但是为了说明两种自动化测试策略，我暂时用这两个名称来区分它们，就像敏捷开发中的”做正确的事情”和”正确的做事情”一样用于区分。

第一种: 测试自动化，为了测试而让测试自动化执行

这种策略主要是指团队已经拥有了自己的各种类型的手动测试，比如说手动验收测试，手动端到端测试，手动探索性测试，手动压力测试，手动安全测试等等。然后当团队已经无法承受手动测试所带来的时间和人力成本的时候，就会思考如何减少时间和人力成本，而自动化执行这些已有的测试，就能有效的减少手动测试的成本。

由于时间要求快以及测试人员的能力不足等，所以这种情况下的目标一般都是快速的将手动的测试自动化运行起来，为了测试而测试自动化。因此一般的解决方案都是选择一些易用的自动化的测试工具或者自动化测试框架，主要的工作是以配置和手动操作自动化工具为主，并且编写少量脚本，比如 Selenium IDE, Browsersync, JMeter，SOAPUI/Postman 等，可以称之为 Testing as Tool。
（注：使用工具进行调试不属于测试自动化的范围里面）

第二种: 自动化测试，为了高效执行，易于复用和维护的自动化测试

这种策略主要是指团队充分认识到自动化测试的优势，并且拥有足够的意愿以及技术能力的时候，愿意投入足够的时间以及人力成，并从整体上思考整个系统的测试策略和测试架构，从而可以实现更为有效的测试。然后尽可能的选取功能强大，并且支持二次开发的自动化测试框架或者自己开发适合自己的自动化测试框架。主要通过写代码的方式来构建自动化测试体系，主要的工作是以编写代码为主，比如 Selenium WebDriver，APPIUM，Gatling，Rest-Assured 等，可以称之为 Testing as Code。

自动化测试策略四象限：

现实中的自动化测试策略：混合

这里的测试自动化和自动化测试只是用来意喻了两种极端的自动化测试策略，不存在谁比谁更好，只是谁比谁更适合。而现实中的很多项目中往往都是互相交织着进行使用，只是不同的团队和不同的公司之间的使用的比例不一样，技术能力差的一般测试自动化占的比例大一些，而技术能力强的一般自动化测试占的比例大一些：

• 比如一个创新小团队，产品也刚刚起步，开始由于时间和成本上的限制，只能测试自动化，随着系统复杂度的增加以及团队的增大，逐步的开始思考如何根据自己系统的特点开发自动化测试系统，然后根据自己的资源情况逐步的实现各个层级的自动化测试，但是还是以工具和代码混合的方式为主。
• 比如一个大型的传统软件系统团队，产品已经成熟了，拥有大量的手动或者工具辅助的测试自动化。但是由于人力成本以及测试时间成本的增加，不得不将一部分相对容易通过编码能自动化的用例先自动化起来，然后通过自动化的产出再来思考整个自动化测试策略，根据子系统的重要性以及测试层次的优先级，在时间和人力成本都允许的情况下将优先级高的重要子系统的测试向全代码级别的自动化测试推进。
• 比如一个大型的新型互联网系统团队，由于团队中人员技术能力都十分强，测试策略和测试架构意识也很强，所以考虑自动化测试的时候直接首先思考选用什么样的自动化测试框架来编写自动化测试，并根据自己项目的架构选取适合的测试框架，如果没有合适就自己开发。然后对于一些不是很重要的系统或者测试类型，选用测试工具辅助手动进行测试就可以了。

当理解并意识到自动化测试策略有这两种极限分类之后，就需要根据自身项目的实际情况，并有效的定义整个自动化测试策略。比如可以是以工具为主，代码为辅；或者是以代码为主，以工具为副；或者全部使用工具；或者全部​使用全代码。无论选择什么都最好以降低成本和增强测试有效性，复用性和易维护性的自动化测试为目标，而尽量避免为了测试而测试的测试自动化。