字节待了5年！新人测开的入门总结...

本文是一名新人测开在工作了半年时记录的一些心得感悟，可以说是从零开始认知与游戏测试开发这个领域的探索过程，相信对有志于进入游戏测试行业从事测试开发工作的新人能提供不少帮助。

一转眼已经工作了快半年时间，在组内各位大佬的指导帮助下，从零开始入门，学习到了非常多测试开发需要的相关知识，对这个岗位也有了更加深刻的认知。这篇分享是作为一个萌新测开，分享一下对半年的工作的问题记录，总结和思考。

01、 自动化测试

自动化测试可能是所有萌新开始入门测试开发工作的第一步。

自动化测试从流程上来说，主要包含三个部分，自动化测试用例的编写，自动化脚本编写，自动化后期维护，以下将从这三个方面分享一下我的萌新入门总结。

1.自动化测试用例编写

入门学习自动化可能是从代码框架和技术层面开始的，自动化测试用例编写可能是刚开始时很容易被忽略的一个点。但是测试用例编写作为一个QA应该掌握的基本功，在自动化上也非常重要。一个好的测试用例，不仅是在自动化脚本的编写上，还是在自动化后期的维护上，都非常重要，可以帮助节省很多时间。

构建自动化测试用例

对于完全不了解如何开始一个自动化的萌新，我梳理了一下大致的构思自动化测试用例流程。

Step1：如果不负责该功能的功能测试，就找对应的功能测试同事，获取该功能的测试用例。

通常来说，自动化是在该功能趋向稳定，核心功能实现基本稳定运行后才会开始进行的，因此对应的功能测试此时应当已经完成了基础流程的测试，因此可以找功能测试要一份测试用例来梳理需要自动化的用例。并且注意尽量提前要，给对方一定的时间整理用例。

一般来说，功能的测试用例，可能是偏向于覆盖测试点的，而不是完全流程性的。而自动化的流程性非常明确，并且在部分方面有一定的局限性，例如一些基础的自动化框架对多开的支持较为复杂；因此自动化用例是没有办法直接复用功能测试的测试用例的，需要自己去整理一份自动化可用的用例。

Step2：将该用例转化为自动化可用的用例

首先，针对于测试用例，自己先去游戏里面跑流程，对于自己不清楚的测试点，在跑流程的过程中记录下来，和功能测试确认清楚。流程中，可能需要的patch或者指令，也可以提前准备好。

在跑流程的过程中，思考用例的先后顺序，然后形成一份流程性的用例，并且可以覆盖功能用例的测试点。这个过程可以是多样的，我的个人习惯是，将用例放在模块性的笔记软件中，在跑测的过程中进行拖动，按流程顺序排序整理，之后再看哪些用例测试点被剩下了，看看覆盖性。

另一个需要注意的点是，对于需要多玩家交互的功能，例如团队，聊天等，由于自动化不能多开客户端，只能是使用制造假人来进行的，在整理用例是需要考虑制造假玩家，假玩家和主玩家间的交互流程的。

对自动化用例的其他思考

除了基础流程以外，设计和实现自动化是需要思考很多方面的。这里分享一下我的两点思考。

其一，是要使用产品思维设计和实现用例。在雷火测试的新人培训中，我受启发很大的一点就是测试也需要具备产品思维。当被分到一个功能的自动化时，我们仅仅停留在是需要完成这个功能的自动化需求层面，是完全不够的。

我在之前半年的工作中，因为没有深入思考自动化的实际需求，踩了很多雷，例如在做某些功能自动化时，基础需求是为了保障版权内容都全部自动展示，减少策划手动流程工作。我在开始做时没有意识到目标用户和用户需求，以为和之前的自动化没有任何区别，因此后期多次返工，浪费了很多时间。

所以在开始做一个功能自动化时，第一要思考具体需求是什么，根据需求的不同有所侧重，例如，为了帮助功能测试进行回归，需要覆盖所有测试用例，需要更多检查性的东西，在每个新版本包中检查该功能是否有地方出现Bug或者崩溃。而如果主要目的是为了帮助进行版权屏录，则需要覆盖所有相关版权的功能，主要保证流程可以正常跑通，甚至在必要时可以主动绕开BUG场景。对于版权内容相关部分，需要全覆盖。有分支的不能随机选择，需要重复跑，全覆盖所有分支。

此外，对于同一个功能，写在不同的类型用例里面，根据需求不同，对该用例的实现也不相同。

例如，"创建队伍"这个简单功能。对于专门针对队伍功能的自动化脚本，我们关注的核心用例就是创建队伍的基础功能，因此脚本尽量针对界面进行操作，以模拟玩家真实的点击操作。而对于其他类型，例如副本类自动化脚本，创建队伍仅仅是作为一个前置条件，可以根据需求，通过调用Rpc接口实现来提高效率和稳定性。

其二，稳定性是自动化测试用例最重要的属性之一。

自动化测试的主要意义在于每次回归测试时，可以找到迭代后产生的新BUG，并且帮助减少人工工作量。但是，如果自动化脚本在每次回归时都会出现脚本导致的问题，过程不稳定导致的问题，其实对后期维护是一个非常大的麻烦。如果因为BUG过多，需要使用大量时间去排查错误，其实就失去了自动化测试存在的意义。

因此，在设计自动化用例时，就需要考虑好这个流程是不是稳定的，如果是有随机性的结果，如何将其转化为稳定的检查。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】

2.自动化脚本编写

开始自动化入门时，组内的自动化测试框架一般都已经搭建得比较完善了，所以整个入门过程其实是在学习已经建好的自动化框架，然后在已有框架上添加新功能的部分。

如何开始了解自动化和自动化的基础框架，首先推荐看下前辈们写的自动化入门指南，并且可以在不同的学习阶段多看几遍。随着对自动化的了解深入，每次看都会有新收获。

但有个概念叫做“知识的诅咒”，即当一个人很了解某个知识后，他就会无法想象不知道这个知识会发生什么。大佬之于萌新之间，是存在“知识的诅咒”的，因此在大佬的入门新手指南之外，我作为一个萌新进行了一些的补充，也总结了各种容易踩的坑，希望对之后的萌新也有所帮助。以下是一些比较通用的思考总结。

如何实现复杂的用例

在自动化的过程中会遇到很多逻辑复杂的用例的，可能需要层层嵌套，多重循环，多重检查。

作为一个萌新，在遇到这种情况的时候，可能无法直接理清楚流程，所以我通常会使用整理文档的方式来理清楚思路。

利用整理文档理清思路的优点：

1. 如果你的这个用例实现会被打断，甚至隔天，文档很容易帮你想起你之前做到哪里了。

2. 文档记录可以提醒你哪些做完了，哪些还没有。

3. 如果后期需要维护，会方便你重新看懂自己写的代码。

对于整理的文档，你可以只是单纯的把你需要完成的功能流程列下来，用word或者思维导图的方式都行，标注出循环的地方，通过文档构建整个用例的流程图，最后再代码去实现。

如何提高自动化代码的健壮性

1. 点击操作中多写检查，保证点击是有效的，如果无效还能再次点击。

2. 多考虑各种操作之后是否会触发别的情况，不是每次都触发，但达到一定条件会触发的类型。

3. 读取文字等操作，需要考虑如果文字为空等可能性。

例如读取为空，可能是nil或者""；两种处理方式和判断方式略有别。如果后续需要使用，建议给一个默认值。如果要和策划表中文字进行对比，可能需要对策划表中文字进行处理。

4. 考虑环境变化

例如在游戏过程中，有许多操作会因为角色是男号女号不同而产生差异。而通常调试时可能会开着一个号一直到完成脚本，这时很容易忽略这个问题。建议在设计用例时就要沟通好是否有相关的功能有类似角色性别这样的底层环境的区别。

5. 写好每个Case的容错处理。   

因为你无法保证代码不出错，但是在当前Case出错后，应该尽量保证存在容错处理可以使得下个Case能够正常继续运行。

3.自动化后期维护

自动化不是一劳永逸的，而是有漫长的后期维护时间。

磨刀不误砍柴工，为了方便后期维护，其实大量的工作应该在代码实现的时候就有意识地去做好，写更加稳健的自动化代码，使得自动化后期维护更加简单。

1. 数据调用策划表

对于一些数值检查，数值计算类型，在写进自动化时，能从策划表中得到就从策划表中获得，尽量不要写死，尤其是对于还不稳定的功能，数值迭代真的是非常频繁的，这样可以减少很多迭代后修改自动化脚本的频率。

2. 写好注释

刚开始会觉得说大家注释写得很少，我写很多注释会不会显得我很菜，所以交代码前会将大部分注释删掉，这个就导致我在遇到之前写的脚本出错的时候，在排查问题方面花费了非常多的时间。

自己的脚本之后都是需要自己维护的，其实写了很久的脚本，基本就忘了具体流程了，如果有好好写注释，会非常容易看懂之前自己写了啥。如果留了之前记录的流程用例，就会更容易看懂，更加好维护脚本。

3. 写好LOG

LOG写详细，可以帮助我们在自动化脚本出错的第一时间知道错在哪里。对于复杂的功能。各个重要参数和流程节点，都要写好LOG输出。这样后期排查，就会非常清楚，错是在哪个细节点导致的，可以节省很多排查BUG的时间。

02 、工具制作

测试开发的另一个重要工作内容就是为其他同事服务，制作各种工具平台等，为项目提效。

工具制作通常的流程是：

1. 接到单子，和需求方讨论需求和排期。

2. 如果需要其他部门的参与，例如前端工作需要平台做，需要沟通需求，确定排期。

3. 开始按需求完成工具，交付给对方检查。

由于工具是可能由任何职能的人提出，所以其实会涉及各种方面，因此是一个技术难度比较高的复杂工作。并且这类任务是需要大量的沟通，也需要你能主动有效地去和他人沟通。

所以在这个过程中，我认为以下几点是非常重要的：

1. 多问！作为萌新接到工具单子时，通常是两眼一抹黑啥都不知道的，所以这种时候需要直接去抱住大佬大腿，让大佬给你讲解一遍具体咋做的流程，不懂就问，最好听完再复述一遍流程，防止有误解部分。在过程中，遇到任何困难，都尽量多问，不要自己闷头查问题，在不熟悉整体架构的情况下，是很难找出解决方案的，会浪费很多时间。

2. 多沟通！在刚开始接到单子和对方沟通需求时，你可能自己不是很了解整体项目，于是聊需求可能也没有很容易，所以还是要多沟通，也可以拉上组内大佬和你一起去聊下需求，这样会更容易了解需求具体是啥，大佬还可以帮你分析下做工具的流程方案，在你之后出现问题，或者不会做时，就可以直接去抱大腿。

3. 确定排期！尤其是需要其他部门人员参与时，一定要提前去排期，不要等到你计划开始做这个单子再去沟通，在需求确定下来就去沟通。因为通常其他人手里可能有一些优先级更高的单子在做，是不可能你去找别人，就立即开始帮助你做的，所以一定要提前沟通，也能方便你自己的工作排期。

在技术方面，工具制作会要求你变成一个多面手，你会在这个过程中接触到各种代码语言，除了常用的Lua、C#、Python、SQL，可能还有PHP、JS等前端语言，可能有些在此之前你都没有接触过。

我的经验是在遇到没接触过的语言时，不要直接去看”啥啥语言从入门到精通“这类的东西，不要纠结于你没学过这件事情，直接上手就好啦！通常你要用到的只是一部分，会有大佬给你提供相似的代码，对着学一下需要用到的部分就行，不会就百度，多用就会积累经验，逐步就会熟练运用啦。实践才是最好的学习。

03、 不同语言之间的相互调用

在实际工作中，还经常遇到不同语言间相互调用的场景，这个在我工作之前也太接触过。以下我将用我半年来做过的自动化测试和工具为例子，简单的说明下在我们项目的自动化框架和工具体系中几种语言间调用的方式，希望能给之后的萌新有实用性的参考。

1.C# -> Lua

我在写自动化脚本时，需要通过UI控件的index获取这个控件的文字内容，但是没有已有的接口可以调用，于是需要自己写一个接口。

在我们项目的自动化框架上，客户端的UI操作是发送点击事件来模拟用户操作来实现的，不是直接调用程序代码，发送点击事件是调用Unity自身的C#代码来实现的，而自动化脚本是通过Lua来实现的，之间需要从C#到Lua的调用。

C#接口转lua接口有很多种方式，例如xlua、tolua等。在项目中，我们采用了xlua来实现。

简单讲解一下xlua的基本原理。当我们使用特定的特性将C#接口标记为可导出到Lua的接口后，xLua会利用C#反射获取接口的所有方法和属性信息，并将这些信息打包成一个Lua元表。

Lua元表是一种特殊的Lua表，它可以定义其他表的行为。当我们将一个Lua表设置为另一个Lua表的元表时，它就可以控制这个表的许多行为，例如调用未定义的函数、访问不存在的元素等。通过将C#接口的方法和属性信息打包成一个Lua元表，并将这个元表作为Lua表的元表，xLua就可以将C#接口转换成Lua接口了。

当Lua脚本调用这个Lua接口的方法或属性时，xLua会在Lua元表中查找对应的C#方法或属性，并将调用转发到C#中执行，然后将执行结果再转发回Lua。这样，就可以在Lua脚本中使用和调用C#接口了。

接下来看看在实际工程中的使用。首先，我们在C#接口定义上添加[ExportToLua]特性：

然后我们就可以在自动化的lua脚本中调用此方法，来触发C#中的相关逻辑了。

2.C# -> PHP -> SQL

在C#中写一个工具接口，需要将数据存入数据库时，需要调用PHP。

（因为C#中直接处理MySQL需要安装新的DLL，而通常不能随意安装DLL。）

可以将数据放在post请求中发送给PHP。

PHP连接数据库是使用mysqli，调试可以使用 PHP Storm + Postman，确保可以通过发送Post请求而对数据库进行操作。

04 、总结

本篇主要分享了我作为一个测开萌新半年来的经验总结，主要是在自动化测试和工具制作两个方面，可能很多部分都比较浅显，但希望对之后的萌新有所启发。

下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

最后： 可以在公众号：自动化测试老司机 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！