《探索式软件测试》章节试读

《探索式软件测试》的笔记-第1页

探索式软件测试书摘（James A.Whittaker）
http://blogs.msdn.com/b/james_whittaker/archive/2008/12/09/google-v-microsoft-and-the-dev-test-ratio-debate.aspx
探索式测试（exploratory testing）是一种自由的软件测试风格，强调测试人员同时开展测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。
软件测试风格rather than 具体的软件测试技术
探索式测试的分类：
自由式的ET
基于场景的ET
基于策略的ET
基于反馈的ET
软件缺陷的根源：程序员引入的根源和运行环境导致的缺陷
软件测试的决策有5部分：输入，状态，代码路径，用户数据，执行环境
输入：什么是输入？合法与非法输入？开发人员定义错误处理程序的三种方式（输入过滤器、输入检查、使用异常）
状态：什么是软件状态？用户的输入（不同的输入，不同的输入顺序）导致软件状态的改变，一定要注意观察状态的改变。
漫游测试（与场景测试相对）
我们将软件特性分成了：商业区、历史区、旅游区、娱乐区、旅馆区、破旧区
商业区：用户所要使用的软件特性和功能。
历史区：历史的版本遗留的代码
旅游区：有些特性和功能对新用户非常有吸引力，然而老用户不经常使用的部分
测试方法：
出租车测试法（出租车禁区测试法）联系打的理论，坐公交理论，类似旅行计划的制定
取消测试法
破坏测试法
遍历测试法
超模测试法？针对用户界面的优秀漫游测试法
极限测试法
深巷测试法
漫游与测试中的棘手问题
漫无目的
重复性
暂时性
单调性
健忘性
手工测试主要有两种类型：
1.基于脚本的手工测试
2.探索式测试特别适合于敏捷开发（agile development）
Problem：
1.哪种类型的代码比较适合使用自动化测试，哪种类型的代码比较适合手工测试？从理论的角度解释问题
2.在自动化测试中，哪种类型的软件缺陷比较容易被发现？又哪种类型的缺陷不容易被发现，for example.
3.ET的缺点？优点？如何进行ET工作？
4.你自己的测试方法和哲学是什么？脑力风暴
5.测什么？如何测？测试的分类？测试的策略选择？
6.测试人员如何记录应用程序的哪些部分已经被测过？列举至少四条标准作为测试人员衡量测试完整性的基础。
7.测试的最终目标是找到软件的缺陷，但同时也应该让测试更高效，测试周期更短。
8.我想知道你们公司是如何评估测试人员的？
9.虚拟化技术的软件测试中的应用？
10.如何阻止优秀的测试人员转而投向开发工作？
软件测试的真正价值并不是体现在代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限、思路中的狭隘以及技能方面的不足。
手工测试人员善于成为问题领域的专家，善于分析业务逻辑错误。自动化测试擅长低级别的细节。自动化测试可以检测到崩溃、挂起、不正确的返回值、错误代码、突发异常、内存使用情况等。选择什么样的测试取决于希望找到什么样的软件缺陷。大部分时间里，
手工测试在寻找业务逻辑错误上优于自动化测试；而自动化测试在寻找基础结构性软件缺陷上胜过手工测试。
什么时候能让软件测试就像玩电子游戏一样，充满乐趣呢！
===================================================================
1. 简要说明什么是ET

就是在完全不熟悉项目业务需求的基础上，采用边
学产品知识，边测试，通过一些手段来操作产品，使其暴漏出一些隐含的问题。其测试执行思路与测试设计思路是同时进行的。一个很明显的Freestyle ET方式。

2. ET 测试的范围

由于大部分项目存在一些共性，ET 测试的范围一般是主要的功能的实现，再加上主要的功能中隐含的一些潜在的风险，例如超长输入引出的系统错误等。具体可参见ET实践流程。
3. 为何要做ET

至于做 ET实践的原因多方面：
---------目前项目测试人员的功能测试手段太单一
---------目前第3轮测试发现的bug率以及投资回报率很低 淘宝网-探索式测试白皮书
---------为了质疑目前测试部三轮测试的流程规范
---------国外已经有了比较成熟的ET理论和实践经验
---------创新并实践前段时间ET的理论学习
4. 什么时候开始做ET

根据 ET 测试的方式和目的以及时间安排，可看出 ET 并不是为了发现主要功能的流程问题。所以特别需要在相对稳定的系统上做 ET，这里有两个好处：一是由于 ET 测试人员没有项目测试人员对需求了解深入，对于主要功能的流程问题没有项目测试人员发现那么及时以及深入。二是在稳定的系统上做ET，有益于发现项目测试人员的盲点，以及发挥测试的极限测试手段，同时也有益于ET测试产出的效果。所以在 XX1 项目 ET 实践过程中，是在第二轮测试的最后一天开始 ET。一般是在安全测试通过后。因为安全测试的 bug 修复后会引发比较多的页面 bug，此在一定程度上会影响 ET发现较严重的bug数量。
5. 怎样做 ET
ET 过程中使用到的一个非常清晰的任务列表，指出了要测试什么，怎么测试（强调策略，不是详细测试步骤），要寻找什么样的bug，有哪些风险，要去检查什么文档等。

根据国外 ET 实践理念，采用 Session 来进行测试范围的确定(具体请看 ET 的管理)，下面是简单
的一些说明：
第一步: 大概花1-2 个小时时间看PRD和原型(了解目的和产品背景)。
第二步: 大概花1-2 个小时时间确定下有哪些主要的功能模块和贡献性的功能模块。
第三步： 与项目组测试人员沟通哪个功能模块发现bug最多，哪个功能模块发现bug最少，哪个模块存在风险比较大。
第四步：根据前几步情况和参加ET的时间段来确定有多少个Session，并指出每个Session大概花多长时间。一般是1.5-2 个小时。就淘宝而言，一个 Session大概是2-3个 UC 的情况。
第五步：制定ET 测试计划，包含所有Session的名称和测试时间以及缓冲情况。
第六步：根据 ET 测试计划，边学习产品需求，边测试。发现问题立马记录问题描述。最后发送 ET测试报告。
第七步：与项目组测试人员沟通ET的效果以及该产品存在的风险，从用户易用性角度给该产品总体评价，同时跟踪确认bug的fix情况。
6. 做 ET时注意什么

ET
测试人员需要以最少的时间去了解这个产品的某个需求，而不是不要花很长时间去了解某个复杂业务的具体实现过程。

关注细节的部分，多使用一些极限测试的手段，比如超长字符，非法字符，异步编辑等。被某个细节block时，及时与开发人员沟通。 发现一个疑似问题，立马记录其问题描述。全神贯注的进行边学习产品，边测试。
7. ET 产出了什么
8. ET 发现了什么样的bug
对于 ET 测试发现的bug类型做一些个人分析，相信很多人对于这个比较感兴趣：
第一：一般情况下，ET测试的目的不是为了发现正常流程下的主要功能bug，特别是 Freestyle ET 方式，其实践的时间点在第二轮测试结束后 淘宝网-探索式测试白皮书
第二：ET 测试过程中，会变化测试手段去测试，更多的是用户测试和极限测试和交叉测试，也就会发现很多这些手段产生的bug
第三：ET测试过程中，使用的一些测试手段决定了发现的bug类型，常用的测试手段有：边界值测试，极限测试，用户测试，菜单浏览，域测试，组合测试。
第四：ET测试过程中，需要在学习业务的同时，不断的变化上述的测试手段去测试(关键点)。
第五：从产出上来看，使用了极少时间去进行 ET 测试产生的 bug 率是比较高的(平均每个小时产生3.5个 bug)。对于项目组测试人员来说，其单位时间内产生的bug率应该是比较低的。因为其投入包括熟悉需求；测试设计，3 轮测试执行等。具体官方数据个人不是很清楚。可参照 XX1 项目某测试人员的数据：投入时间267 个小时，发现124 个 bug；则平均每个小时产生0.47 个 bug。(注意：该数据不是直接判断标准，只做参考)

《探索式软件测试》的笔记-第74页

我们测的路径越多越好。
讲述用户故事
描述需求
演示产品功能
演示集成场景
描述设置和安装
描述警告和出错情形

《探索式软件测试》的笔记-第24页

测试用例划分优先级，优先保证基本功能可用。工作也是一样，每天计划好8小时的时间，划分优先级，每天充电

《探索式软件测试》的笔记-第28页

正常输入和异常输入，很多人忘记关注逆向测试，很多开发不喜欢写错误处理，想办法让系统崩溃也是很重要的测试

《探索式软件测试》的笔记-第28页

所有的软件，它们可能运行于完全不太的环境中，但是它们都会执行四个基本任务，即接受输入、产生输出、存储数据和进行运算

《探索式软件测试》的笔记-第50页 - 第4章 全局探索式测试法

各个区域：商业区，历史区，旅游区，娱乐区，旅馆区，破旧区
商业区测试类型：
指南测试法 要求测试人员通过阅读用户手册并严格遵照手册的建议执行操作。
卖点测试法 找到那些最能卖钱的特性进行测试
地标测试法 先选择地标，然后在软件中执行类似于在森林中地标间跳跃的动作
极限测试法 向软件提出很多难以回答的问题。如何使软件发挥到最大程度？哪个特性会使软件运行到其设计极限？哪些输入和数据会耗费软件最多的运算能力？哪些输入可能欺骗它的错误检测例程？如果软件用于产生某些特定输出时，使用哪些输入和内部数据可以不断挑战软件的这种能力？
快递测试法 专注于数据，确认哪些被存储起来的输入数据并“跟随”它们走遍软件
深夜测试法
遍历测试法
历史区测试类型：
恶邻测试法 发现和报告越来越多的缺陷后，就可以把缺陷数目同产品特性联系起来，从而可以跟踪究竟在哪些地方会出现产品缺陷。
博物馆测试法 老代码
上一版测试法
娱乐区测试类型：
配角测试法 专注于某些特定的特性，虽然不是用户使用的主要特性，却容易被忽视。
深巷测试法 最不可能被用到的或是那些最不吸引用户的特性
通宵测试法
旅游区测试类型：
收藏家测试法 收集软件的输出
长路径测试法 在到达目的地之前尽量多地在应用程序中穿行，选择长路径而不是短的，把那个埋在应用程序最深处的界面作为测试目标
超模测试法 重点在于测试界面
测一送一测试法 运行多个拷贝
苏格兰酒吧测试法 特别适用于大规模的复杂应用程序，在这些应用程序中的有些地方，测试人员需要事先知道如何去找到它们
旅馆区测试类型：
取消测试法
懒汉测试法 尽量少的做实际工作，接受所有默认值
破旧区测试类型：
破坏者： 利用各种机会破坏
反叛测试法 逆向测试法 输入最不可能的数据
歹徒测试法 输入一些不应该出现的数据
错序测试法 以错误的顺序做事情
强迫症测试法 重复反复做

《探索式软件测试》的笔记-第30页

输入筛选器，需要验证：非法的进不来；合法的都在里面；能否绕过筛选器

《探索式软件测试》的笔记-第17页

使用探索式测试并不是说不写文档。测试结果、测试实例和测试文档都会在运行测试时创建。这和普通测试在测试计划里预先编写好截然不同。用于记录探索式测试结果的最佳工具就是那些截屏软件和记录击键的软件
探索性测试的缺点在于测试人员有可能在测试中没有重点，从而漫无目的地尝试各种情况来试图发现软件缺陷，这会浪费大量时间。从测试策略的角度来说，明确到底要测什么和怎么测试同样重要

《探索式软件测试》的笔记-第162页

算法、计算复杂度、图论、数据结构背景知识都是必不可少的技术。

《探索式软件测试》的笔记-第29页

开发人员有三种基本方式定义错误处理程序（error handler），它们分别是输入筛选器（input filter）、输入检查（input check）和使用异常（exception）

《探索式软件测试》的笔记-第21页 - 第二章：手工测试

目前看完了第二章，了解了什么是局部探索式和全局探索式测试的定义。以前不知道什么是探索式测试，看完了前两章后回想了下，感觉像是为以前做过的一些测试工作找到了理论依据。
当时我做测试的思路是按照定好的测试计划来做测试，在case目的不变的基础上可以进行自由发挥，因此发现了一些不易被发现的bug，当时颇感欣喜。现在发现，这样做，确实有点贴近书上描述的思想，但是并没有书中说的那么详尽具体，更不及书中规范。所以，还得接着学习。
希望这本书后面的内容能带给我更多收获。
（不知道为啥总感觉这本书或多或少有点啰嗦，我更开门见山直奔主题的感觉~~#）

《探索式软件测试》的笔记-第28页 - 第三章 局部探索式测试法

如何测试用户输入
合法输入和非法输入
输入筛选器
输入检查
异常处理代码
常规输入还是非常规输入
默认输入或用户提供的输入
使用输出来指导输入选择
如何测试软件状态
代码路径
用户数据
运行环境

《探索式软件测试》的笔记-第41页

输入 状态 路径 数据 运行环境