BS架构下，如何构建高效的质量保障工作流程？

本文共计3036个文字，预计阅读时间需要13分钟。

确保产品质量是做好产品的关键一步，但为了快速形成业务，很多项目在初期由前后端开发人员自行测试，上线后再补充完善质量保障内容。

质量保障是做好产品十分重要的一步，但是为了快速起项目形成业务，很多项目在设计之初全由前后端开发人员自测，稳定上线后才补上质量保障侧的内容。本文旨在梳理一套BS架构产品的通用质量保障模型。其中部分内容，如API、UI自动化与质量保障标准或许会在日后更新详细内容，大概吧（坑挖了再说

产品设计与技术评审阶段

在设计阶段，QA应当在各评审会1小时前开始阅读并评论方案，以此提高会议效率并尽可能发现其中问题。

产品定义文档（PRD）评审/用户体验设计（UED）评审

在此阶段，开发（RD）与测试（QA）人员应当替PRD/UED捉虫，寻找PRD/UED当中的缺漏和未定义行为。在开发之前就尽量完善PRD到RD、QA没有疑问。举个例子：

需求名为“为搜索框增加搜索历史记录与搜索建议”，PRD中没有显式说明该需求的“记录的历史记录”是点击搜索按钮、按下回车哪一种方式触发；也没有说明搜索历史记录记录的是用户所有搜索行为还是仅记录用户点击搜索建议后产生的搜索行为。这样RD可能会理解/曲解PRD，只记录点击搜索建议以后的搜索关键词。显然从用户视角这样的产品很奇怪，但是从RD视角来看“反正PRD这里没定义，怎么好做怎么来呗”。这样的厚度哦就是功能做出来PM发现和自己想的不一样，用户用起来不爽。如果在需求评审阶段就能解释清楚需求定义不明确的内容，这种问题就能大大减少。