《软件测试的艺术》读书总结

2018-03-08  本文已影响0人  Aym_fuhong

本文通过软件测试基础、测试用例设计、测试的种类、互联网应用测试、敏捷中的测试、调试六个方面进行总结。

一. 测试的基础

定义：测试是为发现错误而执行程序(文档测试就不是执行程序)的过程。
目标：通过有限的测试(用例)，最大限度的提高发现问题的数量，以取得最好的测试效果。

软件测试最普遍的两种手段

黑盒测试：数据驱动的测试或者输入/输出驱动的测试，’穷举输入’；
白盒测试：逻辑驱动的测试，检查程序的内部结构

软件测试10项原则

二. 测试用例的设计

包括白盒测试，黑盒测试，错误猜测，测试组合策略
  1. 白盒测试：语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，多重条件覆盖
If A and B then Action1
If C or D then Action2

语句覆盖：保证程序中的语句都执行一遍即可
A=true B=true C=true
判定覆盖：保证程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假均曾被满足
（1）A=true，B=true，C＝true，D=false（2）A=true，B=false，C＝false，D=false
条件覆盖：保证每个判断中的每个条件的可能取值至少满足一次
A=true/false B=true/false C=true/false D=true/false, so （1）A=true，B=true，C＝true，D=true（2）A=false，B=false，C＝false，D=false
判定/条件覆盖：保证判断中每个条件的可能结果至少执行一次，每个判断的所有可能结果至少执行一次
（1）A=true，B=true，C＝true，D=false（2）A=true，B=false，C＝false，D=false （3）A=false，B=true，C＝false，D=true
多重条件覆盖：将每个判定中的所有可能的条件结果的组合，以及所有入口点都至少执行一次
（1）A=true，B=true，C＝true，D=false（2）A=true，B=false，C＝false，D=false （3）A=false，B=true，C＝false，D=true（4）A=false，B=false，C＝true，D=true

  1. 黑盒测试：等价划分，边界值分析，因果图
    等价划分：1）确定等价类(‘有效’，‘无效’)；2）生成测试用例
    边界条件：输入和输出等价类中那些恰好处于边界，或者超过边界，或在边界值以下的状态

检查结果空间的边界很重要，因为输入范围的边界并不总能代表输出范围的边界情况（三角正弦函数sin)

因果图：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可
以通过因果图转换为判定表，从而设计相应的测试用例。

  1. 错误猜测：利用直觉和经验猜测出错的可能类型，然后编写测试用例来暴露这些错误
  2. 测试组合策略：多种测试用例设计组合而成的一个整体的策略(例如白盒和黑盒测试用例设计的组合测试)。

组合策略要求：

  1. 规格说明中包含条件组合的情况，应首先使用因果图分析方法
  2. 任何情况下都应使用边界值分析方法
  3. 应为输入和输出确定有效和无效等价类
  4. 使用错误猜测技术增加更多的测试用例

三. 测试的种类

从传统的开发模式，执行测试的顺序和粒度，分为单元测试，集成测试，功能测试，系统测试，验收测试，安装测试

开发过程与测试过程的对应关系：


测试与开发过程对应关系图.jpeg
1. 模块(单元)测试

单元测试：是对程序中的单个子程序，子函数或过程进行测试的过程。

目前大多数的单元测试其实都是黑盒测试，包括开发人员自己写的单元测试也是黑盒测试，只有像自动扫描这种对每行代码逻辑的测试才是真正使用的白盒测试 ，彻底的单元测试需要使用增量策略

2. 集成测试(增量测试)：

分为自顶向下的增量测试与自底向上的增量测试
测试单独的模块需要有个特殊的驱动模块和一个或多个桩模块。自顶向下测试更侧重于编写桩模块，自底向上测试更侧重于编写驱动模块
增量测试的优缺点：
1）非增量测试所需的工作量要多一些（需要更多的驱动模块和桩模块，而自顶而下的增量测试只需要桩模块，自底而上的增量测试只需要驱动模块）
2）增量测试可以尽早发现模块中与不匹配接口，不正确假设相关的编程错误，容易调试（由于可以尽早地对模块组合进行集成测试）
3）增量测试使用先前测试过的模块，取代了非增量测试中使用的桩模块或驱动模块，所以实际模块经受了更多的检验
4）模块测试阶段开始时，若使用非增量测试，就会有更多机会进行并行操作

3. 功能测试

功能测试通常是一项黑盒操作。用来发现程序与其外部规格说明之间存在不一致的过程。常用等价类划分，边界值分析，因果图分析和错误猜测方法。

4. 系统测试

系统测试的目的就是将系统或程序与其初始目标进行比较。含义：

系统测试分类：

分类 说明
能力测试 确保程序的目标功能实现(目标和用户文档进行比较)
性能测试 评估程序的响应时间及吞吐量瓶颈
强度测试 发现在大规模负载，高强度不间断持续的数据处理中的异常
容量测试 发现处理大容量数据时的程序异常
安全性测试 试图攻破程序的安全防线
兼容性测试 评估新版本能否兼容老的版本
可用性/用户体验测试 评估最终用户在使用软件与软件交互时的可用性问题
存储测试 确保程序可以正常处理其对存储的需求，包括系统的存储和物理上的存储
可靠性测试 评估程序能达到规格说明中运行时长和平均故障间隔时间要求
可恢复性测试 测试系统恢复相关的功能是否按照设计要求实现
可维护性/服务测试 评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需
配置测试 检查程序是否能在推荐配置上流畅运行
安装测试 确保能够在所有支持的平台上安装软件
文档测试 校验所有的用户文档是否准确
过程测试 对软件系统操作或维护所设计的流程进行评估和确定

三种测试的区别：

  • 模块测试的目的是发现程序模块与其接口规格说明之间的不一致
  • 功能测试的目的是为了证明程序未能符合其外部规格说明
  • 系统测试的目的是为了证明软件产品与其初始目标不一致

系统测试中的可用性(用户体验)测试
是一种黑盒测试。测试从功能缺陷到不符合人机工程学的设计失误。

准备真实、可重复的试验场景 -> 测试人员选取(优秀的测试员、用户) -> 数据采集(沟通、调查问卷等)

目标：

5. 验收测试

验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的过程。该测试通常是由程序的客户或最终用户来进行。

6. 安装测试

安装测试的目的不是为了发现软件中的错误，而是为了发现在安装过程中出现的错误。

四. 互联网应用测试

基于web的应用系统基本结构分为表现层，业务层，数据层

  1. 挑战
  1. 测试策略

表现层

业务层

数据层

五. 敏捷中的测试

敏捷：无固定的开发过程。三个特性：依赖客户参与、测试驱动、紧凑的开发周期
敏捷中的测试：通过持续的测试反馈推动项目前行，帮助开发这修复bug，改变需求设计以及其他一般性质量提升。敏捷测试依赖于自动化测试(及时反馈，更可靠)。
极限开发中的测试：单元测试和验收测试(自动或者非自动化)组成（在创建开发代码库之前创建）

六. 调试

执行测试用例成功捕获错误之后需要进行调试，找到错误根源。
调试种类

上一篇 下一篇

猜你喜欢

热点阅读