• 场景测试-支付场景


     软件测试人员在进行测试的时候,根据测试项目或者测试对象的不同,会采用不同的方式方法来进行测试,那么,带有支付功能的产品该如何测试呢?在测试过程中又应该注意些什么?

     大概的思路:金额(对、错、空等),支付流程,使用设备,绕过前端直接调取接口支付,支付失败处理:补单、退款等,网络导致的失败等待,在设计测试用例尽量落实在每一个数据核对

            财务人员有句老话叫:财务无小事。因为,首先,任何涉及到财务的问题,不论金额有多么的小,它在性质上也是严重事件;其次,在各种金融支付功能已深入老百姓生活的方方面面的今天,一个程序中,哪怕仅有一个小小的支付问题,那么,最后引起的也可能是涉及成百上千乃至上亿元金额和大量用户的大问题。
            因此,专业的测试人员,在对待带有支付功能的产品时,都会格外的小心谨慎,将边界值分析、等价类划分、错误推测、因果图等各种测试方法进行结合,整理出尽可能全面的测试案例,对该支付功能及其相关功能进行测试,以确保整个支付流程以及涉及到支付流程的其他流程在任何情况下都能正常进行。
            简单总结一下测试的思路:
            从金额上:包括正常金额的支付,最小值的支付,最大值的支付,错误金额的输入(包括超限的金额、格式错误的金额、不允许使用的货币等等);
            从流程上:包括正常完成支付的流程,支付中断后继续支付的流程,支付中断后结束支付的流程,支付中断结束支付后再次支付的流程,单订单支付的流程,多订单合并支付的流程等等;
            从使用的设备上:包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等;
            从支付接口上:包括POSE终端机支付、银行卡网银支付、支付宝支付、微信支付、手机支付等;
            从产品容错性上:包括支付失败后如何补单或者退单、如何退款等;
            从后台的账务处理上:成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。
            还有其他需要考虑的问题这里就不再赘述了,总之,在测试过程中,测试人员要将以上各种情况都综合考虑到,根据这些情况来编写最少量但尽可能发现最多问题的测试案例,并且严格按照案例来执行测试,只有经过最严谨的测试的支付功能,才能够尽可能的避免上线后出现生产问题。

  • 相关阅读:
    在 .NET 3.5 中序列化和反序列化 JSON Kevin
    .NET 3.5 获取不全Cookie的问题 Kevin
    C#反序列化JSON数组对象 Kevin
    使用ConfigurationManager类 读写配置文件 Kevin
    C# post数据时 出现如下错误: System.Net.WebException: 远程服务器返回错误: (417) Expectation Failed 的解决办法 Kevin
    .NET 关于反序列化 JSON 对象数组的问题 Kevin
    为什么调用thread.Abort(),线程不会马上停止 Kevin
    vs2005调用迅雷完美解决方案 Kevin
    .NET 复杂的 DataBinding 接受 IList 或 IListSource 作为数据源 Kevin
    找不到DataContract属性! Kevin
  • 原文地址:https://www.cnblogs.com/test_home_c/p/9399323.html
Copyright © 2020-2023  润新知