各位评委，我是xx，目前负责xx中心的业务测试。
下面我会根据这4部分来叙述
首先介绍下我在xx公司做什么？
我是2021年7月份来xx公司的，到今天已经有755天了。这两年里我一直在xx中心，参与了xx中心从无到有的过程。那么为什么会有xx中心？xx公司里的分账是由各个业务侧自己做的。比如xx有自己的分账，xx也是，分账能力相对分散，用户使用多个业务侧分账操作相对复杂。为了……成立xx中心。简单来说就是为各个业务侧提供平台分账能力，我的工作就是保证分的钱要对，不能多分也不能少分。
那么xx系统是如何运转的，我划了个简单的流程图，xx是承接订单，以xx配置结合业务侧来计算分佣。
下面是价值产出，价值产出会以以下3点来分别叙诉 首先是业务测试，这是我在xx负责的已经上线的业务分账，这张图大家能看出来涉及到也业务侧有很多，各个订单类型都有。这就导致我在做业务测试时会有这些痛点，
下面是我对这些痛点的解决，作为一个类似中台的系统，对一些常规的业务场景我肯定是了解的，但我肯定没有他们测试了解的那么全面。为了解决场景漏测，我会牵头去梳理上下游的业务场景，将一些特殊场景结合xx配置设计测试用例记录到用例库。也为了及时了解业务的变更，与业务测试紧密合作，落地到人，比如订单对接层，我就会找增辉，并协助他了解xx对接接口的一些需要重点关注的字段。前期也会让产品研发对场景字段做一些梳理，落地成文档。
下面是提测质量，对于研发来说，xx的前置条件太多，导致研发在提测前冒烟都是单园测试或者改数据自测，导致提测质量很差，q1的冒烟通过率不到40%，为了解决这一问题，我跟研发沟通决定q2冒烟通过率要达到80才算冒烟通过，否则打回。执行后效果很好，但也出现其他问题，冒烟是通过了，但其他模块有影响。所以在q3，我又在冒烟测试通过率90的基础上加了自动化通过率100。目前正在执行中。
下面是一些数据统计，其中bug工单26个，xx21个，xx中心5个；两个系统的情况不同，解决方案也不同，下面我会分别叙述
xx，我是22年8月份接手的，接手之后没有做任何迭代。没想到元旦节爆发，一周来了15个工单。针对工单问题，紧急处理。数据也在1周内修复。后成立专项测试小组；针对门店业绩测试之后又发现bug14个，专项测试完成后，效果显著，可以看右侧曲线图，后续基本没有再出现什么生产事故。
xx中心，bug不多，今年有5个，主要采取的措施是并发问题先修数据，后续优化。这个流程问题是我没评估好，以为用的不多，所以没有上报；导致后续有商户做活动正好是bug出现的场景。后续也自我反省了；测试发现问题及时抛出，场景遗漏确实是xx的痛点问题，发现问题及时更新通用测试用例库，确保一个坑不能掉两次。
随着功能越来越多，人工测试压力也越来越大，开始考虑到如何提效。下面是针对平时工作做的一些提效类的事情。
下面主要说下xx的自动化，随着功能的不断完善，回归的任务越来越大，xx计算还没有对应的页面，导致我回归的时候只能看数据库，字段太多，人为check也很吃力，还容易出错。我开始考虑自动化，常规接口自动化是模拟请求，check响应，场景也是一个接口一个接口链路测试；但xx的前置依赖方太多，核心场景很多需要实际支付。为了解决这个问题，我制定了一套自动化方案，
针对xx特殊的架构：基于xx配置快照和业务快照，同一笔订单反复进入分账计算，结果必须是一致的。我其实只要确保某个场景下的一笔订单分佣是正确的，那我拿这笔订单数据反复去喂给我们xx系统，得到的分佣结果数据，自动化就可以check出有没有问题。为了方便理解我也化了个流程图；主要就是以订单数据为驱动，把xx表和账单表，redis数据清理掉，再重新把这笔订单喂给xx系统，最终check跟我人工确认的数据一致就算断言通过了。
目前自动化也发现了bug4个，自动化测试用例267条，覆盖了业务场景60%，后续也会继续完善。这个方案大家肯定也知道它其实只能保证内部分账逻辑有没有问题，无法保证业务数据的准确性；我也想过这个问题，后续可能会针对这一方面再做改进。计划是写个自动化脚本抽查xx拿到的订单数据和订单详情页做一些关键数据的对比来保证数据的准确性。
关于团队赋能，我沉淀出xx业务文档9份，协助xx等相关业务部门同事操作分账，开发一些小工具分享给同事，提高同事工作效率；在部门内主持xx测试案例分享会，也将xx的自动化实现方案在组内培训过。并且我了解到目前导购业绩也是用的我这套方案，还挺开心的。
下面是我的晋升理由，其实我觉得我的价值产出就是我的晋升理由
下面是我的未来规划：在质量管理上做一些改进；比如需求分析及评审，我希望未来我可以根据自己对业务的了解在需求评审中给出一些好的建议以及前期的风险评估。在未来的工作中继续降低工单数，完善自动化。
以上就是我的全部述职报告，谢谢。
