Post

软件测试

Posted Updated
By SmallC
19 min read
软件测试

什么是Software

质量模型六个属性

  • Functionality
  • Reliability
  • Usability
  • Efficiency
  • Maintainability
  • Portability

三种软件错误

  • software fault：软件静态缺陷
  • software failure：与软件需求或预期描述不符合的外部错误行为
  • software error：内部软件错误

PIE Model

  • execution
  • infection
  • propagation

software faults categories

  • algorithmic faults
  • syntax faults

Verification / Validation

  • Verification：确定软件开发阶段的产品是否满足前一阶段所确立的需求
  • Validation：软件开发末期的验收问题

software testing axioms / 软件测试公理

  1. 可以完全的测试一个程序
  2. 软件测试是一项基于风险的活动
  3. 测试不能保证bug不出现
  4. 越多的bug你发现，越多的bug没发现
  5. 不是所有被找到的bug都能被修复
  6. 很难说一个错误何时能被称作错误
  7. specification 无法被确定
  8. 软件测试者不是一个项目最受欢迎的人
  9. 软件测试是专业的高技术的专业问题

重要的测试模型

Waterfall Model / 瀑布模型

  • 所有计划在开始阶段完成设计，并且在后续阶段不会改变
  • 阶段与阶段之间没有重叠部分

    Spiral Model / 螺旋模型

  • 迭代的开发模型，允许在每个阶段进行修改和改进
  • 每个阶段都包含一个风险评估的过程，螺旋模式是风险驱动的开发模式

    V-Model / V模型

    获取需求-分析-设计-规范-编程-单元测试-集成测试-系统测试-验收测试

    W Model / W模型

    编写需求-规范系统-设计系统-编写代码-构建软件-构建系统-安装系统 测试需求-测试规范-测试设计-测试代码-测试软件-测试系统-测试安装

    Agile Model / 敏捷模型

测试原则

static and dynamic verification

  • static: 不运行代码
  • dynamic：运行代码

black and white box testing

  • black: 根据软件规格来进行测试
  • white：根据软件代码来进行测试

fault insertion

Mutaion Testing

  • ABS
  • AOR
  • LCR
  • ROR
  • UOI

Black Box Testing

Equivalence Partitoning \ 等价性划分

等价性划分是将庞大的测试用例集合划分为小的但等价的测试集合的过程。

Equivalence Class，等价的测试集合称为等价类

  • Valid Equivalence Class 合法的等价集合 测试需要覆盖全部
  • Invalid Equivalence Class 不合法的等价集合 测试只需一个

Steps to identify the test cases

场景测试步骤

  • 根据规格，描述basic flow 和alternative flow
  • 构建不同的能够满足测试需求的场景
  • 对每个场景设计对应的相关的测试用例
  • 重新检查所有生成的测试用例并删除冗余测试用例。确定测试用例后，将为每个测试用例确定测试数据值。

white box testing

control flow testing

  1. Statement Coverage 状态覆盖
  2. Decision Coverage 判断覆盖：设计测试用例使得所有的真假分支都被执行
  3. Condition Coverage 条件覆盖
    1. 优势：集中再跳进啊结果中，而扩大分支机构的覆盖范围
    2. 缺点：无法实现分支覆盖，因为决策本身没有必要采用真假结果。
  4. Decision/Condition Coverage 条件的真假分为两种测试用例

Decision/Condition Coverage Comments

Steps： - Identify all the decisions in the program - List all the conditions - Generate the data to cover the above decisions and conditions

  1. Condition Combination Coverage
    • 优点：测试每个决策中的可能的条件
    • 缺点：expensive、difficult

Path Coverage

  1. Control Flow Graphs 控制流图

Path Expression

  • . 表示节点序列的连接
    • 表示决策 if
    • 表示迭代 while for

得到路径表示公式后如何压缩呢？

  • 将 （expression）* 替换成（expression+0）

如何根据公式计算路径数呢？

  • 将node num替换成1
  • 将+当作加法 .当作乘法

每条路径就是一个测试用例，测试用例集合需要覆盖全部的路径

Path Coverage - EX

  • 优势：能够覆盖全部的测试分布
  • 缺点：程序复杂的情况下，可能有很多路径被发现，增大计算量；没有明确评估决策中的条件

Basis Path Test

step：

  • 绘画control flow graph
  • 计算cyclomatic complexity
  • 找到基本路径集合
  • create test path

计算cyclomatic complexity的方法

1
2
3

V(G) = E - N + 2
V(G) = P + 1 // P = Number of decision nodes
V(G) = R // R is number of regions

Data Flow Testing

Definitions

  • DEF(v,n) : v 的值在 n 被定义
  • USE(v,n) : v 的值在 n 被使用
    • P-Use：出现在表达式
    • C-Use：出现在计算

Coverage Criteria

  • ADUP：All-DU-Paths
    • ADUP 要求在某些测试用例下，从每个变量的每个定义到该定义的每次使用的每条 du 路径都必须执行。

Du-Pair testing / 双对测试的原则是执行变量中值的定义和随后使用之间的每条路径。

Static Testing

不运行代码，而是靠仔细的阅读代码来检查bug

  • Code Review
  • Static Program Analysis

Walkthroughs 代码走查

Formal Code Inspections

step：

  • Overview / 概况
  • Preparation / 准备
  • Inspection / 检查
  • Rework / 反工
  • Follow-up / 跟进

Program Static Analysis / 代码静态分析

  • Security
  • Memory Safety
  • Resource leaks
  • Api Protocols
  • Exceptions
  • Encapsulation
  • Data races

Test Plan and Test Case

  • Test Plan：描述软件测试返回和活动的文档
    • Master Test Plan
    • Testing Level Specific
    • Testing Type Specific

Test planning process

  • define test strategy
  • define test system
  • estimate test effort

  • prepare and review test plan

  • Testcase：测试案例是一组记录在案的前提条件 (prerequisites)、程序 (input/action) 和后提条件 (expected results) 的集合，测试人员用它们来确定被测系统是否满足要求或正常工作。

test cases 的集合是test suite

Unit Testing

单元测试是代码开发者为测试程序功能的小的单元的白盒测试

Scaffolding / 脚手架

Test-Driven Development / 测试驱动开发

  • 先写测试用例，然后写代码来通过测试用例
  • 编写代码当自动化测试失败时，及时修复代码以确保测试通过
  • 经常运行测试用例，确保代码的正确性

TDD的优点：

  • 单元测试被编写了
  • 程序员的满意度导致测试编写的一致
  • 说明接口和表现的细节
  • 自信的改变代码

Refactoring / 重构

Automated Unit Testing / 自动化单元测试

测试框架

  • automatic
  • repeatable
  • independent

Integration Testing / 集成测试

定义：

  • 选择集成测试数据是为了确保系统的各个组件或子系统能够正确协同工作
  • 测试案例研究各个组件之间的不同相互作用，确保产生正确的结果

System Tests

定义：

  • 保证整个系统能正常工作
  • 系统测试案例探究不同的输入和输入组合，确保系统能正常工作

Drivers and Stubs

临时的代码，用于替代被测系统的组件或子系统。

集成测试的方法

Decomposition-based Integration Testing / 分解基础集成测试

  • Big Bang Integration Testing / 大爆炸集成测试
    • 优点：简单、快速
    • 缺点：难以定位错误、难以调试、难以维护
  • Top-down Integration Testing / 自顶向下集成测试
    • 优点：早期发现错误、早期发现设计缺陷、早期发现接口问题
    • 缺点：需要stubs、需要大量的测试用例
  • Bottom-up Integration Testing / 自底向上集成测试
    • 优点：早期发现错误、早期发现设计缺陷、早期发现接口问题
    • 缺点：需要drivers、需要大量的测试用例
  • Sandwich Integration Testing / 三明治集成测试
    • 优点：早期发现错误、早期发现设计缺陷、早期发现接口问题
    • 缺点：需要stubs和drivers、需要大量的测试用例

Big Bang Integration Testing

将整个系统作为一个子系统，在单独的测试session中测试所有的组件和子系统。

Top-Down Integration Testing

介绍：自顶向下集成测试是一种集成测试方法，通过逐步集成和测试系统的各个模块，确保系统的整体功能和性能。

将系统拆解成树形的结构，测试从根节点开始，逐步向下集成和测试各个子系统。

Bottom-Up Integration Testing

Top-Down Integration Testing 的反面。

Sandwich Integration Testing

结合了Top-Down和Bottom-Up集成测试的方法。向下向上同时进行集成测试。

Pros and Cons of Integration Testing / 集成测试的优缺点

  • Props：
    • 直观清晰
    • 使用经过验证的组件进行构建
    • 故障隔离随着集成的单元数量而变化
  • Cons：
    • 功能分解中的一些分支可能与实际接口不对应
    • stub driver 开发是昂贵的

Call Graph-based Integration Testing / 调用图基础集成测试

什么是调用图？

  • 调用图是一个有向图，其中每个节点表示一个方法或函数，每个边表示一个方法调用另一个方法的关系。

Pair-Wise Integration Testing / 成对集成测试

根据定义，调用图中的 edge 指的是作为边端点的单元之间的接口。每条边表示待测试的一堆测试单位。故障隔离定位到正在集成的对。集成测试会话数是边的数。

Neighborhood Integration

  • Neighborhood Integration 是一种集成测试方法，通过在调用图中选择相邻的节点进行集成测试，确保系统的整体功能和性能。

Path-Based Integration Testing / 路径基础集成测试

  • source node：程序执行开始或继续的语句片段
  • sink node：程序执行结束或继续的语句片段
  • module execution path：模块执行路径是从源节点到汇节点的路径。
  • message： 模块之间的消息传递
  • MOdule path：模块路径是从源节点到汇节点的路径。

MM-Path Definition and example

  • MM-Path 是从源节点到汇节点的路径，其中每个模块都可以通过消息传递进行通信。

  • Props：
    • 功能性和结构性的测试集合
    • 与实际系统行为紧密结合
    • 不需要stubs和drivers
  • Cons：
    • 需要大量的测试用例
    • 难以维护和调试

System Testing / 系统测试

什么是系统测试？

  • 系统测试是对整个系统进行测试，以确保系统的整体功能和性能符合预期。
    • 假设所有的组件都已经过单元测试和集成测试，并且可以正常工作。
    • Integration testing已经完成

System Testing Types

  • Functional testing
  • Non-functional testing
  • Regression testing

Function testing

Performance Testing Process

  • 识别自己的测试环境
  • 确定自己的性能验收标准
  • 计划和设计性能测试
  • 配置测试环境
  • 实现测试设计
  • 运行测试
  • 分析、调整和重复测试

Acceptance Testing

验收测试时软件测试的最后阶段，由客户端或者用户进行。验收测试的目的是验证软件是否满足用户的需求和期望。

Bug Report & Test Summary Report

Bug Report

bug报告是描述软件缺陷的文档，它列出了原因和可视的错误，包括如何定位到错误的步骤和如何重现错误的步骤。

好的bug report应该包括什么？

  • 包含复现和修复问题的信息
  • 对于bug报告员和bug接受者，都是一种高效的通行方式
  • 能够被尽快的处理
  • 发送给负责人
  • 以文件的形式存在

Bug Report 重要特性

  • Bug Number / id
  • Bug Title
  • Report Type
  • Serverity
  • Priority
  • Status
  • Assign To
  • Platform / Environment
  • Description

包括Bug的复现步骤、期望结果和实际结果、屏幕截图

Test Summary Report

测试总结报告是对测试活动的总结和评估，包括测试的结果、缺陷的数量和严重程度、测试的覆盖率和测试的效率等。

Automated Software Testing

why we need automated testing

  • 人为的软件测试是slow的、容易出错且难以重复的
  • 软件测试需要快、准确和可重复

What is Automated Testing

这是一种软件测试方法，利用特殊的自动化测试工具，比较测试用例的预期结果和实际结果。

Steps:

  • 在自动化测试中定义目标并制定策略；
  • 选择自动化测试工具来执行测试任务
  • 设置测试环境
  • 开发自动化测试脚本
  • 执行自动化测试脚本、分析测试结果

Pros And Cons of Automated Testing

  • Pros：
    • 支持执行重复的测试用例
    • 帮助测试大型测试矩阵
    • 支持并行测试
    • 鼓励无人执行
    • 提高测试的准确性
    • 节省时间和金钱
  • Cons：
    • 自动化测试工具的成本
    • 在测试应用程序中的用户体验方面不佳
    • 编码知识和经验是必不可少的

什么时候适合人工测试

  • 你有一个短期项目，预算很低；
  • 你需要完成探索性测试；
  • 你将进行临时测试，这通常是未计划的，在这个过程中收集测试见解很重要；
  • 你应该测试应用程序的可用性，并衡量用户体验对最终用户的价值。

什么时候适合自动化测试

  • 你知道项目中特定数量的回归测试；
  • 你应该在负载和压力测试中测试服务器模型和 Web 服务器；
  • 你有一个大型项目，需要测试几个软件功能；
  • 你运行性能测试来检查软件质量属性，如可扩展性、可靠性、速度等。

Software Maintenance / 软件维护

软件测试
This post is licensed under CC BY 4.0 by the author.