软件测试——概念

目录

1.软件测试的目的和原则

2. 什么是需求

2.1 IEEE定义

2.2 案例

 3.什么是bug

4.什么是测试用例

5. 开发模型和测试模型

5.1 软件的生命周期

5.2 瀑布模型型（Waterfall Model）

5.3 螺旋模型

5.4  增量、迭代

5.5 敏捷中的测试

5.6 软件测试V模型

 5.7 软件测试W模型

 6. 配置管理和软件测试

  6.1 什么是配置管理

6.2 软件配置管理的应用

6.3 实施软件配置管理的好处

 6.4 配置管理与软件测试

---

1.软件测试的目的和原则

目地：验证软件有或没有问题

原则：以客户为中心，遵循软件测试的规范|流程|标准和要求

1）好的测试方案是极可能发现尚未发生的错误和测试方案。

2)测试并不仅仅是为了找出错误。通过分析错误产生的原因、阶段及错误发生的趋势。

 一、帮助项目管理者了解当前软件开发过程中的缺陷。以便即使纠错、改进。

 二、帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性。

 三、让开发人员知道错误产生的重灾区，加强自测试。

 四、让客户清楚我们专业的质量保证团队，可以向他们提交一份满意的答卷。

3）没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一致方法。

4）根据测试目地的不同，还有回归测试、压力测试、性能测试、安全测试等，分别为了让检验修改或者优化过程。

5）软件测试为了建立软件的信心。

6）从测试的目地出发，大概可以分为两类：为了验证程序能正常工作的测试；为了验证程序不能正常运行的测试。

2. 什么是需求

2.1 IEEE定义

软件需求是

1)用户解决问题或达到目标所需条件或权能(Capability)。

2)系统或系统部件要满足合同、 标准、规范或其它正式规定文档所需具有的条件或权能。

3)一种反映上面1)或2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。

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

用户需求：

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

软件需求：或者叫功能需求

该需求会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试的基本依据

2.2 案例

一、用户需求

    平台支持邮箱注册

二、软件需求

1. 注册账号

1.1 功能概述

    用户可以通过填写邮箱信息在平台注册个人用户

1.2 用户角色

    匿名用户

1.3 前置条件

    无

1.4 输入

序号	名称	说明	长度	类型	备注
1	姓名	必填，录入个人姓名	6~15	字符型	无
2	电子邮箱	必填，录入个人电子邮箱	无规定	字符型	无
3	密码	必填，输入密码隐藏*号显示	6~15	字符型	无
4	确认密码	必填，输入密码隐藏*号显示	6~15	字符型	无
5	验证码	必填，录入验证码	无规定	字符型	无
6	注册	注册操作	无规定	操作型	无

1.5 处理

   1.5.1 基本事件流

        1.用户选择注册

         2.系统展现用户协议界面，并请用户确认是否同意用户协议

              1）若用户不同意协议，系统禁止用户注册

              2） 若用户同意协议，用户进行注册信息填写

          3. 用户填写注册信息

             注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。

          4.用户提交注册信息

          5.系统提示用户并向用户注册电子邮件地址发送含有激活信息的电子邮件。系统并提            示用户，若未收到激活邮 件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。

           6.用户可执行激活操作，直接跳转至注册邮箱门户页面

           7.用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束

  1.5.2 扩展事件流

      用户注册并激活成功后，第一次登录平台时，提示用户完善信息

  1.5.3 异常事件流

      1）若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。

      2）每次发送的激活邮件，仅在发送后起24小时之内有效，超过24小时后需要重新发送                激活邮件。

1.6 输出

     用户注册成功

1.7 后置条件

     该模块为用户登录等的前置模块

 3.什么是bug

以游戏为例：

当我们在正常运行时，突然发现打敌方，敌方一直处于无敌状态，一点事都没有，本来就要赢了，结果敌方无缘无故无敌了。

敌方无缘无故一直无敌就是bug.

凡是实现效果与需求不相符的都可以认为是bug

bug的后果：用户流失，绩效蹦

bug的责任：开发人员一定是第一个背锅侠，特定情况下，测试才会分担

bug的处理：生产环境上的问题，要第一时间回滚，在慢慢定位

bug的态度：心存敬畏，但是不要害怕，开发人员背负的bug，就是一个老兵身上的疤痕，最值得骄傲的勋章。

软件错误的一般定义：

当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是 错误。

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

4.什么是测试用例

通过重重方式测试软件的功能，   有具体步骤 ， 有预期结果， 有真实结果。

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

测试用例：单位用户注册成功
步骤动作：	期望的结果：
进入注册页面，选择注册	系统展示注册页面
输入符合要求的单位名称、单位邮箱、密码、确认密码、组织机构代码、验证码，并确认同意《用户注册协议》，提交注册信息	系统进行注册操作，发送激活邮件。注册成功后，跳转到注册成功页面，并提示用户进行激活操作。
进入注册的邮箱，进行激活操作	激活成功
进入注册用的邮箱，进行登录操作	登录成功，系统展示欢迎页面
测试方式	手工
重要性	重要
测试环境	CHROME,IE10
测试前提	系统运行正常，邮件服务器已开启
功能模块	注册登录

测试过程或者可能会遇到以下问题：

1）不知道是否全面的测试了解所有功能

2）测试的覆盖率无法衡量

3）对新版本的重复测试很难实施

4）存在大量冗余测试影响测试效率

5. 开发模型和测试模型

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

5.1 软件的生命周期

软件的生命周期是指从软件产品的设想开始到软件不在使用而结束的时间。

如果把软件看成是有生命的事物，那么软件的生命周期可以分为6个阶段，即需求分析、计划、设计、编码、测试运行维护。

5.2 瀑布模型型（Waterfall Model）

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

优点：

1）强调开发的阶段性

2）强调早期计划即需求调查；强调产品测试

缺点：

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

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

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

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是：“ 集成之日就是爆炸之日 ” 。

尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。

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

5.3 螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模式是渐进式开发模型的代表之一。对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式 给软件测试带来了新的要求 它不 允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

优点：

1）强调严格的全过程风险管理。

2）强调各开发阶段的质量。

3） 提供机会检讨项目是否有价值继续下去。

缺点：

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

5.4  增量、迭代

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个达代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚…… 而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

5.5 敏捷中的测试

挑战1：轻文档

挑战2 ：快速迭代

1 、测试工作的核心内客是没有变的，就是不断地找 Bug ，只是要调整好自己的心态，一切以敏捷的原则为主。

2 、测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试。

3 、敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究 Bug出现的原因。

5.6 软件测试V模型

 

 V模型目地是改进软件开发的效率和效果，是瀑布模型的变种。

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

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

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

 5.7 软件测试W模型

 

1）W 模型增加了软件各开发阶段中应同步进行的验证和确认活动。 W 模型由两个 V 字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

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

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

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

 6. 配置管理和软件测试

  6.1 什么是配置管理

配置管理 ( Confifiguration Management) 是通过对在软件生命周期不同的时间点上的软件配置进行标识，并对这些被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。

6.2 软件配置管理的应用

软件开发过程中会产生大量软件产品（包括文档、源代码和数据等），且这些产品之间存在关联关系。同一软件产品也会发生变更，从而产生许多版本。软件开发小组必须清晰地知道会有哪些品、这些产品会有哪些不同的形式和版本。开发小组必须清晰地知道如何将产品的变更通知给受影响的小组。如果不能有效地了解软件产品及其变更，开发小组将很难组装这些软件产品，很难得到所需的软件产品。

6.3 实施软件配置管理的好处

实施软件配置管理 (SCM) ，至少能给项目团队带来如下好处。

1)  能够对项目中的文档、代码等的变化进行有效管理。

2)  能够方便地重现某个文件的历史版本。

3)  能够重新编译某个历史版本，使维护工作变得容易。

4)  能够使异地多团队开发、并行开发成为现实。

5)  从公司级看，实行统一的配置管理流程可提高项目组间人员流动时的工作效率

 6.4 配置管理与软件测试

测试人员是 SCM 中的参与者，有些公司也会把测试人员和配置管理员合二为一。如果配置管理流程不规范，或者没有遵循一定的配置管理流程进行软件测试活动，也可能导致很严重的后果。

假设开发人员修正了一个 Bug ，然后找测试人员过去讨论，测试人员在开发人员的机器上重新测试了一下，发现Bug没再出现了，修复了，这时候，如果测试人员把缺陷关闭了，则可能导致缺陷莫名其妙地在用户那边又出现 。

其实，原因可能仅仅是开发人员把这个Bug 修改的代码没有提交的到配置管理数据库中。但是作为测试人员有没有责任呢？当然有，因为测试人员也没有按照规范的配置管理流程执行测试，测试人员应该从配置库取源代码编 译后再测试，只有看到新的构建版本不再出现那个 Bug ，才能把缺陷库中的 Bug 关闭 。