背景
小程序依托百度与微信两大重量级平台的庞大自然流量生态，达到了全年访问量的巅峰，日均吸引超过xx万用户的瞩目，彰显了其强大的市场吸引力和用户基础。然而，面对如此庞大的流量红利，小程序在用户体验的承接、用户价值的转化以及长期留存机制上尚显不足，具体表现为消费转化率低、用户粘性不强及整体运营效能有待提升。
承接范围
在微信小程序与百度小程序的测试实践中，我们采取了一种高效协同的策略，即针对小程序的前端功能测试资源，将与现有需求共享测试人力资源。这一举措旨在优化资源配置，确保关键领域（如用户交互、界面展示、业务流程等）的测试覆盖与质量把控得到充分保障。
同时，为了明确职责边界与提升效率，我们界定了测试服务的范围：专注于小程序前端功能的测试，而技术类（如底层架构优化、新技术引入验证）及后台类（如服务器性能、数据处理逻辑）需求，则不直接纳入共享测试资源的范畴。对于这类需求，我们鼓励并支持研发团队或产品团队自行构建质量保障体系。
总体流程及保障方案
- 新创建的小程序必经详尽配置以奠定坚实基础，而迭代优化的小程序则可根据变更灵活调整配置，无需全面重新配置。
- 需求评审：在产研流程中，需确保项目目标明确、产品方案已获认可，并具备足够优先级。若需求未通过三方评审，需在云效系统中标记为“打回”。若涉及数据埋点需求，务必在需求文档中明确列出。
- 技术评审：针对给定的技术方案，我们可以从以下功能、性能、兼容性等方面来制定具体的测试范围，以确保测试全面覆盖关键方面，并满足可操作性和成本效益的要求。
- 开发 & 联调: 研发进行编码及前后端联调，切勿使用mock数据进行调整，使用真实服务端下发数据调试
- 开发自测: 研发自测需要体验版小程序测试，切勿使用本地代码测试。
- 提测后: QA将执行冒烟测试，不通过则直接在系统标记为打回状态。
- ShowCase (重点需求P0): 提交Showcase后转入代码审查（CR），迅速修正CR中发现的问题，进入测试阶段后尽量减少对代码进行非必要的优化改动。
- 测试 & 验收: 验收包含产品验收和设计验收，需要在项目测试完成前验收完成。
- 埋点测试: 根据「数据产品」编写的埋点文档进行埋点测试。
- 提审: 研发在小程序后端提交当前版本的审核，大概审核时间1小时。
- 灰度验收:
- 开发在小程序后台可以操作灰度占比
- QA 如果灰度验收的话，提审需要一定时间，目前看 1小时左右，不排除一些特殊时期或者是百度需要整改的需求没过审，可能审核失败，时间不太可控。
- 灰度是流量控制，可能无法命中。
- 使用白名单方式
- 需要加体验白名单，需要提供测试账号统一加白名单
- 灰度验证范围: 小程序核心回归用例
- 全量上线: QA不再进行线上回归测试，仅关注线上用户反馈、报警等。
总结
小程序质量保障需全面覆盖需求分析、技术选型、开发过程、测试验证及上线运营各阶段。需求分析需精准对接用户期望，技术选型应匹配业务场景，开发过程需遵循规范确保代码质量。测试阶段需进行详尽的功能、性能、兼容性测试，及时发现并修复问题。上线后持续监控运营数据，优化迭代以提升用户体验。同时，注重合规运营，确保小程序合法、安全、稳定地服务于用户。通过这一系列措施，可以有效提升小程序的质量和用户满意度。
