测试场景组件化轮子——用例元
发布时间：2020-03-13 15:24:42 所属栏目：资源 来源：站长网
导读：背景介绍 当今的移动端 测试 已经进入白热化阶段，各种测试维度、方法、工具化、效率化遍地开花，同时对于测试工程师的要求越来越高，需要做的就是不断创造新的测试场景，并将场景自动化，实现高效迭代，周而复始，一切都很美好。但不得不承认的是，有了各
背景介绍 当今的移动端测试已经进入白热化阶段，各种测试维度、方法、工具化、效率化遍地开花，同时对于测试工程师的要求越来越高，需要做的就是不断创造新的测试场景，并将场景自动化，实现高效迭代，周而复始，一切都很美好。但不得不承认的是，有了各种工具化建设就完美了么？线上就没有漏测发生么？归根溯源，“人”是核心，对测试工程师来说点点点的时代已经过去，我们在各种效率化、自动化释放人力的基础上，更多的是要发挥职业自身探索性、经验性的能力，这个是工具所不能替代的，尤其是在京东作为业务型驱动的公司来说，不断衍生出新的业务形态，测试工程师的人工介入在一定程度上也显示尤为重要。 “这个场景操作我不知道呀，漏测我也没办法” “其他项目已经出现过这个bug了，怎么现在又发生了？” “相同的问题为啥多次发生，为啥没有回归到，自动化不能覆盖么？” …… 哎，奴婢实在是难啊，操作场景、环境特性、设备特定、业务坑等，要么难以自动化，要么由于新人经验不足，要么测试人员变更导致移交不充分，要么长时间后的遗忘等多种因素导致重复漏测，归根结底，没有将测试经验进行很好的复用及流传。 针对当前痛点，既然开发能够将各种通用方法进行组件化封装和流用，为啥测试这边就不行呢？以组件化的思想为引导，并贴合京东测试内部的实际情况，提炼出京东测试场景组件化轮子 – 用例元。 接下来，介绍一下京东app用例元的前世今生演变过程。 用例元演化 外界看来，测试门槛低，不就是点点点嘛，所谓外行看热闹，内行看门道，拿到一个需求后，如何能够在短时间内梳理出测试思路，对功能进行可测性拆分后场景扩展覆盖，做到精准化测试，并且对测试结果做到清晰化评估、高覆盖度才是合格的测试，而非盲目的点点点。 毫不自夸的说，我们内部都是高素质、高测试Sense、高负责的测试伙伴，对于需求的测试也尽心尽力，但为啥没有达到预期效果？更多的还是缺少了系统性思维的指引以及对于历史经验的加持，所以更多的都是单纯从产品文档出发，未转变为测试框架中的一部分来进行扩展而导致覆盖度不够，故而需从问题源头探讨解决方案。 需求功能点，我都按照产品文档覆盖了，自认为质量过关，可是上线就出问题，所谓测试过程的问题都是小问题，线上问题都是大问题，毕竟我们是DAU上千万的超级app，任何一个小小的过失有时都会引发大范围的客诉。也正是因为我们线上的大流量用户，各用户的设备、网络、系统、设置项等组合项就特别多，这块同时也体现了移动端测试的特性：操作场景多样性、设备多样性、环境多样性…… 从被测对象出发，搜集线上各类型的问题进行复盘总结后其实不难发现，影响到被测功能的一个非常重要的点就是外部影响因子，我们的测试环境都是相对干净，所以测试是在没有太多外界干扰的情况下进行的，结果当然是相对比较完美，功能逻辑也都能走的通，但就在功能逻辑闭环过程的各个节点上如果存在各种影响因子的介入时，就会发现又一个新大陆，也就是异常分支逻辑如果考虑不周，整个功能就会异常薄弱。 究竟存在多少影响因子？这是一个相对繁杂的工程，纯粹拍脑袋是行不通的，通过大概1年的测试数据的沉淀，从测试过程经验总结以及线上bug中进行问题原因的剖析，问题归类，类别提炼等过程，大概梳理出如上图中所罗列的11+的因子点。 接下来如何运用这些因子也是面临的一个难题，我们需要将这些因子无缝的融入到我们的测试观点中，并且形成一定的方法论，做到用例覆盖流程化。 测试是一门艺术，如何体现我们的专业性，那就是测试过程有章可循，在吸收业界以及自身经验的同时，融合京东app自身的特性，将测试过程中的各项工作进行了测试策略（维度）的划分，使得我们测试工作更加具有方向性和针对性，在拿到一个需求后，对于需求来说我们需要如何开展测试工作，从哪些方面思考测试点，有哪方面的影响因素等有个清晰的认识，这样在用例编写时能够有思维扩散的引导作用，非常重要。 在前期做了方法论的输出之后，虽然给到了测试人员的用例编写指引，但依旧停留于思想理论层面，如何将思想转变为赋能，就需要将抽象化内容进行实际的书面化用例提炼，在经过了提炼梳理之后，最终形成了6大类的用例元，分别为：APP GUI用例元、功能接口用例元、PC兼容性用例元、移动端兼容性用例元、专项测试用例元、通用业务用例元，如下图： 当前阶段对于用例元的整体框架已经形成，目标也逐步的清晰，除了业务本身逻辑以外的通用类用例都交由用例元来完成，这6大类的用例元几乎涵盖了移动端测试的方方面面，可以作为测试用例组件在测试过程中直接来引用，跳过了重新编写这块用例的步骤，各用例元中间所包含的内容又是如何分布的呢，接下来在用例元分类章节中分别进行阐述。 用例元分类 第一类：APP GUI用例元 该类中按照京东app内所涉及到的全部控件进行了罗列，然后根据各自控件的特性分别进行的验证点的描述，做到了控件级别的用例覆盖最大化。 第二类：功能接口用例元 针对服务端接口，请求报文、返回报文、接口逻辑的正向及负向的入参方式，上线流程等通用例，让服务端接口测试做到更加的全面性。 第三类&第四类：PC兼容性用例元、移动端兼容性用例元 针对PC端实现的业务，从硬件和软件两块来进行兼容方面的扩展；针对移动端，按照业务实现方式的类型来划分：APP原生（RN）、H5、小程序等进行软硬件兼容性拓展，覆盖目标设备的映射绑定，对于设备的兼容范围做了明确化的设备选取规范，在后期的测试过程中，只要按需从提供的列表中进行选取设备即可，不用担心兼容因素覆盖不全的困扰。 第五类：专项测试用例元 针对移动端特性所抽出的无业务强耦合的7大类专项方向，各专项方向的测试目标、检测点、测试方法的扩展。此处的专项用例元是整个用例元的核心部分，将移动端特性展现得淋漓尽致，所分成的7个子专项方向，分别输出了各自范围内的详细用例，可单独进行测试，也可以融入至业务逻辑功能中作为业务场景的补充，比如其中的用户交互类，将站在用户操作视角下，用户对于设备所能进行的操作场景进行非常全部的覆盖，如各类用户操作手势交互、键盘交互、不同厂商ROM的定制化功能交互、APP的长时间放置等，做到了不仅仅明确方向，而且形成详细的用例说明；其他维度的专项同理。 第六类：通用业务用例元 针对业务方向，业务实现所使用的通用组件、框架、编码、实现方式等，各业务有耦合的功能所踩过的坑、注意点、检查方法。 其中第五类及第六类中都有涉及到业务类的用例元，为啥会存在两份？主要考虑是否有业务强耦合关系，如果存在业务强耦合关系的场合，就需要在接入相关业务的时候来使用，如果无业务强耦合关系的场合，就是所有业务测试过程中都需要注意的，这样会使得用例选择时较为明朗。 用例元维护 用例元处于不断的更新迭代之中，不断有新的测试形态、新的影响因子、新的业务坑等出现，在平时测试过程中穹天平台有产线缺陷分析环节，其中加入了是否可提炼为用例元的标签，可以集思广益，在不久的将来用例元将会形成一套完善的测试宝典库。 用例元赋能案例 用例元的详细用例已经与穹天平台（测试生命周期管理平台）进行的流程上的打通，在需求测试时，通过测试策略的引导流程，指引用户去创建各类型的测试用例，其余涉及到的6大类的用例元，无需测试人员单独编写，只需要进行勾选操作就能够作为当前的需求测试所使用，当前的用例元被测试团队引用次数已超过4000+。 其中的通用业务用例元，将赋能充分扩散，应用至大促活动的范畴，比如会场类的活动形态相对单一，验证内容也比较集中，将会场类用例进行通用性的抽出，省去了测试人员重复编写开发自测用例及测试用例的时间，而且能够保证验证点的不遗漏，做到效率的提升。 在整个大促过程中，测试团队消化了50+的活动，无严重问题漏测。 最后，为了让团队能够从根本上理解用例元的核心概念思想，对用例元的前世今生做了一次全员宣导会议，不单单知道如何利用平台使用用例元，而且也能够对各用例元的落地过程有深入理解，希望后续工作中对用例元的丰富工作起到推动作用。 写在最后 回顾测试过程，一直不断倡导测试工作效率化、流程化，除了不同维度自动化提升、流程改善，额外就是希望不要在同一个地方摔倒多次，如何将经验集进行场景及书面化的输出，起到通用性测试场景赋能是本次核心的主题。通过测试方法及场景的提炼，重新结构化排布所落地的通用元，方便新人的快速入手，提供测试指引；同时对老人拓展测试思路提供帮助；业务之间的经典场景互通，相互补充，发挥最大效能。 显然这是个长期不断迭代的过程，道阻且长，但意义非凡。 基础根基的手工探索性测试工作 + 工具化&平台化的加持 = 高质量的京东app。（编辑：武汉站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |