测试场景组件化轮子——用例元

https://edu.csdn.net/course/detail/28103

哎，奴婢实在是难啊，操作场景、环境特性、设备特定、业务坑等，要么难以自动化，要么由于新人经验不足，要么测试人员变更导致移交不充分，要么长时间后的遗忘等多种因素导致重复漏测，归根结底，没有将测试经验进行很好的复用及流传。

针对当前痛点，既然开发能够将各种通用方法进行组件化封装和流用，为啥测试这边就不行呢？以组件化的思想为引导，并贴合京东测试内部的实际情况，提炼出京东测试场景组件化轮子 – 用例元。

接下来，介绍一下顺丰国际物流app用例元的前世今生演变过程。

外界看来，测试门槛低，不就是点点点嘛，所谓外行看热闹，内行看门道，拿到一个需求后，如何能够在短时间内梳理出测试思路，对功能进行可测性拆分后场景扩展覆盖，做到精准化测试，并且对测试结果做到清晰化评估、高覆盖度才是合格的测试，而非盲目的点点点。

更多学习资料:https://edu.csdn.net/course/detail/25768
更多学习资料：https://edu.csdn.net/course/detail/22948

毫不自夸的说，我们内部都是高素质、高负责的测试伙伴，对于需求的测试也尽心尽力，但为啥没有达到预期效果？更多的还是缺少了系统性思维的指引以及对于历史经验的加持，所以更多的都是单纯从产品文档出发，未转变为测试框架中的一部分来进行扩展而导致覆盖度不够，故而需从问题源头探讨解决方案。

需求功能点，我都按照产品文档覆盖了，自认为质量过关，可是上线就出问题，所谓测试过程的问题都是小问题，线上问题都是大问题，毕竟我们是DAU上千万的超级app，任何一个小小的过失有时都会引发大范围的客诉。也正是因为我们线上的大流量用户，各用户的设备、网络、系统、设置项等组合项就特别多，这块同时也体现了移动端测试的特性：操作场景多样性、设备多样性、环境多样性……

从被测对象出发，搜集线上各类型的问题进行复盘总结后其实不难发现，影响到被测功能的一个非常重要的点就是外部影响因子，我们的测试环境都是相对干净，所以测试是在没有太多外界干扰的情况下进行的，结果当然是相对比较完美，功能逻辑也都能走的通，但就在功能逻辑闭环过程的各个节点上如果存在各种影响因子的介入时，就会发现又一个新大陆，也就是异常分支逻辑如果考虑不周，整个功能就会异常薄弱。

究竟存在多少影响因子？这是一个相对繁杂的工程，纯粹拍脑袋是行不通的，通过大概1年的测试数据的沉淀，从测试过程经验总结以及线上bug中进行问题原因的剖析，问题归类，类别提炼等过程，大概梳理出如上图中所罗列的11+的因子点。

接下来如何运用这些因子也是面临的一个难题，我们需要将这些因子无缝的融入到我们的测试观点中，并且形成一定的方法论，做到用例覆盖流程化。

https://edu.csdn.net/course/detail/28103

测试是一门艺术，如何体现我们的专业性，那就是测试过程有章可循，在吸收业界以及自身经验的同时，融合顺丰国际物流app自身的特性，将测试过程中的各项工作进行了测试策略（维度）的划分，使得我们测试工作更加具有方向性和针对性，在拿到一个需求后，对于需求来说我们需要如何开展测试工作，从哪些方面思考测试点，有哪方面的影响因素等有个清晰的认识，这样在用例编写时能够有思维扩散的引导作用，非常重要。

在前期做了方法论的输出之后，虽然给到了测试人员的用例编写指引，但依旧停留于思想理论层面，如何将思想转变为赋能，就需要将抽象化内容进行实际的书面化用例提炼，在经过了提炼梳理之后，最终形成了6大类的用例元，分别为：APP GUI用例元、功能接口用例元、PC兼容性用例元、移动端兼容性用例元、专项测试用例元、通用业务用例元，如下图：

更多学习资料:https://edu.csdn.net/course/detail/25768
更多学习资料：https://edu.csdn.net/course/detail/22948

第一类：APP GUI用例元

该类中按照京东app内所涉及到的全部控件进行了罗列，然后根据各自控件的特性分别进行的验证点的描述，做到了控件级别的用例覆盖最大化。

第二类：功能接口用例元

针对服务端接口，请求报文、返回报文、接口逻辑的正向及负向的入参方式，上线流程等通用例，让服务端接口测试做到更加的全面性。

第三类&第四类：PC兼容性用例元、移动端兼容性用例元

针对PC端实现的业务，从硬件和软件两块来进行兼容方面的扩展；针对移动端，按照业务实现方式的类型来划分：APP原生（RN）、H5、小程序等进行软硬件兼容性拓展，覆盖目标设备的映射绑定，对于设备的兼容范围做了明确化的设备选取规范，在后期的测试过程中，只要按需从提供的列表中进行选取设备即可，不用担心兼容因素覆盖不全的困扰。

第五类：专项测试用例元

针对移动端特性所抽出的无业务强耦合的7大类专项方向，各专项方向的测试目标、检测点、测试方法的扩展。此处的专项用例元是整个用例元的核心部分，将移动端特性展现得淋漓尽致，所分成的7个子专项方向，分别输出了各自范围内的详细用例，可单独进行测试，也可以融入至业务逻辑功能中作为业务场景的补充，比如其中的用户交互类，将站在用户操作视角下，用户对于设备所能进行的操作场景进行非常全部的覆盖，如各类用户操作手势交互、键盘交互、不同厂商ROM的定制化功能交互、APP的长时间放置等，做到了不仅仅明确方向，而且形成详细的用例说明；其他维度的专项同理。

第六类：通用业务用例元

针对业务方向，业务实现所使用的通用组件、框架、编码、实现方式等，各业务有耦合的功能所踩过的坑、注意点、检查方法。

其中第五类及第六类中都有涉及到业务类的用例元，为啥会存在两份？主要考虑是否有业务强耦合关系，如果存在业务强耦合关系的场合，就需要在接入相关业务的时候来使用，如果无业务强耦合关系的场合，就是所有业务测试过程中都需要注意的，这样会使得用例选择时较为明朗。

用例元处于不断的更新迭代之中，不断有新的测试形态、新的影响因子、新的业务坑等出现，在平时测试过程中穹天平台有产线缺陷分析环节，其中加入了是否可提炼为用例元的标签，可以集思广益，在不久的将来用例元将会形成一套完善的测试宝典库。

回顾测试过程，一直不断倡导测试工作效率化、流程化，除了不同维度自动化提升、流程改善，额外就是希望不要在同一个地方摔倒多次，如何将经验集进行场景及书面化的输出，起到通用性测试场景赋能是本次核心的主题。通过测试方法及场景的提炼，重新结构化排布所落地的通用元，方便新人的快速入手，提供测试指引；同时对老人拓展测试思路提供帮助；业务之间的经典场景互通，相互补充，发挥最大效能。

显然这是个长期不断迭代的过程，道阻且长，但意义非凡。