软件测试基础

• 一、 软件缺陷的概述
• • 1、什么是软件缺陷
  • 2、软件缺陷的类型
  • 3、软件缺陷的案例
  • 4、软件缺陷的产生原因
  • 5、软件缺陷的分类
  • 6、软件缺陷的处理流程
  • 7、多学一招：缺陷 告（由测试人员完成）
  • 8、常见软件缺陷管理工具
  • 9、修复软件缺陷的成本
• 二、 软件的概述
• • 1、软件生命周期
  • 2、开发过程中的角色
  • 3、软件开发模型
  • 4、软件质量概述
• 三、 软件测试的概述
• • 1、软件测试的发展
  • 2、软件测试的定义
  • 3、软件测试的目的
  • 4、软件测试的分类
• 四、 软件测试与软件开发的关系
• 五、 软件测试的原则
• 六、 软件测试的流程
• 七、结束语

对于一个软件来说，总会存在各种各样的软件缺陷。因此我们需要通过软件测试来检查软件中存在的各种问题。

在下面的这篇文章中，将讲解软件测试的基础知识，让我们一起来了解一下吧

一、 软件缺陷的概述

1、什么是软件缺陷

软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求。

IEEE(电气电子工程师协会)对软件缺陷有一个标准的定义：

从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、误差等各种问题。

从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

2、软件缺陷的类型

（1）软件未实现产品说明书要求的功能。

（2）软件出现了产品说明书不应该出现的错误。

（3）软件实现了产品说明书未提到的功能。

（4）软件未实现产品说明书虽未明确提及但应该实现的功能。

（5）软件难以理解、不易使用、运行缓慢——从测试员的角度看——最终用户会认为不好。

3、软件缺陷的案例

（1）千年虫问题（产生约1974年）

（2）爱国者导弹防御系统（1991年）

（3）英特尔奔腾浮点除法缺陷（1994年）

（4）“冲击波”病毒（2003年）

（5）诺基亚手机平台缺陷（2008年）

4、软件缺陷的产生原因

• 需求不明确
• 软件结构复杂
• 开发人员水平有限
• 项目期限短
• 使用新技术
• 其他原因

5、软件缺陷的分类

• 提交：测试人员发现缺陷之后，将缺陷提交给测试组长。
• 分配：测试组长接收到测试组员提交的缺陷之后，将其移交给开发人员。
• 确认：开发人员接收到移交的缺陷之后，会与团队甚至测试人员一起商议，确定该缺陷是否是一个缺陷。
• 拒绝：如果经过商议之后，缺陷不是一个真正的缺陷则拒绝处理，关闭缺陷。如果经过商议之后，确定其是一个真正的缺陷，则可以根据缺陷的严重程度或优先级等立即处理或延期处理。
• 复测：开发人员修改好缺陷之后，测试人员重新进行测试（复测），检测缺陷是否确实已经修改。如果未被正确修改，则重新提交缺陷。
• 关闭：测试人员重新测试之后，如果缺陷已经被正确修改，则将缺陷关闭，整个缺陷处理完成。

7、多学一招：缺陷 告（由测试人员完成）

测试人员在提交软件测试时都会按照公司规定的模板（Word、Excel、缺陷管理软件等）将缺陷的详细情况记录下来生成缺陷 告，每个公司的缺陷 告模板并不相同，但一般都会包括缺陷的编 、类型、严重程度、优先级、测试环境等，有时还会有测试人员的建议。

8、常见软件缺陷管理工具

（1）Bugzilla

• Bugzilla是Mozilla公司提供的一款免费的软件缺陷管理工具。
• Bugzilla能够建立一个完整的缺陷跟踪体系，包括缺陷跟踪、记录、缺陷 告、处理解决情况等。
• 使用Bugzilla管理软件缺陷时，测试人员可以在Bugzilla上提交缺陷 告，Bugzilla会将缺陷转给相应的开发者，开发者可以使用Bugzilla做一个工作表，标明要做的事情的优先级、时间安排和跟踪记录。

（2）禅道

• 禅道是一款优秀的国产项目管理软件，它集产品管理、项目管理、质量管理、缺陷管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。
• 禅道分为专业和开源两个版本，专业版是收费软件，开源版是免费软件，对于日常的项目管理，开源版本已经足够使用。

（3）JIRA

• JIRA是Atlassian公司开发的项目与实务跟踪工具，被广泛用于缺陷跟踪、客户实务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA配置灵活、功能全面、部署简单、扩展丰富、易用性好，是目前比较流行的基于Java架构的管理工具。
• JIRA软件有两个认可度很高的特色：第一个是Atlassian公司对该开源项目实行免费提供缺陷跟踪服务；第二个是用户在购买JIRA软件同时将源代码也购置进来，方便做二次开发。

9、修复软件缺陷的成本

软件开发过程是使用软件工程的方法，在整个过程中，都有可能出现各种各样的软件缺陷。**随着开发时间的推移，软件缺陷修复成本呈倍数的增长。**假如早在进行分析时发现相关功能缺失，立即补上就可以了，可以说付出的代价小得几乎忽略不计。如果在发布时发现缺失某个功能，那么此时加上一个功能，相当于重新开发一样，这时的修补费用可以说高了许多。因此要尽早进行测试。

二、 软件的概述

1、软件生命周期

先来了解软件生命周期的全过程：

（2）快速原型模型

• 优点：克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。
• 缺点：原型设计较难；不利于开发人员对产品的扩展。

（4）螺旋模型

• 优点：强调了风险分析，有助于将软件质量融入开发中；小分段构建大型软件，易于计算成本；客户参与，保证项目可控性。
• 缺点：构建过程太过繁琐，不适合小型项目。

对内部质量、外部质量和使用质量进行逐一解析：

①内部质量：针对内部质量需求被测量和评价的质量，可维护性、灵活性、可移植性、可重用性、可读性、可测试性、可理解性。

②外部质量：使用外部度量在模拟环境中，用模拟数据测试时，所被测量和评价的质量，即在预定的系统环境中运行时可能达到的质量水平。正确性、可用性、效率、可靠性、完整性、适应性、精确性、坚固性。

③使用质量：在规定的使用环境下，软件产品使特定用户在达到规定目标方面的能力。有效性、生产率、安全性、满意程度等。

三、 软件测试的概述

1、软件测试的发展

软件测试的发展也经历了一个漫长的过程，其发展过程可用下图表示：

• 白盒测试：测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚的知道从输入到输出的每一步过程。

2、常见软件测试模型

（1）V模型

• 优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。
• 缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。

V模型流程图如下：

（3）H模型

• 设计原理：H模型的设计原理是将测试活动完全独立了出来，形成一个完全独立的流程，这个流程将测试准备活动和测试执行活动清晰的体现出来。测试流程和其他工作流程是并发执行的，只要某一个工作流程的条件成熟就可以开始进行测试。

• 优点：

  • 开发的H模型揭示了软件测试除测试执行外，还有很多工作；
  • 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
  • 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
  • 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

• 缺点：

  • 管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
  • 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
  • 测试就绪点分析困难：测试很多的时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；
  • 对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。

H模型流程图如下：

经验小结：

• v模型适用于中小企业，w模型适用于中大型企业（因为人员要求高），h模型人员要求非常高，很少有公司使用；
• 结合W模型与H模型进行工作，软件各方面的测试内容是以W模型为准，而测试周期、测试计划和进度是以H模型为指导。X模型更多是作为最终测试、熟练性测试的模板，例如，对一个业务的测试已经有2年时间，则可以使用X模型进行模块化的、探索性的方向测试。

五、 软件测试的原则

1、软件测试的原则

（1）测试应基于客户需求

所有的测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。有时候，软件产品的测试结果非常完美，但却不是客户最终想要的产品，那么软件产品的开发就是失败的，而测试工作也是没有任何意义的。因此测试应依照客户的需求配置环境并且按照客户的使用习惯进行测试并评价结果。

（2）测试要尽早进行和不断进行

软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早的开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制定出完善的计划和方案，提高测试的效率。

（3）穷举测试是不可能的

由于时间和资源的限制，进行完全（各种输入和输出的全部组合）的测试是不可能的，测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。

（4）遵循GoodEnough原则

GoodEnough原则是指测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费。随着测试资源投入的增加，测试的产出也是增加的，但当投入达到一定的比例后，测试的效果就不会明显增强了。因此在测试时要根据实际要求和产品质量考虑测试的投入，最好使测试投入与产出达到一个GoodEnough状态。

（5）测试缺陷要符合“二八”定理

一般情况下，软件80%的缺陷会集中在20%的模块中，缺陷并不是平均分布的。因此在测试时，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的缺陷，则要投入更多的人力、精力重点测试这些模块以提高测试效率。

（6）避免缺陷免疫

测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和测试对象过于熟悉，形成了思维定势。

六、 软件测试的流程

1、软件测试的基本流程

不同类型的软件产品测试的方式和重点不一样，测试流程也会不一样。同样类型的软件产品，不同的公司所制定的测试流程也会不一样。虽然不同软件的详细测试步骤不同，但它们所遵循的最基本的测试流程是一样的。