西北工业大学软件测试50复习题（PPT顺序版）供参考

最新推荐文章于 2023-11-06 22:36:54 发布

Lord_Camelot

最新推荐文章于 2023-11-06 22:36:54 发布

阅读量1k

点赞数 1

分类专栏： NPU 文章标签：软件测试

本文链接：https://blog.csdn.net/weixin_64203206/article/details/121412976

版权

NPU 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

pdf版本下载（提取码：3ovf）

软件测试复习题

1、软件测试

概念：
- 在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价。
- 分析某个软件项以发现现存的和要求的条件之差别（即错误）并评价此软件项的特性。
目的：
- 回避潜在的软件错误和缺陷给软件造成的商业风险。
- 发现当前开发工作所采用的软件过程的缺陷，修正软件开发规则。
- 对软件质量进行度量和评估。

2、软件测试的原则

软件测试是证伪而非证真
尽早地和不断地进行软件测试
重视无效数据和非预期使用习惯的测试
程序员应避免检查自己的程序
注意测试中的群集现象
用例要定期评审
对测试结果做全面检查
测试现场保护和资料归档
经济型原则

3、软件质量保证

是贯穿软件整个生命周期的有计划和有系统的活动。
确保软件项目遵循了对应的标准及规范要求，且产生了合适的文档和精确反应项目情况的报告。

4、软件测试计划

软件测试计划是指导测试过程的纲领性文件，包含了产品概述，测试策略，测试方法，测试区域，测试配置，测试周期，测试资源，风险分析等内容；借助软件测试计划，参与测试的项目成员可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

5、制定软件测试计划的原则

尽早开始：尽早开始能根本了解被测对象及其内容，方便后续完善。
简洁易读：让测试人员清楚自己的任务和工作安排。
多渠道评审：通过开发等相关负责人的评审，发现不足与缺陷，能很好地提升质量。
计算投入：投入成本有限，注意测试计划的费用情况，量力而行。

6、制定软件测试的技术的步骤

计划、准备、检查、修改、继续

7、软件测试与软件开发的过程的关系

8、常用软件质量模型

McCall 模型、Boehm 模型、FURPS 模型、Dromey 模型和 ISO9126 模型。

9、各类测试汇总

黑盒测试&白盒测试
- 黑盒测试：只关心软件的输入数据和输出数据。
- 白盒测试：研究源代码和程序结构。
- 关系：
  - 软件公司往往采用黑盒测试与白盒测试相结合的方式。
  - 整体功能和性能进行黑盒测试。
  - 源代码采用白盒测试。
静态测试&动态测试
- 静态测试：不运行被测软件，只静态地检查程序代码、界面或文档中可能存在的错误。
- 动态测试：运行被测程序，输入测试数据，检查输出结果和预期结果是否相符。
单元测试&集成测试&系统测试&验收测试
- 单元测试
  - 定义：针对软件设计中的最小单位——程序模块，进行正确性检查的测试工作。
  - 原则：
    
    1）快速原则：快速运行。
    
    2）独立原则：独立运行。
    
    3）可重复原则：保证单元测试的可重复性。
    
    4）自动化原则：自动运行，自动校验，自动给出结果。
    
    5）及时原则：尽早地进行软件单元测试。
  - 重要性及目的：
    - 重要性
      
      1）单元测试会使工作更轻松、设计更好，并大大减少花在调试上的时间。
      
      2）提高代码质量。
      
      3）减少bug，快速定位bug。
      
      4）放心地修改、重构。
    - 目的
      
      1）尽早发现错误
      
      2）检查代码是否符合设计和规范
  - 主要测试问题：
    
    1）接口功能测试：保证接口功能的正确性。
    
    2）局部数据结构测试（不常用）：保证接口中的数据结构是正确的。
    
    3）边界条件测试。
    
    4）所有独立执行通路测试：保证每一条代码，每个分支都经过测试。
    
    5）各条错误处理通路测试：保证每一个异常都经过测试。
- 集成测试
  - 主要任务：在单元测试的基础上，将程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。
  - 集成测试与单元测试，系统测试的区别：
    
    1）测试方法不同：
    
    ①单元测试属于白盒测试范畴。
    
    ②集成测试属于灰盒测试范畴。
    
    ③系统测试属于黑盒测试范畴。
    
    2）考察范围不同：
    
    ①单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等。
    
    ②集成测试主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能。
    
    ③系统测试主要测试整个系统相对于需求的符合度。
    
    3）评估基准不同
    
    ①单元测试的评估基准主要是逻辑覆盖率。
    
    ②集成测试的评估基准主要是接口覆盖率。
    
    ③系统测试的评估基准主要是测试用例对需求规格的覆盖率。
  - 内容：
    
    1）将各个具有相互调用关系的模块组装起来时，检查穿越模块接口的数据是否会丢失。 2）判断各个子功能组合起来是否能够达到预期要求的父功能。 3）检查一个模块的功能是否对其他模块的功能产生不良影响。 4）检查全局数据结构是否正确，以及在完成模块功能的过程中是否会被异常修改。 5）单个模块的误差累计起来，是否会放大到不可接受的程度。
  - 方法：
    
    1）自顶向下：由上而下的集成测试方法要求首先测试和集成最高级别的模块。最大限度地减少对驱动程序的需求。
    
    2）自底向上：由下而上的方法要求首先测试和集成最低级别的单元。最大限度地减少了对存根（stub）的需求。
    
    3）第三种方法（伞形方法）：要求测试沿功能性数据和控制流路径进行。
- 系统测试：
  - 定义：将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。
  - 系统测试与用户测试的区别：
    
    1）系统测试，是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方，能够发现系统分析和设计中的错误。
    
    2）用户测试，是以用户为中心设计流程中的一种设计验证方法。通过观察和询问用户，记录产品的真实使用情况，界定出可用性问题。
  - 主要内容：
    
    1）功能测试。即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。
    
    2）健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力
    
    3）常见的、典型的系统测试包括恢复测试、安全测试、压力测试。
  - 常见系统测试方法：
    
    1）按测试对象分类
    
    ①白盒测试：软件底层代码功能实现，同时逻辑正确
    
    ②黑盒测试：测试软件外在功能是否可用。
    
    ③ 灰盒测试：介于两者之间（接口测试）
    
    2）按测试对象是否执行分类
    
    ①静态测试：测试对象不执行，测文档
    
    ②动态测试：将软件运行在真实环境当中
    
    3）按测试手段进行分类
    
    ①手工测试：由测试人员手动的对被测对象进行验证，优点，就是可以灵活的改变测试操作和环境
    
    ②自动化测试：两种形式：一种是自己写测试脚本，另外一种是通过第三方测试工具对被测对象进行测试。
- 验收测试：
  - 主要内容：按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。在系统测试的后期，以用户测试为主或有测试人员等质量保证人员共同参与的测试。
功能测试&性能测试
- 功能测试：略。
- 性能测试：时间性能，空间性能，一般性能测试，可靠性测试，负载测试，压力测试
回归测试&冒烟测试&随机测试
- 回归测试：软件被修改后重新进行的测试，为了保证修改没有引入新的错误。
- 冒烟测试：在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。
- 随机测试：略。

10、其余测试汇总

容量测试与压力测试的区别：
- 容量测试：目的是通过测试预先分析出某项指标的极限值，系统在极限值状态下能保持正常运行。容量测试是面向数据的，目的是显示系统可以处理确定的数据容量。
- 压力测试：对系统不断施加压力的测试，通过确定一个系统的瓶颈或者不能接受的性能点，获得系统能提供的最大服务级别的测试。
α 测试和β测试的区别：
- α测试：
  - 指的是指的是由用户，测试人员、开发人员等共同参与的内部测试。
  - α 测试在开发方场所测试，环境受开发方控制，用户少，时间集中，先于β测试。
- β测试：
  - 指的是内测后的公测，即完全交给最终用户测试。
  - β测试在一个或多个用户的场所测试，环境不受开发方控制，用户多，时间不集中，测试周期长。
恢复测试：对每一类导致恢复或重构的情况进行测试，验证软件自身运行、软件控制的系统、系统控制的软件的恢复或重构。
强度测试：使软件在极限状态以及超过极限状态下运行，检验软件对异常情况的抵抗能力。
正确性测试：检查软件的功能是否符合规格说明的测试
Web测试：Web测试是针对Web应用的一类测试。 Web项目的功能和性能都必须经过可靠的验证。通过测试可以尽可能地发现浏览器端和服务器端程序中的错误并及时加以修正，以保证应用的质量。
变异测试：一种面向缺陷的软件故障定位方式，属于一种白盒测试方法
兼容性测试：验证软件与所依赖的环境的依赖程度，包括对硬件平台的依赖程度和对软件平台的依赖程度。
第三方测试：第三方测试是指介于软件开发方和用户方之间的测试组织的测试，也称为独立测试，有独立的验证和确认活动。
确认测试：验证软件是否满足软件需求规格说明的各项需求，分为α测试和β则试。
负载测试：逐步增加系统负载，测试系统性能的变化，最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试。
安全（性）测试：测试软件在没有授权的内部或者外部的用户的攻击或者恶意破坏时如何进行处理，是否能保证软件和数据的安全。
自动化测试：把以人为驱动的测试行为转化为机器执行的一种过程。
模糊测试：向目标系统提供非预期的输入并监视异常结果来发现软件漏洞。
渗透测试：为了证明网络防御按照预期计划正常运行而提供的一种机制。
文档测试：测试开发过程中生成的文档，以需求规格说明、软件设计、用户手册、安装手册等为主，检验文档是否和实际存在差别。文档测试不需要编写测试用例。

11、测试用例

测试用例是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量稳定的根本保障。
唯一标准是用户需求，参考资料是《需求规格说明书》

12、测试用例的设计

为什么需要测试用例：
- 避免盲目测试，提高测试效率，减少测试的不完全性。
- 令软件测试实施重点突出、目的明确。
- 根据测试用例的多少和执行难度，估算工作量，便于时间和资源管理的跟踪。
- 减少回归测试复杂度。
- 测试用例的通用化和复用化会使软件测试易于开展。
- 方便书写软件测试缺陷报告。
- 根据测试用例执行等级实施不同级别的测试。
好的测试用例的特征：
- 最大程度地找到软件隐藏的缺陷。
- 最高效率地找到软件缺陷。
- 最大程度地满足测试覆盖要求。
- 不过分复杂，也不过分简单。
- 使软件缺陷的表现可以清楚判定。
  - 测试用例包含期望的正确结果。
  - 待查的输出结果或文件简单明了。
- 不包含重复测试用例。
- 测试用例内容清晰，格式一致，分类组织。
影响因素：
- 需求目标：是功能性的需求目标也是非功能性的需求目标。功能性测试正确与否一目了然，非功能性测试相对性比较强。
- 用户实际使用场景。
- 软件功能需求规格说明书、产品设计文档。
- 测试方法。
- 测试对象：客户端软件和服务器端系统、分布式系统和集中式系统等。
- 软件实现所采用的技术。
4性
- 代表性：能够代表并覆盖各种合理的和不合理的、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。
- 针对性：对程序可能存在的错误有针对性的测试。
- 可判定性：测试结果的正确性是可判定的，每一个测试用例应有相应的期望结果。
- 可重现性：同样测试用例的执行结果相同。
指导思想：
- 软件测试需求和测试计划是测试用例的设计基础。
- 按照测试用例框架设计和详细设计进行分布式的测试。
- 根据质量目标，测试周期，测试成本，测试者技能，确定合适的测试用例数量和测试内容的详细程度。
- 分析用户实际使用的场景，被测软件的类型特征和测试方法。
- 寻求系统设计、功能设计的弱点，设计测试用例以寻求软件存在的缺陷，而不是简单的复制软件设计规格说明书。
- 既要设计正面的测试用例，也要设计负面的测试用例。
元素

5W1H1E
- 测试目标：Why—为什么而测？功能、性能、易用性、可靠性、兼容性、安全性等。
- 测试对象：What—测什么？被测试的项目、如对象、菜单、按钮等。
- 测试环境：Where—在哪里测？测试用例运行时环境，包括系统配置和设定等要求，也包括操作系统、浏览器、网络环境等。
- 测试前提：When—什么时候开始测？测试用例运行的前提或条件限制。
- 输入数据：Which—哪些数据？在操作时系统所接受的数据。
- 操作步骤：How—如何测？执行软件的先后次序步骤。
- 预期结果：Effect—判定依据？执行用例后的判定依据。
组成：
- 测试用例编号
- 测试用例名称
- 测试用例设计者
- 软件版本号
- 测试目的
- 参考信息
- 测试条件
- 测试环境
- 输入数据
- 操作步骤
- 预期结果
分类：
- 接口测试用例
- 路径~
- 功能~
- 容错能力~
- 性能~
- 界面~
- 安全性~
- 压力~
- 可靠性~
- 安装/反安装~
设计步骤：
设计方法：

13、测试用例的原则

利用成熟测试用例设计方法指导设计
测试用例的针对性
~代表性
~可判定性
~可重现性
~足够详细、准确和清晰的步骤
符合内部规范要求

14、黑盒测试

常见的测试用例设计方法：等价类划分、边界值划分、错误推测法、因果图法、正交表试验法、场景图、功能图

等价类：从大量数据中划分等价类，从每个等价类中挑选代表数据，这些代表数据要能反应这个范围内数据的测试结果。
边界值：程序的很多错误发生在输入或输出范围的边界上，因此针对边界情况设置测试用例，可以发现不少程序缺陷。
错误推测法：基于测试人员的经验和直觉推测所有可能存在的错误，有针对性的设计测试用例的方法。
因果图法：适合输入条件比较多的情况，测试所有输入条件的排列组合。
正交表试验法：从大量试验点中挑出适量的、有代表性的点，利用“正交表”合理安排试验对所有变量对的组合进行典型覆盖。
场景图：用例场景是用来描述流经用例路径的过程，这个过程从开始到结束遍历用例中所有基本流和备选流。
功能图：用功能图描述程序的功能说明，并机械的生成功能图的测试用例。

15、白盒测试

覆盖准则：
- ESTCA（错误敏感测试用例分析）：在最容易发生问题的地方设计测试用例。
- LCSAJ（线性代码序列与跳转）：一个LCSAJ是一组顺序执行的代码，以控制跳转为其结束点
常用工具及其适用的情况：
- Jtest：是一个代码分析和动态类、组件测试工具，是一个集成的、易于使用和自动化的Java单元测试工具。它增强代码的稳定性，防止软件错误。
- Jcontract：Jcontract在系统级验证类/部件是否正确工作并被正确使用。Jcontract 是个独立工具，在功能上是Jtest 的补充。
- C++ Test：无需编写单个测试实例、测试驱动程序或桩调用。
- CodeWizard：代码静态分析工具
- Insure++：一个基于C/C++的自动化的内存错误、内存泄漏的精确检测工具。
- .test：专为.NET开发而推出的使用方便的自动化单元级测试与静态分析工具。
- BoundsChecker：针对Visual C++开发人员的首选的运行时的错误检测和调试工具。
- SmartCheck：针对Visual Basic的主要的自动错误检测和调试工具。它能够自动检测和诊断 VB运行时的错误,并将一些表达不清楚的错误信息转换为确切的错误描述。