在给简历列技能的时候，软件测试者和工程师也许要考虑一件事，那就是越来越多的公司正在寻找一种新型的软件专家。他们要找的不仅仅是能够在出现问题时修补系统漏洞和崩溃服务的人，他们还在寻找愿意花时间去故意攻击这些服务和系统的人。

有意制造事端，导致服务和软件崩溃或者失灵，这个叫做故障注入。这是一种QA范式，微软的两位软件工程师认为，这个东西可以缓解现代软件部署和管理相关的风险，尤其是与云端应用和服务相关的风险，通过受控的方式帮助工程师观察和找到这些失效情况的补丁，而不是在意外情况下第一时间去处理它们。

云是如何把事情搞复杂的

尽管云改善了企业迅速发布高质量、高能力应用的能力，但专家警告说要小心这些应用汇变得太复杂，难以进行人工测试。

软件变得越来越复杂，据Netflix的工程经理Casey Rosenthal说，以至于整个流程无法在心中建模，日益给QA造成了负担。实际上，公司的软件系统也许是“黑箱”，甚至连负责开发它们的软件工程师都弄不清楚。

“我认为这整个行业正在转移到这样一个领域，在那里系统变得越来越复杂，” Rosenthal说：“复杂到即便是对于开发某些系统的软件工程师来说，这些系统本身也变成了黑箱。比方说你无法对深度学习算法进行反思，没办法以任何有意义的方式进行。”

除了这种复杂性以外，还有就是软件部署的速度很快。据微软的软件工程师Michalis Zervos说，部署日益加快的节奏意味着组织需要找到测试以外的办法来验证这些服务在生产下如预期行事。

微软首席软件工程经理兼服务弹性团队领导Dmitri Klementiev对此表示同意，他说软件开发和交付给客户软件的速率使得进行及时进行软件的完整测试变得太过困难。实际上，他并不认为任何服务开发者在交付前有时间彻底测试完所有的软件。

Rosenthal指出，这个问题的一大部分在于，事实上当服务中断之后，往往是处在最不方便的时候——也即是说，在半夜。

“没人想在凌晨3点接到电话说系统罢工了，因为其中一个服务器突然消失或者停止响应了，”他说。

Zervos指出，这不仅给开发者造成不便，而且一个疲惫的头脑还会导致糟糕决策——从而使得后果甚至更加糟糕。

注入故障

整个行业都需要一种新的办法来处理日益增加的复杂性，Klementiev说。处理的办法之一是采用Zervos和Klementiev所谓的“故障注入”。

据Zervos说，故障注入是这样一种办法，通过它软件工程师、开发者或者测试人员可以模拟经常在跟云服务这样的东西配合时发生的错误的效果，比如迫使资源压力的增加或者网络中断的发生。故障注入必定并没有规定的办法——只是把系统推到极限，有时候到破坏点的程度，只是为了看看会发生什么，从而确定作为团队要作何响应。

新颖创意还是被废弃的概念？

Michalis Zervos和 Dmitri Klementiev都是微软的软件工程师，据两位的说法，故障注入背后的想法并不新鲜。几乎在10年前微软自己就已经进行过被认为是故障注入变种的做法。

“比方说，当微软和其他公司有传统封装软件的时候，在代码中进行故障注入……会迫使代码抛出错误，迫使代码返回错误值，这时候再来看看应用的其他部分会如何表现，” Zervos说。

Klementiev同意，故障注入已经存在了很长一段时间，但云端软件交付的性质已经改变了这种思想形态。在过去，软件交付的周期一般都是1、2年，所以在测试产品和处理bug时，时间是站在他们这边的。

“我们可以用来测试的时间很多，是云环境下不能比的……我们可以推迟交付知道我们修补好所有发现并认可的bug，” Klementiev说：“而现在交付云软件时，我们可能每天都要交付。”

Zervos和Klementiev同意，鉴于这些交付周期已经加快，故障注入可以帮助填补仅仅执行单元测试等传统技术无法满足要求所造成的鸿沟。然而，Zervos指出，这些测试并不总能为服务依赖性而不仅仅是代码以及对整个系统的影响提供洞察。

Zervos说：“比方说如果我们希望测试，如果我的CPU压力上升的时候大家都在点我的服务，使得CPU使用率达到了90%的话，我的这个登录服务，一项鉴权服务会发生什么呢？……尝试任何那些传统办法几乎都是不可能的。”

Zervos补充说，故障注入可以跟所谓的“压力测试”这种测试方法相比较——制造更多流量或者从外部给服务制造更多的压力。但即便这类测试也不能提供故障注入可提供的那类信息，包括看看在特定情况下依赖性是如何体现的。

错误注入最有用的方面之一是，你可以看到一个bug或者一次崩溃的结果，你还可以在它们真正发生之前确定好的行动步骤，Klementiev说。这些崩溃必定是要发生的，而这个可以让工程师更快发现问题，然后在受控的方式下处置它们。

Zervos指出，这可能也会涉及到软件相关的错误，比如像OutOfMemoryException这样非预期的例外或者错误代码的出现。错误注入使得开发者和工程师看到其余代码，以及任何的依赖服务因为该事件会如何表现。

“比方说，你试图跟SQL服务器对话时，一些数据包丢失了，或者连接很慢，”Zervos说：“错误注入很容易就能测试这些。”

反对错误注入的理由  

然而，Zervos和Klementiev说，采用这种办法并不是免费搭车，执行故障注入的时候尤其如此。许多开发者根本就不能或者不想花时间去学习一种新的测试方式。这个问题使得理解如何对故障注入进行自动化，以及如何让组织的相关人执行这一流程尽可能的方便变得非常关键。

Zervos说，另一个问题是他发现许多工程师质疑鼓励以真实客户流量往生产环境注入故障的做法，这是可以理解的。为了应对这个，最好是先在测试环境下慢慢树立起对你执行故障注入能力的信心。然后，当信心足够大时，开始在生产环境下执行故障注入。

然而，Klementiev说，即便测试者、开发者或者工程师对自己在生产环境下进行故障注入的能力信心够足了，他们也仍然需要得到公司领导层的完全支持才行，因为基本上这种做法是搞破坏。这是很大的文化变革，但领导买账仍然非常关键。

“如果他们不在现在承担一点点风险的话，到后面可能公司要付出的代价就要高得多，” Klementiev说。

Zervos和Klementiev指出，对于预算、客户群以及开发或测试团队有限的小公司来说，这个也许不是简单的事情。然而，Klementiev提出，即便他们不能正式进行故障注入，也有临时方案可以做。

“我认为任何人都可以做的最简单的故障注入是过去把电源给拔了，” Klementiev说：“只需要跑到数据中心然后把它给关了。或者关掉一机架的机器。我知道有很多公司就是这么做的。”

开发者和测试者在一条船上吗？

Klementiev和Zervos同意，这种类型的测试仍然有待得到行业认可。然而，据Zervos说，这种做法的方向是积极的，并且他相信软件工程的本质绝对可以让这种做法得到认可。

“我认为它们意识到往弹性和故障注入投入的好处，近期许多公司都会需要故障注入测试，”他说：“过去2年，你会看到越来越多的企业把资源和努力投入到这一领域。对我来说，这是一个信号，标志着故障注入测试在云服务世界正在变得越来越大。”

Klementiev指出，这还不仅仅只是学习技巧的事情。相反，在云端的软件开发方面，它要求接受新的哲学。正如他所述，业界需要一个新的学科，一个能成为云服务文化一部分的学科。