API Team背景介绍

在介绍API Team是如何工作之前，先给介绍一下背景。团队主要负责给外部Consumer提供数据同步。当内部系统的数据发生更新后，外部Consumer需要拿到自己订阅的事件更新自身系统，以保内外部系统数据一致.

内部系统不能直接暴露DB或Api给外部系统直接访问，所以我们提供了一个外部接口External api专为外部Consumer服务（暴露 event feed 或 api数据）！具体是如何把这些事件或api提供给外部Consumer的，请看如下简易结构图及介绍:

结构图

内部系统（Domain api）的每一个编辑操作会往数据库ES中写事件event。 Service负责把所有事件按External system订阅要求，分类处理后，重新存入EventStore的另一个stream。（原理:通过用不同的job分别对不同类型的事件transfer）

当Consumer每隔几分种向External API请求数据时，那么External API会把此steam中的数据转换成feed形式提供给Consumer。

API Team是怎么测试的

【API 层测试】

Domain API层测试
（1）测试所有需要产生事件的Action（Domain Api）都有正确地触发事件并存入到ES；
（2）测试不需要产生事件的场景没有触发事件。
（3）这层最底层的测试了，80%场景都已测试覆盖
Transfer service层测试
（1）测试Transfer中的每个job能每100个event为一批顺序往后读取。
（2）测试Transfer中的每个job在每一批读取转换中失败时，能够准确停止在失败的位置。
（3）测试:符合条件的（DomainAPI层触发的）原始Event能正确转换成（下一层external api能消费的格式)准确的event。
（4）测试:不符合条件的跳过并不被转换。
（5）这一层属于中间一层，它把底层Domain
（6）Api层可能输出的所有情况都进行mock，并加以测试，此处测试覆盖达95%.
External Api层测试
（1）测试上一层Transfer之后的event，能通过External Api出去正确的feed格式。
（2）这也是最外层，直接和Consumer打交道的，它把所有transfer层可能出现的输出情况都mock并加以<wbr>测试，这层测试覆盖95%.

【Integration测试】
（1）这一层的测试主要是连通测试，把api层的测试串联起来，由最底层Domain层直接通向最外层Exteral api层.（api的端对端）
（2）把业务中每个事件都加了一个连通测试，至顶向下连通。从Domain层-External Api层）
（3）通过调用Domail API创建数据触发event，然后直接调用External API检验其结果是最终预期的feed。
（4）测试覆盖30%（另：提供给外部Consumer调用的API也都在这里测试覆盖。）

【QA regression测试】
通过UI模拟实际场景发event，然后再验证Consumer能成功拿到正确的feed. 这一层端对端测试，从内部系统UI层操作再到Consumer拿到数据，最贴近实际使用的连通测试！涉及到UI的测试成本高，所以只把主要事件场景进行覆盖20%。

【探索式测试】
测试人员根据经验进行手动探索寻找defect。

日常中测试怎么实践的

QA参与每一环节进行质量把控，旨在提前发现问题，<wbr>提前预防问题，减少重复......

【IPM】
每个迭代开始会进行IPM，在IPM上大家补充或确认此story涉及到的业务场景（通常在写story AC时也会找QA沟通确认），IPM上补充越多的场景或Case，对估点的准确度越会有帮助。

【Story Review】
在Review story时，进一步熟悉检查AC，如果遗漏或缺陷及时发现，同时，在Review story时，也会以把测试Case写到QA Notes中。这个不仅是提醒自己要测试的点，也是给DEV的一个提示。
【Kick Off】
在KickOff时，大家总结了一个KickOff Checklist（此表会被持续更新改进），KickOff 时会问下图中的问题，有需要注意的团队会标到Story上，有需要测试的点也要加到QA Notes，开发人员在这一环节也会Tasking中遇到的疑问进行确认，也会把一些Point share。

KickOff Checklist

【Sign Off】

SignOff Checklist

（1）SignOff时，会参照SignOff Checklist进行，我们会把所有AC验证，也会把story上标的所有测试case验证，也就是说想到的测试点都在此环节做一次检查（绝对的提前测试哈哈，我们也从中尝到了它的好处，哪些好处静等专题分解)。
（2）测完AC或Case后，会Review autotest,通常UT,IT都是DEV写的，有时QA也会和DEV pair写IT（不过机会很少），QA简单了解代码框架结构后，一起review UT, IT，从测试角度找到漏掉的测试点，当然这个过程中QA也会从DEV那里学到很多。（当然也会因为哪些需要哪些不需要加而争吵，争吵过程中有相互触进思考和共同学习的好处）
（3）测试环境提前准备好，能提前准备数据的场景，DEV要提前准备好测试数据。
（4）项目的所有卡（故事卡、技术卡、缺陷卡）都要进行KickOfff, SignOff
（5）发现的defect都要求加自动化测试，优先从底层单元测试加起、再往上加集成测试。(QA在SignOff时Check一下)
（6）会优先让新人drive SignOff，为了给新人更多熟悉业务系统、<wbr>更快融入及成长的机会。（QA要在旁边给于引导，让Dev从测试视角来SignOff）

【QA Test in QA-Env】
（1）进行Manual探索测试。因为在SignOff环境已经把所有的场景测试过了，此处我们更多的经验探索测试，关注在QA环境下可能的隐患。
（2）QA编写或修改API Auto Regression Test。（如果功能修改，那么原有的Regression在一上包后就会挂掉，所以及时修test,也会为新的Case加Test)