通用技术 测试能效平台的诞生-国际化商城智能物料平台

听雪 · July 29, 2020 · Last by xiaofeier312 replied at September 28, 2020 · 8916 hits
本帖已被设为精华帖!

技术指导性文章网上比比皆是,但对于不那么擅于写代码的测试同学而言,从头开发一个平台的经验分享的文章相对较少。而在平台开发过程中,技术其实没什么难点。难的在于你要利用最少的资源,最快的时间内,选择最合适的实现方案来解决团队中特定的问题。本文记录我在国际化商城项目中,担任智能物料项目PO,从零搭建一个快速创建测试物料的工具平台的心得和经验。该项目在四个月中,迭代了5个版本,有近200多个用户,帮助团队快速创建了两千多个物料,粗略估计相当于节省了一个员工一年多的工时。想通过我作为PO的经验,给大家在思路及心法上提供一点微薄的参考。

一. 为什么要做这个平台

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

二. 平台从0到1

1.项目BRD

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

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

2)项目计划及排期:整个平台规划做多久,第一期做什么,做多久,用到的人力是多少。大概示意是这样的:

版本号 计划时间 功能列表 投入人力
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天/人

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

3)产品原型

作为内部的工具平台,不会有多少设计和产品资源支持。而且产品也不太了解你要做一个什么样的东西,你的流程你的期望你的诉求,产品都没你清楚。自己要思路清晰,理出个框架,如果条件允许,可以找产品同事帮你画出大家日常工作中熟悉的产品原型,当然你自己也可以照猫画虎的画出来,只要方便其他参与者更好理解和协作就行。至于功能细节及详细的交互,在今后可以自己慢慢填充和完善。这时开始就不需要产品再次介入了。

4)UI设计

这是一个看脸的时代,好看的界面会叫人愿意多停留几秒,挽留下来的这几秒,会帮你争取到宝贵的注意力。也许他这个激活用户就看到了他感兴趣的东西了。得不到业务需求那样的设计资源,让设计同学帮你出一套页面样式规范还是可以争取到的。做前端页面时尽量遵照这套样式规范做,不会丑到哪里。看的人觉得赏心悦目,自然也愿意多用。

5)需求

​ 首先你要清晰且明确的知道你们的平台工具它的核心价值是什么?它要解决的核心问题是什么?围绕这两个问题,产品形态就会有个大概的轮廓,基于这个轮廓自己就可以往里填充功能了。

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

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

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

​ 这么做有两个好处:一、极大降低使用者的上手成本 二、实现起来也比较简单,不用处理太多的逻辑判断,节省宝贵的开发时间 。

6)减法艺术

​ 做平台工具也是做产品。做产品就要做减法。可有可无的功能能不做就不做,交互和功能都要从减少用户上手成本出发。比如摄影中画面元素越少,越能凸显主题,让观者一下抓住画面的核心。工具平台的价值是提升工作和生产效率,如果用户使用工具还要看很长的文档,研究半天,我个人觉得它已经失败一半了。有时候我们思维惯性,想把能呈现的功能能满足的需求,都尽可能的交付给用户,没有考虑用户能消化多少真正用多少。你要将用户的使用场景代入进来,帮他恰到好处的解决了平台能帮他解决的问题,没有多余的操作、选择、输入。断舍离很难,但很重要。

三、跨团队协作

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

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

1)表明来意

在寻求不认识的同事协助的时候,要清晰明确言语简洁的表达清楚目的和意图。

2)找到利益共同点

比如我们搭建了物料平台后,对于某些模块的研发同事来说。测试同事可以挤出更多的时间,好好测试他们的开发的需求,同时物料平台解决了因测试物料创建不当而引发的事故,就再没有人找他们紧急处理事故了。最后他们自己在调试功能时,再不需要找测试同学帮忙创建物料了。

3)风险规避,解除戒心

物料平台会调很多模块的接口,轻者入参错误触发报警,重者接口暴露使用不当会有一定事故风险。本来是想着帮你,但一不小心,给自己添了麻烦。这就要我们事先帮他解除顾虑。我会事先和他们讲出我想到的风险,并告诉我的风险规避方案。比如我在调接口的时候先捞线上的log模拟入参,再在测试环境调接口,调没问题了,再切预发或线上。又比如我在调商品创建的接口时,硬编码写死某个商品的属性,来和线上正式商品做隔离,避免用户使用不当或误操作引发的事故。

4)名单感谢

平台上线后,在开发者人员名单中,一一感谢曾经帮助和提供协助的同事们,这本来就供内部使用的平台,名单再长也无碍。虽然他们不一定会看,有一天一旦在这个名单中搜索到自己的名字时,看到你如此珍视他们哪怕一点点的付出,也是让人心悦的。

四. 做平台,作为测试,需要做哪些技术准备

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

我个人以前只写过Python自动化脚本,测iOS客户端时学过一些OC和Swift。物料平台的后台技术栈选择的是spring,当时对于Java怎么使用,spring具体怎么用,完全懵的。在架构师帮我们设计好架构后,买了一本spring的书结合网上的教学视频,学了依赖注入和切片就clone了一个公司内的spring项目。看里面的结构,启动一个项目必备的配置文件有啥。一个简单的http请求从contorller到数据库,需要经过哪几层,分别做哪些处理。刚开始是十分痛苦的,都是陌生的概念和名词,在写通一两个接口后,后面虽然还是有很多不会,但知道在google和百度上通过哪些关键字搜索了。后因前端开发资源紧缺,又利用之前的套路,快速上手了vue,通过先解bug学习vue的使用,再逐渐熟悉就可以慢慢的开发功能了。

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

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

共收到 17 条回复 时间 点赞
陈恒捷 将本帖设为了精华贴 30 Jul 08:58

总结挺不错的,最关键的点都把控得很好,特别是商品模板的,很明确用户需要什么,而不仅仅是平台可以做什么,点赞!

期待你后期分享落地之后,平台运行的稳定性,风险预判等心得。

赞,尤其是商品模版的设计,测试平台一定要帮测试同学做选择

听雪 #5 · July 30, 2020 作者
陈恒捷 回复

感谢认可,希望能帮助大家在以后搭建平台时,能起到一点点作用

听雪 #6 · July 30, 2020 作者
Allen.liu 回复

嗯,后面针对架构设计思路(虽然简单)和安全防护总结一篇。欢迎捧场😀

听雪 #7 · July 30, 2020 作者
zailushang 回复

是的,帮用户提前做好选择,降低平台使用门槛儿和学习成本。

我觉得这才是设计测试平台思路,从解决用户痛点出发;现在论坛里好多都在分享测试平台开发帖子,感觉基本都华而不实,有点本末倒置了

想问下您,花了多长时间,从0研究spring,并且上手调通一两个接口的时间?

听雪 #10 · July 30, 2020 作者
小酷 回复

论坛上测试平台分享的技术相关的内容还是很好的。

听雪 #11 · July 30, 2020 作者
luke 回复

大概是一周左右,边研究边上手干活很快的,如果按照书本和视频上的目录一个一个学,看了后面的忘了前面的。当然如果时间充裕,系统学习还是很有必要的。

听雪 回复

好的,羡慕您时间充裕啊,我感觉我跟您先前情况类似,现在就感觉实操少,根本记不住。想请教如何能彻底掌握,看了您这时间,1周,您也是肯定下了不少功夫,这么快就入门了

听雪 #13 · July 30, 2020 作者
luke 回复

时间不充裕啊,就一周的时间研究,一周后就上手干活了,边干边找晚上和周末时间补课。多研究下公司其他spring项目和开源项目,然后研究下里面的写法。
遇到搜不到的东西,自己研究思考后还解决不了,找研发同事请教。比较幸运,我旁边有高手。😀

听雪 回复

我不是说分享不好,只是感觉那些分享大多是个人用来学习技能的项目,实际落地效果可能会堪忧,感觉大家有点浮躁,偏离了测试的本质

听雪 #15 · July 31, 2020 作者
小酷 回复

嗯,您讲的很对。技能和技术存在的意义就是解决现实世界中的问题。非常赞同回归本质,将解决问题作为核心,其他的都是辅助工具和手段。

针对日常测试难点去研究, 才会有动力, 组内也会逐步开展这样的活动, 感谢分享。

感谢分享

任何一个接口改了,你也得改啊,而且跨团队估计没人通知你吧😅 ,以后维护需要一定的时间。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up