软件测试基础理论知识

• 什么是软件测试

  通过自动化或手工的方式运行系统，看实际结果和预期结果之间是否一致。

• 软件测试的目的

  发现软件缺陷，评估软件质量，降低项目风险。

• 软件测试的工作流程

  需求分析：理解业务需求、识别测试范围。

  测试计划：制定测试策略、评估工作量与资源、确认测试结束的标准。

  测试设计：设计测试用例、准备测试数据、编写自动化脚本。

  测试执行：执行测试用例、测试结果的记录、bug的跟踪管理。

  测试评估：评估测试覆盖是否完全以及测试是否通过、编写测试报告。

• 敏捷测试模型

  • V模型

    一种线性、顺序的软件开发模型，将软件开发过程和测试过程分成几个阶段。强调测试与开发的对应关系。

    开发过程（左边）：需求分析-> 概要设计-> 详细设计-> 编码

    测试过程（右边）：系统测试<- 集成测试<- 单元测试
    优点 ：测试活动与开发活动严格对应；测试计划在早期制定，减少返工；每个阶段都有明确的验证标准。
    缺点：灵活性差，不适合频繁变更的项目；测试接入交完，缺陷发现修复成本高。

  • W模型

    V模型的改版，开发测试同步进行。测试在需求分析阶段就介入。

    开发过程：需求分析 -> 概要设计 -> 详细设计 -> 编码 -> 集成 ->实施

    测试过程:：系统测试设计 -> 集成测试设计 -> 单元测试设计 -> 单元测试 -> 集成测试 -> 系统测试
    优点：缺陷发现更早，修复成本更低；测试计划更全面；支持需求变更的快速响应。

  • XP模型（极限编程测试模型）

    测试在XP中被视为开发过程的核心，通过将测试贯穿整个开发周期，实现了高质量、可维护的软件交付。
    测试驱动开发 ，"先写测试后写代码"，开发人员在编写功能代码之前，先编写对应的单元测试用例，确保代码从一开始就满足需求。
    持续集成，代码频繁集成到主干，每次集成后自动运行所有测试，快速发现和修复问题。频繁回归。

  • 自动化金字塔

    微量的UI自动化，少量的接口测试自动化、大量的单元测试自动化

• 软件的分类

  按用功能分 系统软件、应用软件、中间件

  按工作模式分 单机软件、分布式软件

  按部署模式分 本地软件、Web软件、移动软件等

• 测试的分类

  • 按是否需要知晓内部代码逻辑分：白盒测试、黑测测试、灰盒测试
  • 按执行阶段分：冒烟测试、回归测试、探索性测试
  • 按质量特性分：
    功能测试（单元测试、集成测试、系统测试、验收测试）
    性能测试（负载测试、压力测试、稳定性/耐力测试）
    安全测试（SQL注入、XSS跨网站脚本攻击、CSRF跨域站脚本攻击）
    兼容性测试
    可用性测试

• 软件测试的对象（文档、程序和数据）

  文档：需求规格说明书、概要/详细设计文档

  程序：业务功能与流程

  数据：数据库中的数据保存是否正确

• 什么是测试用例

  一系列操作步骤和预期结果的集合，包括用例标题、前提条件、测试步骤、预期结果等内容。

• 怎么编写测试用例

  需求分析，根据需求确认输入、输出，根据用例设计方法设计用例

• 冒烟测试

  只测试最核心最关键的功能，不做细节或边缘情况测试。目的在于检查构建是否基本可用，避免在深入测试时发现严重问题而浪费时间。

  常被自动化，再持续集成流水线中作为门禁，失败时自动拒绝构建。

• monky测试

  一种随机、无特定规则的自动化测试。模拟用户胡乱操作，目的是发现程序在随机输入下的异常崩溃或错误。

• 测试工程师的职责

  通过一系列测试活动，尽早的找出软件的bug（包括功能、性能、安全等层面），确保功能、性能等符合需求。

• 自动化测试框架要素

  测试数据管理

  公共函数库

  测试报告生成

  日志记录

  持续集成

• 常见工具

  单元测试：JUnit、TestNG、pytest

  接口测试：Postman、JMeter、RestAssured

  UI测试：Selenium、Appium、Cypress

  性能测试：JMeter、LoadRunner

  测试管理：TestLink、Jire、禅道

• 黑盒测试常见的用例设计方法

  1. 等价类划分

     有效类：符合需求允许的输入

     无效类：不符合需求允许的输入

  2. 边界值分析

     基于等价类划分，在划分的等价类中的边界附近的值。

     上点：边界上的点；

     离点：边界外的点；

     内点：边界内的点。

  3. 场景法

     选择基本流（系统正常运行情况下、顺利操作的场景）

     选择备选流（各种分支、异常场景、错误情况等）

     比如调用外部接口报错、录入不符合条件的数据、系统本身运行异常报错等

  4. 判定表/决策表

     适用于有多个逻辑条件决定多个动作的场景。

     步骤：确定条件与动作，列出所有条件组合，根据业务逻辑填充动作，合并简化。

     例如：订单折扣规则。

     条件是：1）是否是会员、 2）订单金额是否大于100。

     动作：1）打9折、 2）免运费

     条件/动作	规则1	规则2	规则3	规则4
     是否会员	Y	Y	N	N
     金额是否大于100	Y	N	Y	N
     打9折	Y	Y	N	N
     免运费	Y	N	Y	N

  5. 因果图法

     通过图解分析输入条件组合关系，并基于判定表设计测试用例的软件测试方法。主要用于处理输入条件与输出结果之间的逻辑关系。其核心在于系统化覆盖多钟组合场景，确保测试用例的有效性和完整型。

     步骤：

     需求分析，确定原因和结果。因即为输入、果即为输出。

     分析输入之间的关系（互斥、包含、唯一、要求、屏蔽），明确输入之间的关系组合、组合数量即为用例数量。

     分析输出之间的关系（互斥、包含、唯一、要求、屏蔽）

     分析输入与输出的因果关系（恒等、非、或、与）

  因果法中的因、果分别对应判定表法中的条件、动作。
  6. 错误猜测法

  通过过往经验，推测出软件可能存在的缺陷，从而针对地设计测试用例。

  7. 正交排列法（解决了判定表用例太多的问题）

     输入条件较多，且每个输入的可能取值有多个时，全面组合的用例数量巨多。

• 白盒测试用例设计方法

  • 逻辑覆盖
    语句覆盖（使程序中的每条可执行语句至少被执行1次）。
    判定覆盖（使程序中的每个分支各成立一次），也被叫做分支覆盖。
    条件覆盖（使程序中的每个条件的可能取值至少满足一次）
    判定-条件覆盖（使程序中的每个分支真假各出现至少一次，且每个条件的真假各出现一次）
    条件组合覆盖 （使程序中每个判断的的所有条件的各种可能组合都至少出现一次）

• 一个具体的功能，可以怎样测试

  • 纯软件（包含前端界面、前后端交互、接口调用）

    从功能、接口、性能进行测试。

    功能层面，首先保证乐观的主流程正常。再考虑各个环境可能出现的特殊或者异常场景，比如输入的无效类、边界值等

    接口层面，看接口的参数有哪些，是否必录。搭配不同的入参，看接口返回是否符合预期。对每个参数输入无效类，是否有明确提示。对于查询接口，使用A用户的token，查询B用户的数据，是否能成功阻断。

    性能层面，对接口进行不同并发的压测，看响应时间、tps、应用和数据库服务器的资源占用是否是可接受的。

  • 软硬件交互

    从实际的使用场景进行考虑，

    先保证主流程正常，接下来考虑个各种可能出现的特殊或者异常场景。考虑用户使用体验。