《软件测试》 知识点

应对期末考试，555。。。

面向对象设计原则（7点）

• 单一职责
  类的职责要单一，不能将太多的职责放在一个类中
• 开闭原则
  软件实体对扩展是开放的，但对修改是关闭的，即不能修改一个软件实体的基础上去扩展其功能。
• 里氏代换
  在软件系统中，一个可以接收父类对象的地方必然可以接收一个子类对象。
• 依赖倒转
  要针对抽象层编程，而不要针对具体类编程
• 接口隔离原则
  使用多个专门的接口来取代一个统一的接口。（不需要的功能分离开）
• 合成复用原则
  尽量使用组合和聚合，少使用或不适用继承。
• 迪米特
  高类聚，低耦合。
  软件是体对其他实体的引用越少越好；减少直接通信，或引入第三者发生间接交互。

实验部分

LoadRunner11

1、制定测试计划
测试计划是必要的；保证测试目标，包括实例的设计、场景设计等。

2、录制测试脚本

• 2.1、新建脚本/协议
  -Create/Edit Scripts -> New Single Protocol Script -> Web -> create
• 2.2、录制脚本
  Start Record -> URL( 站) ->some actions -> 运行测试脚本

3、创建运行场景

• 3.1、手动设置场景Manual Scenario
  • 3.1.1、添加脚本（上一步 录制的脚本）
  • 3.1.2、设置虚拟用户（试用版25个）
  • 3.1.3、设置测试机器
    默认是本机localhost
  • 3.1.4、设置测试组

4、运行测试
单机Run即可运行整个场景

5、监视场景
运行过程中，对服务器的各项性能指标进行实时监测。
Start Scenario按钮，进入场景监视界面，

6、分析测试结果

• Mercury LoadRunner/Application/Analysis
• Results/Analyze Results
  查看各种图表。

Ranorex

1、Ranorex Spy 捕获控件

• 启动Spy程序，鼠标单击“Track”。
• 鼠标至于控件上， 可以在Ranorex Studio上看到 控件库。
  2、录制/编写脚本

录制：

• 新建项目
• 点击“Record”开始脚本录制； 首次录制需要选择 启动的程序（计算器等）
• 对计算机进行一些操作。
• 录制完毕会生成脚本，可以run运行回放。

JUnit

1、引入 JUnit的Jar包

• 引入方式有多种，比如Maven项目在pom文件引入等等； 最终能在 External Libararies 里看到JUnit的Jar包；
• 注意版本。

2、主要是用五种断言进行测试；

• assertTrue（express）：
• assertEquals([String message,] expected, actual); 判断测试值 是否符合预期
• assertSame([String message,]expected, actual); 判断是否指向同一个对象；
• assertNull([String message,], java.lang.Object object); 判断对象是否为空
• fail([String message]); 立即终止测试

BoundCheck

BoundCheck继承 VC++6.0，可以在工具栏出现他的选项。
两种模式

• ActiveCheck： 低级模式，检查内存泄漏错误、资源泄露错误、API函数使用错误。
  1、选择测试程序代码；
  2、开启 “BoundsCheck-》 Integrated Debugging” 和 “BoundsCheck -》 Report Errors and Events”
  3、Build -》 Start Debug -》 go。
  4、选择 Report Error Immediately 可以实时看到错误，并且可以选择 跳过、调试等操作
  5、结束后 会有一个 发现错误的 列表。

• FinalCheck： 高级模式，检查指针操作错误、内存操作溢出、使用未初始化内存等。
  （比ActiveCheck 更详细，但会慢一点， 区别需要添加一个 BoundsCheck文件夹）
  1、构造一个 BoundsChecker编译连接器文件夹

  • Build-》 Configurations…
  • Add -》 输入名称
  • Copy settings from组合框中 选择 “xxx-Win32 Debu” ->close

  2、build -》 Set Active Configuration， 选择上一步新建的文件夹
  3、BoundsChecker-> Rebuild All with BoundChecker， 用BoundsChecker重新编译。
  4、然后和 ActiveCheck操作一样， start-》 debug-》go； 可以看到错误的列表。

第一章 软件测试基础

1.1.1、什么是软件

• 软件： 是计算机中与硬件相结合的一部分， 包括 程序 和 文档。
• 程序：实现某种功能的 指令集和。
• 文档：软件在开发、使用、维护过程中产生的 图文集和

1.1.2、软件测试包括 程序测试 和 文档测试。

程序测试： 程序逻辑功能、界面、性能、易用性、兼容性、安装等测试。
文档测试： 文档内容和截图的检验，排版风格的检查，错别字的校验。

1.2、软件的分类

• 按功能 划分
  系统软件： 直接操作底层的硬件、并为上层软件提供支撑的软件。
  应用软件： 为用户提供特定的应用服务软件。
• 按技术架构划分
  单机版软件：直接在单个计算机上安装并运行的软件；不需要考虑 络传输。
  C/S结构软件：服务器安装服务器软件，客户端安装客户端软件； 基于局域 或互联 ，不便于升级和维护（重新安装）
  B/S结构软件： 只要有浏览器，地址栏输入域名，就可以访问服务器端程序；基于局域 或互联 ；便于升级和维护。
• 按照用户划分
  产品软件： 目标是大众用户；需要考虑硬件和软件的兼容性测试；
  项目软件： 目标是具体的用户； 80%都属于项目软件。
• 按照开发规模划分
  小型： 10人以下， 1-4个月；
  中型： 10-100人， 1年以下；
  大型： 100人以上，1年以上；

1.3、什么是BUG

唯一标准： 软件中不符合用户需求的问题。

3类Bug：

• 完全没有实现的功能
• 基本实现了用户需要的功能，但是运行时会出现一些功能或性能上的问题。
• 实现了用户不需要的功能；多余的功能。

几个概念：Defect、Error、Failure

• Defect（缺陷）：在需求和设计阶段所引入的错误。
• Error（错误）：在开发编码阶段产生的错误。
• Failure（故障）：在交付客户使用过程中出现的错误。

1.4、什么是软件测试

使用人工或自动的手段，来运行或测试某个系统的过程。
目的： 检验它是否满足规定的需求，或弄清预期结果与实际结果之间的差别。

1.5.1、测试环境

软件测试环境就是软件运行的平台，硬件、软件和 络的集合。
测试环境=硬件+软件+ 络。

• 硬件：PC机、笔记本、服务器、各种PDA终端等。
• 软件：软件运行的操作系统；Windows2000、WindowsXP等
• 络：C/S结构和B/S结构的软件。 局域 /互联 ， 10M/100M

1.5.2 怎么搭建测试环境

1、真实
2、干净
3、无毒
4、独立

1.5.3 软件环境分类

• 软件开发环境： 开发过程中使用的环境
• 软件生产运行环境： 用户使用的环境
• 软件测试环境要与软件生产运行环境保持一致， 要从开发环境中独立出来。

1.6 测试用例

1.6.1 什么是测试用例

TC(Test Case): 测试执行之前设计的一套详细的测试方案，包括 测试环境（）、测试步骤、测试数据（输入）和预期结果（输出）。
测试用例 = 输入 + 输出 + 测试环境。

1.6.2 注意事项

1、 为什么要写测试用例：

• 便于团队交流
• 便于重复测试
• 便于跟踪统计
• 便于用户自测

2、什么时候写TC
尽早编写（测试设计）
测试计划 -》 测试设计 -》 测试执行 -》 测试评估

3、由谁编写
测试人员：测试设计人员

4、根据

• 用户需求
• 《系统需求规格说明书》和软件原型（没有嵌入全部源代码的软件界面）。

第二章 软件测试分类

2.1 黑盒测试和白盒测试

• 黑盒测试：不去关心内部结构，只关心软件的输入数据和输出结果。
• 黑盒测试包括： 功能测试 和 性能测试。
• 白盒测试：研究内部源代码和结构。
• 往往采用黑盒白盒相结合的方法；黑盒测试 对软件的整体的功能和性能进行测试； 对软件的源代码采用 白盒测试。

2.2 静态测试 和 动态测试

静态测试 ：指 不实际运行被测软件，只是 静态的检查程序代码、界面或文档中可能存在的错误的过程。
静态测试包括对 代码、界面、文档的测试：

• 代码： 代码是否符合相应 标准和规范。
• 界面： 软件的实际界面 和 需求中说明的是否相符。
• 文档： 测试 用户手册 和 需求说明是否正真符合用户实际需求。

动态测试： 实际运行被测程序，输入相应的测试数据，检查实际输出结果 和 预期结果是否相符合的过程。

• 和静态测试唯一标准 是 是否运行程序

静态测试、动态测试 和 黑盒测试、白盒测试 有包含交叉的关系：

• 黑盒测试可以是 静态（不运行程序，查看界面）和动态（运行程序，只看输入、输出）
• 白盒测试可以是 静态（不运行，看代码） 和 动态（运行，分析代码结构）
• 动态测试 可以是黑盒（） 和 白盒
• 静态可以是 黑盒 和 白盒

2.3 一些概念 单元测试、集成测试、系统测试、验收测试

2.3.1 单元测试

概念： 对软件中 最小可测单元进行检查和验证。
例如： C函数、Java类、图形化 窗口、菜单。
什么时候： 代码编译后即可； 前期应该准备工作
谁来测试： 白盒测试工程师或开发人员； 开发人员测试应该交叉测试。
依据：源程序本身： 代码和 注释； 《详细设计》文档。
通过标准：

• 所有单元测试用例
• 语句覆盖率 100%
• 分支覆盖 85%；

桩模块和 驱动模块：

• 桩模块： 模拟被测模块所调用的模块。（下部）
• 驱动模块：模拟 被测模块的上级 模块。

2.3.2 集成测试

概念： 单元测试下一步； 将通过测试的单元模块组装成系统或子系统，在进行测试；重点测试不同模块的接口部分。
目的： 检查各个单元模块结合到一起能否协同配合，正常进行。
时间：单元测试之后； 单元和集成同步进行；
谁：白盒测试工程师， 开发人员
依据： 单元测试的模块 和 《概要设计》文档。

2.3.3 系统测试

概念： 将整个软件系统看作1个整体进行测试；包括对功能、性能，以及软件所运行的软硬件环境进行测试。
谁： 黑盒测试工程师， 在整个系统集成完毕后测试； 前期功能， 后期 性能；
依据： 《系统需求规格说明书》

2.3.4 验收测试

概念： 在系统测试后期，以 用户测试为主， 或有测试人员等 质量保障人员共同参与的测试； 是软件正式叫给用户使用的最后一道工序；
验收测试分为 α测试 和 β测试：

• α测试：由 用户、测试人员、开发人员等共同参与的内部测试； 项目软件
• β测试： 内侧后的公测，完全交给最终用户测试； 产品软件
  依据： 《需求规格说明书》、验收标准。

2.4 功能测试和性能测试

2.4.1 功能测试

概念： 检查实际软件的功能是否符合用户需求；
包括：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试
1、逻辑功能测试
基本的 逻辑功能
2、界面测试（具体 。。。）

• 窗口
• 下拉式菜单和鼠标操作
• 数据项

3、易用性测试
从软件使用的合理性 和 方便性等角度对 软件系统进行检查，来发现软件中不方便用户使用的地方。

4、安装测试
包括 安装和卸载

5、 兼容性测试
包括： 硬件 和 软件 兼容性测试。

• 硬件兼容性测试： 软件运行的不同硬件平台的兼容性； 相对固定。
• 软件兼容性测试：
  • 单机版软件： 软件环境： 操作系统等
  • B/S结构：
    • 服务器： 服务器硬件、服务器操作系统、Web服务器、数据库服务器之间的兼容性
    • 客户端：用户所使用的操作系统 和 浏览器版本的 兼容性。（参照 单机版）
  • C/S结构：
    • 服务器：参照B/S
    • 客户端： 参照 单机版。

2.4.2 性能测试

性能主要有 时间性能 和 空间性能。

• 时间性能： 一个具体事务的 响应时间。（在某测试环境下，测不同响应时间的平均值）
• 空间性能：软件运行时所消耗的系统资源； CPU利用率、内存占有率等。

软件性能测试分为一般性能测试、稳定性测试、负载测试、压力测试。
1、一般性能测试

• 让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
• 单机版： 在其推荐配置下，检查 CPU利用率、内存占有率等性能指标 和 软件主要事务的平均响应时间。
• C/S和B/S结构的软件，测试单个用户登陆后，系统主要事务的响应时间和服务器的资源消耗情况。

2、稳定性测试（可靠性测试）

• （正常的软硬件环境）连续运行被测系统，检查系统运行时的稳定程度。
• MTBF（Mean Time Between Failure）错误发生时的平均时间；越大越好；
• 方法： 采用24 * 7 的方式让系统不间断运行，直到出错，记录，取平均值。

3、负载测试

• 在能忍受压力的极限范围之内，连续运行，测试稳定性。
• 对被测系统施加 其刚好能承受的能力；资源消耗到达临界值（CPU利用率 90% 以上、内存占有率 80% 以上等）
  4、压力测试
• 持续不断地给被测系统增加压力，直到将被测系统压垮为止；测试最大承受压力。

2.5 回归测试、冒烟测试、随机测试

2.5.1 回归测试

• 对软件的新的版本测试时，重复执行上一个版本测试时的用例。
• 新版本需要增加的功能的 测试，不属于回归测试。
• 时间：任何阶段进行。

2.5.2 冒烟测试

在对一个新版本进行系统大规模的测试之前，先验证以下软件的基本功能是否实现，是否具备可测试性。

2.5.3 随机测试

• 测试中所有输入数据都是随机生成的，目的是模拟用户的真是操作，并发现一些边缘性错误。
• 缺点： 测试不系统，很难回归测试；
• 一般是先做大规模的正规测试，时间允许，辅助一些随机测试。

第三章 软件测试的尝试

3.1 软件外包

软件外包：一些软件公司，处于节省成本 或是 优势互补的原因考虑， 将项目中的测试、部分编码或是 设计等工作 委派给第三方公司来完成。

3.2 软件测试工程师所需具备的素质

3.2.1 测试人员的基本从业素质

三心二意一能力：

• 三心： 细心、耐心、信心。
• 二意： 服务意识、团队合作意识
• 一能力：沟通能力。

3.2.2 如何成为一名优秀的测试工程师

1、不断学习充电
2、阅读原版书籍
3、阅读缺陷管理系统中的缺陷 告
4、阅读高手写的测试用例

3.3 软件测试和软件质量的关系

软件测试是软件产品高质量的必要非充分条件。

3.4 软件测试和SQA的关系

3.4.1 什么是SQA

• SQA（Software Quality Assurance， 软件质量保障）：为确保软件开发过程和结果符合预期要求而建立的一系列规程，以及依照规程和计划 采取的一系列活动及其结果评价。
• QA： 做软件质量保障的具体工作人。
• SQA是独立于项目组之外的第三方监督机构。

3.4.2 什么是CMM

• 是SQA用来监督项目的一个 标准质量模型。
• CMM, Capability Maturity Model， 能力成熟度模型。

3.4.3 SQA与测试

• 测试是在发现问题，SQA是在预防问题。
• 测试作为软件生命周期的一部分，其过程也要受SQA的监督
• 国内，许多名义上的SQA做着测试的工作；许多测试人员做着部分SQA的工作； 职位界定比较模糊。

3.5 软件测试的一些基本原则（7）

3.5.1 Zero Bug 与 Good Enough

• Zero Bug： 没有任何Bug。
• Good Enough： 软件达到一定质量要求，就可以停止测试了。
• 质量要求标准没有同一答案；

3.5.2 不要试图穷举测试

等价类等，在测试用例上 多下功夫。

3.5.3 开发人员不能既是运动员又是裁判员

• 测试应该由独立的第三方机构来完成。
• 黑盒测试由 测试人员来测试； 白盒测试由开发人员进行 交叉测试。

3.5.4 软件测试要尽早进行

• 在需求分析阶段引入的缺陷是最多的， 修复成本却是最低的；
• 越到后期，修改一个缺陷所涉及的问题和因素越多，相应的成本也越高；

3.5.5 软件测试应该追溯需求

测试环节 包括了4个部分：

• 正确的功能；
• 由错误编码代码的错误； 由开发人员直接修改；
• 由 错误的设计产生的错误； 不能直接修改，必须修改设计；
• 由 粗无说明带来的错误； 需要我们追溯需求；

3.5.6 缺陷的二八定理

• 80% 的缺陷集中在20% 的模块中；
• 集群现象；虫子窝现象；

3.5.7 缺陷具有免疫力

• 要求测试人员 要根据新版本的特点 去修改维护测试用例。

第四章 黑盒测试技术

4.1 等价类技术

常用例子：

• 数值
  • 整数
    • 范围划分
  • 小数
    • 范围划分
• 非数值
  • 字母
  • 特殊字符
  • 空格
  • 空白

4.1.1 等价类方法总结

等价类： 某个输入域的子集合；在其中，各个输入数据对于揭露程序中的错误都是等效的。

• 细节概念： 不考虑程序的内部结构，只是根据软件的需求说明，来对输入的范围进行细分，然后再从分出的每一个区域内选取一个有代表性的测试数据。
• 等价类分的好，这个代表性的测试数据的作用就等价于其区域内的其他取值。

等价类分为 有效等价类 和 无效等价类。

• 有效等价类： 合理的输入数据集合。
• 无效等价类：无意义的输入数据集合。

2、等价类划分步骤

• 数据类型
• 数据范围
• 示意图
• 等价类编
• 构造测试用例

3、常用划分方法

• 范围： 一个有效等价类， 两个无效等价类。
• 布尔表达式： 一个有效等价类， 一个无效等价类
• 规定了输入数据的一组值： 每个输入是一个有效等价类；一个无效等价类（任意一个不允许的输入值）
• 规定了输入数据必须遵循的规则： 一个有效等价类和若干无效等价类。

4.2 边界值技术

• 边界值，黑盒和白盒 都可以用

• 一般测试边界值 和 正好超出边界值 一个单位的值。

4.3 因果图法

• 测试所有的 输入条件的排列组合， 以及相应的输出
• 看ppt 例子

4.4 流程图

看例子，做题

第五章 缺陷管理

5.1 Bug的分类

1、按严重程度划分
【系统奔溃、】严重、一般、次要【、建议】
2、按优先级划分
高、中、低。

• 高：立即修复
• 中：产品发布之前修复
• 低：如果时间允许可以修复；可以暂时存在的bug

注意：

• 严重程度高优先级不一定高（极端条件、修改软件的整体架构）
• 严重程度低优先级不一定低（UI）

5.3 提交缺陷 告注意事项

1、 确保重新Bug
2、要用最少 且 必要的步骤描述Bug
3、简洁、准确、完整
4、一个bug一个 告

5.4 Bug处理流程

第六章 测试管理

6.1.1 软件的生命周期

定义： 指软件开发和测试全部过程的活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。

6.1.2 软件开发的 生命周期

需求分析 -》 概要设计 -》 详细设计 -》 编码 -》 维护（自 迭代）
《需求规格说明书》、《概要设计》、《详细设计》

6.1.3 软件测试的生命周期

测试计划 -》 测试设计 -》 测试执行 -》 测试评估

6.4 软件测试的评估

• 对覆盖的评估
  • 对源代码的覆盖
    • 语句覆盖100%
    • 分支覆盖85%
  • 对需求的覆盖
    • 所测试到的功能 和 功能需求 占到需求总数的百分比
    • 测试用例执行率100%
    • 测试用例的通过率 95%以上
• 对缺陷的评估
  • 缺陷分布图
  • 缺陷趋势图

第7章 软件测试工具简介

3类测试工具

• 黑盒测试工具
  • 功能：测试软件 功能和性能的工具；
  • 主要用于系统测试 和 验收测试
  • LoadRunner、Robot
• 白盒测试工具
  • 功能：实现代码的 静态分析和动态测试、评审等功能
  • 主要用于 单元测试
  • JUnit、BoundsCheck、JTest、C++Test
• 测试管理工具
  • 管理整个测试流程的工具
  • 功能： 测试计划的管理、测试用例的管理、缺陷跟踪、测试 告管理等
  • TestDirector、TestManager

白盒测试

1.2.1 白盒测试与黑盒测试比较

1、 白盒测试应用领域（3）

• 测试 程序中的分支覆盖 情况。
• 找到内存泄漏情况
• 极端情况， 只能对源代码进行静态分析

1.2.2 白盒测试分类

1、静态分析（3）

• 代码走查：开发组内部进行的；采用讲解、讨论和模拟运行的方式查找错误的活动；没有计划和 告；低 正式程度
• 代码审查：开发组内部进行的；采用讲解、提问并使用编码模板进行的查找错误的活动；由正式的计划、流程和结果 告； 中 正式程度。
• 技术评审： 开发组、测试组和相关人员（QA、产品经理等）联合进行；采用讲解、提问并使用编码模板进行的查找错误的活动； 有 正式的计划、流程和结果 告。

2、动态测试
用到一些比较实用的技术：边界值、逻辑驱动覆盖、路径图法等。

1.3 边界值技术

• 错误隐藏在角落，问题聚焦在边界。
• 具体方法： 根据输入数据的范围，找到边界值，测试边界值和正好超出边界值的数据。

白盒测试中的边界值：

• 测试i数据类型的边界值： 整数、单精度数；
  • 各平台下的 数据存储范围； C的 DOS平台和 Windows平台
  • int： -2147485648 – 2147483647 等
  • .。。。
• 测试数组的边界值；
• 测试分支判断语句的边界值： if(a >= 0) 中 a = 0；

1.4 逻辑驱动覆盖

• 专门用来测试程序中的分支结构 和 循环结构。
• 分支结构测试 包括：语句覆盖、分支覆盖、条件覆盖、分支-条件覆盖、条件组合覆盖、路径覆盖等。

1.4.1 语句覆盖

• 设计若干测试用例，使得程序中的每一条语句至少执行一次。
• 优点： 直观地 从源代码得到测试用例
• 缺点：对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的

1.4.2 分支覆盖

• 又叫判定覆盖
• 设计若干测试用例，使得程序中每一个分支的 取真分支和取假分支 至少各执行一次。
• 优点：简单性，无需细分每个判定。
• 缺点：用例仅根据最终结果 来设计，忽略了每个条件的取值情况，会遗漏部分测试路径。

1.4.3 条件覆盖测试

• 使得被测程序 不仅每条语句至少执行一次， 而且每个判定表达式中的每个条件都去到各种可能的结果。
• 缺点：不能保证分支覆盖

1.4.4 分支-条件覆盖

• 使得程序中 每个分支的 取真分支和取假分支至少个执行一次； 并且每个判定表达式中的每个条件 都取到可能的结果。
• 优点：满足 判定覆盖和条件覆盖准则；

1.4.5 条件组合覆盖

• 使得判定表达式中条件的各种可能组合至少出现一次。
• 每个分支有 2^n 个情况； n是条件的个数； 将每个分支的 情况 组合起来，设计用例
• 优点： 满足分支覆盖、条件覆盖、分支-条件覆盖准则。

1.4.6 路径覆盖

• 使得每条可能路径至少执行一次。
• 缺点： 不一定能保证条件组合覆盖。

总结：

没有十全十美的测试覆盖方法， 每一种方法都有其优点和缺点。
一般对测试用例有如下要求：

• 语句覆盖 100%；
• 分支覆盖 85% 以上;
• 路径覆盖 80% 以上；

多看看例题

1.5循环语句测试

不是重点

1.6 面向对象单元测试

1、划分类的优先级，适当取舍。
2、对被测试类进行静态分析
3、对被测试类 设计测试用例
4、 构造测试驱动程序。