黑盒测试顾名思义就是将被测系统看成一个黑盒,从外界取得输入,然后再输出。整个测试基于需求文档,看是否能满足需求文档中的所有要求。黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或经验,它适用于对系统的功能进行测试。
黑盒测试的优点有:
1)比较简单,不需要了解程序内部的代码及实现;
2)与软件的内部实现无关;
3)从用户角度出发,能很容易的知道用户会用到哪些功能,会遇到哪些问题;
4)基于软件开发文档,所以也能知道软件实现了文档中的哪些功能;
5)在做软件自动化测试时较为方便。
黑盒测试的缺点有:
1)不可能覆盖所有的代码,覆盖率较低,大概只能达到总代码量的30%;
2)自动化测试的复用性较低。
2. 白盒测试
白盒测试是指在测试时能够了解被测对象的结构,可以查阅被测代知腔纳码内容的测试工作。它需要知道程序内部的设计结构及具体的代码实现,并以此为基础来设计测试用例。
白盒测试的直接好处就是知道所设计的圆悔测试用例在代码级上哪些地方被忽略掉,它的优点是帮助软件测试人员增大代码的覆盖率,提高代码的质量,发现代码中隐藏的问题。
白盒测试的缺点有:
1)程序运行会有很多不同的路径,不可能测试所有的运行路径;
2)测试基于代码,只能测试开发人员做的对不对,而不能知道设计的正确与否,可 能会漏掉一些功能需求;
3)系统庞大时,测试开销会非常大。
3. 基于风险的测试
基于风险的测试是指评估测试的优先级,先做高优先级的测试,如果时间或精力不够,低优先级的测试可以暂时先不做。有如下一个图,横轴代表影响,竖轴代表概率,根据一个软件的特点来确定:如果一个功能出了问题,它对整个产品的影响有多大,这个功能出问题的概率有多大?如果出问题的概率很大,出了问题对整个产品的影响也很大,那么在测试时就一定要覆盖到。对于一个用户很少用到的功能,出问题的概率很小,就算出了问题的影响也不是很大,那么如果时间比较紧的话,就可以考虑不测试。
基于风险测试的两个决定因素就是:该功能出问题对用户的影响有多大,出问题的概率有多大。其它一些影响因素还有复杂性、可用性、依赖性、可修改性等。测试人员主要根据事情的轻重缓急来决定测试工作的重点。
4. 基于模型的测试
模型实际上就是用语言搭没把一个系统的行为描述出来,定义出它可能的各种状态,以及它们之间的转换关系,即状态转换图。模型是系统的抽象。基于模型的测试是利用模型来生成相应的测试用例,然后根据实际结果和原先预想的结果的差异来测试系统。
什么是测试需求?确切地讲,所谓的测试需求就是在项目中要测试什么。我们在测试活动中,首先需要明确测试需求(What),才能决定怎么测(How),测试时间(When),需要多少人(Who),测试的环境是什么蔽饥悔(Where),测试中需要的技能、工具以及相应的背景知识,测试中可能遇到的风险等等,以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
就像软件的需求一样,测试需求根据不同的公司环境,不同的专业水平,不同的要求,详细程度也是不同的。但是,对于一个全新的项目或者产品,测试需求力求详细明确,以避免测试遗漏与误解。
为什么要做测试需求?
如果要成功的做一个测试项目,首先必须了解测试规模、复杂程度与可能存在的风险,这些都需要通过详细的测试需求来了解。所谓知己知彼,百战不殆。测试需求不明确,只会造成获取的信息不正确,无法对所测软件有一个清晰全面的认识,测试计划就毫无根据可言。活在自己世界里的人是可悲的,只凭感觉不做详细了解就下定论的项目是失败的。
测试需求越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期,测试需求就相当于软件的需求规格,测试策略相当于软件的架构设计,测试用例相当于软件的详细宏正设计,测试执行相当于软件的编码过程。只是在测试过程中,我们把“软件”两个字全部替换成了“测试”。这样,我们就明白了整个测试活动的依据来源于测试需求。
测试需求的收集主要通过对测试依据进行分析整理,最后生成一个以测试的观点出发的checklist(检查表),用来作为测肢斗试该软件的主要工作内容。检查表的检查要点包括需求的正确性、必要性、优先级、明确性、可测性、完整性、一致性、可修改性:
在整个信息收集过程中,务必确保软件的功能与特性被正确理解。因此,测试需求分析人员必须具备优秀的沟通能力与表达能力。
以上主要描述了测试需求相关理论和获得测试需求树的一般过程。为具体项目实施测试中提供了一套获取测试需求树的参考方案。实际的测试类型划分和测试需求树生成的形式或粒度,因项目而不同,需灵活应用。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)