作者 | 网易雷火测试中心

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

01 发现需求

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

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

1.习以为常的流程

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

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

案例：下包起本地服

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

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

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

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

2.重复性的操作

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

案例：QA 起服的配置

举个例子，之前在项目组里，QA 服起服或者修改版本等操作是通过一个 Python 脚本来控制，每个 QA 服都维护了一份起服脚本，每份脚本里写死了一些诸如数据库地址、服务器 IP 等配置项。这样就导致如果中间某个流程有修改，比如说新增一个起服前发 POPO 消息的需求，就需要连上每个 QA 服的服务器，分别修改起服脚本。如果项目组只配置了少量 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 的定时任务自动来运行，或者放在桌面上点击运行，也能帮助我们减少几个操作步骤。

超越手工

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

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

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

• 自动化，能让测试更加高效，哪怕是从 1 到 1.01 也有必要。

3.其他灵感

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

留心观察

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

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

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

参考使用

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

他人建议

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

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

• 当我们多留心，凡事多问一下为什么，就会有很多看不见的积累。

03 总而言之

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

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

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

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