1.4 开发者测试趋势
1.4.1 软件开发和运营困境
很多组织将开发和系统管理划分成不同的部门。开发部门的驱动力通常是频繁交付新特性，而运营部门则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。
开发人员经常不考虑自己写的代码会对运营造成什么影响。他们在交付代码之前，很少邀请运营人员参与架构决策或代码评审；开发人员对配置或环境进行修改之后，也经常会因为没有及时与运营人员沟通，导致新的代码不能运行；开发人员在自己的机器上手工修改配置，却有记录所有需要的步骤；而运营人员想找到需要的参数配置，通常需要尝试很多不同的参数组合。
开发人员倾向于使用有利于快速开发的工具，如对代码修改实现更快的反馈、更低的内存消耗等。这样的工具集与运营人员面对的目标运行时环境非常不同，后者对稳定性和性能的要求远胜于灵活性。由于开发人员平时使用桌面计算机，他们倾向于使用为桌面用户优化的操作系统，而生产环境的运行时系统通常都运行在服务器操作系统上。在开发过程中，系统在开发者的本地机器上运行；而在运营过程中，系统经常分布在多台服务器上，如Web服务器、应用服务器、数据库服务器等。
开发是由功能性需求（通常与业务需求直接相关）驱动的，运营是由非功能性需求（如可获得性、可靠性、性能等）驱动的。运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险；如果运营人员拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大；变更规模越大，风险也越高，因为其中涉及的区域越多；而由于运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特性交付给用户使用的速度。运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程；而开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。
企业在开发过程中希望产品更新更小、更频繁，从而降低更新风险。因此，开发人员应更多地控制生产环境的复杂度，更多地以应用程序为中心来理解基础设施。产品的流程尽量定义得简洁明了，所有流程尽量自动化，以促进开发与运营的协作。
一般而言，当企业希望将原本笨重的开发与运营之间的工作移交过程变得流畅无碍时，他们通常会遇到以下三类问题：
1）发布管理问题：很多企业有发布管理问题。他们需要更好的发布计划方法，而不只是一份共享的电子数据表。他们需要清晰了解发布的风险、依赖、各阶段的入口条件，并确保各个角色遵守既定流程行事。
2）发布/部署协调问题：有发布/部署协调问题的团队需要关注发布/部署过程中的运行。他们需要更好地跟踪发布状态，更快地将问题上升，严格执行流程控制和细粒度的报表。
3）发布/部署自动化问题：这些企业通常有一些自动化工具，但他们还需要以更灵活的方式来管理和驱动自动化工作——不必要将所有手工操作都在命令行中加以自动化。在理想情况下，自动化工具应该能够在非生产环境下由非运营人员使用。
1.4.2 DevOps介绍
在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低。与传统大规模、不频繁的发布（通常以季度或年为单位）相比，敏捷方法大大提升了发布频率（通常以天或周为单位）。与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于经常部署，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。
DevOps是Development和Operations的组合词，通常看作敏捷开发的延续，其重视软件开发人员（Dev）和IT运维技术人员（Ops）之间的沟通合作，将敏捷精神由开发阶段拓展到构建、测试、发布等过程，达到快速响应变化、交付价值的目的。DevOps依靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（WiKi、SharePoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。同时，DevOps还采用了强大的部署自动化手段以确保部署任务的可重复性、减少部署出错的可能性。
传统组织将开发、IT运营和质量保障设为各自分离的部门。部门隔离带来管理简单的同时，给软件开发整体生产链带来极大挑战——开发的内容难以完成有效测试和运维。在互联网环境下如何采用新的开发模式是一个重要的课题。对于以前的开发模式，开发和部署不需要IT支持或者QA深入的跨部门支持，而现在我们需要极其紧密的多部门协作。DevOps不是简单的开发与运维的结合，它是一套针对这几个部门间沟通与协作问题的流程和方法。
DevOps的引入对产品交付、测试、功能开发和维护产生意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间常常存在信息鸿沟：运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。
DevOps经常被描述为开发团队与运营团队之间更具协作性、更高效的关系。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能因此降低。
1.4.3 DevOps中的开发者测试
在当前环境下，基于敏捷的要求，企业不仅仅要求传统的测试人员进行测试，开发者也需要对自己的代码负责，进行一定水准的测试。开发者在本地进行测试后，应将代码提交服务器进行自动化的集成测试。相较于以往的测试，现在的开发者测试需要更多的依赖多样化的自动化测试工具，使用自动化测试来提高开发者测试的效率。自动化测试能够有效提高开发和运维的效率，开发者可以很快获得自动化测试的结果，并根据自动化测试的情况对自己的代码进行更正。
作为测试人员，简单测试工具的使用已经无法满足现阶段的需求。测试人员需要充实自己的知识库。无论是静态扫描还是动态的覆盖检测，测试人员都需要有一定的了解，并将自动化测试工具集成到现有系统之中，减轻自身压力，提高测试效率，同时也提高了开发效率。
在这个快速变化发展的时代，任何一款产品想要在市场中具备竞争力，必须能够快速适应和应对变化，并要求产品开发过程具备快速持续的高质量交付能力。而要做到快速持续的高质量交付，自动化测试必不可少。同时，自动化测试也不是用代码或者工具替代手工测试那么简单，它有了新的特点和趋势：针对不同的产品开发技术框架有着不同的自动化技术支持，针对不同的业务模式需要不同的自动化测试方案，从而使得自动化测试有着更好的可读性、更低的实现成本、更高的运行效率和更有效的覆盖率。
自动化测试工具云集，但实践自动化应避免冲动，需要重视以下几点：综合考虑项目技术栈和人员能力，采用合适的框架来实现自动化；结合测试金字塔和项目具体情况，考虑合适的测试分层，能够在底层测试覆盖的功能点一定不要放到上层的端到端测试来覆盖；自动化测试用例设计需要考虑业务价值，尽量从用户真实使用的业务流程/业务场景来设计测试用例，让自动化优先覆盖到最关键的用户场景；同等看待测试代码和开发代码，让其作为产品不可分割的一部分。
测试环境的准备在过去是一个比较麻烦和昂贵的工作，很多组织由于没有条件准备多个测试环境，导致测试只能在有限的环境下进行，从而可能遗漏一些非常重要的缺陷，总之测试的成本和代价很高。随着云技术的发展，多个测试环境不再需要大量昂贵的硬件设备来支持，加上以Docker为典范的容器技术生态系统也在逐步成长和成熟，创建和复制测试环境变得简单多了，成本也大大降低。
另外是大量开源工具的出现，这些工具往往都是轻量级的，简单易用，相对于那些重量级的昂贵的测试工具更容易被人们接受。测试工作有了这些开源工具的帮助将更加全面、真实地覆盖到要测试的平台、环境和数据，将加快测试速度、降低测试成本。更重要的一点，有了这些工具，测试人员能够腾出更多的时间来做测试设计和探索性测试等更有意思的事情，使得测试工作变得更加有趣。在企业级应用中，对组件进行良好的测试至关重要，尤其是对于服务的分离和自动化部署这两个关系到微服务架构是否成功的关键因素，我们更需要合适的工具来对其进行测试。