本书详细地叙述了当前软件质量保证的技术、方法、原理和构成方面的最新知识,每一章的开始是本章的简介,使读者了解本章要讲述的内容;每一章的结束部分都有评价,对从业人员来说具有实践指导意义。本书在写作上,注重了将理论和实践、软件和硬件、经验知识和教学知识领域的牢固结合,使读者更贴近软件开发这个重要的领域。
本书适合作为高等教育计算机相关专业的教材和教学参考书,也可用作从业人员的参考书。
出版说明
前言
第1章 引言
1.1 动机
1.2 数据和概念的定义
1.3 技术水平
1.3.1 质量管理
1.3.2 软件质量保证
1.3.3 硬件质量安全
1.3.4 软件密集型系统的质量保障
1.4 测试技术的分组与归类
1.4.1 动态测试
1.4.2 静态分析
1.4.3 形式技术:符号测试和形式证明流程
1.5 组织结构 出版说明
前言
第1章 引言
1.1 动机
1.2 数据和概念的定义
1.3 技术水平
1.3.1 质量管理
1.3.2 软件质量保证
1.3.3 硬件质量安全
1.3.4 软件密集型系统的质量保障
1.4 测试技术的分组与归类
1.4.1 动态测试
1.4.2 静态分析
1.4.3 形式技术:符号测试和形式证明流程
1.5 组织结构
第2章 面向功能型测试
2.1 面向功能型测试的属性和目标
2.2 功能性等价类划分
2.2.1 功能性等价类划分的属性和目标
2.2.2 描述功能性等价类划分
2.2.3 评价功能性等价类划分
2.3 以状态为基础的测试
2.3.1 以状态为基础的测试的属性和目标
2.3.2 描述以状态为基础的测试
2.3.3 评价以状态为基础的测试
2.4 原因一效果一分析
2.5 其他面向功能型测试技术
2.5.1 句法测试
2.5.2 以事务流为基础的测试
2.5.3 以判定表格为基础或者以判定树为基础进行测试
2.6 评价面向功能型测试
第3章 面向控制流程的、面向结构的测试
3.1 面向控制流程的测试属性和目标
3.2 指令覆盖测试
3.2.1 指令覆盖测试的属性和目标
3.2.2 描述指令覆盖测试
3.2.3 评价指令覆盖测试
3.3 子项覆盖测试
3.3.1 子项覆盖测试的属性和目标
3.3.2 描述子项覆盖测试
3.3.3 子项覆盖测试的问题
3.3.4 评价子项覆盖测试
3.4 条件覆盖测试
3.4.1 条件覆盖测试的属性和目标
3.4.2 简单的条件覆盖测试
3.4.3 条件/判定覆盖测试
3.4.4 最小多重条件覆盖测试
3.4.5 修正条件/判定覆盖测试
3.4.6 多重条件覆盖测试
3.4.7 问题
3.4.8 评估条件覆盖测试
3.5 测试循环的技术
3.5.1 属性和目标
3.5.2 结构化路径测试和边界一内部路径测试
3.5.3 LCSAJ测试
3.6 路径覆盖测试
3.6.1 路径覆盖测试的属性和目标
3.6.2 评价路径覆盖测试
3.7 评价面向流程控制的测试
第4章 数据流型、面向结构型测试
4.1 数据流型测试的属性和目标
4.2 定义/用途测试
……
第5章 特殊的动态测试技术
第6章 软件测量
第7章 利用工具进行静态代码分析
第8章 软件验证与复审
第9章 形式技术:符号测试和形式正确性证明
第10章 过程和测试策略
第11章 工具
第12章 测试面向对象型软件
第13章 测试嵌入软件
第14章 实践指南
参考文献
第1章 引言
每个开发软件的企业都努力提供最佳质量的软件。只有精确定义了一个目标,我们才能切实地实现这个目标,但这个道理却并不适用于“最佳质量”的概念。软件质量是涉及多方面的。一个软件的多种性能共同构成软件的质量。这些性能对使用者和制造商而言并非同等重要。一些性能对特定的软件产品特别重要,其他性能对相同的软件产品则毫无关系。一些性能相互发生负面作用。有人说,我们要做出质量最好的软件,显然是没有理解软件质量的含义。开发软件的目的不在于实现最好的质量,而是最合适的质量。为此,需要确定所谓的质量目标来制定所需的软件质量。随后,人们可以决定,采用何种方式来达到确定的质量。一般来说,必须采用设计上有前瞻性、经过分析检验的技术与组织管理方面的手段相结合。在实现质量的过程中,重要的是考虑到经济性,即一定不要忘记时间和成本两个要素。不同软件产品的多样性,造成了对软件质量的不同要求,加上时间和成本,导致人们无法找出万能的解决方案。本章将分门别类地为您介绍软件质量管理和软件质量保证的各种组织上和技术上的解决方案。
1.1 动机
随着计算机越来越深入人类生活的各个应用领域,其软件功能的正确性、可靠性也越来越重要。成本的发展表明,和硬件成本相比,软件成本明显呈上升趋势,同时,软件使用寿命也明显长于硬件。所以,在软件开发领域缩减成本是十分经济的做法。如果根据软件生命周期来分析软件开发的成本,则其结果是市场上某个软件产品的大部分成本在维护阶段产生,也就表明软件质量不够理想。在制作软件时产生的错误,和使用软件时发现的错误是导致软件质量不完善的原因。如果一个软件产品结构不清晰,内容不够简洁明了,要修正错误则是一件耗费时间的重任。软件产品日渐增强的复杂性同样也增加了软件质量不完善的可能性。要将错误本地化,并消除错误很难,特别是结构上有欠缺的软件,修正的错误可能会带来其他错误,因为对某一处的修改会与软件的其他部分相互作用。如果某个错误的形成原因已经在软件开发的早期阶段出现,比如在定义要求的时候或者设计软件的时候,那么必须进行大量的变动。
……