测试场景组件化轮子—

背景介绍

当今的移动端测试已经进入白热化阶段，各种测试维度、方法、工具化、效率化遍地开花，同时对于测试工程师的要求越来越高，需要做的就是不断创造新的测试场景，并将场景自动化，实现高效迭代，周而复始，一切都很美好。但不得不承认的是，有了各种工具化建设就完美了么？线上就没有漏测发生么？归根溯源，“人”是核心，对测试工程师来说点点点的时代已经过去，我们在各种效率化、自动化释放人力的基础上，更多的是要发挥职业自身探索性、经验性的能力，这个是工具所不能替代的，尤其是在顺丰作为业务型驱动的公司来说，不断衍生出新的业务形态，测试工程师的人工介入在一定程度上也显示尤为重要。

“这个场景操作我不知道呀，漏测我也没办法”

“其他项目已经出现过这个bug了，怎么现在又发生了？”

“相同的问题为啥多次发生，为啥没有回归到，自动化不能覆盖么？”

了解更多测试知识访问如下链接：

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

https://edu.csdn.net/lecturer/3215

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

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

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

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

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

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

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

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

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

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

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

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

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

了解更多测试知识访问如下链接：

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

https://edu.csdn.net/lecturer/3215

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

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

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

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

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

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

第一类：APP GUI用例元

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

第二类：功能接口用例元

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

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

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

了解更多测试知识访问如下链接：

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

https://edu.csdn.net/lecturer/3215

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

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

第五类：专项测试用例元

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

第六类：通用业务用例元

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

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

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

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

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

了解更多测试知识访问如下链接：

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

https://edu.csdn.net/lecturer/3215

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

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

测试场景组件化轮子——用例元相关推荐

Android组件化开发，其实就这么简单
组件化,在实际的业务开发中,越来越多的会使用这种方式,特别是业务逻辑复杂,功能模块较多的项目,越能凸显出组件化的优点,比如各个模块拆分,使其业务分明,比如耦合度低,组件之间相互独立,再比如编译运行速度 ...
Android组件化原理
Android组件化原理什么是组件化? 为什么使用组件化? 一步步搭建组件化组件化开发要注意的几点问题 1.新建模块 2.统一Gradle版本号 3.创建基础库 4.组件模式和集成模式转换 5.A ...
微服务时代组件化和服务化的抉择
作者:vivo 互联网服务器团队-Yao Wenyu 随着业务系统的复杂性越来越高,系统之间的调用也越来越多,在微服务拆分和迭代过程中,是不断的拆分出新的独立的服务还是封装独立的组件以jar包依赖的方 ...
vue（9）—— 组件化开发 - webpack（3）
前面两个终于把webpack相关配置解析完了.现在终于进入vue的开发了 vue组件化开发预热前期准备创建如下项目: app.js: footer.js: main.js: webpack.con ...
[Android Pro] 由模块化到组件化(一)
cp from : https://blog.csdn.net/dd864140130/article/details/53645290 在Android SDK一文中,我们谈到模块化和组件化,现在我 ...
Android 开发:由模块化到组件化(一)
在Android SDK一文中,我们谈到模块化和组件化,现在我们来聊聊组件化开发背后的哪些事.最早是在广告SDK中应用组件化,但是同样适用于普通应用开发以下高能,请做好心理准备,看不懂请发私信来交流 ...
基于云开发的答题活动小程序v2.0-结合具体场景谈谈路由传参以及组件化思想
项目技术栈微信原生小程序+云开发.我这里主要使用了云开发能力中的小程序端SDK,说白了就是在javascript中就能直接操作数据库. 本篇前言基于云开发的答题活动小程序v2.0的源码地址,以及手 ...
面向接口编程实施模块化/组件化解耦，以友盟、极光等统计分析为例
模块化/组件化通过模块化/组件化组织代码,面向接口编程,尽可能做到高内聚.低耦合.重复用. 模块可分为多种类型,一般分为:基础库(日志打印.网络请求.图片加载等).三方包(微信登录.统计分析.消息推 ...
iOS 组件化 —— 路由设计思路分析
原文前言随着用户的需求越来越多,对App的用户体验也变的要求越来越高.为了更好的应对各种需求,开发人员从软件工程的角度,将App架构由原来简单的MVC变成MVVM,VIPER等复杂架构.更换适合业 ...

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

测试场景组件化轮子——用例元相关推荐

最新文章

热门文章