游戏测试用例

对于一个软件质量过程来说,设计测试用例是必不可少的一环,而好的测试用例不但易于执行也利于维护。好的测试用例不但覆盖全面而且不会有太多的冗余用例,要达到这个效果,必然要有一个清晰的思路。我自己常用的一套思路是从开发引申出来的:面向对象。举例说明如下:

我们要测试一个登录功能,此功能要求用户必须输入两个参数:用户名和密码,然后提交给服务器验证,通过,返回responsecode=200,用户名错误201,密码错误。

我们把登录功能作为测试对象,对象包括属性和动作两个部分。那么这个对象的属性有用户名,密码两个。而动作有发送数据到服务器,接收数据,数据校验三个。我们要为用户名和密码两个属性设计用例,还要为三个动作设计用例。但是当我们设计用户名和密码的测试用例的时候,发现用户名和密码也是两个对象,这个时候我们就再次细分这两对象,结果如下:

对象名:用户名

属性:长度,符号集,正确性。

对象:密码

属性:长度,符号集,正确性,掩码。

这样我们就可以这样设计用例,长度根据等价类划分原则可以用6个用例,空,最小长度减一,最小长度,中间长度,最大长度,最大长度加一。符号集6个:字母,数字,上位键符号,非法字符如单引号,混合,空格符;正确性2个,正确和错误。那么用户名输入的用例用例为14个。

同理设计密码的测试用例。最后剩下三个动作的测试用例,对于动作我们主要考虑一点就是动作完成与否。为此可以这么设计:发送数据到服务器这个动作就一个用例,发出数据到指定服务器,预期是服务器端收到发送内容。接收数据也一个用例:接收到服务器发送的指定数据。数据校验这个动作的用例不用写了,为什么呢?因为这个动作的用例在前面的用例中已经被覆盖到了,再写就是重复的。

使用这种方法只要能够把对象找正确,那么设计的过程就非常清晰,便于评审和维护检查。


https://www.360docs.net/doc/bf12281326.html,/

不用部署,免费注册,还有截图功能。你去试一下.
测试用例只能说尽可能的覆盖全面,这个覆盖全面可能需要很久的积累来做的。简单一点的可以按照下面几个步骤做。

第一,确认用例是否完全覆盖了需求说明书所描述的所有功能点及逻辑。可以使用各种用例的设计方法来满足,边界值,等价类,判定表,因果图,正交分析,场景法等等。别看这些东西大家都在说,真正用好很难。

第二,尽可能的考虑及补充需求说明书并未描述但是实际存在的功能及逻辑。这个可以通过需求评审,用例评审来做。

第三,尽可能考虑异常情况,可以从

可靠性,安全性等方面入手。

第四,可以通过平时的积累来达到,比如建立用例库,经验库等。

第五,就是要靠自己的经验和第六感了,呵呵~这个不靠谱,但是确实可以利用。

做到完全覆盖基本不可能,但是我们可以尽可能覆盖。注意,在尽可能覆盖的同时也要考虑测试周期及项目时间的分配。


 1、用例覆盖程度

毫无疑问,这一点应该是最重要的,无需多说,覆盖率最大化是一套测试用例的最重要评价标准,如果漏测就杯具了。

2、用例是否已经达到工作量最小化

在满足用例覆盖程度最大化的前提下,应该尽量减小执行用例所需要的工作量。这些方面的方法有不少,如条件覆盖,分支覆盖,正交覆盖等方法。面对不同的测试对象,也有不同的方法来保证:对于网页背后的php逻辑,可以通过在网页上测试后,用一些工具比如xdebug来统计代码覆盖率;对于向外提供接口的server,采用的方式就是分析在外面暴露的接口设计用例,大致的通过接口参数来估计一下分支判断的情况。

3、用例的分类以及描述是否足够清晰

用例的分类,在这里是指相同类型的用例是否放在一起了。例如:接口类的用例,参数的取值范围是1-3,但是现在却传入4;数据类用例,状态机现在位于状态2,却要求状态跳转到无法到达的4;逻辑类用例,正常功能的产出等。将相同类型的用例放在一起,有助于理清思路,清楚了解用例设计是否完备。

用例的描述,是指描述的清晰程度是否能够形成文档。例如上面参数取值范围的例子,用例这样写:“传入错误的值”或者“传入非1-3的值”,明显没有写成“传入值4”有效。这与写程序一样,总是写闭区间的范围而不是开区间。

4、用例是否表明了测试目的

写明用例的测试目的,对文档的易于理解性和工作交接的好处不言而喻,现代软件工程不可能只有一个人在做事情,项目于人员的变动也是难免的。在过程中留下足够的信息,可以在后续工作提高很多效率。

5、测试用例的易于维护性

如果被测对象有所升级,测试用例的说明或者脚本是不是容易维护呢?例如在有状态机的情况下,测试用例之间是相互依赖的(即需要一定的执行顺序),这样被依赖的用例修改后,后端不需要同步根据修改。而如果用例之间没有相互依赖关系(如用例是自己造的数据,不是依赖于前端的产出),可能一旦有变化,就需要修改这两个。当然,这两种情况不能绝对的说哪种好,是需要看实际使用时候的情况进行取舍的。不过,通过一些系统性的工具支持,也会出现一种做法绝

对性的好于另外一种的情况,情况很多,做法也有很多,在这里就不多说了

相关文档
最新文档