首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >测试效能平台最佳实践 | 解决用户痛点,比堆叠功能更重要!

测试效能平台最佳实践 | 解决用户痛点,比堆叠功能更重要!

原创
作者头像
霍格沃兹测试开发
修改2020-08-24 17:56:32
7140
修改2020-08-24 17:56:32
举报
文章被收录于专栏:测吧测试开发测吧测试开发

测试效能平台开发的难点是什么?

关于测试效能平台开发,从技术上提供指导的文章网上比比皆是,但从 0 到 1 全面阐述测试平台开发实战经验的文章就相对较少。

而且,即使对于不那么擅于写代码的测试同学而言,在平台开发过程中,技术其实也没什么难点。

最难的点在于你要利用最少的资源,在最快的时间内,选择最合适的实现方案来解决团队中特定的问题。

本文就记录分享一下我在公司国际化商城项目中,作为智能物料项目 PO,从零搭建一个快速创建测试物料的工具平台的一些心得和经验。该项目在四个月中,迭代了 5 个版本,服务了近 200 多个用户,帮助团队快速创建了两千多个物料,粗略估计相当于节省了一个员工一年多的工时。

以下是项目经验总结,抛砖引玉,期待与大家一起探讨。

一、为什么要做这个测试平台?

国际化商城的物料创建(如商品、优惠券、促销和下单等),一直是项目中多个角色最头疼的事情。部分站点是找业务创建,部分站点是找负责相应模块的测试同学创建。无论哪种方式,这一来二去的沟通成本是极其高昂的。最极端情况下,物料准备的时间能占到整个测试时间的三分之一到四分之一。所以解决测试物料创建的问题,可以突破商城相关测试人力占用瓶颈。

二、从 0 到 1 构建平台

项目 BRD

在接到这个任务的时候,是没有任何详细的需求,只有一个问题场景。所以要根据这个问题场景,梳理出平台最核心的价值是什么,要解决什么样的问题。从而延伸出需要解决的问题涉及的范围是多大。我根据自己的理解编写了 BRD,这个 BRD 包括以下内容:

  1. 功能列表和描述 颗粒度可以很粗,这是对平台初期的一个定位。在开始没有demo出来之前,一定不要规划大而全的东西。实现出来的功能,一定是大家可能都会用到的功能,比如我们第一期做的就是通过选择模板创建测试商品,因为一切的物料都是以商品为基础。
  2. 项目计划及排期 整个平台规划做多久,第一期做什么,做多久,用到的人力是多少。大概示意是这样的:

版本号

计划时间

功能列表

投入人力

v 0.8

1.1 - 1.15

功能A;2.功能B 3.功能C

前端15天/人;后台15天/人

v 1.0

1.16 - 1.31

功能D; 2.功能E;3.功能F

前端15天/人;后台20天/人

v 0.9

2.1 - 2.15

1.功能G;2.功能H;3.优化功能A

前端20天/人;后台25天/人

这个项目除了我从头至尾是全职投入,其他同事都或多或少有其他的事。所以一份包含人力投入的项目计划极为关键,这是向领导申请人力支援的凭证。如果有同事做到一半,业务缠身去做别的事情,领导一看这期要实现什么功能,几号就要上线,缺口了多少人力,一目了然。在还没开始之前,不知道具体的功能会遇到什么阻碍,具体需要多少人力投入,估个大概就行,实际在项目开发中,再动态调整。

  1. 产品原型 作为内部的工具平台,不会有多少设计和产品资源支持。而且产品也不太了解你要做一个什么样的东西,你的流程你的期望你的诉求,产品都没你清楚。自己要思路清晰,理出个框架,如果条件允许,可以找产品同事帮你画出大家日常工作中熟悉的产品原型,当然你自己也可以照猫画虎的画出来,只要方便其他参与者更好理解和协作就行。至于功能细节及详细的交互,在今后可以自己慢慢填充和完善。这时开始就不需要产品再次介入了。
  2. UI 设计 这是一个看脸的时代,好看的界面会叫人愿意多停留几秒,挽留下来的这几秒,会帮你争取到宝贵的注意力。也许他这个激活用户就看到了他感兴趣的东西了。得不到业务需求那样的设计资源,让设计同学帮你出一套页面样式规范还是可以争取到的。做前端页面时尽量遵照这套样式规范做,不会丑到哪里。看的人觉得赏心悦目,自然也愿意多用。
  3. 需求 首先你要清晰且明确的知道你们的平台工具它的核心价值是什么?它要解决的核心问题是什么?围绕这两个问题,产品形态就会有个大概的轮廓,基于这个轮廓自己就可以往里填充功能了。

一个人或几个人的角度毕竟有限,可以找以后的用户做一下需求收集,听听他们的痛点和诉求。获取到这些东西后一定要做过滤。从用户侧收集到的需求是有噪音的, 他们会根据自己的立场和角度,可能给你一个小众需求,只能解决少数几个用户的问题。这时 要回过头来审视之前那两个问题:核心价值是什么?解决的核心问题是什么?

举个例子:商城中商品的创建会涉及到非常非常多的字段,有普通属性、销售属性、品牌、类目、运费模板等等。那在做商品物料创建的时候,是不是要给用户塞很多输入框或下拉框,这样不就可以满足很多不同场景的测试需求了。NO!商品的创建界面,我们只给用户一个下拉框选择平台定义好的最常用的几个商品模板,两个输入框一个输价格一个输入库存,就没有了,简单易用,完全是傻瓜式创建。

为什么这么做?多数人对于商品这些琳琅满目的繁杂字段是不敏感的,他们也不清楚那些到底有啥含义。给他那么多输入项,反而造成了困扰,不知道如何入手。**他们的诉求很简单,就是要一个某个类型测试商品,能用就行。**我们挑选一些最最常用的几种类型的商品(不同字段的组合),通过模板事先定义好,供用户选择。对于商品某些字段有高要求的用户,他们本身已经明白这些字段的含义,完全可以在运营端自己去操作。即使满足了多字段选择的需求,他们后面也有可能不用。因为你再全也没有运营端全。

这么做有两个好处

  • 大降低使用者的上手成本;
  • 实现起来也比较简单,不用处理太多的逻辑判断,节省宝贵的开发时间;
  • 减法艺术 做平台工具也是做产品。做产品就要做减法。可有可无的功能能不做就不做,交互和功能都要从减少用户上手成本出发。比如摄影中画面元素越少,越能凸显主题,让观者一下抓住画面的核心。

工具平台的价值是提升工作和生产效率,如果用户使用工具还要看很长的文档,研究半天,我个人觉得它已经失败一半了。有时候我们思维惯性,想把能呈现的功能能满足的需求,都尽可能的交付给用户,没有考虑用户能消化多少真正用多少。

要将用户的使用场景代入进来,帮他恰到好处的解决了平台能帮他解决的问题,没有多余的操作、选择、输入。断舍离很难,但很重要

三、跨团队协作

做工具平台免不了其他团队的支持和协助,比如物料平台需要涉及多个研发团队和部门,有的甚至是跨地域的部门。在此特别感谢一下在平台建设过程中曾经帮助过我们的同事们。在他们百忙的工作中,抽空帮忙处理和解决与他们业务以及绩效毫无相关的事情。

后来接触的部门和人多了以后,也逐渐有了一点点自己寻求帮助的方式和心得。

  1. 表明来意 在寻求不认识的同事协助的时候,要清晰明确言语简洁的表达清楚目的和意图。
  2. 找到利益共同点 比如我们搭建了物料平台后,对于某些模块的研发同事来说。测试同事可以挤出更多的时间,好好测试他们的开发的需求,同时物料平台解决了因测试物料创建不当而引发的事故,就再没有人找他们紧急处理事故了。最后他们自己在调试功能时,再不需要找测试同学帮忙创建物料了。
  3. 风险规避,解除戒心 物料平台会调很多模块的接口,轻者入参错误触发报警,重者接口暴露使用不当会有一定事故风险。本来是想着帮你,但一不小心,给自己添了麻烦。这就要我们事先帮他解除顾虑。我会事先和他们讲出我想到的风险,并告诉我的风险规避方案。比如我在调接口的时候先捞线上的 log 模拟入参,再在测试环境调接口,调没问题了,再切预发或线上。又比如我在调商品创建的接口时,硬编码写死某个商品的属性,来和线上正式商品做隔离,避免用户使用不当或误操作引发的事故。
  4. 名单感谢 平台上线后,在开发者人员名单中,一一感谢曾经帮助和提供协助的同事们,这本来就供内部使用的平台,名单再长也无碍。虽然他们不一定会看,有一天一旦在这个名单中搜索到自己的名字时,看到你如此珍视他们哪怕一点点的付出,也是让人心悦的。
四. 做平台,作为测试,需要做哪些技术准备?

我的答案是,用什么学什么。

我个人以前只写过 Python 自动化脚本,测 iOS 客户端时学过一些 OC 和 Swift。物料平台的后台技术栈选择的是 Spring,当时对于 Java 怎么使用,Spring 具体怎么用,完全是懵的。在架构师帮我们设计好架构后,买了一本 Spring 的书结合网上的教学视频,学了依赖注入和切片就 clone 了一个公司内的 Spring 项目。

看里面的结构,启动一个项目必备的配置文件有啥。一个简单的 HTTP 请求从 contorller 到数据库,需要经过哪几层,分别做哪些处理。刚开始是十分痛苦的,都是陌生的概念和名词,在写通一两个接口后,后面虽然还是有很多不会,但知道在 Google 和百度上通过哪些关键字搜索了。后因前端开发资源紧缺,又利用之前的套路,快速上手了 Vue.js,通过先解 bug 学习 Vue.js 的使用,再逐渐熟悉就可以慢慢的开发功能了。

技术的革新很快,行业变革的也很快。不论研发还是测试,我们所面对的是日新月异的测试框架、技术和工具。在这个快速变化的行业里,掌握一招吃一辈子的情况越来越少见了。有了扎实的基础技术储备,比如熟练掌握一门编程语言,知道计算机和网络传输的原理,程序的几种常见设计模式等等,就能快速掌握和驾驭新框架、技术和工具。上层东西是不断变化的,向下走,他们底层原理都是大同小异,就像建筑造型无论怎么改变,他都是需要有地基和承重的

以上,希望这些对于大家在测试平台的搭建上有一些思路上的帮助。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 测试效能平台开发的难点是什么?
    • 一、为什么要做这个测试平台?
      • 二、从 0 到 1 构建平台
        • 三、跨团队协作
          • 四. 做平台,作为测试,需要做哪些技术准备?
          相关产品与服务
          Prowork 团队协同
          ProWork 团队协同(以下简称 ProWork )是便捷高效的协同平台,为团队中的不同角色提供支持。团队成员可以通过日历、清单来规划每⽇的工作,同时管理者也可以通过统计报表随时掌握团队状况。ProWork 摒弃了僵化的流程,通过灵活轻量的任务管理体系,满足不同团队的实际情况,目前 ProWork 所有功能均可免费使用。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档