软件测试的15个分类

 


软件测试的15个分类

 

能力测试:

 最明显的系统测试类型是判断目标文档提及的每一项能力(或能力,为了避免与功能测试发生混淆而不使用”功能” 一词) 是否都满足确实已经实现, 能力测试的过程是逐条语句地检查目标文档
当某条语句定义了一个  “要做什么” 就判断程序是否满足 。此类型的测试常常可以在不使用计算机的情况下进行,有时人工对目标和用户文档进行比较就足够了
系统测试 :
系统测试是将集成好的软件系统,作为整个基于计算机系统的一个元素,与计算机硬件,外设,支持软件,数据等其他系统元素结合在一起在实际运行(使用)环境下所进行的一系列测试活动
容量测试:
第二类系统测试是使程序经受大容量数据的检验  举例来说 编译器可能要编译规模非常庞大的源程序 连接编辑器可能需要处理一个包含上千
模块的程序
电子电路模拟可能要输入一个包含上千部件的电路   而操作系统的作业队列可能已经到达饱和 的容量  如果程序需要处理跨越不同卷的文件
则应产生足够的数据是程序从一个卷转换到另一个中    换一种说法  容量测试的目的是为了证明程序不能处理目标文档中规定的数据容量
由于容量测试显然需要大量的资源  鉴于对机器和工时的考虑 不可进行过多的容量测试  当然 每个程序应该至少进行几次容量测试
强度测试:
强度测试使程序承受高负载或强度的检验。 这不应和容量测试发生混淆 所谓的高强度是在很短的时间间隔内达到的数据或操作的数量峰值
类似的情况是 测试一名打字员   容量测试是判断打字员能否处理大篇幅的稿子 而强度测试则是判断打字员能否到达每分钟50个单词的速度
由于强度 测试涉及时间因素 因此 它不适用于很多程序  如编译器或批处理工资程序 然而 强度测试适用于在可变负载下运行的程序以及交互
程序 实时程序和过程控制程序
基于Web的应用程序是最常接受强度测试的软件之一   在这里 我们需要确信的是应用程序及硬件能够处理一定容量的并发用户
可用性测试:
另一种重要的测试就是可用性测试 又叫用户体验测试   从用户使用角度考虑 在使用过程中的细节体验
安全测试:
       安全测试是设计测试用例来突破程序安全检查的过程  举例来说  我们可以设计测试用例来规避操作系统的内存保护机制 破坏数据库管理系统的数据安全机制   设计此种测试用例的方法之一
是研究类似系统  中已知的安全问题  然后生成测试用例  尽量暴露被测系统存在相似问题 例如 在杂志  聊天室和新闻中发布的资料  经常包含有操作系统胡其他软件系统已知错误   通过在与被测软件
提供相似服务的现有系统中搜寻安全漏洞  可以设计测试用例来判断软件是否类似问题的困扰
基于Web的应用程序常常比绝大多数程序所需的安全测试级别更高 对于电子商务网站尤其如此  经管已经有了足够多的技术(列如密码学)  允许客户 网络上安全地完成交易 但不能单纯依赖技术
的应用确保安全  
性能测试 :
很多软件都有特定性能或效率目标  这些特性描述为在特定负载和配置环境下 程序的响应时间 和吞吐率 再一次强调 由于系统测试的目的是为了证明程序不能实现其目标  因此应设计测试用例
测试用例来说明程序不能满足其性能目标
存储测试:
软件偶尔会有存储目标 举例来说,可能描述了程序使用的内存和辅存的容量,以及临时文件或溢出文件的大小,应设计测试用例来证明这些容量目标没有得到满足
配置测试:
诸如操作系统 数据库管理系统和信息交换系统等软件都支持多中硬件配置,包括不同类型和数量I/O设备和通信线路  ,或不同的存储配置,通常可能的配置数量非常庞大。
以至于测试无法 面面俱到,但是至少应该使用每一种类型的设备,以最大和最小的配置来测试程序。但是软件本身的配置可忽略掉某些程序组件,或可运行在不同的计算机上,那么该软件所有的
可能的配置都应测试到
兼容测试:
大多数的开发软件都并不是全新的,常常是为了替换某些不完善的系统,这样的软件往往有着特定的目标  涉及与现有系统的兼容以及从现有系统的转换过程,再次强调 在针对这些目标
测试程序时,测试用例的目的是证明兼容性目标未被满足,转换过程并为生效,在将数据从一个系统转移到另一个系统时,应尽力发现错误,升级数据库管理系统就是一个例子。 需要确定现有
的数据安置到了新的系统中 ,有很多不同的方法测试这个过程,但这些方法都高度依赖于所使用的数据库系统
安装测试:
有些类型的软件系统安装过程非常复杂,测试安装过程是系统测试中的一个重要部分,对于包含在软件包中的自动安装系统而言,这尤其重要 ,安装程序如果出现故障,会影响用户
对软件的成功体验,用户的第一次体验来来自于安装软件的过程,如果这个过程进程很糟糕,用户或顾客就要么寻找其他的产品,那么对软件的有效性不抱太大信心,
可靠性测试:
所有类型的测试都是为了提高软件的可靠性 , 但是如果软件的目标中包含了可靠性的特别描述,就必须设计专门的可靠性,测试可靠性目标可能很困难。举例来说,诸如公司的局域网
在线系统在整个系统运行期间,正常运行时间应占99.97%. 我们现在还不太可能花上数月甚至数年的时间来测试这个目标。今天的关键软件系统的可靠性标准甚至更高高。而现今的硬件可以令人信服
地保障这个目标的实现。但如果软件或合理的功能错误目标,就有可能对其进行测试
可恢复性测试:
诸如操作系统,数据库管理系统和远程处理系统等软件通常都有可恢复性目标,说明系统如何从程序错误,硬件失效和数据错误中恢复过来,系统测试的一个目标是证明这些恢复机制
不能够正确发挥作用,我们可以故意将程序错误置入某个系统中,判断系统是否可以从中恢复,诸如内存校验错误或I/O设备错误等硬件错误页可以进行模拟。而如通信线路中的噪音。或数据库中的
无效指针等数据错误可以故意生成或模拟出来,以分析系统的反应
这些系统的设计目标之一是使平均恢复时间最小,系统宕机往往会减少公司的收入,我们的一个测试目标是证明系统不能满足MTTR的服务合同。MTTR往往有上界和下界,所以测试用例应反应
出这些界限
可维护性测试:
软件还有可能有服务和维护性的目标, 所有的此类目标都必须测试到,这些目标可能定义了系统提供的服务辅助功能 ,包括存储转存程序或诊断程序,调试明显问题的平均 响应时间
维护过程以及内部业务文档的质量等
文档测试:
系统测试也需要检查用户文档的正确性,完成此任务的主要方法是根据文档来确定系统测试用例的形式。 也就是说,一旦设计完成某个具体的测试情况,应该使用文档来作为编写实际
测试用例的指南。同时,用户文档应成为审查的对象。检查其正确性和清晰性。在文档中描述的任何范例 应编成测试用例。 并提交给程序
系统测试的执行:
系统测试执行中一个关键的考虑是决定由谁来执行进行测试,我们从反面来回答这个问题
1、不能让程序员来进行系统测试
2、在所有的测试阶段之中,这是唯一一个明确地不能由谁来负责,程序开发的机构来执行的测试
第一点基于的事实是,执行测试的人思考问题的方式,必须与最终用户相同,这意味着必须充分了解最终用户的态度 和应用环境 ,以及程序的使用方式
第二点基于的事实是,系统测试是一项“随心所欲,百无禁忌” 的活动 而软件开发机构会受到心里束缚, 有勃于此项活动 而且大多数的开发机构最为关心的是让系统测试进行得尽可能顺利
并按时完成,而不会尽力证明程序不能满足其目标,系统测试至少应由很少,受开发机构左右的独立人群来执行
验收测试:
验收测试订购方(用户)来进行验收测试,将程序的实际操作与原始合同进行对照 如同其他类型的测试,验收测试最好的方法是设计测试用例,尽力证明程序满足合同要求