51Testing软件测试论坛

标题: 最近十年，软件测试领域有什么重要进展？ [打印本页]

作者: lsekfe 时间: 2022-6-2 09:27
标题: 最近十年，软件测试领域有什么重要进展？
有道是：“观史知今当思进退，读书养志可识春秋”。
　　列数最近十年的重要进展，其目的还是要我们带着发展的眼光，来预测未来几年测试领域的发展，提前做好准备。
　　所以为了让大家阅读此文后有尽可能强烈的获得感，本文行文结构如下：
　　一、回顾软件测试发展的五个重要时期：
　　·1957之前 - 以调试为主：独自承担需求分析，设计，研发，调试，也就是Debug。
　　· 1957-1978 - 以证明为主：确保程序解决它该解决的问题，证明软件是否符合需求，证明确实是有缺陷的。
　　· 1979-1982 - 以破坏为主：在符合需求的情况下，通过异常测试的方法，明确软件应该做什么，不应该做什么。
　　· 1983-1987 - 以评估为主：分析、评审、验证、确认。由测试评估产品软件是否符合需求质量。形成目前已知岗位雏形，形成独立的学科，制定软件测试国际标准。
　　· 1988-至今 - 以预防为主：预防问题发生，从需求开始介入，贯穿软件开发生命周期。
　　二、最近10年，测试领域的重要进展
　　软件测试行业发展，受益于经济转型，产业升级，软件基础平台同云计算大数据相结合，测试行业在我国正处于高速发展成长期。
　　最近十年测试领域用一句话总结：软件测试职位的发展逐渐细化。
　　· 08到12年国内已经有的测试岗位分别是：功能测试、性能测试、安全测试、测试经理、测试总监。随着技术的发展，工种也变得越来越细。
　　· 12到13年开始出现大数据测试工程师。
　　· 14年多了python自动化测试工程师，及测试架构师。
　　· 15年至今出现java自动化测试工程师和测试开发工程师。
　　相对来讲不同的职位对应的薪资水平也不一样，目前对应平均薪资水平如下图：
[attach]138268[/attach]
　随着互联网逐渐渗透到国企，加上最近10年物联网的发展，软件测试在整个研发体系中，担负的责任越来越大，越来越被重视。
　　那么这十年软件测试领域有什么重要的进展呢？
　　我的结论：软件测试对整个产研体系内，协作效率的提升及质量内建。
　　为什么会得出上述结论，讲述下依据：
　　1、从个人过往的经验看，传统测试下，产、研、测、维，曾出现严重的部门墙
　　以传统手工测试为例：相对于整个测试体系来讲是最基础的，同时也是最独立的。在整个产研团队中，都保持着特立独行的节奏。
　　但在产研进行敏捷研发的今天，通过手工进行测试已经面临较为严重的效率瓶颈。比如，我刚从事测试工作时，测试团队常因为排期不同步，不断与产品、研发冲突。
　　因为测试时间内，长期被临时插入的需求占用测试时间，上线后又面临持续复盘。导致测试周期长，发布频率低。比如手工测试过程中，往往研发5天开发量，到测试团队，测了半个月还测不完。
　　长周期下，又会偶发需求调整，或者紧急插入新需求，导致无人力支持大面积回归，上线事故率高，潜在风险大，项目风险不可控。
　　事故方界定不清晰，事故无法追责，导致产研各个团队中相互不信任加大。在下一轮需求展开时，往往在需求评审中进行扯皮，旧事重提，实施阶段各团队之间相互掣肘。
　　当时我们总结经验教训后，采取如下措施：
　　1）进行各部门团队建设，明确测试范围，测试分工。
　　2）增加绩效考核标准，量化工作产出。
　　3）完善准入准出规则，建立一整套提测流程，制定统一化的文档编辑标准。
　　4）每天编写产出内容文档，流程中增加更多审批节点。
[attach]138269[/attach]
以上措施就解决问题了吗？并没有，还衍生出了新问题。
　　举例“增加绩效考核标准，量化工作产出”这个环节：规定测试团队个人，一天需要写多少条case，执行多少条case。还要求一次迭代至少要发现几个bug为达标，发现几个优先级高的bug为优秀。线上事故追责到个人，每次发版闹的人心惶惶。
　　而在这一系列繁文缛节的流程背后，看似清晰有据可查，实际导致工作内容极其繁琐，产研团队之间嫌隙加大。
　　产研团队彼此只追求考核目标，只关注需求文档本身，而忽略了实际业务，导致无共同目标，无效沟通增加。
　　遇到事故，彼此在复盘中相互甩锅，互相指责，每次都像“律政俏佳人”一般在打官司。其实在无形之中不断挑起产品、研发、测试、运维部门的对立，形成部门墙。
　　2、后来敏捷开发流行，传统测试团队曾是整个产研团队中的短板

[attach]138270[/attach]
而逐渐流行的敏捷开发，导致研发迭代发布速度持续加快。但测试无法让手工测试效率也加快。因为对于测试团队来讲，每次迭代不仅要保证本次迭代功能质量，还要至少回归相关联的模块。
　　提高测试效率，测试团队只有不断的加人。但加人不代表能够提高效率，也无法有效的保证质量。从而测试团队成为整个产研团队中的短板。
　　随着业务高速增长、团队快速扩张的情况下，质量问题极易被放大化，如果不能及时得到处理，后续解决成本会越来越高。
　　如何有效解决测试效率低的问题，成为了当时测试领域的重点及难点。
　　3、配合敏捷开发，测试团队引入测试敏捷化思想
　　通过敏捷开发的成功实践，测试团队也引入了敏捷测试的概念，目的是为解决以下目标：
　　· 测试不再是独立于整个研发体系，而要和产、研融合，成体系化建设；
　　· 建立和测试密切相关的：质量目标、流程规范、测试策略、实践标准等；
　　· 做好缺陷分析，分析客观原因即可，无需追责到人；
　　· 测试人员应尽早的介入全流程；
　　· 敏捷开发模式下质量的保证需求
[attach]138271[/attach]
为解决全生命周期流程的构建和执行能力，进行全阶段的持续测试，测试团队需要通过：自动化测试、持续交付、DevOps来实现。
　　敏捷测试理念搭配自动化、持续交付、DevOps 落地分别解决的问题是：
　　通过自动化解决迭代速度；
　　通过持续集成去交付；
　　通过DevOps来进行部署；
　　自动化、持续交付、DevOps 落地后分别需要达成的测试目标是：
　　全生命周期流程的构建和执行能力；
　　使用各种自动化测试框架，同持续集成流水线相互关联；
　　实时监控平台的搭建，对质量风险和严重缺陷进行智能预测和告警；
　　4、为实现敏捷测试，当前中大型企业普遍流行的测试团队体系介绍
　　1）思想上摒弃工作量化
　　通过价值观体系的培养，将各个团队通过“组织”的结构形式，使彼此高效率协同。
　　2）明确整个产研的质量目标，并让全体成员知晓形成统一共识
　　以质量目标，驱动各个职能部门间的合作，增强全员对质量负责的意识。做好缺陷的预防。

[attach]138272[/attach]
　3）质量保证团队建设及组成
　　· 外包测试团队：负责基础功能的测试；
　　· 测试团队：手工测试、自动化测试、持续集成；
　　· 测试开发团队：一种是跟业务的测试负责测试中台化，另一种利用测试技术赋能测试与研发团队；
　　· 外部测试服务：提供对外的测试服务。
　　4）质量保证团队的核心业务：
　　· 前台验收测试：Web、App、Gui兼容；
　　· 前台用户体验测试：性能、安全、电量、流量、稳定性；
　　· 中后台功能测试：性能、安全；
　　· 流程管理：持续集成、持续交付、DevOps；
　　· 质量分析：监控平台、数据分析平台、Ai辅助平台。
　　三、测试领域可预见的未来是怎样的？
　　在可预见的未来，产研团队依旧遵循
　　1）从产品提需求，开发实现，测试验证，运维部署原则。
　　2）继续打破传统软件研发体系中的部门墙，让整个流水线更顺畅。
　　每隔几年，产研团队会围绕产、研、测、维几个环节，在不断的摸索实践中，解决各自业务的痛点难点，拿出最优解，从形成新的概念和理念。而其中的本质上也就是要打通产、研、测、维这几个环节。
　　所以，如何使测试团队提高测试效率，测试质量，将成为了测试领域重中之重。
[attach]138273[/attach]
在持续集成、敏捷、DevOps时代下，对测试人才的标准也将越来越高。
　　这也是为什么近些年测试领域职位，不断被细化的原因。
　　这也是手工测试在当前，虽保持着独立化，但同时也在产研核心中被边缘化，面临被淘汰的命运。
　　未来，只有掌握自动化测试，才能进入核心的研发流程中，牢牢占据敏捷测试这一环。只有这样才能完成整个研发流程的打通。
　　所以在当前，对于测试人员来讲，学习自动化知识，转身走向自动化测试越来越重要。
　　四、面对测试趋势，我们应该如何准备？
　　毫无疑问，每个测试人员，都要立即转身奔向自动化测试，不要犹豫。
　　若你是功能测试（也叫手工测试），应该立即学习编程语言，java或者python，学习接口测试，UI自动化测试，性能测试，甚至是测试开发；不然你离职后，还只会功能测试，那就很难再重新找到工作（不相信，你作为非应届生可以投简历试试）。
　　若你是测试新人，千万不要止步于功能测试，还要继续学习编程知识（python或Java），学习接口、学习UI自动化....

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)