【软件测试】（软件测试和软件开发 软件测试和软件调试之间的区别 需求 测试用例 BUG 软件生命周期 瀑布模型 螺旋模型 增量、迭代 敏捷 V模型 W模型 描述bug bug级别 bug的生命周期）

---

什么是软件测试？

软件测试就是找bug，发现缺陷，软件测试就是验收软件产品特性是否满足用户的需求。

• 测试试图验证软件是“工作的”，也就是验证软件功能执行的正确性。
• 测试的活动是以测试人员“预期的结果”为依据，这里的“预期结果”指的是需求定义。

为什么有软件测试？

软件测试是保证软甲质量的。

软件测试的特点

软件测试只是一个样本试验，具有不可穷尽性。

软件测试和软件开发的区别

1. 工作内容：

• 开发：通过不同的编程语言，最终做出软件。
• 测试：写测试用例，执行，发送测试报告，编写自动化测试用例，开发相关的测试工具。

2. 技能区别：

• 测试：技能广度的掌握（测试人员要对产品进行全面的测试，外观是否好看，WEB的UI自动化测试，APP的UI自动化，后端的接口进行测试，性能，安全等）
• 开发：技能深度的掌握（开发要写出高效的代码）

3. 发展前景：

• 测试：初级测试工程师 > 中级测试工程师 > 高级测试工程师 > 架构师 > 项目经理
• 开发：初级开发工程师 > 中级开发工程师 > 高级开发工程师 > 架构师 > CTO

软件测试和软件调试之间的区别

1. 角色

• 调试：开发自己调试
• 测试：测试+开发执行（通常情况下，黑盒测试由测试人员执行，部分白盒测试由开发人员执行）

2. 阶段

• 调试：开发的时候才调试
• 测试：测试是伴随着软件的整个生命周期的（测试介入的时间比调试早）

3. 目的

• 调试：调试发现问题，解决问题
• 测试：发现问题

4. 手段

• 调试：debug，分析代码逻辑
• 测试：等价类划分法，边界值法等

软件测试的岗位

测试工程师：功能测试比较多，设计测试用例，执行测试用例，涉及到开发的工作内容较少

测试开发工程师：测试工程师的工作内容上加了一些开发的工作（开发测试用例，开发测试工具，开发出来的测试工具让测试人员用，提高测试效率）

自动化测试：设计自动化测试用例，开发自动化测试框架。

什么是需求

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须完成的任务。该需求一般比较简略。

软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。
用户需求就是一句话，软件需求是一个文档（详细描述用户需求如何实现），日常工作中我们通常是用软件需求进行开发测试。

测试用例

测试用例是一组集合，测试环境，测试数据，预期结果，操作步骤。

登录（qq）是否能够成功
测试环境：Windows + chrome浏览器 + 本地
测试数据：账号密码
操作步骤：输入账号，输入密码，点击登录
预期结果：登录成功

为什么要有测试用例

1. 测试用例可以提高测试人员的工作效率、降低测试人员工作的重复性问题。
2. 测试用例是建立自动化测试的基础。（自动化就是把测试人员双手解放，让代码代替人员执行测试）

BUG

当且仅当规格说明是存在的并且正确 （软件需求，规格说明书），程序与规格说明之间的不匹配才是错误。
当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序员没有实现其最终用户合理预期的功能要求时，就是软件错误（BUG）

软件生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，需求分析、计划、设计、编码、测试、运行维护。

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

计划：谁开发，谁测试，开发多久，测试多久

编码：写代码

运行维护：如果有线上问题，此时测试人员需要协助开发定为问题+解决问题。

瀑布模型

测试：编写完成的代码需要经过严格的测试来确保它能够正确工作并且没有错误。软件测试是验证和保证软件产品质量的关键步骤。
运行维护：一旦产品发布给用户，它将进入维护阶段。这个阶段涉及对产品进行更新和改进，以修复可能出现的问题或根据用户的反馈添加新的功能。

特点：线行的
优点：每个阶段做什么，产出什么非常清晰。
缺点：风险往往迟至后期的测试阶段才能显露，因而失去及早纠正的机会。

适用的项目：小型的项目适用于这种模型。

总的来说，瀑布模型适用于需求明确且变动不大的项目，而对于需要快速响应市场变化和用户反馈的项目，可能不太适合使用瀑布模型。在实际的软件开发过程中，团队可能会根据项目的特点和需求选择适合的开发模型。

螺旋模型

优点：

1. 每个阶段都会进行风险分析，避免一些线上问题发生
2. 减少了过多测试或测试不足所带来的风险。

缺点：
3. 风险分析可能分析错，需要人力财力的投入
4. 每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟交付时间

适用项目：适用于比较大的项目，风险比较多。

增量、迭代

“增量”和“迭代”是两种常见的开发和测试方法，它们都属于敏捷开发的范畴。尽管这两个词经常被混用，但它们实际上有着不同的含义和应用场景。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
增量关注的是产品的逐步构建和增长，每个步骤都会产生一个可以交付的增量；而迭代则关注整个开发过程的重复，每次迭代可能会改进产品的所有方面，但不一定每次都产出可交付的成果。在实践中，这两种方法往往结合使用，以实现更灵活、高效地软件开发和测试。

敏捷

敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情。
敏捷开发有很多种方式，其中scrum是比较流行的一种。

scrum

scrum里面的角色
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

• 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布
  计划，对产品负责。
• scrum master 负责召开各种会议，协调项目，为研发团队服务。
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

scrum的基本流程：

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

V模型

用户需求：PM将用户需求收集形成软件需求。
规格说明可以看成是需求分析与系统设计：验证需求是否正确，确定编程语言，确定框架。
概要设计：项目结构如何设计。
详细设计：每个接口，涉及哪些库表，设计哪些任务。
编码：写代码。
单元测试：Java中测试每一个方法，类，C语言中函数。发现代码级别的错误，包括逻辑错误、算法错误等。它有助于开发人员确保代码的正确性和健壮性。
集成测试：将许多的方法集成到一起测试。
系统测试：验证集成后的系统是否满足需求规格说明书中列出的功能和非功能要求。
验收测试：验证软件是否准备好被最终用户用于执行既定的功能和任务。

特点：左边是开发，右边是测试，类似于瀑布模型
优点：V模型清晰地展示了开发过程中不同阶段的测试活动，从单元测试到系统测试，每个开发阶段都有相应的测试进行验证。这有助于团队理解项目进度，并确保每个阶段的质量。
缺点：

1. 测试人员介入太晚，发现问题时机太晚。可能导致发现问题时修改困难。
2. V模型的开发过程比较刚性，当项目需求发生变更时，可能需要返回到较早的阶段重新规划和开发，增加了时间和成本。

W模型

W模型，也称为双V模型，是一种软件开发过程模型，它强调开发和测试的并行进行，旨在从软件生命周期的早期阶段就开始进行测试活动。W模型通过早期介入和并行测试的方式，促进了更早、更全面的缺陷发现，从而降低了修复成本并加快了项目进度。然而，对于需要快速响应变化和采用灵活开发方法的现代软件项目，W模型可能不是最佳选择。

特点：开发一个V测试一个V
优点：测试人员尽早介入了需求
缺点：测试人员和开发人员一定程度上还是串行的，不能拥抱变化，不能适用于敏捷。

软件测试的生命周期： 需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

如何描述一个bug

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

1. 发现问题的版本

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

2. 问题出现的环境

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

3. 错误重现的步骤

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

4. 预期行为的描述

要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需 求提出的故障，能写明需求的来源是最好的。

5. 错误行为的描述

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

6. 其他

某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。

7. 不要把多个bug放到一起

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

如何定义bug的级别

1、Blocker（崩溃）：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等。（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2、Critical（严重）：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最
多）

4、Minor（次要）：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置
不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

bug的生命周期

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

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed