软件工程复习L7
Introduction
- 软件测试的两个不同目标
- 向开发人员和客户证明软件满足要求 -- software meets requirements
- 在软件的行为不正确、不受欢迎或不符合其规范的情况下发现软件中的故障或缺陷 -- discover faults or defects
- 埃兹格·迪克斯特拉:
- “测试只能显示错误的存在,而不是它们的缺失”
- 软件测试过程模型 software testing process

Software Testing Process
数据处理 -> 设计测试用例 -> 判断结果

- 验收测试:
- 如果软件是给一个客户开发的,需要进行一系列验收测试来保证满足客户所有的需求。验收测试主要由用户而不是开发者来进行的。
- Alpha测试与Beta测试:
- 如果一个软件是给很多客户使用的,可使用Alpha测试与Beta测试。
- Alpha测试:
- 是在一个受控的环境下,由用户在开发者的指导下进行测试,由开发者负责记录错误和使用中出现的问题。
- Beta测试:
- 由最终用户在自己的场所进行,开发发者通常不在场,也不能控制应用的环境。由用户记录错误和使用中出现的问题,并定期地交给开发者来解决。
Integration testing 集成测试
- 系统集成的过程包括从其组件构建一个系统,并针对组件交互引起的问题测试生成的系统
- 集成测试期间出现的一个主要问题是定位错误 localizing errors
- 为了更容易地定位错误,您应该始终使用增量方法进行系统集成和测试
- 一个好的经验法则是首先集成实现最常用功能的组件。 这意味着最常用的组件接受最多的测试
- 系统被视为组件的层次结构
Incremental integration testing

Integration Testing Strategies 集成测试策略
- 选项:
- “大爆炸”方法 -- big bang
- 增量构建策略 -- incremental construction strategy
Big-Bang Integration Example
需要存根和驱动程序来测试独立组件

系统被视为组件的层次结构

Bottom-Up Integration Example
测试序列及其依赖关系

Top-Down Integration Example
只有A是自己测试的

Modified Top-Down Integration Example
在合并之前对每个级别的组件进行单独测试

集成测试的策略:
- 自顶向下测试:从顶模块开始,沿被测程序的结构图逐渐向下测试。按照移动路线的差异,又可区分为两种不同的实施策略:
- 先广度后深度实施步骤。 组装顺序:M1-M2-M3-M4-M5-M6-M7-M8
- 先深度后广度实施步骤。 组装顺序:M1-M2-M5-M6-M8-M3-M4-M7

Black-box and White-box testing
黑箱测试

白箱测试

Release testing 发布测试
- 发布测试是测试将分发给客户的系统发布的过程
- 发布测试通常是一个黑盒测试过程,其中测试源自系统规范
- 黑盒测试
- 另一个名称是功能测试

Black box testing

导致异常行为的输入
显示缺陷存在的输出
惠特克 (2002) 指导方针:
- 选择强制系统生成所有错误消息的输入
- 设计导致输入缓冲区溢出的输入
- 多次重复相同的输入或一系列输入
- 强制生成无效输出
- 强制计算结果过大或过小
LIBSYS 示例:
- 使用正确和不正确的登录来测试登录机制,以检查是否接受了有效用户和拒绝了无效用户
- 使用针对已知来源的查询来测试搜索工具,以检查搜索机制是否确实在查找文档
- 测试系统演示工具以检查有关文档的信息是否正确显示
- 测试请求下载权限的机制
- 测试表明下载的文档可用的电子邮件响应
Performance testing 性能测试
- 发现缺陷的一种有效方法是围绕系统的限制设计测试。 在性能测试中,这意味着对系统施加压力——因此得名压力测试(stress testing)
- 压力测试的两大功能
- 它测试系统的故障行为
- 它会给系统带来压力,并可能导致通常不会发现的缺陷曝光
Component testing 组件测试
- 组件测试(或单元测试)是测试系统中单个组件的过程
- 要测试的不同类型的组件
- 对象中的单个函数或方法
- 具有多个属性和方法的对象类
- 由几个不同的对象或功能组成的复合组件
Interface testing 接口测试
- 许多组件由几个相互作用的对象组成
- 测试这些复合组件然后主要关注测试组件接口的行为

- 接口测试的一些通用指南
- 检查要测试的代码并明确列出对外部组件的每次调用
- 当指针通过接口传递时,始终使用空指针参数测试接口 -- pointers
- 在通过程序接口调用组件的情况下,设计应该导致组件失败的测试
- 在消息传递系统中使用压力测试,如上一节所述 -- stress testing
- 在多个组件通过共享内存交互的情况下,设计测试以改变这些组件的激活顺序
Test case design
- 设计测试系统的测试用例(输入和预测输出)
- 测试用例设计的各种方法
- 基于需求的测试,其中测试用例旨在测试系统需求 -- Requirements-based testing
- 分区测试,识别输入和输出分区并设计测试,以便系统执行来自所有分区的输入并在所有分区中生成输出 -- Partition testing
- 结构测试,您使用程序结构的知识来设计测试程序的所有部分 -- Structural testing
Requirements-based testing
- 基于需求的测试是一种系统的测试用例设计方法,您可以在其中考虑每个需求并为其派生一组测试
- LIBSYS 要求
- 用户应能够搜索所有初始数据库集或从中选择一个子集
- 系统应提供合适的查看器供用户阅读文档库中的文档
- 每个订单都应分配一个唯一标识符(ORDER_ID),用户应能够将其复制到帐户永久存储区
- LIBSYS 测试:
- 发起用户搜索已知存在和已知不存在的项目,其中一组数据库包括一个数据库
- .....,包括两个数据库
- ……,包括两个以上的数据库
- 从一组数据库中选择一个数据库并启动用户搜索已知存在和已知不存在的项目
- 从一组数据库中选择一个以上的数据库,然后……
Partition testing
- 输入数据和输出结果通常属于不同的类,其中一个类的所有成员都是相关的。
- 这些类中的每一个都是一个等效分区(equivalence partition)或域,其中程序对每个类成员都以等效的方式运行。
- 应从每个分区中选择测试用例。
Equivalence partitioning


Equivalence partition for search routine

Structural testing
- 结构测试是一种测试用例设计的方法,其中测试源自对软件结构和实现的知识
- 有时称为“白盒”测试

Path testing
- 路径测试是一种结构测试策略,其目标是通过组件或程序来执行每条独立的执行路径
- 通过程序的路径数通常与其大小成正比
- 路径测试不会测试通过程序的所有路径的所有可能组合
- 路径测试的起点是程序流程图 (a program flow graph)
- 路径测试的目标是确保通过程序的每个独立路径至少执行一次

When to Stop Testing More faulty?
Probability of finding faults during the development


Fault seeding
何时停止测试停止方法
覆盖标准 Coverage criteria
故障播种 Fault seeding
- \(\frac{检测到的种子故障}{种子错误总数} = \frac{检测到的非种子故障}{非种子错误总数}\)
N=Sn/s
- S:播种故障数,n找到非播种故障数,其中播种故障s个
两个独立的测试小组测试
- 两个小组的有效性 E1=x/n, E2=y/n
- 两个小组共同发现了q个故障
- 小组1的有效性 E1=x/n=q/y 并且 E2 =y/n=q/x
- 因此推导出 n= q/(E1*E2),用q/y,q/x来模拟有效性
- n = x*y/q
何时停止测试识别容易出错的代码
- 跟踪开发过程中在每个组件中发现的故障数量
- 收集关于每个组件的测量(例如,大小、决策数量)
- 分类树(Classification
trees):一种统计技术,可对大量测量信息进行排序并创建决策树以显示最佳预测值
- 树有助于确定哪些组件可能有大量错误
An Example of a Classification Tree

Test automation 测试自动化
- 测试是软件过程中一个昂贵且费力的阶段
- 一些工具:
- Test manager Test data generator Oracle File comparator Report generator Dynamic analyzer Simulator
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Yeの博客!
