【软件测试理论003】软件开发与测试模型

螺旋模型作为一种独特的方法体系，其核心在于其风险驱动的特性。它通过将开发过程划分为多个螺旋周期，每个周期都紧密结合了瀑布模型的各阶段，并在坐标的四个象限中分别体现了制定计划、风险分析、实施工程以及客户评估等活动。这种循环往复的螺旋式推进方式，使得项目团队能够在每个阶段开始前和循环迭代时，进行及时的风险评估，从而确保项目的稳健进行。

螺旋模型的优点

螺旋模型显著的优势在于其风险管理的有效性。在每个阶段，项目团队都需要进行风险评估，这不仅有助于识别潜在的风险点，还能为制定针对性的风险应对措施提供有力支持。因此，螺旋模型特别适合那些风险较高的项目，通过持续的风险监控和调整，能够大大降低项目失败的可能性。

螺旋模型的缺点

螺旋模型也存在一些不可忽视的缺点。首先，它要求项目团队具备丰富的风险评估经验和专门知识，否则可能无法准确识别风险，从而导致项目出现重大损失。其次，过多的迭代次数可能会增加开发成本，并延迟项目的提交时间。因此，在选择螺旋模型时，需要权衡其风险管理的优势与可能带来的额外成本和时间压力。

1.4 敏捷开发模型

学习程度：了解

敏捷开发是一种注重用户需求驱动和快速响应变化的软件开发模型。它采用迭代和循序渐进的方式进行项目构建，将整体软件项目切分为多个相互关联但可独立运行的小项目或模块。每个小项目的成果都经过严格测试，确保具备可测试性、可视性、可集成性和可运行使用的特性。通过这种方式，敏捷开发保证了软件在开发过程中始终处于可使用的状态，能够持续为用户提供价值。敏捷模型强调团队成员间的紧密协作、面对面的沟通以及持续反馈，从而快速适应变化，提升软件质量和开发效率。

价值观

【个体和互动】比【流程和工具】更重要：强调团队成员之间的沟通和合作，以及他们与客户之间的互动，认为这比严格遵循流程和使用特定工具更重要。
【工作的软件】比【详尽的文档】更重要：注重实际的软件产品，认为软件是交付的最终目标，而不是文档。通过迭代开发，尽早交付可工作的软件，并在此基础上持续改进。
【客户合作】比【合同谈判】更重要：强调与客户的密切合作，不仅是在项目开始阶段，而是在整个开发过程中持续进行。通过与客户频繁沟通和反馈，及时调整和满足客户需求。
【响应变化】比【遵循计划】更重要：认识到需求和环境的变化是不可避免的，因此注重灵活性和适应性，随时准备调整计划和优先级，以满足变化的需求。

敏捷原则

敏捷开发的12条原则如下：

我们的最高目标是通过尽早和持续地交付有价值的软件来满足客户。这意味着团队应该优先关注交付客户真正需要的软件功能，而非过度关注非核心或不必要的部分。
欢迎对需求提出变更。在敏捷过程中，我们接受并欢迎需求的变化，甚至是在开发后期。这种灵活性使我们能够迅速响应市场变化，为客户提供更好的解决方案。
持续交付可工作的软件。团队应该频繁地交付可工作的软件，而不是等到所有功能都完成后再进行交付。这样可以确保客户能够尽早看到成果，并提供反馈。
业务人员与开发人员紧密合作。在项目过程中，业务人员和开发人员应该每天在一起工作，以便更好地理解和满足客户需求。
激发团队成员的积极性和创造力。为项目人员提供所需的环境和支持，并相信他们能够完成任务。这有助于创建一个积极的工作氛围，提高团队的工作效率。
面对面交谈是最高效的沟通方式。在团队内部和各个团队之间，面对面的沟通通常比电子邮件、会议等其他方式更为高效。这有助于减少误解，提高沟通质量。
可工作的软件是衡量进度的首要指标。相比传统的文档或代码行数等衡量标准，可工作的软件更能直观地反映项目的进度和成果。
可持续的开发速度。敏捷过程提倡保持一个稳定、可持续的开发速度，以确保项目能够按时、按质完成。
重视技术卓越和好的设计。通过关注技术卓越和良好的设计，可以提高软件的质量和可维护性，从而增强敏捷性。
简化工作流程。尽量减少不必要的工作，以提高团队的工作效率。这是一种艺术，需要我们在实践中不断摸索和优化。
最佳的架构、需求和设计出自自组织团队。相信并授权团队自主决策，根据项目的实际情况和需求来制定合适的架构、需求和设计。
定期回顾和反省。团队应该定期回顾项目进展，分析存在的问题，并制定相应的改进措施。这有助于团队不断优化工作流程，提高开发效率和质量。

敏捷开发之Scrum

Scrum是一种轻量级的敏捷开发框架，强调增量和迭代式的开发过程。在Scrum中，整个项目被划分为多个小的迭代周期，每个周期称为一个Sprint（即项目开发过程中的最小迭代周期），通常建议的长度为2-4周。Scrum旨在帮助团队、组织和个人通过自适应的解决方案应对复杂问题，创造价值。作为一种融合了迭代和增量开发原则的开发方法，Scrum在现代项目开发管理中得到了广泛应用。

Scrum的优势体现

Scrum相较于传统的开发模式，更加突出自组织的特性，能够有效调动项目开发人员的自主性和积极性。它强调团队的透明性和协作效率，通过引入“Scrum Master” 这一角色，平衡了项目经理与开发人员之间的权力关系，增加了开发人员的话语权。此外，Scrum采用迭代的工作方式，不仅在团队内部进行定期总结，还对外进行定期汇报，从而确保项目在效率、质量和透明度方面达到最佳平衡。

从职位设置看Scrum

在Scrum框架中，有几个核心概念和关键角色共同构成了其独特的项目管理方式。

核心概念：

Sprint：指一个最小的开发周期，通常是2-4周的时间，期间团队会完成一系列预定的工作任务。
Backlog：即产品待办事项列表，包含了所有需要完成的产品功能或需求，并根据优先级进行排序。

关键角色：

Product Owner（主要指产品经理）：主要负责代表利益相关方管理产品backlog，确保其与业务目标保持一致，并确定需求的优先级。
Scrum Master（项目主管）：作为项目过程中的引导者和服务者，确保Scrum过程的顺利进行，帮助团队解决障碍，促进团队协作。
Development Team（项目开发人员）：由跨职能的开发人员组成，负责在每个Sprint中交付高质量的产品增量。

这样的职位设置确保了Scrum流程的高效运作。Product Owner确保了项目与业务需求的一致性，并为团队提供了明确的工作方向。Scrum Master则作为团队的协调者和保护者，确保项目按照Scrum的原则和规则进行，并帮助团队解决遇到的问题。而Development Team则专注于任务的执行和交付，根据每个Sprint的目标来推进项目。

这样的分工避免了项目经理频繁变更需求和增加任务的情况，使团队能够按照自身的节奏和实际情况推进项目。同时，Scrum Master的存在确保了项目的稳步进行，通过引导团队、解决冲突和确保流程的正确执行，为项目的成功提供了有力保障。

从流程上看Scrum

1. 确定产品负责人（Product Owner）

产品负责人是团队中的关键角色，必须清晰了解团队需要开发的产品以及期望达到的成果。在一个项目团队中，只能有一个产品负责人，其负责代表利益相关者，并决定产品的发展方向。与之对应的，团队中可以有多个产品经理，每个产品经理负责管理一个模块的功能，但产品负责人是他们的代表。

2. 组建敏捷小组（Scrum Team）

在一个项目团队中，可以根据功能模块的不同组建多个敏捷小组，例如，一个小组负责开发前端界面，另一个负责支付功能，还有一个负责社交功能等。每个敏捷小组应该由3到9名成员组成，这个范围内的人数有助于保持良好的沟通和协作效率。超过9人的小组将增加沟通路径的复杂性，可能影响团队间的协作和工作效率。

3. 确定敏捷教练（Scrum Master）

敏捷教练在团队中扮演着关键的角色，他们负责进行敏捷培训，管理工作进度，优化项目流程，解决团队成员遇到的问题，以提高整个敏捷小组的工作效率，确保项目顺利交付。

如果团队只有一个敏捷小组，通常由项目经理兼任敏捷教练的角色。但如果团队有多个敏捷小组，则需要为每个小组指定一个敏捷教练，简称为SM。在这种情况下，项目经理负责统筹管理每个敏捷小组和其对应的Scrum Master。

举例来说，一个软件研发团队可能包含三个敏捷小组，分别负责前端开发、后端开发和测试。在这种情况下，每个小组的高级工程师或技术专家可以担任Scrum Master，而项目经理则需要对这些Scrum Master进行敏捷培训，使他们能够有效地指导小组成员，形成一个协作高效的敏捷团队。

4. 拟定产品需求（Product Backlog）

产品需求的拟定是由产品负责人负责的重要任务。首先，产品负责人需要权衡各个需求，并根据其重要性和价值来排列需求的优先顺序。其次，产品负责人需要清晰地向团队传达产品待办列表，确保每个人都清楚下一步应该做什么工作。第三，产品待办列表必须是可见且透明的，以确保所有人都了解团队的工作方向。最后，在创建产品待办列表时，需要包括测试描述，以便在任务完成时验证产品的完整性。

同时，产品负责人应该倾听团队对列表的建议，并根据需要进行调整。例如，如果开发团队认为工作量过多或过少，可以与产品负责人重新协商。此外，开发团队也可以邀请技术专家参与讨论，以确保需求的可行性和有效性。

产品待办列表代表了各方的业务需求，因此任何变更或对优先级的调整都必须经过产品负责人的批准。产品待办列表的内容和顺序必须是透明可见的，任何人都不能强迫开发团队处理列表范围之外的需求工作。

5. 需求评审会和点数评估

团队通过需求评审会来审查产品负责人提出的需求，这个会议通常由产品负责人和团队中的技术专家共同参与。在评审过程中，他们会评估每个需求所需的技术、人力和时间，并提出改进意见或者直接驳回不合理的需求。评审会讨论的问题包括：

评审会的最终目的是确保每个需求都是切实可行的，并且对团队可执行。此外，在Scrum中，通常使用点数来评估需求的工作量，而不是直接使用人天或人时。点数通常采用斐波那契数列（1，2，3，5，8，13，21……），这种规律能更好地比较需求之间的差异。通过对比评估，团队能够更准确地估算出工作量，以便在规划和执行过程中做出合理的决策。

6. 冲刺规划会

在每个迭代周期，也就是我们所称的Sprint中，团队都会进行冲刺规划会议。冲刺周期通常是固定的，一般为2至6周不等。在这个会议上，团队成员、敏捷教练以及产品负责人会聚在一起，共同规划即将展开的冲刺。

7. 工作透明化

Scrum强调工作的透明化，允许团队外的人员参加内部会议。每个成员的工作都是公开透明的，常见的做法是准备一块白板，分成三栏：待办事项、在办事项、完成事项。将待办事项写在便笺纸上，随着进展移动到其他栏目。此外，也可以借助项目管理软件如PingCode、Jira等记录任务，达到与白板相似的效果。

8. 每日立会

每日立会是全员参与的会议，固定在特定的时间和地点进行，通常持续时间不超过15分钟，并以站立形式进行。每位团队成员只需回答以下三个问题：

成员在回答问题时，只需要关注进度、计划和问题，以提高会议效率，不耗费过多时间。具体事项可在会后讨论。通过这种反馈机制，敏捷教练能够有效掌控项目进度，并协助团队成员解决工作中的障碍。

9. 冲刺评估

冲刺评估是在冲刺结束前进行的，团队成员向产品负责人展示项目成果，并接受评价。这是一场公开的会议，任何人都可以参与，包括产品负责人、敏捷教练、开发团队、利益相关者、管理人员和客户。

10. 反思会

反思会是通过举行回顾会议来总结本次冲刺中遇到的问题、阻碍、优点和改进建议。通过优化流程规范，提高下次冲刺的工作效率，为进入下一个迭代做好准备。

2 软件测试模型

在软件开发过程中，软件测试是保证软件质量的关键环节。为了指导软件测试的实施，人们提出了多种软件测试模型。这些模型不仅描述了测试活动的组织方式，还揭示了测试与开发之间的关系。以下是几种常见的软件测试模型及其特点。

2.1 V模型

学习程度：掌握

V模型适用于中小型项目

V模型是软件测试领域中最具代表性的模型之一，其概念由Paul Rook在20世纪80年代后期提出，并在英国国家计算机中心的文献中正式发布。该模型的初衷在于提升软件开发的效率和质量，将测试活动贯穿于整个开发流程中，而非仅仅作为项目收尾的一个阶段。

在V模型推出之前，测试往往被视为在需求分析、设计、编码等阶段全部完成之后的一个孤立环节。尽管当时已经意识到测试工作可能占据项目周期的一半时间，但多数人仍将其视为一个收尾任务，未能充分重视其在软件开发中的重要性。

V模型作为瀑布模型在测试领域的延伸，深刻反映了测试活动与分析和设计之间的紧密关系。它清晰地标明了测试过程中存在的不同阶段，从左至右依次对应开发过程中的需求分析、设计、编码等阶段，展示了开发与测试之间的阶段对应关系。

通过V模型，我们得以更加系统地规划和执行测试活动，确保软件质量从设计之初就得到充分考虑。同时，V模型也提醒我们，测试不仅仅是发现错误的过程，更是验证软件是否满足用户需求、是否达到预期效果的重要手段。

各阶段任务

1. 需求分析阶段

明确客户对于产品的需求，软件需要具备的功能模块，以及软件需要适应的硬件功能。分析师需要准确理解客户的需求，并编写出需求规格说明书。

2. 概要设计阶段

搭建架构，表述各模块功能、模块接口、模块数据的传递等事务。

3. 详细设计阶段

对概要设计中表述的各模块进行深入分析，达到伪代码级别，把程序的具体实现的功能、现象等描述出来。

4. 编码实现阶段

编程人员按照详细设计中模块的功能表编写出实际的代码。

5. 单元测试阶段

对软件设计中的最小单位——模块进行测试，检查模块内部的逻辑和功能是否正确。

6. 集成测试阶段

将各个模块按照设计要求组装在一起进行测试，检查模块之间的接口是否正确，数据流是否畅通。

7. 系统测试阶段

将软件作为一个整体进行测试，检查软件是否满足需求规格说明书中的要求。

8. 验收测试阶段

由客户或相关利益方对软件进行测试，确认软件是否符合预期，是否满足验收标准。

V模型的优点

全面的测试覆盖：V模型在软件测试中实现了从底层单元测试到高层系统测试的全面覆盖。这种覆盖确保了软件从各个层面都得到了充分的检验，从而提高了软件的质量和可靠性。
阶段划分明确：V模型清晰地将软件开发过程划分为不同的阶段，每个阶段都有明确的任务和目标。这种划分使得开发过程更加有序，便于项目管理和进度控制。
易于控制开发过程：由于V模型在每个阶段都有明确的输出和交付物，这使得开发团队能够更好地控制开发过程，确保每个阶段都达到预期的目标。
便于问题定位与解决：由于V模型将开发过程划分为多个阶段，当出现问题时，可以更容易地定位问题所在，并采取相应的措施进行解决。

V模型的缺点

顺序性导致的延迟反馈：V模型的一大缺点是其顺序性。在编码完成之前，测试活动往往无法进行，这导致错误可能在编码阶段之后才发现，从而增加了修复错误的成本和难度。
需求变更应对不足：V模型在需求阶段就要求对用户需求进行明确，但在实际开发中，用户需求往往难以完全明确且容易发生变化。当需求变更时，V模型往往需要重新进行之前的阶段，导致开发过程变得冗长和复杂。
模型灵活性低：由于V模型严格按照阶段顺序进行，当项目需求或环境发生变化时，模型难以灵活调整，可能导致开发过程与实际需求脱节。
测试与开发的分离：V模型将测试和开发划分为相对独立的阶段，这可能导致测试人员与开发人员之间的沟通不畅，影响测试的有效性和开发效率。

2.2 W模型

学习程度：掌握

V模型适用于大型项目

IEEE Std 1012-1998《软件验证和确认（V&V）》的原则明确指出，软件的需求和设计阶段同样应当包含测试活动，这确保了软件开发的每一环节都能得到充分的验证和确认。这一原则强调了测试在软件开发中的关键地位，确保软件质量从源头得到控制。

W模型，由Evolutif公司提出，是对V模型的一种重要拓展和改进。在W模型中，开发活动与测试活动并行进行，形成两个相互交织的V，组合成一个W的形状。这种模型强调了测试与开发的紧密集成，使得测试活动能够更早地介入到软件开发过程中，从而及时发现问题并进行修复。

在W模型中，测试伴随着整个软件开发周期，从需求分析、设计、编码到集成和部署等各个阶段，都有相应的测试活动。这确保了软件开发的每一个环节都能得到充分的验证和确认，从而提高了软件的质量和可靠性。

值得注意的是，W模型不仅关注对程序的测试，还强调对需求和设计的测试。这是因为需求和设计是软件开发的基石，它们的正确性直接决定了软件的质量。通过对需求和设计的测试，可以尽早地发现潜在的问题，避免在后续的开发过程中出现重大错误。

W模型的优点

全程测试覆盖：W模型强调测试活动贯穿于整个软件开发周期，从需求分析到概要设计，再到具体的编码实现，都有相应的测试环节。这种全面的测试覆盖确保了软件的质量从源头得到把控，减少了潜在缺陷的遗漏。
提前发现问题：由于测试活动在开发初期就介入，W模型能够更早地发现潜在的问题和缺陷。这使得开发团队能够以更低的成本进行缺陷修复，避免在后期出现更大的问题，提高了软件开发的效率。
便于项目控制：W模型将软件开发过程划分为不同的阶段，每个阶段都有明确的测试任务和目标。这种分阶段的工作使得项目过程更加可控，便于开发团队进行进度管理和风险控制。

W模型的缺点

线性关系限制：W模型仍然依赖于软件开发和软件测试之间的线性关系，这在一定程度上限制了模型的灵活性。它难以支持迭代开发、自发性和需求的变更调整，对于快速变化的项目环境可能不太适用。
文档依赖性：W模型强调对需求和设计的测试，这通常依赖于详细的文档。然而，在实际项目中，很多团队可能并不产生完整的文档，这使得W模型在某些情况下难以适用。
技术复杂度高：W模型对测试人员的技术要求较高，特别是对需求和设计的测试。实践起来可能存在一定的困难，需要测试人员具备扎实的业务知识和丰富的测试经验。

2.3 H模型

学习程度：了解

H模型诞生背景

在软件开发实践中，尽管需求、设计、编码等活动常被划分为不同的阶段进行，但人们逐渐认识到这些活动并非完全线性执行。相反，它们在实际操作中往往呈现出交叉进行和迭代执行的特点。这种灵活性和迭代性使得传统的分阶段测试模型难以完全适应。

为了解决这一问题，专家们提出了H模型。这一模型的核心思想是将测试活动作为一个完全独立的流程来对待，使其从整个软件开发流程中独立出来。通过将测试准备和测试执行两个关键阶段清晰展现，H模型旨在确保测试工作的连贯性和高效性。

H模型的引入，不仅解决了传统测试模型难以适应迭代开发的问题，还提高了测试工作的灵活性和适应性。它使得测试人员能够更好地配合开发团队，确保软件质量在开发过程中得到及时有效的验证。

测试流程

H模型中的测试流程主要包括测试准备、测试就绪点、测试执行以及其他流程。以下是对这些流程的详细解释：

测试准备

在H模型中，测试准备是测试流程的关键起始阶段。这一阶段主要涵盖了测试所需的所有前期准备工作，包括但不限于测试环境的搭建、测试数据的准备、测试用例的设计等。
测试人员需要根据项目需求和设计文档，制定详细的测试计划，并编写出覆盖所有关键功能的测试用例。
同时，测试团队还需要确保测试工具和相关资源的准备充分，以便后续测试活动的顺利进行。

测试就绪点

测试就绪点是H模型中一个非常重要的概念，它代表着测试活动可以开始执行的条件。
在测试准备完成后，测试团队需要评估当前的状态是否满足测试就绪点的要求。这通常涉及对测试环境、测试用例、测试数据等的全面检查，确保它们都已准备就绪。
一旦达到测试就绪点，测试团队就可以启动测试执行活动。测试就绪点的判断对于测试流程的顺利进行至关重要，它避免了过早或过晚进行测试，从而确保了测试的有效性。

测试执行

测试执行是测试流程中的核心阶段，它涉及按照测试计划和测试用例执行具体的测试活动。
在测试执行过程中，测试人员会操作被测软件，记录测试结果，并对发现的问题进行缺陷管理。这包括缺陷的识别、记录、跟踪以及验证修复等工作。
测试执行需要遵循严格的流程和规范，确保测试的准确性和一致性。测试人员还需要根据测试结果，及时与开发团队沟通，推动问题的及时解决。

其他流程

在H模型中，测试流程并不是孤立的，它与其他开发流程如设计流程、编码流程等存在交互和协同。
测试团队需要与设计团队、开发团队等紧密合作，确保测试活动能够与其他流程同步进行，共同推动项目的进展。
同时，测试团队还需要关注项目的整体进度和需求变更情况，及时调整测试计划和策略，以适应项目的变化。

H模型的优点

测试工作的全面揭示：H模型不仅关注测试执行，还强调了测试准备、测试就绪点等关键阶段，从而全面揭示了软件测试的复杂性及多元性。
独立性与并发性：在H模型中，测试流程被设计为完全独立的，它贯穿整个软件生命周期，并与其他开发流程如设计、编码等并发进行，确保了测试活动的及时性和有效性。
灵活性与迭代性：H模型允许测试活动尽早准备和执行，这使得测试可以根据实际情况灵活调整，同时支持分层、分阶段、分次序的执行，也支持迭代执行，从而适应不断变化的项目需求。
适应性强：H模型对于不同被测物的测试能够做出适应性的调整，根据被测物的特性和需求，可以灵活调整测试策略和步骤。

H模型的缺点

高管理要求：由于H模型的灵活性，需要制定清晰的规则和管理制度来规范测试过程，否则可能导致测试活动的混乱和难以控制。
技能要求严格：H模型要求测试人员能够精确界定每个迭代的规模，这既需要深厚的测试经验，又需要良好的项目管理和分析能力。
测试就绪点判断难：在H模型中，测试就绪点的判断是一个难点，因为很难准确界定测试准备到什么程度是合适的，缺乏明确的标准可能导致测试执行的延误或提前。
对人员素质要求高：H模型的高效运行依赖于整个项目组的高水平协作和高效执行。如果人员技能不足或规范执行不到位，可能会导致项目进展受阻或质量下降。

Thanks_ks

关注

31
点赞
踩
28

收藏

觉得还不错? 一键收藏
打赏
1
评论
【软件测试理论003】软件开发与测试模型

本博客全面概述了软件开发和测试中的关键模型。瀑布模型以其严谨的流程和明确的阶段著称，但缺乏灵活性。快速原型模型则强调快速反馈，适合需求不明确的项目。螺旋模型通过迭代和风险管理，为大型项目提供稳定框架。敏捷开发模型凭借快速响应变化的能力，成为现代开发的热门选择。在测试领域，V模型注重测试与开发阶段的对应，W模型强调测试与开发的并行性，而H模型基于风险驱动，灵活适应测试需求。这些模型为项目管理和测试工作提供了宝贵的参考和启示。
复制链接

扫一扫