近期测试小获

        测试设计阶段，了解主要功能实现流程，从接入门户、用户类型以及产品类型入手设计用例，再将其他场景考虑进去，总体上来看，没有什么难度，其实在测试时也没遇到阻碍，较为顺畅，不过也有稍许收获。

    一、用例设计，用例设计一块依旧是短板，虽然也是一直是在努力提升，但收效甚微，从单一的用例来说，包含详细的步骤，重要关注点以及后台流程，从场景覆盖的角度来说，绝大部分场景都能覆盖到，但是如果按照用例执行，虽说可以发现一些问题，但比较有限，可能与这次是使用模拟桩有关。于是在尽力写好用例的基础上，执行用例时只是作为一个引导和参照。

   二、接口关注，对于第三方支付系统的测试，对外暴露的接口需重点关注，在系统测试时，并没有与真实部件对接，而是使用tomcat模拟桩给出回执消息，这就是为何用例覆盖到了，但是却未能测出问题的原因之一。对于此次测试，通过对接口抓包看码流消息，发现了不少问题，可以归纳为三类：

    第一类，消息体正确性，通过抓包得到的码流与WSDL进行对比，虽然重要参数正确，但是一些对于参数的描述并未与WSDL一致，与开发沟通后，确认需要修改

    第二类，参数安全性，因为是与第三方系统对接，对于秘钥相关参数一定要加密后传出去，而不是抓个包就展现出。此次CashU支付方式，是将一些参数先转换为小写再进行加密，就在这里差点就漏了一个问题，总体方案以及部件规格未曾涉及，而预置的某些参数都是小写，这块又是由上游部件保障，之前并未关注，在最后几天，对比CashU接口文档，发现提及此处（convert to lower case，差点看漏了），验证发现此问题。

    第三类，参数一致性，因为在支付流程中，对于暴露出的接口定义是由CashU系统定义的，而对于某些未定义的非必选字段，各部件定义就可能会不一致。此次测试的流程是，系统-CashU-系统，先向CashU系统发起创建交易，后构造post请求去CashU系统，但是CashU系统又是用模拟装模拟，在测试时，不仅需要使用Httpwatch观察Post请求消息中携带的参数，还得关注模拟CashU跳转回携带的参数，而这些参数，有些是在创建交易时携带过去的，需要保持一致性。

     三、挖掘后续bug，一个小bug的发现再往后延伸或许能发现其他问题。此次也是这般，无意间往后延伸了下，发现不同门户在创建交易时，这块逻辑实现有些差异，向USE（Union SE，总体方案编写者）反馈，USE答复是前阶段的CR未完全落实。虽然发现这问题存在幸运的成分，不过也提醒了自己，多往后想想或许会有其他收获。

      四、流程思考，这样实现就没问题么？也许现在看来有些夸张了，但是确实得去这样思考，遇到方案性问题，首先会自己先思考一下，如何实现。此次测试时，也遇到一个流程实现问题，USE问我这个问题你觉得怎么解决，虽然很想直接说修改这个接口传参，但还是通过邮件方式发出问题，最后USE给出更完善的解决方法，彻底杜绝了类似问题，当时觉得自己目光太短浅了，为了解决问题而解决问题。对于自己，后面的路还长着呢，需要多想，提升看问题的高度。

      五、沟通，与USE、开发以及测试沟通。

   USE的思维相当跳跃，有时候没办法跟上，不过在向USE阐述问题时，先准备好想表达的事情，开头需要一句总结，具体什么问题，影响了哪些流程，之后再详细描述，厉害的最好能附加上自己观点

   与部件测试沟通也是必要的，很多部件实现的功能，虽说发起端受前台控制，但是也得清楚后台的相关配置项，遇到问题时，先请单部件测试进行协助。

   与开发沟通，当问题存在不确定性时，流程描述下再附上相关日志，有时此部件报错是由于下游部件传参问题导致，需先确认，避免无效单或者提错部件,确认时间需要控制在10分钟之内，不行先提着跟着，避免漏掉。

   虽说沟通对象不同，但是一切得基于对流程的熟悉程度，再者根据角色，需要采取不同的方式，比如USE，场景阐述清晰明了，但扼住重要；开发则是简化到某个流程的接口报错了；对于单部件测试，提供的信息则是越详细越好。

       此次版本，自己也有少许收获，发觉自己的思维也在逐渐改变，比起以往单纯的看问题单数，更喜欢去挖掘稍有深度的问题，愿能更进一步