软件测试理论（一）————持续更新

软件测试与软件项目的关系

软件测试是为软件项目服务的。

在整个项目中，要强调测试服务的概念。

软件测试的目的是为了发现软件中存在的错误。

但是根本目的是为了提高软件质量，降低软件项目的风险。

软件测试只能证明软件存在错误，而不能证明软件没有错误。

软件测试不可能无休止的进行下去，而是要把错误控制在一个合理的范围之内。

测试应该贯穿整个项目生命周期。测试应该尽早介入。

软件测试的发展趋势

1.　测试工作将进一步前移。软件测试不仅仅是单元测试、集成测试、系统测试和验收测试，还对需求的精确性和完整性的测试技术、对系统设计的测试技术将成为新的研究热点。

2.　软件架构师，开发工程师，QA人员，测试工程师将进行更好的融合

3.　测试职业将得到更充分的尊重。

4.　设置独立的软件测试部门将成为越越来软件公司的共识。

5.　测试外包服务将快速增长，和软件开发外包一样，软件测试外包将成为全球化的趋势。

什么是软件测试

软件测试的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。

软件测试的IEEE定义:使用人工或自动的手段来运行或测量软件系统的过程，目的是检验软件系统是否满足规定的需求，并找出与预期结果之间的差异。

什么是软件质量

ISO 9126中定义，软件质量是：软件满足规定或潜在用户需求特性的总和。

软件质量包括内部质量、外部质量和使用质量三部分,也就是说软件满足规定或潜在用户需求的能力要从软件在内部，外部和使用中的表现来衡量。

软件测试与质量保证的区别

软件测试人员的一项重要任务是提高软件质量,但不等于说软件测试人员就是软件质量保证人员,因为测试只是质量保证工作中的一个环节,软件质量保证和软件测试是软件质量工程的两个不同层面的工作。

• 质量保证( Q A）：质量保证的重要工作通过预防、检查与改进来保证软件质量。质量保证的工作重点是软件质量的检查与测量，着眼于软件开发活动中的过程、步骤和产物。

• 软件测试：软件测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产出物以及开发出的软件进行剖析。软件测试的着眼点在于找出问题报告质量，对测试中发现的问题进行分析；回归测试也是软件测试中的重要工作

软件测试的目的

软件测试领域先驱 Bill Hetzel 博士 1993年在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。从此以后，软件测试开始频繁出现在软件工程的研究和实践中，也可以认为，软件测试作为一个学科正式诞生了。

1973年正式将软件测试下了一个定义：软件测试就是为程序能够按预期设想运行而建立足够的信心。

Bill hetzel 觉得这个定义不够清楚，理解起来比较困难，所以在1983年将软件测试定义修改为：软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定是否达到了预期结果。

Bill hetzel 可以说是软件测试的奠基人，但是他的观点还是受到业界的一些权威的质疑和挑战，其中代表人物要数Glenford J.Myers（软件测试的艺术作者）Myers认为测试不应该着眼于验证软件是工作的，相反，应该用逆向思维发现尽可能多的错误。

Myers提出的”测试的目的就是证伪“和Bill hetzel提出的”测试是试图验证软件是正确的“争锋相对。

Myers观点中强调测试的目的是寻找错误，就可能使测试人员忽视软件产品的某些基本需求或客户的实际需求，测试活动存在一定的随意性和盲目性

如果测试目的是寻找错误，会让开发人员认为测试人员的工作就是挑刺挑毛病

两种观点应该相辅相成，侧重点不一样，在各行业要求不一样，实际工作中，按要求来。

最终定义就是：使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。

软件测试的原则

• 所有的软件测试都用追溯到用户需求

• 应当把"尽早地和不断地进行软件测试"作为软件测试者的座右铭

• 完全测试是不可能的,测试需要终止;原因主要有三个,一输入量太大,二输出结果太多,三路径组合太多

• 测试无法显示软件潜在的缺陷;进行测试可以查找并报告发现的软件错误和缺陷,但不能保证软件的缺陷和错误全部被找到。

• 充分注意测试中的群集现象(二八定律)

• 程序员应避免检查自己的程序(由于思维定式,人们难于发现自己的错误)

• 尽量避免测试的随意性(应该从工程的角度去理解软件测试,他是有组织、有计划、有步骤的活动)

软件测试的对象

根据软件定义,软件包括程序、数据和文档,所以软件测试并不仅仅是程序测试。

软件测试应贯穿于整个软件生命周期中。

每个阶段有不同的测试对象,需求分析、概要设计、详细设计以及程序编码簦个阶段所得到的文档,包括需求规格说明书、概要设计规格说明、详细设计规格说明以及源程序,都应成为软件测试的对象。

• 单元测试对程序模块进行测试;
• 集成测试堆积成在一起的模块组件或者部件进行测试;
• 在集成测试后,需要检测与证实软件是否满足软件需求说明书中规定的需求,这就成为"确认测试",
• 将整个程序模块继承类软件系统,安装在运行环境下,对硬件、网络、操作系统以及支撑平台构成的整体系统进行测试,称为系统测试。

软件开发有很多环节,为了把握各个环节的正确性,人们需要进行各种验证和确认(Verification & validation)工作。

• 验证(Verification)是保证软件正确实现特定功能的一系列活动和过程,目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。

• 确认( validation)是保证软件满足用户需求的一系列的活动和过程,目的是在软件开发完成后保证软件与用户需求相符合。

验证已确认都属于软件测试,它包括的软件分析、设计以及程序的验证和确认。

软件测试的分类

• 按阶段划分:

  • 单元测试(单元测试又称模块测试,是真的软件设计的最小单位——程序模块进行正确性检验的测试工作)
  • 集成测试(也叫组装测试,通常在单元测试的基础上,将所有程序模块进行有序的、递增的测试。软件集成的过程是一个持续的过程,会形成很多个临时版本,在不断地集成过程中,功能集成的稳定性是真正的挑战。在每个版本提交时,都要进行冒烟测试,即对程序主要功能进行验证。冒烟测试也将版本验证测试、提交测试。)
  • 确认测试(确认测试是通过检验和提供客观证据,证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。)
  • 系统测试(系统测试实例验证和确认系统是否达到其原始目标,而对集成的硬件和软件系统进行的测试。)
  • 验收测试(按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接受或拒收系统。)

• 按照测试实施组织划分

  • 开发测试(通常要验证测试或α测试)
  • 用户测试(通常情况下用户测试不是指用户的"验收测试",而是指用户的使用性测试,由用户找出软件的应用过程中发现的软件的缺陷与问题,并对使用质量进行评价。β测试通常被看成是一种用户测试)
  • 第三方测试(介于软件开发方和用户方之间的测试组织的测试。第三方测试也成为独立测试。软件质量工程强调开展独立验证和确认(IV&V)活动)

• 按照测试技术划分

  • 白盒测试(关注程序内部结构和逻辑)
  • 黑盒测试(关注外部表现和功能)
  • 灰盒测试(吃关注内部结构与逻辑也关注外部表现和功能)

• 软件测试过程模型

瀑布模型

图片引用来源

v模型

W模型

H模型

• 其他模型

X模型

测试模型的使用

测试模型对指导测试工作具有重要的意义,但任何模型都不是完美的。我们应该尽可能去应用模型中对项目有实用价值的方面,但不强行的为使用模型而使用模型,否则也没有实际意义。

v模型强调了在整个软件项目开发中需要经历的若干个测试级别,而且每一个级别都与一个开发级别相对应,但她忽略了测试的对象不应该仅仅包括程序,或者说她没有明确的指出应该对软件的需求设计进行测试,而这一点在W模型中移到了补充。W模型强调了测试计划等工作的先行和对系统需求和系统设计的测试,但W模型和v模型一样也没有专门针对测试的流程予以说明,因为事实上,随着软件质量要求越来越被大家所重视,软件测试也逐步发展成为一个独立软件开发和的组织,就每一个软件测试的细节而言,他都有一个独立的操作流程。比如,现在的第三方测试,就包含了从测试计划和测试案例编写,到测试实施以及测试报告编写的全过程,这个过程再H模型当中得到了相应的体现,表现为测试是独立的。也就是说,只要测试前期具备了,就可以开始进行测试了。当然,X模型和前置测试模型又在此基础上增加了许多不确定因素的处理情况,因为在真实项目中,经常会有变更的发生,例如需要重新访问前一阶段的内容,或者跟踪并纠正以前提交的内容,修复错误,排除多余的成分,以及增加新发现的功能等。因此在实际的工作中,要灵活地运用各种模型的优点,在W模型的框架下,应用H模型的思想进行独立的测试,并同时将测试和开发紧密结合,寻找恰当的就绪点开始测试并反复迭代测试,最终保证按期完成预定目标。

软件生命周期测试策略

软件测试的过程

测试信息流
需求说明书的框架
需求说明书评测规范
软件设计规格说明大纲
概要设计说明书评测规范
详细设计说明书评测规范
单元测试的工作
单元测试的测试环境

软件质量的定义

参考:

• ISO/IEC 25000《软件和系统工程–软件产品质量需求和评价(SQuaRE)》
• ISO 9126 (软件产品质量)和ISO 14598 (软件产品评价)
• ISO 15504 ( SPICE,软件过程改进和能力确定)
• ISO 12207 (软件生存期过程)
• ISO/IEC 15939 (GB/T 20917)《信息技术–软件测量过程》

---

1.软件质量的定义

1 ) ANSI/IEEE Std 729-1983定义软件质量为:“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。

其含义有四:

1 能满足给定需要的性质和特性的全体;
2 具有所期望的各种属性的组合程度；
3 顾客和用户觉得能满足其综合期望的程度;
4 确定软件在使用中将满足顾客预期要求的程度。

2. M.J. Fisher将软件质量定义为：“所有描述计算机软件优秀程度的特性的组合。”

3. GB/T6583一ISO 8402(1994)定义软件质量为:“反映实体满足明确和隐含需要的能力和特性总合”

4. 软件质量还被定义如下:

• 客户满意度
• 一致性准则
• 软件质量度量
• 过程质量观

5. 软件质量和一-般产品质量类似，被定义为3A特性:

• 可说明性(Accountability)
• 有效性(Availability)
• 易用性( Accessibility)

6. RUP（Rational Unified Process）中，软件质量被定义为具有以下三个维度:

• 功能(Functionality)
• 可靠( Reliability/Dependability )
• 性能(Performance)

简言之，软件质量是软件一些特性的组合，它依赖软件的本身。

GB/T 6583—ISO 8404（1994版）《质量管理与质量保证术语》对质量的定义是“反映实体满足明确的和隐含的需要的能力的特性的总和”。作为软件质量,在在GB/T 18905—ISO 14598（1999版）《软件工程　产品评价》中也是这样定义的:“实体特性的总和,满足明确或隐含要求的能力”

包含：内部质量，过程质量，外部质量，使用质量

ISO9126标准里的软件质量模型：6大特性的27个子特性（质量特性）：

• 功能性（Functionality）:软件在指定条件下使用时,满足用户明确可以和需求的功能的能力。

  • 适合性（Suitability）:软件为指定的用户和用户目标提供一组适合功能的能力。
  • 准确性（accuracy）:软件提供具有所需精确度的正确或相符的结果或效果的能力。
  • 互操作性（Interoperability）:软件与一个或更多的规定系统进行交互的能力。
  • 保密安全性（Security）:软件保护信息和数据的能力,以使未授权的人员和系统不能阅读和修改这些信息和数据,而不拒绝授权人员和系统对他们的访问。 如数据库加密，IP，登陆次数限制防Dos 攻击
  • 功能性的依从性（Functionality Compliance）:软件遵循与功能性相关的标准、约定和法规以及类似规定的能力。这些标志要考虑国际标准、国家标准、行业标准、企业内部规范等。

• 可靠性（Reliability）:产品在规定的条件下，在规定的时间内完成规定功能的能力。

  • 三要素：规定的环境，规定的时间，规定的性能
  • 成熟性（Maturity）:软件为避免由软件中错误而导致实效的能力。
  • 容错性（fault tolerance）:在软件出现故障或者违反指定接口的情况下,软件维持规定的性能级别的能力。
  • 易恢复性（recoverability）:在失效发生的情况下,软件重建规定的性能级别并恢复手指这样想的数据的能力。
  • 可靠性的依从性（Reliability Compliance）:软件遵循与可靠性相关的标准、约定和法规的能力。即国际/国家/行业/企业 标准规范一致性

• 易用性（Usability）：在指定使用条件下，产品被理解、学习、使用和吸引用户的能力

  • 易理解性（Understandability）：软件使用户能理解软件是否合适,以及如何能将软件用于特定的任务和适应环境的能力。
  • 易学性（Learnability）：软件使用户能学习其应用的能力。
  • 易操作性（operability）：软件使用和能操作和控制他的能力。
  • 吸引性（attractiveness）：软件新用户的能力。
  • 易用性的依从性(Usability compliance)：软件遵循与易用性相关的标准、约定、风格指南或法规的能力。国际/国家/行业/企业 标准规范一致性

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

  • 时间特性(time behavior)：指在规定条件下,软件产品执行其功能时,提供适当的响应和处理时间以及吞吐率的能力。平均事务响应时间，吞吐率，例如：用户打开某个网页需要等待的时间；
  • 资源利用性(resource utilization)：；资源相关的特性是指，在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力，例如：用户在进行相关操作时，系统的内存和CPU的变化情况。CPU 内存 磁盘 IO 网络带宽 队列 共享内存
  • 效率依从性(efficiency compliance)：软件遵循与效率相关的标准或约定的能力。

附:用户愿意等待时间分布表

页面加载时间	愿意等待的用户比例
十秒	84%
15秒	51%
20秒	26%
30秒	5%

• 软件可移植性（Portability）：从一种环境迁移到另一种环境的能力

  • 适应性（adaptability）：适应不同平台
  • 易安装性（installability）软件在指定环境中被安装的能力。
  • 共存性（co-existence）：软件在公共环境中同与其分享公共资源的其他独立软件共存的能力。兼容性
  • 易替换性（replaceability）:软件在同样环境下，替代另一个相同用途的指定软件产品的能力。
  • 可移植性的依从性：（portability compliance）:软件遵循与可移植性相关的标准或约定的能力。

• 可维护性（maintainability）：“四规”，在规定条件下，规定的时间内，使用规定的工具或方法修复规定功能的能力

  • 易分析性（analyzability）：软件诊断软件中的缺陷、失效原因或识别待修改部分的能力。定位成本：分析定位问题的难易程度
  • 易改变性（changeability）：软件使指定的修改可以被实现的能力。降低修改缺陷的成本：软件产品使指定的修改可以被实现的能力
  • 稳定性（stability）：软件避免由于软件修改而造成意外结果的能力。防止意外修改导致程序失效。
  • 易测试性（testability）：软件使已修改软件能被确认的能力。降低发现缺陷的成本：使已修改软件能被确认的能力
  • 维护性的依从性（maintainability compliance）：软件遵循与维护性相关的标准或约定的能力

资料引用：

• 《软件测试师教程》
• ISO/IEC 25000《软件和系统工程–软件产品质量需求和评价(SQuaRE)》
• ISO 9126 (软件产品质量)和ISO 14598 (软件产品评价)
• ISO 15504 ( SPICE,软件过程改进和能力确定)
• ISO 12207 (软件生存期过程)
• ISO/IEC 15939 (GB/T 20917)《信息技术–软件测量过程》
• 软件工程之美学习笔记四 03 | 瀑布模型：像工厂流水线一样把软件开发分层化 - alva_xu的博客 - CSDN博客