探索式软件测试读书笔记

2011年4月买的书,2014年1月才读,罪过罪过,后悔莫及.中括号里面的内容是自己的评注

第2章:手工测试

1.软件失效的主要原因是因为开发人员没有理解,预见或测试所有可以运行软件的环境 [环境应该只是失效的一个因素]

2.测试人员拥有那种"如何才能攻破这个功能"的态度和开发人员那种"如何才能实现这个功能"的态度是相辅相成的 [可以说是相辅相成,换个角度也可以说明大家都不完美 ,才导致有分工]

3.程序如果不在真实环境中运行起来,很多缺陷不会被触发 [参考1,后面也讲到环境本身算是一种输入源]

4.如果想发现与应用程序业务逻辑相关的缺陷,手工测试是最理想的选择

5.用于记录探索式测试结果的最佳工具就是那些截屏软件和记录击键的工具[有些困惑,难道每次都要记录?]

6.探索式测试最适用于使用"敏捷开发过程"的web应用程序,因为他们开发时间短,没时间编写正式的测试脚本[依现在的情形看,手机程序应该也是很适合的]

7.探索式测试和脚本测试算是两个极端,可以说是一种互补关系

 

第3章:局部探索式测试

1.对于软件测试的艰巨性和复杂性,正确的态度应该是从一开始就要承认无论怎么做都是不够的.

2.软件发布的时候可以达到的目标:所有重要的任务都完成了,而剩下没做的事情都是比较次要的,这样就可以较早尽可能地降低发布风险

3.软件运行的四个基本任务:接受输入,产生输出,存储数据和进行运算

4.测试人员应该牢记,大多数开发人员都不喜欢编写错误处理代码[开发与测试的思维方式不同]

5.使用探索式测试法的测试人员必须牢牢抓住显示的错误信息,我的建议是必须仔细阅读每一条错误信息

• 检查错误信息是否写错,它还可以透露出开发人员编程时的一些想法
• 如果错误信息比较笼统,往往表示这里使用的是异常处理的方式

6.测试人员不输入任何东西并不意味着软件就不需要花功夫去处理这些情况[此处指默认值]

• 尝试删除默认值,仅留下空白
• 默认值附近的值[边界值]

7.我们选择下一步使用 哪个输入的时候,必须考虑从前使用过的那些输入所造成的累积效应[软件的状态]

• 如果两个或者更多个输入在某种程度上是相关联的,那么他们应该放一起测

8.测试人员必须明确知道程序里可能有哪些分支,并理解哪些输入会导致软件走这条分支而不是那一条

 

第4章:全局性探索性测试

1.探索式测试的目标

• 理解应用程序如何工作,它的接口看起来怎样,它实现了哪些功能
• 强迫软件展示其全部能力
• 找到缺陷:探索程序的各种极端情况

2.任何关于测试计划的讨论都需要首先把软件划分成更便于管理的小块.这里引入了特性(Feature)测试的概念[之前在某公司工作的时候测试计划里就会列出程序的feature list]

 

3.商业区测试:商业区就是软件包装盒上描述的那些特性

• 指南测试法:要求测试人员通过阅读用户手册并严格遵照手册的建议并执行操作
• 博客测试法:遵循第三方的建议来测试
• 专家测试法:根据怒气冲冲的评论者的抱怨来创建测试用例
• 竞争对手测试法:遵循专家或者博客为竞争对手们提供的建议来测试 [以上大部份方法(指南测试法外)好像比较适合用于测试那些知名的应用程序]
• 卖点测试法:测试那些最卖钱的特性,可以参考销售的演示.使用此方法时候可以同时使用质疑测试法,想象推销的时候,客户在不断提问质疑的情景
• 地标测试法:依然有疑问....
• 极限测试法:向软件提出很多难以回答的问题
• 复杂的订单
• 订购很多数量的商品
• 所有字段都填错..等等,总之所做的一切不一定要有实际的意义,只要软件允许输入
• 快递测试法:快递移动之时候,能确保系统里持续更新快递单子的状态
• 深夜测试法/清晨测试法:对应软件执行维护任务,已经软件启动的时候
• 遍历测试法:选定一个目标,然后使用可以发现的最短路径来访问目标包含的所有对象

4.历史区测试:对于软件来说,它指从前版本遗留下的代码,通常难以理解.对于软件缺陷来说,历史经常会重演

• 恶邻测试法:测试缺陷横行的代码段,缺陷通常扎堆出现,缺陷多的地方值得反复测试
• 博物馆测试法:软件遗留代码值得关注
• 上一版本测试法:对上一个版本支持的场景和测试用例,验证在新版本中依然可以运行

5.旅游区:软件中有些特性对新用户非常有吸引力

• 收藏家测试法:收集软件的输出,收集得越多越好[错误信息可以用来做自动化测试]
• 长路径测试法:思想是到达目的地之前尽量多地在应用程序中穿行
• 超模测试法:重点不是测试功能,而是测试界面,比如外观,性能,刷新情况,界面是否违法管理或者标准
• 测一送一测试法:测试同时运行同一应用程序的多个拷贝情况[这个应该指非web程序]
• 苏格兰酒吧测试法:试图找出那些不容易找到的功能进行测试[应该是针对比较复杂的应用]

[评注:个人感觉旅游区里的方法似乎都是挺通用的方法,归到旅游区下显得有点刻意]

 

6.娱乐区:软件的辅助特性和功能

• 配角测试法:专注于某些特定的特性,把注意力向左或者向右调整几度,以确保配角得到应有的重视
• 深巷测试法:尝试测试最不可能被用到的或者那些最不吸引用户的特性
• 通宵测试法:测试应用程序能持续运行多长时间?处理数据而不崩溃?这个测试法背后的逻辑是永远不要关闭程序[这个可以不放在娱乐区吧.....]

 

7.旅馆区:前面指软件"休息"的时候的特性(p50),后面指测试计划中较少描述的次要及辅助功能[两处地方的定义似乎有点矛盾]

• 取消测试法:学会使用取消按钮,必须寻找应用程序中最耗时的操作来充分实施这种攻击.这种攻击往往会暴露程序自我清除能力的不足
• 懒汉测试法:接受所有的默认值,保持输入字段继续为空,表单中尽可能少填数据

[这两种同样是很通用的技巧...]

 

8.破旧区:

• 破坏测试法:该测试法的直观概括如下:
• 强迫软件做一些操作
• 掌握软件成功完成操作必须使用的资源
• 在不同程度上移除那些资源或限制使用那些资源,我们可以使用故障注入的概念来人为地创建有问题的运行环境
• 反叛测试法:要求输入最不可能的数据,或者已知的恶意输入,不应该出现的数据.以错误的顺序输入等
• 强迫症测试法:反反复复地执行同样的操作,用户往往会由于弄错而不得不回头重干

第5章:混合探索式测试技术

1.用户可以根据自己的计划和时间,随意增加或减少步骤来改变场景,一个场景可以演变出许多测试用例

2.通过场景引入变化

• 插入步骤:增加更多数据;使用附加输入;访问新的界面
• 删除步骤:去掉冗余和可选的步骤
• 替换步骤:某些步骤有多种方法完成,就可以用替换步骤
• 重复步骤
• 替换数据:理解应用程序连接和使用的数据源
• 替换环境:替换硬件,替换容器,替换版本,修改本地设置

第6章:实践中的探索式测试

1.Dynamics AX客户端的漫游

• 我们发现的很多缺陷都不是通过测试用例设计中所定义的测试用例找到的
• 未经改动的手工测试很少能检测到新问题,但是对现有测试做哪怕是最细微的改动都可能发现很多缺陷
• 出租车测试法:测试人员的责任和出租车司机一样,他们必须熟悉到达指定位置的每条可能的路径
• 出租车禁区测试法:与上面的测试相反
• 多元文化测试法:本地化测试

2.利用漫游查找隐错

• 取消一切能取消的操作,多次取消
• 反复刷新几次
• 损坏启动配置文件或者配置文件很大时,程序会崩溃

3.因为漫游测试定义了测试什么和如何测试,所以任何正常的测试人员都能够执行类似的漫游,发现类似的缺陷

 

第7章:漫游与测试中的棘手问题

1.在微软公司,对于每一个被发现的缺陷,明确地讨论它应该在什么时候被发现,基于缺陷的历史数据分析,我们将学会如何在代码审查,单元测试或其他方面我针对性地进行工作

2.农药悖论:当你向一块农田里的作物喷洒农药时,你将杀死大量的虫子,但是存活下来的虫子会增加对这种农药的抵抗性.要解决杀虫剂悖论问题,对于测试人员来说,意味着必须调整测试用例,场景和漫游路径就是杀虫剂

3.建好的房屋有一定数量的缺陷,只有人们住进去后才会发现,软件也不例外.

4.漫游测试在一定程度上效果更好,因为一条漫游路径可以代表任何数量的实际测试用例

 

第8章:软件测试的未来

1.THUD:测试人员的提示显示[对于web而言,应该显示系统日志,http请求状态,服务器状态等等信息]

2.测试用例的重用:携带环境的测试

• 测试原子和测试分子:到了一定阶段，积累的测试原子和分子会变得足够多,使需要编写新测试用例或修改旧测试用例的可能性变得很小
• 我们我们写测试用例时所覆盖的区域越小,所产生的的测试用例就会越通用
• 可重用的测试实验室和测试用例将使将来未来软件测试人员的工作更偏重于设计

3.自我测试能力应该是未来软件的一项基本功能[这个应该更多地指客户端程序]

附录

1.测试门槛很低,但通往精通的道路却很艰难

2.测试自动化是解决重复劳动的答案

3.我们从开发人员的失败中学习如何编写可靠的代码.分析我们的成功也同样重要

4.我们必须使用和寻找产品缺陷一样的流程来寻找我们自己的测试流程,测试过程中的缺陷

5.相对于那些工程专家,我们对于很多细节从没有深入思考,而只流于表面的直觉

6.测试过程中考虑使用调试器之类能追踪动作和软件状态的工具

7.每一个好缺陷背后,都可能隐藏着一个更好的缺陷.在你确实了解缺陷的影响程度和破坏力之前永远不要停止搜索

8.我们不应该抱怨发布日期,而是应该提前警告后果.这是我们的职责范围,也是我们应该担心的范围

9.阅读源代码可以学习到很多东西

10.我们行业所有已知的开发方法所能提供的些许改进,已经远远跟不上我们所创建的系统复杂性

11.分析质量问题的流程

• 收集我们发布给用户的所有缺陷
• 分析每一个缺陷
• 每一个开发人员,测试人员都能理解我们曾写过的每一个缺陷
• 将学到的内容整理成文档

12.测试人员评估:真正的评估并不在于衡量找出软件缺陷的数量,而在于改正这些缺陷后软件质量得到改善的程度.你可以通过观察测试人员究竟提高了多少开发人员的工作绩效.测试人员是质量控制大师

13.让设计者以及其他的软件开发周期里的角色参与测试才是我们的将来.如果项目中的每个人都理解测试,想象我们需要很少测试人员就可以达到这一目标

14.手工测试能更好地测试业务逻辑,而自动化测试在寻找基础结构性软件缺陷上胜过手工测试

15.唯一真正储存测试历史智慧的地方就是在我们的自动化测试工具[个人以为还有测试用例等其他文档]

本文出自"lijingshou"博客，请务必保留此出处lijingshou.iteye.com/blog/2002829