随着调测版本发往一线测试任务也告一段落，此次版本主要特性之一是PaymentHub集成，当用户购买产品进行支付时，可以选择多种支付方式，如Paypal、Credit Card、积分、CashU等，而自己主要负责CashU相关功能。CashU是第三方支付系统，支付时系统构造Post请求消息跳转到CashU侧，支付完成后再携带相关参数跳转回来，触发查询以及确认交易流程。
测试设计阶段，了解主要功能实现流程，从接入门户、用户类型以及产品类型入手设计用例，再将其他场景考虑进去，总体上来看，没有什么难度，其实在测试时也没遇到阻碍，较为顺畅，不过也有稍许收获。
一、用例设计，用例设计一块依旧是短板，虽然也是一直是在努力提升，但收效甚微，从单一的用例来说，包含详细的步骤，重要关注点以及后台流程，从场景覆盖的角度来说，绝大部分场景都能覆盖到，但是如果按照用例执行，虽说可以发现一些问题，但比较有限，可能与这次是使用模拟桩有关。于是在尽力写好用例的基础上，执行用例时只是作为一个引导和参照。
二、接口关注，对于第三方支付系统的测试，对外暴露的接口需重点关注，在系统测试时，并没有与真实部件对接，而是使用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，场景阐述清晰明了，但扼住重要；开发则是简化到某个流程的接口报错了；对于单部件测试，提供的信息则是越详细越好。
此次版本，自己也有少许收获，发觉自己的思维也在逐渐改变，比起以往单纯的看问题单数，更喜欢去挖掘稍有深度的问题，愿能更进一步。
版权声明：本文出自 forstkksk 的51Testing软件测试博客：http://www.51testing.com/?600991
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
