浅谈测试用例分析和设计
http://www.51testing.com/html/30/n-234230-2.html51Testing软件测试网uw+H7W$RY
51Testing软件测试网LU,zUg
测试用例的重要性是毋庸置疑的,它是软件测试全部过程的核心,是测试执行环节的基本依据。下面我们来浅谈下测试用例的分析和设计过程。
5`!IR,I6gpu051Testing软件测试网J@OUEhhj
一、测试用例分析阶段
(e)QO9uBc051Testing软件测试网0A^2Br$]g!O8c%_#[
测试用例设计的基础文档是需求文档,如果测试人员能拿到一份完整的准确的需求文档,那么对测试人员来说,工作量可以减轻大半,工作效果会大幅提高。但是我们在需求分析阶段,即便是在需求评审之后,我们拿到的需求文档,仍然是存在一些疑义的或者是分析不透,表达不清的一些需求文档。这样的时候,测试人员是否有自己的分析方法,显得尤为重要。
*V?t`)w1]N?S0
gz#iQ$Fz"x9iL0测试人员对付需求文档,从操作策略上来说,可以从以下两点出发:
*af\,pp3C051Testing软件测试网)io;|kNjs-L@
(一)、对于需求规格全面、完整的需求文档来说,我们可以采取“切割策略”,把需求按一定的粒度进行分解,来编写测试用例。
s|IC/B,R}S0
[4V/L&i^9{y'|0(二)、对于简单不全面、需求规格含糊的需求文档,我们可以采取的策略:“联想策略”。这点还是主要来自工作经验及对该行业的理解,把一些含糊的内容补充起来。
wuA't4v&[1lZ051Testing软件测试网1I%M8Lu;X Ph
在参与需求文档阅读的过程中,我们还可以采用一些小方法,把需求吃透。例如:51Testing软件测试网8GbF#M!p%uD
A3G.C h3xL'P01、在参与需求阅读的过程中,我们可以把需求中的一些边界或者异常的情况列出来,这些往往是以后bug的多发地带。
3RM"|&CW {],w-GT*O051Testing软件测试网X8tk sM
2、对于需求文档中的一些隐式缺陷,我们需要补充清楚质量属性,例如一些安全性、性能、UI等的一些质量属性内容,我们需要补充清楚。51Testing软件测试网 vBjh \!Qw o S
%BqE n]^'mh03、对需求文档的阅读,我们还可以采用一些工具:思维导图工具及UI界面设计工具,把图给画出来,有助于我们理解需求,找到测试点。例如思维导图工具,通过名词+动词的方法,可以把测试数据和操作动作列出来,有利于理清测试的要点。
!u6w3rm9B%v"X4T5s0
HJn @_4G Z|M0通过以上的一些策略和方法,我们大致上可以把需求测试分析做的比较到位了。
cR-i'\} jJn051Testing软件测试网X/C VY7D;k
测试人员对需求文档分析后,接下去还需要对设计文档进行分析,大部分的测试人员,不是太注重开发组的这份设计文档,觉得与己无关,其实,理解设计文档,有利于降低我们的测试规模,降低劳动负荷。一般来说缺陷会与内部结构映射,如果你了解了代码的结构,一般来说,我们都可以找到缺陷出现的真正原因了。这里有一种工具,可以帮助我们进行这方面的工作,就是UML的反向工程获得设计模型,该工具网上大家也可以找到。51Testing软件测试网X-K'SdI7v
"U+n(F g7p0二、测试用例设计阶段51Testing软件测试网'Y ho0y`rL
5NYU2[2O u&jN0通过以上对需求文档和设计文档的分析,下面我们来浅谈下测试用例的设计,测试用例一般由三部分内容组成:步骤、数据、标准。步骤一般与需求规格说明书相对应,对于某些共享步骤,可以进行参数化,或借用工具进行管理,步骤的描述应该无二义性。测试标准,主要为预期值与结果值的对比方式。51Testing软件测试网 d7e |PKuI
O|`:lv6av0对于测试数据的设计,这里我们讲解以下几种方法:51Testing软件测试网5GBCQ4?
dSr9F b&JF01、最原始的方法:排列组合。通过排列组合,把所有的数据都遍历过,这样的穷举的方法,尽可能的把系统都测试到位。但数据庞大,这样穷举的方法,会让测试陷入困境。51Testing软件测试网1ZKcu*JNJM
@9f&H
51Testing软件测试网LU,zUg
测试用例的重要性是毋庸置疑的,它是软件测试全部过程的核心,是测试执行环节的基本依据。下面我们来浅谈下测试用例的分析和设计过程。
5`!IR,I6gpu051Testing软件测试网J@OUEhhj
一、测试用例分析阶段
(e)QO9uBc051Testing软件测试网0A^2Br$]g!O8c%_#[
测试用例设计的基础文档是需求文档,如果测试人员能拿到一份完整的准确的需求文档,那么对测试人员来说,工作量可以减轻大半,工作效果会大幅提高。但是我们在需求分析阶段,即便是在需求评审之后,我们拿到的需求文档,仍然是存在一些疑义的或者是分析不透,表达不清的一些需求文档。这样的时候,测试人员是否有自己的分析方法,显得尤为重要。
*V?t`)w1]N?S0
gz#iQ$Fz"x9iL0测试人员对付需求文档,从操作策略上来说,可以从以下两点出发:
*af\,pp3C051Testing软件测试网)io;|kNjs-L@
(一)、对于需求规格全面、完整的需求文档来说,我们可以采取“切割策略”,把需求按一定的粒度进行分解,来编写测试用例。
s|IC/B,R}S0
[4V/L&i^9{y'|0(二)、对于简单不全面、需求规格含糊的需求文档,我们可以采取的策略:“联想策略”。这点还是主要来自工作经验及对该行业的理解,把一些含糊的内容补充起来。
wuA't4v&[1lZ051Testing软件测试网1I%M8Lu;X Ph
在参与需求文档阅读的过程中,我们还可以采用一些小方法,把需求吃透。例如:51Testing软件测试网8GbF#M!p%uD
A3G.C h3xL'P01、在参与需求阅读的过程中,我们可以把需求中的一些边界或者异常的情况列出来,这些往往是以后bug的多发地带。
3RM"|&CW {],w-GT*O051Testing软件测试网X8tk sM
2、对于需求文档中的一些隐式缺陷,我们需要补充清楚质量属性,例如一些安全性、性能、UI等的一些质量属性内容,我们需要补充清楚。51Testing软件测试网 vBjh \!Qw o S
%BqE n]^'mh03、对需求文档的阅读,我们还可以采用一些工具:思维导图工具及UI界面设计工具,把图给画出来,有助于我们理解需求,找到测试点。例如思维导图工具,通过名词+动词的方法,可以把测试数据和操作动作列出来,有利于理清测试的要点。
!u6w3rm9B%v"X4T5s0
HJn @_4G Z|M0通过以上的一些策略和方法,我们大致上可以把需求测试分析做的比较到位了。
cR-i'\} jJn051Testing软件测试网X/C VY7D;k
测试人员对需求文档分析后,接下去还需要对设计文档进行分析,大部分的测试人员,不是太注重开发组的这份设计文档,觉得与己无关,其实,理解设计文档,有利于降低我们的测试规模,降低劳动负荷。一般来说缺陷会与内部结构映射,如果你了解了代码的结构,一般来说,我们都可以找到缺陷出现的真正原因了。这里有一种工具,可以帮助我们进行这方面的工作,就是UML的反向工程获得设计模型,该工具网上大家也可以找到。51Testing软件测试网X-K'SdI7v
"U+n(F g7p0二、测试用例设计阶段51Testing软件测试网'Y ho0y`rL
5NYU2[2O u&jN0通过以上对需求文档和设计文档的分析,下面我们来浅谈下测试用例的设计,测试用例一般由三部分内容组成:步骤、数据、标准。步骤一般与需求规格说明书相对应,对于某些共享步骤,可以进行参数化,或借用工具进行管理,步骤的描述应该无二义性。测试标准,主要为预期值与结果值的对比方式。51Testing软件测试网 d7e |PKuI
O|`:lv6av0对于测试数据的设计,这里我们讲解以下几种方法:51Testing软件测试网5GBCQ4?
dSr9F b&JF01、最原始的方法:排列组合。通过排列组合,把所有的数据都遍历过,这样的穷举的方法,尽可能的把系统都测试到位。但数据庞大,这样穷举的方法,会让测试陷入困境。51Testing软件测试网1ZKcu*JNJM
@9f&H