因此，让我们进一步调查围绕自动化测试的问题领域，看看怎么做才能改善这种情况：

。  廉价的测试没什么价值。

一个问题是，单元测试是成本很低的自动化测试类型，一般来说它比其他的测试类型带来的价值更低。单元测试仍然是一种不错的测试类型，但是人工测试可能被认为会在实践中暴露更多的bug。可能就会感觉写单元测试没什么必要了。

。  很难去创建和自动化集成测试相关的测试支架( test cradle)。虽然实现单元测试的测试支架或者测试夹具( test fixture)不是很困难，但是将其

变得更像产品环境会越来越困难。这可能是因为缺乏硬件资源、许可证、人力等。

。  程序的功能随时间而变化，而测试必须做出相应的调整，耗费时间和精力。

这使得自动化测试好像只是让软件开发变得更困难而没有感觉到什么收益。

在开发和运维关系不是很紧密，或者说非面向DevOps的企业中，尤其如此。如果有其他人不得不处理你那些不能正常工作的烂代码，那么对于开发人员来说写点烂代码根本无关紧要。这不是一个健康的关系。这也是DevOps想要解决的最核心的问题。DevOps的方式证明了这条已重复数次的规则：帮助不同角色的人们紧密工作在一起。在像Netflix这样的企业中，一个敏捷团队对自己服务的成功、维护及中断负有全部责任。