想清楚这4个问题，也就明白测试策略了

lsekfe

在软件质量行业工作了很多年，自己主导或者参与了不少测试自动化项目，也见过很多同行做测试自动化的工作，满眼看到满耳听到的，大家都是在谈这个技术那个技术，这个框架那个框架，听到大家讨论测试自动化策略的，很少，有的同行写了很多代码，自动化了很多用例，搭建了颇复杂的自动化平台，可是要解决啥问题？怎么去解决？现在解决了吗？说不清楚，自己觉得很好，别人看了摇头。
　　然而自动化的目标是啥，要解决啥问题，从什么角度去解决，用什么方法去解决，现有的资源能不能解决，这些都是基础性的问题，回答了这些问题，也就想清楚了自己的测试自动化策略是什么。
　　测试自动化的目标
　　1.用自动化进行回归测试：这算是最常见的自动化测试目标了。在互联网行业，技术负责人如果要求测试团队开展自动化工作，大多数都是出于这个目的。我们国内的互联网公司，多是缺少足够的质量成本意识的，老板们不满意软件质量太差，线上问题太多，也不满意投资足够的软件测试或者质量工程师，看到线上bug来气，听到测试负责人的招聘请求也光火，又要马儿跑又要马儿不吃草，听人说有这么一种技术，用机器自己完成软件测试，哎唷，不错哦，测试负责人你过来，给你个任务，搞测试自动化。。。
　　2.用测试自动化来简化手工测试，这也是一种自动化目标。有些软件测试的工作，流程简单，执行枯燥，同时应该要覆盖的场景或者数据类似而大量，测试执行的重复性又很高，手工测试就很乏味无趣，测试者可谓不堪其苦，用自动化来执行，不失为一个好的想法。也有一些测试工作，手工操作很困难，而代码执行却很容易，自动化也是解决这种困境的一个有效工具。
　　3.用自动化来监控产品质量：现在的产品质量是个广义的范畴，除了开发者开发的代码之外还有其他很多影响运行质量的因素，比如系统库，第三方服务，软件/硬件/网络环境等等，每个因素都可能存在变化进而影响系统质量。自动化可以进行持续监控，帮助及时发现相关的问题。
　　4.用自动化来提高测试覆盖面或者测试深度，进而提高测试质量：自动化测试擅长进行重复性的工作，手工测试一般集中在测试功能，但是不同测试数据的测试覆盖有限，使用自动化，可以容易的针对大量的测试数据进行功能验证，提高交付的质量信心。
　　所处的研发环境
　　想清楚了测试自动化的目标，还要想想测试自动化所处的研发环境。熟话说，看人说话，看菜下饭，到了哪个山头唱哪个山头的歌，研发环境的不同，也可以影响甚至决定你的测试自动化目标是否可行。
　　在稳定的研发环境中，产品研发周期长，产品规划合理，需求演进稳定，上述四种策略都是可以实现的。然而更多的情况下，测试团队很难有幸运在这样的研发环境中工作，更常见的是情况是研发速度快，需求混乱或者不稳定，系统功能复杂，以及随之而来的软件提测质量差。
　　在一个成熟稳定的研发环境中，上述的四个测试自动化目标，都是有机会达成的，但是如果你像大多数同行一样工作在一个快速而混乱的研发环境中，试图用自动化来进行回归测试还是困难的，自动化目标更多可以考虑后面三种策略。
　　测试自动化的切入点
　　多数研发模式，瀑布也好敏捷也好，一个产品的研发，大多要经历一个信息转换的流程，从需求分析，到架构设计，系统设计，代码开发，最后到测试验证交付，质量风险和问题，往往在一个研发过程的不同阶段引入，而这些引入的问题，其发现和修复成本，会随着时间的推移而放大，越早介入自动化，实现成本越低，发现问题越容易，但是发现的质量风险可能也相对局限，这个话题比较大，以后有机会再细聊。? ?
　　很多测试自动化，上马就要搞自动化系统测试，基于GUI操作，完全替代手工操作，有的甚至要跨平台，甚至跨多个产品或者系统做全流程测试，想法是美好的，然而失败的往往居多，成功的罕见，啥原因呢？系统级别，特别是GUI Based测试自动化，稳定性，可维护性，可靠性，执行效率都面临很大的挑战，这种挑战不仅来自于测试自动化设计和实现本身的质量，更来自于被测系统的设计甚至是业务逻辑的频繁变更，在产品快速迭代，产品规划混乱，技术债务重的研发环境中，自动化系统测试，成本高，收益低，挑战大。
　　更合理的测试自动化实施策略，是分析质量风险的分布，结合系统变更的定位来进行设计，一般而言，质量风险在哪里，就在最靠近这些风险的地方去检测它，精准直接不饶弯子，脸上长没长痘痘，手一摸镜子一照就知道了，用不着去验个血号个脉。常见的互联网产品来说，常常将被测功能拆分成三个部分：内容，业务逻辑，展示与交互，结合每次提测的变更点分析，从不同的部分去覆盖质量风险，内容可以从数据质量进行检测，业务逻辑可以从后端进行API测试，而GUI based的自动化可以对前端进行展示和交互的验证。这样一来，既避免了大量使用低效而不稳定的测试自动化手段对系统进行验证，也可以在成本可控的基础上有效的覆盖足够的质量风险。当然，其他类型的软件产品功能，设计，实现或者质量需求不同，但是因地制宜，对症下药的道理是一样的。
　　自研，还是选择商用工具平台，以及测试团队的研发能力
　　在这个问题上，测试团队常常可能走两个极端，一个是过度迷信商用平台，特别是那些吹嘘不需要代码开发能力就能完成自动化的测试工具，另一个极端是完全自研，从基础框架，到日志系统，测试调度，测试报告系统，多数自己开发，如果测试团队有充分的时间和经验丰富的工程师，能自己全部搞定当然也很牛，但实际上测试自动化生态圈中已经有了很多可以定制和使用的工具，完全没必要重复造轮子。
　　商用测试平台，往往用很酷炫的功能来包装自己，然而完全不依赖编程能力就能实现高效自动化的工具，我真的还没有遇到过，决定自动化成败的不是工具，而是人。但是相比较自己从头开发，很多成熟的商用工具确实提供了更加易用的接口，更加丰富的辅助功能，更加稳定的平台，如果提供了足够的培训，对团队自动化能力和经验的要求，相对也要低一些。
　　选择自研，要结合团队研发能力以及能控制的研发周期来考虑，有多大能力办多大事情，开源社区有不少优秀的工具和模块可以集成和使用，在资源和能力有限的情况下，可以利用，集成和改造现有的系统先把自动化跑起来，毕竟自动化最后的成败，还是要看是不是在可控的ROI下达成了测试自动化的目标，短期内可能还是要看测试覆盖率，稳定性，可靠性等，当然中长期看开发和维护一个高效的，成熟的，易用的自动化测试平台也是必要的。
　　写了那么多，总结一下，还是想强调测试自动化工作中目标和策略的重要性，很多测试自动化失败在设计上，实现上，或者实施上，但是更多的自动化，一开始就失败了，因为选择了一个不合理或者不现实的自动化策略，只有解决了策略的根本问题，结合团队能力，以及所处的研发环境的特点，选择对了自动化的方向，后续的工作才有成功的可能，测试自动化的价值才有机会体现。