软件测试回顾(1)

目录

软件测试回顾(1)

说明:好久都没有回顾测试理论和方法了，今天有把《软件测试52讲》拿出来看了看，感觉每次都读一遍太浪费时间，遂自行记录下每章节的重点，以便后续可以快速翻阅。

所有信息均来自《软件测试52讲》，只是每讲会抽取重点进行记录。如果侵权，请联系我删除。

重点优先级：

  1. 加颜色
  2. 黑体
  3. 普通文本

斜体：代表本人的一些看法。

00章：测试工程师的生存之道

能力：

  • 从业务出发的手工测试+完全掌握自动化测试的开发技术来设计自动化用例。
  • 必须掌握开发测试基架构的关键技术。
    • 高并发测试架构来应对互联网产品的“快速更迭”
  • 测试数据的准备-工具化、服务化、平台化。
    • 测试数据的准备影响的是自动化和手工

测试三步走：

  1. 成为互联网时代“合格”的测试工程师
    1. 需要有比开发人员更全面的计算机基础知识
    2. 需要了解互联网的基础架构、安全攻击、软件性能、用户体验和常见缺陷等知识
    3. 需要能够使用常见的测试框架或者工具
    4. 需要具有一定的自动化测试脚本的开发能力
  2. 成为互联网时代“优秀”的测试工程师
    1. 合格的测试工程师关注的是纯粹的测试，优秀的测试工程师关注更多的是软件整体的质量
    2. 需要根据业务风险以及影响来制定测试策略。
    3. 有效控制测试的时间和成本，并且能够对测试框架以及工具做出适合项目需求的选型
    4. 还非常清楚这些测试工具背后的实现原理，以及多个同类测试工具各自的优缺点和适用场景。
    5. 在遇到问题时，你还需要能够通过二次开发解决工具和框架层面的问题，对于没有合适可用工具的场景，可以自行设计开发一些小工具来更好地展开测试工作。
  3. 成为互联网时代的测试架构师
    1. 站在更高的角度
      1. 面对大量测试用例的执行，无论是GUI还是API，都需要一套高效的能够支持高并发的测试执行基础架构；
      2. 面对测试过程中的大量差异性数据要求，需要统一的测试数据准备平台；
      3. 为了可以更方便地和持续集成与发布系统（CI/CD）以解耦的形式做集成，需要统一发起测试执行的接口。
    2. 对一些前沿的测试方法和技术有自己的理解.
      1. 能够在恰当的时候、因地制宜地把它们应用到实际项目中。

01、02章：测试用例的分析和设计

作为测试工程师，你的目标是要保证系统在各种应用场景下的功能是符合设计要求的，所以你需要考虑的测试用例就需要更多、更全面。

在绝大多数的软件工程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。

一个优秀的测试工程师必须具有很宽广的知识面，如果你不能对被测系统的设计有深入的理解、不明白安全攻击的基本原理、没有掌握性能测试的基本设计方法，很难设计出“有的放矢”的测试用例。

1.待测系统的分析

一个质量过硬的软件系统，需要显式功能性需求+非功能性需求

显式功能性需求

显式功能性需求（Functional requirement）的含义从字面上就可以很好地理解，指的是软件本身需要实现的具体功能，也就是指需求文档上面的功能需求。

这个不多说

非功能性需求

  1. 安全性
    1. 密码加密
    2. 典型的sql注入攻击，查看返回页面
    3. xss跨站脚本攻击，行为篡改
  2. 性能
    1. 高并发用户登录
    2. 高并发场景服务端监控指标
    3. 高并发下子资源分配
    4. 大量用户连续登录退出，服务端内存泄露？
  3. 兼容性
    1. 不同浏览器
    2. 不同版本...

2.测试用例评价指标

要想说明一个测试是否为好测试用来，就要先设定评价标准

好的测试用例评价指标

  1. 整体完备性：是有效测试用例组成的集合，能够完全覆盖测试需求。
    1. 注意，这里是覆盖 测试需求，而不是无穷尽的测试
  2. 等价划分的准确性：只要其中一个输入测试通过，其他输入也一定测试通过。
  3. 等价类集合的完备性：保证所有可能的边界值和边界条件都已经正确识别

3.设计用例的方法

  • 等价类划分

    • 最重要的是找出所有“无效等价类”

  • 边界值分析方法

    • 边界值其实是对等价类划分的补充。
    • 大量的错误发生在输入输出的边界值上
    • 通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据

  • 错误推测方法(探索式测试方法)

    • 系统设计理解
    • 经验(从个人工作来看，这个占比比较多)
    • 个人直觉
    • 玄学

4.怎么进行用例的设计？

用例设计的流程

在用例设计时，要搞清楚业务对应的多个软件功能的需求点，分析出多个测试点，最后形成测试用例。

此处建议使用xmind工具来进行分析。

在非互联网软件企业的实践中，通常会使用需求追踪管理工具（比如ALM、DOORS、JIRA、TestLink等）来管理，并以此来衡量测试用例对业务需求、软件功能需求的覆盖率。

用例设计的关键点：

  1. 从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
  2. 对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例

用例设计的其他经验

  1. 只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
  2. 必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑
    1. 切忌不要以开发代码的实现为依据设计测试用例。因为开发代码实现的错误会导致测试用例也出错，所以你应该根据原始需求设计测试用例。
    2. 说实话，这个实现还是比较难的，现实中开发不会有耐心和测试详细的说明处理流程和分支处理，只会“敷衍”了事，反正出问题找责任也是测试，开发不用承担责任，对开发来讲，这既是负担，又没有好处，还耽误本职工作，最终开发测试墙就形成了
  3. 需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。

03章：单元测试

1.什么是单元测试？

对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。

单元测试的具体表现形式就是对函数以各种不同输入参数组合进行调用，这些调用方法构成了函数的使用说明。

其他说明

  1. 单元测试一般由开发工程师完成，伴随开发代码一起递交至代码库。

  2. 单元测试都是以自动化的方式执行，所以在大量回归测试的场景下更能带来高收益。

2.怎么做好单元测试？

  1. 找到产生错误的原因(必须做到分类正确并且完备无遗漏，同时每个分类的处理逻辑必须正确)
    1. 哪几种正常的输入
    2. 特殊处理的多种边界输入
    3. 非法输入的可能性以及如何处理
  2. 单元测试用例(单元测试的用例是一个“输入数据”和“预计输出”的集合)
    1. 哪些是输入数据？
      1. 被测试函数的输入参数
      2. 被测试函数内部需要读取的全局静态变量
      3. 被测试函数内部需要读取的成员变量
      4. 函数内部调用子函数获得的数据
      5. 函数内部调用子函数改写的数据.....
    2. 对应的输出数据
      1. 被测试函数的返回值
      2. 被测试函数所改写的成员变量
      3. 被测试函数所改写的全局变量
      4. 被测试函数中进行的数据库更新
      5. 被测试函数中进行的文件更新....
  3. 驱动代码、打桩、Mock
    1. 驱动代码是用来调用被测函数的
    2. 桩代码和Mock代码是用来代替被测函数调用的真实代码的

3.实际中怎么展开单元测试？

  1. 测试范围：并不是所有的代码都要进行单元测试，通常只有底层模块或者核心模块的测试中才会采用单元测试
  2. 测试架构选型：ava最常用的单元测试框架是Junit和TestNG；C/C++最常用的单元测试框架是CppTest和Parasoft C/C++test。
  3. 计算代码覆盖率：Java的JaCoCo，JavaScript的Istanbul下为代码覆盖率统计工具
  4. 把单元测试执行、代码覆盖率统计和持续集成流水线做集成，以确保每次代码递交，都会自动触发单元测试。

单测的公司不多，甚至没有单元测试，我只见过提供api包的产品进行了单元测试

posted @ 2020-12-28 13:49  火颜  阅读(201)  评论(0)    收藏  举报