游戏风云之敏捷&移动时代的测试用例

在敏捷时代,尤其是在一个快速迭代的手游项目中,整体的项目周期乐观估计就1年,测试介入项目时,已经到项目开发的中后期了,留给测试人员的时间本来就不多,还有没有必要花费时间去写测试用例?如果写,测试时间被压缩,如果不写,容易出现漏测情况,怎么解决?这个问题已经成了很多手游公司中测试人员纠结的问题之一,值得我们详细的探讨一下。

首先,我们还是来看一下是什么因素导致了不写测试用例的现象的出现。从项目经验来看,主要的因素来源于2个方面。

1、研发流程变化

在现在的手游团队中,一款游戏的研发周期已经比端游时代缩短了非常多,项目周期比较长的也就1年左右,何况那些换皮的团队,也就两三个月,项目就上线了。整体研发流程的时间缩短导致各个环节的时间都被压缩。

在这短短的研发周期内,扣除前期的demo制作,项目定型等环节,测试人员介入时基本已经到了项目中期左右了,此时留給测试人员的时间也就几个月。在这种外部严峻的环境逼迫下,如果还按照端游时代书写详细的测试用例,然后评审,然后执行等旧有流程,显然是不符合实际情况的。

2、认知误区

很多同行认为写测试用例是不必要且浪费时间的一件事,原因无外两点,一是被外部环境所迫又没有找到有效的解决方法,二是很多最近两三年入行的新同学们刚入行就加入到了手游行业,没有经历过传统软件或端游时期的严格训练,不太可能摸索出有效的应对方案。

从入行就没接触过测试用例的书写,周围的环境也不允许,所以很多项目不写测试用例也就不足为奇了。

也有人认为测试要走高大上的路线,比如自动化和白盒,这没有问题,这些仅仅是测试方式的不同,无论何种测试方式,都是针对某个特定场景去设计测试用例,去验证测试场景是否存在缺陷,方式的不同不能认为测试用例是可以忽略的。

说完以上这些原因,我也说说我的看法,个人觉得测试用例还是要写的,不仅要写,还要评审,但是方式也应该与时俱进,最好不要纠结于特定的形式。

测试用例书写

测试用例的书写没有必要遵循一定的形式,比如用excel、xmind、伪代码等都可以,只要把测试场景的测试方法描述清晰即可。书写的目的并非为了好看,而是为了让测试人员清楚测试场景的逻辑,让执行人员能够清晰快速的执行即可。

而且有些内容可能都是灵光一闪,如果不记录下来,可能测试的时候就会漏掉这个测试项。

测试用例书写的基本思路如下:

游戏测试用例编写思路

既然用例要写,怎么跟紧迫的时间协调呢?个人认为用例写的形式要变通一下,无需像以前一样事无巨细的全部写清。根据需求文档,将功能的重点逻辑拆分出来,仅就这部分来书写即可,一些通用的和无关核心的边缘内容忽略即可。既可以理清功能逻辑,又可以节省时间。

测试用例评审

用例写完尽量喊上负责这个功能的策划和开发人员一起评审一下,主要目的有2个,一是让大家就功能本身达成认知上的一致,二是大家就用例本身多思考一下,避免逻辑上的漏洞

达成思路一致在研发流程中非常重要,因为在研发过程中,功能需求会议后大多是单独沟通,很容易出现信息孤岛。在整个功能研发流程中,功能需求会议和用例评审是重要的2次打通信息孤岛的环节。

游戏用例评审

在评审过程中,策划、开发、美术和测试就功能本身及需求变更再次达成认知一致,这样功能研发出来后才不至于出现信息不对称导致的返工。

当然,评审也可以变通一下,如果时间允许,可以找个会议室一起认真的过一下,如果时间不允许,可以发送給功能相关人员,让他们提供意见即可,或者测试人员内部简单过一下也可以,不要拘于形式,以项目实际情况做适宜的变通。

源自 公众号  游戏测试风云录



留言