测试需求点不是很难做

发表于:2008-09-28来源:作者:点击数: 标签:需求
测试 需求 点 的改进。 网络 上有一个帖子说微软的用户登录功能的 测试用例 有5000个 测试用例 ,很多做测试的朋友第一个反应是变态。大家的这个反应有很多妒忌、羡慕的意思,其实更多的是不知道为什么微软会写那么多的测试用例,而如何写出来(这是 测试人
 测试需求的改进。网络上有一个帖子说微软的用户登录功能的测试用例有5000个测试用例,很多做测试的朋友第一个反应是变态。大家的这个反应有很多妒忌、羡慕的意思,其实更多的是不知道为什么微软会写那么多的测试用例,而如何写出来(这是测试人员第一个基本功)就更不了解了,于是才有了这个反应。其实编写测试需求,编写测试用例几万,几十万,几百万并不是一个很难的事情,关键看你是否掌握编写测试需求以及测试用例的方法。
    测试需求的来源是系统需求报告(或者叫软件规格说明书等名字),测试需求报告主要内容是本次测试需要测试那些点,一般的系统需求说明书是按照系统,子系统,模块、功能、子功能、数据的形式来编写的,(这里是指的比较规范的需求说明书),比如人力资源管理,可能包括前端人力资源管理子系统(给人力资源部门的
工作人员使用),后台管理子系统(系统管理员进行用户管理,权限管理等操作的系统)。用前端人力资源管理子系统而言一般有人员基本信息管理模块,薪金管理模块等模块,而人员基本信息管理模块又可以分为添加新人员基本信息功能,修改人员基本信息功能,删除人员基本信息功能,查询人员基本信息功能,汇总人员基本信息功能等功能,而在添加新人员基本信息功能里会涉及到人员基本信息的具体数据内容,比如人员姓名、性别、出生时间、到本单位的时间等信息。以上内容都应该在软件需求报告中获得,很多单位由于开发流程的差异测试人员即使不能在需求文档中获得,也应该可以从概要设计文档或者详细设计文档中获得,最糟糕的,也可以从开发人员的开发的系统上获得(顺便说一句,测试人员获得这些信息的顺序,可以代表开发部门开发的规范性和开发能力的高低,越早获得说明开发越规范)。作为一个测试人员可以依据这些信息编写测试需求,但此时编写的测试需求会很粗糙。一个系统编写的测试需求点会是几百到几千之间。写到这一步作为初级测试人员应该是很不错了,但这些东西都是用开发人员的成果转化过来的,还没有看出测试人员的能力。让我们将测试需求点进一步分割下去。拿人员基本信息管理的添加功能来举例吧,首先:可以分为添加0条数据,添加1条数据,添加n条数据。添加0条数据是指进入添加功能界面,然后不添加数据直接退出,(我曾经见过有一个系统在用户进入添加数据界面后你不添加数据就不让你退出添加功能,没有天理呀),添加一条数据就是添加一个数据,然后退出添加功能的界面,添加n条数据是连续添加数据。添加0条数据不能再扩充了。但添加一条数据和添加n条数据是可以扩充。比如姓名输入域可以测试的内容包括:标准数据,合法数据,非法数据。标准数据是指在输入最不可能出错的数据的情况下,该功能是否可以使用,如果在我们选择最不可能出错误的数据的情况下系统无法使用,我们就认为此功能根本不可使用,下边的合法数据的测试以及非法数据的测试就可以不进行了。合法数据的测试是对系统来说应该可以处理的数据,比如拿日期型数据来说,有闰年的问题,所有月的第一天,所有月的最后一天,年应该是4位,月可以是2位或者1位,而且应该小于等于12,另外一个是年、月、日之间应该有分割符号,这些内容都可以作为合法数据进行测试。如果合法数据测试通过则我们认为系统在处理合法数据的时候是应该没有问题的,如果项目时间紧张,在完成此类测试后就可以给用户试用了。这里有几个问题大家主要注意一下,一个是合法数据测试完成并不意味着测试完成,因为测试非法数据的测试还没有执行,而且就一般的规律来看,在输入非法的数据的情况下,系统出问题的可能性更大,之所以说可以给用户使用主要是迫于工期的压力,我们可以将部分测试工作和用户试运行这两个工作并行,但任务并行必然带来风险,如果开发人员都是熟练的开发人员(简单说都是5年以上的开发人员),风险会比较小,如果开发团队都是1-2年的开发人员最好不要并行。(风险太大)。第二点,在合法数据我们会进一步细分,比如单个数据输入域合法数据的测试和组合输入域的合法数据测试,单个数据输入域的测试,是在标准数据的基础上,对某一个测试输入域的合法数据进行测试,这样比较好明确的发现问题点,对开发人员的帮助会比较大,比如在人员基本信息管理的添加功能的测试中,我们有了标准数据,在标准数据测试通过的情况下,我们对姓名数据输入域进行测试,那么我们会将标准数据作为一个基准,在其他输入域不变的情况下(前提是其他输入域没有唯一性要求)只测试姓名输入域在合法数据的测试情况。其他数据输入域的情况依次类推。在单一数据输入域合法性测试完毕之后,可以进行组合测试。一般来说,单一合法性数据测试没有问题,组合出问题的可能性比较小。这里有一个问题,一个测试数据量比较大,比较好的解决方法有两个,一个是采用自动化测试工具,比如我们将字符型的数据输入域的需要测试的数据加以总结并放到一个电子报表里,你只要做好测试自动化脚本,并参数化相关输入域就可以完成相关输入域的测试,而且脚本的量并不是很大。另外一个方法是采用正交试验法。具体的方法和理论根据可以看《测评工程师教程》的相关内容,也可以减少测试用例的数据。保证测试质量。非法数据的构造的方法和合法数据的构造方法基本相同,这里就不多说了。基本上字符型输入可以有几十个检查点,日期型的可以有几百个测试检查点,浮点数和整形数的检查点也不会少,这样大致的统计下来写出几万,几十万的测试需求点不是很难的事情

原文转自:http://www.ltesting.net