Software Testing_软件测试基础知识

你好，我是阿Ken
开学新加了软件测试这门课，故因此特意整理出一个新专栏，
参考学校有关教材并进行整理和删减，属于课程相关笔记，重点以考试考点为主，其次为简单了解软件测试。

人总归不能活的太矫情
希望在一塌糊涂的时候你也能鼓励自己坚持下去
悲喜自渡，他人难悟

1.1_软件测试背景

软件缺陷给我们的生产和生活造成了大量的损失，这些惨痛的教训时刻警醒着世人要更加重视软件测试，不断提高软件的质量。

1.1.1_软件故障案例

1.1.2 _软件缺陷定义

软件缺陷，即计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。

缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983 对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

对于软件缺陷的定义，通常有以下 5 项规则描述，如符合任意一项，便称为“软件缺陷”：

(1) 软件未达到产品说明书中已标明的功能。

(2) 软件出现了产品说明书中指明不会出现的错误。

(3) 软件未达到产品说明书中虽未指出但应达到的目标。

(4) 软件功能超出了产品说明书中指明的范围。

(5) 软件测试人员认为软件难以理解，不易使用、运行速度缓慢，或者最终用户认为该软件使用效果不佳。

1.2_软件开发过程

1.2.1_软件产品的组成

1. 软件产品需要各种开发投入
2. 客户需求
3. 产品说明书
4. 进度表
5. 软件设计文档
6. 测试文档

1.2.2_软件项目组成员

软件项目的开发需要大量人员的团结协作，下面的清单列出了主要人员及其职责。

① 项目管理员、程序管理员或者监制人：始终驱动整个项目，负责编写产品说明书、管理进度，进行重大决策和取舍。

② 设计师或者系统工程师：是软件小组的技术专家，设计整个系统架构或软件构思。

③ 程序员、开发人员或者代码制作者：设计、编写并修复软件中的缺陷。

④ 测试员或者质量评判员：负责找出并报告软件产品的问题。

⑤ 技术作者、用户手册、用户培训专员、手册编号人员或者文案专员：编制软件产品附带的文件和联机文档。

⑥ 软件管理员或者制作人员：负责把程序员编写的全部文档资料合成一个软件包。

1.2.3_软件开发模式

从最初构思到公开发行软件产品的过程称为软件开发模式。

1. 快速原型模型

快速原型模型允许在需求分析阶段，对软件的需求进行初步的非完全的分析和定义。

2. 增量模型

采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可分布的“增量”。

3. 原型模型

原型模型也称样品模型，它采用逐步求精的方法完善模型。

4. 喷泉模型

喷泉模型是以用户需求为动力，以对象为驱动的模型，不要用于面向对象技术的软件开发项目。

5. 螺旋模型

螺旋模型适合用于需求经常变化的项目，适用于大型复杂的系统。

6. 瀑布模型

从本质来讲，瀑布模型是一个软件开发架构重复应用的模型，其核心思想是按工序交问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法，将逻辑实现与物理实现分开。

1.3_软件测试基本理论

1.3.1_软件测试的基本概念

1. 软件测试的定义

_
软件测试就是使用人工或者自动化工具按照测试方案和流程对产品进行测试的过程。
_
有时需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合用户的需求。
_
软件测试是帮助识别开发完成 (中间或最终的版本) 的计算机软件 (整体或部分) 的正确度、完全度和质量的软件过程，是SQA ( Sofware Quality Assurance) 的重要子域。

2. 测试原则

_
（1）软件开发人员及程序员应当避免测试自己的程序。自己软件的测试要别人来进行反而更有效。
（2）应尽早和不断地进行软件测试。
（3）对测试用例要有正确的态度。在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的测试条件。
（4）人以群分，物以类聚。充分注意20—80原则，不要以为发现几个错误并且解决这些问题后，就不需要进行测试了。
（5）严格执行测试计划，排除测试的随意性。
（6）应当对每一个测试结果进行全面检查。
（7）妥善保存测试计划、测试用例、测试报告和最终分析报告，以备回归测试及维护之用。

3. 测试目标

_
软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置进行。如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。
_
不同的机构会有不同的测试目的;相同的机构也可能有不同测试目的，可能是测试不同区城或是对同一区域的不同层次的测试。

1.3.2_软件测试的基本技术

1. 软件测试的基本方法

_
对于软件测试技术，可以从不同的角度加以分类:
_
从是否需要执行被测软件的角度，可分为静态测试和动态测试:
_
从测试是否针对系统的内部结构和具体实现算的角度来看，可分为白盒测试和黑盒测试
_

(1) 黑盒测试

_
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能的前提下，通过测试来检测每个功能是否都能正常使用。
在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法主要有等价类划分法、边界值分析法、因果图法、错误推测法等，主要用于软件确认测试。
_
“ 黑盒 ” 法着眼于程序外部结构，不考虑内部逻辑结构，针对软件界面和软件功能进行测试。“黑盒” 法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无有多个，人们不仅要测试所有合法的输入，面且还要对那些不合法但是可能的输入进行测试。
_

(2) 白盒测试

_
白盒测试也称结构测试或逻辑驱动测试，它是在已知产品内部工作过程的前提下，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。白盒测试的主要方法有逻辑覆盖法、基本路径法等，主要用于软件验证。
“ 白盒 ” 法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“ 白盒 ” 法是穷举路径测试。在使用这一方案时， 测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试绝不能查出程序违反了设计规范，即程序本身就是个错误的程序; 第二，穷举路径测试不可能查出程序中因遗漏路径而出的错; 第三，穷举路径测试可能发现不了一些与数据相关的错误。

2. 软件测试的复杂性与经济性

人们常常以为开发一个程序是困难的，测试一个程序则比较容易。这其实是种误解。

3. 测试过程及组织

首先，测试人员要仔细阅读有关资料，做好测试前的准备工作。
测试过程分成几个阶段：
1 代码会审
2 单元测试（集中检查软件设计的最小单位–模块上）
3 集成测试（将模块按照设计要求组装起来同时进行测试）
4 确认测试（目的是向未来的用户表明系统能够像预定要求那样工作）
5 系统测试（软件开发完成后，最终还要与系统中其他部分配套运行）

1.4_软件质量 与质量模型

1.4.1_软件质量的定义

软件质量：即国际化标准组织 ISO ISOIEO9126 中将软件质量定义为反映软件产品满足规定需求和潜在需求能力的特征和特征的总和。

MJ. Fisher 将软件质量定义为所有描述计算机软件优秀程度的特性的组合。也就是说，为了满足软件的各项精确定义的功能、性能要求，符合文档化的开发标准，需要相应地给出或设计一些质量特性及其组合，要得到高质量的软件产品，就必须满足这些质量特性。

按照 ANSI/IEEE Std 1061.1992 中的标准，软件质量定义为：与软件产品满足需求所规定的和隐含的能力有关的特征或特性的全体。具体包括:

(1) 软件产品中所能满足用户给定需求的全部特性的集合;

(2) 软件具有所有的各种属性组合的程度;

(3) 用户主观得出的软件是否满足其综合期望的程度;

(4) 决定所用软件在使用中将满足其综合期望程度的合成特性。

目前，对软件质量特性有多种提法，但实际上是大同小异。ISOIEC 9126 国际标准中定义的软件质量特性为以下6项：功能性、可靠性、易使用性、效率、可维护性和可移植性。

1.4.2_影响软件质量的因素

软件本身的特点和目前软件开发模式的些缺陷，使软件内部的质量问题有时不可能完全避免。

(1) 软件本身的特点。 软件只有复杂性、 一致性、可变性和不可见性。

(2) 开发环节多跟据传统的瀑布模型，增加了成本。

(3) 选择支持工具。在软件的整个开发过程中，能够得到的开发工具或管理工具都十分有限。

(4) 测试的局限性。测试只能在一定程度上把错误减少到最低限度。

1.4.3_软件质量控制

1. 软件质量控制的定义

_
在IEEE中对软件质量控制的定义是:用以评价开发或生产的软件产品质量的一系列活动。质量控制是质量管理的一部分， 是为保证每一件产品都满足对它的需求而应用于整个开发周期中的一系列审查和测试。
_
软件质量控制是指监视项目的具体结果，以确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源。这就是说，软件质量控制是以软件质量为目的，以软件质量评估为度量，以软件质量控制为核心手段，高效地运作软件开发的过程。
_
高质量的软件离不开有效的管理和控制。J.M.Juran 认为，质量控制是一个常规的过程，通过它度量实际的质量性能并与标准比较，当出现差异时采取行动。由此，Donald Refer给出软件质量控制定义:软件质量控制是系列的验证活动，在软件开发过程之中的任何一点进行评估开发的软件产品是否在技术上符合该阶段指定的规约。
_
由此，我们给出软件质量管理的定义是:软件质量管理是一系列的验证活动，通过这些活动，我们可以判断软件开发各个阶段是否符合既定的要求，对发生的软件缺陷和软件错误是否给出及时的修正和纠正。

2. 软件质量管理方法

_
软件的开发至今仍不能自动化地进行，而以人工开发方式为主。针对软件的特点，对软件的质量控制，更应该注重对软件过程的控制，通过完善质量管理体系以适应软件质量管理要求。

1.4.4_软件质量评估的标准与度量

软件质量有与硬件不同的评价方法，根据软件产品的特性，评估一个软件的质量需要有一个评价标准、一个评价准则和一种度量。

1. 标准

_
软件的质量标准就是软件质量的 6 个特性，如下所述。
_
(1) 功能性:
指软件所实现的功能满足用户需求的程度。
_
(2) 可靠性:
指在规定的时间和条件下，软件所能维持其应有性能水平的程度。它除了反映软件满足用户需求正常运行的程度，而且反映了在故障发生时能继续运行的程度。
_
(3) 易用性:
指对于一个软件， 用户学习、操作时所做的努力程度。易用性反映了软件与用户的友善性。
_
(4) 效率:
指在指定的条件下，软件实现某种功能所需要的计算机资源(CPU、内存、接口、外设等)时间的有效程度。效率反映了在完成功能要求时，有没有浪费资源。
_
(5) 可维护性:
指在一个运行的软件中，为了满足用户需求、环境改变或软件发生错误时，进行相应修改所做的努力程度。可维护性反映了在用户需求、环境发生变化或软件发生错误时，对软件进行修改的容易程度。
_
(6) 可移植性:
指从一个计算机系统或环境移植到另一个计算机系统或环境的容易程度。可移植性反映了软件在不同环境的适应程度，评价了软件的质量。

2. 准则

_
对不同类型的软件、软件的各个开发阶段，评价准则要进行不同的有机组合，方可反映出该软件的质量要素。

3. 度量

_
在软件开发不同的生命周期，对不同类型的软件在每一个阶段制定相应的评价内容，以实现软件开发过程的质量控制。

1.4.5_软件度量的方法体系

1. 项目度量
   _
   项目度量是针对软件开发项目的特定度量。

2. 规模度量
   _
   规模度量是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。

3. 成本度量
   _
   主要指软件开发项目所需的财务性成本的估算。

4. 顾客满意度度量

5. 软件质量的生命周期及其度量

6. 过程度量
   _
   过程度量是对软件开发过程的各个方面进行度量

课后提醒

以上内容应了解:
软件缺陷的定义
原型法开发模式的优缺点
软件测试的几大原则
软件质量的六个特性
测试的过程及组织

• 简述原型法开发模式的优缺点
  原型模型的优点如下：
  _
  (1) 开发人员和用户在“原型” 上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
  _
  (2) 缩短了开发周期，加快了工程进度。
  _
  (3) 降低成本。
  _
  原型模型的缺点如下:
  _
  (1) 当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。
  _
  (2) 不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致。

• 简述测试的过程及组织
  当设计工作完成以后，就应该着手测试的准备工作了，一般来讲， 由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。
  _
  在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般可按下列方式组织：
  _
  (1) 首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。
  _
  (2) 为了保证测试的质量，将测试过程分成几个阶段，即:代码审查、单元测试、集成测试、确认测试和系统测试。
  _
  (3) 代码会审。
  代码会审是由组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组在充分司读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。实践表明，程序负在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进步促使了问题的暴露。
  _
  (4) 单元测试。
  单元测试集中在检查软件设计的最小单位模块上，通过测试发现实现该模块的实际功与定义该模块的功能说明不符合的情况，以及编码的错误。
  _
  (5) 集成测试。
  集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失;一个模块与另一个模块可能有由于疏忽的问题而造成有害影响;把子功能组合起来可能不产生预期的主功能;个别看起来是可以接受的误差可能积累到不能接受的程度;全程数据结构可能有错误等。
  _
  (6) 确认测试。
  确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性， 这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样。
  _
  (7) 系统测试。
  软件开发完成以后，最终还要与系统中其他部分配套运行，进行系统测试。包括恢复测试、安全测试、强度测试和性能测试等。
  _
  经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。

记得前几年上高中的时候，有个同学在讲台上说过一句话，
“你没有输，你只不过是还没有赢而已”
他本来成绩好像还前三前五稳稳的，
甚至后来最差的时候都能十几名，
但他最后是攥着一张双一流的大学录取通知书去的北京某校…
平凡很烦
但你不能烦
找到自己的节奏懂得迎难而上
有了自己的节奏坚持下去总归是没错的

我是阿Ken
欢迎下次来访