软件测试理论知识

软件测试理论基础

一.什么是软件

1.1软件的定义

程序 数据 文档的完整集合

1.2软件和程序的区别

软件=程序+数据+文档

1.3软件的分类

按层次：

系统软件（在硬件之上）

例如：操作系统

支持软件（便于操作计算机）

例如：计算机管理类工具

应用软件（常用）

例如：游戏娱乐软件

按适用范围：

单机版软件（不需要和其他计算机进行交互）

分布式软件（需要多台计算机进行协同工作）

1.4软件的特性

1. 一种逻辑实体 抽象性
2. 主要是开发和研制 再复制产生大量软件
3. 无磨损老化的问题
4. 对硬件环境有不同程度的依赖性 导致软件移植的问题
5. 手工作坊式的研发方式 效率低
6. 复杂 越来越复杂
7. 成本昂贵

二.软件危机和软件工程

2.1软件危机

定义

开发 维护过程中遇到的一系列严重问题

包含

如何开发软件满足日益复杂的需求

如何维护数量不断膨胀的软件产品

典型表现

1. 软件开发的成本和进度不准确
2. 客户不满意已完成的软件系统
3. 软件产品的质量不靠谱
4. 软件常常不可维护
5. 软件通常没有适当的文档资料
6. 软件成本在计算机系统总成本中所占的比例逐年上升
7. 提高的速度跟不上硬件的发展速度和计算机应用的普及速度

产生的原因

1. 忽视软件开发前期的调研和需求分析工作
2. 缺乏软件开发的经验和有关软件开发数据的积累，使得开发计划很难制定
3. 开发过程缺乏统一的、规范化的方法论指导
4. 忽视与用户、开发组成员间的及时有效的沟通
5. 文档资料不规范或不准确，导致开发者失去工作的基础，管理者失去管理的依据
6. 没有完善的质量保证体系

2.2软件工程

定义

研究怎么用系统化、规范化、数量化等工程原则和方法去进行软件的研发和维护

包含

2.2.1软件研发技术

1. 软件研发方法学
2. 软件工具
3. 软件工程环境

2.2.2软件项目管理

1. 软件度量
2. 项目估算
3. 进度控制
4. 人员组织
5. 设置管理
6. 项目计划

三.软件测试的产生和意义

3.1背景

3.1.1程序规模的爆炸式增长

1. 程序代码规模显著增大
2. 结构算法更复杂
3. 程序模板间接口增多

3.1.2寻找程序员和用户需求间的平衡点

程序员的关注点

设计需求

技术内涵

用户的关注点

满足自身特定的需求

3.2意义

1. 工作量方面
2. 解放程序员 售后人员
3. 软件测试的过程角度
4. 推动了软件工程的发展 使软件的质量得到阶段性提升

3.3定义

使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别

3.4重要性

对生活带来破坏和经济损失

3.5流程

1. 制定测试计划
2. 设计测试用例
3. 实施测试
4. 提交缺陷报告
5. 测试总结

四.软件测试的目的和原则

4.1目的

1. 确保产品完成了它所承诺或公布的功能且用户可以访问到的功能都有明确的书面说明。
2. 确保产品满足性能和效率的要求
3. 确保产品是健壮的和适应用户环境（兼容性）

4.2原则

1. 应尽早执行
2. 应贯穿于整个软件生命周期
3. 参与审评 审核相关文档
4. 需求阶段引入的缺陷最多
5. 应追溯需求（需求说明书）
6. 应由第三方来构造（测试或者外包）
7. 穷举测试是不可能的
8. 遵循good enough原则：不要做过多 也不必要做不充分的测试
9. 必须确定预期结果（作为基准）
10. 必须彻底检查每个测试结果
11. 充分注意测试中的群集现象

4.3其他注意的规律和经验

• 缺陷的二八定理
• 严格执行测试计划，排除测试的随意性
• 注意合法合理的输入，也要注意非法的非预期的输入
• 检查程序是否做了不该做的
• 测试应从“小规模”开始，逐步转向“大规模”
• 反复使用同样的测试会使软件具有抵抗力 （杀虫剂悖论）
• 关注缺陷的修复
• 测试活动依赖于测试背景

五.软件测试的现状与发展

5.1现状

• 处于发展阶段
• 目前还是以手工为主

5.2前景发展

国内外软件企业越来越重视软件测试

发展的原因

• 市场竞争的压力
• 不断提升的客户需求
• 整个行业逐渐的规范
• 用户基数水平的提升

5.3软件测试思维模型

正向测试

• 测试是验证软件的正确性

逆向测试

• 测试是发现软件中的缺陷bug

六.测试人员的必备素质

• 责任心
• 沟通能力
• 团队合作意识
• 耐心 细心 信心
• 保持怀疑态度 缺陷预防意识
• 具备一定的编程经验

七.软件缺陷

7.1缺陷的识别

1. 不符合设计要求
2. 不满足用户确定需求

注意：

• 有些问题看似错误但不是缺陷
• 有些问题看似正确但确是缺陷

7.2产生缺陷得原因

• 人员之间交流不够
• 需求不断变化
• 文档不完善
• 参与人员的过度自信
• 程序设计本身有错误
• 工期短 任务重 时间压力大
• 软件复杂性
• 软件开发工具或系统软硬件本身有缺陷

7.3判断发现的问题是否是缺陷的方法

• 通过参考文档来确认缺陷
• 通过了解软件产品的行业背景（或参考同类型典型软件）
• 通过沟通来确认识别

7.4再现与优化缺陷

再现（重现）与优化缺陷的必要性

为什么要再现与优化缺陷（优化缺陷的再现步骤）

关于软件中“随机”出现的缺陷

7.5怎样有效记录缺陷

• 保证重现缺陷
• 分析故障——使用最少步骤重现缺陷
• 包含所有重现的必要步骤
• 方便阅读
• 尽量简单——一个缺陷一个报告
• 注意自己的语气

值得注意的经验：

• 报告不能重现的缺陷
• 不能夸大缺陷
• 小缺陷（甚至建议）也要报告
• 及时报告缺陷
• 引用别人的报告时，最好不要修改，可以添加批注之类的补充评论

7.6缺陷报告的用途

• 记录缺陷
• 不是所有的缺陷都会被修复
• 缺陷分类
• 缺陷跟踪

7.7缺陷的分类

1.按问题引出不同

2.按功能模块

3.按缺陷的严重程度

•     影响进度的问题
•     死机
•     功能问题
•     界面问题
•     建议

4.按修复缺陷的优先级

•     应立即修复的问题
•     在产品发布之前必须修复的问题
•     如果时间允许应该修复的问题
•     可以在发布版本中存在的问题

备注：

缺陷的严重程度和优先级各软件公司可根据实际情况自行确定

7.8缺陷报告的分类

1.按缺陷所处状态分类

• 待确认的
• 新提交的
• 已分配的
• 问题未解决的
• 待返测的
• 已关闭的

2.按处理意见分类

• 已解决的
• 不是问题
• 无法修复
• 延迟解决
• 重复bug
• 无法复现

7.9缺陷报告的处理流程

1. 提交缺陷报告
2. 分配缺陷报告
3. 处理缺陷报告
4. 反测报告
5. 关闭缺陷报告

7.10关于处理缺陷

• 注意缺陷报告的处理成本
• 修改缺陷要量力而行
• 关注被推迟修改的缺陷
• 如果决定据理力争就一定要赢

八.软件质量

8.1定义

软件质量特性的总和，软件满足规定或潜在用户需求的能力。简单的说，软件质量就是客户的满意度

8.2组成部分

软件产品的质量，即满足使用要求的程度（软件质量特性）

软件开发过程的质量，即能否满足开发所带来的成本、时间和风险等要求（CMM、ISO9000）

8.3软件测试与软件质量

8.3.1软件测试与软件过程的关系

过程决定质量，软件过程决定软件质量，软件质量是在软件开发过程中逐渐建立起来的。

软件过程的优劣决定了软件质量的高低，好的过程是高效高质量的前提。人员和过程是决定软件质量的关键因素，高质量的人员和好的过程应该得到好的产品

在软件过程中注意把握测试的对象

软件测试在软件生存周期中占有非常重要的位置，是对软件规格说明、设计和编码的最后终审

8.3.2软件测试与软件质量的关系

软件测试是软件质量保证的重要手段，是规约、设计和编码的最终检查

8.4正确认识软件测试

软件的质量不是靠测出来的

软件测试真的比开发容易么 ？不是

• 测试人员发现缺陷是测试的初步，还要分析定位缺陷；而且测试人员需要发现潜在的难以被发现的缺陷
• 测试人员需要开发测试工具和自动测试脚本
• 测试人员必须精通整个业务
• 软件测试需要开发与测试人员的共同努力
• 破坏性、建设性（角度不同）

8.4.1软件质量特性

• 功能性40%

软件在指定条件下使用时，满足用户明确和隐含需求的功能的能力

适合性：软件是否提供了相应的功能

准确性：软件提供的功能是否正确（用户需要的）

互操作性：产品与产品之间交互数据的能力，例如word对其他文档的支持能力

安全性：允许经过授权的用户和系统能够正常的访问相应的数据和信息，禁止未授权的用户访问等  

功能性的依从性：软件遵循与功能性相关的标准、约定或法规以及类似规定的能力。这些标准要考虑国际标准、国家标准、行业标准、企业内部规范等

• 可靠性5%

软件在指定条件下使用时，维持规定的性能级别的能力。平均故障修复时间（mean time to repair，MTTR）、平均无故障时间（mean time between failures，MTBF） 

• 易用性15%

软件在指定条件下使用时，维持规定的性能级别的能力。平均故障修复时间（mean time to repair，MTTR）、平均无故障时间（mean time between failures，MTBF） 

• 效率30%

在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力

• 可维护性5%

软件可被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规格说明变化的适应

• 可移植性5%

软件从一种环境迁移到另一种环境的能力

质量管理体系

1. ISO
2. CMM

• 初始级（等级1）：软件过程的特点是无秩序的，偶尔甚至是混乱的。几乎没有什么过程是经过定义的，成功依赖于个人的努力
• 可重复级（等级2）：已建立基本的项目管理过程去跟踪成本、进度和功能性。必要的过程纪律已经就位，使具有类似应用的项目，能重复以前的成功。
• 已定义级（等级3）：管理活动和工程活动两方面的软件过程均已文档化、标准化、并集成到组织的标准软件过程。全部项目均采用供开发和维护软件的组织标准软件过程中的一个经批准的剪裁本。
• 已管理级（等级4）：已采集详细的有关软件过程和产品质量的度量。无论软件过程还是产品均得到定量了解和控制。
• 优化级（等级5）：利用来自过程和来自新思想、新技术先导性试验的定量反馈信息、使持续过程改进成为可能

1. CMMI