【软件测试】软件测试-----概念篇

一.需求的相关概念

• 在多数的软件公司,会有两部分需求, 一部分是用户需求, 另一部分是软件需求.

1.1 用户需求

• 用户需求: 可以理解为甲方提出的需求, 也可以理解为用户提出的需求. 就是一句没有经过合理评估的一句话.
• 举个例子:
  • 用户需要一种智能手表，能够准确监测心率和睡眠质量，同时能接收手机通知，并通过简易的操作界面进行互动操作。这一需求合理，因为它解决了用户健康管理和便捷通信的实际问题，且技术上可行，用户价值明显。
  • 用户希望开发一款能100%准确预测未来市场变化的软件。这一需求是不合理的，因为目前技术和信息的限制，无法确保市场预测的绝对准确性，这种需求忽视了实际的技术限制和市场复杂性。

1.2 软件需求

• 软件需求: 也可以叫做功能需求, 该需求会**详细的描述开发人员必须实现的软件功能. 软件需求也是测试人员进行测试工作的基本依据.
• 举个例子:
  • 开发一个学生在线考试系统，该系统能够让学生在网络环境中完成在线考试、成绩查询等操作，同时允许教师对试题库进行维护和更新。(此处只是一个简略的过程,在实际的工作中软件需求文档会更加的详细)
    • 考生身份验证：考生进入系统前需要进行身份验证，以确保考试的公正性和安全性。
      考试难度选择：考生可以根据自己的需求选择不同级别的考试难度，如顶级、甲级、乙级，这有助于评估不同层次的学生能力。
    • 随机抽题功能：为了确保考试的规范性，每位考生接收到的试卷内容和题量应相同，但具体试题可以不同。这通过从服务器数据库中随机抽取试题来实现。
    • 时间控制机制：系统需要具备时间控制功能，确保考试时间的公平性，到时系统将自动要求考生交卷。
    • 自动判卷功能：考生提交答案后，系统应能自动进行判卷并显示成绩，减少人工干预，保证评分的客观性。
    • 成绩查询功能：考试结束后，考生应能在系统中查询自己的成绩和排名，以便了解自己的学习状况。
    • 试题库管理：管理员有权对试题库进行维护，包括添加、修改和删除试题，从而更新和优化题库资源。

二. 开发模型

2.1 模型的基本概念.

• 在软件开发中，“模型”二字通常指的是指导开发过程的框架和方法。具体来说，开发模型为软件项目提供了一种结构化的方法和步骤，确保开发流程有序进行并达到预期目标。不同的开发模型适用于不同的场景和需求，选择合适的模型对于项目的成功至关重要。

2.2 软件的生命周期

• 生命周期: 指的是从生命的开始到生命结束的一段时间。以人为例，人类的生命周期是从生命孕育的开始，中间会经历幼年，童年，少年，青年，老年，最终直至死亡。而软件/产品的生命周期也是如此，需求的开始是软件生命的起点，中间会经历需求的计划、设计，程序开发，程序测试等阶段，直至软件不再进行维护便到了生命的终点。
• 举个例子:(现在我们需要盖一个房子,我们来看看房子的生命周期是怎么样的)

步骤	总结	映射软件流程
为什么要建房⼦？商品房还是普通住宅？建造100层技术上是否可⾏？	明确合理的建房⽬标	需求分析
什么时候开发建房⼦？计划竣⼯时间？多久可以交房？	计划好时间	计划
建房前明确流程：先打地基，做基础框架，砌墙、粉刷、水电工程…	设计好具体的建房流程	设计
按照前面的流程和时间实施建房中…	施工中	编码
房屋建造完成，开发商验收成果、买家验收房子品质（房子是否牢固，是否漏水及其他偷工减料的地方，是否按照规定来建造的）	检查房屋的建造结果	测试
检查结束开始逐步入住，使用中出现了各种情况如房屋漏水、墙⾯掉皮、下水道堵塞等问题，一边使用一边找物业修理	使用房屋并进行房屋的维护	运行维护

由此我们得出了软件的生命周期: 需求分析---->计划---->设计---->编码---->测试---->运行维护

2.2.1 理解软件生命周期每个阶段的具体任务

• 需求分析 : 分析用户的需求是否合理，分别从市场需求、技术等方面进行分析。这个阶段完成后会输出需求文档.
• 计划 : 对成立的需求执行需求执行计划，多长时间内完成该需求，每段时间具体完成哪些功能。 这个阶段完成后会输出计划文档.
• 设计 : 将需求细化成一个个任务，团队成员各司其职领取任务并进行技术设计（如何进行架构设计，设计哪些接口、采用什么技术） 这个阶段完成后会输出技术文档.
• 编码 : 开发⼈员参考需求需档、设计文档、交互图等等文件进行代码的编写。 这个阶段完成后会输出代码文件文档.
• 测试 : 测试人员需要介入到软件的测试中来，参考测试用例对软件进行测试。这个阶段完成后会输出测试用例, 测试设计与计划, 测试报告文档
• 运行维护 : 项目测试结束之后，项目需要进行上线，并对产品进行线上的维护。线上的维护主要分为三个方面。分别为修复性维护、完善性维护和预防性维护。
  • 修复性维护 : 对项目中未发现的问题进行修复.
  • 完善性维护 : 对项目中的功能进行完善.
  • 预防性维护 : 居安思危, 为了避免产品在线上出现一些其他不可预料的问题, 进行一些预防的手段.

2.3 常见的开发模型.

2.3.1 瀑布模型(适用场景：需求固定的小项目).

• 瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进⾏的软件开发模式。
• 瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日”。
• 尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户.
• 瀑布模型的优缺点(特点)总结:
  • 优点(特点) :
    • 强调开发的阶段性；
    • 线性结构，每个阶段只执行一次
    • 是其他模型的基础框架
  • 缺点:
    • 测试后置
      • 前⾯各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会
      • 必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给用户（产品质量差）
    • 周期太长，产品很迟才能被看到和使用，可能会导致需求/功能过时

2.3.2 螺旋模型(适用场景：规模庞大、复杂度高、风险大的项目)

• 螺旋模型本质上就是在瀑布模型的基础之上每一步都加入了原型和风险分析
• 一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
• 这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。
• 螺旋模型的优缺点(特点)总结:
  • 优点(特点) :
    • 强调严格的全过程风险管理。
    • 强调各开发阶段的质量。
    • 增加风险分析和原型
  • 缺点 :
    • 项目中可能存在的风险性与风险管理人员的技能水平有直接关系
    • 需求人员、资金、时间的增加和投入，可能会导致项目的成本太高

2.3.3 增量模型. 迭代模型

1、增量模型

1. 核心概念：增量模型是将软件产品划分为一系列增量构件，以便分批次地分析、设计、编码和测试。每个增量都是软件功能的一个子集，它们集成在一起，共同构成完整的软件产品。
2. 主要特点：
   • 逐步构建：通过逐步构建软件系统的各个部分，每增加一个部分就离整体目标更近一步。
   • 模块化：各个增量可以独立开发和测试，便于团队并行工作，提高工作效率。
   • 易于管理：由于是分批次开发，项目管理者可以更容易地监控进度和质量，及时调整计划。
3. 优点：
   • 快速交付：增量模型允许开发团队在短时间内交付可用的软件产品，让客户尽早看到成果。
   • 风险管理：通过分批次开发，可以降低整体项目风险，因为每个增量的开发和测试都相对独立。
   • 灵活性：根据项目需求和客户反馈，可以灵活调整增量的内容和优先级。
4. 缺点：
   • 集成问题：随着增量的增加，系统集成的难度可能会逐渐增大，需要仔细规划集成策略。
   • 需求变更：如果需求频繁变更，可能导致已开发的增量需要大幅度修改，影响项目进度。
   • 文档更新：增量模型要求持续更新文档，以反映每个增量的最新状态，这可能增加管理成本。

2、迭代模型

1. 核心概念：迭代模型是一种循环开发的方法论，每个迭代周期（或称为迭代）都是一个完整的小型项目，包括需求分析、设计、编码、测试和评估等环节[³]。
2. 主要特点：
   • 循环迭代：每次迭代都是对软件产品的一次改进，每次迭代结束后都会产出一个可运行的软件版本。
   • 客户反馈：迭代模型强调客户参与，客户的反馈是迭代过程中的重要输入，用于指导后续迭代的方向。
   • 持续改进：通过不断的迭代，软件产品会逐渐完善，直至满足最终的需求。
3. 优点：
   • 适应性强：迭代模型能够快速适应需求变更，特别适合于需求不明确的项目。
   • 客户满意度高：由于客户参与整个开发过程，产品更符合客户的实际需求，提高客户满意度。
   • 风险降低：通过多次迭代，可以及时发现和修复问题，降低项目失败的风险。
4. 缺点：
   • 管理复杂：迭代模型要求项目管理具有较高的灵活性和适应性，对项目管理的要求较高。
   • 资源消耗：每次迭代都需要完整的开发流程，可能会导致资源重复消耗，增加项目成本。
   • 效率问题：如果迭代次数过多，可能会导致开发效率降低，项目延期。

2.3.4 敏捷模型

• 在早期，迭代瀑布模型非常流行来完成一个项目。但是现在开发人员在使用它开发软件时面临着各种各样的问题。主要困难包括在项目开发期间处理来自客户的变更请求以及合并这些变更所需的高成本和时间。为了克服瀑布模型的这些缺点，在1990年代中期提出了敏捷软件开发模型。
• 敏捷模型主要旨在帮助项目快速适应变更请求。因此，敏捷模型的主要目的是促进项目的快速完成。要完成这项任务，需要敏捷。敏捷性是通过使过程适应项目，删除对特定项目可能不是必需的活动来实现的。此外，避免任何浪费时间和精力的事情。
• 在敏捷模型中，需求被分解成许多可以增量开发的小部分。敏捷模型采用迭代开发。每个增量部分都是在迭代中开发的. 每次迭代都旨在小而易于管理，并且只能在几周内完成。一次为客户计划、开发和部署一个迭代。没有制定长期计划。
• 敏捷模型中有⼀个非常重要的《敏捷宣言》，宣言内容：
  • 个体与交互重于过程和工具----->强调高效的沟通
  • 可用的软件重于完备的文档----->强调轻文档, 文档不应该作为工作验收的标准
  • 客户协作重于合同谈判----->强调应该主动了解当下的需求
  • 响应变化重于遵循计划----->强调能够主动迎接变化

==总结出敏捷开发模型的四个特点—>轻文档 , 轻流程 , 重目标 , 重产出 . ==

Scrum开发模型.

• Scrum是敏捷开发模型中的一种, 又称为迭代式增量软件开发模型.

1、核心概念

1. 团队协作：Scrum强调团队合作的重要性，团队成员需要相互协作，共同面对挑战。
2. 快速迭代：通过短周期的迭代开发，Scrum确保团队能够快速交付软件，并及时获得反馈。
3. 适应性：Scrum框架允许团队在面对不断变化的需求时，能够灵活调整计划和优先级。

2、Scrum角色

1. Product Owner(产品负责人)：负责定义产品待办事项列表，确定优先级，发布计划, 对产品负责 , 以确保团队工作与业务目标一致。
2. Scrum Master(项目经理)：帮助团队遵守Scrum规则，召开各种会议, 协助解决阻碍进展的问题，促进团队间的有效沟通。
3. Team(开发团队)：执行迭代计划的工作，包括设计、编码、测试等，通常由跨职能的团队成员组成。

3、Scrum的工作流程.

• scrum的基本流程如下：
  • 产品负责人负责整理user story，形成左侧的product backlog。就是生成一个产品待办事项列表
  • 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。就是生成一个迭代代办的事件
  • 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。进行任务拆解, 明确负责人和完成任务所需的时间
  • 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。了解项目的进度,及时解决问题,确保能够及时交付
  • 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。演示看是否有可以继续优化, 或者修改的地方
  • 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果. 回顾迭代过程中出现的问题, 在迭代的过程中不断改进.

三. 测试模型.

‌3.1 V模型‌.

• V模型是从瀑布模型演变过来的测试模型.
• 特点‌：V模型是最具有代表意义的测试模型，它反映了测试活动与分析和设计的关系，标明了测试过程中存在的不同类型的测试，从左到右描述了基本的开发过程和测试行为。‌
• 优势‌：
  • V模型非常明确地标明了测试过程中存在的不同级别，清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。‌
  • V模型指出：
    • 单元和集成测试应检测程序的执行是否满足软件设计的要求；
    • 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
    • 验收测试确定软件的实现是否满足用户需要或合同的要求
• 局限性‌：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。
• 

‌‌3.2 W模型‌(也称为"双V"模型).

• V模型中未将测试前置的问题在W模型中得以解决.W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程.
• 特点‌：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。
• 优势‌：测试与开发同步进行，有利于尽早地发现问题。
• 局限性‌：
  • 需求、设计、编码等活动被视为串行的；
  • 测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工
    作。
  • 重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑
    

3.3 H模型‌.

• H模型将测试活动与其他研发流程独立，测试活动分为测试准备与测试执行两个部分，便于测试设计与测试执行活动定义。测试准备活动包括测试需求分析、测试计划、测试设计、测试编码和测试验证等，测试执行包括测试运行、测试报告、测试结果分析和确认回归测试等。‌
• 特点‌：H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行。‌
• 优势‌：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发进行，测试可以尽早进行，并且可以根据被测物的不同而分层次进行。
• 局限性‌：不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，对测试员的熟练程度要求比较高。
  

‌3.4 X模型‌：

• X模型左边表明针对单独的程序片段 n 进行独立的编码和测试活动，以此为基本过程，不断迭代，通过集成活动最终成为可执行程序，然后再对这些可执行程序进行测试。通过集成测试的成品可以进行封装并提交给系统测试环节或直按给用户。多条并行的曲线表示变更可以在各个部分发生。
• X模型提出了探索性测试的概念。探索性测试与常规的测试方法不同，无须事先制定测试计划或设计，有经验的测试工程师可根据自己的思维活动及对被测对象的理解，在测试计划之外发现更多的软件错误。但探索性测试通常情况下仅作为其他测试方法的补充，因其消耗测试资源较多，且受制于测试工程师的经验，所以不能成为独立的测试方法。‌
• 特点‌：X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序。
• 优势‌：定位了探索性测试，不进行事先计划的特殊类型的测试，往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
• 局限性‌：可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。
  

3.5 敏捷测试模型

• 其实软件测试中并无敏捷测试模型，为了对应敏捷开发，才提出了敏捷测试的概念。
• 敏捷开发的最大特点是高度迭代，周期性强，能够及时、持线地响应需求的频繁变更反馈。敏捷测试即是不断修正被测对象的质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产过程安全、及时地发布最终产品。
• 敏捷测试工程师在高速迭代、沟通之上的敏捷开发团队中，需要关注需求变更、产品设计、源代码设计。通常情况下，需要全程参与敏捷开发团队的团队讨论评审活动，并参与次策制定等。在独立完成测试设计、测试执行、测试分析输出的同时，关注用户、有效沟通，从而协助敏捷流程推动产品的快速开发。
• 在传统开发模型下，一个测试版本生成周期可能为几个月，但在敏捷模型中，可能几周一个版本，甚至几天一个测试版本，因此敏捷团队中的测试工程师在技术技能、业务理解、产品设计等方面都需要熟练，否则很难快速高效地完成测试任务，给项目带来风险。