一、序

日常研测工作演绎

你是否也有同样的困惑？

跟进的需求，就在提测前一秒，被告知不能如期提测了，研测计划被打乱；

提测的功能，犹如遇到不好的购物体验，缺斤短两，与 prd 预期不符；

产研测三方需求理解不一致，临时组会讨论，出临时解决方案；

等等。。。

你是否也遇到了以下的挑战？

1.时间约束：敏捷开发周期较短，迭代速度快，使得测试人员很难在可用的时间内彻底测试软件；

2.回归测试：在不断地迭代中，系统功能大大小小的功能点，多如牛毛，如何能准确确定回归范围？

3.测试自动化：敏捷开发通常需要高度的测试自动化来跟上快速的开发节奏，测试 case 的开发和维护，都需要投入大量的时间和精力。

面对这些困惑、挑战，我们该如何去推动、提升研发的提测质量呢？有没有前置的动作，能够提高提测质量呢？

二、提测质量研测共建

软件项目中，影响产品质量的因素很多：需求质量、设计质量、编码质量**、**测试质量，甚至发布时的配置，都会影响最终的交付质量。提测前的工作占比高，为核心环节，过程、质量的好坏，直接决定最终的结果。

1. 责任与使命

参与者的参与度、责任感，都会直接影响整个产品质量：

目标管理："心之所向，行之所往，未来可期"，在软件项目中，也同样适用，有明确的目标，即把工作做好、做极致、做完美，才会有好的结果。

越位思考，本位做事：每个参与除了要考虑岗位职责范围的工作，还要将自己置身于整个过程、整个链路中，思考上、下游衔接点，做好无缝衔接。

拥抱变化：软件研发管理中，变化是常态，参与者要善于调整计划，适应变化。

自我提升：在工作中，不断地提升自身的技术能力，拓展业务知识，提高沟通和协作能力，通过持续的提升，提高工作效率，提升工作质量。

2. 项目管理

2.1 资源管理

人员是最为重要的项目资源，进行工作安排时，应充分考虑以下几点：

人员的责任心够么？能够支撑他完成这项任务么？

人员能力与项目所需能力是否匹配，会小马拉大车么？

人员对业务是否了解？是否能把握当前需求么？

人员的工作量是否已饱和？是否能消化当前需求？

2.2 流程管理

在每个迭代实施过程中，形成标准化的协作流，如下图：

在践行标准的流程下，还有些细节点可以帮助提升提测质量：

2.2.1 需求评审阶段

在敏捷管理中，需求评审是一个关键环节。需求是项目实施过程中共同的标准参考，需求的质量很大程度上决定了最终的交付质量，研测要在评审前，做充分的思考：

1. 评审前，研测人员对需求进行预习，准备待确认问题，对需求问题进行信息拉齐；

2. 抽象：从宏观层面，了解业务背景，理解要解决的业务痛点；

3. 具象：了解需求功能，了解相关功能的上下文；

4. 抽离：对功能进行推理、演化、扩展，提出需求未明确的场景，进行补充确认；

5. 控场：对于歧义较大、需求缺失信息较多的情况，合理拒绝。

6. 对评审的问题，形成待办，落实责任人。对问题进行跟进，对结论进行同步。

2.2.2 研发设计评审阶段

在敏捷管理中，设计方案评审是一个重要的环节，旨在确保项目的设计方案符合项目需求、技术标准，准确评估影响范围。

1. 研发人员需要编写清晰、具体、可验证的设计文档，数据库设计，接口文档，以便在评审过程中更好地理解和评估设计方案；

2. 测试人员评审前对相关文档进行预习：包含但不限于以下文档，设计文档、依赖的内部、第三方、企微接口文档、数仓表、上下游功能等；

3. 测试人员准备待确认问题，不限于设计问题，也可包含业务场景补充、影响范围补充；

4. 测试人员提合理的物料要求：比如造数、日志关键字支持，在测试环境进行冒烟测试，配置依赖的配置信息，通过业务流完成冒烟测试；

5. 测试人员，可以提前识别复杂造数场景，与研发沟通，协商采用脚本或其他工具提前完成；

6. 研发技改需求，研发为了追求完美，方案可能会改多版，改动随意，要求明确改动点，影响范围，回归范围；

2.2.3 研发开发、自测阶段

1. 频繁沟通，保持频繁、及时、有效的沟通，确认需求理解一致性，确保对项目的需求和进展有清晰的理解；

2. 对业务背景及需求理解透彻，避免开发方向性错误；

3. 合理设计方案，具备灵活扩展、足以应对小的需求变更的能力；

4. 合理工作拆分，尽量减少交叉工作及相互依赖；

5. 合理评估工作量，细化工作内容，规避工期对质量的影响；

6. 合理设计自测场景，提前了解测试用例，提高自测意识及覆盖度；

7. 全面评估及约束影响范围，避免对已有功能产生不可预知的影响；

8. 开发细节过程可追溯，避免在测试阶段遗漏；

9. 代码评审，通过评审，帮助团队发现签潜在的问题，提高提测质量。

2.2.4 测试用例设计及评审阶段

1. 测试用例前置，帮助团队发现潜在的问题，避免在后期才发现问题，从而降低修复问题的成本；

2. 充分理解需求，了解业务的痛点，从业务层设计，全面覆盖业务场景；

3. 理解技术实现过程，了解数据存储及数据处理逻辑，多考虑可能的异常情况，对数据的不同态进行考虑设计；

4. 自动化测试用例资源盘点，复用自动化用例，提高测试效率，扩大测试回归范围，保证测试质量；

5. 测试物料准备工作前置，环境的构建，数据的准备，脚本的开发，资源的协调等；

6. 充分进行需求变更，通过改动点，精准圈定变更范围；

2.2.5 冒烟测试阶段

1. 严格按照约定的标准进行准入、准出；

2. 根据过往合作情况，灵活调整冒烟策略；

3. 对冒烟测试不通过的需求，进行记录；

4. 可酌情，做必要的冒烟支持工作；

2.2.6 持续改进

质量数据积累

通过积累的度量数据，提供分析，改进过程的数据依据。

质量门禁建设

质量门禁的作用，就是从需求阶段开始，尽早的介入需求设计、产品设计和技术方案设计等环节，通过评审、提问等方式，尽可能多的发现存在的问题，通过制定科学合理符合项目实际情况的准入准出标准，来保证每个环节流转到下一环节的输出结果，质量更高。

不但测试需要建设质量门禁，研发也同样需要。

自动化测试用例库建设

自动化测试用例建设是软件测试过程中的一个重要环节，帮助测试团队提高测试效率、减少人工测试的工作量，以及确保软件质量。测试人员，在项目结束后，要完善响应的 case，通过自动化 case 的不断积累，来打破时间约束带来的问题。

复盘总结+分享

以史明鉴是一种重要的学习方法，定期复盘总结很有必要，能够帮助我们避免犯重复的错误，在错误中吸取教训，补充缺失点，并形成文档或报告，以供以后的项目参考。

作者：京东零售 王兰青

来源：京东云开发者社区 转载请注明来源