测试效能平台最佳实践 | 解决用户痛点,比堆叠功能更重要!
本文为霍格沃兹测试学院优秀学员关于测试测试效能平台开发(国际化商城智能物料平台)的最佳实践经验分享。
测试效能平台开发的难点是什么?
关于测试效能平台开发,从技术上提供指导的文章网上比比皆是,但从 0 到 1 全面阐述测试平台开发实战经验的文章就相对较少。
而且,即使对于不那么擅于写代码的测试同学而言,在平台开发过程中,技术其实也没什么难点。
最难的点在于你要利用最少的资源,在最快的时间内,选择最合适的实现方案来解决团队中特定的问题。
本文就记录分享一下我在公司国际化商城项目中,作为智能物料项目 PO,从零搭建一个快速创建测试物料的工具平台的一些心得和经验。该项目在四个月中,迭代了 5 个版本,服务了近 200 多个用户,帮助团队快速创建了两千多个物料,粗略估计相当于节省了一个员工一年多的工时。
以下是项目经验总结,抛砖引玉,期待与大家一起探讨。
一、为什么要做这个测试平台?
国际化商城的物料创建(如商品、优惠券、促销和下单等),一直是项目中多个角色最头疼的事情。部分站点是找业务创建,部分站点是找负责相应模块的测试同学创建。无论哪种方式,这一来二去的沟通成本是极其高昂的。最极端情况下,物料准备的时间能占到整个测试时间的三分之一到四分之一。所以解决测试物料创建的问题,可以突破商城相关测试人力占用瓶颈。
二、从 0 到 1 构建平台
项目 BRD
在接到这个任务的时候,是没有任何详细的需求,只有一个问题场景。所以要根据这个问题场景,梳理出平台最核心的价值是什么,要解决什么样的问题。从而延伸出需要解决的问题涉及的范围是多大。我根据自己的理解编写了 BRD,这个 BRD 包括以下内容:
-
功能列表和描述
颗粒度可以很粗,这是对平台初期的一个定位。在开始没有demo出来之前,一定不要规划大而全的东西。实现出来的功能,一定是大家可能都会用到的功能,比如我们第一期做的就是通过选择模板创建测试商品,因为一切的物料都是以商品为基础。 -
项目计划及排期
整个平台规划做多久,第一期做什么,做多久,用到的人力是多少。大概示意是这样的:
版本号 | 计划时间 | 功能列表 | 投入人力 |
---|---|---|---|
v 0.8 | 1.1 - 1.15 | 1. 功能A;2.功能B 3.功能C | 前端15天/人;后台15天/人 |
v 1.0 | 1.16 - 1.31 | 1. 功能D; 2.功能E;3.功能F | 前端15天/人;后台20天/人 |
v 0.9 | 2.1 - 2.15 | 1.功能G;2.功能H;3.优化功能A | 前端20天/人;后台25天/人 |
这个项目除了我从头至尾是全职投入,其他同事都或多或少有其他的事。所以一份包含人力投入的项目计划极为关键,这是向领导申请人力支援的凭证。如果有同事做到一半,业务缠身去做别的事情,领导一看这期要实现什么功能,几号就要上线,缺口了多少人力,一目了然。在还没开始之前,不知道具体的功能会遇到什么阻碍,具体需要多少人力投入,估个大概就行,实际在项目开发中,再动态调整。
-
产品原型
作为内部的工具平台,不会有多少设计和产品资源支持。而且产品也不太了解你要做一个什么样的东西,你的流程你的期望你的诉求,产品都没你清楚。自己要思路清晰,理出个框架,如果条件允许,可以找产品同事帮你画出大家日常工作中熟悉的产品原型,当然你自己也可以照猫画虎的画出来,只要方便其他参与者更好理解和协作就行。至于功能细节及详细的交互,在今后可以自己慢慢填充和完善。这时开始就不需要产品再次介入了。 -
UI 设计
这是一个看脸的时代,好看的界面会叫人愿意多停留几秒,挽留下来的这几秒,会帮你争取到宝贵的注意力。也许他这个激活用户就看到了他感兴趣的东西了。得不到业务需求那样的设计资源,让设计同学帮你出一套页面样式规范还是可以争取到的。做前端页面时尽量遵照这套样式规范做,不会丑到哪里。看的人觉得赏心悦目,自然也愿意多用。 -
需求
首先你要清晰且明确的知道你们的平台工具它的核心价值是什么?它要解决的核心问题是什么?围绕这两个问题,产品形态就会有个大概的轮廓,基于这个轮廓自己就可以往里填充功能了。
一个人或几个人的角度毕竟有限,可以找以后的用户做一下需求收集,听听他们的痛点和诉求。获取到这些东西后一定要做过滤。从用户侧收集到的需求是有噪音的, 他们会根据自己的立场和角度,可能给你一个小众需求,只能解决少数几个用户的问题。这时 要回过头来审视之前那两个问题:核心价值是什么?解决的核心问题是什么?
举个例子:商城中商品的创建会涉及到非常非常多的字段,有普通属性、销售属性、品牌、类目、运费模板等等。那在做商品物料创建的时候,是不是要给用户塞很多输入框或下拉框,这样不就可以满足很多不同场景的测试需求了。NO!商品的创建界面,我们只给用户一个下拉框选择平台定义好的最常用的几个商品模板,两个输入框一个输价格一个输入库存,就没有了,简单易用,完全是傻瓜式创建。
为什么这么做?多数人对于商品这些琳琅满目的繁杂字段是不敏感的,他们也不清楚那些到底有啥含义。给他那么多输入项,反而造成了困扰,不知道如何入手。**他们的诉求很简单,就是要一个某个类型测试商品,能用就行。**我们挑选一些最最常用的几种类型的商品(不同字段的组合),通过模板事先定义好,供用户选择。对于商品某些字段有高要求的用户,他们本身已经明白这些字段的含义,完全可以在运营端自己去操作。即使满足了多字段选择的需求,他们后面也有可能不用。因为你再全也没有运营端全。
这么做有两个好处:
- 大降低使用者的上手成本;
- 实现起来也比较简单,不用处理太多的逻辑判断,节省宝贵的开发时间;
- 减法艺术
做平台工具也是做产品。做产品就要做减法。可有可无的功能能不做就不做,交互和功能都要从减少用户上手成本出发。比如摄影中画面元素越少,越能凸显主题,让观者一下抓住画面的核心。
工具平台的价值是提升工作和生产效率,如果用户使用工具还要看很长的文档,研究半天,我个人觉得它已经失败一半了。有时候我们思维惯性,想把能呈现的功能能满足的需求,都尽可能的交付给用户,没有考虑用户能消化多少真正用多少。
要将用户的使用场景代入进来,帮他恰到好处的解决了平台能帮他解决的问题,没有多余的操作、选择、输入。断舍离很难,但很重要。
三、跨团队协作
做工具平台免不了其他团队的支持和协助,比如物料平台需要涉及多个研发团队和部门,有的甚至是跨地域的部门。在此特别感谢一下在平台建设过程中曾经帮助过我们的同事们。在他们百忙的工作中,抽空帮忙处理和解决与他们业务以及绩效毫无相关的事情。
后来接触的部门和人多了以后,也逐渐有了一点点自己寻求帮助的方式和心得。
-
表明来意
在寻求不认识的同事协助的时候,要清晰明确言语简洁的表达清楚目的和意图。 -
找到利益共同点
比如我们搭建了物料平台后,对于某些模块的研发同事来说。测试同事可以挤出更多的时间,好好测试他们的开发的需求,同时物料平台解决了因测试物料创建不当而引发的事故,就再没有人找他们紧急处理事故了。最后他们自己在调试功能时,再不需要找测试同学帮忙创建物料了。 -
风险规避,解除戒心
物料平台会调很多模块的接口,轻者入参错误触发报警,重者接口暴露使用不当会有一定事故风险。本来是想着帮你,但一不小心,给自己添了麻烦。这就要我们事先帮他解除顾虑。我会事先和他们讲出我想到的风险,并告诉我的风险规避方案。比如我在调接口的时候先捞线上的 log 模拟入参,再在测试环境调接口,调没问题了,再切预发或线上。又比如我在调商品创建的接口时,硬编码写死某个商品的属性,来和线上正式商品做隔离,避免用户使用不当或误操作引发的事故。 -
名单感谢
平台上线后,在开发者人员名单中,一一感谢曾经帮助和提供协助的同事们,这本来就供内部使用的平台,名单再长也无碍。虽然他们不一定会看,有一天一旦在这个名单中搜索到自己的名字时,看到你如此珍视他们哪怕一点点的付出,也是让人心悦的。
四. 做平台,作为测试,需要做哪些技术准备?
我的答案是,用什么学什么。
我个人以前只写过 Python 自动化脚本,测 iOS 客户端时学过一些 OC 和 Swift。物料平台的后台技术栈选择的是 Spring,当时对于 Java 怎么使用,Spring 具体怎么用,完全是懵的。在架构师帮我们设计好架构后,买了一本 Spring 的书结合网上的教学视频,学了依赖注入和切片就 clone 了一个公司内的 Spring 项目。
看里面的结构,启动一个项目必备的配置文件有啥。一个简单的 HTTP 请求从 contorller 到数据库,需要经过哪几层,分别做哪些处理。刚开始是十分痛苦的,都是陌生的概念和名词,在写通一两个接口后,后面虽然还是有很多不会,但知道在 Google 和百度上通过哪些关键字搜索了。后因前端开发资源紧缺,又利用之前的套路,快速上手了 Vue.js,通过先解 bug 学习 Vue.js 的使用,再逐渐熟悉就可以慢慢的开发功能了。
技术的革新很快,行业变革的也很快。不论研发还是测试,我们所面对的是日新月异的测试框架、技术和工具。在这个快速变化的行业里,掌握一招吃一辈子的情况越来越少见了。有了扎实的基础技术储备,比如熟练掌握一门编程语言,知道计算机和网络传输的原理,程序的几种常见设计模式等等,就能快速掌握和驾驭新框架、技术和工具。上层东西是不断变化的,向下走,他们底层原理都是大同小异,就像建筑造型无论怎么改变,他都是需要有地基和承重的。
以上,希望这些对于大家在测试平台的搭建上有一些思路上的帮助。