DevOps对测试员意味着什么？
当任一应用程序代码改变了，只有将依赖于它的每样事物都重新测试一遍，才能保证是正确的。软件相关性通常是极其复杂的，功能中看起来毫不相关的bug很常见。即使是极小的改变也要求将所有代码重新测试一遍，如果每一样都是手动测试的话，这个过程需要大量资源和时间。因此，在短周期（持续集成的一部分）内，因为软件中加入了附加组件或功能，软件的每一部分都需要经常性地重新测试。因为通常每隔几天要部署一次，所以不太可能每隔几天手动测试一遍所有的功能。自动化测试提供了一种理想的解决方案，因为这种编码测试可以在短时间按照要求进行多次。只有拥有更多实质性改变的新故事需要手动测试。一个故事的测试一完成，同样故事的自动化测试也创建好了并被添加到一个中央储存库。于是，尽管测试的数目随着项目增加而增加，但手动执行的测试数目仍保持相对稳定。
如何将一切都自动化？
DevOps中，理想情况是将测试的每个阶段都自动化，可以追踪方式的每一步并可以一次次地实现可预测的结果。尽管下面的一些做法已经存在很久了，但不少团队没能成功利用其优势，因此还需要大幅度调整改善。
自动化单元测试
自动化测试的基础应该是整个单元测试覆盖。单元测试将会测试独立的单元，通常是在一个不依赖于其他系统的类中。尽管还没有变成一个主流做法，但自动化单元测试已存在了很久，且往往被视作开发团队的责任。
自动化集成测试
集成测试连接不同的单元，还经常访问数据库和其他系统。这些服务测试进行地比单元测试更久且应该只在构建服务器上启动，它通常是由测试团队与开发团队在一个类灰盒测试里合作执行的。有不少工具如Fitnesse和NUnit，每个都拥有特定技术且能基于需求被采用。
服务测试
服务和组件层包含不同的单元。系统的各个组件被集成，它们的web服务需要通过分析对设置请求的回应来检查。这在一个应用程序的敏感部分里执行测试时尤其重要，比如保险系统中的保险金确认，一些自动化web服务验证工具（比如GreenHat Tester，SOAP UI，SOAP UI Pro等）已经存在很久了。
UI测试
UI测试是一种黑盒测试技术，本质上是测试应用程序，中间设备和基础设施的。这些GUI测试是常见的测试，其编写和自动化很贵。但是对于有效的交付到生产，自动进行所有系统和回归测试极其重要。Devops的关键之一是要了解每一层的执行者以及上述测试周期每一阶段预期的质量水平。举个例子，仔细考虑一下下列要求：“当点击提交，数据库中应该建好一个条目”。事实上，在UI测试中测试这个是不可能的。然而，我们需要确保有一个单元测试能覆盖这个场景，在这里任何失败都可以追溯到上述任一测试中，且可以追究相应执行者（如：测试团队，开发团队等）的责任。
其他自动化流程
尽管上面展现了不同测试阶段的自动化，开发和交付周期的一些其他流程可以自动提供灵活的DevOps团队。
--基于新签入代码的自动化和按需的构建部署。
--从系统到开发者/测试员回送反馈以确定潜在的性能差错的自动化服务器和性能控制。
--与多个系统相互连接并基于需求和要求按区域帮助分配团队运行进程的自动化报告和批处理。
--减少对专业运维人员或巨大资金支出需要的自动化基础设计配置和设置。
结论
DevOps的目标不仅仅是增加变化发生的速度，还要成功将这些变化部署到生产中，同时当错误发生时快速发现并改正。要做到这一点，需要一个特定人员或团队负责Quality Gate将大多数测试自动化。还有，DevOps是一种工作文化，没有敏捷、高层管理的鼓励和开发与运维团队间的理解无法发展壮大。但是如果正确实施的话，能够提供长期商业利益。
版权声明：本文出自 SPASVO泽众软件测试网：http://www.spasvo.com/news/html/2015528142745.html
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
