2018年年底，接手了先后两个质控同事都跟进过然后因故没做的功能模块，回顾这么多年的工作经历，很多经验都没有形成文字形式保存，而这次的测试出现的问题也比较能涵盖之前的工作总遇到的问题，故总结文字记录之：
App—要约收购解除
一、应用端委托成功，生产了委托单，方向买入，资金扣减了
业务理解：解除业务是T+1日返回成交确认，当日不应该进行资金持仓扣减，怎么会扣减？
找原因：到交易系统查询委托详情，发现委托属性不是要约收购解除
问题：接口调错了，调了买入的接口
总结：对于调周边接口的应用，界面返回的成功、失败应答需要有深入质疑的精神，刨根究底，确定返回的数据不是伪应答
二、收购期限届满前三个交易日不可做解除
场景：包含周六日时，是否可以做业务
原因：开发没理解到交易日的概念
总结：对行内业务要有敏感度，方能充实测试场景
三、需求原型和UI设计均显示：收购人代码 字段名
业务理解：个人根据交易所官方文档，文档中均定义的是：收购编码
原因：产品经理直接借鉴了hs交易系统的界面，直接就定义为收购人代码
总结：测试不应该是基于产品经理设计的原型，而是基于官方业务和客户实际需求来做测试
四、深市解除需要判断可解除数量，委托数量满足可解除数量方可解除
问题：因为没有存量可做解除的数据，委托订单无法生成，测试场景无法执行
分析：按照整个的PM流程，该问题在开发自测，产品经理验收时，就应该暴露出来，因为其他同事的工作遗漏，最终流落到质控测试组。
困难：为了完成场景执行，需要解决可解除数量是怎么算出来的，进而造业务数据，需求经理忙碌。。。开发和接口供应商沟通后答复质控需要在xx表加数据即可，我在几个环境中找了历史数据，仿造了几笔，仍然无法完成场景执行，与开发沟通，开发继续和供应商沟通，答复仍然是在xx表加数据即可。时间就这样过去了，工作进度没有推进。。。后，我直接和接口供应商联系，提供log日志，针对供应商的开发的答复提出了自己的疑问，确认了xx表某几个字段的含义和来龙去脉，最终造出正确的数据，解决此问题。
总结：工作各司其职没有问题，但上游应该规避的问题最终流落到我们手中，如何能快速解决问题是第一要务，不要觉得这个问题是上游导致的，然后就耗着，停滞不前，等待上游去返工解决（当然如果上游有快速解决问题的能力最好），总的来说，就是要有主动型，遇到问题的时候需要动起来，而不是坐等，最后跟领导反馈说遇到xx问题阻塞，应该是上游xx来解决的，因为他解决不了，我这里无法开展