很久不发帖，这里丢个问题。
我们现在越来越讲究测试左移，越来越看重开发测试的比重。 测试左移，或者提高开发测试比重有一点清单就是让开发做更多的测试。 那么问题来了：
1. 开发做更多什么类型的测试？
2. 测试如何帮忙开发自测，测试需要提供什么等？
3. 如何去校验开发自测与否，以及自测的质量如何？
4. 第三个问题也引申一个问题，提测的标准可以有哪些？
被测需求核心流程的用例即可，用例中不需要体现太多细节性的东西，至于用例的载体，随便什么都行，可以是 xmind、文本文件。。。
第三个问题：先不说怎么检查，我们先说怎么做好自测，这个东西尽量用流程去约束（小公司可能没有流程，那么靠你自己的冒烟用例），有时候自测质量不高，有可能是人的问题，如果真的是这样，就不好办了。。。
好问题，关注下
GAGA
回复
心里有一定答案只是想看看 大家都怎么去定义。
我们当前尝试做的 2 件事：
- 在用例评审阶段，真正的跟开发共同定下自测用例，并真实给到开发，并开发自测后用例备注。
- 测试最烦的是准备数据，我们测试可以为开发自测提供一些基础的数据准备，甚至数据生成工具。
来自大老板的重视
就我司的实践，分享下个人经验见解：
开发做更多什么类型的测试？
——正向的基本功能流程，或者说相当于冒烟测试类型的测试测试如何帮忙开发自测，测试需要提供什么等？
——冒烟测试，或者说开发自测的用例（内容写明确一点，别只是要点，免得认知有偏差后面撕逼）；造数据的脚本或者平台（特别是对于后端比较复杂的，前端不懂造数据会导致自测效率很低）；走通整体流程的一些手把手教程或培训（有时候开发只知道自己负责的一小块子模块，不知道整体流程怎么回事，我们既然很熟悉这个，可以分享下）。严格说不是帮忙自测，而是让开发更方便、更高效地去做自测，这样他们才更愿意做。毕竟开发最能产生价值的还是写代码完成功能，都想在写代码之外的事情尽可能不要花太多时间。-
如何去校验开发自测与否，以及自测的质量如何？
——用例精简到顺利的话半小时内可以全部完成，然后提测前让开发组织做一次半小时到一小时的演示（我们内部称为 showcase ），开发自己亲自执行这些自测用例，测试和产品一起看。一个是确认功能确实已经可用，测试自己也不用再花时间重复执行一遍；另一个是产品确认实现效果和他期望一致（有时候产品需求会有些没提及的模糊地带，开发可能不沟通直接自己脑补做功能，和产品期望不一样）。如果老是走不通，开发自己也会不好意思的，所以能借此促进他们自己先做好自测再演示，免得出溴。很多时候开发自己对质量没要求，是因为自己开发的东西自己都不用，所以对里面的问题都没感觉，磕磕碰碰能过一次就交差了。让他们自己实际用起来，自然就会发现自己开发的东西有啥问题或者哪里不好用，产生改进的自驱力。用流行点的话说就是 eat your own dog food ，各个大公司内部最新版本要求研发全员自己日常就得使用也是这个道理。
第三个问题也引申一个问题，提测的标准可以有哪些？
——核心还是要能证明自己的代码能用，至少能走通正向核心功能，所以最低要求是上一步说的演示必须进行并且测试、产品都认为可以通过。更严格的提测标准可以在这个基础加上一些代码质量要求（如 sonar 标准、单测标准等）
米阳MeYoung
回复
我谈下我的看法~但是有些是纯看法，还没有实践过
1. 开发做更多什么类型的测试？
——我感觉开发要做的是两类测试：1.代码自测（目前我们没有严格规范，主要看研发个人能力）；2.功能流程，我觉得如果考虑让开发自测，很大程度我们基于 “功能测试” 的想法，所以业务流自测是我们主要想让开发做的，目的是为了确保没有低级 bug，确保业务流实现。
2. 测试如何帮忙开发自测，测试需要提供什么等？
——我们目前做的是提供自测用例，自测用例的来源是：我们认为哪些业务流是研发需要确保实现的。
我们的业务很少涉及大量数据，纯操作型，所以我们的业务流可能不像你们要制造数据，所以制造数据这块的我不了解，我看法是研发自己去想要产生什么样的数据。自测这块还是需要研发有些自主想法，所以之后我们也会借鉴你的方式，就是和研发讨论自测用例。有利于多暴露问题。
3. 如何去校验开发自测与否，以及自测的质量如何？
——啊~第三和第四个问题就是我想关注的！！！我们现在仅仅通过冒烟测试的效果来看自测效果，测试冒烟不通过及自测有问题。但其实这相当于通过结果来判断过程，不太好！我学习了下 5# 陈恒捷的关于这个问题的看法，可以借鉴，只是考虑的是如此做下去，效率和效果哪个对项目影响更大。
4. 第三个问题也引申一个问题，提测的标准可以有哪些？
——关注~
这个问题很具备代表性，我也想结合团队的实践凑个热闹。
1. 开发做更多什么类型的测试？
看到这个问题第一反应是 push 开发写 UT，实际上我们这边多个项目都尝试过，抵触的很厉害。只有少数稳定的项目才能主动写一点。我们的做法有几点（和恒捷他们的做法类似）
- 研发部署好配置环境，设置好 conf 文件各种参数，我们的业务线配置文件比较复杂，经常因为研发本地自测环境不一致导致提测的和自测的不一致，提测被打回。（目前这个问题已经通过 docker 解决）
- 研发根据测试人员提供的 ckecklist 在测试环境进行演示，保证自己的功能都 ok，业务逻辑主流程通过
- 前端开发会写 mock 保证交互的 API 格式和状态正常（不能是 4 或者 5 的错误）
2. 测试如何帮忙开发自测，测试需要提供什么等？
我们这边可以加速研发提测准入的方式有几种：
- 完善的 CI/CT/CD 流水线功能
- 自测用的 checklist
- 由测试开发的造数平台，方便研发自测一键造数（业务流程复杂，造一个测试数据非常麻烦）
- 增量代码覆盖率统计
- 性能监控、离线训练等（模型算法会用来自测）
3. 如何去校验开发自测与否，以及自测的质量如何？
如上面提到的，研发需要在测试环境进行演示，走主流程的 checklist，如果没有自测到的话，会当场现形。
测试在测试过程中发现冒烟测试不通过会打回本次提测，在系统中会有记录。
自测质量主要有代码覆盖率统计来进行跟踪，目前没有特别好的办法来跟踪这个指标。
4. 第三个问题也引申一个问题，提测的标准可以有哪些？
- checklist 验证通过
- API 冒烟测试用例自动化测试通过
- 静态代码分析结果没有 Block 级别 bug
- 部分业务需要性能自测 QPS 在指定范围内
* 团队目前正在准备实行开发自测，分享一下流程，以及我遇到的一些还未解决的问题
1.需求评审会预留自测用例执行时间
2.测试在评审会结束后提供自测用例，并上传至任务链接
3.开发执行自测用例并填写执行结果，与测试环境编号
4.测试接入时发现功能本身与自测结果不符追述原因
遇到的问题：
1.如何定义哪些任务需要自测用例（UI 类等）-- 测试主管主观界定并给任务打标签过滤
2.如何确认哪些任务已交付自测用例？--测试主管给任务打标签过滤
3.任务流之前间隔时间长，测试环境变更频繁会导致自测结果无效怎么定责？--未解决
4.任务提交杂乱导致测试可能上传 N 份自测用例不敏捷怎么处理？
GAGA
回复
当项目内容/业务流/功能点很多时，效果和效率是如何权衡的
核心点和自动化回归一样，这个事情不管谁做，是不是你在上线前必须做的。如果是，那做这个事情本身就不会降低效率，最多持平。而效果肯定比不做要好。
但要留意做好宣贯，让整个团队都认为这个事情是必需要做的，工作量纳入时间排期和提测标准。很多时候开发不做自测很大的原因也是给排期时没有考虑这块的时间，所以没时间做。
另外，如果项目自测的内容确实非常多，光测试执行可能就要超过 1 天，那真的得好好想想是不是需求划分出了问题，一个需求太过庞大了。
技术型的老板和公司是多么的重要啊
有吗?
感觉冒烟 case 就够了
现在还头疼如何给【后端开发】【Web 端开发】【App 端开发】编写自测标准与规范呢...
今早被拉去开个会，让我牵头出三份文档，其实我觉得一份自测规范流程/标准就够了，但是觉得 “难产” ing...
提供核心用例，完成提交测试前自测，保证提交测试程序正常运行
金主
回复
没有特别明确的文档标准，我说下大概过程吧：
1、用例评审通过后，可以开始整理输出 showcase 场景列表。基本上是把本次需求的几个核心流程按照操作步骤梳理出来。在预计提测时间前 1-2 天发给开发，明确 showcase 内容。这部分没有太明确的标准，开发、测试、产品都能看懂（不大推荐用自己写用例的方式写这部分内容，步骤要描述清晰一些，避免歧义），并认可即可。
2、到了提测的时候，开发群里召集产品、测试到其工位进行演示。开发自己操作，把 showcase 里面包含的流程走一遍，以说明此流程没问题。如果测试或者产品有觉得想要确认或者补充的细节点，操作不复杂现场补充，操作复杂就后续自行确认。
3、流程没走通的，不要纠结，记录下来即可。如果开发燃起了 debug 的心，及时先熄灭，不要拖长 showcase 时间。showcase 完毕后，测试可以整理下记录下来的 showcase 问题，在项目群里同步出来，避免开发自己遗漏。流程阻塞类的问题直接就认为 showcase 不通过，要求开发修复后二次 showcase（尽量当天完成修复，避免延期）；非阻塞类的记录一个缺陷即可，认为 showcase 通过。通过后开发可以发出提测邮件，测试可以开始进入测试。
注意：showcase 时尽量使用测试环境，避免 showcase 通过才开始部署，部署过程中出现其他问题导致 showcase 场景测试自己还得手动再过一遍。