软件测试笔记Word格式.docx
- 文档编号:20934599
- 上传时间:2023-01-26
- 格式:DOCX
- 页数:53
- 大小:112.12KB
软件测试笔记Word格式.docx
《软件测试笔记Word格式.docx》由会员分享,可在线阅读,更多相关《软件测试笔记Word格式.docx(53页珍藏版)》请在冰豆网上搜索。
●系统软件能直接操作底层硬件,并为上层软件提供支持
●中间件在应用软件和平台之间建立一种桥梁,常见的中间件包括数据库和万维网服务器
●应用软件能为用户提供某种特定的应用服务
2)按技术架构分类(单机版软件、C/S架构的软件、B/S架构的软件)
●单机版软件直接安装并运行在单个计算机上,如office、ACDSee等
●C/S架构的软件基于互联网或局域网,需要一台服务器来安装服务器端软件,每台客户端都要安装客户端软件,如QQ、MSN等
●B/S架构的软件:
B/S架构的软件也是基于互联网或局域网,但这类软件不需要安装客户端软件,只需要浏览器软件即可
3)按用户分类(产品软件和项目软件)
4)按开发规模分类(小型软件、中型软件和大型软件)
1.2.4软件测试定
软件测试指使用人工河自动手段来运行或测试某个系统的过程,目的在于检验其是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。
1.3软件缺陷
1.3.1软件缺陷的定义
只有符合以下五条规则才能叫软件缺陷
●软件未达到需求规格说明书中指明的功能
●软件出现了需求规格说明书中指明不会出现的错误
●软件功能超出需求规格说明书中指明的范围
●软件未达到需求规格说明书中虽未指出但应达到的目标
●软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好
1.4测试用例
1.4.1测试用例的定义
定义:
指执行条件和预期结果的集合,完整来讲是针对要测试的内容所确定的一组输入信息,是为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据。
测试用例可以用一个简单的公式表示:
测试用例=输入+输出+测试环境
输入:
指测试数据和操作步骤
输出:
指系统的预期执行结果
测试环境:
指系统环境设置,包括软件环境、硬件环境和数据,有时还包括网络环境
1.4.2测试用例的重要性
测试用例的重要性体现在技术和管理两个层面
1、就技术而言,测试用例有利于以下方面:
指导测试的实施
规划测试数据的准备
编写测试脚本的“设计规格说明书”
降低工作强度
2、就管理层面而言,使用测试用例的好处有以下几个方面
团队交流
重复测试
检验测试员进度
质量评估
分析缺陷的标准
1.4.3测试用例的评价标准
有效性、经济性、可仿效性、可修改性、独立性、可跟踪性
1.4.4测试用例设计的基本原则
1、测试用例的代表性
能够代表并覆盖各种合理的和不合理的,合法的和非法的,边界的和越界的以及极限的输入数据、操作和环境设置等
2、测试结果的可判定性
即测试执行结果的正确性是可判定的,每一个测试用例都应有相应明确的预期结果,而不应存在二义性,否则将难以判断系统是否运行正常
3、测试结果的可再现性
即对同样的测试用例,系统的执行结果应当相同
1.4.5测试用例的输入通常考虑三方面的数据
1、正常数据
2、边界数据
3、错误数据
1.4.6测试用例设计的注意事项
1.测试用例应尽早设计
2.测试用例由专门的人来设计
3.测试用例的功能描述要与软件需求规格说明书保持一致
4.测试用例的设计并非一劳永逸
5.在不知道预期结果的情况下,应推迟用例设计
6.在设计测试用例过程中注意与其他人员的沟通
7.测试用例在不同阶段下实施时应该是独立的
8.整个测试用例设计顺序逻辑性要强,以便于测试人员执行用例
9.测试用例应该满足自清除性
10.测试用例本身无法保证覆盖要求
11.每个测试用例应有一个唯一的标识
1.4.7测试需求
1、定义:
测试需求是指在一定的策略前提下,对应于验证某个系统的业务需求或功能需求的测试需求
注意:
软件需求与测试需求的不同在于:
软件需求在于用于指导后续设计的开展,而测试需求则是直接源于客户的质量需求
2、测试需求应包含两方面的内容:
A、确定测试什么,就是需求测试的内容
B、测试对软件产品的需求,解决需要产品为测试提供什么特性,可以更好的去测试的问题,就是我们通常所说的可测试性需求
3、测试需求的分类与分析
对应不同的测试目的,可将测试需求分为两类:
A、验证业务过程的流程类测试需求
B、验证功能点的功能性测试需求
1.5测试环境
测试环境就是软件运行的平台,即进行软件测试所必须的工作平台和前提条件
公式表示:
测试环境=硬件+软件+网络+历史数据
硬件:
指进行测试所必须的服务器、客户端、网络连接设备,以及打印机、扫描仪等辅助硬件设备所构成的环境
软件:
指被测软件运行时的操作系统,数据库及其它应用软件等构成的环境
网络:
主要针对C/S、B/S架构的软件
历史数据:
是指测试用例执行所需初始化的各项数据
2、测试环境的重要性
加快测试速度
准确重现缺陷
提高工作效率和软件质量
3、良好测试环境的要素
良好的测试模型
多样化的系统配置
熟练使用工具的测试员
第二章软件测试原理
2.1测试原则
2.1.1软件测试应追溯到用户需求
软件开发的最终目的是要满足最终用户的需求,测试员应始终站在用户的角度去看问题,系统中最严重的缺陷是那些导致程序无法满足用户需求的缺陷。
用户是软件最终使用者,同时往往也是软件的投资者。
因此,不满足用户需求的软件是无法顺利交付和收回成本的。
2.1.2应尽早和不间断地测试
2.1.3对待缺陷的基本原则
1、缺陷的群集现象
2、缺陷有免疫力
3、缺陷关联和依赖
2.1.4测试结果的处理原则
1、对缺陷进行复查和确认
2、测试结果的全面检查
3、出错统计和分析
4、妥善保存测试过程文档
2.2软件测试的分类
2.2.1按是否需查看代码分类
1、黑盒测试(black-boxtesting)
黑盒测试是将被测试软件看作一个黑盒子,只考虑系统的输入和输出,完全不考虑程序内部逻辑结构和处理过程
黑盒测试的依据是各个阶段的需求规格说明
黑盒测试又称功能性测试(functionaltesting)或数据驱动测试(data-driventesting)
2、白盒测试(white-boxtesting)
白盒测试是将黑盒子打开,研究源代码和程序内部的逻辑结构
白盒测试的依据是程序源代码
白盒测试又称结构性测试(structuraltesting)或逻辑驱动测试(logic-driventesting)
白盒测试
白盒测试的定义
白盒测试(White-boxTesting,又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的盒子。
利用白盒测试法进行动态测试时,需要测试软件产品的内部结构和处理过程,不需测试软件产品的功能。
白盒测试的目的
通过检查软件内部的逻辑结构,对软件中的逻辑路径进行覆盖测试;
在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。
白盒测试的实施步骤
1.测试计划阶段:
根据需求说明书,制定测试进度。
2.测试设计阶段:
依据程序设计说明书,按照一定规范化的方法进行软件结构划分和设计测试用例。
3.测试执行阶段:
输入测试用例,得到测试结果。
4.测试总结阶段:
对比测试的结果和代码的预期结果,分析错误原因,找到并解决错误。
白盒测试的优缺点
1.优点
●迫使测试人员去仔细思考软件的实现
●可以检测代码中的每条分支和路径
●揭示隐藏在代码中的错误
●对代码的测试比较彻底
●代码优化
2.缺点
●昂贵(成本高)
●无法检测代码中遗漏的路径和数据敏感性错误
●不验证规格的正确性
●无法检验程序的外部特征
白盒测试法的循环覆盖
1)简单循环
依据边界值测试
2)嵌套循环
1)最内层循环开始,见那个其他循环设为最小值
2)对最内层使用简单循环
3)由内到外
4)继续,直到测试到所有循环
3)串接循环
1)彼此独立,对每个循环进行简单循环测试
2)注意第一个循环是第二个循环的初始值,则使用检讨循环
白盒测试法的逻辑覆盖
白盒测试法的辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、修正判定条件覆盖和件组合覆盖
六种覆盖标准:
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、修正判定条件覆盖和件组合覆盖发现错误的能力呈由弱至强的变化。
语句覆盖每条语句至少执行一次。
判定覆盖每个判定的每个分支至少执行一次。
条件覆盖每个判定的每个条件应取到各种可能的值。
判定/条件覆盖同时满足判定覆盖条件覆盖。
条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
路径覆盖使程序中每一条可能的路径至少执行一次。
语句覆盖为了暴露程序中的错误,程序中的每条语句至少应该执行一次。
因此语句覆盖(StatementCoverage)的含义是:
选择足够多的测试数据,使被测程序中每条语句至少执行一次。
语句覆盖是很弱的逻辑覆盖。
判定覆盖比语句覆盖稍强的覆盖标准是判定覆盖(DecisionCoverage)。
判定覆盖的含义是:
它要求设计足够多的测试用例,使得程序中每个判定至少有一次为真值,有一次为假值,或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次,因此判定覆盖又称为分支覆盖。
条件覆盖在设计程序中,一个判定语句是由多个条件组合而成的复合判定。
为了更彻底地实现逻辑覆盖,可以采用条件覆盖(ConditionCoverage)的标准。
条件覆盖的含义是条件覆盖要求设计足够多的测试用例,使得判定中的每个条件获得各种可能的结果,即每个条件至少有一次为真值,有一次为假值。
判定/条件覆盖:
设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身所有可能结果也至少出现一次。
修正判定条件覆盖这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。
它要求满足三个条件:
1、判定(即由条件和零或者多个布尔操作符号组成的布尔表达式)中的每一个条件(即含有布尔操作符号组成的布尔表达式)的所有可能结果至少出现一次
2、每一个判定本身的所有结果也至少出现一次
3、每一个入口与出口点至少被唤醒一次,且每一个条件都能单独的影响判定的结果(即在其他条件不变的情况下改变这个条件的值,使得判定结果改变)
条件组合覆盖,它的含义是:
设计足够的测试用例,使得每个判定中条件的各种可能组合都至少出现一次。
显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
静态白盒测试
静态测试并不实际运行被测软件,而是直接分析软件的形式和结构,查找缺陷,主要包括对源代码,程序界面,各类文档及中间产品(如产品规格说明书、技术设计文档等)所做的测试,
静态白盒测试的主要内容
包括:
代码检查、静态结构分析、代码质量度量、函数执行性能测试、动态内存分析
1、代码检查
代码检查是静态测试的主要方法,它包括桌面检查、代码走查、代码审查和技术评审等。
1)桌面检查
桌面检查是程序员对源程序代码进行分析、检验,并补充相关的文档,发现程序中的错误的过程。
由于程序员熟悉自己的程序,可以由程序员自己检查,这样可以节省很多时间,但要注意避免自己的主观判断。
2)代码走查
代码走查是以小组为单位进行代码阅读、讨论和模拟运行,是一系列规程和缺陷检查技术的集合,代码走查是不正式的测试
走查可分为以下两个步骤:
①小组负责人把材料发给每个组员,然后由小组成员提出发现的问题。
②通过记录,小组成员对程序逻辑及功能提出自己的疑问,开会探讨发现的问题和解决方法。
3)代码审查
代码审查是程序员和测试员组成的审查小组通过阅读、讨论、分析技术对程序进行静态分析的过程。
与代码走查不同的是,代码审查一般有正式的计划、流程和结果报告。
代码审查可分为以下两个步骤:
①小组负责人把程序文本、规范、相关要求、流程图及设计说明书发给每个成员。
②每个成员将所发材料作为审查依据,但是由程序员讲解程序的结构、逻辑和源程序。
在此过程中,小组成员可以提出自己的疑问;
程序员在讲解自己的程序时,也能发现自己原来没有注意到的问题。
为了提高效率,小组在审查会议前,可以准备一份常见错误清单,提供给参加成员对照检查。
4)技术评审
技术评审是由开发组、测试组和相关人员联合进行的,采用讲解、提问并使用编码模板来查找程序中的缺陷的过程
缺陷检查表
代码检查过程中一份重要的材料就是缺陷检查表,从某种意义上说,缺陷检查表可以看成是某种特殊形式的测试用例,在查看代码时,可以通过对比缺陷检查表来找出程序中的缺陷。
缺陷检查表一般包括容易出错的地方,以及以往工作中遇到的典型错误。
值得注意的是缺陷检查表不应太注重编程风格,且缺陷描述不能太模糊。
2、静态结构分析
静态结构分析主要是以图形的方式表现程序的内部结构,例如函数调用关系图、函数内部控制流图。
静态结构分析是测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构,生成函数调用关系图、模块控制流图等各种图形图表,清晰地标识整个软件的组成结构,便于理解,通过分析这些图表(包括控制流分析、数据流分析、接口分析、表达式分析),检查软件是否存在缺陷或错误。
●函数调用关系图
通过被测软件系统中各函数之间的调用关系展现系统的结构,函数调用关系图查看的重点如下:
1)检查函数的调用关系是否符合要求。
2)是否存在孤立的函数。
3)是否存在递归调用
3)函数调用层次是否太深
●模块控制流图
模块控制流图是节点和边组成的有向图,图中节点表示一条或多条语句,边代表节点之间的控制流向,或语句的执行。
模块控制流图可以直观的反映函数的内部逻辑结构,展示程序中明显的缺陷和潜在缺陷的风险。
模块控制流图查看的重点:
1)是否存在多入口或多出口
2)是否存在孤立的语句
3)模块的环复杂度是否太大
4)最长、最短路径的差别是否太大
白盒测试工具采用的基本符号:
串行语句
逻辑判断语句(开始)
逻辑判断语句(结束)
环形复杂度
又叫做圈复杂度,是定量程序逻辑复杂程度
V(G)=E-N+2(E是边数、N是节点数)
V(G)=P+1(P是判定节点的数量)
2.2.2按是否需要执行被测软件分类
1、静态测试
静态测试又称静态分析,是不实际运行被测软件,而是直接分析软件的形式和结构,查找缺陷。
主要包括对源代码、程序界面和各类文档及中间产品(如产品规格说明书、技术设计文档等)所做的测试。
∙对于源代码,静态测试主要是看代码是否符合相应的标准和规范
∙对于程序界面,静态测试主要是查看软件的实际操作和运行界面是否符合需求中的相关说明
∙对于文档,静态测试主要是检查用户手册与需求说明是否真正符合用户的实际要求
∙静态测试的方法:
走查、同行评审、会审
2、动态测试
动态测试又称为动态分析,是指需要实际运行被测软件,通过观察程序运行时表现出来的状态、行为等发现软件缺陷,包括在程序运行时,通过有效的测试用例(对应的输入、输出关系)来分析被测程序的运行情况或进行跟踪对比,发现程序所表现的行为与设计规格或客户需求不一致的地方。
动态从测试的局限性:
●往往需要借助测试用例来完成
●需要搭建软件特定的运行环境,增加了有关测试环境的配置、维护和管理的工作量
●不能发现文档问题
静态测试与动态测试的比较
测试方法
是否需要运行环境
是否需要测试用例
可否直接定位缺陷
测试实现难以程度
静态测试
否
可以
容易
动态测试
是
困难
2.2.3按测试阶段分类
按照测试阶段划分软件测试可分为:
单元测试、集成测试、系统测试、确认测试和验收测试。
1、单元测试
一、单元测试定义
1、单元测试又称模块测试,是指对软件中的最小可测试单元或基本组成单元进行检查和验证,目的是检查每个单元是否能够正确实现详细设计规格说明中的功能、性能、接口和设计约束等要求,发现各个模块内部可能存在的各种缺陷。
2、主要依据:
程序代码和详细设计文档
3、由开发人员负责单元测试工作
4、单元选取的原则
●对于C语言这类面向过程的开发语言来说,单元常指一个函数或子过程
●对于C++、java等面向对象的开发语言来说,单元一般指一个类
●图形化软件中,单元常指一个窗口或一个菜单
二、单元测试内容及目标
单元测试目标:
确保各单元模块被正确的编码,这里的正确不仅指代码功能正确,还指代码的结构正确、可靠,在所有条件下可以正确响应。
单元测试内容包括:
1模块接口测试;
2模块局部数据结构测试;
3模块边界条件测试;
4模块中所有独立执行通路测试;
5模块的各条错误处理通路测试。
1.模块接口测试是单元测试的基础。
只有在数据能正确输入、输出模块的前提下,其他测试才有意义。
测试接口正确与否应该考虑下列因素:
1输入的实际参数与形式参数的个数、属性、量纲和顺序上是否匹配;
2被测模块调用其他模块时传递的实参的个数、属性、量纲和顺序与被调模块的形参是否匹配;
3调用标准函数时所用参数的个数、属性和次序是否正确;
4是否存在与当前入口点无关的参数引用;
5是否修改了只读型参数;
6对全程变量的定义各模块是否一致;
7是否把某些约束作为参数传递。
2.模块局部数据结构测试
局部数据结构往往是最常见的缺陷来源,检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。
检查应考虑以下方面:
1是否存在不正确或不一致的数据类型说明;
2是否存在未初始化或未赋值的变量;
3变量值是否存在初始化或默认值错误;
4是否存在不正确的变量名(拼错或不正确地截断);
5是否存在上溢、下溢或和地址异常。
如果模块内包括外部输入输出,还应该考虑下列因素:
1)文件属性是否正确;
2)OPEN/CLOSE语句是否正确;
3)格式说明与输入输出语句是否匹配;
4)缓冲区大小与记录长度是否匹配;
5)文件使用前是否已经打开;
6)是否处理了文件尾;
7)是否处理了输入/输出错误;
8)输出信息中是否有文字性错误;
3、模块中所有独立的执行路径测试
在模块中应对每一条独立执行路径进行测试,单元测试的基本任务是保证模块中每条语句至少执行一次。
此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。
此时基本路径测试和循环测试是最常用且最有效的测试技术。
计算中常见的错误包括:
1)误解或用错了算符优先级;
2)混合类型运算;
3)变量初值错;
4)精度不够;
5)表达式符号错
常见的比较和控制流错误如下:
1)是否存在不同数据类型变量之间的比较;
2)是否存在错误的逻辑运算符或优先次序;
3)是否存在因计算机表示的局限性,导致浮点运算精度不够,致使期望值与实际值不相等的两值比较;
4)关系表达式中是否存在错误的变量和比较符;
5)是否存在不可能的循环终止条件,导致死循环;
6)是否存在迭代发散、导致不能退出;
7)是否错误地修改了循环变量。
导致循环次数多一次或少一次。
4、模块的所有错误处理路径测试
一个好的设计应能预见各种出错条件,并设置适当的错误处理,以提高系统容错能力保证逻辑正确性,应考虑下列问题:
1)输出的出错信息是否难以理解;
2)记录的错误与实际遇到的错误不相符;
3)在程序自定义的出错处理段运行之前,缺陷条件是否已经引起系统干预;
4)异常处理不当;
5)错误陈述中未能提供足够的定位出错信息。
边界条件测试是单元测试中最后,也是最重要的一项任务。
众的周知,软件经常在边界上失效,采用边界值分析技术,针对边界值及其左、右设计测试用例,很有可能发现新的错误。
三、单元测试涉及的测试方法
1、静态测试技术
被测单元编译运行之后,若能正确运行,则可以展开后续的静态和动态测试,其中静态测试主要是通过走查、审查等会议方式,依据模块的详细设计,将代码与缺陷检查表进行对照,查看代码是否符合标准和规范。
2、动态测试技术
完成静态测试之后,还需运行程序,完成动态测试,在该过程中,也应综合应用百合与黑盒测试方法,查看语句、分支与路径的覆盖情况,同时利用边界值测试、等价类测试等黑盒测试方法,检查代码的容错性、边界处理等能力。
四、单元测试环境
单元测试一般不考虑每个模块与其他模块之间的关系,但单元本身并不是一个独立的程序,往往需要基于被测单元的接口开发相应的驱动模块和桩模块
1.驱动模块——模拟被测单元的上级模块,用于接收测试数据,启动被测模块和输出结果
2.桩模块——模拟被测单元所调用的模块
3.驱动模块和桩模块的使用条件
●驱动模块和桩模块是为了对单元进行测试而引人的额外的代码
●当需要模拟的单元比较简单时,如:
代码很短、代码结构简单、不含有复杂的循环和逻辑判断、不涉及复杂的动态内存分配和释放等,无需专门设计驱动模块或桩模块
●当需要模拟的单元比较复杂时,最好利用驱动模块或桩模块构建测试环境
4.测试驱动程序的定义
测试驱动程序是通过测试用例来驱动被测单元,以便于观察测试用例执行结果,查找缺陷的代码段
简单的说,测试驱动是能够执行测试用例或测试套包的软件程序或测试工具。
2、集成测试
1)定义:
集成测试也叫做组装测试。
通常在单元测试的基础上,将所有的程序模块进行有序的、递增的测试。
集成测试是检验程序单元或部件的接口关系,逐步集成为符合概要设计要求的程序部件或整个系统。
集成测试的依据是单元测试的单元及概要设计文档
软件集成的过程是一个持续的过程,会形成很多个临时版本,在不断的集成过程中,功能集成的稳定性是真正的的挑战。
在每个版本
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 笔记