【测试开发篇】初识软件测试（2）

---

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

需求的概念

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

IEEE定义：软件需求是 (1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。

在多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求

• 用户需求： 可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。
• 软件需求： 或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。

软件需求规格说明书
一、用户需求：
平台支持邮箱注册

二、软件需求：
1.1.1.1 注册账号
1.1.1.1.1 功能概述
用户可以通过填写邮箱信息在平台注册个人用户。
1.1.1.1.2 用户角色
匿名用户。
1.1.1.1.3 前置条件
无。
1.1.1.1.4 输入
| 序号 | 栏位名称 | 栏位说明 | 长度 | 类型 | 备注|
| ------ | -------- | ------------------- | ------- | ------ | ------ |
| 1 | 姓名 | 必填，录入个人姓名 | 6至15 | 字符型 |
| 2 | 电子邮箱 | 必填，录入电子邮箱 | | 字符型 |
| 3 | 密码 | 必输，输入的密码隐藏号显示，最短6位 | 6至15 | 字符型 |
| 4 | 确认密码 | 必输，输入的密码隐藏号显示，最短6位 | 6至15 | 字符型 | |
| 5 | 验证码 | 必填，录入验证码 | | 字符型 |
| 6 | 注册 | 注册操作 | | 操作型 |
1.1.1.1.5 处理
1.1.1.1.5.1 基本事件流
1、用户选择注册；
2、系统展现用户协议界面，并请用户确认是否同意用户协议

1. 若用户不同意协议，系统禁止用户注册。
2. 若用户同意协议，用户进行注册信息填写。

3、用户填写注册信息。
注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。
4、 用户提交注册信息；
5、 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收 到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。
6、 用户可执行激活操作，直接跳转至注册邮箱门户页面。
7、用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。
1.1.1.1.5.2 扩展事件流

1. 用户注册并激活成功后，第一次登录平台时，提示用户完善信息；

1.1.1.1.5.3 异常事件流

1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
2. 每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。

1.1.1.1.6 输出 用户注册成功
1.1.1.1.7 后置条件 该模块为用户登陆等的前置模块。

软件需求是测试人员进行测试工作的基本依据。
在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出
每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

过程如下，业务需求—>软件功能需求点—>测试需求点—>测试用例

以“用户登陆”为例，来阐述下整个过程：

---

测试用例的概念

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

测试用例解决了两大问题：测什么，怎么测。

假如我们要测试优快云搜索框：

考虑输入搜素框中的各种情况：

• 空字符串
• 特殊符号
• 超长字符串
• 中英文符号
• 输入关键词：Java
• 查找一个里面全部不存在的
• SQL注入
• 大量用户并发搜索
• 空格过滤

---

这里我们具体写一个测试用例：

• 标题：网易邮箱正确注册功能
• 测试环境：Microsoft Edge 版本 111.0.1661.54 (正式版本) (64 位)+Windows11
• 操作步骤：
  1.进入网易邮箱登录主页
  2.点击网易邮箱注册入口进入注册页面
  3.输入对应注册信息。邮箱地址，密码，手机号，协议勾选框，点击立即注册
• 测试数据：
  邮箱地址：Wzt2023
  密码：123456
  手机号：1xxxxx
• 预期结果:页面跳转至注册成功页面,注册的账号可以正确登录

---

软件错误（BUG）的概念

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

---

开发模型和测试模型

随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编写，而是扩展到了整个软件生命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新和替换新的版本。软件工程还包括很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管理，在这些方面也逐步地建立起了标准或规范。

软件的生命周期

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

需求分析
产品经理收集用户的需求，分析用户需求是否合理(市场分析、技术分析等)

计划(产出计划文档)
制定软件什么时候开始、什么时候结束。（制定需求的计划）
包括消耗多少人力，多少人员一起参与开发、测试等等。
设计(产出设计文档)
将需求细化为一个个的任务，进行技术设计（需要使用哪些技术，例如sql等。需要哪些接口）
编码
开发人员按照需求文档、设计文档来进行代码开发。
测试
测试人员参考测试用例来执行测试。
运行维护
项目上线之后对产品进行线上的维护。

修复性维护：对于未发现的问题进行修复、

完善性维护：对功能进行完善
预防性维护：为了避免产品在线上出现一些其他问题，进行一些预防的手段(例如预防用户访问量突然增多的情况)。

软件测试的生命周期

项目测试完成之后，需要进行项目上线。产品在线上运行期间我们测试人员也需要及时关注产品线上运行情况，是否出现了产品质量问题，如果出现了问题：

1. 尝试复现（普遍存在的问题还是个别问题）
2. 尝试定位问题出现的原因，帮助开发人员尽快的定位问题并解决问题
3. 反思问题（为什么出现，如何解决，如何后续避免）

---

瀑布模型（Waterfall Model）

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。

瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

• 优点： ①强调开发的阶段性； ②强调早期计划及需求调查； ③强调产品测试。
• 缺点： ① 依赖于早期进行的唯一一次需求调查，不能适应需求的变化； ②由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； ③风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会；④必须留有足够的时间给测试活动，否则测试不充分，将缺陷暴露给用户（产品质量差）；⑤周期太长，产品很迟才能够看到和使用，可能导致需求/功能过时。
• 使用场景：需求固定的小项目。

瀑布模型的一个最大缺陷在于，前面各阶段遗留的风险推迟到测试阶段才被发现，导致项目大面积返工，失去了及早修复的机会。这会给项目带来很大的风险，尤其是集成的风险。业界流行的说法是：“集成之日就是爆炸之日”。

---

螺旋模型（Spiral Model）

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

• 优点： ①强调严格的全过程风险管理。 ②强调各开发阶段的质量。 ③提供机会检讨项目是否有价值继续下去。
• 缺点： ①引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求，需要人员、资金和时间的投入。

螺旋模型拉直之后：

---

增量模型和迭代模型

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。

增量模型里把大的需求划分成一个个可以独立开发上线的功能。

增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

增量通常和迭代混为一谈，但是其实两者是有区别的。 增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

假如有一个软件，共有A B C D E 五个功能
增量模型：可以先开发A B功能，再开发C D E
迭代模型：先开发A B C D E 的基础版本，在基础版本上不断地进行功能完善

---

敏捷模型

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷”(Agile)作为新的过程家族的名称。

在会议上，他们提出了《敏捷宣言》（http://agilemanifesto.org/）： 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍，我们形成了如下价值观。

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。

由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程(Social Engineering)的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。

---

敏捷开发有很多种方式，其中scrum是比较流行的一种。

scrum模型

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

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

迭代开发
与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

scrum的基本流程

scrum的基本流程如上图所示：

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

软件测试V模型

V模型最早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种。

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

软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

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