[NCRE2017整理]软件测试的基本概念

本文档由[NCRE2017软件测试考试书籍]整理

---

1. 软件质量的概念

软件质量，是贯穿软件生命周期的一个极为重要的问题，是软件开发过程中所使用的各个开发技术和验证方法的最终体现。因此，在软件生命观周期中要特别重视质量的保证，已生成高质量的软件产品。

我国的国家标准GB/T 11457——2006《软件工程属于》定义软件的质量为：

1. 软件产品中能满足给定需要的性质和特性的总体，例如：符合规格说明。
2. 软件具有所期望的各种属性的组合程度。
3. 顾客和用户觉得软件满足其综合期望的程度。
4. 确定软件在使用中将满足顾客预期需求的程度。

2. 软件质量模型

   3. 影响软件质量的因素

1. 开发软件的组织
2. 开发过程
3. 开发过程中所使用的方法和技术

具体的开发角度：

1. 开发方法和工具
2. 开发人员的训练水平
3. 软件开发的组织形式
4. 文档的提供：源代码中的文档、软件开发所需的文档：配置管理计划、质量保证计划、软件开发计划、软件测试计划。
5. 复杂性：结构和功能的复杂性。
6. 环境：终端用户的实际使用环境以及对环境建模的难易程度。具体的环境因素：软件、硬件与人之间的接口；用户的培训；输入数据的确认。
7. 现有的软件原型：概念构想、需求分析、设计阶段所创建的原型
8. 需求的转换和可跟踪性
9. 测试方法：独立的验证和确认技术；责任分配；专职的开发、测试和编码；不独立的测试。
10. 维护活动
11. 计划和资源
12. 更高级的语言
13. 现有的类似软件
14. 影响软件的质量属性：可维护性、可复用性、安全性、容错性、保密性、精度、灵活性、性能、用户友好性等。

4. 软件测试的定义

1990年IEEE在其IEEE 610.12标准中给出的较正式的定义为：

1. 在规定条件下运行系统或构件的过程——在此过程中观察和记录结果，并对系统或构件的某些方面做出评价。
2. 分析软件项目的过程——在此过程中检测现有状况和所需状况之间的不同（即bug），并评估软件项目的特性。

5. 软件测试的目的

软件测试是为了保证软件质量，通过修正各种错误和缺陷提高软件质量，规避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

6. 软件测试的原则

1. 应当把“尽早地和不断地进行软件测试”作为软件开发人员的座右铭。
2. 测试用例应由测试输入数据和与之对应的预期输出结果两部分组成。
3. 程序员应避免检查自己的程序。
4. 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
5. 充分注意测试中的群集现象。
6. 严格执行测试计划，排除测试的随意性。
7. 应当对每一个测试结果做全面检查。
8. 妥善保存测试计划、测试计划、出错统计和最终分析报告，以便为以后的回归测试及维护提供方便。

7. 软件缺陷的定义

IEEE标准729中IEEE 1983 对缺陷有一个标准定义：

1. 从产品内部看，缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。
2. 从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

8. 软件缺陷的类型

1. 软件没有实现产品规格说明书所要求的功能。
2. 软件中出现了产品规格说明指明不应该出现的错误。
3. 软件实现了产品规格说明没有提到的功能。
4. 软件没有时间虽然产品规格说明没有明确提及但应该实现的目标。
5. 软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。

9. 软件缺陷的级别

1. 致命的（Fatal）：造成系统或应用程序崩溃、死机、系统悬挂，或造成数据丢失、主要功能完全丧失等。
2. 严重的（Critical）：功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。
3. 一般的（Major）：不太严重的错误，虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期效果。（如次要功能丧失，提示信息不准确、用户界面差、操作时间长等）
4. 微小的（Minor）：对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不正确等。

10. 软件缺陷的状态

1. 活动状态（Active或Open）：问题没有解决，测试人员新报告的缺陷，或者验证后缺陷仍然存在。
2. 已修复状态（Fixed或Resolved）：开发人员针对已存在的缺陷，修改程序，认为已经解决，或者通过单元测试。
3. 非活动状态（Close或Inactive）：测试人员验证已修正的缺陷，确认缺陷不存在之后的状态
4. 保留状态（Hold）：目前无法解决或是第三方引起的缺陷。
5. 不一致状态（Differed）：暂时不需要解决或下个版本解决更好写的缺陷。

11. 缺陷产生的原因

1. 技术问题
2. 团队工作
3. 软件本身

12. 软件缺陷的构成

1. 功能缺陷

1. 规格说明书缺陷
2. 功能缺陷
3. 测试缺陷
4. 测试标准引起的缺陷

2. 系统缺陷

1. 外部接口缺陷
2. 内部接口缺陷
3. 硬件结构缺陷
4. 操作系统缺陷
5. 软件结构缺陷
6. 控制与顺序缺陷
7. 资源管理缺陷

3. 加工缺陷

1. 算术与操作缺陷
2. 初始化缺陷
3. 控制和次序缺陷
4. 静态逻辑缺陷

4. 数据缺陷

1. 动态数据缺陷
2. 静态数据缺陷
3. 数据内容、结构和属性缺陷

5. 代码缺陷

包括数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入/输出错、以及其他的错。

13. 修复软件缺陷的代价

测试人员要在软件开发的早期，如需求分析阶段就介入，问题发现的越早越好。
如果在需求阶段修正一个错误的代价是1，那么在设计阶段就是它的3-6倍，在编程阶段是它的10倍，在内部测试阶段是它的20-40倍，在外部测试阶段是它的3–70倍，而产品发布出去时，就是40-1000倍。

14. 软件测试的心理学

1. 程序测试的过程具有破坏性
2. 程序员应避免测试自己的程序
3. 程序设计组织不应测试自己的程序

15. 软件测试的经济学

为了应对测试经济学的跳转，应该在开始测试之前建立某些策略。黑盒测试和白盒测试是两种最普遍的策略：

1. 黑盒测试：数据驱动的测试或输入/输出驱动的测试。将程序视为一个黑盒子，测试目标与程序内部机制和结构完全无关，而是将重点集中放在发现程序不按其规格说明正确运行的环境条件。
2. 白盒测试：逻辑驱动的测试，这种策略通过对程序的逻辑结构进行检查，从中获取测试数据。

程序测试只能证明错误的存在，但不能证明错误不存在。
为了降低测试成本，选择测试用例应注意遵守“经济性”原则：

1. 要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级。
2. 要认真研究测试策略，以便能使用尽可能少的测试用例，发现尽可能多的程序错误。

需要做多少测试的影响因素：

1. 系统的目标（控制密封燃气管道的系统>游戏软件）
2. 潜在的用户数量（几千级用户>j几个用户）
3. 信息的价值（银行系统>音像店系统）
4. 开发组织（没有标准、缺少经验的组织）
5. 测试的时机（存在于市场几年的产品，产品的质量变得更重要了）

16. 软件质量保证活动的实施

Target：设定质量特性与质量子特性的评价标准。
Plan：与组织的软件过程组（SEPG）和项目管理人员合作，参与制定项目的软件过程，包括如何划分开发阶段、分解任务、定义过程活动（人员、任务、中间产品、工作流）。
Do：在软件开发过程中，参与各个活动的评审和阶段的正式技术评审。
Check：以Plan阶段确定的质量度量标准进行评价。
Action：对评价发现的问题进行改进活动，如果实现并达到了质量目标就转入下一个开发阶段。

17. 软件的验证与确认任务分析

主要活动包括：关键性分析、可跟踪性分析、评审、接口分析、测试。
评审方法包括3种：

1. 静态分析规格说明（如审查、检查、结构分析等）。
2. 动态分析软件行为（如模拟、建模、屏幕仿真、分支执行分析等）。
3. 形式化分析（如数学校对）。