软件测试基础理论

软件缺陷

• 软件缺陷的定义
  对软件产品属性的偏离现象
  • 软件错误
  • 功能遗漏
  • 性能不符合要求
  • 设计产品缺陷
• 软件缺陷与软件错误的区别
  • 软件缺陷包含软件错误
  • 软件错误必须被修正，但软件缺陷不一定
  • 软件错误仅指软件代码本身的问题

软件测试

• 为什么要进行软件测试
  • 软件总存在缺陷，只有通过测试，才可以发现软件缺陷。也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。
  • 软件中存在的缺陷给我们带来的损失是巨大的，这也说明了软件测试的必要性和重要性。
• 测试和调试的区别
  • 测试：找错误（证明程序有错）
  • 调试：改错误（使程序正确）
• 软件测试的定义
  • Myers认为：“软件测试是为了发现错误而执行程序的过程。”明确提出 “寻找错误”是测试的目的。
  • 1983年IEEE对软件测试的定义：“使用人工或自动手段运行或测定某个系统的过程，其目的在于检测它是否满足规定的需求或是弄清楚预期结果与实际结果之间的差别。”明确地提出软件测试以检验是否满足需求为目的。
  • 从软件质量保证的角度看：软件测试是一种重要的软件质量保证活动。测试过程中的活动包括“分析”软件和“运行”软件。也有人认为软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
• 软件测试辩证统一的观点
  • 测试是为了证明程序有错，而不是证明程序无错。
  • 一个好的测试用例在于发现了至今没有发现的错误。
  • 一个成功的测试是发现了至今未发现的错误。
• 软件的定义
  软件=程序+数据库+文档+服务
• 软件测试并不等于程序测试
  软件测试贯穿于软件定义和开发的整个期间。
• 软件测试的对象
  • 需求规格说明（系统测试）
  • 概要设计规格说明（集成测试）
  • 详细设计规格说明（单元测试）
  • 源程序
• ANSI/IEEE STD729给出了软件质量定义
  • 软件产品满足规定的和隐含的与需求能力有关的全部特性和特征。
  • 软件产品质量满足用户要求的程度。
  • 软件各种属性的组合的程度。
  • 用户对软件产品的综合反映的程度。
  • 软件在使用过程中满足用户要求的程度。
• 软件测试最致命的缺陷就是：不能进行彻底的测试。
• 软件不可能做到“零缺陷”的原因
  • 测试覆盖率不可能穷尽。
  • 改正现有的缺陷可能会产生新的缺陷。
  • 测试工程师对产品的理解与用户的需求存在差异。
  • 测试的环境不一致。

软件产品特性

• 正确性
  在预定环境下，软件满足设计规格说明及用户预期目标的程度。它要求软件本身没有错误。
• 可靠性
  软件按照设计要求，在规定时间和条件下不出故障，持续运行的程度。
• 效率
  为了完成预定功能，软件系统所需的计算机资源的多少。
• 完整性
  为某一目的而保护数据，避免它受到偶尔的或有意的破坏、改动或遗失的能力。
• 可使用性
  对于一个软件系统，用户学习、使用软件及为程序准备输入和解释输出所需工作量的大小。
• 可维护性
  为满足用户新的要求，或当环境发生了变化，或运行中发现了新的错误时，对一个已投入运行的软件进行相应的诊断和修改所需工作量的大小。
• 可测试性
  测试软件以确保其能够执行预定功能所需工作量的大小。
• 灵活性
  修改或改进一个已投入运行的软件所需工作量的大小。
• 可移植性
  将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需的工作量大小。
• 可复用性
  一个软件（或软件的部分）能再次用于其他应用（该应用的功能与此软件或软件部分的所完成的功能有关）的程度。
• 互联性
  又称互相操作性。连接一个软件或其他系统所需工作量的大小。如果这个软件要联网或与其他系统通信或要把其他系统纳入到自己的控制之下，必须有系统间的接口，使其可以连接。

软件测试的原则

• 所有的测试都应追溯到用户的需求
  • 系统中最严重的错误就会那些导致程序无法满足用户需求的错误。
• 尽早地和不断地进行软件测试
  • 需求和设计时出现的缺陷占很大的比例。
  • 缺陷的修改成本随着阶段的推移将急剧上升。
  • 缺陷具有放大的特点。
• 不可能完全的测试
  • 输入量太大
  • 执行路径太多
• 80-20原则
  • 测试发现的错误中80%很可能起源于20%的模块中。应孤立这些疑点模块重点测试。
• 注意测试中的群集现象
  • 在所测程序段中，若发现错误数多，则残存错误数目也比较多。
• 避免测试自己的程序
  • 程序员轻易不会承认自己写的程序有错误。
  • 程序员的测试思路有局限性，做测试时很容易受到编程思路的影响。
  • 程序员测试不具有典型性。
• 设计周密的测试用例
  • 设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
• 回归测试
  • 程序修改后必须进行回归测试，避免引入新的错误。
• 严格执行测试计划，排除测试的随意性。
• 确认BUG的有效性
  • 对测试错误结果一定要有一个确认过程。
  • 有时候测试人员提交的BUG不是真的BUG。
• 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

软件测试分类

• 按是否执行程序分类
  • 静态测试
    不运行被测程序，而是通过在对软件进行分析、检查和审阅达到测试目的。
  • 动态测试
    通过运行软件来检验软件的动态行为和运行结果的正确性，一般包括白盒测试、黑盒测试和灰盒测试技术三类。
• 按测试技术分类
  • 灰盒测试
    介于白盒测试与黑盒测试之间的测试。
  • 黑盒测试
    将测试对象看成一个黑盒子，只在程序界面处进行测试，对接口进行测试，检查是否满足需求规格说明书。
  • 白盒测试
    结构测试，将程序看成一个透明的白盒子，检查所有的
• 按测试阶段分类
  • 单元测试
    又称模块测试，目的在于检查每个单元模块是否实现详细设计说明书中的功能、性能、接口和设计约束等要求。
  • 集成测试
    又称组装测试，主要测试单元之间的接口关系，逐步集成为符合概要设计说明书要求的整个系统。
  • 系统测试
    在真实或模拟系统运行的环境下，为验证和确认系统是否达到需求规格说明书的要求，而对集成的硬件和软件系统进行的测试，采用黑盒测试技术。
  • 验收测试
    按照项目任务书或合同、供需双方约定的验收依据文档进行的整个系统的评测，决定是否接受系统。
• 按照测试实施组织分类
  • 开发方测试（α测试）
    开发方在软件开发的环境下，证实软件的实现是否满足需求。
  • 用户测试（β测试）
    用户通过运行和使用软件找出软件使用过程中发现的软件缺陷。
  • 第三方测试
    介于开发方和用户之间的测试组织的测试。
• 按是否使用工具划分
  • 手工测试
  • 自动化测试