简单地说，在传统的瀑布模型时代，大家都挺慢，系统需求也不会有太多变化，单纯美好的年代里，我们有足够的时间来准备详尽的测试计划、测试用例，慢慢地测。但如果在敏捷迭代的短频快开发模式下，事情就变得不那么美好了。
由于敏捷开发模式下，每个迭代周期最终都要开发一个完整的可用版本，所以在每一个迭代周期内，软件测试工程师都要进行完备的测试，以确保发布出去的软件产品是没有问题的。但每个迭代版本的周期又比过去的瀑布模式开发缩短了很多，这意味着相同时间内，你发布的次数增多了。而每一次发布版本都意味着你要快速回归所有重要的测试场景，这通常来说工作量非常巨大。
所以，测试不能等着编码完成之后再去完成了，那怎么办呢？
这时，我们提出了测试左移和测试右移的概念。所谓测试左移，即测试往需求方向移动，介入到需求、设计、编码、集成过程中去，提前寻找可能存在的问题。而测试右移，则是指测试加入到发布后的流程中去，通过生产环境监控得来的各种数据去分析潜在的缺陷。
所以，现在质量已经不再单单是软件测试工程师的责任了，而是团队所有角色（开发、质量保证人员、技术运维）都要对产品质量负责。
· Devops
最近几年业界流行的所谓 Devops（开发运维）其实就是开发、质量保证人员、运维三个角色的交集。Devops 旨在通过自动化的“软件交付”和“架构变更”的流程，来解决不同角色之间合作的流畅度，以及把软件交付的构建、测试、发布变得更加快捷、频繁和可靠，充分适应现代互联网产品短频快的特点。
Devops 在提高了公司的研发效率的情况下，也给测试人员带来又一个挑战：即如何在持续集成、持续部署的模式下保障质量？
对于软件测试来说，如何把测试活动，特别是自动进行的测试活动无缝融合到公司的持续集成、持续部署框架下，将是一个非常大的挑战，也是未来大家在软件测试职业生涯上再走远一些，将要面对的问题。
· 微服务
微服务这词现在在 IT 行业非常火，几乎是大厂产品的标配了。怎么理解微服务呢？
它也是一种产品实现模式，虽然微服务实现起来比较复杂，但理解起来相对来说还是比较容易的。你可以理解为，传统的开发是基于单体应用，就是不管功能再多，都是作为一个应用整体来进行构建和部署的。虽然有分层，但仍然是一个整体。而微服务模式下会将应用进行拆分，拆分成更小的独立服务，并使它们可以单独构建和部署。
微服务的引进提升了开发效率，降低了发布时间，但也带来了新的挑战：由于各个微服务常由不同的团队负责微服务的引进提升了开发效率，降低了发布时间，但也带来了新的挑战：由于各个微服务常由不同的团队负责契约测试”也就相应产生了。
还有，相较于传统单体应用，微服务的测试也更加复杂。仅从代码打包部署这件事儿来说，在单体应用里，不太会出现使用错测试包的情况，但是在微服务里，这个情况可能会发生。
单体应用，一个版本就对应一个代码分支；而使用微服务，每个微服务通常对应不同的代码分支。这就意味着在测试微服务时，测试不仅要关注你测试的微服务是否版本部署正确，还要检查其依赖的其他微服务的部署分支，查看其他微服务的分支是不是也部署正确。
除此之外，微服务的采用，也让我们的技术栈更为繁多、复杂，比如：
因为我解决微服务间复杂的通信和消息传递问题，引入了 RabbitMQ、RocketMQ、Kafka 各种消息中间件;
因为多个微服务的独立部署导致的环境依赖问题，引入了容器化技术 Docker;
容器越来越多，要解决其管理和维护问题而引入了 Kubernetes;
为简化故障定位问题，引入 ELK（Elasticsearch + Logstash + Kibana）;
上线后，要对系统运行情况进行监控，因而引入了 Prometheus 与 Grafana 等。
以上“新”技术的引入，是为了不断应对软件开发演变中带来的各项需求和问题，解决了旧问题的同时，也为测试带来了新挑战。
面对这些挑战，软件测试在快速演进的同时，也在裹挟前行，寻找破局之道。那么这个破局之道是什么呢？
答案就是测试开发工程师。
正如前文所述，软件的发布动作变得越来越频繁，以往靠大量手工功能测试+少量主流程自动化测试+部分回归测试来保障质量的做法，变得越来越不现实。自动化测试，特别是不同层次的自动化测试在整个测试活动中的占比，正逐渐成为影响软件发布质量的关键。这也就是测试开发在近年来越来越受追捧的原因。
这么多的自动化测试用例，需不需要维护？如何维护？如何将自动化测试融入公司的持续集成流程中并自动触发运行？这些都是测试开发首要关注的问题，可以预料的是，随着交付频率的加快，测试开发会变成软件测试人员的基本技能。
所以，为什么我们一开始就说现在传统的点点点工程师已经没有出路，测试开发工程师才有未来，就是这个原因。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
