《探索式软件测试》- 读书笔记

     

• 1. 局部探索式测试法
• 2. 全局探索式测试法
• 3. 混合探索性测试

 

 

    软件缺陷主要程序员引入的缺陷，或因运行环境导致的缺陷缺陷预防。开发人员测试不足，没有理解、预见或测试所有可以运行软件的环境分类，软件处于静态状态和测试缺乏数据。从开发人员角度来说的，包括code review，static analysis tool 和 unit testing 。 缺陷检测一般测试人员一般使用两种动态设置，手工测试和自动化测试。手工测试可以发挥人的主观流动性，设计出真实的用户情况，真实的环境使用真实的数据，识别出显而易见的缺陷；但是手工测试的测试很慢，没有规律，不可反复使用，发现问题后也不能重现，也不能移植手工。自动化测试里，简单的一个程序可以执行无数次测试用例，其测试使用脚本会根可以根据功能改变脚本，记录着实际运行着哪些测试；但是需求花大量的时间编写代码。测试人员要找到隐藏很深的软件缺陷，这就要求测试人员再进行探索式测试，做到要理解应用程序如何工作，它的接口看起来怎样，它实现了哪些功能，强迫软件展示其全部能力，找到缺陷。

1. 局部探索式测试法

      局部探索式测试法有一个好处是测试人员不需要知道很多信息就可以完成这些任务。局部探索式测试法适用于在多个原子输入中选择合适的值，也可以用于确定如何对多个原子输入进行排列组合。根据软件的各种属性，将决策分为5部分：输入(input)、状态(state)、代码路径(codepath)、用户数据(user data)和执行环境(execution environment)。

     state：如何测试软件状态临时的，长期保存的

     codepath：代码路径

     execution environmen：执行环境

     input：各种输入之间会相互影响而造成软件失效，并且输入这些值时的先后顺序也会导致问题

• 合法输入和非法输入：正向测试(postive testing) / 逆向测试(negative testing)的概念
• 错误处理程序(error handler)：输入筛选器(input filter)，输入检查(input check)和使用异常(exception)
• 常规输入还是非常规输入
• 输入默认输入或用户提供的输入：在空白字段中不输入字符 / 给某个API传递一个 NULL参数把该默认值删除/留下一个空白的字段默认值附近的其他值
• 使用输出来指导输入选择:非法输出(illegal outupt)和合法输出(legal output)

     user data：

• 真实用户数据库中数据被不断地添加和修改
• 无法推测真实数据中可能会有什么样的关系和结构
• 数据量大时，在哪里可以放得下这些数据也是个问题
• 敏感数据，如用户隐私  

 

2. 全局探索式测试法

        全局探索式测试法是关于测试人员在全局方面所必须做出的各种决定，比如在考虑特性交互、数据流以及在应用程序的用户界面上如何选择不同路径来完成某些实际功能时。这里我们不再考察在单个输入面板上充当中间用途的原子输入，转而讨论那些可以帮助测试人员达到更重要目的的输入。

 

3. 混合探索性测试

      混合探索性测试，展示如何把探索式测试的思维方法与传统的基于场景的测试方法结合起来。它也打破了脚本测试法所固有的那种死板，提共了更多的灵活性。它让那些在测试脚本上已经倾注大量人力物力的团队也可以使用探索式测试法。

1. 通常有价值的场景会做下面一些事情：

• 讲述用户故事 - 通常是记录用户使用软件的动机、目的以及具体动作

• 描述需求

• 演示产品功能 - 这些场景出现在在线帮助或为用户准备的书面说明书中

• 演示集成场景 - 描述功能在集成后是如何工作的，用户在一些实际任务中如何使用这些集成后的功能

• 搭配设置和安装

• 描述警告和出错情形

2.使用基于场景的探索式测试

1) 通过场景操作引入变化

• 插入步骤：给场景插入一个或多个步骤能增加软件失败的机会。增加更多数据，使用附加输入（比如添加一条产品评论后，对其他评论进行评分），访问新的界面

• 删除步骤：可使用递进的方式重复场景，每次只删除一个步骤。每减少一个步骤，场景都在被测软件上执行一次，直到获得一个最短的测试用例，然后循环结束。

• 替换步骤：如果场景中某些步骤可以有多种方法完成，就可以用替换步骤的场景操作来修改这个场景。

• 重复步骤

• 替换数据：这里的思路是理解应用程序连接和使用的数据源，并确保它们之间的交互是稳定可靠的

• 替换环境：如替换硬件，替换容器（如不同浏览器），替换版本，修改本地设置（应用程序是否使用Cookie或者在用户机器 上写文件吗，使用本地注册表吗，如果用户修改浏览器设置来限制这类活动会怎样？如果用户直接改变应用程序的注册表设置会怎样？）

2) 通过漫游测试引入变化

      极限测试法

• 如果场景要求软件打开文件，给它最复杂的文件会什么样?
• 如果软件要求数据输入，什么样的数据会让它运行起来最费力?
• 很长的字符串输入会产生问题吗?
• 打破输入格式规则怎么样(例如，Ctrl字符，Esc序列以及特殊字符)?

      破坏测试法

• 如果场景要求在网络上传输数据，那么可以在执行该步骤之前
• 执行之中拔掉网线(或者通过操作系统来断开网络连接，关闭无线连接，等等)
• 用文档记录下沂有这些破坏点，并尽量多地、有意识地、谨慎地执行它们

       收藏家测试法

• 测试部门可以把它做为游戏，让测试人员比赛看谁能产生最多的输出，最后给赢家颁奖。
• 能否创建一个可以产生最多输出数量的超级场景?
• 测试人员是否能创建出(或派生出)新的场景，并让它具有其他场景中所没有的输出?

        配角测试法 (邻居测试法)

• 如果场景指定使用斜体字，就偏偏用黑体字，
• 如果它希望你强调某些文本，就偏偏强调另一些文本。