【软件测试】浅了解什么是软件测试及开发测试模型

目录

1.什么是软件测试？

2.什么是需求？

3.什么是测试用例

4.什么是软件错误（bug）？

5.开发模型和测试模型

5.1软件的生命周期

5.2瀑布模型

5.3螺旋模型

5.4软件测试V模型

5.5软件测试w模型

6.软件测试的生命周期

7.bug的生命周期

---

1.什么是软件测试？

最常见的理解是：软件测试就是找 BUG ，发现缺陷。

现实生活中在很多情况下我们都在默默进行测试：

刚新买来一部手机，我们要干什么？

一场考试 , 做完一遍题目之后 , 进行一遍检查 , 就是在 " 测试 "

买一台电视 , 安装好之后打开试试看能不能正常使用 , 也是在 " 测试 "

软件测试 就是验证软件产品特性是否满足用户的需求 。

软件测试的特点：

        软件测试只是一个样本试验，具有不可穷尽性。

2.什么是需求？

需求：满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

IEEE 定义：软件需求是（1） 用户解决问题或达到目标所需条件或权能 (Capability) 。 (2) 系统或系统部件要 满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面 (1) 或 (2) 所述条件或 权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性 能要求，质量标准，或者设计限制

在多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求

用户需求： 可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。

软件需求： 或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求 。

从软件测试人员的角度看需求：

需求是测试人员开展软件测试工作的依据。

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

过程如下，业务需求 —>软件功能需求点—>测试需求点—>测试用例

3.什么是测试用例

测试用例（Test Case ）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含： 测试环境、操作步骤、测试数据、预期结果 等要素。

测试用例解决了两大问题：测什么，怎么测。

例如：

测试一个登录页面。

测试环境：chrome浏览器

操作步骤：输入账号，输入密码，点击登录

测试数据：账号3874482，密码111111

预期结果：登录成功

4.什么是软件错误（bug）？

第一个 bug ：

1945 年 9 月的某天，在一间老式建筑里，从窗外飞进来一只飞蛾，此时 Hopper 正埋头工作在一台名为Mark Il 的计算机前，并没有注意到这只即将造就历史事件的飞蛾。这台计算机使用了大量的继电器（电 子机械装置，那时还没有使用晶体管）。突然， Mark II 死机了。 Hopper 试了很多次还是不能启动，他 开始用各种方法查找问题，最后定位到了某个电路板的继电器上。 Hopper 观察这个继电器，惊奇地发 现一只飞蛾已经被继电器打死。 Hopper 小心地用镊子将飞蛾夹出来，用透明胶布贴到 “ 事件记录本 ” 中， 写上 “ 第一个发现虫子的实例 ” 。 Hopper 的事件记录本，连同那只飞蛾，现在都陈列在美国历史博物馆 中。

软件错误的一般定义： 程序与规格说明之前不匹配 。

注意：以上说法是片面的，准确的来说： 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。

当需求规格说明书没有提到的功能，判断标准以最终用户为准： 当程序没有实现其最终用户合理预期的功能要求时，就是软件错误（bug）。

5.开发模型和测试模型

随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编 写，而是扩展到了整个软件生命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部 署、运行维护，直到软件被更新和替换新的版本。软件工程还包括很多技术性的管理工作，例如过程管 理、产品管理、资源管理和质量管理，在这些方面也逐步地建立起了标准或规范。

5.1软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成 6 个阶段，即需求分析、计划、、设计、编码、测试、运行维护。

5.2瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

瀑布模型的优缺点如下：

优点： 1. 强调开发的阶段性；

            2. 强调早期计划及需求调查；

            3. 强调产品测试。

缺点： 1. 依赖于早期进行的 唯一一次需求调查，不能适应需求的变化；

            2. 由于是单一流程，开发中的经验教训不能反馈应用于本产 品的过程；

            3.风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶 段的工作大面积返工，业界流行的说法是： “ 集成之日就是爆炸之日 ” 。尽管瀑布模型存在很大的缺陷， 例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经 很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这 个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。

在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

5.3螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代 表之一。

这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重 要性就不言而喻了。

 螺旋模型的优缺点如下：

优点： 1. 强调严格的全过程风险管理。

            2. 强调各开发阶段的质量。 – 提供机会检讨项目是否有价值继续下 去。

缺点： 1. 引入非常严格的风险识别、风险分析和风险控制（这对风险管理的技能水平提出了         很高的要求。这需要人员、资金和时间的投入）

5.4软件测试V模型

 

V 模型最早是由 Paul Rook 在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种。

1.明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间 各阶段的对应关系

2.V 模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功 能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同 的要求

3.局限性 : 仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

5.5软件测试w模型

W 模型增加了软件各开发阶段中应同步进行的验证和确认活动。 W 模型由两个 V 字型模型组成，分

别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W 模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的

W 模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需 求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度 和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。

局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系， 上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复 杂多变的情况， W 模型并不能解除测试管理面临着困惑。

6.软件测试的生命周期

软件测试的生命周期： 需求分析 →测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

软件测试&软件开发生命周期 :

需求阶段

– 测试人员了解需求、对需求进行分解，得出测试需求

计划阶段

-根据需求编写测试计划 / 测试方案

设计阶段

– 测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据 需求和设计编写一部分测试用例

编码阶段

– 测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。

测试阶段

– 测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告。

运行维护

– 测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集 问题并及时反馈给相关负责人。

7.bug的生命周期

● New:新发现的 Bug ，未经评审决定是否指派给开发人员进行修改。

● Open ：确认是 Bug ，并且认为需要进行修改，指派给相应的开发人员。

● Fixed: 开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

● Rejected ：如果认为不是 Bug ，则拒绝修改。

● Delay: 如果认为暂时不需要修改或暂时不能修改，则延后修改。

● Closed ：修改状态的 Bug 经测试人员的回归测斌验证通过，则关闭 Bug 。

● Reopen ：如果经验证 Bug 仍然存在，则需要重新打开 Bug ，开发人员重新修改。

无效的 bug ： open->closed open-rejected-closed

Bug 的跟踪以及状态变更应该遵循一些基本原则：

1.测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同 的问题不再出现，才能关闭缺陷。

2.对于拒绝修改和延迟修改的 Bug ，需要经过包含测试人员代表和开发人员代表、用户方面的代表

（或代表用户角度的人）的评审。