这期的需求中有一项是表单状态。表单状态需求的流程图如下。
需求流程图.png
在测试分析过程中，先明确及细化需求，了解各端（客户端、web、服务端、其他端）的交互，针对表单状态，可以先对表单的类型进行区分，再对不同类型的表单分析状态转换图及逻辑表，最后结合状态的状态流转图及逻辑表，设计测试用例用来覆盖逻辑表及状态转换的各种情况。
就表单状态来讲，表单有四种状态：未完成、已完成、已通过审核、已完结。而且表单四种状态与表单内部的几个小状态决定：表单是否完成的状态、ocr识别状态、人工识别状态。表单的几种小状态和最终状态的内部逻辑可以以表格的方式展示，这样一目了然，对于测试理解和测试过程很有帮助。这里盗用一张图:
image.png
表单类型可从是否有必填、是否有人工审核及是否有ocr识别几个维度分为以下8种类型：
| 是否必填/审核方式 | 无审核 | 人工审核 | ocr识别 | 人工审核&ocr识别 |
|---|---|---|---|---|
| 无必填 | 无审核无必填 | 人工审核无必填 | ocr审核无必填 | 人工审核&ocr识别无必填 |
| 有必填 | 无审核有必填 | 人工审核有必填 | ocr审核有必填 | 人工审核&ocr识别有必填 |
表单四种状态的状态流转图如下，我最初考虑的时候只画了一张流转图，但是后来发现应该对表单进行分类，不然就可能漏掉有些可能的情况。而且分类后，对于接口或功能测试来说，都有了细致明确的划分，便于测试的进行。
无审核无必填的表单 (1).png
无审核有必填的表单.png
只有人工审核的情况.png
只有ocr审核的情况.png
ocr和人工审核均有的情况.png
在本次测试的过程中，针对各端（前端、服务端接口、客户端）分别进行了测试，即先进行了模块测试（前端、服务端接口），再进行了系统测试，从不同的层次关注了表单的状态逻辑。以后的测试设计可以从不同的模块层级进行考虑分析，每个层级关注的点其实是不一样的，就像服务端只关注的是接收消息后计算的结果是否正确，而前端关注的是触发rabbitmq的时机和是否发送了正确的rabbitmq消息，客户端则更侧重业务逻辑及交互展示问题。
