【软件测试二】开发模型和测试模型，BUG概念篇

目录

1.软件的生命周期

2.瀑布模型

3.螺旋模型

4.增量，迭代

5.敏捷---scrum

1. 敏捷宣言

2.角色

6. 软件测试v模型

7.软件测试w模型

8.软件测试的生命周期

9.如何描述一个BUG

 10.如何定义BUG的级别

 11.BUG的生命周期

12.产生争执怎么办

---

1.软件的生命周期

软件的生命周期是指从软件产品的设想开始到软件不再使用而结束的时间，如果把软件看成有生命的事务，那么软件的生命周期可以分成六个阶段，即

需求分析，计划，设计，编码，测试，运行维护

2.瀑布模型

优点：每个阶段之间都是线性的，每个阶段该做什么都清晰明了
缺点：测试人员介入需求太晚，以至于发现问题的时机太晚，从而失去及早纠正的机会

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

瀑布模型适用于需求固定的小项目

3.螺旋模型

特点，每一次实施之前，都要进行风险分析
优点，风险分析可以避免未知的问题
缺点，风险分析一旦分析错误就会带来损失，风险分析需要一定成本 （人力，实际，资金）

螺旋模型适用于需求不确定，规模庞大、复杂度高、风险大的项目。

4.增量，迭代

增量，先开发 1，然后2，3，4
迭代，先开发1部分，2部分，3部分，4部分

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

5.敏捷---scrum

1. 敏捷宣言

轻文档轻过程，重目标重产出

2.角色

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
其中
（1）product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。收集需求
（2）scrum master 负责召开各种会议，协调项目，为研发团队服务。
（3）研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
scrum的基本流程：
1. 产品经理整理用户需求，形成product backlog。

2. 发布计划会议：制定出这一期迭代要完成的story列表，sprint backlog。

3. 迭代计划会议：项目团队分解story，确定负责人。

4. 每日例会：每天scrum master召集站立会议，总结前一天的工作，阐述今天的计划，以及遇到的问题，了解项目进度。

5. 演示会议：迭代结束之后，召开演示会议，演示成果，PO整理反馈记录，有用的建议收集在用户需求。（拥抱变化）

6. 回顾会议：项目团队对本期迭代进行总结。

6. 软件测试v模型

明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间
各阶段的对应关系
V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功
能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同
的要求
局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试（测试后置）

7.软件测试w模型

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

8.软件测试的生命周期

 

9.如何描述一个BUG

 10.如何定义BUG的级别

 11.BUG的生命周期

 

12.产生争执怎么办