质量保证梳理

对于一些需求的实现，使用checklist的方式，回答清楚每一个跟质量相关的问题，帮助开发人员梳理清楚对于质量保证而言最重要的事是什么，做到质量保证“能落地”。

问题列表：

如何保证质量？

首先得定义质量，要能对质量进行衡量

对于一个软件项目而言，质量意味着什么

可扩展性
  • 以当前的资源部署下，在业务上，能支撑多少业务量 (tps/qps)？
  • 最早遇到性能瓶颈的模块是什么 ？
  • 最简单能解决该性能瓶颈的方法是什么，解决成本怎么样？
  • 从设计上，需要达到20-100倍的设计标准，当前的方案能否达到目标？
  • 扩容/缩容的成本如何？
可靠性
  • 当前设计是否存在单点故障？
  • 极端情况下，是否能够正常提供共服务(流量突增、恶意刷接口)？
  • 节点故障是否会影响到正常使用(部分节点宕机)？
  • 功能是否具备 feature toggle？
  • 功能是否具备回滚能力？
  • 若发生错误，是否能第一时间得到通知？
  • 若发生错误，是否任何人都能快速定位到问题？
可维护性
  • 预计可能的功能拓展有些什么？可能的功能需要增加哪些内容？
  • 是否是插件化设计，组件的替换成本如何？
  • 对于较大的功能模块，是否有比较明显的设计模式说明？
  • 功能是否具有两个以上的人熟悉，做到维护人员冗余？
其他
  • 是否有详细的说明文档、设计文档、沟通文档、项目过程文档？
  • 是否有针对于项目结构/模块设计/代码风格与他人进行沟通讨论？
  • 是否有完善的单元测试及集成测试？
  • 是否进行过技术探讨与反思？例如当前项目的主要问题是什么？解决的优先级是怎样的？当前的解决方案是否具有通用性？能否有所沉淀以成为通用组件？等

如何用测试来保障质量？

测试 是更接近实际的一种质量保证手段。

2.1 如何保证功能的正确性？
单元测试/集成测试

  • 如何保证(自动化)单元测试的覆盖率

  • 学习QA如何写测试用例

  • 做测试的代码覆盖率检查

    如何能快速管理集成测试

  • super_test 项目

如何保证集成测试的场景覆盖率
  • 学习 QA 如何写测试用例
  • 先以一系列场景为例，实际写一堆用例再来回答这个问题
2.2 如何保证性能和可扩展性？
性能测试、故障演练(性能瓶颈)

性能测试主要为 单模块性能测试 和 链路集成测试

对于模块的测试，可以先站在基础架构的角度，考虑模块的可扩展性，再站在实际使用的角度，从业务角度测试性能。

例如，对于messenger的压测，可以先考虑当前使用的 redis、mongo、kafka 的本身的拓展能力，得到在不同流量级别下这些模块的性能。

然后，考虑 messenger 目前提供的服务内容，针对每个业务内容，进行单独的测试，类似于单接口测试。然后对多接口进行测试，考虑不同接口之间的相互影响因素。

对于链路压测，需要考虑 1. 链路范围界定 2. mock 服务。(ps: 可以考虑 mock 为正常服务的一个切面)

2.3 自动化性能测试平台的构想

对于业务的性能测试，压测的情况越接近于真实业务情况的压测约具有说服力。因此，性能测试是要尽量模拟真实的业务场景。

但对于一个变化较快的业务，或者一个新的业务，是很难准确估计真实的业务流量模型的。

这种时候最好的方式是对多个可能的变量进行笛卡尔积，然后对每种情况进行压测。

举个例子，messenger 可能面临的业务流量模型有很多，其中 总连接数、单个房间人数、房间个数、首页关注人数、changeset 发送频率、changeset 大小、广播消息类型/频率 等都是可能的变量

例如，平均一个房间10个人，单实例上 100 个房间，总连接 5000 时，用户以 6帧/s 的速度发送 800 byte 大小的 changeset，那么，对于资源的耗用情况如何？

如果要对每一种情况进行手工压测，那么其成本是巨大的。

从 do not repeat yourself 的角度出发，这应该是一个可以自动化的流程。

对于压测人员，需要做的是： 1. 找出约束的变量，配置关注的变量值。 2. 对结果进行分析并做近一步的确认。

自动化性能测试平台最好是一个可以适应多种场景的通用化平台，支持自定义的压测脚本、自定义的压测报告、自定义的压测策略，

应该支持多种消息格式，例如 http、https、ws、wss、grpc、mqtt 等。

对于这个平台的搭建，一定要仔细去分析 jmeter、metersphere 这两个平台的逻辑以及设计。

2.4 如何保证可靠性？
  • 边界测试、极端测试、混沌测试、故障演练(错误故障)
可以考虑以下内容：
  • api的边界测试交给中间件来进行。
  • 梳理可能的错误点，并考虑故障注入的方式。
  • 跳出代码逻辑去考虑错误故障，目标是得到尽可能全的故障类型，并针对每个可能的故障进行故障排查及恢复演练。
当前最紧要的事：
  • 故障演练的规范化。
2.5 如何保证用户角度的正确性？
  • 视觉感知测试/e2e测试

e2e测试的成本相对较高，需要测试人员写相应的代码，且每当业务逻辑产生变化，则需要维护这些用例代码。

视觉感知测试是另一种和e2e测试类似的测试，一般来说不需要写代码，但由于测试是基于“图片对比”的，因此灵活性不如 e2e。

视觉感知测试的优点是“直观”，在考虑操作录制的情况下，测试人员仅需要对“用例场景”进行定义即可，要求相对较低。

视觉感知测试怎么做？

最基础的方式，是进行图片对比，有一系列的操作逻辑，每一步操作后，都有一个截图，用于展示当前操作状态。

只要一个功能的逻辑没有改动，则特定操作会产生特定的结果。

只要重复这样的操作逻辑，并对每次的图片进行比对，就能得出特定的结论。

划分应当以 功能 区分开。

在某一个功能下，有一些具体的场景。

每个场景都有特定的操作与逻辑。

很多场景是相关联的，这些场景应当可以进行参数化配置。

场景中的很多流程是相似的，这些流程应当可以复用。

由于运行与截图需要对测试人员透明，因此需要提供录制场景的方法。

考虑到功能可能频繁变更，因此要增加快速处理比对失败的场景的能力。

考虑到测试的后台运行属性，因此需要具备报警与通知的功能。

考虑到素材的可变更性，需要标注可变素材块。

考虑到h5的布局对内容的影响，可以考虑对于布局的视觉感知测试。

当前最紧要的事：

以一个功能需求为实际场景，进行MVP实验

考虑当前 master 项目的整体质量保证措施

  • 以瑞阳牵头的发布流程的保证
  • 各小组进行的code review
  • 写轮眼项目
  • 前端项目的e2e模块
  • 后端的api接口自动化测试
  • 监控报警
  • 基于用户反馈的 oncall 机制

文档直通车：

关于质量保证的探讨

The greatest achievement of humanity is not its works of art, science, or technology, but the recognition of its own dysfunction.
— Eckhart Tolle