1634 words
8 minutes
测试
2025-09-05

优势#

  • 技术能力
    • python:pytest、selenium等工具
    • java:junit5、jmeter
  • 实习经验
    • 背景:团队精简,测试开发人员比较少,后台开发也负责部分测试工作
    • 通过两方面来保证代码质量
      • 单测用例的编写(目的:提高代码增量覆盖率),主要有以下两种方式
        • 自行编写单测代码,通过mock技术(减小对数据库等外部环境的依赖,伪造一个外部环境)提高代码覆盖率
        • 对于单测代码难以覆盖到的场景,向部署的容器中发送请求,通过实际请求发送的方式提高代码覆盖率
      • 流量回放(参与设计,目前已经初步集成到我们内部的dev工具流平台上)
        • 数据源:日志平台数据获取历史真实线上请求参数
        • 流量回放过程:模拟请求,比较测试成功率与历史成功率(回归测试)
          • 原本正确变成错误
          • 原本错误变成正确

测试开发工作理解#

  • 目标层面 交付给用户产品的可靠性、稳定性,是产品质量的重要防线
  • 思维层面 既要有用户业务的视角,又要有开发的思维。
    • “测试左移”:意味着测试工作应该尽早介入,从需求分析和评审阶段就开始。通过评审需求文档、设计文档,我们可以在编码前就发现逻辑漏洞和模糊不清的地方,大大降低修复成本。
    • “测试右移”:意味着产品上线后,测试工作并没有结束。我们需要关注线上的监控、用户反馈、日志分析等,从中发现潜在问题,并为后续的迭代提供数据支持。
  • 角色层面
    • 团队:并不是开发的对立面。我们的工作是提供高质量的反馈,帮助开发人员定位问题、修复问题,共同提升产品质量。
    • 自身:效率提升。开发测试工具以及自动化测试框架来提高整个团队的研发效率

测试全流程#

  • 需求分析 明确业务场景、识别需求中模糊、有歧义或可能存在逻辑冲突
  • 测试计划 明确测试框架、重点测试部分
  • 测试设计与用例编写
    • 方法:等价类法、边界值、场景法
      • 等价类法:有效等价类、无效等价类
      • 边界值:上点(边界上的点)、离点(边界内/外边缘)、内点(边界内任意的点)
      • 场景发:模拟用户、流程驱动
    • 用例组成:用例编号、模块、前置条件、操作步骤、预期结果
    • 进行用例的评估与审核:可行性与覆盖率
  • 测试环境准备 稳定性与独立性、确保接近真实的生产环境
  • 测试执行
  • 测试报告、缺陷管理、后续跟进

测试的角度#

  • 功能(正常场景、异常场景)
  • 性能(压力测试、QPS、时延等)
  • 安全(订单重复提交、XSS攻击)
  • 兼容(平台、特别是针对一些前端UI)

测试vs测开#

  • 测试:更偏向于“业务”和“用户视角”
  • 测开:“业务”和“用户视角” + “工程效率”和“技术实现”(开发测试工具、搭建自动化测试框架,使测试效率、可靠性更高)

黑盒与白盒#

黑盒测试,又称为功能测试行为测试。在这种测试方法中,测试人员将待测软件系统看作一个完全不透明的“黑盒子”。测试人员完全不关心盒子内部的程序结构、代码实现以及数据是如何存储和流转的。

  • 优点
    • 视角客观:用户角度
    • 独立性强:用例设计不依赖于代码具体实现,更加关注功能性
    • 使用范围广
    • 门槛低
  • 缺点
    • 覆盖率不明确
    • 错误定位困难
    • 依赖于需求文档

白盒测试#

又称为结构测试透明盒测试代码驱动测试。与黑盒测试相反,测试人员将待测软件看作一个透明的“白盒子”。测试人员必须清楚地了解程序的内部结构、代码逻辑和执行路径。

  • 优点
    • 代码覆盖率高
    • 错误定位迅速
    • 有助于代码优化
  • 缺点
    • 成本高
    • 独立性弱:依赖于代码,代码重写也需要进行测试用例的重写

黑白测试应用场景#

白盒测试:关注代码本身

  • 单元测试
  • 代码覆盖率分析
  • 安全审计与漏洞扫描(代码静态分析,跨站脚本xss攻击、sql注入等) 黑盒测试:关注功能性、业务逻辑
  • 系统集成测试
  • 用户验收测试UAT
  • 回归测试(新加功能没有影响到原本逻辑)

白盒测试中代码覆盖率#

  • 语句覆盖 每一行可执行语句都得到执行
  • 判定覆盖/分支覆盖 每一个判断语句if、while等为真/假都至少执行一次
  • 条件覆盖 确保每个判断语句中,每个独立的布尔子条件的“真”和“假”都至少被执行一次
  • 路径覆盖 确保程序中所有可能的执行路径都至少被执行一次。这是最强的覆盖标准,但在复杂程序中几乎不可能完全做到

条件覆盖不一定满足路径覆盖(下面是这个例子);路径覆盖也不一定满足条件覆盖

public void process(int a, int b) {
    // 判断 1
    if (a > 0) {
        System.out.println("A > 0"); // 语句 1
    }

    // 判断 2
    if (b > 0) {
        System.out.println("B > 0"); // 语句 2
    }

    System.out.println("End"); // 语句 3
}
  • 所有可能执行路径
    • 路径 1: a > 0 为真, b > 0 为真。 (执行 语句1 -> 语句2 -> 语句3)

    • 路径 2: a > 0 为真, b > 0 为假。 (执行 语句1 -> 语句3)

    • 路径 3: a > 0 为假, b > 0 为真。 (执行 语句2 -> 语句3)

    • 路径 4: a > 0 为假, b > 0 为假。 (只执行 语句3)

  • 一个条件覆盖
    • 测试用例 1: a = 1, b = 1 这条用例执行了路径 1。
    • 测试用例 2: a = -1, b = -1 这条用例执行了路径 4。 满足条件覆盖,但是没有满足路径覆盖