软件测试——开发模型、测试模型介绍

重点掌握敏捷开发模型

软件开发过程

1.测试用例（Test Case）

2.开发模型

2.1瀑布模型（Waterfall Model）

2.2.螺旋模型（Spiral Model）

2.3增量、迭代

2.4敏捷开发

3.测试模型

3.1V模型

3.2W模型

4.配置管理与软件测试

5.描述一个BUG

5.1BUG级别

5.2bug的生命周期

软件开发过程

用户需求（分析）——软件需求文档（细化）——编码——测试——上线

需求：是满足用户期望和合同规定的文档标准、规范所需要的条件和权限。

用户需求：简单的描述，没有具体的的实现过程

软件需求：需求的细化，是对用户需求的验证（合理性、正确性），是具体功能实现的细节说明。需求是开发人员和测试人员进行开发和测试的依据，

软件的生命周期：从软件产品设计开始到软件不再使用而结束的时间。可以分成6个阶段：即需求分析、计划、、设计、编码、测试、运行维护。

软件测试生命周期（软件测试流程）：

需求分析、测试计划（测试范围、时间、人员、目的）、测试设计/开发（写测试用例）、测试执行（找BUG、管理bug、记录并跟踪）、测试评估（写测试报告：统计测试用例、bug、修改及遗留bug）。

1.测试用例（Test Case）

保证需求明确且合理才能进行测试

为了解决测试过程中遇到的问题而实施的。向被测试的系统提供的一组集合 测试用例编写包括：测试环境、操作步骤、测试数据、预期结果等要素。

常用工具：Excel、xmind或测试工具

测试用例如下：

测试遇到的问题：是否较全面的测试了所有功能、测试的覆盖率无法衡量、对新版本的重复测试很难实施、存在大量冗余测试，影响测试效率

2.开发模型

瀑布模型、螺旋模型、增量模型、迭代模型、敏捷模型；

2.1瀑布模型（Waterfall Model）

瀑布模型是所有其他模型的基础框架。瀑布模型每个阶段都只执行一次，是线性顺序进行的软件开发模式，适用于需求比较稳定的项目

优点：强调开发的阶段性、强调早期计划及需求调查、强调产品测试；

缺点： 依赖于早期进行的唯一1次需求调查，不能适应需求的变化；是单一流程，开发中的经验教训不能反馈应用于本产品的过程； 风险往往在后期的测试阶段才暴露，失去及早纠正的机会。——“集成之日就是爆炸之日”

2.2.螺旋模型（Spiral Model）

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一，适合规模庞大、复杂度高、风险大的项目。

优点： 严格的全过程风险管理、强调各开发阶段的质量、提供机会检讨项目是否有价值继续

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

2.3增量、迭代

增量开发模型能显著降低项目风险，结合软件持续构建机制。鼓励用户反馈，在每个达代过程中（涉及需求更改、构建新的可执行软件版本等），要求测试人员与开发人员更加紧密地协作，开发小组以一种循环的、可预测的方式驱动产品的开发。

增量是逐块建造的概念：先完成模块A，再模块B；

迭代是反复求精的概念：先完成所有模块的基础功能（轮廓），再进行模块的升级和细化

2.4敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

轻文档、轻流程、重目标，重产出，适应需求变化

周期较短（一般1~4周），团队人员较少、高质量可用软件

PO（Product Owner）:客户代表方，整理客户需求，形成user story，定义其商业价值，对其进行排序，制定发布计划
SM（Scrum Manager）:项目经理，管理整个开发流程，保证敏捷开发流程顺利实施
ST(Scrum Team)：研发团队，各种技术人员组成，确保交付高质量软件

敏捷scrum流程：

产品负责人负责整理user story，形成左侧的product backlog。

发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
每日例会：每天SM召集会议，团队成员汇报做了什么，计划做什么，存在什么问题。
演示会议：迭代结束之后，召开演示会议，项目人员参加，团队展示本次迭代取得的成果。期间大家的反馈记录下来，由PO整理，形成新的story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

3.测试模型

3.1V模型

V模型是瀑布模型的变种，左右每个阶段之间一一对应，左边是右边测试阶段的依据；

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

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

3.2W模型

W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示了测试与开发的并行关系,开发的同时进行验证和确认；
W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
W模型优点：测试介入较早，有利于尽早地全面的发现问题
局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段结束，才可开始下阶段工作。不支持敏捷开发模式，不能解决复杂情况下的测试

4.配置管理与软件测试

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

优点

能够对项目中的文档、代码等的变化进行有效管理。
能够方便重现某个文件的历史版本。
能够重新编译某个历史版本，使维护工作变得容易。
能够使异地多团队开发、并行开发成为现实。
统一的配置管理流程可提高项目组间人员流动时的工作效率。

常用项目管理工具：禅道、tapd、jira

5.描述一个BUG

测试版本：出问题代码对应的软件版本，有利于统计分析每个版本的质量
测试环境：硬件环境和软件环境，web项目：需描述浏览器版本、操作系统等；app项目：需描述机型、分辨率、操作系统版本等，详细的环境描述有利于故障的定位
测试步骤（数据）：描述问题重现的最短步骤（具体数据详细定位到问题）
实际结果：
预期结果：达到需求，保持一致
其他附件（错误截图、日志等）：指有用的附件

注意！！！在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

5.1BUG级别

崩溃：系统无法运行，此时需立即回退到一个系统稳定的版本
严重：系统可以运行，但是不稳定（视频画面卡顿、画面失真）
一般：系统可稳定运行，但影响用户使用及体验感
次要：建议型bug。属于可优化部分，不影响使用和体验

5.2bug的生命周期

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

新建
指派
接受
修复
关闭

若经开发人员修复之后的bug，测试时bug仍然存在？？？

1.开发人员没有正确修复

2.测试人员没有获取到最新修改后的版本进行测试