一、测试在业务中的种种杂谈

📅 2026/7/9 5:31:14
一、测试在业务中的种种杂谈
1、角色和定位先说个人结论业务质量体系的建设者和落地者。通常我们测试工作中大部分时间在做什么工作需求评审、技术评审、用例设计与编写、用例执行、特定场景压测、专项测试、发布上线等等时至今日大部分的测试同学基本实在工作中做这些事情但是企业更多时候其实测试去做更多的事情所以我们看到一些招聘要求上不仅要你会测试的基本功还会顺带一些项目流程方向、项目主导与推进方向、效率工程方向、风险预防方向的要求。这样总会觉得测试怎么要做这么多事我只是一个小测试而已如果这样想那么测试同学很容易陷入进去当前得到瓶颈。我们来看看传统测试模式的局限性在哪里很早以前我们测试一个业务需求可能对业务的技术结构不了解对业务需求也没有更深层次的理解更没有对历史迭代版本的经验沉淀功能也没那么复杂于是一直在测试设计、执行、回归这个循环里如果功能简单、时间充裕这样其实天下太平测试覆盖基本不会出问题。后来敏捷迭代来了产品体量上来了问题也越来越多了我们原有的那一套测试流程与体系好像不够用了我们会发现流程中各种各样的问题敏捷模式下迭代节奏太快了开发编码质量越来越差了测试覆盖不全了线上总是报一些各种各样的问题产品需求prd越来越抽象了比毛坯房还毛坯需求工期都排好了总是有一些临时需求加进来打乱原有计划等等时间一长问题越来越多越来越复杂难受的总是下游的测试复盘会越来越多了甩锅现象也越来越严重了。。我们跟PMO去申诉相关问题他说你给出相关的字据记录存档描述下问题你又不知道怎么说了。回到正题为什么说当今测试的角色更需要像是质量体系的主人因为你不仅仅在做质量保障工作也在做风险防控识别也在做迭代流程规范也像是部门协作的胶水。如果你觉得我做测试工作执行就行了那其实局限性就在于你不会提前把缺陷提前拦截在更早的阶段缺陷都是写出来的编码缺陷、产品漏洞、特殊场景如果在很早的阶段没人关注这些那最后导致的情况就是在测试执行阶段各种各样的问题、不断加大的工作量让你手无足措、防不胜防然后质量复盘会上测试要背锅然后话语权越来越低下但是明明当初如果能提前介入如果能提前预判到这些地方可能会有问题如果大家都按照约定的规范来很多问题都不应该出现的但是没有如果了。2、全阶段保障质量重新梳理一下测试除了做最开始的测试执行工作还能做哪些工作呢又或者说测试如何在整个项目迭代流程中保障产品质量呢我直接说出一下我的看法那就是扩大宽度和深度我们先简单把迭代流程分为几个阶段需求阶段、设计阶段、执行阶段、验收发布阶段、线上监控阶段测试大部分时间都在测试执行阶段扩大宽度的意思就是五个阶段测试都可以介入并且发挥作用就是做好合理的测试左移和右移如果你对业务很熟悉熟悉程度不比产品差而且是产品的忠实用户那么在需求阶段你可以提出需求不合理、有冲突的地方可以补充场景的异常边界场景可以挖掘出隐形的需求场景在需求会上直接跟产品说建议他补全如果你对编程语言、设计模式有了解对历史迭代总结都铭记于心那么你在设计阶段可以积极参与开发的技术评审会了解一些逻辑实现、数据存储在用例编写和评审的时候补全高质量高覆盖的测试用例如果你对项目流程规范有心得、对协同合作有经验那么在执行、验收、发布阶段你可以清楚的知道什么节点应该做什么事情、跟谁沟通什么事宜、同步什么内容如果你也是自研产品用户的一员那么在项目上线之后你可以跟众多用户一样去深度体验一下新功能的上线扩大深度的意思就是做好测试垂直领域的强化与加深测试在实际业务中的具体工作内容无非就两点质量保障与效率提升通俗一点就是你怎么把事情做好、什么把事情快速做好那么我们可以提升的方向就多了完善知识库、用例库总结历史问题总结通用场景和用例模板把业务理解敏感度训练到极致测试手段的丰富我们把可行的自动化测试、测试平台开发、Ai智能体应用都用上有些比较难的执行工作、或者重复执行工作我们通过技术手段去帮我们做测试效率提升以前总是手动一条一条执行这样太慢了那么我们是否可以把用例高效精炼一下又或者说通过技术手段帮我们去做。总结来看测试工程师可以在宽度和深度上去探索优化来全阶段保障业务质量。3、测试应该具备哪些能力品质我这里分为硬能力和软能力硬能力如下测试设计能力与技术能力测试基本理论用例设计编写测试工具编程能力设计模式专项测试ai能力ci/cd等质量思维、产品业务敏感度思维发散度业务敏感度用户思维场景化思考理解能力等风险防控与应急对于一些高风险、高频率的功能场景能否比较准确预判到问题存在紧急问题出现了怎么处理等流程规范制定与落地提测标准制定冒烟测试通过标准制定发布标准制定上下游交付标准事故评级与方案枚举等软能力沟通协作能力好好说话认真说话准确说话靠谱说话不多阐述职业素养与责任感分内工作做好是自己的问题承认不是自己的问题不要帮别人擦屁股进阶发展与时代趋势关注一下自己本身的未来发展和行业的未来发展