作者 | 网易雷火测试中心

众所周知,QA 的日常工作覆盖范围很广,从阅读需求文档到测功能到验 Bug,我们需要用到许多辅助测试工作的工具。这些工具往往都是为了提高我们工作的效率,或者保障工作的质量,所以每个工具的诞生,一定都有着明确的需求和开发目的。
相反,如果我们在工作过程中发现了不方便的地方,就可以思考是否能借助工具来解决问题。
所以本文主要从细小处出发,着眼于如何从项目组的日常工作中提出新的工具需求点或者优化点,以及几种通用的解决方案思路。

01 发现需求

有问题才会有需求,发现问题是最为重要的部分。

一般来说,老项目的工作流程已经足够稳定,很难跳出现有的框架去思考可以优化的地方。所以我们可以有意识的把目光聚集在下面的这些情况,或许就能产生一些新的想法。

1.习以为常的流程

大家都知道人与电脑的交互主要靠鼠标和键盘,使用键鼠的目的就是向电脑输入指令,假设我们换一种更加直接的输入方式,比如语音,于是罗永浩就带来了 TNT;比如大脑,于是马斯克就联合创立了 Neuralink 公司。这种回归事物最基本的条件从而找到目标最优路径的方法,用马斯克带火的词来概括就是:第一性原理。

当然我们不需要聚焦于这种颠覆性的命题,只需要对工作中的事物多个心眼,重新审视那些已经习以为常的流程。

案例:下包起本地服

比如之前项目组里,策划要起本地服需要下载当天的日版本包体,下载 2G 多的压缩包,再将解压出来的其中一个文件夹 pkgs 复制到项目特定文件夹里。这套流程用了一年多,所有人都习以为常,直到项目规模扩大后,同时下包的人越来越多,网页服务器的带宽容易被占满,才注意到了这个过程。

优化手段也极其简单,就是在 Build 的时候单独将 pkgs 目录打一个压缩包并上传,如此一来需要下载解压的内容从 2G 变为 110M,效率直接提升 18 倍。

从这个例子可以看出来,有时候多一小步处理,就能极大优化整个流程。对于工作中习以为常的部分,我们也不是要一味适应和习惯,换种实现说不定会更好。

多想想工作中流程事物的目的,能达到相同目的情况下,有没有更优的解法。

2.重复性的操作

我们会遇到一些重复性的工作,如果是流程一样的事情做多次,可以考虑通过脚本来处理;如果是流程基本一样的事情,可以考虑通过脚本 + 配置文件来处理。

案例:QA 起服的配置

举个例子,之前在项目组里,QA 服起服或者修改版本等操作是通过一个 Python 脚本来控制,每个 QA 服都维护了一份起服脚本,每份脚本里写死了一些诸如数据库地址、服务器 IP 等配置项。这样就导致如果中间某个流程有修改,比如说新增一个起服前发 POPO 消息的需求,就需要连上每个 QA 服的服务器,分别修改起服脚本。如果项目组只配置了少量 QA 服,这个操作流程尚能接受,但随着服务器数量越来越多,就需要想办法优化掉重复性的操作。

思路也很简单,把写死的起服脚本改为通用逻辑 + 读取配置的形式,在中央服务器维护一个 QA 服对应配置信息的文件,通过在中央服调用脚本,将起服逻辑脚本 + 额外的配置文件推送到 QA 服。

这一部分最难的其实是鼓起优化的决心,很多时候我们知道问题在哪,也知道怎么改会更好,但是因为有优先级更高的任务,就会搁置优化的决心。所以我们要衡量好投入和产出的收益,情况允许的情况下,积极大胆优化。重复性工作在第一次流程跑完以后,就可以想办法编写自动化的脚本;如果有多个命令脚本,也可以尝试集成到一键启动。

3.繁琐的步骤

工作中一些环节会有很多步骤,比如我们要开始新一天的测试工作,需要更新 SVN,将客户端更新到特定版本,服务器更新启动到特定版本,打开 GM 工具,打开对应策划表……在复杂度超过把大象放进冰箱之后,我们就要思考是否能够简化步骤。

案例:GM 快捷模块

相信大部分项目都有角色属性,属性在战斗中的取值变化是我们在测试过程中重点关注的部分,所以我们会频繁打印、修改这些值来进行测试。我们项目的战斗有一部分是回合制,但是在使用相应修改特定属性的 GM 命令时往往还需要修改局内的 index 来对应不同位置的角色,使整个流程操作十分繁琐。这时候我们就需要想一想,如何简化这个流程。

首先,选对应卡牌是一个麻烦事,我们需要在每局开始后使用打印 index 与对应的卡牌名称才能获取一个映射关系;其次使用修改属性的 GM 命令还需要输入属性名和修改后的值。所以综合下来,我们发现繁琐的是多次修改、发送 GM 命令的这个过程,如果能减少这部分的操作,整体使用就能更加高效。

于是就有了下图的这个辅助工具,中间一部分是场上的卡牌角色,左边是对应卡牌的所有属性值,右侧是一些快捷的 GM 命令,将原先的编辑命令发送改成了鼠标点选目标,拖动滑动条或者输入特定值来修改属性。

有了这个工具之后,不但 QA 的测试效率提高了,策划的配表效率也提升了。

4.人工难处理的问题

还有的时候,我们可能会遇到一些人工难以处理的问题,可能是概率上的,也可能是数量上的,或者是凭肉眼难以辨别的工作。比如说道具礼包内容的验证、怪物掉率的验证,这类问题我们都可以想办法借助工具来解决。

案例:礼包道具的测试

最常见的礼包道具,策划配表会配置能开出来的物品 ID 和概率,但是我们一眼看过去能获得的信息近乎为零,大概只知道能开出的物品确实很多。

如果把物品 id 转化为道具图标,那么礼包内的物品就能一眼看出来。其他额外的信息也能直观展示出来,比如概率能通过列表或者图标的排序来由大至小排列,物品是否绑定能通过图标左上角的绑定角标来显示。

文本转图标,静态转动态,手动转自动,问题更轻松。

5.容易出错的地方

有人为的操作就可能出错,就拿复制粘贴来说,相信大家都经历过误操作的情况,比如说策划表里少复制一个标点,多复制一个符号。对于这类容易出错的地方,我们的目标就是尽可能帮助操作者减少出错的可能。

案例:关服指令

比如 GM 工具可以发送关服的命令,如果一不小心误操作,本来不想使用却误点了,就要耗费额外时间来还原之前的环境。所以我们可以采用最简单的防错方法,就是加一个二次确认,在检测到发送的命令包含关服的内容时加一个弹窗提示,默认为 No,手动选择 Yes 时才会让命令真正的生效。

作为 QA,我们一部分工作内容就是找出别人的错误,所以才会归纳总结那么多的 Checklist;有时候换种思路,如果让上游的工作产出更加标准规范,也能减少我们测试时的工作量。比如策划在表里填写剧情对话容易出各种格式问题,如果我们写一个对话编辑器,就能从源头上避免格式问题的产生。

错误无法避免,除了错误发生后更快修正,同时也能想办法减少错误的产生。

02 如何解决

发现需求之后,我们就需要考虑该用哪种方案来解决问题。这一部分需要我们思维保持开阔,多想多尝试,因为不可能有一个标准答案,所以我们可以尽情发挥,在可行的方案里寻找最优解。

下面我将分享一下我比较常用的几种思路。

1.可视化

现在无论是游戏攻略,还是科普文章,甚至政府报告,都会做成 “一图流” 的形式。不可否认的是,相比于以前的大段文字,我们确实更喜欢这类长图片,它通过排版能更加突显信息的层级和关键数据,让我们阅读更轻松。

文本可视化

在工作中,我们也可以优先考虑把文字转化成图片,来提高我们的工作效率。这种方式需要我们明确两个问题,是否需要可视化和如何可视化。

第一个问题的关键在于可视化之后是否让我们获得信息更加方便,假设一个技能的生效概率是 0.8,我们通过阅读 0.8 这个数字就已经能获取所需的信息,不需要再生成一个 80% 生效、20% 不生效的饼图。但是如果我们需要对比一系列技能的生效概率,就最好生成一个直方图来横向对比。

第二个问题主要是说采用哪种方式来展现,举个例子策划填的表里很多都是由多个 ID 组成,比如地图中包含的 NPC。考虑到 NPC 会有头像图标,最基础的办法就是将 NPC 头像排列出来;但是还能更进一步,地图一般会有俯视角的地图截图,如果我们做一个坐标的转换,就能将 NPC 头像放到地图上对应位置,会更加直观。

操作可视化

有时候文本可视化仅仅是第一步,它可以帮助我们应用到某些地方,让一些复杂的操作步骤变得更加简单直观,所以我总结为 “操作可视化”。

一个很好的实践是 GM 工具里选人流程的优化,在工具中需要输入角色 ID 来对特定人物发送 GM 指令,角色 ID 是一长串数字,原先需要对照着客户端里的信息手动输入到 GM 工具里,如果要切换角色,需要重新输入或者在下拉框中切换已输入过的 ID,十分不直观。

所以我们要想办法优化掉输入角色 ID 的过程,考虑到 GM 工具能通过命令直接打印服务器上所有角色的 ID、职业、名字等信息,我们就可以做一个映射,把每个角色的 ID 转化为职业头像 + 姓名,整个流程就简化很多,自动生成角色的图标列表以后,在工具中用鼠标点选切换即可。

流程可视化

如果把 “可视化” 的概念再往上递进一层,就可以升级成流程可视化,不再聚焦于一个具体的操作,而是如何让一整个流程更加简单。

在日常测试过程中,偶尔会需要用到一些概率自动化的脚本,比如新装备开放时,需要运行一系列装备洗炼、装备生成、怪物掉落的概率测试脚本。原有的流程是通过打 GM 命令来加载测试代码、设定测试次数和条件、开始测试,然后通过 SSH 连接到 QA 服上把生成的 csv 数据取到本地。

这些操作步骤对于一个熟练工来说不算多也不复杂,但对于一个初接触的人来说有一定使用门槛,需要保证按顺序打 GM 指令,还需要去 Linux 服务器上打命令下载文件,所以希望每个人都能掌握这套流程无疑是不现实的。但我们的目标应该是让每个人都能运行脚本获取结果,这样才能减轻负担,使用的人不用担心要去麻烦别人来操作,维护脚本的人不需要花费时间在重复执行脚本上。

所以我们可以开发一个工具,把运行 GM 的部分转换成输入具体配置,点击按钮一键运行的功能,并且网页后台会自动从对应的 QA 服务器上获取文件结果并支持网页前端展示下载。这样一来整个流程就变得易于上手,维护的人只需要维护后台配置的模块脚本,使用的人能直接开箱使用。

又比如项目作为一个稳定运营期的游戏,日常工作中会涉及合服、开分支、月版本回归等诸多测试流程,以往这些流程都是靠 popo 消息来沟通推进,会有难记录、易遗漏等问题,所以后续就通过一系列网页工具来规范、可视化了这些流程。

2.自动化

自动化这个词,想必大家也都熟悉得不能再熟悉了。在这里我对于它的定义是,能减轻我们手工操作负担的,都可以算作自动化。

辅助手工

每个人在工作中都或多或少用自动化辅助过手工测试,比如用 Excel 来测算复杂的公式,所以并不是一定要用代码编程才能算自动化。

优化 GM 指令也是辅助手工测试的一种自动化手段。比如说策划在场景里新配置十个 NPC,需要我们逐一在场景中检查,那么最基础的办法是利用传送到 NPC 的命令运行十次,每次修改一下坐标;进阶一点的办法是我们用一个列表来存取十个 NPC 的坐标,每次修改编号并传送到对应编号的坐标;这还不够,我们还能更偷懒一点,可以在服务器上保存当前的编号,每次运行指令的时候自动给编号 +1,如果超过了最大数量就重新回到第一个,然后传送到对应的 NPC 坐标,这样一来使用指令的时候就不需要修改参数,直接点击发送指令就行。

利用自动化辅助手工测试,重点不需要放在自动化,而是在于通过自动化追求更加高效的手工测试执行。

替代手工

辅助测试之余再发展,就是能替代手工测试,常见的自动化测试脚本、性能测试脚本都是如此。但是除了这些系统性的模块,我们在日常工作中也能发现很多小点来切入。

比如排行榜的测试,我们需要观察存在大量排行榜数据时各类表现是否正常,而生成大量的数据规模,显然不是人工创建角色能做到的。这时候就需要一些机器人来帮助我们完成测试,对于相关负责的功能测试同学,能使用机器人完成相应的测试点就是胜利;对于自动化开发的同学,这是一个可能的需求点,如何封装好机器人模块或者改进已有的服务器/客户端机器人,来让所有人更好的使用。

不止是游戏测试工作,工作流程中也有隐藏的需求。比如我们经常需要更新 SVN,每次都需要手动打开项目文件夹,鼠标右键 - 更新 SVN,但这完全也可也写成一个 bat 脚本,利用 Windows 的定时任务自动来运行,或者放在桌面上点击运行,也能帮助我们减少几个操作步骤。

超越手工

这一部分可能也是测试发展的一些趋势,从手工到自动化,最终走向智能化。

毕竟从人工测试到无人值守之后,接下来肯定是令这个无人值守的逻辑更智能,比如伏羲和项目组合作的基于强化学习的任务自动化;比如战斗平衡性、经济系统平衡性……只要是数值挖的坑,我们都可以跟着跳进去研究一番。

当然我们也能畅想,未来在提交平台上检查的提交,能直接显示对应的用例平台上的用例,或者是抛错平台的对应代码的抛错,这便是我们需要研究精准测试的意义。

3.其他灵感

我们可以从日常生活中发掘工具的灵感,只有平时多留心,需要时才能灵光乍现。

留心观察

在平时的网上冲浪过程中,大到 WEB 网页整体的样式布局,小到 APP 按钮的点击反馈,我们都能留心观察一番,然后用到自己的工具里。比如说现在 PC 端的浏览器中,连 IE 都有顶部 Tab 页,所以如果工具里有分页的需求,做成类似的顶部 Tab 就能减少使用者的学习成本,让使用更加易上手。

我们在各类游戏中也能获取灵感,如果是复杂类型的游戏,比如模拟经营或者建造,我们可以观察游戏里是如何布局 UI 才能让游戏繁而不乱;如果是休闲类型的手游,我们可以看看游戏里是通过简化哪些地方来让操作更轻松。

在生活中也是,比如地铁车厢里的站点信息,用在工具里就是很好的显示当前节点的一种形式;点外卖有预计等餐时间,运行的工具里比较耗时的任务也可也加上预计剩余时间。

参考使用

在我们有了具体的功能需求,但是不知道通过何种交互方式来呈现时,一种直接的方法就是参考其他工具,也就是——抄作业。比如 GM 工具在实现搜索功能的时候,我希望搜索到之后能直接运行,所以就参考了 Listary 这个工具的做法,搜索到之后按方向右键就能进入操作的选单,上下切换选项后按回车能对搜索到的 GM 指令进行相应的操作,这样通过键盘就能完成所有的操作,非常快捷。

他人建议

工具做出来之后会有使用者,他们初次试用时的建议是非常非常重要的,因为很多时候我们是靠着自己的理解来制作,所以操作习惯上肯定不能适配所有人。这时候我们要在各种建议中提炼出比较共通的问题然后改进。

比如上文提到的查看战斗属性的工具,按原先的数据展示和调整分开的方案,属性一多就会比较麻烦。所以后来在组内同事的建议下,改成了下图的方式,在打印属性的地方就能直接修改属性,比原先的方案更合理。

03 总而言之

回顾本文的标题,如何从工作中提取工具需求。

这里面定义的是广义 “工具”,它具体指代的可以很庞大,或许最终成为一个平台系统;也可以很细分,最终只是项目组内一个功能测试点的辅助脚本或者命令。但无论如何,我们的目标是通过它来提高效率解决问题,只要能完成这个使命,那就是我们的好 “工具”。

为什么要提取工具需求,因为我们希望事物在不断优化中做得更好,效率更高。我们要多多思考,当前的问题是什么,需要如何解决,怎么更好的解决。在我眼里,这是 QA 岗位必要的一个重要特质,有不断优化改进事物的目标,才能促使我们产出更多的想法。

每个人的工作习惯和思维模式不同,看问题的角度和想法也不同,这种差异正是每个人的独特财富。本文的想法也只是个人的一些体会,希望在某些时刻,能帮助大家跳出来从另一个角度重新发现。


↙↙↙阅读原文可查看相关链接,并与作者交流