游戏测试成长之路03-测试执行及测试流程

剧情简介

在熟练掌握测试用例分析和编写之后，导师同步安排你开始在项目中开展测试工作，你将在实际项目中参与项目研发的完整过程，并从中去理解、总结出科学、适宜的测试流程。你求助成长教练U，给你建议了下列注意事项：

带着几个点去开展每一次的工作：
1、任务前：需要完成哪些测试任务、起止时间、测试标准、可用的资源？你需要如何规划测试任务，可能遇到哪些困难，涉及哪些技能或工具？
2、任务中：做好过程记录，遇到了什么问题，怎么解决的，涉及了哪些人？
3、任务后：问题和不足，优点和亮点；从个人–小组–项目整体，尽可能从小到大多范围思考总结。
。。。

测试执行

关键点1：任务前，整体目标和个人目标

测试执行是我们工作中最最基本也是最核心的内容，几乎测试人员70-80%的时间都是在执行测试任务。如何开展好测试执行工作，却是我们一直需要思考的问题。
俗话说方向不对，努力全费。我们在开展工作前就要准确理解任务目标，只有方向对了，结果才可能对。对于初期的你来说，提前和组长、小伙伴们沟通确认好任务目标，能让你更好的把握自己的工作任务安排。

初期的你，基本上任何工作内容都是自上而下获取的，当你收到工作任务后，你需要进行评估，兵马未动粮草先行，初期主要从以下2个点评估就行了：
1、技能和资源（文档、Bug跟踪平台、权限、硬件设备、测试账号等等）
2、协作的人（内部/跨部门、合作方式等等）

对于技能和资源，如：文档管理、Bug平台权限、测试设备、账号等，需要你提前评估是否可以在任务期间具备相关的操作技能和使用权。
对于协作的人，如：和哪些人配合、依赖从属关系、性格特点等。
有了上述的评估后，你基本上能对自己的工作任务有基本的思路了。

关键点2：任务中和任务后，记录过程和回顾复盘

过程记录是为了数据，过程和复盘需要结合，很多时候往往会忽略了其中之一，需要引起重视。

为什么记录过程，是为了让我们有数据可追溯，可分析。让我们复盘有数据可参考，更有效的回顾和总结。（某些情况下还能避免分锅、黑工啥的情况）
记录内容主要针对不理解、易出问题的部分，事件本身-涉及的人-处理的方式。
复盘是为了总结经验、改正错误，是面向未来的。

测试流程

流程都是在长期的工作中不断总结，形成的一套适合的标准工作模式。每个行业、每个公司、每个团队都可能有自己独特的流程，而且不是一层不变的，是跟随市场行情、技术发展、组织结构等持续变化的。

目前来看，游戏相关业务的测试流程，核心流程归纳从前到后（忽略部分项目流程），理论上应该有：
1、立项分析
2、需求分析及评审
3、用例设计及评审
4、测试执行
5、测试报告
6、发布及线上跟踪
7、复盘

立项分析

所有的项目都是基于达成战略目的而开展的，一般情况下为实现项目目标，会分为多个版本来实现，每个版本需要持续验证是否朝着战略目标达成在前进。当然这个过程一般由高层领导、制作人、核心产品人员等完成。

需求分析

有了项目目标，会拆分成不同的功能玩法，就会需要评估需求是否合理，是否符合市场需求等。一般由制作人、产品、运营同事完成。

用例评审

需求制定后，进入该阶段，一般会和研发阶段同步。大部分情况下测试人员从该阶段介入，此时测试团队开始做测试准备，包括熟悉需求、编写测试用例等。

测试用例评审一般需要产品、研发、测试3方共同参与，用例评审非常有必要的点在于：
1、指出需求不合理的点（产品）
测试往往是最熟悉游戏当前情况的人员，所以这个时候，需要站在用户侧对需求文档进行评估，
比如：功能设计互相冲突，涉及法律法规的限制，会不会造成舆情，影响平衡等；

2、对测试细节进行补充及讲解（产品、研发）
a. 讲述你的测试设计和思路，这样会提前给研发一个暗示，规避低级bug；
b. 产品、研发同事进行补充，往往有些部分他们更专业，可以给出更好的测试思路及方法；
c. 指出测试需要的支持，提前和研发同事沟通，比如造数据、准备测试服啥的；

用例评审后根据情况补充用例、备注测试方法、资源准备计划等（方便你正式开测前或测试中找对应的人配合，为后续测试提前计划）

用例评审的核心价值在于上述2点，提前避免需求漏洞、补充测试覆盖度、获取测试所需支持、优化测试方法。做好了能有效提升项目研发及测试的效率及质量。

测试执行

每次打好测试版本，就进入测试执行阶段。这其实是个无限循环的过程。

提测（*****）

交付测试版本涉及1个提测过程，这个流程很重要，该流程理论上应该是：
1、用例评审阶段，同步会准备一份冒烟用例，交付给研发同事。
2、打包后，自测，自测包括（研发按冒烟用例体验流程是否阻塞、产品及美术同事体验游戏效果是否满足设计），需有自测说明书
3、自测通过后，发送邮件或其他方式，交付给测试团队进行细致的测试。
4、测试验证，通过进入测试，不通过打回重复上述过程。

但是现实往往不是这样的，无数测试同学吐槽的点就在这里，没有自测，打个包全是bug，测都测不了，浪费大家时间，严重搞心态，这估计是绝大部分测试同学都有过的经历。

大部分团队受限于业务类型、组织结构等因素，往往不会有自测流程。给测试同学带来了额外的工作内容及负面情绪，可能无法改变，但是我们应该以达成此流程为目标，不断努力去推动优化。（坚持去推广整体为质量负责的理念，此处后续项目管理部分会单独详细讲解。）

执行

真正进入执行阶段，就需要按着测试用例去执行即可，过程中有额外的测试想法，动态补充即可。
按文初提到的一些细节做好过程记录，按照标准流程执行、提交bug、记录问题即可。

这个阶段是个重复过程， 测试—bug跟踪—回归测试。

测试过程中，提交bug是最基本的点，bug提交规范，参考：
【xx项目】【xx版本】【xx类型】bug描述

注意事项：
1、bug提交规范统一，形成一致的风格，降低理解成本；
2、不能出现模棱2可的词，增加2次沟通成本；
比如：A功能不正常（x）；A功能在超出等级限制情况下还可升级（√，需要具象化）
3、对于问题，尽量测试覆盖类比全，信息量给足，定位到尽可能小的范围，；
比如设备A出现兼容问题，需再补充测试下同系统版本、同CPU等情况下别的设备
4、bug解决后，针对严重或典型问题，要求研发备注原因，方便后续学习及他人学习

测试报告

测试完成后，进入一般意义上的最终阶段，编写测试报告。编写报告按照内部要求完成即可。
重点在于测试数据统计及风险评估。

发布及线上跟踪

该阶段只针对线上项目，
测试报告完成后，测试工作并未完成。完成版本测试后，还需制定严格的发布计划，按照发布流程执行。

测试同学需要注意的点：
1、版本发布内容（需考虑旧数据、旧版本兼容，是否需要提前准备测试数据、账号等）
2、常规功能检查（检查单，需要有发布测试用例）

发布流程一般为：
1、停服公告
2、踢人、锁客户端、停服
3、服务版本更新、sdk更新等
4、白名单测试
5、开服、客户端更新
6、线上体验及跟踪

注意事项：
1、开服后需完成功能验收，部分功能需要借助真实玩家及等待时间开启；
2、关注玩家群、客服反馈、游戏数据监控等；

复盘

完成上述流程后，针对过程中的问题、优点，开展复盘工作。以此为后续工作提供参考。
推荐几个常用的复盘方法论：
a. KISS复盘法
b. PDCA循环法
c. GRAI复盘法
d. KPT复盘法

复盘往往针对问题，复盘不能是走过场，一定要落地，把问题原因分析好，并制定落地方案，在后续工作中持续监督是否改善。并持续复盘。

注意事项：
1、就事论事，落地方案可量化，需责任到人，截止时间；
2、每次只针对最紧急的前3个问题，往往解决了前3个问题，就解决了70%的问题。

常用工具简介：

项目及Bug管理：tapd、飞书、禅道、Jira、Bugfree等；
版本管理工具：SVN、Git等；
测试工作常用的工具：nodepad++、beyondCompare、adb、itools、Xshell、Navcat、DBeaver、Workbench等。

导师寄语

当我们初出茅庐时，内心深处就要种下强者的种子。从开始参与基础工作时就要在内心深处暗示自己，要带着全局的眼光和思维去对待每一次工作内容。这样才能让你思考的更多、看的更远。不要让自己潜意识只认为自己是工作的执行者，要认为自己是工作的主导者。习惯和信念的力量是无穷大的，因为我们终将从小白成长为顶尖的测试专家。加油！！！