软件测试-常见理论概念整理（一）

软件测试-理论概念整理（一）

1.软件产品质量模型

软件产品质量模型将一个软件产品需要满足的质量划分为六大属性：功能性、可靠性、易用性、效率、可维护性和可移植性

翻阅查询大多数资料指出质量模型分为这六大类，少数资料将可移植性与易用性替换成安全性。

1.1功能性

能够满足明确和隐含要求的功能

1.2可靠性

是指在特定条件下使用时，软件产品维持规定的性能级别能力，且能够处理异常情况，很快从错误中恢复

1.3易用性

指用户在指定条件下使用软件，软件对于用户来说易懂，易学，易操作，一定程度上需要漂亮好看

1.4效率

简单来说就是占用少量的资源，提供适当的性能（大多数从时间、资源上测试体现出来）

在少数文献资料里，效率性与性能等同概念。

1.5可维护性

指软件（产品）可被修改的能力：即对软件的修改实现、改进功能等所表现的适应性

1.6可移植性

指软件从一种环境移植到另一种环境的能力：环境可以是软件间、硬件间、或所处的系统甚至包括使用组织等等

2.软件测试

定义混杂 没有统一标准 但主体中心意思差不多

经典定义：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程

3.软件测试分类-测试方法

根据不同的分类依据，有不同的分类类别。以下列举比较常见（经典）且较有权威性的分类：

3.1 是否考虑覆盖源代码（内部结构）【重要！】

3.1.1 黑盒测试（在另一篇有专门详细的说明）

点击–>>黑盒测试专篇

不考虑内部结构的情况下，在 程序接口 进行测试

3.1.2 白盒测试

检查程序的内部结构，从检查程序的逻辑着手，得出测试数据的基础上进行测试

3.1.3 灰盒测试

介于黑盒与白盒之间

3.2 是否执行程序

3.2.1 静态测试

静态方法是指 不运行被测程序 本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

3.2.2 动态测试

动态测试方法是指通过 运行被测程序 ，检查运行结果与预期结果的差异，并分析运行效率、正确性等性能。

3.3 按阶段划分【重要！】

3.3.1 单元测试

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的功能是否正确。测试的对象是软件设计的最小单位：模块。

3.3.2 集成测试

集成测试也称联合测试或者组装测试，将程序模块（单元测试）采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作

实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来

3.3.3 系统测试

是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明书的地方

一般来说，在系统测试上测试时间占比最大

冒烟测试、回归测试也属于系统测试

3.3.4 验收测试

也称交付测试，是软件部署前最后一个测试，一般以最终用户角度确认软件是否符合预期

3.4 按测试对象划分【重要！】

在文献与各种技术论坛里答案不一，但相近，在这里举一些比较经典常见的

在这里暂时只做概念梳理，后续会详细分析每个测试的要点

3.4.1 性能测试

3.4.2 界面测试

3.4.3 业务测试

3.4.4 文档测试

3.4.5 兼容性测试

3.4.6 安全测试

3.4.7 安装测试

3.5 是否手工执行（自动化）

自动化测试不能完全替代手工测试，自动化测试的目的仅仅在于让测试人员从繁琐重复的测试流程中解脱出来，把更多的时间和精力放在更有价值的测试中

在某些领域和测试中，手动测试比自动化测试效率高，消耗资源少

3.5.1 手工测试

3.5.2 自动化测试【趋于重要】

3.6 其他分类（补充）

3.6.1 冒烟测试

对基本功能、主要功能的测试，避免不必要的测试资源的浪费

一般来说，冒烟测试优于其他测试，属于第一个需要进行的测试（在开发完后）

冒烟测试属于系统测试

3.6.2 回归测试

对bug或测试用例进行重新测试，确认修改后没有引入新的bug且以往通过测试的功能没有产生错误

在目前的快速开发和敏捷迭代开发中，新版本的连续发布使得回归测试进行的更加频繁

3.6.3 探索性测试

探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具

同时做测试设计和测试执行，探索复杂场景，容易被忽视的场景

---

4.软件开发常见模型

4.1 瀑布模型

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式

4.1.1 优缺点

优点：阶段清晰，需求明确—适合大型项目

缺点：以来需求分析成果，对文档要求较高

4.2 快速原型模型

4.2.1 优缺点

优点：支持客户参与，适应灵活开发项目

缺点：文档不完善，不满足大型项目需求

4.3 增量模型

开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

5.软件测试常见模型

5.1 V模型

V模型中开发阶段和测试阶段划分明确，对应关系明确

V模型没有体现尽早测试和不断测试原则

V模型有一定的局限性,它仅仅把测试过程放在需求分析、系统设计、编码之后的一个阶段，忽视了测试对于需求的分析和验证。

5.2 W模型

优点：开发与测试并行，有利于尽早发现问题，有利于及时的了解项目的测试风险，来及早的执行相应的应对方案，加快项目的进度（是V模型的演变，弥补V模型的不足）

缺点：需求、设计、编码仍然是串行进行的，测试和开发保持线性的关系，上一个阶段完成之后才能进行下一个阶段，不能够很好的支持迭代的开发模型。

5.3 H模型

把软件测试看成一个完全独立的流程，与其他流程并发进行，比如设计流程，编码流程，甚至是测试流程

H模型强调把测试分为测试准备和测试执行两个不同的阶段，只要由于其他流程的进展引发了测试就绪点的到位，这时候，只要测试准备不能完成，测试执行活动就可以或者需要开展，在H模型当中，测试是一个完全独立的模型，所以可以和其他的流程交叉地进行，也便于我们 尽早的执行测试 。

5.4 X模型

左边描述的是针对单独的程序片段相互分离的编码和测试，此后进行频繁的交接，再通过集成，最终合成可执行的程序，X模型还定位了 探索式测试 ，探索式测试是不进行事先计划的特殊类型的测试，能够帮助测试人员在测试计划之外发现更多的错误

---

6.软件缺陷（Bug）

6.1 定义

软件缺陷（Defect），常常称为bug。即软件或程序中存在的问题及错误（也包括隐藏的功能缺陷）

6.2 标准

无先后顺序，只要满足以下五条其中一条即可视为软件缺陷（bug）

违反需求：

1.未达到需求规格说明书标明的功能

2.出现了需求指明不会出现的错误

3.超出了需求范围

违反标准：

1.未达到需求虽未指明但应该达到的目标

违反易用性：

1.软件难以理解，不易使用，运行速度慢等

6.3 缺陷报告因素

6.3.1 缺陷ID

缺陷的唯一标识（便于记录沟通）

6.3.2 缺陷状态

指缺陷通过一个跟踪修复过程的进展情况，即当前所处状态

6.3.3 缺陷标题

缺陷的简要概述

6.3.4 严重程度

缺陷的严重程度，指因缺陷引起的故障对软件产品的影响程度

6.3.5 优先级

指缺陷必须被修复的紧急程度

6.3.6 详细信息

缺陷的详细描述

---

7.软件测试的基本流程

总体上分为五个阶段

1.测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议

2.测试计划阶段：在参考软件需求规格说明书前提下，主要任务为编写测试计划，确定整体测试策略

3.测试设计阶段：主要是编写测试用例，且要通过用例评审

4.测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束

5.测试评估阶段：出测试报告，测试结束

eg：

需求分析–》编写测试计划–》编写测试用例–》评审用例–》搭建环境–》等待开发提交测试包–》测试包安排预测（冒烟测试）–》执行测试用例，进行正式测试–》bug跟踪处理（提交及回归bug）–》N轮后符合需求–》-编写出报告，测试结束