https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5502笔者在日常玩过很多搭建流水线做自动化生产的游戏，想要把这类游戏玩好，需要有一定的架构思维和优化思维，进而在游玩的过程中，发现流水线需求，去做好优化输入输出、组件位置、结构压缩、接口暴露等一系列流程，以增加产能。优秀的流水线设计，应当是模块化、标准化、高效灵活可扩展的。而归纳概括到工作中来，在宏观上要能够发现流程上的需求，给出基于软件的实现或优化方案，并利用开发能力推进方案落地，以期达到组内效率提升的目的；在微观上要能够利用自己的专业素养，努力提升优化自己代码的可阅读性、可维护性、可复用性、可扩展性。这里分享入职以来的一些心得，希望其中有一些对大家有所启发，举一反三，进而融入到自己的工作当中。
01 自动化测试
测试开发这样一个岗位天然附带开发属性，而众多测试手段中，开发属性最强的便是自动化测试，也是笔者在组里接触最多的工作内容，想要很好的完成一个测试脚本，游戏、测试、开发，三者缺一不可。这里笔者借由一些工作中遇到的问题，介绍下是如何形成的自动化思维，又是如何运用它的。
1.假人，又爱又恨
在很多游戏项目中，通过主动调用执行创建账号、角色等相关的代码，可以创造出一类服务器玩家，从服务器的视角看，这些对象与真正从客户端登录的玩家相比，除了什么都不干，一直在挂机之外别无二致，称之为假人。底层实现的相同性使得我们可以借这种假人，去并发执行测试用例，在完整覆盖的同时，显著减少测试时间。假人是个好东西，但不代表假人是个好用的东西，在笔者开发使用假人的测试脚本之前，通过为其它同学开发假人指令，初步对其进行了了解。假人在我们实际使用时候，是不存在客户端这一部分的，这使得我们对其的操控势必与主玩家不一样，无法通过一些在客户端上常用的点击等操作，完成对假人的控制。
在开发某个赛事玩法的主流程脚本时，需要使用大量假人，组成数十支队伍参与比赛流程，并在最终走完流程后，触发发奖，检查奖励总量是否正确。这个玩法的最终奖励是通过邮件发放的，正常主玩家可以脚本操作UI进行邮件领取，但是假人不行，且如果使用Rpc的方式触发领取，还需要进一步获取对应的邮件信息，以防多领、漏领等情况干扰脚本运行，处理起来十分复杂且耗时。
那么这时候，如果想完成这样一个操作：让假人在收到邮件的时候，把其中的附件接收到包裹当中，又该怎么办呢？最初是没什么办法的，而且其他人也没有做过相关的东西，倒是知道有几个脚本用到了假人。有了这个线索，进一步检索就发现了办法。通过一个隐蔽的接口，可以给服务器到客户端的Rpc加一个监听器，对应的监听函数可以由我们自行设置，这时再回来看“在……时，做……”这个句式，如果我们能够拦截邮件Rpc，然后按照内容发送对应的收取附件Rpc，不是就可以在没有客户端的时候，让一些流程闭环了吗？我们日常测试的时候，会去造数据，去打一些指令去模拟玩家行为，来替代我们不便于甚至无法去执行的操作。而用到自动化测试中，我们自然也可以Mock一个假人的控制者，编写我们希望的行为，按照我们的期望模拟一个玩家接收到来自游戏的输入时，做出的操作，就好像这个假人真的有客户端在控制一样。
2.包一层，为我所用
写脚本的时候，经常会有这么一个尴尬的场景：基类有一个状态基本符合我的需求，但是正好就少了某些东西，或者输入输出需要转换一下，导致用起来很别扭，甚至可能没有办法复用，而直接修改这个基类状态的风险和收益是不对等的。这时候我们可以在这个状态上再包一个状态，这个包裹状态既可以用作装饰器，给基类状态添加新功能，也可以用作适配器，做输入输出处理，十分好用。这种解决思路是通用的，权衡利弊，简单调整自己的部分以复用老的代码。一来可以解决复用问题；二来在状态驱动这种设计下，可以将多个不包含用例信息的操作包裹在一起，能够使得脚本的主结构更加清晰，凸显用例。
3.报告，自动生成
在逐步开发更为复杂的脚本的路上，碰到了这么一个需求：需要监控满足一定要求的所有物品，测试其能否在玩家商店中上架销售。这个能够上架的情况有很多种，可能是操作过程中无法选中，可能是上架失败，可能是上架对了下架返还失败等等。通常的做法是在出错的地方打日志，但对于这种要跑上很长时间才能把全物品过完的脚本，如何才能从长的要死的日志中找到哪些出问题了呢？直接搜是不现实的，可能有几千个，可能更多；那使用脚本筛查呢？好一些，但我们为什么不直接生成一个报告呢？
通过在错误的地方同步加一个报告记录，在脚本结束前按照csv的格式输出到文件，我们跑完脚本可以在日志处直接打开一个表格，列出了各种出现的错误，还可以筛查、排序，正好csv的结构也比较简单，方便去做这样的报告输出，ID、名字、错误原因一目了然，测试同学看了都说好。
4.日志，永远的神
不管是开发自动化脚本还是维护已上线的自动化脚本，日志对于我们掌握脚本运行状态、用例执行情况都是至关重要的。而这里说的日志更多是指脚本内打印的日志，其在发生错误时，能提供关键信息方便定位问题、分析原因，经过设计的格式化日志在一些情况下是可以有妙用的。
还是以前面上架物品的脚本为例，物品数量有很多，如果是自己跑，可以不限制时间，直接在结束后生成一个csv格式的报告文件。但实际运行时候资源是有限的，在约定的1小时后脚本就被强制关停了，不是正常退出，无法在此时打印报告，这就要退而求其次自己写python代码筛查了。通过对日志内容设置一定的格式，比如“[Report]”，便可以借助简短的python代码，从日志中把所有我需要的信息筛选出来，加以处理生成报告。
在平常看日志的时候，适当给一些标记会使得搜索的效率大大提高，其对我们判断自动化脚本报错的原因和严重程度都有很大帮助。以笔者为例，如果某一个脚本的报错信息中出现了“Unexpected“字样，那这个报错大概率是出现了意外情况，比如一个意外弹出来的窗口，或是背包里多出了某些东西，干扰了脚本运行。而如果出现了“Fatal”字样，则一定要严查到底，这通常意味着这个测试点很重要，且一旦是相应功能出现了问题，后果比较严重。
02 IDE进阶
作为测开免不了整天与IDE打交道，如何更好地使用IDE以提高自己的工作效率是很重要的，这之中最多的就是编写、维护自动化脚本。除了一些常规的检索、光标使用、快捷键外，其实还有一些我们很少知道的东西，东点点，西点点，神奇功能会出现。多去了解、熟悉自己的生产工具，无疑会带来不一样的工作体验，同时也会逐步扩展自己的视野和认知，了解更多成熟的解决方案和工程思路，更好地培养自动化思维。
1.文件模板
编写自动化脚本时候，由于我们的框架不可避免地会在自动化脚本中出现大量重复代码结构，而且这种结构通常不能使用常规的编码技巧加以提取，除了重新设计一个新语言，无法进一步简化编写。Lua的相关插件目前又无法提供强大到像Java、C#等语言的编码支持，补全支持的缺少使得我们无法借由IDE补全减少重复编码带来的影响。
俗话说的好，莫要在一棵树上吊死，考虑到类似的场景应该并不罕见，以笔者使用的IntelliJ Idea 为例，简单调研后，有这么一个文件模板功能（File and Code Templates），可以在新建文件的时候，给文件里写入预先设置的内容。我们每次新建脚本的时候，都要把好多东西重新写一遍，要么就是去别的脚本里捞一份然后删半天，如果能直接生成，岂不是非常舒服？
通过设置文件模板，我们之后只需要如上在新建的时候选择我们自己的AutoQAScript，输入脚本名字，就可以自动生成脚本的几个重要变量和状态，以及几个状态里比较固定的代码部分。在玩这个功能的时候，发现还有子模版的功能，可以随着主模板一起生成几个其他的文件。刚刚好我们一个脚本通常上有测试类、基类、通信类三个文件，这下可以直接把所有的基础结构都一起生成了一石三鸟！这样一次点击全部生成，在基类文件里还可以把自己常用的打日志函数等都塞进去，能直接生成的为什么要复制粘贴？
2.动态模板
除了基础的结构，还有一些如获取状态参数、切换状态、循环定时等等也是有非常固定结构的，针对这部分，这里还有另一棵宝树！Idea的动态模板（Live Template）可以让你给一些预定义的代码结构设置一个简写，比如像下面这样给self:SwitchNextStatus()设置缩写为sns。
这样在编写代码的时候，输入sns就可以弹出提示，直接生成完整的结构，甚至比正常的代码提示还好用。但有时候代码大致结构相同，但内容却不同，仿佛固定了但没完全固定，这样应该怎么办呢？
模板里还可以添加一些占位符，通过配置一些内置的操作，占位符可以自动获取一些值并显示；也可以不进行配置，由IDE引导用户输入；还可以通过“$END$”指定生成结束后光标的位置，使得代码编写更加连贯，不用再使用方向键或者鼠标调整光标了。（感兴趣可以直接去查看官方文档，例子很详细）
灵活运用文件模板和动态模板，显著的降低了笔者浪费在重复代码部分上的时间，得以更加专注的面对代码中业务部分的编写，更加关注功能的实现、用例的编排。同时，在功能的辅助下，显著减少了业务无关代码编写带来的思维打断，能够让自己的编码思路更加连续，代码质量提升，更优质地完成自动化测试的工作。
03 工具开发
并非所有的工作都有趁手的工具，磨刀不误砍柴工，测试开发的专业技能注定了其有着打铁磨刀的职责。趁手的工具可以让使用者的效率大大提升，而打造工具、维护工具，更离不开自动化思维。
1.Vscode插件
插件开发是一个相对来说很偏僻的开发领域，但作为一个从事开发的人员，一定会跟IDE插件产生关联。无论是VSCode、JetBrains Platform还是Eclipse，插件都是组成IDE生态非常重要的一部分，甚至对于VSCode，没有插件就只能叫做文本编辑器了。插件开发使用到的语言、技术和框架与目标平台强相关，每个IDE都有自己的一套API，无形中提升了开发难度，毕竟通常情况下使用各个IDE的开发者都有，而你并不能只支持其中某一个。
虽说各个平台插件的开发细节有很大不同，但接触的插件开发多了以后，借由自动化思维很容易发现，在宏观上的概念、流程和插件的大致组成还是相同的。总结下来添加一个UI组件，以菜单项为例，三个平台都是：给自己的菜单项注册一个挂载点，然后绑定一个回调函数，在回调函数里进行业务逻辑的实现。需要注意的就是你的业务逻辑只能通过插件相关的API与本地文件系统进行交互，不然大概率是要翻车的，但访问网络资源就正常发请求即可。
在笔者使用JetBrains全家桶，享受上面官方给出的IDE功能时，小伙伴们在使用的Vscode并没有提供这类功能。于是笔者便给Vscode写了一个简单的插件，将文件模板的功能进行了实现，现在组内用Vscode的小伙伴也可以右键使用一键模板生成功能了，有福要同享的嘛，毕竟换一个IDE，很多习惯上的东西都要调整，是很影响效率的。
这样一个功能的实现难度并不大，具体上就是预先编辑一个模板，在插件相关功能触发时加载并通过API获取一些的如用户名之类的变量，借由typescript的模板字符串进行组装，再用API创建文件，写入即可。有地方不会怎么办？答曰面向官方文档编程。
2.内网服务器日志工具
测试同学在内网环境验证功能、复现问题的时候，经常会要看此时服务器上输出了什么日志，比如副本实例有没有销毁、指令有没有生效等等。测开这个岗位通常是有日志服务器的权限的，可以直接远程登陆上去使用tail命令看日志，但是功能测试同学们就不一定有这个权限，在查看日志方面并不便捷。
测开嘛，既然有开发能力，自然要帮助大家优化这个流程，于是便设计实现了一个内网实时日志的小工具，通过在日志服务器上部署的服务端，根据需要读取日志，并发送给工具进行显示。同时工具里还可以对日志进行过滤，比如只看含某个或某几个关键词的日志，这样测试同学需要跟踪自己某个功能的日志时，就有路可走了。
后端搭一个Socket服务器，根据需要创建线程拉取日志，而前端选了一个好看方便快速开发的python gui库dearpygui进行界面开发，然后连接到服务器，请求日志。开发搭建之中，要时刻想着使用场景和优化方向，掐指一算，这之中一定是拉取日志的工作线程资源开销最大，且基本是CPU使用率。如果一个用户来了要看服务器日志，我们就给他创建一个线程读取的话，想必来个三五个人测大功能，每人再看着三五个服务器进程的日志，我们的日志服务器就势必要骂街了。显然对于同一个游戏服务器的同一个进程，如果有多个人在看，只需要有一个线程在拉日志就够了。与Flask兼容的socketio库正好内置了房间相关的操作，不需要自己去写了，通过在房间内进行广播，就可以处理这种情况，减少线程数，降低开销。而显然，同一个服务器的不同进程间，日志的数量是有明显差异的，而不同的服务器之间，由于服务器当前人数的差异，日志量也会不一样。既然想要自动化处理这种情况，那就要求我们的日志拉取频率是自适应、动态变化的。将频率由固定转为动态算法调整，能够进一步优化各个工作线程的资源使用，若是突然出现了大量日志（比如报错），也不会导致工具产生延迟。
这样，一个简单的日志工具就可以使用了！
04 如何做好一个开发者
游戏测试开发工程师，有开发两个字，那自然就是个开发者，是代码产出的主体。想要产出好的代码，一定是有一些该做的和不该做的，这里便是笔者从微观的自动化思维出发，产生的一些思考和做出的改进。
1.代码风格
代码风格主要包括缩进、空格、括号、对齐，这些是主要的影响部分，其是针对代码格式化器的一系列用户设置，使得用户在使用代码格式化功能的时候，能够依照相应的预设风格，在不影响代码结构的情况下，优化代码的视觉排布，以协助用户阅读和编写代码。需要指出的是，一个项目组最好有一个固定的格式化标准，这样在版本管理系统中上传代码时，就不会因为修改同一个文件而出现代码风格不同导致的大量无效diff，进而影响提交的查看和评阅。
2.编码规范
良好的编码规范是十分有助于自己工作的，一是能够让自己在编写代码时思路清晰，偶尔因其他事情中断编码后也能快速找回状态，不会出现一回头，不知道自己之前写了啥的情形；二是在后续脚本出现问题，需要查证的时候，能够快速定位到问题所在，后续如果别人去接手工作，也能够快速理解上手。
比如脚本常规的三个代码文件中测试类主要负责对用例进行组装，基类负责承载所需状态函数，通信类负责所需要的Rpc的定义。诚然其中有一些可以混着写，也确实有一些接手的脚本是这么做的，这并不会影响实际的运行，但是对于维护和交接，是十足的灾难。将各个粒度、功能的代码分离，拥有良好的代码组织结构，对后续的工作益处多多。
3.主动式文档
文档是对相关工作的一个记录，这里的文档并非一定要是一个独立的文章，也可以是代码注释、文件注释，只要起到了记录之前工作的作用，在自己出现遗忘时，能够通过其快速获取一些需要的信息，对当下工作产生正向帮助的，都可以算作文档。而主动式文档则代表了这个文档的编写是自发而非被迫进行的。举例来说，脚本流程中一些状态直接对用例进行了覆盖，顺手就在旁边以注释形式标记出来，方便后续出现相关报错直达脚本。
一些纪律性的文件注释可以随着文件创建自动生成，比如在自动化测试脚本开头标明脚本创建的日期和作者，并手动写下这个脚本的主要内容。
比如脚本中有一些还需要修改的地方，用todo进行标记，编辑器可以帮你去定位，这在编写的时候能显著减少跳转导致的思绪紊乱。
比如在某些特殊函数的前面，对状态参数或者特殊数据的格式进行标记，以防后续想不起来这个函数要怎么用。
4.防御性开发
开发就开发，怎么个防御性呢？这便要看要防什么，其中最可能出现的就是要防需求变更，在编写代码的时候，让自己的函数尽可能通用些，在面临需求变更的时候，能够减轻代码变动的影响，坚决避免推倒重来。同时，防御性开发还可以为未来着想，设计更通用的函数使得后续可以经常复用，尽管在直观上可能不是最简单的，但走向通用会方便更多人。
同时，防御性开发在面临紧急的临时需求时候，能够很高效地去实现，比如之前在某个玩法检查脚本中，写过一个根据buff计算属性增益的函数，后续在其他玩法临时需要检查其它buff的时候，就直接可以搬过来用，不需要修改，整体开发效率上有明显的提升。如果当时没有做一些拆分，或许就需要把前面计算属性增益的代码粘过来再一通修改了。
5.偷懒且勤快
偷懒，是偷的以后的懒；勤快，是为了以后偷懒当下勤快。
有那么一句俗话说是懒人改变世界，懒人会去想如何能够变得更懒，进而为了变得更懒，十分勤快的努力。开发也是这样，当你发现假人难用时，会去找能不能变得好用；当发现函数要抄过来改时，会去想办法复用；当发现日志死长时，会去想办法写脚本筛日志、添代码出报告；当发现一遍遍写重复代码时，会找模板功能、或者去实现一个；当发现服务器日志不方便时，会去做一个日志工具；当发现回头看脚本，自己也要愣一会儿时，会去纪律性做注释。
05 总结与感悟
回头看笔者入职半年来的一些体会，很多都是想办法让自己和组内同学们未来能够懒一些，把时间放在更重要的地方，提高效率，做好工作。那么这时候再回头去看游戏测开这个岗位，归根结底而言，工作内容正是去运用自己的代码能力和思维，在各种可能的方面去提升效率，辅助测试工作的展开。半年来，笔者从辅助自己开始，到辅助测开同学，再到辅助组内的测试同学，一步一步，尝试运用自己的代码能力，去影响更多人的日常工作，给予帮助。以后，也要时刻保持着一个自动化的思维，去发现流程中存在的问题，并逐步交给机器去做这些繁杂的事情，愿自动化与各位同在！
行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 759968159，里面有各种测试开发资料和技术可以一起交流哦。
最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
