01软件测试基础-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_54095563/article/details/146237852

软件测试常见名称

在软件测试中，常见的名称和术语包括：

1.需求（Requirement）

软件需要实现的功能或特性，通常由客户或业务方提出。需求又可分为：用户需求、软件需求。

用户需求：一般是客户甲方提出。
软件需求：是从技术角度详细描述系统需要实现的功能、性能、约束等，通常以结构化文档形式呈现，供开发团队使用。

用户需求 vs 软件需求

特性	用户需求	软件需求
描述角度	用户视角	技术视角
语言	非技术性语言，自然语言	技术性语言，结构化文档
关注点	用户目标、任务、使用场景	系统功能、性能、约束
编写者	客户、业务分析师、产品经理	系统分析师、架构师、开发人员
示例	用户希望系统能够快速加载页面	系统应在 1 秒内加载页面

2.测试用例（Test Case）

为了验证某个特定功能或场景而设计的一组输入、执行条件和预期结果。测试用例是测试执行的最小单位，用于检查软件是否按预期工作。

以下是一个简单的测试用例示例：

用例编号	TC_LOGIN_001
测试标题	验证用户使用正确的用户名和密码可以成功登录
前置条件	用户已注册并拥有有效的账号
测试步骤	1. 打开登录页面。 2. 输入用户名 "testuser"。 3. 输入密码 "password123"。 4. 点击“登录”按钮。
测试数据	用户名="testuser"，密码="password123"
预期结果	用户成功登录，跳转到主页。
实际结果	用户成功登录，跳转到主页。
测试状态	通过
优先级	高
所属模块	登录模块

3.测试计划（Test Plan）

测试计划是测试活动的指导性文件，概述测试范围、策略、资源、进度等内容的文档。，确保测试工作有序进行，并为项目团队提供清晰的测试方向。

以下是一个简化的测试计划示例：

部分	内容
引言	本测试计划旨在验证 XXX 系统的功能、性能和安全性，确保其满足用户需求。
测试目标	1. 验证系统功能是否符合需求文档。 2. 确保系统在高负载下的性能表现。
测试范围	1. 功能测试：登录模块、支付模块。 2. 性能测试：系统响应时间、并发用户数。
测试策略	1. 功能测试：手动测试。 2. 性能测试：使用 JMeter 进行负载测试。
测试资源	1. 测试人员：3 名功能测试工程师。 2. 测试环境：Windows 10、Chrome 浏览器。
测试进度	1. 测试用例设计：2023-10-01 至 2023-10-05。 2. 功能测试执行：2023-10-06 至 2023-10-15。
测试交付物	1. 测试计划文档。 2. 测试用例文档。 3. 测试报告。
风险与应对措施	1. 风险：测试环境未按时准备好。 2. 应对措施：提前与运维团队沟通。
测试通过标准	1. 所有高优先级的测试用例已执行并通过。 2. 未解决的缺陷数量低于 5 个。
测试工具	1. 功能测试：JIRA、TestRail。 2. 性能测试：JMeter。

4.测试脚本（Test Script）

自动化测试中用于执行测试的代码或指令。测试脚本可以模拟用户操作、输入数据、验证结果，并生成测试报告。它是自动化测试的核心组成部分，能够提高测试效率，减少重复性工作。

5.缺陷（Bug）

是指在软件测试过程中发现的与需求、设计或预期行为不符的问题。缺陷可能涉及功能、性能、界面、安全性等方面。

以下是一个缺陷报告的示例：

字段	内容
缺陷编号	BUG-001
标题	登录功能无法处理空密码
描述	步骤： 1. 打开登录页面。 2. 输入用户名 "testuser"。 3. 不输入密码。 4. 点击“登录”按钮。实际结果：系统未提示密码为空，直接跳转到错误页面。预期结果：系统应提示“密码不能为空”。
严重程度	高
优先级	高
所属模块	登录模块
环境信息	Windows 10、Chrome 浏览器
附件	登录错误页面的截图
状态	新建
发现人	张三
分配给	李四

5.1Bug的等级

崩溃：导致系统完全无法运行或核心功能失效的缺陷。

登录功能完全无法使用，所有用户无法登录系统。
系统在启动时崩溃。

2.严重：影响主要功能或重要业务流程的缺陷。

支付功能无法完成交易。

数据保存失败，导致用户输入丢失。

3.一般：影响次要功能或非核心业务流程的缺陷。

页面布局错乱，但不影响功能使用。

某些边界条件下功能异常。

4.次要：对系统功能影响较小或仅限于界面优化的缺陷。

按钮颜色与设计稿不一致。

提示信息中的拼写错误。

5.2 Bug的生命周期

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

6.测试环境（Test Environment）

用于执行测试的硬件、软件、网络配置等。

软件的生命周期vs软件测试的生命周期

软件的生命周期

软件测试的生命周期

SDLC vs STLC 对比表格

阶段	SDLC	STLC
目标	完成软件开发并交付用户使用。	确保软件质量，发现并修复缺陷。
主要活动	需求分析、计划、设计、编码、测试、运行维护。	需求分析、测试计划、测试设计、测试执行、测试评估。
输出	需求文档、设计文档、代码、上线版本。	测试计划、测试用例、测试报告、缺陷报告。
参与角色	产品经理、开发人员、测试人员、运维人员。	测试经理、测试工程师、开发人员。
时间范围	覆盖软件从概念到退役的整个生命周期。	主要集中在软件开发阶段的测试活动。
关注点	软件的功能实现和用户需求满足。	软件的质量和缺陷修复。

开发模型

是软件开发过程中使用的框架或方法论，用于指导团队从需求分析到软件交付的整个流程。不同的开发模型适用于不同的项目需求和团队特点。

1. 瀑布模型（Waterfall Model）

特点：
- 线性顺序开发，每个阶段完成后才能进入下一个阶段。
- 阶段包括：需求分析、设计、实现、测试、部署、维护。
优点：
- 结构清晰，易于理解和管理。
- 适合需求明确且不变的项目。

2. 迭代模型（Iterative Model）

特点：
- 将项目分为多个迭代，每个迭代都是一个完整的开发周期（需求、设计、实现、测试）。
- 每个迭代交付一个可运行的版本。
优点：
- 逐步完善软件功能，灵活性高。
- 早期交付部分功能，降低风险。

3. 增量模型（Incremental Model）

特点：
- 将软件分为多个增量，每个增量都是一个完整的功能模块。
- 每个增量独立开发、测试和交付。
优点：
- 早期交付部分功能，用户可提前使用。
- 降低整体项目风险。

4. 螺旋模型（Spiral Model）

特点：
- 结合瀑布模型和迭代模型，强调风险分析。
- 每个迭代包括四个阶段：规划、风险分析、开发、评估。
优点：
- 强调风险管理，适合高风险项目。
- 灵活应对需求变化。

5. 敏捷模型（Agile Model）

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

特点：
- 以用户需求为核心，强调快速迭代和持续交付。
- 常见方法：Scrum、Kanban、极限编程（XP）。
优点：
- 高度灵活，适应需求变化。
- 持续交付，用户可尽早使用。

敏捷开发特点

迭代开发：
- 将项目分为多个短周期（通常 2-4 周），每个周期称为一个迭代（Sprint）。
- 每个迭代交付一个可运行的软件版本。
用户需求为核心：
- 通过用户故事（User Story）描述需求，确保开发始终围绕用户价值。
持续交付：
- 每个迭代结束后交付可用的软件，用户可尽早使用并提供反馈。
自组织团队：
- 团队高度协作，自主分配任务和解决问题。
快速响应变化：
- 通过频繁的评审和调整，快速适应需求变化。

常见的敏捷开发方法Scrum

包括三个角色、五个会议

会议包括需求发布会议、迭代计划会议、每日会议、演示会议、回顾会议。

角色包括：产品经理、项目经理、开发团队。

使用固定的迭代周期（Sprint）1-4周，通常情况下为1周。

测试模型

1. V 模型（V-Model）

V模型的核心思想是测试与开发并行，通过早期测试来降低缺陷修复成本。

V模型将开发过程分为左侧的开发阶段和右侧的测试阶段，两者形成对称的V字形结构。每个开发阶段都有一个对应的测试阶段，确保软件在开发的每个环节都经过验证和确认。

2. W 模型（W-Model）

它是对V模型的扩展和优化。W模型的核心思想是测试与开发并行，强调测试活动贯穿整个软件开发生命周期，从而更早地发现和修复缺陷，提高软件质量。

3.V模型与W模型的对比

方面	V模型	W模型
测试活动	测试活动在开发完成后进行。	测试活动与开发活动并行进行。
灵活性	较低，适合需求稳定的项目。	较高，适合需求变化的项目。
适用场景	大型复杂项目、对质量要求高的项目。	中小型项目、需求变化频繁的项目。