本文主要是介绍软件测试（二）：从软件工程到软件测试，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

软件测试（二）：从软件工程到软件测试

软件的概念

错误观点：“软件就是程序，软件开发就是编程序”

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。

程序是按事先设计的功能和性能要求执行的指令序列。

数据是使程序能正常操纵信息的数据结构。

文档是与程序开发，维护和使用有关的图文材料。

软件的十大特性

• 形态特性：软件是无形的、不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它却是毫无意义的。
• 智能特性：软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了知识实践实验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决策问题。
• 开发特性：尽管有一些工具辅助开发，但目前为止仍未实现自动化。软件开发仍然包含了相当份量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素。
• 质量特性：软件由人编写，由于其开发特性所在，所以不存在完全没有缺陷的软件。
• 生产特性：软件一旦设计开发出来，如果需要提供多个用户，它的复制非常简单，其成本也极为有限。
• 管理特性：由于上面的特性存在，所以软件过程中的管理显得更为重要，相比传统行业，也更为独特。
• 环境特性：软件的开发和运行都离不开相关的计算机环境，包括支持它的硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性。
• 维护特性：软件投入使用之后需要进行维护，维护体现在升级、优化、功能更新等方面，甚至可以全盘重构。
• 废弃特性：与硬件不同，软件并不是由于被“用坏”而被废弃的。
• 应用特性：软件的应用极为广泛，已渗入各个领域，占据了无可取代的地位

软件的分类

系统软件

系统软件是负责管理计算机系统中各种独立的硬件，使得它们可以协调工作。

• 服务性程序：如诊断程序、排错程序、联系程序等
• 语言程序：如汇编程序、编译程序、解释程序
• 操作系统
• 数据库管理系统

应用软件

应用软件是为了某种特定的用途而被开发的软件。它可以是一个特定的程序，比如一个图像浏览器。也可以是一组功能联系紧密，可以互相协作的程序的集合。

软件的生命周期

问题定义，可行性研究，需求分析，概要设计，详细设计，编码和单元测试，综合测试，软件维护

软件开发模型

瀑布模型

原型模型

敏捷模型

软件开发文档

软件开发模型

软件测试概念

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

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

软件测试的目的：软件测试目的在于发现问题，检查系统是否满足需求。

软件测试方法和分类

生命周期各个测试方法的对比

软件测试常见模型

v模型

v模型是我们熟知的瀑布模型的一种改进，瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以可能带来严重的后果。

v模型就是在这点改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时开始，这两个并行的动态的过程就会极大的减少bug和error出现的几率。

w模型

h模型

真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量

为了解决v模型和w模型存在的问题，要专家提出了h模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来

x模型

软件测试覆盖率

覆盖率定义

覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的一个度量

覆盖率 = （至少被执行一次的item 数） / （item 的总数）

特点

1. 通过覆盖率数据，可以检测我们的测试是否充分
2. 分析出测试的弱点在哪方面
3. 指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能一味追求覆盖率，因为测试成本随覆盖率的增加而增加。

测试覆盖率对于黑盒测试来说，主要指两个方面：

需求覆盖和用例覆盖

需求覆盖

1.定义：它表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大通过设计一定的测试用例，要求每个需求点都被测试到。

2.计算公式：需求覆盖 = （被验证到的需求数量）/ （总的需求总数）

用例覆盖

1.定义：主要体现在我们每轮测试验证通过的用例数载总用例中的比重

2.计算公式：用例覆盖 = （验证通过的用例数量）/ （总的用例总数）

测试覆盖率的实际运用

简单的测试覆盖率

本次测试执行的用例数 / 所有用例数

上述覆盖率统计建立在认为总用例数编写全面，一般对于大型系统测试要求覆盖率 100%

覆盖率的审核 ： 抽样验收

基于产品的测试覆盖率

已测试需求点 / 设计所有需求数

以产品、需求维度统计，无论大型项目或是小需求迭代都要求覆盖率达到100%

覆盖率的审核：抽样验收

基于白盒的测试覆盖率

大多工具判断语句覆盖，即单元测试代码覆盖代码行 / 总代码行

更多考察研发人员，更多时候要求覆盖率达到80%+

缺陷：覆盖率数据只能代表测试过哪些代码，不能代码是否测试好这些代码，容易遗漏逻辑、判断等场景

基于自动化的测试覆盖率

自动化覆盖的测试场景（测试用例） / 所有测试场景（用例）

用途：自动化测试更着重于回归验证，没必要追求过高的覆盖率，而要考虑用例设计

测试覆盖率的最终意义

应用最多的地方在 测试停止标准

单纯讨论测试覆盖率，在瀑布式开发模型中并不重要，但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试

在 短迭代、DevOps 中，更强调用单元测试覆盖率来评估不断增加的代码数量。

测试团队的组织架构

金字塔管理模式

矩阵化管理模式

软件测试人员需要的知识体系

软件测试人员具备的素质

软件测试原则

• 原则1: 所有的测试都应追溯到用户需求
• 原则2: 尽早启动测试工作
• 原则3: Pareto 法则应用于软件测试（28原则）
• 原则4: 穷尽测试是不可能的
• 原则5: 杀虫剂怪事（软件测试越多，其对测试的免疫力越强的现象）
• 原则6: 前进两步，后退一步（缺陷修复总会以20-50%的几率引入新的缺陷，每次修复后，必须重新运行先前的所有测试用例，从而确保系统不会以隐蔽的方式被破坏）
• 原则7: 三心二意（细心、信息、耐心，团队合作的沟通意识、时刻保持怀疑的态度且有缺陷预防的意识）

软件测试规范

软件工程标准

ISO9000

CMM

测试规范

这篇关于软件测试（二）：从软件工程到软件测试的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！