测试基础概念及常见开发模型和测试模型

目录

1.需求的概念

2.测试用例

3.什么是BUG

4.软件的生命周期

5.开发模型和测试模型

开发模型

瀑布模型

快速原型模型

螺旋模型

增量模型

敏捷方法

scrum三大角色

测试模型

V模型

W模型

---

1.需求的概念

衡量软件测试结果的依据—需求

概念：满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求

用户需求：可以简单理解为甲方提出的需求，没有甲方，就是终端用户使用产品时必须要完成的任务。不涉及技术实现细节。用户需求是从用户交流、市场调研或需求分析等方式中获取的。

软件需求（功能需求）：是对软件系统功能行为和操作的详细描述。规定了软件系统应该提供哪些功能和功能之间的关联。功能需求通常以用例、功能规范或需求规格说明书的形式进行描述，以便开发人员和测试人员理解和实现。

测试人员严重的需求：以用户登录注册业务为例

如何深入了解需求？

进行需求评审会议

需求评审会议是软件开发和测试过程中的一项重要活动，旨在审查、讨论和验证软件系统的需求。该会议通常由项目团队的相关成员参与，包括需求分析师、开发人员、测试人员、项目经理和其他利益相关者。

需求评审会议是项目团队协作和需求共识形成的重要环节，它可以帮助发现和纠正需求中的问题，减少后续开发和测试阶段的变更和风险。通过及时的需求评审会议，可以提高软件开发过程的效率和质量。

2.测试用例

测试用例是用来检验软件系统是否符合预期要求而设计的和执行的 测试环境，预期结果，操作步骤，和测试数据等 集合。用例叫做"case"

以博客系统登录业务为例：

测试环境：windows系统+chrome浏览器+本地

测试数据：账号+密码

操作步骤：输入账号，输入密码，点击登录

预期结果：登陆成功，跳转到个人博客页面

预期结果与实际结果相同，就说这个 测试用例 通过了

为什么会有测试用例?

提高测试人员工作效率、降低测试人员工作的重复性

测试用例是简历自动化测试的基础

3.什么是BUG

当且仅当规格说明存在并且正确，程序与规格说明书（软件需求）之间的不匹配（预期结果！=执行结果）就是BUG

需求规格书没提到的功能，判断标准最终以用户为准：当程序没有实现最终用户合理预期的功能要求时，就是软件系统出现BUG

在用户登录界面，密码是明文显示的，容易造成密码泄露，显然这就是一个BUG

4.软件的生命周期

六个阶段：需求分析，计划，设计，编码，测试，运行与维护

需求分析：注意需求是否合理，需求是否完整

计划：开发，测试，时间安排

编码：编写代码

测试：进行测试，生成测试报告

运维：项目上线后，如果出现问题，测试人员需要协助开发人员定位问题，解决问题后重新上线

5.开发模型和测试模型

开发模型

瀑布模型

需求分析后要产出：需求文档

设计阶段产出：技术文档，涉及哪些接口，库表，mq，定时任务，UI视觉稿

测试：执行测试用例，提交ＢＵＧ

优点：每个阶段的工作很清晰

缺点：风险大，由于是单一的流程，测试人员介入晚，后期测试阶段显露的BUG失去及早纠正的机会，浪费人力物力

适用项目：项目小，开发周期短的项目

快速原型模型

快速原型模型（Rapid Prototype Model）是一种软件开发过程模型，它主要用于快速验证和演示概念、设计和功能。

快速原型模型的主要特点包括：

快速开发：快速原型模型侧重于快速迭代和开发。开发团队会迅速创建一个简化的原型，以展示系统的核心功能和外观。这有助于及早获取用户反馈和验证设计方案

用户参与：快速原型模型强调用户参与和反馈。原型可以用来与用户进行交互，并获取他们的意见和建议。这有助于确保最终的软件系统符合用户需求和期望

高度可视化：快速原型模型通常是基于图形界面的，通过图形元素和交互操作来展示系统的功能和界面。这使得用户能够更好地理解和评估系统的外观和行为

迭代改进：快速原型模型采用迭代的方式进行开发。根据用户反馈和需求变化，开发团队会不断改进和扩展原型，确保系统的质量和功能符合预期

缺点：快速原型模型可能导致在后续开发阶段遇到技术和复杂性挑战，需要谨慎评估和规划

适用场景：适用于对系统功能和界面进行快速验证和演示的项目

螺旋模型

特点： 

迭代循环：螺旋模型将软件开发过程分为多个迭代周期。每个迭代周期都包括需求分析、设计、开发、测试和评审等阶段。每个迭代周期都会逐步完善软件系统，并根据之前的经验进行调整和改进

风险驱动：螺旋模型注重风险管理。在每个迭代周期开始时，会进行风险评估和分析。开发团队会优先解决高风险的问题，从而降低项目失败的风险

原型开发：螺旋模型支持原型开发。在项目早期阶段，可以使用快速原型来验证需求和设计，获取用户反馈，并指导后续开发工作

阶段评审：螺旋模型中的每个迭代周期结束后，都会进行阶段评审。评审会对上一阶段的成果进行检查和审查，以确认其合理性和可行性，并确定下一阶段的方向

缺点：可能需要更多的资源和时间，且需要更加严格的管理和控制，以确保项目的成功

适用项目： 螺旋模型适用于大型、复杂和风险较高的软件项目

增量模型

将系统的开发和交付分解为多个增量或部分的迭代完成

增量模型的主要特点包括：

增量交付：将软件系统的开发和交付分成多个增量。每个增量都是完整的、可运行的子系统或功能集合。在每个增量完成后，可以交付给用户并获得反馈。

迭代开发：采用迭代方式进行开发。每个增量都是一个迭代周期，包括需求分析、设计、开发、测试和交付等阶段。每次迭代都会增加新的功能或改进现有功能。

优先级分配：在增量模型中，各个增量的开发优先级是可调整的。可以根据用户需求、风险程度和系统复杂性等因素来确定每个增量的优先级顺序。

增量集成：随着每个增量的完成，进行增量集成测试，确保增量之间的交互和整体系统的正常运行。这有助于及早发现和解决集成问题。

用户参与：强调用户参与和反馈。用户可以在每个增量完成后进行评审和测试，并提供对系统功能和性能的反馈意见

敏捷方法

个体与交互重于过程和工具：强调在软件开发中，个体成员之间的沟通和合作比过程和工具更重要。意味着团队成员应该更多地关注有效的沟通、协作和互动，而不是只依赖工具和流程。

可用的软件重于完备的文档：敏捷方法注重交付可用的软件产品，而不是过多强调繁琐的文档编写

客户协作重于合同谈判：强调与客户的紧密合作和持续反馈。团队和客户之间的协作和沟通比起相对僵硬的合同谈判更能推动项目成功

响应变化重于遵循计划：敏捷方法认识到需求是会变化的，因此强调对变化灵活响应

敏捷方法中后者并非没有价值，只是相比于前者是次要的

scrum三大角色

1. 产品经理（Product Owner）：代表利益相关者、客户或用户，并负责管理产品待办列表。他们与团队密切合作，明确产品需求、优先级和发布计划。产品负责人还参与冲刺计划会议、冲刺回顾会议和冲刺评审会议，确保团队交付符合用户期望的功能。

2. 研发团队（Scrum Team）：是一个跨职能的自组织团队，负责开发、测试和交付产品的增量。团队成员通常包括开发人员、测试人员和其他必要的技能。研发团队在冲刺计划会议中承诺完成的工作，并通过日常站会进行协调和信息共享。他们负责根据产品待办列表中的任务完成工作，并在冲刺回顾会议和冲刺评审会议中展示和讨论已完成的工作。

3. 项目经理（Scrum Master）：是团队的敏捷教练和迭代过程的卫道士。他们致力于促进Scrum方法的实施和持续改进。项目经理负责移除团队面临的障碍，确保团队遵守Scrum的规则和实践，并促进团队的自组织和跨功能性。还组织和引导冲刺回顾会议和日常站会，以及培训新成员加入Scrum团队。

流程 

 产品经理（收集用户需求）->项目经理（对需求进行优先级划分，计划项目日程）->每日站会（汇报昨天工作是否完成以及遇到的问题，今题的工作计划）->项目演示

测试模型

V模型

需求分析与系统设计：验证产品所给的软件需求是否正确；确定编程语言，使用框架

概要设计：设计项目结构

详细设计：设计每个接口，库表，定时任务

编码： 代码编写

此时测试人员介入进行后续测试

单元测试：java中测试每一个方法，类

集成测试：将许多方法集成到一起测试

系统测试：测试模块和模块之间是否有影响，测试所有功能

验收测试：项目上线之前，和产品，运营进行验收

特点：左侧是开发流程，右边是测试流程（类似于瀑布模型）

优点：测试过程被划分成许多类型

缺点：测试人员介入晚，发现问题时机太晚， 

W模型

也叫双V模型

特点：开发一个V，测试一个V

优点：测试人员能更早的介入需求

缺点：测试人员和开发人员一定程度上还是串行的；由于类似于瀑布模型，需求文档开始就确定了，V模型和W模型不能拥抱变化，不能适用于敏捷