你应该结合公司研发开发的方式，是敏捷还是传统的冒泡；还有软件提测规范、上线规范、线上跟踪规范等等，都需要考虑

主要做数据服务的，关注点在交付环节，所以不关注线上场景，此处也不做过多扩展。公司是类敏捷开发，半吊子的那种，考虑现实情况也不选择对其作出建议，只做测试范围及对接前后环节的分享

建议规范和流程分开说，先明确每个事应有的规范，然后根据实际情况梳理流程，实际情况不同，流程不同，但基本原则还是 v 模型和 w 模型

建议重点考虑关联节点的约束和流程，配合这些节点，调整测试规范和流程
其实就是约束各个协同节点，尽量减少测试繁琐度，提升测试流畅度

多谢大佬，也有考虑过分开，可是发现分开后流程可写，规范却难以脱离流程分开说明，所以现在基本是按照流程阶段划分节点，在流程说明的基础上添加各节点规范，在讲解流程内容的同时给予标准

多谢大佬
约束主要就想到了需求分析和开发转测时的标准要求，但是因公司研发环境问题又难以实际落地，后面考虑还是加入具体的节点流程要求。
大佬还有没有其他节点的约束分享

和 3L 的建议一样，流程规范和开发自测分为两个事项来整，流程规范设好交付卡点不需要卡用例设计这块，比方说用例代码覆盖率、单测覆盖率、bug 激活率等。

开发自测用这种测试分享的形式可能没啥效果，可以定义好自测规范，自测的颗粒度、自测用例过审，像我们这的开发自测用例还是让测试提供，接着测试就做甩手掌柜。

给你一个建议，1、先梳理流程，得出每个节点上应该干什么事。2、每件事要干啥。3、每件事该如何做（这就是规范了）。4、每件事开始和结束的准入和准出条件，满足什么条件这个事才可以开始，这个事到达什么程度算结束。这四点做好了，项目就运转起来了

我是觉着不妨，往大了整 ，触达的覆盖范围大一些，这样测试阶段才更通畅一些，像：

• 版本需求确认（结合研发、测试初步预估排期，提前确认本次能上线的功能）
• 排期收口（除了测试排期，把研发排期也纳进来，结合上线日期、测试方案，统一协调）
• 范围收口（与研发达成共识，针对某些特定功能，影响范围收紧，测试无法进行的测试可以移交到研发进行）
• 版本收口（针对上线的内容，制定版本准入策略） 不过还是要结合业务实际情况进行，建议全流程 ，测试毕竟偏向于后面阶段，需求产出的阶段开始把控，后面阶段才能更通畅

可能我背景解释说的不清晰。整理的一个目的不是为了开发自测，而是项目人员进行测试阶段的设计和执行工作。我也清楚开发做测试时的实际情况，但是为了降低项目对测试的依赖，只能用测试基础知识普及的方式来提高开发人员的测试意识，对文档的实际作用也有一定的向下预期。
文档更大的目标还是在测试流程的规范说明，为公司测试人员 (为 kpi) 提供一个具体依据，也是对自己的一次锻炼

好的，大佬的建议很清晰，会认真参照，多谢

多谢大佬
也在尽可能的由测试往外辐射，但是毕竟第一份文档，还是想先把一些说的清楚明白的写进入，然后慢慢更新辐射更多。后续的目标就是由测试流程带动整体软件周期流程，把软件生命周期每个节点都制定出具体规范

根据二八原则，建议找到目前最影响项目的一件事，然后对这件事进行改进。
流程规范很多，找到最关键的一个去推广，可能比上一大堆流程规范要好使。

多谢大佬