美文网首页我爱编程
测试分析——KYM

测试分析——KYM

作者: HQQA_5d52 | 来源:发表于2018-04-10 20:45 被阅读0次

    一、

    需求背景

    为什么要做这个需求?(包括了解目前的功能缺陷)

    需求来源是什么?

    这个需求的目的、价值是什么?

    需求用户

    有哪些用户使用该功能?(用户角色)

    用户迫切需要实现的功能是什么?

    用户现在的实现方式是怎样的?痛点是什么?

    用户将来实际使用功能的场景有哪些?

    哪些用户有使用权限?

    用户数量是多少?

    多个用户使用该功能是否有优先级或顺序的影响?

    用户之间有无业务关联关系?

    用户对系统的期望是什么?

    多个用户之间是否有矛盾点?是否已达成一致?

    需求信息挖掘

     1.咨询PM

    PM心中的实现方式是什么?是否最优?

    该功能涉及外部系统吗?怎么对接?

    该功能是否会影响历史功能?

    有没有可参考的文档?

    向谁进一步了解更详细的信息?

    该需求整体规划是什么?后续是否会改动?

    2. 数据

    实现该功能需要什么数据?

    实现该功能输出哪些数据?

    涉及的上下游系统之间数据有哪些?

    该功能对系统的数据表是否有改动?

    对数据的关键操作有哪些?

    数据之间的关系是怎样的?有没有相互制约的地方?

    3. 对象

    该功能涉及的对象有哪些?

    对象之间关系是怎样的?

    是否需要关注特殊对象实例?

    4. 流程

    该功能业务流程是怎样的?

    该功能操作流程是怎样的?

    数据流转的过程是怎样的?

    流程图的判断节点是否合理?

    每个流程是否涉及了合理的终点?

    如果有状态图,状态是否有遗漏或者冗余?

    状态之间的转换动作是否有遗漏或冗余?

    涉及上下游系统场景是什么?

    兼容性

    是否涉及浏览器兼容问题?

    是否涉及新老数据兼容问题?

    系统发布版本之间有无兼容性?

    是否涉及新老客户端兼容问题?

    不同机型是否兼容?

    风险分析

    是否会有大数据问题(大用户访问量,系统性能)

    是否需要工具测试?

    开发是否用了新的技术?

    需求点:支持关闭已完成的付款申请单

    1.需求背景挖掘

    Q:为什么提出这个需求?

    A: 生产上遇到了一种场景:供应商的银行账号维护错误,给这个供应商建付款单推到Oracle系统进行付款,OP查询到Oracle的付款信息后,将付款单的状态变为了已完成。

    而Oracle系统从银行获取到付款失败的消息后,进行调整付款,最终取消发票。OP端由于付款单已完结,关联的对账单等业务单据也已终结,无法发起重新付款,因而这个款项无法重新付款。

    Q:为什么之前设计没有考虑到这个场景?

    A:第一版设计时有了解到Oracle系统有付款调整的功能,但:

    一方面考虑到OP系统自身的复杂性,已完结的单据回退成本较大,且不是很安全。另一方面Oracle进行调整付款的可能性较小,一般都是因为银行付款失败,且会重新进行付款。

    因而对调整付款这个点,OP认为这是一笔最终还会付出去的钱,因而只是接收了一个最新的实付金额并展示,不支持做状态和流程的回退。

    其实本质上是有一个思维误区:我们认为oracle系统去做了付款这个动作,就代表这个单据最后是能够被成功付款的。

    2.需求用户分析

    付款申请单从创建到最终付款主要经历以下几个环节,对应用户如下:

    付款的异常流程处理包括以下几种情况,对应用户如下:

    1.付款失败,需要调整付款再重新付款→ 出纳

    2.发票本身有误,需要在Oracle取消发票→总部AP

    3.对应在OP需要进行的关闭操作→总部AP

    就用户层面而言本项功能是同一用户角色操作,不会存在两方系统沟通不畅的问题。

    3.需求信息挖掘

    Q:针对这种场景,除了支持关闭已终结状态的单据,有没有更好的解决办法?

    A:这个问题的核心点是由于Oracle系统单据没有完结状态,终结后还可以调整付款,再取消发票。上述描述的场景就是单据上的银行账号错误,必须重新建单来付款。

    最方便的解决办法就是OP和Oracle逻辑一致,支持付款回退和单据关闭。暂未想到更好的解决办法。

    Q:该功能涉及外部系统吗?怎么对接?

    A:涉及跟Oracle的对接,走原先的关闭接口。要关闭单据时,先向Oracle请求是否允许关闭,与原先关闭逻辑一致。

    4.需求对象提取

    1. 本次功能的主体对象为:付款申请单、红字申请单,关键操作行为:关闭

    2.对象和行为之间的关系主要包括:

    关闭操作进行后,会将这个单据引入一个终结的状态,不会有后续流程

    对象本身对这个操作有一定的制约逻辑,部分状态下才能进行关闭的操作

    5. 流程梳理

    Q:该功能期望的整体操作流程是怎样的?

    A:出现上述场景后,

    ①Oracle进行调整付款,再将原发票取消。

    ②OP将对应的付款单关闭,释放关联的对账单、预付单等单据数据。

    ③修正供应商的基础信息,将银行账号维护正确。

    ④重新建付款申请单,审批通过后推送至Oracle,走新的付款流程。

    Q:这个流程会不会对原先逻辑有冲击?

    A:对关联业务单据来讲,是支持从已付款的状态回退到了已对账待付款的状态;对对账单来讲,是支持从已完成的状态回退到了待付款的状态;对付款单来讲,是支持从已完成的状态变成了已关闭。

    整体来讲是将建付款单并完成了付款的流程抹掉,其他逻辑还可以正常进行,无其他冲突。

    6. 数据分析

    Q:这个流程的回退涉及哪些数据?

    A:本身涉及付款申请单,另外:

    如果是经销供应商的付款,涉及经销对账单、采购单、采购退货单、供应商费用单、预付申请单

    如果是代销供应商的付款,涉及代销对账单、供应商费用单

    如果是直配供应商的付款,涉及直配对账单、供应商费用单

    7.其他风险分析

    Q:已完成状态的单据可以被关闭,会不会由于误操作带来其他隐患?

    A:如果单据状态变为了已完成,代表这个单据在Oracle系统是发起过付款操作的。因而正常来说误操作去关闭单据不会成功,Oracle会拒绝这个关闭请求。真的会关闭成功的情况是Oracle已经取消了发票。

    PS:后面整理的测试覆盖点

    相关文章

      网友评论

        本文标题:测试分析——KYM

        本文链接:https://www.haomeiwen.com/subject/ogtohftx.html