楔子
这个月测试三一金票需求，感受非常深刻，特做总结。
这单需求原该2月26日提测，结果经过一番折腾，延后到在3月2日提测。
3月1日家里有急事，我请假去处理，请假了差不多一个星期，3月8日回到公司，投入这单需求的测试当中。
这时接到消息，这单需求原计划在yd1环境测试，现临时挪到yd3环境测试，这样我之前准备的所有测试数据都无法使用，需要从头开始准备测试数据。雪上加霜的事情是在yd3环境测试，原计划的测试时间再压缩一个星期，3月19日需要腾出yd3环境，这就相当于压缩的大半的测试时间。
由于这单需求从头到尾都是我跟进，需求涉及改造的有4个系统，业务复杂，测试需要跨系统操作，经过了两个星期的996一番折腾，写下本文总结这一次测试经历。
测试用例设计阶段，遗漏测试要点在所难免
编写测试用例之后，虽然经过评审，但是在测试过程当中，还是会发现漏掉一些测试要点。
MB提醒我要测试公司分配额度场景。这是一个新增的功能，对公信贷有四个团队，是其他团队负责开发的功能，我不知道这个功能，分析遗漏。
在测试用例设计的时候，考虑不到一些细节。比如需求说明书要求额度启用时“是否我行开户”选择“否”时，“支付方式”不能选择“受托支付”，页面上是先选择“支付方式”，而选择“是否我行开户”后还可修改“支付方式”，所以测试的时候我还要测试“是否我行开户”选择“否”后，又把“支付方式”修改为“受托支付”。
测试的时候发现可以多次额度启用，我想到额度启用时输入不同的还款账号，看是不是取最新一次额度启用的还款账号。
在模拟统一支付通道超时场景的时候，结果报文返回流水重复，对公信贷直接记账失败。我很奇怪，我并没有重复给统一支付系统发送请求啊，但统一支付系统的开发人员却反馈收到了两笔相同的报文，所以统一支付系统返回流水重复。经过对公信贷开发人员THR排查，发现统一支付响应时间大于网关超时重发时间，网关就会重发报文，结果统一支付系统收到了两笔相同的流水。
不过，大的测试要点基本是没有遗漏，只是没有考虑到一些细节。
不清楚系统原来的校验
如测试时我发现额度启用页面保存之后，再点击保存，这时需要重新校验还款账号（还款账号是这次需求新增的字段，需求文档中也没提到保存页面后，再次保存需要再验证一次还款账号），我想到原来额度启用页面有一个贷款账号，我在其他测试环境看看是不是保存之后再次保存，是否需要重新验证账号。
如对公信贷是什么时候扣减额度？我测试的时候，需要关注对公信贷的额度占用与恢复。经过了解，才知道在接收到供应链系统PUB011接口报文的时候，对公信贷系统校验通过（如果出账客户没有评级结果，对公信贷系统直接校验不通过，出账通知书就没有记录），就会占用额度，并且在出账通知书生成记录。
如测试过程当中发现132161接口一直以来的约定是不传小数点，开发人员不了解这一点，需求文档也没有提到这个细节，只是说要改接口的字段，结果开发人员改了接口之后，给核心传了小数点。
如三一金票不对接统一支付系统的出账，超时后怎么处理。经过了解，才知道是通过日终文件处理。处理失败返回超时，日终批次后更新出账通知书为“记账失败”，处理成功返回超时，日终批次后更新出账通知书为“已发送-已记账”。
没有完全理解需求
在测试过程当中，我发现接口新增了一些字段，但是我其实并不清楚为什么要新增这些字段，新增这些字段的业务背景是什么。我想，如果在需求人员、开发人员讨论接口的时候，那个时候我就参与进去，就能更加了解为什么要新增这几个字段。
需求文档没有说清楚的细节
出账通知书状态没有完全写清楚。需求文档中只写了出账成功时出账状态是“已发送-已记账”，出账失败的状态是“记账失败”，出账冲正的时候状态是“已撤销”。测试的时候发现，出账状态还有中间的过程。因为需求要求最终对公信贷系统是需要通过UP1201接口向统一支付系统查询结果，而这个过程是通过一个每5分钟执行的定时任务发起的，那么在收到结果之前，出账状态应该是怎样的，需求文档没有说明。经过梳理，在对公信贷系统收到供应链系统PUB011接口报文后未发送UP1101接口前，出账状态是“未发送”；在对公信贷系统收到供应链系统PUB011接口报文后且发送UP1101接口，并没有收到UP1201接口结果前，出账状态是“已发送-未记账”；在对公信贷系统收到供应链系统PUB011接口报文后且发送UP1101接口，收到UP1201接口结果成功，出账状态是“已发送-已记账”，UP1201接口结果是失败，出账状态是“记账失败”，UP1201接口结果是冲正，出账状态是“已撤销”。
需求文档中提到：当UP1101接口没有明确返回失败结果时，需要触发UP1201接口查询结果。而什么是明确的失败结果，需求文档并没有说清楚。
如对公信贷系统中，如果是“已撤销”状态，那原系统功能就没有查看出账通知书的链接，就无法查看UP1201返回的信息，但是需求文档中要求展示UP1201的错误信息。而实际情况出账状态是“记账失败”的时候展示错误信息，出账状态是“已撤销”的时候不展示错误信息。
不清楚关联系统的规则
如我想测试UP1101接口超时情况，我想到其中一种情况是统一支付系统在部署的时候，我向统一支付系统发UP1101接口，这时统一支付系统没有提供服务，那返回就超时了嘛。但是经过向统一支付的开发人员了解，得到的答案是：就算统一支付系统在部署，也是能够正常返回报文。
统一支付系统有小额支付、大额支付之分，大于100W就是大额支付，我不知道这一点就不会设计相应的测试用例进行测试。
冲正交易有不同的场景。经过了解才知道冲正有两种场景，一种是统一支付系统对外支付失败通知核心系统冲正，这叫正冲正，还有一种是记账成功后，进行冲正，叫反冲正。这两种冲正，核心系统发送132010接口给对公信贷系统的报文有区别，正冲正的时候核心判断是交易没有成功，其中一个关键字段传了空，对公信贷系统的判断是不会恢复额度，反冲正的时候关键字段传N，这时对公信贷系统会恢复额度。而对公信贷需求文档中没有区分这两种冲正。
不清楚外关联系统之间的校验。对公信贷——>统一支付——>核心系统，对公信贷系统发送UP1101接口给统一支付系统，我不清楚统一支付系统跟核心系统的校验规则，但统一支付系统返回给对公信贷的结果跟核心系统有关系。
对公信贷系统有三种方式出账场景，只使用自身额度、只是用核心客户额度、关联核心客户额度进行出账。在测试的时候，才发现供应链系统已经控制不能只使用自身额度进行三一金票出账，而我却花时间准备了测试数据。
你要直接表达自己的诉求
直接告诉开发人员，希望他优先处理什么问题。
我发现当你提了一堆bug给开发人员之后，开发人员都是优先修复那些容易改的bug，阻碍主要流程的bug迟迟不改。在测试进度紧张的情况下，我直接跟开发人员沟通，系统他优先改哪些bug。
直接向关联系统测试人员表达你的诉求。
不了解关联系统的规则，需要测试某一测试场景时，我先用业务场景描述，如我想测试UP1101接口返回失败的场景。统一支付系统的测试人员告诉我有哪些具体的场景，如出账账号错误、利率不正确，再具体问要怎样样利率才是不正确。
在测试冲正场景，统一支付系统的测试人员说供应链系统有做过冲正交易了，意思是让我直接看供应链系统的交易数据。但是我需要测试对公信贷系统的额度占用情况，又不知道之前数据的额度是否正确占用，所以还是要求继续做冲正交易。
在群里@人没有回复，私信找，私信找不到打电话，这样推进问题就会很快。
如我一直都是用同一个客户经理进行测试，每次提缺陷的时候都要附上登陆账号（不写上去，有些开发人员就会来询问），为了节省一点时间，我直接向开发人员说明我一直都是用同样的客户经理，所以bug中就不每次都写登录账号。
一天遇到额度启用页面无法保存问题，开发人员说这并不是他改出来的问题，结果开发人员迟迟不跟进这个bug。随后我直接问是否能找到是谁改出来的问题，我直接跟那一个开发人员沟通，结果很快就解决了问题。
没有完全了解设计
如供应链系统通过PUB011接口给对公信贷发送报文，对公信贷系统通过UP1101接口给统一支付系统发报文，UP1101接口有哪些字段分别是取自PUB011接口？
跨系统测试存在工作量翻倍的情况
这次改造设计5个系统，如果每一个系统测试的时候，都要关联系统做一次交易，那可能要做5次交易。但是如果能够事前沟通好测试什么场景，尽量找得各方测试的交集，可能只需要做1次交易，这样可以大大减少工作量。
开发人员实现方案与需求文档要求不一致
测试过程当中发现开发人员实现的方案跟需求文档不一样，但是仅仅通过功能测试看不出来，如需求文档是要求根据UP1101接口没有明确返回失败报文发送UP1201接口，但是开发人员经过跟需求人员沟通，改成了根据出账状态来判断，后来我才知道这个改变。所以如果能够跟着开发人员与需求人员沟通，才能更加了解最新的情况。
应该及时反馈风险
在测试过程当中，刚好参加了SZD集成测试团队培训。其中提到风险预防的两点内容，一是超出研发中心迭代时间则视为风险，二是不要因为一个风险引出另外一个风险。在整个测试过程当中，为什么只能是我一个人测试，跟前期没有汇报风险有关。这单需求明显是超出了研发中心的迭代时间，这个时候压缩了测试时间，我没有提出风险（那时候也不知道自己会有急事请假），如果我提出风险，那这时候可能就会安排人先进来熟悉需求，当我真的忙不过来的时候，可以紧急抽调人员支援。
总结
不熟悉关联系统的规则，我直接向其他系统的测试人员要来他们系统的需求文档。
不了解对方系统，那就多问，不要不好意思。
做为测试人员，你需要了解开发设计。主动看设计文档，参加设计评审。
做为测试人员，你要及时反馈风险，不要把风险拖到最后。
文字沟通不清楚，那就直接当面沟通。
做为测试人员，不是完全按照已经设计好的测试用例进行测试就可以了，你需要投入测试当中，用心思考，不断完善测试要点。
做为测试人员，你需要关注系统新增的功能，这可能会有助于测试设计。
测试受到阻碍的时候，抱怨是没有用的，这时候思考一下我还能做一些什么事情。如明明测试进度很紧张，这时候CJL提出需要停机半个小时进行环境克隆。我想，那我先测试另外一单需求吧，那是是yd1环境进行测试。如测试流程受阻，那我想到是不是可以先准备其他场景的测试数据。
把握自己能够掌控的事情。在进行超时测试的时候，需要在核心系统的SVN文件中填写申请，我没有权限，只能找MB帮忙填写，他忘记填写申请一次后，我就会专门提醒他，主动跟他确认是否已经给我申请超时测试。
我希望开发人员有自己的想法。测试的最后一天，我提了一个bug：出账已经成功，出账通知书中不要展示UP1101接口返回的还在处理中的报文。这个点需求文档中没有要求，只是我基于个人思考，认为这样会给用户造成困惑，到底出账有没有成功。开发人员二话不说就说改，其实我希望他能有自己的思考。
不要开发说没问题就认为没问题了。你还是需要去实际测试，验证是否没有问题。