我们在日常工作中经常会遇到一个问题，我们负责的功能提测后，会发现跟开三方的时候不太一致，还有就是策划验收时候，经常会出现QA，策划，程序理解不一致，做出的结果有偏差这类事情发生。也有遇到过自己带的外包同学有时候会来问，这个功能怎么样才是正确的，但是游戏内的功能在很多情况下没有严格意义的对与错的区别，往往我们要根据游戏类型，玩法目标，面对的群体以及策划的设计等等因素来最终得到一个比较合理，有趣，吸引玩家的功能。我一直在思考我们是否可以在更早期的时候就预防此类问题的发生，因为等到测试阶段再去对需求往往要付出的代价更多。由此想要写这样一篇文章来和大家探讨一下需求分析这件事，当我们把需求分析做的更加透彻，清晰和明确的时候，对于后续测试用例的编写，一些模棱两可的问题的交流，甚至于迁移到海外版本的时候都能有很大的助力。
测试需求分析，也就是我们读策划案，写文档分析再到最后开三方的全流程，这个过程就是我们日常工作的整个测试需求分析的阶段。
需求分析是指从测试角度对策划文档中的需求进行理解分析，发现并提出文档中的设计缺陷、需求不明确或者极容易引起玩家体验上不愉快的地方。
这是最最最重要的一环，也是我们日常工作中文档分析的工作，相信大家都十分熟悉了。我们会提出需求文档中一些有争议的点让策划给出更细致明确的需求，除此之外，这个过程也是我们熟悉需求，明确需求，挖掘测试点的过程，笔者个人的习惯是在做文档分析的时候就可以开始写思维导图了。
在这里解释下我上一段提到的思维导图，这也是除了希望策划回复的部分外，一个自我梳理需求的过程，我觉得它也是测试用例的“前世”，在这个阶段，我们基本上已经把功能梳理清楚，至少我们已经拆分到了每个功能点，甚至是测试点。此时我们后续的测试用例其实已经完成了骨架的部分，测试用例其实就是对每一个测试点根据一些方法进行细化使它变成一条条可执行的用例。到这里，相信我们在后面三方会议的时候，会更加游刃有余。
02 如何做需求分析
老师教学生要因材施教，生产力发展要因地制宜，那我们做需求分析也需要对不同类型的需求找到适合的分析方法。相信我们每个人在需求分析这个赛道都有自己的方法，这一部分就分享一下我自己需求分析的一些小方法。
拆解需求是需求分析中很好用的一个方法，因为我们经常会遇到一些非常庞大复杂的功能，比如笔者曾经遇到的结婚系统，任务系统等等。如果我们能够合理的把这些复杂的功能拆解成一个个小的功能，那对后面的测试会有很大的帮助。
偷懒法的前提是，你遇到了一个写案子非常nice的策划。我们工作中遇到的策划写案子的水平确实参差不齐，当你遇到一个策划案写的非常棒的策划时，你的需求分析就成功了一半。如果策划在自己的案子中画好了逻辑清晰的思维导图，并且对整个系统做了一些拆解，这对于看文档的人是一个很好的辅助，我们修修改改就可以得到一份QA做好测试需求分析的思维导图了。但是一定要小心策划案中的小陷阱，因为有些策划会在文档中自己拆解功能，当你看到ABCD or 1234，千万不要以为可以跟着这个分段来拆解，因为他的思路可能不是按照我们需求分析的思路来的，这种情况下我们还是要理解需求后自己去做拆解比较好。当我们遇到一个相对比较复杂的系统的时候，可能一开始看到密密麻麻的文字会觉得一头雾水，无从下手，此时大家可以尝试把需求简化。首先，先找到需求的主干部分，就好比找到一棵树的躯干，这是它的根本，找到了需求的主干部分，我们再一步步去找它的枝叶以及一些附加的内容。比如，很多游戏中都会有的社交系统，这类系统可能分为很多不同的阶段，我们可以先找到玩家从加好友到达到某种好感度再到最后成为师徒或者密友或者伴侣关系这条主干线，其余的所有附加的玩法流程都是基于这条主线展开的。接下来我们找到主线每个环节的前置条件，相当于树杈从什么地方开始分叉，比如加好友的前置条件是本服还是跨服？结为伴侣关系的前置条件可能会有性别，好友亲密度等等。下一步我们去找每一个环节的躯干，比如加好友都有哪些环节，拜师都有哪些环节，相当于找到了每个分叉的躯干部分。最后剩下一些修饰的功能点，我们把它当做枝叶一个个添加到对应的树枝上，逐步完成对功能的需求分析。这样的好处就是先把复杂的功能简单化，不至于让我们看到一个复杂的系统时茫然无措，同时我们也在简化需求的过程中找到了需求最核心的部分，也是我们冒烟测试应该测的内容，在排期不足的时候我们也能更清楚的分清主次，必要时也好做出取舍，最后也能帮助我们在排期估时时更加准确。流程图其实是拆解需求一个很好的工具，帮助我们梳理思路，做好功能的拆解（1）先通过流程图的方式梳理清楚整个玩法的大概流程，同时把一个大的系统分成的一个个小的子功能。（2）接下来我们再对每一个子功能画出玩法流程图。这时，子功能的流程以及每一个阶段的核心需求已经很清晰了。（3）根据上一步划分的每一个子功能的流程图完成需求分析上一步我们已经整理好核心需求，接下来只需要根据每一个核心需求一步步完成需求分析整理出测试点即可。针对一些比较小规模的，我们不够熟悉的功能甚至是一些小优化，其实搞不好很容易出大问题，所以针对这一类功能，我们要把原本的需求进行扩充从而使测试更全面。所以这一部分的宗旨就是“化简为繁，化小为大”我们在需求分析过程中要警惕一些“一句话需求”，对于这种模糊不清的需求，我们可以按照5W1H的思路去扩充需求（PS：如果真的是写的过于简单且条理不清的需求文档还是建议大家直接打回让策划重写吧，不必浪费时间）。（1）What (是什么)：明确这个游戏功能是什么，比如是一个角色技能、一个宠物装备、一个时装功能等。（2）Why (为什么)：确定引入这一功能的目的，是为了增加游戏的趣味性、提高玩家互动、增加游戏的可玩性等。（3）Where (在哪里)：确定这个功能在游戏中的位置，是在游戏界面的哪个位置展示，或者是在游戏中的哪个场景中使用。（4）When (何时)：确定这个功能应该在游戏的哪个阶段或时间点出现，是在游戏的哪个阶段解锁，或者是在游戏的哪个时刻触发。（5）Who (谁)：确定这个功能对哪些玩家群体产生影响，是针对新手玩家还是老手玩家，或者是对多人游戏中的团队合作产生影响。（6）How (如何)：确定游戏功能的规则是什么，需要哪些技术支持，需要哪些资源投入，以及这个功能会如何影响游戏的平衡性和体验。对于不够完善的需求我们按照上述六个问题从策划的文档中去寻找答案，找不到答案的部分就是我们在文档分析平台上应该提问的了。对于一些我们不熟悉的功能，要多多去体验同类型的游戏，体验后再去看策划案一定会发现很多漏掉的细节，同时也是让我们自己熟悉此类玩法的过程，也能帮助我们深入分析需求。我们接到的需求很少会有完完全全独立的一个功能，多多少少都会和其他功能有一些交叉，所以我们在需求分析的时候一定要考虑这些耦合功能的影响，比如很多游戏都会有跟宠系统，大多数时候这些跟宠的属性、技能等会在一些PVP或者PVE玩法中生效，我们如果要加一个新的跟宠，那我们做需求分析的时候就要考虑其他需要跟宠出战的玩法中本次新加的跟宠是否可以应用于该玩法以及相关数据是否正确。我们在工作中经常会遇到一些堆量系统，比如任务，技能，跟宠等等，这类系统的功能点很琐碎且重复性很大。我们不可能对每一条剧情进行需求分析，此时我们可以使用等价类的方法来对这类系统做需求分析。这个方法我们在设计测试用例的时候经常用到，其实在做需求分析的时候也可以作为参考，只是相比于原本测试用例中的等价类划分，在需求分析中更偏向于找共性。重复性很大的功能必然有一定的共性，找到他们之间的共性归为一类，然后我们对于这些共同点就只需要测一次功能就好，其余的就是对一些重复配置的测试，这些我们可以利用脚本，表检查等方法去代替重复工作。以很多游戏中都会有的剧情任务系统为例，无论是主线，引导任务或是探索任务，都是通过一环又一环的任务通过前后驱任务连接而成一条完整的任务线。通过找共性我们可以发现每一环任务的共同点就是：接取任务----完成任务条件----交任务。如此看来无论以后策划想要配一个多少环的任务，对于功能本身而言我们都可以看做只需要上述这三步即可。接下来对每一步进行需求分析，同样去找共性，比如完成任务条件，杀怪，提交道具或者是完成一个小玩法，那我们其实只需要测试杀怪的触发器或是小玩法这个功能即可，只要功能没有问题了，无论哪一环任务用到了这些功能，我们在后续的测试中只需要测试该功能在任务中的使用即可（也就是跑一下主流程），不需要每一环任务都完整的正例反例去测一遍这个功能本身。
这一部分想以主线剧情为例讲一讲玩家体验这件事，可能略有点偏离需求分析的主题，但是思考了许久还是决定写下来，我觉得这也算是另外一种意义上的需求分析。剧情测久了，总是忽视掉很多体验上的问题，而恰恰主线剧情是用来交代整个游戏世界观的，一旦偏离了世界观，会给玩家带来很割裂的感受。往往在测试的时候我也只会当它是上一部分所说的堆量系统中的一个任务量，忽略了它本身有很多主观因素在里面，比如npc的性格，人物关系，前后章节的连贯。在拿到一条新的提测的剧情主线时，跑完一遍就会先入为主的认为这是一个什么样的故事，但这很容易陷入一个误区，我认为的不一定是文案想要表达的，那么会不会玩家认为的也不是文案想表达的？所以我们在测试功能的同时，也要验证文案表达的准确性。接下来分享几个我觉得可以发现问题的小方法。尽可能多的去找文案要世界观的架构图，人物关系图还有核心npc的设定文档，帮助我们更好的理解人物概况，在后面的测试中如果有出入，我们也能及时发现。先跑剧情后看剧本就是为了让我们摆脱一些因为自己“知道的太多”而带给自己的一些束缚。剧情主线提测后，我们可以先通跑一遍流程，跑完之后心里一定会对本章的剧情有一个初步的了解，再多跑几遍之后心里就会有一个故事的梗概了，然后带着自己所理解的故事再去读一遍剧本，去对比剧情任务和剧本所讲述的故事是否一致，在对比中就会发现一些拆环不合理，或者衔接不当的问题。主线剧情每一章的更新都需要很漫长的时间，有些甚至需要半年之久，我们可能已经忘记上一章停在那里，讲的是什么，所以测新的剧情前最好是再去跑一遍前一两章的内容找回一些记忆，好保证剧情的连贯性。微博，B站有些up主经常会分享每一段剧情的解说，可以时常去看看玩家的视角是怎么解读剧情的，一定会有一些意想不到的收获，而且不同的up主有不同的解读，我们会看到更多彩的视角，可以拿来跟策划分享沟通，对我们后续剧情的发布有很大的益处。
1）不做自己“不擅长的事情”
在策划案中如果有一些影响其他模块的功能点，一定要告知对应的QA，不要自以为自己了解其他功能就可以顺带回归，一定要找负责人完整回归测试，以防漏测错测。
2）表检查
策划一般在给出策划案的时候，就已经把新的配表附在策划案中了，我们可以在需求分析的时候就开始根据配表字段和规则整理表检查，这个之前测试中心的课程有很详细的介绍，大家可以多看看。
3）风险预案
我们无法保证一个功能上线一定没有bug，但是我们可以尽可能通过一些方式规避一些问题，或者是当问题发生后我们是否有一些手段能将损失降到最低，所以可以在需求分析的时候就尽量做出风险预案，三方的时候就可以提出来，这样程序在功能开发期间就可以兼顾到。
4）代码review
一些大型功能，尤其是涉及到经济的模块，代码review是很有必要的，所以在需求分析的时候也要考虑这一点，好提前安排。
在大大小小经历了很多功能之后，会发现有很多测试点是每个功能都需要去考虑的，我们可以自己列一个checklist，如果在需求中没有提到这些要素，我们也可以及时补充和检查。
1）开关
首先总开关一定要关得干净，保证一个开关可以关掉整个玩法包括道具的使用，系统面板以及奖励的领取，并且开关关闭后要有反馈。其次，也要对子功能做开关，防止在某一个小功能出现紧急问题的时候，我们只能关闭总开关，造成不必要的损失。
2） GM
我们在做需求分析的时候，同时也能梳理出来我们测试中可能需要的 GM 来方便测试。第一，是日常测试中便于我们测试使用的。第二，是方便线上救急使用的。
3）红点
想必大家都感受到过游戏内红点泛滥的情况，滥用红点是很可怕的，但是没有红点也是万万不可的，所以无论什么功能一点要在需求分析时明确红点规则。
4）log
Log 记录详细便于我们后续查问题用，且新增 log 一定要登记，不登记的话线上服务器是查不到日志的。
5）异常情况
服务器重启，断线重连，等等异常情况发生的时候要有保底措施，保证在异常情况发生后玩法数据，面板等等相关功能还可以正常继续下去。
6）log监控
必要时要加一些log监控，在某些数值超出一个阈值时及时报警给我们，帮助我们迅速发现问题。
7）玩法引导
新的玩法功能，一定要有简单准确的引导，让玩家快速上手。
8）海外
如果游戏有发行海外的话，我们每一个功能都要考虑海外的迁移，以及海外的法律法规等等，这些后期如果再改的话是很麻烦的。
9）活动的复开
一些将来会复开的活动一点要注意，不要做一次性的功能。下次开的时候一定要用上次参加过活动的账号测试。
10）限时活动善后
限时活动结束后要考虑是否需要特殊处理一些活动期间产生的道具、货币等。比如一些特殊节日的活动可能会产出一些特殊代币或道具，活动结束后这些代币的使用和如何转化为基础货币要提前考虑处理方案。
11）玩家中途改名称
涉及玩家昵称的功能要考虑玩家中途改名后是否需要及时同步。
04 需求分析要落地
在工作中经常会遇到策划开完三方后不更新策划文档的情况，在文档分析平台验收的同时也要督促策划修改文档，保证最后程序和QA都是以三方会议中大家确认过的最终的需求开展工作。
测试期间需求有变更，或者上线后新增的优化，我们要及时进行简单的需求分析并更改自己的测试说明以及测试用例等相关文档。
05 结语
好的需求分析是把策划的变成自己的一个过程，通过需求分析我们对自己将要负责的功能做一个深入的了解，从而保证我们后面的测试工作更加顺利和全面。同时，也是一个测试前移的过程，在需求分析阶段我们能够更多的发现问题，尤其是设计上的漏洞，往往这些问题在后续提测后再发现修复的成本会更高。最后，希望我们都能做好需求分析，测试顺利！
' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
作弊、反作弊与反反作弊
一名测开的任务升级攻略
从小白开始和日志打交道的那些事
都看到这里了，点个赞再走吧~
