软件测试基本概念及方法

1. 软件质量和软件测试的含义

1.1 软件质量的内涵

软件质量是客户满意度的体现

质量是系统、部件或过程满足

1. 明确需求
2. 客户或用户需要或期望的程度不同      IEEE <<Standard Glossary of Software Engineering Terminology>>

• 软件质量：软件产品具有满足 规定的或隐含要求能力要求有关的特征与特征总和(ISO 8492)　

• 软件质量：软件产品满足使用要求的程度

1.2  软件测试的概念

• 是为了发现错误而执行程序的过程。
• 应关心程序的效率和鲁棒性等因素。
• 检验软件是否满足规定的需求。
• 弄清预期与实际结果之间的差别。

备注：所谓“鲁棒性”，是英文“robust”的译音，指强壮、健壮的意思。软件的“鲁棒性”，是指系统在一定条件下维持某些性能的特性，简单地说，就是适应各种各样的变化的能力。鲁棒性越强，系统精确度就愈高，性能越好。 

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

软件测试活动一般包含：

• 制订测试计划
• 设计测试用例
• 实施测试
• 提交缺陷报告
• 测试总结 

1.3   软件质量范围-3A

• Accountability (可说明性) – 用户可以基于产品或服务的描述和定义进行使用. (例如: 市场需求说明书, 功能设计说明书.)
• Availability (有效性) – 产品或服务对于99.999% 客户总是有效的   (例如: 性能测试和恢复测试)
• Accessibility (易用性) – 对于用户, 产品或服务非常容易使用并且一定是非常有用的功能 . (例如: 确认测试和用户可用性测试)   

1.4  高质量软件

应该是相对的无产品缺陷(Bug Free)或只有极少量的缺陷, 它能够准时递交给用户并且所用的费用都是在预算内的并且满足客户需求，是可维护的。但是, 有关质量的好坏最终评价依赖于用户的反馈。


“客户”广义定义 :
内在的定义 : 下一个环节/工序的接收者，更广的服务的对象，周围有任何联系或影响的团队、人。
软件的设计者，程序的检测者，项目管理者，品质管理人员 …
  广泛的定义 : 最终用户，客户管理

1.5  软件质量的不同的视点

• 先验论观点：质量是产品一种可以认识但不可定义的性质
•  用户观点：质量是产品满足使用目的之程度;
•  制造者的观点：质量是产品性能和规格要求的符合度
•  产品观点：质量是联结产品固有性能的纽带;
•  基于价值观点：质量依赖于顾客愿意付给产品报酬的数量

1.6  高质量软件标准体系

产品质量

是人们实践产物的属性和行为，是可以认识，可以科学地描述的。并且可以通过一些方法和人类活动，来改进质量.
 质量模型:  McCall 模型, Boehm 模型, ISO 9126 模型

过程质量: 

  软件能力成熟度模型 CMM ( Capability Maturity Model).
  国际标准过程模型 ISO 9000
  软件过程改进和能力决断  SPICE ( Software Process Improvement and   Capability dEtermination)

在商业过程中有关的质量内容: 

    培训、成品制作、宣传、发布日起、客户、风险、成本、业务等   

1.7  产品质量的标准

- 功能性 Functionality
- 可用性 Usability (简单安装; 轻松使用; 友好界面)
- 可靠性 Reliability (用户使用的根本)
- 性能 Performance
- 容量 Capacity
- 可测量性 Scalability
- 可维护性 Service manageability
- 兼容性 Compatibility
- 可扩展性 Extensibility

1.8  软件质量特征（ISO9126）

•  功能：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。
•  可靠：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。
•  易用：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。
•  效率：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
•  可维护：与进行指定的修改所需的努力有关的一组属性。
•  可移植：与软件从一个环境转移到另一个环境的能力有关的一组属性。 其中每一个质量特征都分别与若干子特征相对应。

1.9  软件过程质量

• 软件能力成熟度模型 CMM ( Capability Maturity Model).
• 国际标准过程模型 ISO 9000
• 软件过程改进和能力决断 SPICE ( Software Process Improvement and Capability dEtermination) 

1.9.1    质量保证的策略

主要分三个阶段：

1.  以检测为重：产品制成之后进行检测，只能判断产品质量，不能提高产品质量。
2.  以过程管理为重：把质量的保证工作重点放在过程管理上，对制造过程 中的每一道工序都要进行质量控制。
3.  以新产品开发为重：在新产品的开发设计阶段，采取强有力的措施来消灭由于设计原因而产生的质量隐患。

1.9.2  全面质量管理

TQM = Total Quality Management 全面质量管理

•   TQM是为了能够在最经济的水平上，并考虑到充分满足用户要求的条件下进行市场研究、设计、生产和服务，把企业内各部门研制质量、维持质量和提高质量的活动构成为一体的一种有效体系
•  TQM内容: 

1.   全员参与质量管理
2.  全过程质量管理。

•  TQM的4个关键要素:

1. 关注客户
2. 过程改进
3. 质量的人性化因素
4. 度量(即模型的测量和分析)

1.9.3  质量管理发展五个阶段

2.软件缺陷（Bug）是什么?

2.1  软件缺陷的含义

任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求

2.2  问题出在哪？

• 项目没有被很好地理解；计划不周，最终导致进度拖延。
• 没有充分的文档资料。
• 人与人的交流比写程序困难得多。
• 软件可靠性缺少度量的标准，质量无法保证。
• 软件难以维护、不易升级。

2.3  解决问题的想法

•  Better management 管理
•  Different team organizations 组织
•  Better languages & tools 语言和工具
•  Uniform coding conventions 编程惯例

必须意识到：“软件” ≠ 编程，它有自己的生命周期 (life cycle)。大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。

实践证明：对软件进行充分的测试
才能够有效的保证软件质量

对软件产品进行充分测试，找出其中的缺陷(Bug),并进行修复(Fix)。

2.4   软件缺陷--Bug

缺点（defect）               偏差 （variance）
谬误（fault）                  失败 （failure）
问题（problem）            矛盾（inconsistency）
错误（error ）                毛病 （incident ）
异常（anomy）

  IEEE (1983) 729 软件缺陷一个标准的定义：

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

软件缺陷的主要类型/现象：

•  功能、特性没有实现或部分实现
•  设计不合理，存在缺陷
•  实际结果和预期结果不一致
•  运行出错，包括运行中断、系统崩溃、界面混乱
•  数据结果不正确、精度不够
•  用户不能接受的其他问题，如存取时间过长、界面不美观 

2.5  软件缺陷的产生

• 技术问题

算法错误，语法错误，计算和精度问题，接口参数传递不匹配

• 团队工作

误解、沟通不充分

• 软件本身

文档错误、用户使用场合(user scenario)，
时间上不协调、或不一致性所带来的问题
系统的自我恢复或数据的异地备份、灾难性恢复等问题

2.6  软件缺陷构成

2.7  软件缺陷在不同阶段的分布

在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。
规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会逐步发现，而不能在需求分析一个阶段发现

2.8  缺陷成本

3.  软件测试的基本方法

3.1   软件测试的目的

软件测试是为了发现错误而执行程序的过程

•  一个好的测试能够在第一时间发现程序中存在的错误
•  一个好的测试是发现了至今尚未发现的错误的测试。

3.2  软件测试一些误区

•  误区一：如果发布出去的软件有质量问题，都是软件测试人员的错
•  误区二：软件测试技术要求不高，至少比编程容易多了
•  误区三：有时间就多测试一些，来不及就少测试一些    
•  误区四：软件测试是测试人员的事，与开发人员无关    
•  误区五：根据软件开发瀑布模型，软件测试是开发后期的一个阶段

3.3  软件测试的原则

1. 所有测试的标准都是建立在用户需求之上。
2. 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。
3. 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。
4. 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。
5. 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合。 
6. 第三方进行测试会更客观，更有效。
7. 软件测试计划是做好软件测试工作的前提。
8. 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。
9. 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。
10. 重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）
11.  应当把“尽早和不断地测试”作为测试人员的座右铭
12.  回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见
13.  测试应从“小规模”开始，逐步转向“大规模”。
14.  不可将测试用例置之度外，排除随意性。
15.  必须彻底检查每一个测试结果。
16.  一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
17.  对测试错误结果一定要有一个确认的过程。

3.4   测试方法

•  黑盒子和白盒子
•  静态的和动态的
•  文档、代码审查
•  数据输入边界条件法
•  等价划分、数据流程图
•  状态变换图
•  逻辑路径法

3.4.1    黑盒子和白盒子

 功能测试和数据驱动测试

结构测试和逻辑驱动测试 

3.4.2  静态的和动态的

3.4.3  自动测试和手动测试

3.5  验证与确认（V&V）

Verification：Are we building the product right？
是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性

Validation： Are we building the right product? 是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求

4.软件测试的分类与阶段

4.1   生命周期如下图：

4.2  软件测试分类

4.3  软件测试阶段

4.3.1  测试阶段（SDLC)

4.3.2  单元测试

单元测试的对象是程序系统中的最小单元---模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、对立地测试，通常要编写驱动模块和桩模块
单元测试一般由编程人员和测试人员共同完成 

4.3.3  集成测试

集成测试，也称组装测试、联合测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题 
两种集成方式：一次性集成方式和增殖式集成方式。

4.3.4  功能测试

功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用 

4.3.5  系统测试

系统测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等 

4.3.6  验收测试 &安装测试

验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样

安装测试是指按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性的测试 

5.  软件测试的工作范畴