偶然间在论坛上看到一个帖子，帖子内容如下：
假设现在有一个新增商品的接口，回来的参数中有新增商品的 id（每次回来的 id 都不一样）、success（判断是否成功，0 失败 1 成功）
- 接口测验，断语的时分是否需求断语 id，仍是说只需求断语 success 等于 1 就行？
- 假如需求断语 id,是断语 id 不为空即可，仍是说从数据库中取新增商品的 id 和接口回来的 id 进行比较，断语是否相等，这种比较有必要吗
问题的中心点是接口测验断语颗粒度问题，咱们的观点根本上属于两派：
-
只需求断语接口响应即可，无需做DB落表数据断语
-
断语尽可能详细，DB断语很重要。
单体架构测验颗粒度
本文的主题也由此打开，讨论一下微服务接口测验的颗粒度问题。
20年之前，其时负责的产品属于单体架构，产品功用也相对比较简略。第一家公司产品是一个用户营销渠道（画像系统），中心功用就是用户标签办理、圈人办理以及客群办理；第二家公司所在部分做在线教育产品，产品是内容生产渠道，该渠道用于对 K12 教辅书本进行流水线办法录入，功用触及文件上传、目录录入、内容框选、标题录入、标题质检等。
其时的测验战略，测验要点在于功用测验，测验手法是手艺端到端测验以及完成自动化的接口端到端测验用例。说白了只需掩盖中心的事务场景（中心链路），发布后就根本上没太大问题。
当然，单接口的自动化测验也有掩盖，包含对接口在处理事务前的前置处理逻辑测验，以及接口处理事务逻辑后的输出成果测验。
1.默认值测验
很多状况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为回来查询的成果数量， 默认为10，那么就应该有一条case来测验，当然前置条件是数据库里面必需求存在这样的数据超越10条。
2.反常类型测验
比如上面的count参数，这个参数的类型必定是能够转换为int类型的，这时分咱们需求测验假如传的一些不能够 转换为int类型值来测验代码是否加入判断
3.必传项测验
假如接口的参数有必传项，那么需求测验在不传这个参数的时分接口回来状况，测验是否会提示 相应的error code
4.非必传项测验
假如接口有非必填项，当我不传递这些参数的时分会不会正常的回来相应的成果
5.非空测验
无论是必传的和非必传的参数，传递的key是正确的，可是value=null，这时分回来成果是否正确
6.错误码测验
通用的错误码与事务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的掩盖一切的状况
7.接口回来值
主要是对接口回来成果进行断语。例如回来成果中某些字段是否缺失，类型是否正确等。
但我印象中，单接口测验用例发现的缺点份额占比相对比较少，更多缺点都是经过端到端测验发现的。
总结一下，可能是出于事务简略（链路杂乱度低、事务模型简略）的缘故，测验手法为手艺测验+自动化测验，测验场景掩盖中心事务流程即可，接口自动化测验断语回来数据就能满意质量要求，也很少断语DB数据。
微服务架构测验颗粒度
来到阿里，触摸的产品事务杂乱度、技术架构杂乱度指数级增高，此外金融类事务对资损的把控极端严格，只需是资损至少是P级故障了，而且和绩效直接挂钩。所以金融类事务的质量确保工作压力颇大，对测验质量要求极高。因而对落库数据正确性、对下流调用的参数正确性都必须校验到。
一般状况下，开发的编码质量也比较高，常规的事务功用用例开发根本上联调过问题不大。对测验同学来说，测验的要点更多偏向于反常测验场景，例如缓存数据共同性、高并发、异步消息重发/漏发等这些状况下系统该如何正确处理。
为什么与之前单体架构测验颗粒度差别如此之大？我从二者架构差异的以下几点说一下：
1.微服务架构布置和运维本钱更高：微服务架构中的服务数量一般比单体架构更多，每个服务都需求独立布置、配置和监控，这会导致布置和运维本钱变得更高。
2.微服务架构一般是分布式系统的：微服务架构中的服务涣散在不同的服务器上，服务之间经过网络通信。服务完成时必须考虑分布式系统的问题，比如服务发现、负载均衡、容错等，显然这些都会增加系统的杂乱性。
3.数据共同性问题：由于微服务架构中的服务是相互独立的，服务之间运用各自的数据库。这使得数据共同性变得更难以确保。
4.服务之间的依赖愈加杂乱：在微服务架构中，一个服务一般会依赖其他多个服务，这就需求办理服务之间的依赖联系（契约）。
ok，说了这么多差异，下面介绍一下当时的接口测验颗粒度。
在测验战略上，不同于单体架构的端到端测验，如今测验要点是服务本身。如上图所示，假如以下单付出事务为例，服务A能够理解为网关的下单付出接口，服务B能够是X应用的下单付出接口，服务C能够是下流X域的付出接口，这样服务A、B、C分属不同的开发团队，则各个开发团队也只能确保各自应用服务的质量，所以测验要点就是服务本身，很少进行端到端测验。
根据此，假如你负责的服务是服务B，则你测验的颗粒度至少确保到：
1.服务A各种调用B的恳求场景需求考虑到。正向的场景能够正确响应和反常的场景服务B则给予上游约好的错误码。
2.服务B内部的事务正常和反常处理落库的数据正确性。
3.服务B调用服务C，恳求报文是否和契约共同。
此外，上文说到了数据共同性问题。整个也是比较重要的，一笔恳求从A到C，则如何确保数据的金额、状态共同性也是需求测验同学关注的。当然如今对分布式系统数据共同性采纳的都是最终共同性的完成办法。
1.选用分布式事务：分布式事务是指跨越多个节点的事务。当多个操作需求在不同的节点上履行时，为了确保一切节点上的操作都能正确地履行而且保持共同，能够运用分布式事务来协调这些操作。常见的完成办法包含两阶段提交和三阶段提交。
2.运用分布式锁：分布式锁是指在分布式系统中对共享资源进行加锁的一种机制。它能够防止多个节点一起对同一个资源进行修正，从而确保数据的共同性。常见的分布式锁完成包含根据数据库的分布式锁和根据缓存的分布式锁等。
3.选用分布式缓存：将数据存储在分布式缓存中，每个节点都能够从缓存中读取数据。假如缓存中没有所需的数据，则能够从数据库中读取。这种办法能够大大削减对数据库的访问次数，因而也能提高系统的性能。
如何测验数据共同性，测验同学只要先了解这些结构本身的原理，才干经过必定的测验手法结构这样的事务场景。
即使有些场景无法结构，也是能够运用被动手法来验证数据共同性，例如能够借助于核对的手法。对同一笔单据，服务A-服务B-服务C，落库数据的共同性核对；以及服务B落库数据各表数据共同性核对。
总结一下：微服务架构下事务杂乱度高、技术架构服务高，对测验质量提出了更高的要求，单体架构下的测验战略已经不适用于微服务架构，微服务架构更偏重于接口测验。对接口测验的颗粒度要求尽可能细：
1.反常场景正确处理（这点和单体架构测验点几乎是共同的，如1-6）
2.契约测验确保契约契合预期
3.落库数据准确性
现在回头再看文章最初的那个问题，我认为他们说的都没错，凡事没有绝对性，不同的产品有不同的质量要求，最优解就是花最少的时刻得到最优的质量报答。
