软件测试——理论篇

测试流程体系

软件测试基本概念

  1. 软件测试:通过手工或者工具对“被测对象”进行测试,验证实验结果与预期结果是否存在差异。
  2. 软件测试的作用:通过测试可以发现并修复软件当中存在的缺陷,从而提高用户对产品的使用信心。测试可以降低同类型产品开发遇到问题的风险。
  3. 软件缺陷:即bug,软件缺陷会导致软件不能正常运行,它的存在会一定程度上导致软件不能满足用户的需求,甚至有可能破坏或泄露用户的重要数据。
  4. 软件测试原则
    • 测试显示缺陷的存在
    • 穷尽测试是不可能的
    • 测试尽早介入
    • 缺陷集群性(2/8)原则
    • 杀虫剂悖论
    • 测试活动依赖于测试内容
    • 没有错误是好是谬论
  5. 软件测试对象
    • 需求分析阶段:需求文档,接口文档。
    • 编码实现阶段:源代码
    • 系统功能使用:软件程序
  6. 测试用例:为特定目的而设定的一组测试输入、执行步骤和预期的结果,以便测试产品是否满足某个特定需求的文档。

软件测试模型

V模型:

V模型

  • 需求分析:需求文档
  • 概要分析:系统架构、模块划分、模块与模块之间的接口
  • 详细设计:模块内部实现的逻辑和方法
  • 编码:用代码实现设计的内容
  • 单元测试:测试代码中最小模块是否符合详细设计
  • 集成测试:测试各个模块组成到一起后是否可以正常使用
  • 系统测试:测试已经集成在一起的产品是否符合需求文档中的要求
  • 验收测试:测试产品是否符合用户的需求
  1. V模型是瀑布模型的一种改进。
  2. V模型标明了测试过程中的不同阶段。
  3. V模型的优点:
    1. 既有底层测试又有高层开发。
    2. 将开发阶段清楚的表现出来,便于控制开发的过程。
  4. V模型的缺点:
    1. 容易让人误解为测试是在开发完成之后的一个阶段。
    2. 由于它的顺序性,当编码完成之后,正式进入测试时,这时发现的一些bug可能不容易找到其根源,并且代码修改起来也很困难。
    3. 如果需求变更较大,导致要重复变更需求、设计、编码、测试。返工量大。

W模型:

W模型

  1. W模型明确表示出了测试与开发的并行关系。
  2. W模型中测试伴随着整个软件开发周期,并且测试的对象不仅仅是程序,需求和设计同样要测试。
  3. W模型的优点:
    1. 将测试贯穿到整个软件的生命周期中,且除了代码要测试,需求、设计等都要测试。
    2. 更早的介入到软件开发中,能尽早的发现缺陷进行修复。
    3. 测试与开发独立起来,并与开发并行。
  4. W模型的缺点:
    1. 无法支持迭代的开发模型。
    2. 对有些项目,开发过程中根本没有文档产生,故W模型无法使用。
    3. 对于需求和设计的测试技术要求很高,实践起来很困难。

H模型:

H模型

  1. 软件开发中需求、设计、编码等活动被分阶段执行、但是实践中,他们并不是完全串行的,它们之间更多时候是交叉进行的,更多的是迭代执行。
  2. 把测试活动完全独立出来,形成一个完全独立的流程,将测试准备活动和测试执行活动清晰的体现出来。
  3. H模型的优点:
    1. 软件测试完全独立,贯穿整个生命周期,且与其他流程并发进行。
    2. 软件测试活动可以尽早准备、尽早执行,具有很强的灵活性。
  4. H模型的缺点:
    1. 测试就绪点分析困难。
    2. 对于整个项目组的人员要求非常高。

软件测试工作流程

传统测试流程

单元测试
集成测试
冒烟测试
系统测试
回归测试
验收测试

系统测试

需求分析
测试计划
测试设计
用例评审
测试执行
bug管理
发布维护

Bug管理流程

后续版本处理
通过
未通过
缺陷提交
指派缺陷
确认缺陷
推迟处理
遗留缺陷
处理缺陷
回归缺陷
关闭缺陷
重新打开

缺陷提交:说明Bug来源、环境、结果、类型、Bug如何复现、截图、录屏、日志等相关信息。

测试左移和测试右移

测试左移

  1. 左移是往测试之前的开发阶段转移
  2. 测试团队在软件开发周期早期就开始介入
  3. 对代码进行测试
  4. 从发现bug到预防bug

测试左移——质量保障手段

  • 代码评审(code review)
  • 代码审计
  • 单元测试
  • 自动化冒烟测试
  • 研发自测

测试右移

  1. 右移是往发布之后移。
  2. 产品上线后进行线上监控。

测试右移——线上监控

  • 闭环的线上问题反馈-检查-解决-更新流程。
  • 更便捷的日志查看、回传服务。
  • 丰富有效的log,便于问题的快速定位。
  • 丰富的监控指标(例如业务异常点指标)。
  • 业务监控(例如短信发送等)。
  • 关键指标每日监控(服务器指标)。
  • 生产数据监控(警报)。

测试技术体系

软件测试分类

软件测试分类
黑盒测试

  • 又称数据驱动测试
  • 完全不考虑程序内部结构和内部特性
  • 注重于测试软件的功能需求
  • 只关心软件的输入数据和输出数据

白盒测试

  • 研究产品内部的源代码和程序结构
  • 单元测试就是白盒测试的一种

灰盒测试

  • 对白盒测试和黑盒测试的结合

自动化分层测试体系

自动化分层测试体系
单元测试方法

  1. java
    • JUnit
    • TestNG
  2. Python
    • unittest
    • pytest

接口测试

  • 一般称作API。
  • 是针对软件对外提供服务的接口的输入输出进行测试。
  • 检查接口参数传递的正确性,接口功能实现的正确性,输出结果的正确性性,以及对各种异常情况的容错处理的完整性和合理性。

接口测试方法

  • Charles、Fiddler
  • postman
  • Jmeter
  • loadRunner
  • python:Requests、HttpRunner
  • Java:HttpClient、RestAssured

UI测试方法

  • 手工方法:人工查看、操作
  • 自动化方法
    • web:selenium
    • app:appium

常用测试平台

测试用例管理和bug管理平台

  • jira:推荐方案,定制性很强
  • redmine:推荐方案,开源,活跃,定制性很强
  • testlink:流行的测试用例管理平台,体验不太好
  • 其他:tapd,云效,禅道,gitlab,在线协作文档
  • 无协作模式:excel,思维导图

代码管理平台

  • gitlab:可本地部署的git代码管理平台,行业标准
  • subversion:svn管理,已经过时
  • github:开源项目运作
  • bitbucket:与jira同属同一家公司altassian

持续集成与持续交付管理平台

  • jenkins:持续集成与持续交付的主流平台
  • gitlab runner:gitlab的持续交付方案
  • github action:github的开源方案
  • 自建devops平台:企业定制平台,tapd,云效等

使用jenkins完成 CI/CD

  • 研发
    1. 构建、单元测试+覆盖率分析
    2. 自动化代码审计
  • 运维:自动化部署
  • 测试:
    1. 接口测试
    2. UI自动化测试
    3. 专项性能测试
    4. 性能测试、安全测试

黑盒测试方法论

常用测试方法

  • 等价类划分
  • 边界值分析
  • 因果图
  • 判定表
  • 决策树
  • 探索式测试

白盒测试方法论

白盒测试的度量

  • 根据待测产品的内部实现细节来设计测试用例
  • 白盒测试的执行手段是可以涵盖单元测试、集成测试等
  • 使用代码覆盖率来作为白盒测试的主要度量指标

代码覆盖率常见概念

  • 语句覆盖:每行代码都要覆盖至少一次
  • 判定覆盖:判定表达式的真假至少覆盖一次
  • 判定/条件覆盖:判定覆盖与条件覆盖都必须覆盖
  • 条件组合覆盖:判定表达式中的所有条件组合都需要覆盖
  • 分支覆盖:控制流中的每条边都要被覆盖一次
  • 路径覆盖:所有的路径都要尽量覆盖
  • 指令覆盖:一行代码会被编译为多条指令,尽可能地覆盖所有指令
  • 方法覆盖:每个方法至少要被覆盖一次
  • 类覆盖:每个类至少被覆盖一次

覆盖率统计工具

  • emma
  • cobertura
  • jacoco

流程覆盖

  • 利用代码执行流代表流程
  • 流程覆盖用路径覆盖率表达
  • 对流程进行裁剪获得一个适合业务的小规模的业务子集
  • 流程覆盖率=测试经过的路径/业务子集路径

精准化测试

  • 代码调用链与黑盒测试用例的关联
  • 根据代码变更自动分析影响范围
  • 黑盒测试过程中借助代码流程覆盖数据知道探索式测试
  • 利用线上数据推导有效测试用例
  • 代码流程分析与覆盖率统计

测试经典书籍

  • 《全程软件测试》
  • 《探索式测试》
  • 《探索式软件测试》
  • 《google测试之道》
  • 《持续交付1.0》
  • 《持续交付2.0》
  • 《不测的秘密》
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页