software

重新开始软件测试：第3部分

发布: (2026年1月2日 GMT+8 20:57)
11 min read
原文: Dev.to

Source: Dev.to

如果您还没有阅读 第 1 部分，可以在此阅读：

重新开始软件测试 – 第 2 部分

“测试场景 vs 测试用例：有什么区别，为什么重要？”

Source: …

1. 测试场景

测试场景 是对需要测试内容的高级描述。
它代表了应用程序的真实使用案例或业务流程。

示例 – 我们有一个网页应用。

测试场景

  • 验证用户登录功能

从这个单一场景可以派生出多个测试用例：

  • 使用有效凭证登录
  • 使用无效密码登录
  • 使用无效用户名登录
  • 使用空字段登录
  • 使用已锁定账户登录

2. 测试用例

测试用例 详细说明执行和验证特定功能的逐步过程。

测试用例的关键组成部分

组件描述
测试用例 ID唯一标识符（例如 TC001）
测试描述 / 标题对被测试内容的简短描述（例如 “验证使用有效凭证的登录功能”。）
前置条件执行前必须满足的条件（例如 “用户必须已在系统中注册”。）
测试步骤逐步指令（见下例）
测试数据测试所需的输入数据（例如 username = user1，password = Pass@123）
预期结果执行步骤后系统应当的行为（例如 “用户应被重定向到仪表板”。）
实际结果实际发生的情况（执行后填写）
状态通过 / 失败
备注可选的评论、缺陷或观察

示例测试用例

Test Case ID:      TC001
Title:             Verify login functionality with valid credentials
Preconditions:    User must be registered in the system
Test Steps:
  1. Open the login page
  2. Enter valid username (e.g., validuser)
  3. Enter valid password (e.g., validpassword123)
  4. Click the login button
Test Data:
  username = validuser
  password = validpassword123
Expected Result:  User is redirected to the dashboard
Actual Result:    (filled after execution)
Status:           Pass / Fail
Remarks:          (optional)

3. 正向与负向测试用例

3.1 正向测试用例

正向测试用例 使用有效输入，验证系统是否按预期工作。

示例 – 验证使用有效凭证登录

步骤操作
1打开登录页面
2输入有效的用户名（例如 validuser）
3输入正确的密码（例如 validpassword123）
4点击登录按钮

预期结果： 用户成功登录并被重定向到主页/仪表板。

3.2 负向测试用例

负向测试用例 使用无效输入，以确保系统能够优雅地处理错误。

示例 – 验证使用无效凭证登录

步骤操作
1打开登录页面
2输入无效的用户名（例如 invaliduser）
3输入错误的密码（例如 wrongpassword）
4点击登录按钮

预期结果：

  • 显示类似 “Invalid username or password.” 的错误信息。
  • 用户仍停留在登录页面，未登录成功。

4. 软件测试中的 Bug 是什么？

Bug（或缺陷）是指软件应用程序中的缺陷或偏差，导致它产生不正确或意外的结果，或表现出未被设计的行为。

示例 Bug

类型描述预期行为实际行为
UI Bug电子商务网站上按钮上的文字未对齐。文字应居中显示在按钮上。文字被推到按钮的左侧。
Functional Bug用户即使使用正确的凭据也无法登录。输入正确凭据后，用户应登录成功并被重定向到主页。提交有效凭据后，显示错误 “Invalid username or password.”（用户名或密码无效）。
Performance Bug网页加载产品列表耗时超过 30 秒。产品页面应在 5 秒内加载完成。页面加载时间超过 30 秒。

5. Bug 生命周期

Bug 生命周期描述了缺陷从发现到关闭所经历的各个阶段。

阶段

  1. New – 已发现缺陷，但尚未分析。
  2. Assigned – 已指派开发人员或团队来修复该缺陷。
  3. Open – 正在处理该缺陷。
  4. Fixed – 开发团队已修复该问题。
  5. Retest – 测试团队验证修复是否解决了问题。
  6. Closed – 确认缺陷已修复并关闭。
  7. Reopened – 如果在首次修复后问题仍然存在，则重新打开以进一步调查。

6. 常见缺陷状态

缺陷状态指示缺陷在其生命周期中的当前状态。

状态含义
New首次发现缺陷；尚未审查。
Open缺陷已审查并接受；已分配给开发人员。
Assigned明确分配给开发人员（在某些工具中与“Open”重复）。
In Progress开发人员正在积极修复。
Fixed开发已实现修复。
RetestQA 正在测试修复。
Closed缺陷已验证修复并关闭。
Reopened修复不足；缺陷重新打开以继续处理。

其他生命周期状态

状态描述
Pending Retest修复已部署到测试环境；等待测试人员验证。
Verified测试人员确认缺陷已成功修复。
Rejected缺陷无效（符合设计或无法复现）。
Duplicate系统中已存在该缺陷。
Deferred缺陷修复被推迟到后续版本。
Not a Bug报告的问题是系统预期行为。
Cannot Reproduce开发人员或测试人员无法复现该问题。
On Hold因依赖或缺少信息工作被暂停。
Won’t Fix已确认缺陷但因影响低而不予修复。

7. 软件测试中的缺陷严重性

Severity 表示缺陷从技术角度对软件的影响。它衡量缺陷的严重程度。

缺陷严重性等级

严重性描述示例
关键 / 阻断系统崩溃或无法使用；测试无法继续。应用启动时崩溃；服务器宕机。
主要 / 高主要功能受损；没有可用的变通方案。登录无法使用；支付处理失败。
中等 / 适中部分功能出现问题；有变通方案。搜索功能正常，但过滤器失效。
低 / 次要轻微问题，影响最小；外观或 UI 问题。按钮错位；字体不一致。

8. 软件测试中的缺陷优先级

Priority 表示缺陷需要多快修复。它帮助团队根据业务影响和时间表决定先处理哪些缺陷。

缺陷优先级层级

优先级描述示例
高优先级必须立即修复；影响关键业务功能。支付按钮无法使用；结账时应用崩溃。
中等优先级应当修复，但不需要立即；核心功能可通过变通方式使用。个人资料更新正常，但显示警告信息。
低优先级可以稍后修复；对用户体验影响较小。UI 对齐问题。

9. 软件测试员的角色与职责

软件测试员确保产品能够正确运行、满足需求并且没有缺陷。

软件测试员的角色

  1. 质量保证角色 – 确保软件符合质量标准和用户期望。
  2. 缺陷识别者 – 找出错误、缺陷和缺失的功能。
  3. 需求验证者 – 检查软件是否与给定的需求和规格相匹配。
  4. 用户倡导者 – 从终端用户的角度考虑，确保良好的可用性和功能性。
  5. 团队协作者 – 与开发人员、设计师和经理紧密合作，以改进产品。

软件测试员的职责

  1. 理解需求 – 仔细研究软件需求、设计和用例。
  2. 测试计划 – 制定测试计划，决定测试的内容、方式和时间。
  3. 测试用例设计 – 根据需求编写测试用例和测试场景。
  4. 测试执行 – 运行手动或自动化测试，以检查软件行为。
  5. 缺陷报告 – 明确识别、记录并使用缺陷跟踪工具报告 bug。
  6. 回归测试 – 在修复后重新测试，确保新更改不会破坏已有功能。
  7. 性能与安全测试 – 检查速度、稳定性以及基本的安全性（视需求而定）。
  8. 测试文档 – 维护测试用例、测试报告和测试结果。
  9. 自动化（如适用） – 开发并维护自动化测试脚本。
  10. 持续改进 – 提出改进测试流程和产品质量的建议。

Conclusion

从了解 SDLC/STLC 和测试类型到识别缺陷，软件测试确保每个产品可靠且用户友好。测试人员在维护质量和弥合开发与用户之间的差距方面发挥关键作用。有效的测试是交付真正可用软件的关键。

Back to Blog

相关文章

阅读更多 »