质量三要素：输入、过程、输出
::输入：::
1、加强开发自测质量监控
一个产品质量是由需求、开发、测试各个角色各司其职，共同保障的，需求提供需求设计、客户场景，开发实现需要理解清楚需求，测试验证开发到产物是否满足需求，不应该全部依赖测试发现产品中断错误、不符合需求的实现，开发修改bug经常找测试说帮忙验一下、我不知道怎么做数据、不太清楚这个功能，不是我做的，开发过程就对需求理解不是很透彻，那开发质量需要打个问号，测试需要统计每个开发的bug率，并将该数据给到项目经理；对多个迭代的bug数量做监控，做到bug是不断收敛的，开发质量是否提升，那么测试方式是有效果的
2、加强开发规范，推动接口测试
a、API文档
API文档就是软件开发的规范和标准，它里面包括了功能以及功能实现的标准
接口的三要素了：url+方法+参数+返回值
开发增强质量意识
::过程：::
1、测试前移，接口测试
a、自动化重要性
持续交付是一种自动确保你的软件可以随时发布到生产环境中的方式，接口要比手工测试（如点点点）更提前介入，更早地发现程序中可能存在的bug，从而补救成本比较低，UI自动化是基线测试的，是主干功能测试之后执行的，接口测试是可以在冒烟测试阶段、功能测试之前执行的，是有测试前移条件的
几十人天的开发任务，给到测试的时间一周，需求投入全部测试人力加班加点赶工，是否在开发阶段引入接口测试，不需要等到界面开发完才开始测试
需要提测后，测试进行冒烟测试可以执行接口测试脚本，通过测试技术、测试工具来做质量验证
测试前移，需要资源、时间去落地，大家去用过之后，有什么问题，再根据问题去想改善方案
在可行的情况下，将测试工作转移到 API 层。
使用测试数据管理和服务虚拟化，以便能够连续执行实际的端到端测试——没有假阳性和超时。
真阳——研发发现的有效缺陷
真阴——客户发现的无效缺陷
假阴——客户发现的有效缺陷
假阳——研发发现的无效缺陷
b、接口测试
接口测试和功能测试没有什么太大的区别。只不过功能测试一般是要等程序上线以后，才能够用手来点点点测试的。而接口测试也是测试软件的功能，只不过是在没有UI界面、在程序没有上线之前就可以测试。
接口测试就是根据接口清单，模拟客户端向服务端发送请求数据，并获取响应数据后，查看响应数据是否符合预期的过程。
2、日报
即使知道怎么很好的管理执行进度，但也还是有一个头痛的问题无法回避，那就是怎么保证执行的质量
如果bug低于经验值，要及时分析原因，是用例覆盖度不够、测试进度缓慢、开发进度缓慢还是什么其他原因
3、交叉测试
质量加固过程中，每人测试一整个应用，之前项目任务是划分功能分散多人测试的，发现了一些功能bug，所以主干功能测试，基线测试交叉测试
自我效能理论，自我效能感是个人对自己完成某方面工作能力的主观评估。评估的结果如何，将直接影响到一个人的行为动机
4、严格执行打回机制
不是bug数量越多越好，如果bug高于经验值，要马上分析bug多的原因，是不是开发设计有问题、有没有产品验证阶段、是否需要扩大自测用例范围、是否每个迭代总是进行重复的测试、bug是否总是重复出现等等，如果一个产品是通过不断打补丁来修复漏洞的，那产品的可靠性是存在很大风险的，经不起推敲的。严格实行打回的权利
5、提升测试技术
是不是没有bug就证明产品质量好呢，按照用例测试已经测不出bug了，那我们要多思考，思考如何进步、思考如何提升测试效率、思考探索性测试、性能测试、安全测试等等，测试不应该被不断的提缺陷、验证缺陷填满时间
6、增加客户场景测试
为什么产品内部测试没问题，到客户测试就会出问题呢，条条大路通罗马，测试也一样，一条用例的测试路径千千万，客户使用场景比较复杂多变，需要由实施、产品这些前方的同事为测试提供客户场景，由测试设计客户场景测试
7、质量意识灌输
不是不重视质量，只是不知道自己的行为会对质量产生什么样的影响。灌输质量意识、公司惩罚制度、对质量事故的前因后果、惩罚措施传达到部门，让大家有严肃对待质量的态度，引以为戒
::输出：::
1、加强质量监控、反馈机制
线上质量问题如何监控、发现时效、如何通知负责人、负责人反馈时效，比如半夜发现问题，能否通知到人、能否立刻开始分析问题，这些时间是否都算在影响客户使用时长范围内
**追责**
1、没有人愿意出质量故障，质量保证需要全员参与，测试不能穷尽测试场景，既然有了用例评审流程，如果测试用例经过了评审，产品、开发、测试一致认为可以以当前用例来测试并进行验收，那么出了线上事故、但是测试又按照用例测试过没问题，那不应该由只由测试背锅，应该是团队一起承担问题
