软件测试基础

分类

1. 按测试目的分类

• 功能测试：验证系统或软件是否按照需求文档的描述实现了预期功能。功能测试关注的是“做什么”，而不是“怎么做”。

  • 例子：测试登录功能是否接受正确的用户名和密码，并拒绝错误的组合。

• 非功能测试：关注系统的性能、可靠性、安全性、易用性等非功能性需求，确保软件在各种条件下的表现。

  • 性能测试：测试软件在不同负载下的响应速度、吞吐量等。
  • 安全测试：确保系统的访问控制、数据保护等机制能有效防止安全漏洞。
  • 兼容性测试：确保软件在不同操作系统、浏览器或设备上运行正常。
  • 可用性测试：检查用户界面的易用性和用户体验。

2. 按执行方式分类

• 手动测试：由测试人员按照预定义的测试用例手动执行测试，通常用于探索性测试和用户界面测试。

  • 优点：便于发现UI细节、用户体验等问题。
  • 缺点：耗时，且对重复性测试不适用。

• 自动化测试：通过编写脚本或使用自动化工具来执行测试。适用于回归测试、性能测试等场景。

  • 优点：提高效率、减少人工错误，适合重复性测试。
  • 缺点：初期投入高，需要维护脚本。

• 探索性测试：测试人员不依赖预定义的测试用例，而是在测试过程中灵活探索系统的不同功能。适用于初次测试或需求不明确时。

  • 优点：可快速找到潜在缺陷，尤其适合发现系统中的异常。
  • 缺点：难以重复测试结果，依赖测试人员的经验。

3. 按测试阶段分类

• 单元测试：由开发人员进行，用于验证单个模块、函数或方法的功能。它是最细粒度的测试，通常用白盒测试方法。

  • 优点：能在早期发现问题，提高代码质量。
  • 缺点：只关注单个模块，不测试模块之间的集成效果。

• 集成测试：测试多个模块的集成情况，确保它们之间的接口和交互正常。常用的方式有增量集成（逐步集成）和非增量集成（大爆炸集成）。

  • 优点：可以发现模块之间的集成问题。
  • 缺点：依赖单元测试的基础，部分模块尚未完成时可能无法进行。

• 系统测试：在完整的系统环境中测试整个软件系统，确保软件在集成后能按预期工作。包括功能测试和非功能测试。

  • 优点：从用户视角测试软件的整体质量。
  • 缺点：可能会覆盖不全面，依赖于测试环境的搭建。

• 验收测试：在系统测试基础上，由用户或产品经理验证软件是否满足业务需求。分为Alpha测试（内部测试）和Beta测试（用户测试）。

  • 优点：确保软件符合客户或最终用户的期望。
  • 缺点：在接近发布阶段进行，发现问题的成本较高。

4. 按测试方法分类

• 白盒测试：测试人员了解代码结构，从内部逻辑上测试软件是否正确实现。常用于单元测试。

  • 优点：深入检查代码逻辑，适合查找隐性问题。
  • 缺点：对复杂系统不适用，无法发现UI问题。

• 黑盒测试：测试人员无需了解代码，依据需求和功能对软件进行测试。适用于功能测试、系统测试。

  • 优点：测试从用户视角出发，注重系统功能的正确性。
  • 缺点：无法深入检查代码内部逻辑，测试覆盖面有限。

• 灰盒测试：结合黑盒和白盒测试，测试人员部分了解内部结构，同时关注外部功能的表现。

  • 优点：适合集成测试，能够提高测试的有效性。
  • 缺点：需要部分代码理解，难以覆盖全部逻辑。

5. 按关注点分类

• 回归测试：在软件修改后重新测试，确保新代码没有引入新的问题。回归测试通常使用自动化。

  • 例子：修复某个功能的缺陷后，重新执行原有测试用例，确保修复未影响其他功能。

• 烟雾测试（冒烟测试）：检查软件的主要功能是否可以正常工作，验证系统的基本稳定性。常用于新版本发布前的快速测试。

  • 例子：确保系统能启动、主要功能如登录、搜索等可以正常使用。

• 性能测试：测试系统的响应时间、吞吐量、资源消耗等，确保系统能在预期负载下正常运行。常见类型包括负载测试、压力测试、稳定性测试等。

  • 例子：测试在高并发请求下，系统的响应时间是否符合需求。

• 安全测试：确保系统能够抵御潜在的攻击，保护用户数据和隐私。包括漏洞扫描、渗透测试等。

  • 例子：检查系统是否存在SQL注入、XSS攻击等常见漏洞。

• 兼容性测试：验证软件在不同平台、浏览器、设备等环境下是否能正常运行，确保用户在各种场景下都能正常使用。

  • 例子：确保Web应用在Chrome、Firefox和Safari浏览器上显示一致。

6. 特殊类型测试

• 用户验收测试（UAT）：最终用户执行的测试，确保软件符合业务需求。通常在实际操作环境中进行。
• Alpha测试：由公司内部员工测试，通常是在开发团队和测试团队之外的人员。
• Beta测试：由实际用户在真实环境下使用软件，反馈问题和建议，通常是软件发布前的最后测试阶段。

质量模型

ISO/IEC 25010 是当前广泛使用的软件质量模型，定义了质量的八个主要特性：

• 功能适合性（Functional Suitability）：指软件在指定的任务下，提供准确和适当功能的能力，包括功能完成度、功能正确性和功能适用性。
• 性能效率（Performance Efficiency）：关注软件在给定条件下资源的使用情况，包括时间表现、资源利用率、容量等。
• 兼容性（Compatibility）：软件与其他产品或系统共存的能力，包含共存性和互操作性。
• 可用性（Usability）：软件的可学习性、可操作性、用户错误控制等，确保用户在使用中的便利性。
• 可靠性（Reliability）：软件在规定条件下持续运行的能力，包括成熟性、可恢复性、容错性。
• 安全性（Security）：软件防止数据泄露、未经授权访问等的能力，包括机密性、完整性、可审核性、责任性和非否认性。
• 可维护性（Maintainability）：软件可以被有效维护的难易程度，包括模块化、可重用性、易理解性、易测试性。
• 可移植性（Portability）：软件在不同环境中迁移的难易程度，包括可适应性、可安装性、可替代性。

这些特性为测试制定了目标，例如：性能测试关注性能效率，安全测试关注安全性，可用性测试关注可用性等。

测试流程

测试流程（STLC：Software Testing Life Cycle）指软件测试的系统化流程，通过各个阶段来保证测试的科学性和全面性，确保软件满足质量标准。STLC 包括以下主要阶段：

1. 需求分析

• 目标：理解并分析业务需求，明确测试范围。
• 活动：与产品经理、业务分析师沟通，获取并评估需求文档，识别可测试的功能点和非功能需求。
• 输出：需求分析文档、测试需求列表。

2. 测试计划

• 目标：制定测试策略、时间表和资源分配，确定测试优先级和范围。
• 活动：编写测试计划，包括测试范围、测试类型、资源需求、风险分析等。
• 输出：测试计划文档。

3. 测试设计

• 目标：编写详细的测试用例，准备测试数据和测试环境。
• 活动：设计测试用例和测试场景，准备测试数据和测试环境。
• 输出：测试用例文档、测试数据。

4. 测试执行

• 目标：执行测试用例，记录测试结果。
• 活动：按照测试用例执行测试，记录通过或失败的结果，并提交缺陷报告。
• 输出：测试执行报告、缺陷报告。

5. 缺陷管理

• 目标：跟踪和管理测试过程中发现的缺陷。
• 活动：使用缺陷管理工具记录、跟踪和更新缺陷状态，协调开发团队修复缺陷。
• 输出：缺陷报告、缺陷状态跟踪记录。

6. 回归测试

• 目标：确保在缺陷修复或新功能加入后，系统未受影响。
• 活动：重新执行部分或全部测试用例，特别是缺陷相关部分，以验证修复效果。
• 输出：回归测试结果。

7. 测试闭环

• 目标：评估测试目标的实现程度，生成最终测试报告。
• 活动：总结测试活动，评估残留风险，生成测试总结报告。
• 输出：测试总结报告。

测试用例

测试用例是对测试场景、测试步骤及预期结果的详细描述，用于指导测试执行和验证。一个高质量的测试用例设计，能有效提高测试效率和测试覆盖率。测试用例一般包含以下要素：

测试用例组成部分

• 用例编号：为每个测试用例分配唯一编号，方便管理和追踪。
• 用例描述：对测试用例的简要描述，说明测试的目标。
• 前置条件：测试开始前需满足的条件，例如系统状态、数据准备等。
• 测试步骤：详细描述测试的具体操作步骤，确保测试人员知道如何操作。
• 输入数据：在测试过程中使用的数据，确保测试的可重复性。
• 预期结果：明确的测试期望结果，用于验证测试通过与否。
• 实际结果：测试执行后的实际观察结果，与预期结果对比判断测试是否通过。
• 通过/失败状态：根据实际结果与预期结果对比，记录测试状态。
• 备注：附加说明或注意事项。

示例测试用例

以下是一个登录功能的测试用例示例：

用例编号	TC-001
用例描述	验证用户可以用正确的用户名和密码登录系统
前置条件	系统已启动，用户已注册
测试步骤	1. 打开登录页面 2. 输入有效用户名和密码 3. 点击“登录”按钮
输入数据	用户名: testuser 密码: correct_password
预期结果	用户成功登录，进入系统主页
实际结果	—
通过/失败	—
备注

编写测试用例的原则

• 明确性：测试用例描述要清晰，易于理解，避免歧义。
• 独立性：每个测试用例应独立，能够单独执行，而不依赖其他测试用例。
• 可重复性：测试用例应设计为在任何时候均可重复执行，保证一致性。
• 覆盖性：测试用例应覆盖各类场景，包括正常路径、异常路径和边界情况。
• 优先级：根据重要性和风险程度为测试用例分配优先级，优先执行关键测试用例。