有道是：“观史知今当思进退，读书养志可识春秋”。
列数最近十年的重要进展，其目的还是要我们带着发展的眼光，来预测未来几年测试领域的发展，提前做好准备。
所以为了让大家阅读此文后有尽可能强烈的获得感，本文行文结构如下：
一、回顾软件测试发展的五个重要时期：
·1957之前 - 以调试为主：独自承担需求分析，设计，研发，调试，也就是Debug。
· 1957-1978 - 以证明为主：确保程序解决它该解决的问题，证明软件是否符合需求，证明确实是有缺陷的。
· 1979-1982 - 以破坏为主：在符合需求的情况下，通过异常测试的方法，明确软件应该做什么，不应该做什么。
· 1983-1987 - 以评估为主：分析、评审、验证、确认。由测试评估产品软件是否符合需求质量。形成目前已知岗位雏形，形成独立的学科，制定软件测试国际标准。
· 1988-至今 - 以预防为主：预防问题发生，从需求开始介入，贯穿软件开发生命周期。
二、最近10年，测试领域的重要进展
最近十年测试领域用一句话总结：软件测试职位的发展逐渐细化。
· 12到13年开始出现大数据测试工程师。
· 14年多了python自动化测试工程师，及测试架构师。
· 15年至今出现java自动化测试工程师和测试开发工程师。
相对来讲不同的职位对应的薪资水平也不一样，目前对应平均薪资水平如下图：
随着互联网逐渐渗透到国企，加上最近10年物联网的发展，软件测试在整个研发体系中，担负的责任越来越大，越来越被重视。
那么这十年软件测试领域有什么重要的进展呢？
我的结论：软件测试对整个产研体系内，协作效率的提升及质量内建。
为什么会得出上述结论，讲述下依据：
1、从个人过往的经验看，传统测试下，产、研、测、维，曾出现严重的部门墙
以传统手工测试为例：相对于整个测试体系来讲是最基础的，同时也是最独立的。在整个产研团队中，都保持着特立独行的节奏。
但在产研进行敏捷研发的今天，通过手工进行测试已经面临较为严重的效率瓶颈。比如，我刚从事测试工作时，测试团队常因为排期不同步，不断与产品、研发冲突。
因为测试时间内，长期被临时插入的需求占用测试时间，上线后又面临持续复盘。导致测试周期长，发布频率低。比如手工测试过程中，往往研发5天开发量，到测试团队，测了半个月还测不完。
长周期下，又会偶发需求调整，或者紧急插入新需求，导致无人力支持大面积回归，上线事故率高，潜在风险大，项目风险不可控。
事故方界定不清晰，事故无法追责，导致产研各个团队中相互不信任加大。在下一轮需求展开时，往往在需求评审中进行扯皮，旧事重提，实施阶段各团队之间相互掣肘。
当时我们总结经验教训后，采取如下措施：
1）进行各部门团队建设，明确测试范围，测试分工。
2）增加绩效考核标准，量化工作产出。
3）完善准入准出规则，建立一整套提测流程，制定统一化的文档编辑标准。
4）每天编写产出内容文档，流程中增加更多审批节点。
以上措施就解决问题了吗？并没有，还衍生出了新问题。
举例“增加绩效考核标准，量化工作产出”这个环节：规定测试团队个人，一天需要写多少条case，执行多少条case。还要求一次迭代至少要发现几个bug为达标，发现几个优先级高的bug为优秀。线上事故追责到个人，每次发版闹的人心惶惶。
而在这一系列繁文缛节的流程背后，看似清晰有据可查，实际导致工作内容极其繁琐，产研团队之间嫌隙加大。
产研团队彼此只追求考核目标，只关注需求文档本身，而忽略了实际业务，导致无共同目标，无效沟通增加。
遇到事故，彼此在复盘中相互甩锅，互相指责，每次都像“律政俏佳人”一般在打官司。其实在无形之中不断挑起产品、研发、测试、运维部门的对立，形成部门墙。
2、后来敏捷开发流行，传统测试团队曾是整个产研团队中的短板
而逐渐流行的敏捷开发，导致研发迭代发布速度持续加快。但测试无法让手工测试效率也加快。因为对于测试团队来讲，每次迭代不仅要保证本次迭代功能质量，还要至少回归相关联的模块。
提高测试效率，测试团队只有不断的加人。但加人不代表能够提高效率，也无法有效的保证质量。从而测试团队成为整个产研团队中的短板。
随着业务高速增长、团队快速扩张的情况下，质量问题极易被放大化，如果不能及时得到处理，后续解决成本会越来越高。
如何有效解决测试效率低的问题，成为了当时测试领域的重点及难点。
3、配合敏捷开发，测试团队引入测试敏捷化思想
通过敏捷开发的成功实践，测试团队也引入了敏捷测试的概念，目的是为解决以下目标：
· 测试不再是独立于整个研发体系，而要和产、研融合，成体系化建设；
· 建立和测试密切相关的：质量目标、流程规范、测试策略、实践标准等；
· 做好缺陷分析，分析客观原因即可，无需追责到人；
· 测试人员应尽早的介入全流程；
· 敏捷开发模式下质量的保证需求
为解决全生命周期流程的构建和执行能力，进行全阶段的持续测试，测试团队需要通过：自动化测试、持续交付、DevOps来实现。
敏捷测试理念搭配自动化、持续交付、DevOps 落地分别解决的问题是：
通过自动化解决迭代速度；
通过持续集成去交付；
通过DevOps来进行部署；
自动化、持续交付、DevOps 落地后分别需要达成的测试目标是：
全生命周期流程的构建和执行能力；
使用各种自动化测试框架，同持续集成流水线相互关联；
实时监控平台的搭建，对质量风险和严重缺陷进行智能预测和告警；
4、为实现敏捷测试，当前中大型企业普遍流行的测试团队体系介绍
1）思想上摒弃工作量化
通过价值观体系的培养，将各个团队通过“组织”的结构形式，使彼此高效率协同。
2）明确整个产研的质量目标，并让全体成员知晓形成统一共识
以质量目标，驱动各个职能部门间的合作，增强全员对质量负责的意识。做好缺陷的预防。
3）质量保证团队建设及组成
· 外包测试团队：负责基础功能的测试；
· 测试团队：手工测试、自动化测试、持续集成；
· 测试开发团队：一种是跟业务的测试负责测试中台化，另一种利用测试技术赋能测试与研发团队；
· 外部测试服务：提供对外的测试服务。
4）质量保证团队的核心业务：
· 前台验收测试：Web、App、Gui兼容；
· 前台用户体验测试：性能、安全、电量、流量、稳定性；
· 中后台功能测试：性能、安全；
· 流程管理：持续集成、持续交付、DevOps；
· 质量分析：监控平台、数据分析平台、Ai辅助平台。
三、测试领域可预见的未来是怎样的？
在可预见的未来，产研团队依旧遵循
1）从产品提需求，开发实现，测试验证，运维部署原则。
2）继续打破传统软件研发体系中的部门墙，让整个流水线更顺畅。
每隔几年，产研团队会围绕产、研、测、维几个环节，在不断的摸索实践中，解决各自业务的痛点难点，拿出最优解，从形成新的概念和理念。而其中的本质上也就是要打通产、研、测、维这几个环节。
所以，如何使测试团队提高测试效率，测试质量，将成为了测试领域重中之重。
在持续集成、敏捷、DevOps时代下，对测试人才的标准也将越来越高。
这也是为什么近些年测试领域职位，不断被细化的原因。
这也是手工测试在当前，虽保持着独立化，但同时也在产研核心中被边缘化，面临被淘汰的命运。
未来，只有掌握自动化测试，才能进入核心的研发流程中，牢牢占据敏捷测试这一环。只有这样才能完成整个研发流程的打通。
所以在当前，对于测试人员来讲，学习自动化知识，转身走向自动化测试越来越重要。
四、面对测试趋势，我们应该如何准备？
毫无疑问，每个测试人员，都要立即转身奔向自动化测试，不要犹豫。
若你是功能测试（也叫手工测试），应该立即学习编程语言，java或者python，学习接口测试，UI自动化测试，性能测试，甚至是测试开发；不然你离职后，还只会功能测试，那就很难再重新找到工作（不相信，你作为非应届生可以投简历试试）。
若你是测试新人，千万不要止步于功能测试，还要继续学习编程知识（python或Java），学习接口、学习UI自动化....
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
