软件测试与维护期末复习——Chapter 1 Introduction


1. Why do we test software?

1.1 什么是软件?

  1. 软件系统的组成

    1. 指令:独立程序中的指令,执行后能实现预期功能(也就是代码)

    2. 数据结构:让程序能正确处理信息的数据结构

    3. 配置文件:设置程序的配置文件

    4. 系统文档:描述系统结构的系统文档

    5. 用户文档:解释系统使用方法的用户文档,和供用户下载最新产品信息的网站

  • 软件工程危机(1970s)

    • 超预算

    • 延期

    • 质量差

    • 不满足需求

    • 混乱

    • 维护困难

  • 21世纪软件的特点

    1. 软件定义了基础设施行为(以前是硬件决定)

      • 服务器

      • 存储

      • 网络路由器

      • 交换网络

      • 其他基础设施

    2. 嵌入式控制软件无处不在(软件在专用硬件设备中且控制硬件)

      • 飞机,空中交通管制

      • 宇宙飞船

      • 手表

      • 烤箱

      • 遥控器

    3. 敏捷开发大幅提升测试员保障质量的压力

1.2 什么是bug?

Bug是非正式表述,包括:

Defect, Fault, Problem, Error, Incident, Anomaly, Variance, Failure, Inconsistency, Product Anomaly, Product Incidence, Feature

缺陷、故障、问题、错误、事件、异常、差异、失效、不一致、产品异常、产品事件、特性

1.3 Fault, Error, Failure

1. 定义

  1. Fault(故障):软件中的静态缺陷

  2. Error(错误):一个不正确的内部状态,是fault的表现形式

  3. Failure(失效):外部可见的不符合预期的行为

Fault(问题根源) → Error (中间态)→ Failure(最终表现)

举个例子

医生发现病因->Fault

医生检测到异常的指标(如血压高)->Error

病人描述症状->Failure

1.3.2 PIE模型

Failure触发的必要条件

  1. Execution(执行):测试用例执行到缺陷代码Fault

  2. Infection(感染):执行后产生内部错误状态Error(比如中间计算出的某个变量值错了)

  3. Propagation(传播):错误传播到输出,形成 Failure

Execution 执行(Fault)->Infection 感染(Error)->Propagation 传播(Failure)

例子:设计测试用例

  1. T1 执行故障,但没有错误

  2. T2 执行故障且产生错误,但是没有失效

  3. T3 出现失效

alt text

1.4 故障软件的不良影响(略)

2. The theory of Testing

2.1 验证(Verification)与确认(Validation)

  1. 验证:判定软件开发各阶段的产物是否满足上一阶段设定的要求

  2. 确认:开发结束时评估软件是否符合预期用途

  3. IV&V:独立验证与确认,由第三方独立团队执行,保证客观公正

  4. 规范(Specifications):必须描述正确行为和错误行为

2.2 软件测试公理(Axioms)

  1. 无法完全测试一个程序

    • 原因:输入 / 输出 / 执行路径数量极大、规格难以绝对完整正确。

    • 结论:穷尽测试不可能,只能选取代表性用例。

  2. 软件测试是基于风险的活动

    • 不做穷尽测试必然会承担风险。

    • 风险包括:经济损失、安全事故、人员伤亡。

    • 测试目标:用合理成本降低风险。

  3. 测试无法证明 bug 不存在

    • 名言 (Dijkstra):测试只能证明bug 存在,永远无法证明无 bug。
  4. 发现的 bug 越多,剩余 bug 越多

    • 原因:bug 扎堆出现;程序员易重复犯错;bug 是冰山一角。

    • 杀虫剂悖论:测试用例用久了,软件会 “免疫”,需持续更新测试用例。

  5. 并非所有发现的 bug 都会被修复

    • 不修复原因:工期不足;不是真 bug;修复风险太高;修复性价比低。
  6. 难以判定是否为 bug

    • 潜伏 bug (latent bugs):未被任何人发现的缺陷,依然属于 bug。

    • 判定:bug 不依赖是否被观察到,代码缺陷本身就是 bug。

  7. 规格说明永远不会定稿

    • 软件特性:迭代快、易修改、竞争激烈,需求持续变动。

    • 对比传统工程(如桥梁):施工后无法随意修改,软件可动态调整。

  8. 测试员不是项目最受欢迎的角色

    • 核心职责:找 bug、尽早找 bug、推动 bug 修复。

    • 避免被讨厌的技巧:尽早发现 bug、专业沟通、不只反馈负面信息。

  9. 软件测试是严谨的技术职业

    • 从非专业手工测试,进化为有技术、有工具、专业化的职业。

2.3 测试员的目标

  1. 发现 bug

  2. 尽可能早地发现 bug

  3. 确保 bug 被修复

注:测试目标不是消灭所有 bug


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值