51Testing软件测试论坛

标题: 从软件测试行业发展，漫谈测试工程师职业发展之路 [打印本页]

作者: lsekfe 时间: 2021-4-7 09:45
标题: 从软件测试行业发展，漫谈测试工程师职业发展之路
软件测试行业供需现状　　
随着敏捷、DevOps等开发模式的引入以及大数据治理与应用、人工智能机器学习与深度学习的应用的发展、软件交付周期逐渐缩短、技术复杂度不断提升对测试人员质量保障与效率提升等方面提出了越来越高的要求。因此，对人员的要求也是在不断提高的，一方面响应基础功能需求的手工测试人员基本饱和，另一方面懂测试的测试开发面试达标者比例过低。
　　软件测试行业的发展现状
　　通过之前对近几年《软件测试行业现状报告》的解读，以及结合对当下软件测试左移与右移思考，总结了以下几点：
　　测试人员对需求分析的投入在逐渐增大，逐渐注重用户反馈问题的分析，更关注用户体验。
　　敏捷和类敏捷型项目已经占到了已经极高的百分比。DevOps模式的使用已经持续数年稳定增长，正在成为软件交付的最佳模式。同时类瀑布开发模式比重逐渐降低。
　　较去年，自动化测试技术比例基本保持在一个高占比的状态。不了解自动化的越来越少。同时发现越来越多的测试人员将自动化技术应用于日志和数据分析、综合监测。
　　敏捷及DevOps模式的应用，对测试人员提出了不同于以往的要求，以前测试基本上都在开发阶段之后和产品上线之前完成，使得测试人员在开发阶段之前加大了对需求分析等测试分析和设计、同时不断提高自动化测试技术应用，促进研发内建质量。（测试左移）
　　随着业务、用户对产品质量提出更高的要求，以及测试开发技术发展与应用，促使测试技术多样化发展，如，日志和数据分析、质量运营、服务监测等。（测试右移）
　　同时，敏捷一直强调“团队为质量负责”，测试不再是测试人员的专属，这里我们需要重新思考下，测试的价值如何更好的体现——如何提高测试效率。
　　DevOps模式更是对测试、尤其是自动化测试、编码能力提出了更高的要求。
　功能测试人员发展的局限性
　　一方面功能测试的深度广度的潜在延伸性很强，另一方面想突破传统功能测试思维的确很难。在软件测试左移的思想中，测试人员对需求分析的投入在逐渐增大，这里的难点就是如何突破传统认知的测试设计深度、广度问题。
　　大多数功能测试人员，半年工作经验可以基本的了解软件测试相关流程，但因专注于功能需求的分析、验证、容易出现忽略功能需求背后的业务需求、用户需求，对产品整体的质量把握不到位，容易出现得此失彼的问题，也难以将功能测试做成闭环。
　　功能测试的深度和广度的延伸性不仅仅体现了功能需求本身，还包括产品架构设计、开发技术栈、服务内容与模式、用户群体等等。
　　我们清楚的认识到，一个优秀的测试工程师，应该做到：
　　懂业务：能够站在用户角度理解业务、用户需求，能扎实通过测试设计的保证业务质量。
　　懂技术：具备技术解决方案思维和能力，提升产品质量和测试效率。
　　懂架构：具备产品架构的基本认识和识别架构设计中的质量、性能风险，保证产品需求和实现能够满足用户需求及产品发展需要。
　　我们不难得出测试逐渐向测试开发过渡已经是一种显在的发展趋势，无论我们决定将来走技术路线还是管理路线。
　　但具备了一定的开发能力并不等同于能够做好测试，之所有测试开发成为一种趋势，是因为测试人员在具备优秀测试设计等业务测试能力的基础上，若同时具备一定开发能力和技术解决思维，能够更好的从质量、效率、风险、成本之间寻求一种平衡。
　　自动化测试方向认知的片面性
　　谈到自动化测试，很多人认为这是测试人员职业发展的一个方向，但对这个方向的认识并不都是充分的，比如，当面试的时候问到自己设计的自动化测试用例的优缺点，自动化测试框架选择的合理性体现在哪里时，很难有清晰的回答。
　　如何围绕产品质量提高测试效率，不仅仅是将手工用例转变为自动化用例这么片面，其中还包含了自动化测试策略、框架选型，自动化的可维护性、可扩展性、可持续性等方面的诸多考虑，一个难以维护、扩展的自动化测试实践，是失败的。
　　“围绕产品质量，提升测试效率，通过不断的技术创新、应用，不断提高测试整体流程能力（单位时间能够提供多少服务）。”假如一个测试团队的人数相对固定、测试时间充足，他提升效率的目的又是什么呢？
　　从这种角度来思考，个人认为测试效率提升的根本意义在于：
　　做更多的有价值的测试（测试左移或右移的投入）
　　实现真正的缩减成本（减少人力投入）。
　　拥抱变化，适应开发模式的转变，比如类敏捷、DevOps模式下的频繁迭代、持续部署。
　　测试职业发展
　　测试职业发展方向大致分为管理方向及技术方向。无论我们决定将来走技术路线还是管理路线。都需要注意测试逐渐向测试开发过渡已经是一种显在的发展趋势，这样就要求我们需要具备一定的测试开发能力和技术解决思维。
　　虽然测试开发逐渐成为测试人员的基本能能力要求，但不要进入一味追求开发能力。具备了一定的开发能力并不等同于能够做好测试，之所有测试开发成为一种趋势，是因为测试人员在具备优秀测试设计等业务测试能力的基础上，若同时具备一定开发能力和技术思维，能够更好的从质量、效率、风险、成本之间寻求一种平衡。

　　培养全面的测试能力
　　懂业务：能够站在用户角度理解业务、用户需求，能扎实通过测试设计的保证业务质量。
　　懂技术：具备技术解决方案思维和能力，提升产品质量和测试效率。
　　懂架构：具备产品架构的基本认识和识别架构设计中的质量、性能风险，保证产品需求和实现能够满足用户需求及产品发展需要。
　　建立良好的质量意识
　　我们清楚一切测试活动都是围绕用户、业务需求保障产品质量而开展，而保障产品质量的核心是测试设计，而非测试技术，测试技术大多仅是解决测试设计执行的可行性、效率问题。
　　拓展测试广度与深度
　　随着类敏捷、DevOps模式的发展、软件交付周期逐渐缩短、技术复杂度不断提升对测试人员质量保障与效率提升等方面提出了越来越高的要求。

　　在敏捷开发模型的软件生命周期中，我们通过不断快速的迭代，以使其最大限度地符合客户对系统的需求。此时测试的关注点基本停留在开发阶段，以保证产品达到上线标准。引入DevOps之后，我们不仅要关注产品的质量是否达标，还需要使产品或功能价值预期得到及时的验证。
　　因此，我们不仅要将测试左移，还要进行测试右移，通过监控产品在生产环境的运作情况，来验证其价值并获得反馈，从而持续改进。我们通过以下三个方面来了解一下测试左移与右移。
　　1.新功能是什么？
　　在开发环境，我们开发新功能，并且通过测试保证其达到产品验收标准。
　　这就要求从产品生命周期开始时，各个角色（测试、开发、产品负责人等）对业务场景、用户需求达成一致的认识，从而使其从需求到最后的测试验证，进行高度的协作和沟通，最后交付最有价值的功能。同时测试人员能够根据用户需求进行需求分析，发现产品前期设计是否存在问题或者补充产品设计。同时，通过及早引入自动化测试，协助研发内建质量。
　　这里体现出了测试左移的核心思想。
　　2.新功能是否价值？
　　我们将新功能部署到生产环境以后，接下来就应该衡量业务价值是否达到预期。
　　通过对用户日志或数据进行分析感知用户的行为变化。比如：比如页面新增了一个导出功能，发布上线后，发现用户的点击导出按钮的次数几乎为零，很可能是因为用户根本不需要这个功能，或者导出按钮的颜色、位置等易用性（产品质量属性之一）原因导致用户没有使用。这时候需要思考如何对该功能进行调整。如果一个功能没有使用或者没有给产品带来显著的价值，在功能正确性和性能验证上投入大量精力又有什么意义呢？
　　这里体现出了测试右移的思想。
　　3.新功能线上是否是可靠的？
　　测试大多数情况只能覆盖已知的测试场景。产品部署在用户环境运行的过程中，可能会由于某些不确定性因素（比如数据量突然陡增，用户访问突然陡增、网络不稳定或者数据盘损坏等等）导致产品或功能失效，由于其不确定性使得测试人员很难模拟测试场景，因此产品线上质量运营需要通过监控的手段开展，通常我们需要监控两种特性：可用性、性能。
　　通过持续获取用户日志或数据，分析产品性能、程序进程等稳定性、产品质量健康度进行问题报警、预警。同时增加用户沟通反馈渠道，获取用户反馈从而及时调整。除此之外，这一点也充分体现了Dev、 QA、Ops的协作，像监控等原本只能Ops做的事，现在Dev或QA一样可以做。
　　这里也体现出了测试右移的思想。
　　提升测试核心竞争力
　　个人的核心竞争力与所在行业发展的趋势，以及随着行业及相关行业的发展对从业者提出的要求应该是有着直接关系的。
　　所以我们需要以发展的眼光，来看未来测试行业会对我们提出哪些要求，进而驱动自己适应未来发展要求。
　　什么是核心竞争力，我个人认为核心竞争力一定程度可以理解为不可替代性，所做的事情或者所具备的能力是否可以能被大部分人替代，这就是是否具备核心竞争力的一个重要体现。
　　相对于测试而言，核心竞争力可以是在某一领域的专业性深度足够深。
　　比如性能测试，曾在一次互联网测试开发大会上，看见过某位前辈讲到过的一个案例：在定位某个性能问题时，挖掘到操作系统内核的深度，并且发现是因操作系统内核缺陷导致的性能风险，这个定位问题的过程及结果就是测试专业性深度的体现。
　　也可以是具备一定的测试广度，并且能够根据不同场景灵活适当的将其融合到一起，做到质量、成本、效率、风险的平衡。
　　比如产品迭代初期，一方面产品初步成形，需求变更频繁、功能稳定性差，同时受到客户和市场压力，往往迭代时间紧张，此时对于测试要解决的就是质量与效率平衡问题，自然而然想到自动化测试，然而这个时候自动化是不是合适的呢，显然自动化初期投入到项目的确能起到效率提升的目的，但随着迭代发展，会出现什么情况？需求变更引入的自动化维护成本，如果此时业务测试不具备测试开发能力，那么这个维护成本将变的更高，本来就项目时间紧张，自动化维护工作自然而然就变的力不从心，由此，一两个版本迭代之后，自动化测试就慢慢淡出了视野之外。一般来讲，需求度量一般要从最原始的需求开始，比如迭代初期项目时间紧，考虑到版本稳定性，通常不会选择自动化测试（除非自动化的开展或重构成本非常的低），而是从需求优先级、质量目标、测试覆盖等角度，对测试广度、测试深度进行测试策略设计，优先保障核心功能质量。这也是很多公司对测试开发的要求是首先要懂测试、然后懂开发的原因，能够对业务测试遇到的问题提出适合的技术解决方案，避免盲目开展自动化、工具开发，导致“药不对症”。
　　虽然我认为核心竞争力一定程度可以理解为不可替代性，但并不意味着封闭，反而要有更加的开放思想，帮助团队测试人员提升基础能力水平，提升他们对测试的理解和认识，可以使得遇到更多志同道合的人。进一步思考测试技术能力的水平赋能和流程化能力建设，这对我们的发展有着更大的帮助，也是我们价值的重要体现。
　　同时，需要不断的了解一下当下比较主流的开发、测试思想、模式，如DevOps开发模式、测试左移与右移思想等等；测试应用领域，如人工智能测试；测试技术，如数据、接口的自动化等等，使得我们对测试的认识具有一定的前瞻性。

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