软件测试的模型

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

测试的目的是为了证明、检测。保证软件质量。

• 证明：验证软件能够正常运行
• 检测：发现尽可能多的bug

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

2：软件测试的需求

     需求：满足用户期望或文档规定的条件和全能

3：缺陷：有需求规格说明且正确，与之不匹配。需求中未提到的以用户的合理期望为标准

4：测试用例：向被测试程序输入集合，要素：环境、操作步骤、输入数据、预期结果

5：开发模型

      瀑布模型：需求稳定，串行
      螺旋模型：复杂、规模庞大、风险大，强调风险
      增量、迭代：适合需求频繁变更的项目，用户可以一直参与，降低风险
      敏捷（价值观）：个体与交互重于过程和工具（人与人之间的沟通）
                 可用的软件重于完备的文档（轻文档）
                 客户协作重于合同谈判（客户参与）
                 响应变化重于遵循计划（拥抱变更）        颠覆了传统模式，瀑布模型要求需求尽量不要变更
               （在每对比对中，后者并非全无价值，但我们更看重前者。） 

      敏捷开发有很多方式，其中scrum是比较流行的一种
      scrum由product owner(产品经理) 、 scrom master(敏捷教练) 、 team(研发团队)组成
      product owner 负责整理user story(用户故事)
      scrum master 负责召开各种会议，协调项目，为研发团队服务
      敏捷流程：
         1）产品负责人负责整理user story，形成左侧的product backlog。
         2）发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出 这一期迭代要完成的story列表，print backlog。 
         3）迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计 
         4）每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题 
         5）演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理形成新的story。 
         6）回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改 进的效果。 

迭代开发：

与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

6：敏捷中的测试：

挑战1：轻文档

挑战2：快速迭代

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

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

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

7：软件测试的生命周期

      需求分析-测试计划-测试执行、测试开发-测试执行-测试评估

8：软件测试的模型（V模型、W模型）

V模型：

V模型早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种
1）明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系    

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

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

V模型：
单元测试 集成测试 是由研发人员或白盒测试工程师完成
系统测试阶段由测试人员完成 环境搭建 数据准备 测试执行 缺陷管理 测试 告的编写
验收测试：协助用户完成验收测试
                                                                                

  W模型：

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

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

3）W模型优缺点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和 确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制 定应对措施，显著减少总体测试时间，加快项目进度。局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

W模型（双V模型）：
第一个V为研发线
第二个V为测试线
测试线研发线并行，解决了V模型中的局限性（仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试）

9：Bug状态转换图

测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。

bug的级别：崩溃（Blocker）、严重（Critical）、一般（Major）、次要（Minor）

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

一个合格的bug描述应该包括以下几个部分：

1）发现问题的版本

开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。

2）问题出现的环境

环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3）错误重现的步骤

描述问题重现的最短步骤。

4）预期行为的描述

5）错误的描述

描述错误的现象。crash等可以上传log，UI问题可以有截图。 

6）其它

某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严 重影响测试需要开发人员优先修改的，可以设置优先级为高。
不要把多个bug放到一起，在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。
 

10：配置管理

1）什么是配置管理

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

2）配置管理的应用

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

3）实施配置管理的好处

实施软件配置管理(SCM)，至少能给项目团队带来如下好处。 (1)能够对项目中的文档、代码等的变化进行有效管 理。 (2)能够方便地重现某个文件的历史版本。 (3)能够重新编译某个历史版本，使维护工作变得容易。 (4)能够使 异地多团队开发、并行开发成为现实。 (5)从公司级看，实行统一的配置管理流程可提高项目组间人员流动时的工 作效率。 

4）配置管理与软件测试

测试人员是SCM中的参与者，有些公司也会把测试人员和配置管理员合二为一。如果配置管理流程不规范，或者没 有遵循一定的配置管理流程进行软件测试活动，也可能导致很严重的后果。假设开发人员修正了一个Bug，然后找测试人员过去讨论，测试人员在开发人员的机器上重新测试了一下，发现 Bug没再出现了，修复了，这时候，如果测试人员把缺陷关闭了，则可能导致缺陷莫名其妙地在用户那边又出现 了。其实，原因可能仅仅是开发人员把这个Bug修改的代码没有提交的到配置管理数据库中。但是作为测试人员有 没有责任呢有，因为测试人员也没有按照规范的配置管理流程执行测试，测试人员应该从配置库取源代码编 译后再测试，只有看到新的构建版本不再出现那个Bug，才能把缺陷库中的Bug关闭。