关于测试工作的经验整理

一、测试的目标和价值

作为测试人员，经常被问到，测试人员存在的价值是什么？如何度量测试人员工作的绩效？等等诸如此类的问题，核心就是测试人员如何体现自己的价值。在这里我引用一篇曾经读到文章部分内容，来回答这些问题。
我们以最简单的利润模型来做解释，利润=商品价格 - 商品成本，我们追求的目标就是利润最大化。对于测试工作，商品价格 = 测试交付产品的质量，商品成本 = 测试人员的人力成本。提高利润的两条途径，一个是提高交付产品的质量，另一个是降低投入的测试人力成本，所以测试的终极目标是：0 人力成本下的高质量标准产品交付。

二、测试工作的流程与改进

根据上面的利润模型，我们为了获得更大的利润，可以从两个方面着手：
1，提高交付产品的质量。
在常见的业务迭代中，交付产品的质量如何，我们要有一个衡量的标准，而标准就涉及到指标，比如需求覆盖率、缺陷逃逸率、缺陷探测率等等。质量标准确定后，为了交付达到指定质量标准产品，我们需要对测试流程进行规划。
工作中常见的基础项目流程是：

• 需求阶段：产品提出需求，开发和测试进行需求评审，直至评审通过。
• 设计和开发阶段：开发进行项目设计和代码开发，测试进行用例设计，并且评审通过。
• 测试阶段：项目提测之后，经过测试一轮，甚至是多轮测试后，测试工作完成；
• 交付验收阶段：产品或者其他用户进行项目验收。
• 上线阶段：将项目代码部署到生产环境。

测试人员的工作流程因此产生：需求评审、用例设计、测试执行、项目上线，这是一个基础流程，主要通过手工执行，能够达到一个基础的质量标准。

那么我们可以采取哪些手段，来丰富优化我们的测试流程？

• 需求阶段。
  改进的方法：1，更早的进入用例设计。在需求初评之后，就开始进行用例设计，这个时候可以不是具体的用例，而是采用脑图类的工具，对需求进行功能分析和非功能分析，这样在需求详评时我们能更有的放矢。2，建立检查清单。检查清单包含几部分内容：需求功能的影响范围（功能涉及的上下游等）、涉及的前端模块（页面功能、公共组件等）、涉及的后端模块（接口、定时任务、中间件、数据库等）、常见问题汇总（测试积累、用户反馈积累等）等内容，依据工作中的经验总结，不断丰富分析思考问题的角度和内容，这份清单不仅在需求阶段，在设计开发阶段依然有所作用。

• 设计和开发阶段。
  改进的方法：1，了解项目使用的框架和技术。通过了解系统使用的框架和相关技术，我们能更好的理解系统的运转，也能够为我们用例的设计提供更多的思路，测试将从黑盒变为灰盒。2，加入 code diff。通过对比本次项目更新的代码，更好的确认改动范围和测试范围。比 code diff 更进一步，是依据改动代码进行调用链分析，更准确的确定代码变更影响范围。3，在设计评审阶段，需求中的非功能需求和开发代码变更带来的技术需求，设计相应的测试方案，比如开发相应的测试脚本或者工具，并在测试阶段之前完成。4，用例设计，我们可以总结针对某种测试元素、某种功能、某种组件的用例样板，最终形成一个用例库，并且不断的丰富其内容，如此，在用例设计阶段就可以参考用例库中的用例，完善项目的业务用例。

• 测试阶段
  改进的方法：1，进行 ET 测试。ET 测试主要是根据经验，对可能的影响点进行验证，尽量将整个项目组的，包括产品和开发，一起进行 ET 测试，如果能有业务人员参与就更好。2，进行回归测试。回归测试主要回归业务主流功能和其他这次改动可能影响的以前运行正常的系统功能。3，如果测试阶段分为多轮测试，可将测试人员负责的业务进行交叉互换，以期发现更多的问题。

• 上线之后
  改进的方法：1，跟踪线上业务反馈，对业务反馈的问题进行归类，比如是用例覆盖不全、产品设计问题、异常边界覆盖不全、三方问题等等，对这些问题进行分类分析，组织多方人员复盘，提出改进方案，指导和优化我们的工作流程。2，建立线上监控预警机制，如果有线上报错，能够推送消息通知开发和测试人员，尽量抢在业务人员告警之前修复问题，即使没能够立即修复，也能在业务反馈至技术团队时，能够迅速做出反馈。

通过上面的一些措施，逐步优化我们的测试流程，提高我们的业务迭代产品质量标准。当然，在不同领域还有其他不同的标准和不同的措施，比如性能测试、服务器测试、兼容性测试、混沌工程等等。

2，降低人力成本
降低人力成本，主要是自动化技术的应用，把人的活儿交给机器来做，可以从如下两个方面来思考：

• 在人力不变的情况下，增加测试的宽度和深度。
• 在质量标准不变的情况下，降低人力的成本。

增加测试宽度和深度，比如：UI 自动化测试、代码静态检查、代码覆盖率、精准测试等等。
降低人力的成本，比如：自动化回归测试、根据需求开发测试脚本和工具、代码集成部署自动化、线上监控自动预警、性能测试基线任务、冒烟用例自动生成等。
其中自动化的回归测试推荐作为首选。
根据自身工作中的情况，理清有哪些方面可以实施自动化、实施自动化的优先级、自动化的技术路线等。

三、测试管理的思考

一线的测试管理包括项目管理和测试人员的管理。
1，业务上的项目管理
我们经常遇到项目时间比较紧张的情况，比如项目时间倒排。这种情况，我们会遇到多种问题，比如需求文档内容不明确、代码提测质量不高、没有充足的时间进行用例设计等等。对于比较紧急的情况，就需要测试人员采取更加主动的措施，例如：

• 找产品明确需求功能点，进行需求的功能点的拆分，划分需求功能点的优先级和风险等级。
• 开发的功能是否可以根据优先级和风险等级分批提测，开发一部分、提测一部分、测试一部分。
• 对于提测质量差的功能，协助开发修正功能，通过冒烟测试。
• 三方尽量面对面沟通，快速响应，避免文字沟通带来的理解歧义，进而产生或加深矛盾。
• 对于口头沟通的结论，要有文字记录，做到所有的需求和结论可追溯，尤其是记性不好的。

团队的负责人，对未来的需求安排、开发和测试的人力安排心中有数，避免事到临头手忙脚乱。
对于我们遇到的细碎的优化迭代需求，尽量让产品合并在一个优化版本中，减少上线频次，同时人力也更好安排。

2，测试人员的管理
对测试人员的管理主要是持续不断的对测试人员的有效性进行评估。可以从用例设计、缺陷有效率、线上故障率、项目推进、对接人员的三方评价、个人评价等方面进行评估，当然考虑线上故障率的时候，要考虑负责的项目的复杂程度。

考虑测试人员能力梯队建设。结合项目组和测试组工作需要，参考个人意愿，对测试人员的技术能力路线做出规划，可以是多面手，但也要有所侧重，比如有的发展 APP 端的技术、有的发展服务端的技术、有的发展工具开发、有的发展性能测试等等，这样整个测试组的能力饼图就会更全面，能够适应的任务也就越多。如果是从 0 开始组建团队，那么就需要从组建时就要根据负责的工作进行一个人才规划，招聘不同层级不同能力的人。如果是中途接手一个团队，就要先了解团队成员的具体信息，根据其所长做出调整。

测试组每个人员都有主要负责的业务，对于非自己负责的业务，可以不熟悉，但要了解。测试组负责的诸多业务系统，每个业务系统都有主要负责的测试人员，这样测试人员能对自己负责的业务系统有更多的了解，更好的保障交付产品的质量。但是，当遇到项目紧急需要调配人员时，就需要调配的测试人员对测试组的其他业务系统有个基本的了解。在日常的工作安排中，我们可以将一些小的需求不定期的交叉负责测试，定期组织业务系统的讲解分享等等，让测试人员对其他业务系统都有了解。同时在给调配的测试人员分配测试任务时，考虑将测试任务根据风险等级和通用程度进行分配。

了解测试组项目推进进度。测试组每周的周会或站会是一个很好的方式，如果遇到重要或紧急的项目，可以组织项目组的每天站会。

及时掌握发生的线上问题。要及时掌握线上问题的产生原因、影响范围、解决方案、优化意见等追踪内容，及时处理。

工作之外的交流。工作之外的日常交流，可以更好的了解测试组成员的基本情况和面临的其他问题，了解这些动态对日常管理可以有更好的帮助。

向上管理，做好工作任务承接和向上汇报。不要害怕和上层领导沟通，多和上层领导交流，可以让上层领导更好的了解自己团队的工作内容和进度，也能更好的了解上层领导对团队的工作规划和意图，同时也能了解他们关注的工作重点，用他们听的懂的语言汇报测试组的工作成果。

以上是对自己工作中遇到的问题和经验的一些总结，权做抛砖引玉，大家有其他的想法，欢迎在评论区留言讨论。

引用文章：顶层视角下的质量建设路径分析泛谈