自1995年,GoF四人组在《设计模式》一书中定义了23种设计模式后，设计模式就如灯塔般给无数开发者指明着方向。这些设计模式有些是我们耳熟能详的，如单例模式,工厂模式,策略模式，也可能有鲜有耳闻的，如享元模式,解释器模式.本文将列出每种设计模式在实际应用中的使用频率，已给开发者以参考。

创建型(Creational Patterns)

结构型(Structural Patterns)

行为型(Behavioral patterns)

原文发布在: https://www.jianshu.com/p/907b21353a4f

这是一个老生常谈的话题，如果你打开这篇文章，说明你正困惑于“如何开展自动化”这类问题。相信目前测试业内普遍认同"自动化并不是银弹"的说法。也就是说自动化并不能完美的解决测试的所有问题，但很多公司又都在搞自动化，说明开展自动化是需要具备一定条件的。

适不适合开展自动化测试

开展自动化测试之前，你第一个要问自己的问题就是"我们的团队适不适合开展自动化测试?"。并不是公司老板说我们需要开展自动化测试来提高工作效率，节约公司成本，就匆匆忙忙的开始进行自动化测试。你至少应该从以下几个方面考虑是否适合开展自动化测试:

公司及业务的规模
一般说来,自动化测试是大公司才能玩得转的游戏。因为在这些公司，开发流程相对比较严谨和完善，有专门的自动化测试团队来实施自动化;同时也因为规模大，可以使自动化测试形成规模优势，从而降低成本，提高效率

项目的规模和性质
并不是所有项目都适合进行，一些短平快的项目不适合自动化测试,一些需求长期变动频繁的项目也不适合自动化测试，只有迭代周期长且需求变动平稳的项目才适合自动化测试.

做好ROI(投资回报率)
做工作干事业，我们总是会考虑投入和产生的问题,自动化测试自然也例外。简单的概括,自动化测试的ROI可以用如下公式来计算:

ROI=(手工测试成本-自动化测试成本)/自动化测试成本*100% 

比如：现在有100条测试用例,设计这些用例需要耗费3天时间,执行一次需要耗费1天时间,那么以1月执行5次为例，
那么一个月手工测试成本为3+1*5=8人日，而自动化测试100条用例设计需要7天，执行一次需要耗费2小时,
但由于业务需求更改，每次需要花费半天进行脚本调整，那么一个月的自动化测试成本为7+0.5*5=9.5人日
由此可见,只有在需求尽量少变更（减少维护成本），且需要多进行自动化测试的情况下,自动化测试才会有比较高的回报率.

测试团队的技术水平
虽然目前自动化测试框架的**度已经很高，但依然需要测试人员具备一定的开发能力。如果在技术储备不足的情况下开展自动化测试，成功的几率很低。

业务需求变动频繁
关于这点,几乎已经是业界内的共识。对变更很频繁的功能进行自动化测试，结局几乎都是灾难性的。测试人员往往陷入到自动化测试用例维护的漩涡中,结果就是自动化测试没有起到应有的作用，手工测试也被耽误了。

持续集成的项目
目前越来越多的团队实施了敏捷开发模式，敏捷开发中比较重要的观点就是持续集成。由于持续集成的持续性和即时性，所以非常需要自动化测试来持续的，及时的反馈测试的结果。

节制且有策略的实施自动化测试

实践出真知.jpg

要选择合适的自动化测试

测试金字塔.png

大家对上面这幅图都应该很熟悉，测试金字塔揭示了进行测试的优先级。如果你们公司需要开展自动化测试，那么如上图所示，从单元测试开始是最好的选择。但单元测试是否实施以及如何实施的主动权往往在开发的手里。所以开展自动化测试的最佳选择往往是API测试(接口测试)。尤其是在现在越来越盛行基于服务的开发以及前后端分离，给接口测试实施自动化带来了极大的便利。对于UI自动化测试,虽然关于UI自动化测试讨论以及相关技术和框架都比较多，但实施的效果往往都不尽如人意。

你可能需要一个自己的框架

我们需要自己的框架并不是为了显示自己逼格高，而是当自动化测试规模到了一定的规模，维护自己的框架才会使你的自动化测试更好的进行。你也不必自己从头开始造轮子，在现有的测试框架上实现适合自己公司的功能就可以。比如说，使用Junit驱动API测试用例的执行，那么你可能需要一个平台来管理你目前的用例，批量执行测试以及测试报告的查看。

结束语

自动化测试,你是否值得拥有，我想答案是肯定的。但如何拥有，确有很长的一段路要走。如何结合技术与实践总结出适合工作的最佳方案是最终的目