斗地主功能测试实战一之需求分析

一、前言

  经过前置大量的基础内容学习，目前已经进入到实战阶段啦，意味着在基础篇已经接近了尾声，从本文章开始会结合前置的文章所学内容以及新内容以用于在斗地主的讲解之中，让大家能够充分的运用与学习~
  笔者之所以选择斗地主，而不选择当下火爆游戏进行讲解的首要原因是斗地主更容易理解且逻辑性清晰、易学习，方便大家进行实操，希望读者能从中受益。
  本实战系列只会进行功能测试的相关讲解，在后续的文章中会逐渐介绍接口、自动化、专项测试等维度的内容，敬请期待~

二、测试需求分析与展示

  再进入正式的需求分析前，大家必须要了解的就是为何要做需求分析，面对一个逻辑性较强或较大的系统、模块时，需求分析能够帮助我们快速理解策划“想要的”、需求要“做什么”、“怎么做”，更重要的是需求分析是为了给测试用例的设计做铺垫，而用例设计是否优秀的一部分则来源于对需求理解是否足够透彻。

  

三、需求分析实战

  整体的斗地主内容较多，故此只演示部分，部分需求展示如下所示：

  分析第一段话的第一句：第一轮先叫地主的玩家由系统随机选定。后续轮如果同一桌没换人则由获胜玩家（先出完牌的玩家）先叫地主，如果换人则继续随机。

  如果仅仅是根据需求进行思考分析，那么无法想出异常点，由需求只能够得出：

  实际上，分配地主这个事件本身就是一个随机事件，随机事件就会涉及到概率，那么由此可以新增一条：

  只有第一轮的地主是随机指派的，那么会涉及到一个“正反”，即：第一轮和非第一轮：

  有人中途退出重新进入新的玩家，就又会走第一轮的随机逻辑，故此也需要清除：

  很明显，需求中所提及的“退出”这个概念不明确，断线重连、较长时间的断网恢复后是否也算退出，杀进程恢复，切后台等等是否会计算在“退出”这个范围内

  分析第二句需求：如果有玩家在叫地主前选择"明牌"，则第一个选择"明牌"的玩家优先获得叫地主权，因此由需求得出：

  明牌是一个操作行为，玩家需要手动进行点击选择明牌后，玩家才会明牌，这意味着在地主由系统分配或确定一个地主前，玩家可以随时进行明牌，如果两个玩家在同一时间进行明牌，地主的权利应该会给谁？（真实的情况肯定会有时间差异，由服务端进行计算先后顺序，可能会有微秒的计算差异 ，如果真的出现时间完全一致的情况下，则随机给予一名玩家）：

  在真实的工作经历中往往边界值更容易出现问题，第一次叫地主的流程顺利，不代表第二次仍然处于逻辑正确的情况（写代码的人懂的都懂），故此我们仍需要对流程进行“边界值”测试：

  那么现在，让我们来分析第三段需求：如果有玩家在叫地主前选择"明牌"，且三名玩家都不选择"叫地主"，则系统选择第一个，"明牌"的玩家为地主。无人明牌且无人叫地主则第一位叫地主的玩家为地主。

  如需求所示，顾名思义，有玩家明牌的情况且三位玩家均不进行地主争夺，默认地主牌权交给明牌玩家，那么由需求可得：

  为了验证代码中的逻辑是否真的是选择了第一个明牌的玩家，在测试过程中需要有两名或三名玩家均进行明牌，来确认代码逻辑是否正确，是否选择的是第一个明牌的玩家：

  无任何玩家叫地主、明牌时，第一位拥有叫地主权利的玩家默认为地主，由需求可得：

  需求，毕竟也只是需求，会存在遗漏，那么需要根据自己对叫地主的理解，进行用例设计的补充，这往往是最困难的，更依赖测试人员的思维以及对游戏的熟悉程度（知道为啥之前讲解熟悉游戏能够更好的保证测试质量了吧），根据对斗地主的基础认知，大致可以补充以下内容：

  上述列举的是测试点，测试用例的设计会在后续的用例设计文章中进行设计，三句需求写出12个测试点，还补充了一些遗漏的需求，这是最后分析对应的需求所得出的结果

  

四、模块拆解

  需求分析完成后的步骤就是对游戏整体进行拆解，拆解游戏整体划分出子模块的分支测试点可以帮助测试人员更好的理解需求，梳理需求，为后续的测试用例设计进行铺垫，大致可以拆解成以下标签（以下的展示非测试用例，只是子模块分支下的拆解分支点）：

  下述所展示的拆解模块为大部分拆解点，因游戏设计不同，故此拆解模块会存在差异，大多数内容是当下斗地主通用的逻辑和测试点，根据需求划分出拆解点后，在对应的模块划分这里就已经做好了充分的准备

  上述所介绍的是斗地主游戏全局的拆解点，如果只针对需求中所提及的叫地主的三点那么它的拆解位置大致是：

  游戏中某一个划分子模块的内容按照上述的划分即可，用例设计的结构后续也会按照该结构进行设计~

  
  

  好啦~以上就是本次文章分享的全部内容啦，你学会了吗？希望能给大家带来帮助哦！