在敏捷时代，尤其是在一个快速迭代的手游项目中，整体的项目周期乐观估计就1年，测试介入项目时，已经到项目开发的中后期了，留给测试人员的时间本来就不多，还有没有必要花费时间去写测试用例？如果写，测试时间被压缩，如果不写，容易出现漏测情况，怎么解决？这个问题已经成了很多手游公司中测试人员纠结的问题之一，值得我们详细的探讨一下。
首先，我们还是来看一下是什么因素导致了不写测试用例的现象的出现。从项目经验来看，主要的因素来源于2个方面。
1、研发流程变化
在现在的手游团队中，一款游戏的研发周期已经比端游时代缩短了非常多，项目周期比较长的也就1年左右，何况那些换皮的团队，也就两三个月，项目就上线了。整体研发流程的时间缩短导致各个环节的时间都被压缩。
在这短短的研发周期内，扣除前期的demo制作，项目定型等环节，测试人员介入时基本已经到了项目中期左右了，此时留給测试人员的时间也就几个月。在这种外部严峻的环境逼迫下，如果还按照端游时代书写详细的测试用例，然后评审，然后执行等旧有流程，显然是不符合实际情况的。
2、认知误区
很多同行认为写测试用例是不必要且浪费时间的一件事，原因无外两点，一是被外部环境所迫又没有找到有效的解决方法，二是很多最近两三年入行的新同学们刚入行就加入到了手游行业，没有经历过传统软件或端游时期的严格训练，不太可能摸索出有效的应对方案。
从入行就没接触过测试用例的书写，周围的环境也不允许，所以很多项目不写测试用例也就不足为奇了。
也有人认为测试要走高大上的路线，比如自动化和白盒，这没有问题，这些仅仅是测试方式的不同，无论何种测试方式，都是针对某个特定场景去设计测试用例，去验证测试场景是否存在缺陷，方式的不同不能认为测试用例是可以忽略的。
说完以上这些原因，我也说说我的看法，个人觉得测试用例还是要写的，不仅要写，还要评审，但是方式也应该与时俱进，最好不要纠结于特定的形式。
测试用例书写
测试用例的书写没有必要遵循一定的形式，比如用excel、xmind、伪代码等都可以，只要把测试场景的测试方法描述清晰即可。书写的目的并非为了好看，而是为了让测试人员清楚测试场景的逻辑，让执行人员能够清晰快速的执行即可。
而且有些内容可能都是灵光一闪，如果不记录下来，可能测试的时候就会漏掉这个测试项。
测试用例书写的基本思路如下：
既然用例要写，怎么跟紧迫的时间协调呢？个人认为用例写的形式要变通一下，无需像以前一样事无巨细的全部写清。根据需求文档，将功能的重点逻辑拆分出来，仅就这部分来书写即可，一些通用的和无关核心的边缘内容忽略即可。既可以理清功能逻辑，又可以节省时间。
测试用例评审
用例写完尽量喊上负责这个功能的策划和开发人员一起评审一下，主要目的有2个，一是让大家就功能本身达成认知上的一致，二是大家就用例本身多思考一下，避免逻辑上的漏洞。
达成思路一致在研发流程中非常重要，因为在研发过程中，功能需求会议后大多是单独沟通，很容易出现信息孤岛。在整个功能研发流程中，功能需求会议和用例评审是重要的2次打通信息孤岛的环节。
在评审过程中，策划、开发、美术和测试就功能本身及需求变更再次达成认知一致，这样功能研发出来后才不至于出现信息不对称导致的返工。
当然，评审也可以变通一下，如果时间允许，可以找个会议室一起认真的过一下，如果时间不允许，可以发送給功能相关人员，让他们提供意见即可，或者测试人员内部简单过一下也可以，不要拘于形式，以项目实际情况做适宜的变通。
源自 公众号 游戏测试风云录