测试相关基础概念与常见开发模型

目录

1. 什么是需求

1.1 需求的定义

1.2 为什么有需求?为什么需求对软件测试人员如此重要?

1.3 测试人员眼里的需求(重要)

1.4 如何深入了解需求

2. 测试用例

2.1 什么是测试用例

2.2 为什么有测试用例

3. 什么是BUG

3.1 BUG定义

 3.2 如何描述一个BUG

3.3 如何定义bug的级别

3.4 BUG的生命周期

BUG状态转换图

4. 软件生命周期

5. 开发模型

5.1 瀑布模型(Waterfall Model)

5.2 螺旋模型(Spiral Model)

5.3 增量, 迭代

5.4 敏捷

敏捷宣言

scrum

scrum里面的角色

迭代开发

scrum的基本流程

5.5 软件测试V模型

5.6 软件测试W模型

 6. 软件测试生命周期

7. 如何开始第一次测试

---

1. 什么是需求

1.1 需求的定义

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

IEEE定义: 软件需求是
(1)用户解决问题或达到目标所需条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

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

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

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

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

软件需求是测试人员进行测试工作的基本依据.

【软件需求规格说明书】

1. 引言
本文档旨在定义软件平台支持邮箱注册功能的需求规格。平台的主要目标是允许用户通过邮箱进行注册，并为他们提供相关服务。本文档将涵盖对该功能的详细描述，包括功能性需求、非功能性需求、用户界面设计以及安全性考虑。

2. 功能性需求
2.1 用户注册
用户应该能够通过邮箱注册一个新的平台账号。在注册过程中，用户需要提供以下信息：
- 邮箱地址：作为唯一的用户标识符，用于登录和与用户进行沟通。
- 密码：用于保护账号安全性的用户选择的密码。

2.2 邮箱验证
在用户完成注册后，系统应该向提供的邮箱地址发送验证邮件，其中包含一个唯一的验证链接或验证码。用户必须通过点击验证链接或输入验证码来确认并激活账号。

2.3 密码重置
在用户忘记密码或需要更改密码时，系统应该提供一个密码重置功能。用户应该能够通过邮箱收到包含重置链接或验证码的邮件，以重置密码。

3. 非功能性需求
3.1 安全性
为了保障用户数据安全，平台必须采取适当的安全措施，包括但不限于以下要求：
- 使用加密协议保护用户登录和注册时传输的数据。
- 对用户密码进行哈希加密存储，确保即使数据库泄露，用户密码也不会暴露。
- 限制账号激活邮件中的有效期，以防止链接失效后被滥用。

3.2 可靠性
平台需要保证邮箱注册功能的稳定性和可靠性，尽量避免系统崩溃或故障。在高负载情况下，系统应该能够正常处理用户注册请求。

3.3 用户友好性
用户界面应该设计简洁、直观，并提供相应的提示信息，帮助用户顺利完成注册流程。错误处理应该友好，向用户展示清晰的错误信息，帮助用户及时纠正错误。

4. 用户界面设计
4.1 注册页面
- 提供一个输入框，让用户填写邮箱地址。
- 提供一个输入框，让用户设置密码。
- 提供一个按钮，允许用户提交注册请求。

4.2 邮箱验证页面
- 在用户注册后，提示用户检查收件箱，并点击验证链接或输入验证码。
- 提供一个输入框，让用户输入收到的验证码。
- 提供一个按钮，允许用户提交验证请求。

4.3 密码重置页面
- 提供一个输入框，让用户填写与账号关联的邮箱地址。
- 提供一个按钮，允许用户请求重置密码邮件。

5. 测试计划
在开发完成后，需要进行全面的功能和安全测试，确保邮箱注册功能的正确性和稳定性。测试计划应该包括以下方面：
- 功能性测试：验证所有注册、验证和密码重置功能是否按照规格要求工作。
- 安全性测试：检查系统是否正确地处理安全敏感信息，如用户密码和验证码。
- 可靠性测试：模拟高负载场景，测试系统在不同负载下的性能表现。

6. 总结
本文档定义了平台支持邮箱注册功能的需求规格，包括功能性需求、非功能性需求、用户界面设计和测试计划。通过遵循这些规格，我们将确保平台提供安全、可靠且用户友好的邮箱注册功能，满足用户的需求。

1.2 为什么有需求?为什么需求对软件测试人员如此重要?

• 从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
• 对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计

1.3 测试人员眼里的需求(重要)

需求是测试人员开展软件测试工作的依据.

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

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

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

1.4 如何深入了解需求

测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集。

1. 参加需求评审会议
2. 查阅需求文档
3. 团队沟通

2. 测试用例

2.1 什么是测试用例

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

测试用例解决了两大问题: 测什么，怎么测.

2.2 为什么有测试用例

1. 测试用例提高测试人员工作效率 / 降低测试人员工作的重复性问题
2. 测试用例是建立自动化的基础

3. 什么是BUG

3.1 BUG定义

BUG是:

当且仅当规格说明(软件需求/需求规格说明书)是存在的并且正确，程序与规格说明之间的不匹配才是错误。

当需求规格说明书没有提到的功能，判断标准以最终用户为准: 当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

 3.2 如何描述一个BUG

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

1、发现问题的版本

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

2、问题出现的环境

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

3、错误重现的步骤

描述问题重现的最短步骤

4、预期行为的描述

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

要相信:测试人员是最懂需求的

5、错误行为的描述

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

6、其他

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

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

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

提交了如下bug:
1、在短信列表，选择一条短信，进行删除，删除失败
2、在短信列表，选择一条短信，进行查看，在查看页面，进行删除，删除失败

很明显上述bug描述中, 第二条描述较清楚, 符合bug的描述要求.

3.3 如何定义bug的级别

通过bug的影响程度, 我们对其分级别定义, 注意bug的定义每个公司都不一致，在定义级别之前需要查看公司规范.

以下为样例：

1、Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

注: 如果发现该级别的bug, 此时就需要停止测试, 打回给开发, 让开发修复, 再进行测试.

2、Critical（严重）：

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3、Major（一般）：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）

4、Minor（次要）：

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

3.4 BUG的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的，下面仅是一个常见的例子

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

BUG状态转换图

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

4. 软件生命周期

软件的生命周期包含以下几个阶段:

• 需求分析: 分析用户需求是否合理(市场分析, 技术上分析......) -> 软件需求文档;
• 计划: 指定需求执行计划;
• 设计: 将需求细化成一个个任务, 进行技术设计(设计哪些接口, 采用哪些技术) -> 产出设计文档;
• 编码: 开发人员按照需求文档以及设计文档来进行编码;
• 测试: 测试人员参考测试用例来执行测试;
• 运行维护: 项目上线后对产品进行线上的维护.

注: 维护有以下几种:

修复性维护: 对项目中未发现的问题进行修复

完善性维护: 对功能进行完善

预防性维护(居安思危): 为了避免产品在线上出现一些其他的问题, 进行一些预防的手段.

5. 开发模型

5.1 瀑布模型(Waterfall Model)

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

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

优点:

• 强调开发的阶段性，
• 强调早期计划及需求调查，
• 强调产品测试。

缺点:

• 依赖于早期进行的唯一一次需求调查，不能适应需求的变化;
• 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程;
• 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

适用项目: 小型项目

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是:“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想.
在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动否则将导致测试不充分，从而把缺陷直接遗留给用户。

5.2 螺旋模型(Spiral Model)

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一.

优点:

• 强调严格的全过程风险管理。
• 强调各开发阶段的质量。
• 提供机会检讨项目是否有价值继续下去。
• 每个阶段都会进行风险分析, 避免一些线上问题发生.

缺点:

• 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。

适用项目:规模庞大、复杂度高、风险大的项目。

5.3 增量, 迭代

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

增量通常和迭代混为一谈，但是其实两者是有区别的。

增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚.....

而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

5.4 敏捷

敏捷宣言

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的"轻量过程派聚集在犹他州的Snowbird，决定把"敏捷"(Agile)作为新的过程家族的名称。
在会议上，他们提出了《敏捷宣言》 ( Manifesto for Agile Software Development )

敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划

在每对比对中，后者并非全无价值，但我们更看重前者。

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

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

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。
• 回顾会议: 项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

5.5 软件测试V模型

在V模型中,

• 用户需求 是指 产品经理将用户需求收集成软件需求;
• 需求分析与系统设计 是指 验证需求是否正确, 确定编程语言与框架;
• 概要设计 是指 项目结构如何设计;
• 详细设计 是指 设计好每个接口, 有涉及哪些库表, 具体完成哪些任务;
• 编码 是指 写代码;
• 单元测试 是指 测试程序中的每一个方法;
• 集成测试 是指 将许多的方法, 集成到一起测试;
• 系统测试 是指 测试模块和模块之间有没有影响;
• 验收测试 是指 确定软件的实现是否满足用户需要或合同的要求.

特点: 左边是开发, 右边是测试, 类似于瀑布mox

优点: 测试被划分成许多类型

缺点: 测试人员介入太晚, 发现问题时机太晚. 有局限性, 仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试.

5.6 软件测试W模型

• W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
• W模型特点: 测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
• W模型优点: 有利于尽早地全面的发现问题。

例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度.

• 局限性: 需求、设计、编码等活动被视为串行的;测试和开发活动也保持着一种线性的前后关系上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑.

---

 6. 软件测试生命周期

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

需求分析: 测试人员了解需求, 看需求是否完整, 对需求进行分解, 探讨需求是否正确

测试计划: 确定软件由谁测试, 什么时候开始测试, 什么时候结束测试, 测试哪些模块.

测试设计, 测试开发: 写测试用例(手工测试用例, 自动化测试用例), 编写测试工具

测试执行: 执行测试用例

测试评估: 测试人员产生测试报告.

测试报告

项目名称：电子商务网站
测试日期：2023年8月1日至2023年8月2日
测试团队：QA测试团队
测试目的：对电子商务网站的登录功能进行功能和安全性测试，确保登录功能的稳定性和安全性。
测试环境：
- 操作系统：Windows 10
- 浏览器：Chrome、Firefox、Edge
- 设备：PC、手机、平板电脑
测试用例：
1. 用户名和密码正确登录。
2. 用户名正确但密码错误登录。
3. 用户名错误但密码正确登录。
4. 用户名和密码均错误登录。
5. 登录失败超过3次账户锁定。
6. 密码重置功能测试。
7. 找回密码功能测试。
8. XSS攻击测试。
9. SQL注入测试。
10. 密码规则测试。
测试结果：
- 登录功能测试通过，所有测试用例均正常运行。
- 安全性测试无发现安全漏洞。
建议和改进：
- 建议在账户锁定后提供恢复账户的功能。
- 增强密码规则，要求包含数字、大写字母和特殊字符。
总结：
登录功能经过全面测试，目前运行稳定，符合预期要求。未发现严重的缺陷和安全漏洞。建议在后续版本中考虑加入更多的安全性验证措施和密码规则以进一步提升系统的安全性。
测试团队
日期：2023年8月2日

7. 如何开始第一次测试

首先要开始第一次测试工作, 需要先充分理解需求, 可以借助产品文档, 技术文档等文档进行理解, (项目功能相关问题可以问产品经理, 模块底层相关问题可以问开发人员), 然后就要确定测试计划, 接下来执行测试, 注意 当BUG开发修复了之后一定要进行验收, 最后就是项目的上线维护工作.