软件在上线前需要经过测试。以验证软件是否满足使用需求，同时尽可能减少软件中的 BUG 缺陷，保证软件质量。
分类#
按开发阶段划分#
- 单元测试 (Unit Testing)：测试程序代码模块（如函数）是否能正常工作，通常由开发人员自己进行。
- 集成测试 (Integration Testing)：也称联合调试。将已经通过单元测试的模块组合起来进行测试，验证它们之间的接口是否正确。（确保协同工作时候没问题）
- 系统测试 (System Testing)：将整个系统作为一个整体进行测试，验证其功能和非功能需求（包括兼容性测试、性能测试、安全性测试等）是全面的验证。通常会根据内部文档来执行。
- 验收测试 (Acceptance Testing)：由实际用户或客户进行的测试，以确定系统是否满足业务需求。形式上分为：内测（Alpha 测试）、公测（Beta 测试）。通常以公测的形式，确保产品在发布前尽可能发掘项目缺陷，更好地达到用户的期望，减少上线后的风险。
单元测试是一个模块内部的测试；集成测试是多个模块间的测试
按代码可见度划分#
-
黑盒测试 (Black Box Testing)：源代码不可见。UI 功能可见。不关心实现细节，只关心输入输出。主要是在用户的角度来验证系统的功能和性能。（比如功能上的，兼容性的和用户体验方面的测试）
-
白盒测试 (White Box Testing)：测试人员完全了解内部结构和实现细节，直接测试源代码。主要是开发人员做白盒测试。一般是在单元测试里使用。
-
灰盒测试 (Gray Box Testing)：黑盒测试和白盒测试的折中。测试从用户角度出发，但也对内部的实现逻辑有一定的了解。主要在集成测试里使用，用作接口测试等。
评估：软件质量模型#
八个质量维度均达标，则是一个优秀的软件
- 功能性 (Functionality) ：主要考虑软件提供的功能是否满足用户需求。包括：功能的数量和完整性，功能是否正确实现（如登录功能的正确性和错误处理），错误处理情况（如输入错误密码时的提示信息）
- 性能 (Performance)：主要考虑软件在高负载下的表现。包括：服务器每秒能处理多少请求数、现有硬件配置是否满足需求（如 CPU、内存）、优化以满足预期的用户数量（如 20 万在线用户）。
- 兼容性 (Compatibility)：主要考虑软件在不同软硬件环境下的表现。包括浏览器兼容性（如 Chrome、Firefox、Safari、IE、Edge 等五大浏览器）、操作系统兼容性（如 Windows 7/8/10/11, macOS, Linux 等）、移动设备兼容性（如分辨率、品牌、操作系统版本、网络类型等）以及与其他应用的兼容性（如支付宝、微信等）。
- 易用性 (Usability)：主要考虑软件是否易于使用。包括：界面简洁性、用户友好性（如操作流畅、文字清晰）、美观度（如界面设计）。
- 可靠性 (Reliability)：主要考虑软件在各种条件下的稳定性和无故障运行能力。包括：无响应（如登录时无反应）、卡顿（如游戏过程中卡顿）、死机（如软件崩溃）。
- 安全性 (Security)：主要考虑软件在数据传输和存储过程中的安全性。包括数据传输加密（如登录时的密码传输）、数据存储加密（如数据库中的敏感信息）。
- 可维护性 (Maintainability)：主要考虑软件在后期维护和更新时的便利性。包括代码的整洁性和注释、代码模块化和分离、网络和硬件的标签和整理。
- 可移植性 (Portability)：主要考虑软件在不同平台和环境下的迁移能力。包括数据迁移的便捷性（如服务器升级时的数据迁移）、软件在不同硬件上的安装和运行。
功能性、性能、兼容性、易用性和安全性是重中之重，通常也是必测的内容。
测试流程#
- 需求评审 (Requirement Review)：项目开始时，产品、开发和测试团队共同审查需求文档，确保各方对需求的理解一致，并识别核心功能和重要需求。
- 计划编写 (Test Planning)：根据需求评审的结果，编写详细的测试计划。哪些功能需要测试，谁来做这些测试，如何进行测试（采取什么测试策略。比如兼容性、性能等），测试时间表安排等等。
- 用例设计 (Test Case Design)：根据测试计划，设计具体的测试用例。每个测试用例包含测试步骤、输入数据和预期结果。用例需要覆盖所有需求和功能点。以确保测试的全面性和可重复性。
- 用例执行 (Test Case Execution)：按照设计好的测试用例进行实际测试，并记录实际结果。以验证软件的功能和性能是否符合需求。同时发现并记录缺陷。
- 缺陷管理 (Defect Management)：管理和跟踪发现的缺陷，返给开发人员，直到其被修复。确保所有发现的缺陷都得到及时处理和验证。
- 测试报告 (Test Report)：总结测试过程和结果，生成测试报告。报告需体现测试覆盖率、缺陷统计和分析、测试结论和建议。以提供项目的整体测试情况。为决策者提供依据，评估软件是否可以发布。
编写测试用例#
编写测试用例的作用
- 防止漏测：确保所有需求点都被覆盖，避免遗漏。
- 标准化：提供明确的测试步骤和预期结果，确保测试过程的一致性和可重复性。
格式#
- 用例编号 (Case ID)
格式：项目简称_模块简称_编号（如：ProjectName_ModuleName_001）
目的：唯一标识每个测试用例，便于管理和追踪。 - 用例标题 (Title)
格式：期望结果 + 功能描述
目的：简明扼要地描述该用例的测试目标，方便评审人员快速理解。 - 项目 / 模块 (Project/Module)
内容：指出该用例属于哪个项目或模块。
目的：明确测试范围，便于分类管理。 - 优先级 (Priority)
等级：P0 (最高) 到 P4 (最低)
目的：确定测试用例的执行顺序，核心功能（用户使用频率最高）通常设为 P0。 - 前置条件 (Preconditions)
内容：执行该用例前必须满足的条件。
目的：确保测试环境和状态正确，避免因环境问题导致测试失败。 - 操作步骤 (Steps)
内容：详细的测试步骤，包括每一步的具体操作。
目的：提供清晰的操作指南，确保测试人员能够按照相同的步骤进行测试。 - 测试数据 (Test Data)
内容：测试过程中使用的具体数据。
目的：确保测试数据的一致性和准确性，便于复现问题。 - 期望结果 (Expected Result)
内容：测试执行后应达到的结果。
目的：对比实际结果与预期结果，判断测试是否通过。
测试用例设计#
等价类划分法#
属于黑盒测试技术。将输入数据划分为不同的等价类。选取代表性的数据进行测试。减少用例数量，提高测试效率。
等价类分类
- 有效等价类：满足需求的数据集合。
- 无效等价类：不满足需求的数据集合。
如何划分等价类
- 明确需求：理解需求并确定划分依据（如性别、年龄等）。
- 划分等价类：根据需求将数据划分为有效和无效等价类。
- 提取数据：从每个等价类中选择代表性数据。
- 编写测试用例：基于提取的数据编写测试用例
案例 1
假设有一个验证 QQ 账号合法性的需求，要求 QQ 账号为 6 到 10 位自然数。以下是如何使用等价类划分法来设计测试用例：
- 有效等价类：
8 位自然数（例如：12345678）【长度校验】 - 无效等价类：
小于 6 位的自然数（例如：123）【长度校验】
大于 10 位的自然数（例如：12345678901）【长度校验】
8 位非自然数（例如：1234567a）【类型校验】
QQ 号为空【类型校验】
边界值分析法#
需要分别考虑：
- 上点（On Point）：刚好等于边界值的数据。
- 离点（Off Point）：距离边界值最近的数据，包括刚好大于和刚好小于边界值的数据。
- 内点（In Point）：区间内的数据，通常取居中的值。
案例 2
假设有一个需求，判断一个数是否小于 - 99 或大于 99，如果满足条件则给出错误提示。
- 上点：-99，99
- 离点：-100，-98，100，98
- 内点：0（或其他区间内的值，如 50）
然后分别设计测试用例来考虑
判定表（Decision Table）法#
判定表是一种黑盒测试技术，通过表格的形式将多个条件及其组合与相应的操作结果进行罗列，从而帮助设计测试用例。【解决条件依赖问题】
关键名词
- 条件桩（Condition Stubs）：列出所有条件。
- 动作桩（Action Stubs）：列出所有可能的操作或结果。
- 条件项（Condition Entries）：每个条件的具体取值（通常是 “是” 或 “否”）。
- 动作项（Action Entries）：根据条件项的组合确定的动作结果。
步骤
- 明确需求：理解需求中的条件和结果。
- 绘制判定表：
- 填写条件桩和动作桩。
- 根据条件桩填写条件项。
- 根据条件项组合填写动作项。
- 编写测试用例：基于判定表生成测试用例。
案例
假设有一个需求，涉及两个条件：用户是否欠费和用户手机是否关机。具体规则如下：
如果用户欠费且手机关机，则不允许拨打电话。
如果用户欠费但手机未关机，则允许拨打电话。
如果用户不欠费且手机关机，则允许拨打电话。
如果用户不欠费且手机未关机，则允许拨打电话。
| 用户是否欠费（条件桩） | 手机是否关机（条件桩） | 是否允许拨打电话（动作桩） |
|---|---|---|
| 是 | 是 | 不允许 |
| 是 | 否 | 允许 |
| 否 | 是 | 允许 |
| 否 | 否 | 允许 |
然后根据判定表设计用例。
场景法#
通过模拟用户使用软件的实际过程来设计测试用例。这种方法通常基于业务流程图或使用案例来确保整个业务流程能够顺利运行。
作用
- 覆盖业务流程：确保所有关键业务流程都能被正确执行。
- 提高用户体验：从用户角度出发，确保软件满足实际使用需求。
步骤
- 明确需求：理解业务流程的具体要求。
- 绘制流程图：包括开始、结束、判断和处理步骤。
- 编写测试用例：基于流程图生成测试用例，确保覆盖所有业务路径。
案例
假设有一个简单的登录系统，用户需要输入用户名和密码进行验证。具体规则如下：
如果用户名为 admin 且密码为 123456，则登录成功。
否则，登录失败。
首先要绘制流程图。（省略）
然后编写测试用例。
错误推测法#
错误推测法是一种基于经验和直觉来设计测试用例的方法。它依赖于测试人员的经验和对类似项目的了解，以推测系统可能出现的问题。
- 快速发现缺陷：通过经验快速识别可能存在的问题。
- 补充其他方法：作为其他测试方法的补充，确保测试覆盖更全面
主要思想
- 列举问题清单：根据经验列出可能出现的问题。
- 分析问题原因：对每个可能的问题进行分析，找出可能的原因。
- 发现缺陷：根据分析结果设计测试用例，验证并发现缺陷。
使用场景 - 时间紧、任务量大：当项目时间紧迫且任务繁重时，无法进行全面详细的测试。
- 项目后期：当所有计划内的测试用例都已执行完毕，并且已知的缺陷已被修复，但距离上线还有一段时间时，可以使用错误推测法进行最后的复测。
案例
假设一个电商项目即将上线，所有的计划内测试用例已经执行完毕，并且已知的缺陷也已经被修复。此时距离上线还有几个小时的时间，可以采用错误推测法进行最后的检查。
测试步骤
- 回顾经验：回忆过去在类似项目中遇到的问题。
- 列出问题清单：
a) 用户登录过程中可能的异常情况（如密码输入错误次数限制、验证码失效等）。
b) 购物车功能中的边界条件（如添加大量商品后的响应）。
c) 支付过程中的网络中断或支付失败的情况。 - 设计测试用例：基于上述清单设计测试用例。
- 执行测试：根据设计的测试用例进行测试，验证是否存在这些问题。
软件缺陷管理#
软件缺陷是指在使用过程中存在的任何问题，不仅仅是代码错误，还包括功能缺失、性能问题、易用性问题等
产生原因
- 需求阶段：需求描述不清晰或有歧义。
- 设计阶段：设计错误或不合理。
- 编码阶段：编写代码时的错误（如逻辑错误、语法错误或其他编程错误）
- 运行阶段：比如兼容性问题或其他环境问题。（比如在某个系统某个版本上程序会崩溃）
评定标准
- 未实现需求规格说明中的明确要求的功能：如果软件没有实现客户或产品文档中明确要求的功能，则视为缺陷。
例如，如果合同规定了十个功能，但实际交付了八个功能，即使这八个功能完美无缺，仍然是有缺陷的。 - 出现需求说明书指明不应该出现的错误：这包括功能上的逻辑错误，如计算错误或不符合预期的行为。
例如，要求 1+1=3，但软件实现了 1+1=2；或者要求只能通过身份证号登录，但软件允许手机号登录。 - 超出需求说明书指明的范围：即使是额外的功能，如果这些功能未经请求且可能带来负面影响，也会被视为缺陷。
例如，电商软件提供了一个未经请求的功能，允许用户随意退货，而实际上应该有一个严格的审批流程。 - 未实现需求规格书中虽未指明但应实现的要求：指的是隐性功能，即虽然需求文档中没有明确指出，但根据常识和用户体验应该实现的功能。
例如，预期结果中的一些非功能性需求，如用户友好性和交互体验。 - 软件难以理解、不易使用、运行缓慢：
从测试人员的专业角度出发，如果软件难以理解、不易使用或运行缓慢，也被视为缺陷。
测试人员需要站在用户的角度考虑软件的易用性和用户体验。
缺陷管理流程
- 发现缺陷：在测试过程中发现不符合上述标准的问题。
- 记录缺陷：使用工具（如 JIRA、Bugzilla 等）或 Excel 记录缺陷，包括缺陷描述、重现步骤、严重程度等。
- 分配缺陷：将缺陷分配给相应的开发人员进行修复。
- 修复缺陷：开发人员修复缺陷，并提交修复后的版本。
- 验证缺陷：测试人员验证修复后的版本，确认缺陷是否已解决。
- 关闭缺陷：如果缺陷已解决，关闭缺陷；否则，重新分配并继续修复。
缺陷生命周期
- 注入缺陷：在需求、设计、编码等阶段，由于各种原因（如需求不明确、设计错误、编码错误）而引入的缺陷。
- 发现缺陷：测试人员通过测试用例执行，发现并记录缺陷。
- 分类和优先级划分：根据缺陷的严重程度和影响范围，对其进行分类和优先级划分。
- 分配和修复：将缺陷分配给相应的开发人员进行修复。
- 验证缺陷：测试人员验证修复后的缺陷，确认是否已解决。
- 关闭缺陷：如果缺陷已解决，关闭缺陷；否则，重新分配并继续修复。
- 回归测试：修复缺陷后，进行回归测试以确保新修复的代码没有引入新的缺陷。
工具
缺陷管理工具：JIRA, Bugzilla, Mantis, TestRail 等。
电子表格：Excel 也可以用于简单的缺陷跟踪。
任何一个阶段的问题都会影响整个项目的质量（木桶效应） 所以每个阶段都需要严格把关。
缺陷报告与提交#
如何描述软件缺陷
- 缺陷标题：简洁明了地描述缺陷的核心问题。例如：“用户登录时密码输入框无法显示星号。”
- 前置条件：描述在复现缺陷之前必须满足的条件。例如：“用户已注册账号，并处于未登录状态。”
- 复现步骤：详细列出复现缺陷的具体步骤。例如：“1. 打开登录页面；2. 输入用户名；3. 输入密码；4. 点击登录按钮。”
- 预期结果：描述执行上述步骤后应得到的结果。
例如：“用户成功登录系统。” - 实际结果：描述执行上述步骤后实际得到的结果。例如：“用户无法登录，页面提示‘密码格式错误’。”
- 附件（可选）：提供有助于理解和复现缺陷的附加信息，如截图、日志文件等。例如：附上登录页面的截图和错误日志。
缺陷提交
一般通过缺陷管理工具来填写。通常还需要包括以下信息。
- 缺陷编号：每个缺陷都有一个唯一的编号，便于跟踪和管理。
- 严重程度：通常分为 S1（非常严重）、S2（严重）、S3（一般）、S4（轻微）等。例如：主功能模块的问题通常是 S1 或 S2，次要功能模块的问题可能是 S3 或 S4。
- 优先级：通常分为 P1（紧急）、P2（高）、P3（中）、P4（低）等。例如：P1 级别的缺陷要求 24 小时内解决，P2 级别的缺陷要求发布前解决。
- 缺陷类型：包括代码错误、兼容性问题、设计缺陷、性能问题等。例如：选择 “代码错误” 表示是编程上的问题，“兼容性问题” 表示不同环境下的问题。
- 缺陷状态：常见的状态有新建（New）、打开（Open）、关闭（Closed）、延期（Deferred）等。例如：新建表示刚刚提交的缺陷，打开表示正在处理中的缺陷，关闭表示已修复的缺陷。
缺陷类型
- 功能性错误：软件的功能没有按预期工作。例如：某个按钮点击后没有响应。
- 界面 / UI 错误：用户界面的问题，如布局不正确、图片显示不全等。例如：登录页面的 Logo 显示不完整。
- 兼容性问题：软件在不同的操作系统或浏览器中表现不一致。例如：在 Chrome 中正常，在 Firefox 中无法使用。
- 数据问题：数据库相关的问题，如数据丢失、数据不一致等。例如：用户数据在数据库中未能正确存储。
- 易用性问题：软件的用户体验问题，如操作复杂、导航不直观等。例如：用户难以找到某个功能的入口。
- 建议性问题：对软件功能或界面的改进建议。例如：建议增加夜间模式。
- 架构设计缺陷：软件架构设计上的问题，可能导致整体性能或稳定性问题。例如：数据库连接池配置不合理导致性能瓶颈。
缺陷管理工具
可以使用 DevOps 工具即可代劳。比如禅道。或其他软件。
集成了产品管理、项目管理和质量管理。能够明确产品、研发、测试和项目管理的角色及其职责。
DevOps 一词的来自于 Development 和 Operations 的组合。突出重视软件开发人员和运维人员的沟通合作。通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。