软件测试的定义及常用软件测试方法介绍Word文件下载.doc
《软件测试的定义及常用软件测试方法介绍Word文件下载.doc》由会员分享,可在线阅读,更多相关《软件测试的定义及常用软件测试方法介绍Word文件下载.doc(5页珍藏版)》请在冰豆网上搜索。
![软件测试的定义及常用软件测试方法介绍Word文件下载.doc](https://file1.bdocx.com/fileroot1/2022-10/9/365eccf6-44ca-4007-9272-fae821db6e9f/365eccf6-44ca-4007-9272-fae821db6e9f1.gif)
即保证软件做了你所期望的事情。
(Dotherightthing)
1.静态确认,不在计算机上实际执行程序,通过人工或程序分析来证明软件的正确性
2.动态确认,通过执行程序做分析,测试程序的动态行为,以证实软件是否存在问题。
软件测试的对象不仅仅是程序测试,软件测试应该包括整个软件开发期间各个阶段所产生的文档,如需求规格说明、概要设计文档、详细设计文档,当然软件测试的主要对象还是源程序。
二、软件测试常用方法
1.从是否关心软件内部结构和具体实现的角度划分:
a.黑盒测试
黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。
在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。
黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度,从输入数据和输出数据的对应关系出发进行测试的,很明显,如果本身设计有问题或者说明规格有错误,用黑盒测试是发现不了的。
黑盒测试法注重于测试软件的功能需求,主要试图发现下列几类错误。
功能不正确或遗漏;
界面错误;
输入和输出错误;
数据库访问错误;
性能错误;
初始化和终止错误等。
从理论上讲,黑盒测试只有采用穷举输入测试,把所有可能的输入都作为测试情况考虑,才能查出程序中所有的错误。
实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但可能的输入进行测试。
这样看来,完全测试是不可能的,所以我们要进行有针对性的测试,通过制定测试案例指导测试的实施,保证软件测试有组织、按步骤,以及有计划地进行。
黑盒测试行为必须能够加以量化,才能真正保证软件质量,而测试用例就是将测试行为具体量化的方法之一。
具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。
b.白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构测试程序,通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子,测试人员依据程序内部逻辑结构相关信息,设计或选择测试用例,对程序所有逻辑路径进行测试,通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。
白盒测试的实施步骤:
1.测试计划阶段:
根据需求说明书,制定测试进度。
2.测试设计阶段:
依据程序设计说明书,按照一定规范化的方法进行软件结构划分和设计测试用例。
3.测试执行阶段:
输入测试用例,得到测试结果。
4.测试总结阶段:
对比测试的结果和代码的预期结果,分析错误原因,找到并解决错误。
白盒测试的优点:
迫使测试人员去仔细思考软件的实现;
·
可以检测代码中的每条分支和路径;
揭示隐藏在代码中的错误;
对代码的测试比较彻底;
·
最优化;
白盒测试的缺点:
无法检测代码中遗漏的路径和数据敏感性错误;
不验证规格的正确性;
c.灰盒测试
灰盒测试,是介于白盒测试与黑盒测试之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。
2.从软件开发的过程按阶段划分有
a.单元测试
单元测试(unittesting),是指对软件中的最小可测试单元进行检查和验证。
对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,Java里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。
总的来说,单元就是人为规定的最小的被测功能模块。
单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
b.集成测试
集成测试,也叫组装测试或联合测试。
在单元测试的基础上,将所有模块按照设计要求(如根据结构图〕组装成为子系统或系统,进行集成测试。
实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。
程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。
c.确认测试
确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。
经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是确认测试的任务,即软件的功能和性能如同用户所合理期待的那样。
确认测试又称有效性测试。
有效性测试是在模拟的环境下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。
任务是验证软件的功能和性能及其他特性是否与用户的要求一致。
对软件的功能和性能要求在软件需求规格说明书中已经明确规定,它包含的信息就是软件确认测试的基础。
d.系统测试
系统测试,英文是SystemTesting。
是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起,进行信息系统的各种组装测试和确认测试,系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾的地方,从而提出更加完善的方案。
系统测试发现问题之后要经过调试找出错误原因和位置,然后进行改正。
是基于系统整体需求说明书的黑盒类测试,应覆盖系统所有联合的部件。
对象不仅仅包括需测试的软件,还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。
系统测试的步骤:
【Step1】制定系统测试计划
系统测试小组各成员共同协商测试计划。
测试组长按照指定的模板起草《系统测试计划》。
该计划主要包括:
测试范围(内容)
测试方法
测试环境与辅助工具
测试完成准则
人员与任务表
项目经理审批《系统测试计划》。
该计划被批准后,转向【Step2】。
【Step2】设计系统测试用例
系统测试小组各成员依据《系统测试计划》和指定的模板,设计(撰写)《系统测试用例》。
测试组长邀请开发人员和同行专家,对《系统测试用例》进行技术评审。
该测试用例通过技术评审后,转向【Step3】。
【Step3】执行系统测试
系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。
将测试结果记录在《系统测试报告》中,用“缺陷管理工具”来管理所发现的缺陷,并及时通报给开发人员。
【Step4】缺陷管理与改错
从【Step1】至【Step3】,任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工具”。
该工具将记录所有缺陷的状态信息,并可以自动产生《缺陷管理报告》。
开发人员及时消除已经发现的缺陷。
开发人员消除缺陷之后应当马上进行回归测试,以确保不会引入新的缺陷。
e.验收测试
验收测试,系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。
它让系统用户决定是否接收系统。
它是一项确定产品是否能够满足合同或用户所规定需求的测试。
这是管理性和防御性控制。
至此软件测试的定义及常用方法已经介绍完毕了,但软件测试远远不只这么简单,上面列出的只是一些基本的概念,只有自己深入的去学习才能学的更多,走的更远。
完结