测试基础理论是测试工作的基础
一、软件测试的定义和目的
定义：软件测试是规定条件下对软件产品进行操作，发现软件中的错误和缺陷，衡量软件质量，并对软件是否满足设计要求进行评估的过程。
目的：
- 验证软件是否满足需求和用户期望
- 发现缺陷和错误，提高软件质量
- 提高可靠性和稳定性
- 了解软件性能和功能，以便优化和改进
二、软件测试的原则
软件测试应尽早测试、全面测试、基于风险测试、迭代测试、具备客观性等。
- 尽早原则：应该开发的早起阶段尽早介入，降低修复成本
- 全面原则：对功能、模块、接口、边界条件等进行全面测试，确保软件质量
- 基于风险测试：根据功能、复杂度、使用频率等因素，评估高风险重点测试
- 迭代测试：软件测试要持续迭代，确保软件质量
- 客观性：测试人员应该保持客观，准确发现和报告软件中的问题
三、软件测试类型
3.1 开发阶段划分
3.1.1 单元测试
对软件最小可测单位进行检查验证，一般是针对函数、类、模块进行的测试，一般由开发人员自己完成，保证每个单元的正确性，一般是使用白盒测试的方法。
3.1.2 集成测试
- 单测之后，测试模块间的接口，使用白盒和黑盒测试方法，关注模块间的数据传输和功能冲突。
- 讲多个单元组合在一起测试，检查单元间的接口和数据传递是否正确。
- 可以分为自顶向下，自底向上和混合等多种方式。
3.1.3 系统测试
- 测试完整系统，包括功能、性能和运行环境，依据需求由黑盒测试工程执行
- 整个软件系统作为一个整体，验证系统师傅符合需求和规格说明
- 包括功能、性能、兼容性、安全性测试等。
3.1.4 验收测试
- 分为α测试和β测试
- 软件部署前的最终测试，由用户或需求方使用黑盒测试方法执行，验证软件是否满足用户的需求和期望。
3.2 查看代码划分
3.2.1 黑盒测试
- 不关心程序结构，关注输入输出
- 测试人员不了解内部实现细节，根据规格说明书来设计测试用例，检查软件是否符合要求
- 主要关注软件的外部行为和功能表现
3.2.2 白盒测试
- 研究程序逻辑
- 对内部结构和代码有深入了解，根据代码逻辑设计测试用例，检查逻辑正确性和覆盖程度。
3.2.3 灰盒测试
- 介于黑白之间，关注功能和接口
- 对于逻辑有一定了解，但不会像白盒一样详细。
- 关注外部功能和考虑内部结构。
3.3 按是否运行划分
3.3.1 静态测试
- 不运行软件，根据文档代码等进行检查和分析，发现潜在问题
- 代码审查、文档审核、静态分析等工作方式
3.3.2 动态测试
- 运行软件检查功能、性能、安全等
- 包括功能测试、性能测试、压力测试、兼容性测试等
3.4 按照测试对象划分
3.4.1 页面测试
观测用户软件的布局、颜色、字体等，部分公司有UI进行检查
3.4.2 数据测试
检查软件处理数据的准确性，完整性和一致性，包括数据输入，检索，输出等。
3.4.3 易用性测试
操作简便性、用户学习成本、满意度等。
3.4.4 业务逻辑测试
验证软件的业务流程和逻辑是否正确，是否符合业务需求。
3.4.5 性能测试
评估软件在不同负载下的性能表现，响应时间，吞吐量，资源利用率等。
3.4.6 安全测试
数据泄露、权限管理不当
3.4.7 兼容性测试
不同操作系统，浏览器，硬件平台下的兼容性
3.4.8 文档测试
基于需求文档、设计文档进行测试，确保文档的完整性
3.4.9 安装测试
安装过程是否正确和顺利
3.4.10 可靠性测试
在规定时间和条件下，完成规定的功能的能力
3.4.11 恢复测试
检查系统的容错能力，系统故障能否在规定时间内恢复。
3.5 按测试实施的组织划分
α测试
开发环境下内部用户测试
β测试
软件最终用户在实际使用环境测试
3.6 是否手工执行划分
3.6.1 手工测试/功能测试
人工输入用例并观察结果
3.6.2 自动化测试
预设条件下运行软件，评估运行结果
3.7 测试地域划分
一般会涉及到对外软件，分为国际化测试和本地化测试。
软件测试的分类有助于理解测试目的和方法。不同的测试关注点不同，如功能、性能、安全等都有独特的测试方法和重点。通过合理的测试策略，确保软件符合用户的需求和期待。
四、软件测试的流程
虽然不同的软件测试流程有不同之处，但一般都会遵循基础测试流程，会根据项目要求对实际情况而定。
4.1 需求评审阶段
- 参与需求讨论和评审会议，由产品和开发团队共同对软件需求进行详细分析理解
- 确保对需求的功能、性能、页面等有清晰认知，明确测试的重点和范围
- 提出对需求的疑问和建议
4.2 制定测试计划
- 明确测试目标：确认软件需要达到的质量标准和预期功能实现
- 界定测试范围：确定需要测试的功能、模块、特性等
- 制定测试测试：选择合适的测试方法和技术
- 规划测试资源：人力、时间、硬软件资源分配
- 测试时间表：制定猜测是进度计划，确保工作按时完成。
4.3 测试用例设计
- 依据需求文档和测试计划，设计详细的测试用例
- 考虑正常和异常的测试场景，包括功能、性能、兼容性、安全测试等
- 对测试用例进行编号和分类，确保具有良好的可读性和可维护性
- 组织测试用例评审，邀请产品和开发人员参与，确保测试用例的完整性和有效性
4.4 测试环境搭建
- 准备硬件设备、系统、数据库、中间件等测试环境
- 安装和配置软件和工具，确保稳定性和兼容性
- 对测试环境进行验证和调试，确保满足测试要求
4.5 测试执行
- 按照测试计划和用例逐步执行测试
- 记录测试过程实际结果，包括通过和发现的缺陷
- 对发现的缺陷进行详细记录，描述缺陷出现的步骤，严重程度，优先级等信息
- 及时反馈给开发团队，跟踪缺陷的修复情况
4.6 缺陷管理和跟踪
- 缺陷记录，缺陷描述、发现时间、发现人、所属模块、严重程度、优先级
- 缺陷修复过程：缺陷分配给开发人员，跟踪修复情况，确保按照修复缺陷
- 进行验证：进行回归测试，验证是否正确修复，同时检查是否引入新的缺陷
4.7 测试评估阶段
- 根据测试结果，评估软件质量
- 分析测试数据，评估软件功能、性能、兼容性
- 编写测试报告，总结测试过程中遇到的情况，测试结果，发现的问题，统计数据等
4.8 测试报告
- 对测试过程进行总结，回顾测试过程中遇到的问题和解决方案
- 向产品和开发团队反馈测试结果，提出改进建议
- 参与项目总结会议，为后续工作积累经验和提供参考
五、软件测试方法
5.1 黑盒测试
黑盒测试中测试人员不关注内部结构与实现，关注输入输出，功能表现，根据规格说明书来设计测试用例
5.1.1 等价类划分法
- 输入数据划分为若干等价类，每种等价类代表一种可能的输入情况。
- 等价类可分为有效等价类和无效等价类
- 有效等价类：符合需求的输入数据
- 无效等价类：不符合需求的输入数据
- 从等价类中选取代表性的数据进行测试，以覆盖各种输入情况
- 如需要输入整数
- 有效等价类：随机的整数
- 无效等价类：小数
5.1.2 边界值分析法
- 选取数据数据范围的边界值进行测试，往往边界值附近更容易出现错误
- 如需要输入整数范围1-100
- 选取-1，1,1.1
- 选取99,99.1,101
- …
5.1.3 因果图法
- 通过分析输入条件之间的因果关系生成判定表，从而设计测试用例
- 适用于输入条件之间存在多种组合关系
- 如条件A和B都需要满足才能输出结果C
- A已登录
- B已付费
- C查看结果
5.1.4 决策表法
- 将条件和动作列出表格，根据条件组合确定采取的动作从而设计测试用例。
- 适用于条件和动作之间存在复杂逻辑关系
5.1.5 正交试验法
- 从大量的试验点中挑选出适量的、有代表性的点，应用依据伽罗瓦理论导出的“正交表”，合理地安排试验的一种科学的试验设计方法。
- 如表单中，必填字段A，B，C各有3个参数，那么尝试所有组合方案有3x3x3=27种组合，但是出于时间关系，就可以采用正交表，讲27种组合剪至9种组合即可。
正交表示例：
| 测试用例编号 | A | B | C |
|---|---|---|---|
| T1 | 0 | 0 | 0 |
| T2 | 0 | 1 | 2 |
| T3 | 0 | 2 | 1 |
| T4 | 1 | 0 | 1 |
| T5 | 1 | 1 | 2 |
| T6 | 1 | 2 | 0 |
| T7 | 2 | 0 | 2 |
| T8 | 2 | 1 | 0 |
| T9 | 2 | 2 | 1 |
5.1.6 场景法
通过模拟用户的操作场景来设计测试用例，主要用于测试系统的业务流程。场景法通常包括基本流（正常的操作流程）和备选流（异常的操作流程）。
对于一个网上购物的系统，基本流为用户登录、选择商品、加入购物车、结算、支付。备选流可以包括用户未登录时进行操作、商品库存不足、支付失败等情况。根据这些流程设计测试用例。
5.1.7 错误推测法
基于经验和直觉推测软件中可能产生的错误，针对性设计测试用例。
对于一个登录功能，测试人员可能会推测用户可能会输入错误的用户名或密码，或者输入的用户名或密码为空，或者输入的用户名或密码包含特殊字符等情况，然后针对这些推测设计相应的测试用例。
5.2 白盒测试
5.2.1 语句覆盖
- 确保程序中每一条语句都至少执行一次。
- 是一种较弱的覆盖标准，可能会无法发现逻辑错误，特别在判定语句中
1 | (a > b): |
一个满足语句覆盖的测试用例可以是 a = 2, b = 1
5.2.2 判定覆盖
- 要求所有分支都要执行一遍，但仍然可能会忽略某些条件组合导致覆盖度不足
1 | (a > b): |
满足判定覆盖的测试用例可以是 a = 2, b = 1（使判定为真）和 a = 1, b = 2（使判定为假）
5.2.3 条件覆盖
- 确保判定中每个条件可能的取值至少满足一次
- 多个条件的判定需要考虑每个条件的各种可能取值
- 例如，对于代码 if (a > b and c > d)，条件覆盖的测试用例需要包括 a > b 为真和为假的情况，以及 c > d 为真和为假的情况。
5.2.4 判定-条件覆盖
- 结合判定和条件覆盖，既保证每个判定结果出现一次，也保证每个条件的取值至少才出现一次
- 对于复杂的判定语句，需要仔细设计测试用例满足要求
5.2.5 条件组合覆盖
- 使每个判定中条件的各种可能组合都至少出现一次。
- 这是一种较强的覆盖标准，但在实际应用中，可能会因为条件组合的数量过多而导致测试用例数量庞大。
5.2.6 路径覆盖
- 覆盖程序所有路径
- 非常严格的标准，但往往受项目时长，复杂度等限制难以实现，路径数量较多。
在实际的测试中，需要根据项目的需求和资源情况，选择合适的覆盖标准来设计测试用例。
5.3 灰度测试
- 介于白盒和黑盒之间的测试方法，关注外部功能表现的同时，也关注内部结构和逻辑
- 测试人员会了解部分软件的内部实现细节，例如软件的架构和模块之间的关系等，又不会像白盒测试一样精细到每一行代码
5.4 探索性测试
强调测试人员在测试过程中的主观性和创造性，保证测试的同时降低成本时间。
5.5 冒烟测试
对软件的基本功能快速测试，确定软件是否具备可测试性
5.6 随机测试
随机选择输入数据和操作步骤测试，发现一些隐藏问题。
5.7 接口测试
对软件的内外接口进行测试，检查接口传参、数据格式、异常处理等方面是否符合设计要求，确保不同模块或系统之间正确交互。
5.8 集成测试
将多个模块或组件集成在一起进行测试，检查它们之间的接口和协作是否正常，发现集成过程中可能出现的问题。
5.9 系统测试
将整个软件系统作为一个整体进行测试，验证系统的功能、性能、安全性、兼容性等方面是否满足需求和规格说明
5.10 回归测试
缺陷修复后，重新对相关功能测试，以确保修改没有引入新的问题，同时原有功能正常进行
5.11 兼容性测试
- 系统兼容性：不同操作系统或平台运行
- 浏览器兼容性：多种主流浏览器运行
- 硬件兼容性：不同的设备
5.12 本地化测试
不同国家或地区的语言、文化、货币、日期等
5.13 可用性测试
评估软件的的易用性和用户体验，通过实际试用的行为反馈，来提高软件可用性
六、测试用例的设计
- 测试用例定义
- 为了特定目的而设计的一组测试输入，执行条件和预期结果的集合
- 是软件的重要组成部分，用于验证软件的需求功能，性能等。
- 测试用例的重要性
- 全面设计测试用例，发现缺陷和错误，提高软件的质量和可靠性
- 合理的测试用例可以减少重复测试，提高效率和覆盖率
- 可以作为执行测试的依据，便于测试管理和缺陷跟踪
- 作为开发人员和产品人员沟通桥梁，促进团队合作
| Title | Description |
|---|---|
| 用例编号 | 用于唯一标识每个测试用例，方便管理和跟踪。。 |
| 测试项目/模块 | 描述被测试的功能或特性，明确测试的范围和对象 |
| 测试目的 | 阐明该测试用例的测试目标，即希望通过该测试用例验证的内容。 |
| 前置条件 | 列出执行该测试用例所需的前提条件 |
| 测试步骤 | 详细描述执行测试的操作过程，包括输入数据、操作步骤和执行顺序等。 |
| 预期结果 | 说明在执行测试步骤后应该得到的结果，包括界面显示、数据输出、系统响应等方面的预期。 |
| 优先级 | 表示该测试用例的重要程度和执行的先后顺序。 |
| 测试类型 | 如功能测试、性能测试、安全测试等，明确测试的性质。 |
| 实际结果 | 在执行测试后记录实际得到的结果，用于与预期结果进行对比，判断测试是否通过。 |
| 测试人员 | 记录执行该测试用例的人员，以便在出现问题时进行追溯和责任认定。 |
| 测试时间 | 记录测试用例的执行时间，便于对测试进度进行监控和管理。 |
| 测试级别 | 确定测试的级别，如单元测试、集成测试、系统测试等。例如：系统测试。 |
6.1 测试用例注意事项
- 覆盖全面：尽可能覆盖软件的各种功能，场景和边界
- 有效性：测试用例应该能够有效发现软件中的缺陷和问题，避免无效的测试用例浪费时间和资源
- 可重复性：用例应该可以在不同环境和条件下重复执行，确保结果一致性和可靠性
- 可读性： 具有良好的可读性和可理解性，以便其他人员能够理解
- 及时更新： 软件迭代，测试用例也应该及时进行更新和维护
七、缺陷管理
测试过程中非常重要的一环，旨在记录、跟踪和解决软件中的bug，确保软件的质量和稳定性，还可以提高开发和测试团队的协作效率，降低软件发布后的风险。
7.1 缺陷管理流程
- 缺陷报告
- 发现缺陷，及时详细记录缺陷的相关信息，重现步骤，预期结果和实际结果等
- 使用jira、bugzilla等软件提交缺陷报告
- bug等级和分类
- 对bug进行优先级划分，根据bug的严重程度和影响范围，确定修复优先级
- 常见的分类包括功能缺陷、性能缺陷、安全缺陷、页面缺陷等
- bug分配
- bug分配给相关开发人员或负责人，确保每个bug都有明确的负责人
- 开发人员根据报告分析问题，进行修复
- bug修复
- 开发人员修复bug，提交代码，进行自测，确保bug修复
- 保持与测试人员的沟通
- bug验证
- 测试人员收到修复反馈，需要对修复的bug进行测试，并确保没有引入新的bug
- 验证通过，关闭bug报告，如果后期发现再次出现，则重新打开bug报告
- bug报告和分析
- 定期生成bug报告，统计数量，类型，严重程度，修复时间等问题
- 通过分析，发现开发和测试过程中的薄弱环节，提出改进建议，优化开发和测试流程
7.2 bug组成部分
- 编号：每个bug都有唯一的编号
- 标题：简要描述bug内容，是快速了解bug的主要信息
- 描述：描述具体情况，当时的环境，操作步骤等
- 类型：功能、性能、安全、界面缺陷
- 严重程度：致命、严重、一般、轻微
- 优先级：高中低等，或用数字表示
- 发现人：记录人员信息
- 时间：发现时间
- 模块：功能模块
- 重现步骤：详细描述操作步骤，附带的参数等
- 附件：相关截图和日志等。
八、测试模型
软件测试中有几种常见的测试模型，v模型，w模型，H模型和敏捷测试模型，它们提供了结构化的方法来规划和执行测试，可以帮助测试更加有效地组织和管理整个测试过程，现代测试基本都以敏捷测试为主。
8.1 v模型
是瀑布模型的一种改进，强调开发和测试活动的对称性和相互依赖关系。
优点
-明确的阶段性结构，开发和测试活动进展可控
-风险导向的测试，有助于发现和解决软件中的重要问题，提高测试效率和质量
缺点
测试活动滞后，无法及时发现和解决问题，可能增加修复成本，并延长交付时间
缺乏灵活性和迭代性，面对需求变化频繁和迭代开发的项目不够灵活
适用范围
- 适用于中大型企业，通常企业有成熟的软件开发和测试流程，且能够承担一定的测试成本和资源投入
8.2 w模型
W模型模明确标注了测试与开发同步进行的关系，且能表现出测试能更提早介入测试中，各个阶段伴进行不同测试设计
优点
注重迭代开发，测试与开发同步进行，及早介入测试，可更早发现问题
更加灵活和变通，测试与开发同步进行可以快速响应需求变化
提高了风险管理，版本迭代中可以进行风险评估和优先级的确定，可将主要目光放在高风险测试点
缺点
对于版本迭代需求稳定要求比较高，无法支持迭代
有些项目急短快，无各种文档产生，模型就不使用
针对测试要求较高
适用范围
- 适合中大型企业，企业通常需要更快的交付周期和更灵活的开发流程，快速响应需求变更和市场竞争
8.3 h模型
H模型结合了瀑布模型和迭代模型的优势，强调需求稳定性和迭代开发，有助于提高软件质量和交付效率
优点
软件测试完全独立，贯穿整个生命周期，与其他流程并行
可以尽早介入测试，灵活度较高
提高了风险管理，版本迭代中可以进行风险评估和优先级的确定，可将主要目光放在高风险测试点
缺点
需求稳定性要求高：H模型要求在开发前期尽可能明确和稳定需求，对需求稳定性的要求较高
测试就绪准备的点难以掌控，需要精准评估
测试人员的技能要求较高，且需要良好的协作和沟通
适用范围
- 适合中大型企业，企业通常需要更快的交付周期和更灵活的开发流程，快速响应需求变更和市场竞争，但目前该类型企业用的比较少。
8.4 敏捷模型
敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。
故敏捷模型是为了快速迭代开发上线，而引出的一种测试开发模型。强调快速迭代、持续集成和自动化测试。
优点
快速响应变化，能够及时适应需求变化和项目调整，快速迭代开发和测试
提高整体的风险管理，可以及早发现和修复问题，减少项目风险和质量风险
提高软件质量，通过持续集成和自动化测试，减少人为错误
缺点
需求频繁变更，敏捷开发强调变化和灵活性，但这也意味着需求可能会频繁变更
需要更专业的测试技能，要求测试团队丰富的测试经验和技能，可以快速迭代中保证高效测试
加深自动化测试依赖，自动化测试使用和维护成本增加
适用范围
- 大多为互联网企业（不轮大小），快速迭代开发测试，快速响应需求变更和市场竞争，尽早上线。