软件测试基础教程学习4

软件测试技术和方法

4.1 静态测试和动态测试

根据程序是否运行,可以把软件测试分为静态测试和动态测试两大类。

静态测试主要针对不运行的部分进行检查和审阅;
动态测试是指通常意义上的测试及运行和使用软件。
在实际工作中,代码检查为静态测试,而黑盒测试和白盒测试都是动态测试。

静态测试包括:

  • 代码审查(包括代码评审和走查)。代码审查一般是按代码检查单阅读程序,查找错误。其内容包括:检查代码和设计的一致性;检查代码的标准性、可读性;检查代码逻辑表达的正确性和完整性;检查代码结构的合理性等。
  • 静态分析。主要对程序进行控制流分析、数据流分析、接口分析和表达式分析等。
  • 文档检查。主要是指文档测试。

通过静态测试,一般可以发现软件中的如下缺陷:

  1. 错误的局部变量和全局变量。
  2. 不匹配的参数。
  3. 不适当的循环嵌套和分支嵌套。
  4. 不适当的处理顺序。
  5. 无终止的死循环。
  6. 未定义的变量。
  7. 不允许的递归。
  8. 调用不存在的子程序。
  9. 遗漏了标号或代码。
  10. 不适当的连接。

引起以上缺陷的原因可能是:

  1. 未使用过的变量。
  2. 不会执行到的代码。
  3. 未引用过的标号。
  4. 可疑的计算。
  5. 潜在的死循环。

动态测试是通过原程序运行时所体现出来的特征来进行执行跟踪,时间分析以及测试覆盖等方面的测试。动态测试时真正运行被测程序,在执行过程中通过输入有效的测试用例,对其输入与输出的对应关系进行分析,以达到检测的目的。

4.2 黑盒测试和白盒测试概述

**黑盒测试:**已知产品的用户需求规格,可以通过测试证明整个软件系统是否符合用户的最终需求。
**白盒测试:**已知产品的详细设计过程,可以通过测试证明所有内部操作是否符合设计规格要求,所有内部成分是否已经通过检查。

在这里插入图片描述
黑盒测试的出发点是用户需求,而白盒测试的出发点是程序实现。

4.3 黑盒测试技术

黑盒测试的检查点一般包括:

  1. 根据需求规格说明书检查是否有不正确或遗漏的功能;是否忽略了用户的隐含需求。
  2. 在软件的外部接口上输入信息能否被正确的接受,能否输出正确的结果。
  3. 是否有数据结构错误或外部信息(如数据文件)访问错误。
  4. 性能上能否满足要求。
  5. 易用性和其他功能特性能否满得到满足。
  6. 是否有初始化或终止性缺陷,是否会出现用户不能接受的缺陷。

4.3.1 等价类划分

采用等价类划分方法,主要是根据需求规格中对程序的输入和输出要求区别开来并加以分解,从而进一步设计出测试用例。

等价类划分的方法是把程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据作为测试用例。其中每一部分代表测试相同目标或者暴露相同软件缺陷的一组测试用例,具体划分为有效等价类和无效等价类。

  • 有效等价类:对程序的规格说明是有意义的,合理的输入数据所构成的集合。在具体问题中,有效等价类可以是一个,也可以是多个。

  • 无效等价类;对程序的规格说明是不合理的或无意义的输入数据所构成的集合。一般来讲,无效等价类会有多个,对于输入数据较多的情况,无效等价类要比有效等价类的数量多。

  1. 确定等价类的原则
  • 如果输入条件规定了取值范围或取值的个数,则可确定一个有效等价类和两个无效等价类。
  • 输入条件规定了输入值的集合,或是规定了“必须如何”的条件,则可确定一个有效等价类和一个无效等价类。
  1. 确定测试用例步骤
  • 为每个等价类规定一个唯一的编号。
  • 设计一个测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类。
  • 设计一个新的测试用例,使其只覆盖一个无效等价类。

4.3.2 边值分析

边值可能涉及的数据类型包括数值、速度、尺寸、字符、地址、位置,数量等。在对这些数据进行边值分析时,重点考虑具有以下特征的数据:

(1)第一个和最后一个。
(2)最小值和最大值。
(3)开始和完成。
(4)超过和在内。
(5)空和满。
(6)最短和最长。
(7)最慢和最快。
(8)更早和更迟。
(9)最大和最小。
(10)最高和最低。
(11)相邻和最远。

边值分析原则:

(1)如果输入条件规定了取值范围,或是规定了值的个数,则应以该范围的边界内即刚刚超出该范围的边界外的值,或是分别对最大,最小个数及稍小于最小、稍大于最大个数作为测试用例。
(2)如果程序规格说明中提到的输入或输出域是个有序的集合(如顺序文件、表格等)则应注意选取有序集的第一个和最后一个元素作为测试用例。
(3)分析规格说明,找出其他的可能边界条件。

4.3.3 因果图法

因果图法不仅要考虑输入情况的各种组合,也要考虑各个输入情况之间的制约关系。

在实际问题中,输入状态之间相互还可能存在某些依赖关系,称为约束。例如,某些输入条件不可能同时出现。输出状态之间也存在约束。

注:因果图最终要生成决策表。

4.3.4 正交实验设计法

在正交实验设计法中,判断实验结果优劣的标准称为实验的指标,可能影响实验指标的条件称为因子,而因子影响实验的程度称为因子的水平(或状态)。

正交实验设计饭,首先要根据被测软件的规格说明书,找出影响其功能实现的操作对象和外部因素,把它们当做因子,把各个因子的取值当做状态构造出二元的因素分析表。然后利用正交表进行各因子的状态组合,构造有效的测试输入数据集,并由此建立因果图。

4.4.5 决策表驱动测试

在一些数据处理问题中,某些操作是否可以实施依赖于多个逻辑条件的取值,即在这些逻辑条件取值的组合所构成的多种情况下,分别执行不同的操作。处理这类问题的一个非常有力的分析和表达工具是决策表。其一般由以下四个部分组成,

(1)条件桩:列出了问题的所有条件,通常认为列出的条件的先后次序无关紧要。
(2)动作桩:列出了问题规定的可能采取的操作,这些操作的排列顺序没有约束。
(3)条件项:针对条件中给出的条件列出所有可能的取值。
(4)动作项:与条件项紧密相关,列出在条件下的各组取值情况下应该采取的动作。

在这里插入图片描述
决策表的建立步骤:

  • 确定规则的个数,假如有n个条件,每个条件有两个取值(0,1),则有n种规则。
  • 列出所有的条件项和动作项。
  • 填入条件取值。
  • 填入集体动作,得到初始决策表。
  • 简化合并相似规则(相同动作)。

任何一个条件组合的特定取值及其相应要执行的操作称为规则。在决策表中贯穿条件项和操作项的一列就是一条规则。

4.5.6 错误推荐法

错误推荐法靠经验和直觉来推测程序中可能存在的各种错误,从而有针对性的编写测试用例,可以列举出可能的错误和可能发生错误的位置,然后选择测试用例。

4.4 白盒测试技术

白盒测试技术主要应用于单元测试阶段,一般由编码人员完成。

白盒测试又称为结构测试或逻辑驱动测试,主要是测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序的所有逻辑路径进行测试,确定实际的状态是否与预期的状态一致。

白盒测试遵循的原则:

(1)对程序模块的所有独立的执行路径至少测试一次。
(2)对所有的逻辑判定,取“真” 与“假” 的两种情况都至少测试一次。
(3)在循环的边界和运行界限内执行循环体。
(4)测试内部数据结构的有效性。

白盒测试技术的内容主要包括:

(1)程序结构分析。
(2)逻辑覆盖。
(3)域测试
(4)符号测试。
(5)路径测试。

4.4.1 程序结构分析测试

  1. 控制流分析

控制流分析主要是检查程序的控制结构,只需要把程序设计中的流程图转化为流图(也称为控制流图)。
在这里插入图片描述

  1. 数据流分析

数据流分析最初是随着编译系统要生成有效的目标代码而出现的,主要用于代码优化。

  1. 信息流分析

信息流分析主要用于验证程序变量间信息的传输是否遵循了保密要求。

4.4.2 逻辑覆盖测试

逻辑覆盖测试方法包括:

1. 语句覆盖

语句覆盖:在测试时,首先设计若干个测试用例,然后运行被测程序,使程序中的每个语句至少执行一次。

语句覆盖的测试可以给人们一种心理上的满足,以为每个语句都经历过,似乎可以放心了,但实际上,语句覆盖在测试过程中,除去对检查不可执行语句有一定的作用外,并没有排除被测程序包含错误的风险,必须看到,被测程序并非是语句的无序堆积,语句之间的的确存在着许多有机的联系。

2. 判定覆盖
判定覆盖:设计若干测试用例,运行被测程序,使得程序中每个判断的真分支和假分支至少经历一次,即判断的真假值曾经均被满足。

同样只做到判定覆盖,仍无法找出内部条件的错误。

3. 条件覆盖
条件覆盖:设计若干测试用例,执行被测程序后,要求每个判断中的每个条件的可能取值均至少满足一次,但覆盖了条件的测试用例不一定覆盖了分支。

4. 判定/条件覆盖

判定条件覆盖:要求设计足够多的测试用例,使得判断中的每个条件的所有可能至少出现一次,并且每个判断本身的判定结果也至少出现一次。

但是忽略了路径覆盖的问题,而路径能否全面覆盖在软件测试中是个重要问题,因为程序要取得正确的结果,就必须消除遇到的各种障碍,沿着特定的路径顺利执行,如果程序中的每一条路径都得以测试,那么才能说程序受到了全面的检验。

5. 条件组合覆盖

条件组合覆盖:设计足够多的测试用例,使得每个判断的所有可能的条件取值组合至少执行一次,覆盖了所有判断的可取分支。但同样忽略了路径覆盖的问题。
6. 路径覆盖

路径覆盖:设计足够多的测试用例,要求覆盖程序中的所有可能路径。

在许多情况下,路径数都是个庞大的数字,要全部覆盖是无法实现的,即使都覆盖到了,仍然不能保证对此程序的正确性。

4.4.3 路径分析测试

分析程序中的路径是指检验程序从入口开始,执行过程中经历的各个语句,直到出口。

4.4.4 程序插装测试

程序插装是借助于在被测程序中设置断点或打印语句来进行测试的方法,在执行测试的过程中,可以了解一些程序的动态信息。这样在运行程序时,既能检验测试的结果数据,又能借助插入语句给出的信息掌握程序的动态运行特性,从而把程序执行过程中所发生的重要事件记录下来。

插装技术在软件测试中主要有以下几个应用:

  • 覆盖分析。程序插装可以估计程序在控制流图中被覆盖的程度,确定测试执行的充分性,从而设计更好的测试用例,提高测试覆盖率。

  • 监控。在程序的特定位置设立插装点,插入用于记录动态的语句,监控程序运行的某些特性,从而排除软件故障。

  • 查找数据流异常。程序插装可以记录在程序执行中某些变量值的变化情况和变化范围,掌握了数据变量的取值状况,就能准确的判断是否发生了数据流异常。

4.4.5 程序变异测试

程序变异测试是一种错误驱动测试。所谓错误驱动测试是指该方法是针对某类特定的程序错误的。

错误驱动测试主要有两种:程序强变异和程序若变异。

目录 一 软件测试 从零开始 5 1.1 引言 5 1.2 测试准备工作 5 1.2.1 向有经验的测试人员学习 5 1.2.2 阅读软件测试的相关书籍 6 1.2.3 走读缺陷跟踪库中的问题报告单 6 1.2.4 走读相关产品的历史测试用例 6 1.2.5 学习产品相关的业务知识 6 1.3 识别测试需求 7 1.3.1 主动获取需求 7 1.3.2 确认需求的优先级 8 1.3.3 加入开发小组的邮件群组 8 1.3.4 与开发人员为邻 8 1.4 测试用例设计 8 1.4.1 测试用例的基本格式 8 1.4.2 重用同类型项目的测试用例 9 1.4.3 利用已有的软件 Checklist 9 1.44 加强测试用例的评审 10 1.4.5 定义测试用例的执行顺序 10 1.5 测试用例执行 10 1.5.1 搭建软件测试环境,执行测试用例 10 1.5.2 测试执行过程应注意的问题 11 1.5.3 及时更新测试用例 11 1.5.4 提交一份优秀的问题报告单 12 1.6 测试结果分析 12 1.7 总结 13 二 软件测试的常识 13 2.1 引言 13 2.2 软件测试常识 13 2.2.1 测试是不完全的(测试不完全) 13 2.2.2 测试具有免疫性(软件缺陷免疫性) 14 2.2.3 测试是 “ 泛型概念 ” (全程测试) 14 2.2.4 80-20 原则 14 2.2.5 为效益而测试 15 2.2.6 缺陷的必然性 15 2.2.7 软件测试必须有预期结果 15 2.2.8 软件测试的意义 - 事后分析 15 2.2.9 结论: 15 三 浅谈软件开发中的注意事项 16 3.1 项目设计 16 3.2 设计变化和需求变化 16 3.3 代码编写 17 3.3.1 源程序文件结构 17 3.3.2 界面设计风格的一致性 17 3.3.3 编辑风格 17 3.3.4 命名规范 18 3.4 BUG修补 18 3.5 开发人员的测试 18 四 软件测试的若干问题 19 4.1 前言 19 4.2 博弈的各方 19 4.3 测试的过程 20 44 测试所具备的素质 20 4.5 自动化测试 20 4.6 测试的误区 21 五 浅谈功能测试用例模板设计 21 5.1 Excel 模版 21 5.2 测试用例状态转换分析 23 六 如何提高软件质量 23 6.1 什么是质量 24 6.2 流程对质量的贡献 25 6.3 流程与技术 27 6.4 全面质量管理 28 6.5 关注测试 29 6.6 成功的铁三角 30 6.7 国际上流行的质量标准 30 6.8 如何起步 32 七 ISO和CMM,我们该选择谁 32 7.1 管理水平的适用性 33 7.2 复杂度的适用性 33 7.2.1何谓研发过程复杂度 34 7.2.2 何谓组织机构复杂度 34 7.3 量化管理的适用性上 35 7.4 结论 36 八 如何做好单元测试 36 8.1 前言 36 8.2 组织结构应该保证测试组参与单元测试 36 8.3 加强单元测试流程规范性 37 8.3.1 制订单元测试的过程定义 37 8.3.2 单元测试工作产品必须纳入配置管理 38 8.3.3 必须制订覆盖率指标和质量目标来指导和验收单元测试 38 8.3.4 加强详细设计文档评审 39 8.4 单元测试者技能的提高 39 8.4.1 加强对单元测试人员的技能培训 39 8.4.2 必须引入工具进行辅助 40 8.4.3 单元测试者加强对被测软件的全面了解 40 8.5 结尾 40 九 漫谈人机界面测试 41 9.1 一致性测试 41 9.2 信息反馈测试 42 9.3 界面简洁性测试 42 9.4 界面美观度测试 42 9.5 用户动作性测试 43 9.6 行业标准测试 43 9.7 小结 44 十 基于Web的系统测试方法 44 10.1 功能测试 45 10.1.1 链接测试 45 10.1.2 表单测试 45 10.1.3 Cookies测试 45 10.1.4 设计语言测试 45 10.1.5 数据库测试 46 10.2 性能测试 46 10.2.1 连接速度测试 46 10.2.2 负载测试 46 10.2.3 压力测试 46 10.3 可用性测试 47 10.3.1 导航测试 47 10.3.2 图形测试 47 10.3.3 内容测试 47 10.3.4 整体界面测试 47 10.4 客户端兼容性测试 48 10.4.1 平台测试 48 10.4.2 浏览器测试 48 10.5 安全性测试 48 10.6 总结 49 十一 为盈利而测试 49 11.1 引言 49 11.2 什么是软件测试 50 11.3 六个误区 50 11.3.1 误区一:忽视对正常输入的测试 50 11.3.2 误区二:忽视设计阶段的参与与评估 50 11.3.3 误区三:忽视测试计划与测试文档的建立及维护 51 11.3.4 误区四:忽视缺陷的分析,报告及跟踪 51 11.3.5 误区五:错误的测试目标及测试终止条件 51 11.3.6 误区六:不懂得合理调配使用测试人员的知识技能结构 51 11.4 软件质量与软件测试 52 11.5 软件测试的经济目的 54 11.5.1 满足用户需求,提高产品的竞争力,最终提高产品的销售量 54 11.5.2 尽早发现缺陷,降低后继质量成本 54 11.6 何时应当停止测试 56 十二 整体性能测试剖析 57 十三 性能测试工具之研究 62 13.1 性能测试的意义 62 13.2 性能测试工具综述 63 13.3 性能测试工具的体系架构 64 13.4 虚拟用户产生器 Vugen 65 13.5 Proxy 二次捕获的问题 67 13.6 关联的问题 68 13.7 脚本的问题 70 13.8 Conductor 和 Player 部分 71 13.9 Conductor 和 Player 的技术要点 72 13.10 数据分析工具 Analysis 72 13.11 结束语 72 十四 性能测试原理及性能测试实例分析 73 14.1 软件测试中的性能测试 73 14.1.1 性能测试的含义 73 14.1.2 性能测试的分解 73 14.2 一个性能测试实例 74 14.2.1 被测系统 74 14.2.2 对被测系统进行性能测试 75 14.5 总结 80 十五 软件GUI测试中的关注点 80 15.1 不能不说的二个问题 81 15.1.1 软件测试中的“二八”原则 81 15.1.2 软件黑盒测试解决的问题 81 15.2 软件黑盒测试常见错误类型及说明 81 15.2.1 用户界面错误 81 15.2.2 功能性 81 15.2.3 人机交互 82 15.3 命令结构和录入 87 15.3.1 不一致性 87 15.3.2 “最优化” 87 15.3.3 菜单 89 15.4 遗漏的命令 90 15.4.1 状态转换 90 15.4.2 危机预防 90 15.4.3 由用户进行的错误处理 91 15.44 其他问题 91 15.5 程序僵化 92 15.5.1 用户可调整性 92 15.5.2 控制方式 93 15.6 性能 94 15.6.1 降低程序速度 94 15.6.2 缓慢回应 94 15.6.3 如何减少用户吞吐量 94 15.6.4 反应拙劣 94 15.6.5 没有提前输入 95 15.6.6 没有给出某个操作会花很长时间的警告 95 15.6.7 程序太多提示和询问 95 15.6.8 尽量使用简单命令和提示 95 15.7 输出 95 15.7.1 不能输出某种数据 95 15.7.2 不能重定向输出 95 15.7.3 与一个后续过程不兼容的格式 96 15.7.4 必须输出的很少或很多 96 15.7.5 不能控制输出布局 96 15.7.6 荒谬的精度输出级别 96 15.7.7 不能控制表或图的标记 96 15.7.8 不能控制图形的缩放比例 96 15.8 错误处理 96 15.8.1 错误预防 96 15.8.2 错误检测 97 15.8.3 错误恢复 98 15.8.4 边界相关的错误 99 15.8.5 计算错误 100 15.9 小结 100 十六 软件测试技术 100 16.1 软件测试基础 101 16.1.1 测试目标 101 16.1.2 测试原则 101 16.1.3 可测试性 102 16.2 测试用例设计 104 16.3 白盒测试 104 16.4 基本路径测试 105 16.4.1 流图符号 105 16.4.2 环形复杂性 106 16.4.3 导出测试用例 106 16.4.4 图矩阵 108 16.5 控制结构测试 108 16.5.1 条件测试 108 16.5.2 数据流测试 110 16.5.3 循环测试 111 16.6 黑盒测试 112
说明: 一、由于附件大小的限制,已将文件打成两个包发布(保证内容完整),请需要的朋友分开下载,谢谢合作。 二、请自行下载超星阅读器 简介:   我所见过的最好最经典的软件测试入门书,有一个别名叫“软件测试的本质”。书中没有讨论太多的软件测试理论,只包含了一部分常用的、基本的知识。从什么是软件测试、为什么要作软件测试开始,逐步引入基本的和高级的测试技术和方法,然后开始把读者引入实际工作中,讲述了一般的测试过程中要经历哪些阶段,要作哪些具体的工作,如何开展测试工作,如何找到缺陷并提交缺陷。甚至还包括了对测试人员的职业指导。建议所有的测试人员都读一读。 编辑推荐: 本书与同类书相比,具有一个显著的特点,就是浅显易懂。虽然整本书涉及的范围相当广泛,但是作者始终没有忘记,是读者的书,而不是他本人在自言自语。能够在如此庞杂的学科中流畅讲解、层层剖析,可见作者深厚的技术功底和对软件测试、软件工程的透彻理解。 目录 第一部分 软件测试综述 第1章 软件测试背景 第2章 软件开发过程 第3章 软件测试的实质 第二部分 测试基础 第4章 检查产品说明书 第5章 闭着眼睛测试软件 第6章 检查代码 第7章 带上X光眼镜检查软件 第三部分 运用测试技术 第8章 配置测试 第9章 兼容性测试 第10章 外国语言测试 第11章 易用性测试 第12章 测试文档 第四部分 加强测试 第14章 自动测试和测试工具 第15章 臭由轰炸和Beat测试 第五部分 使用测试文档 第16章 计划测试工作 第17章 编写和跟踪测试案例 第18章 报告发现的问题 第19章 评价成效 第六部分 软件测试展望 第20章 软件质量评判 第21章 软件测试员职业指导 附录测验问题解答
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值