探索式软件测试读书笔记

标签: 软件测试 读书 笔记 | 发表时间:2014-01-11 18:49 | 作者:lijingshou
出处:http://www.iteye.com

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



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [软件测试 读书 笔记] 推荐:

Google软件测试之道之读书笔记

- - ITeye博客
以下是看完Google软件测试知道之后书中摘录以及整理的笔记.主要摘录自己认同的,有启发性,指导性的内容.并且适当对书中的内容做了一些整理,欲看全部内容请购买原版图书. 第一章:Google软件测试介绍. 1.Google的测试团队并非雄兵百万,我们更像是小而精的特种部队,我们依靠的是出色的战术和高级武器.

探索式软件测试读书笔记

- - 行业应用 - ITeye博客
2011年4月买的书,2014年1月才读,罪过罪过,后悔莫及.中括号里面的内容是自己的评注. 1.软件失效的主要原因是因为开发人员没有理解,预见或测试所有可以运行软件的环境 [环境应该只是失效的一个因素]. 2.测试人员拥有那种"如何才能攻破这个功能"的态度和开发人员那种"如何才能实现这个功能"的态度是相辅相成的 [可以说是相辅相成,换个角度也可以说明大家都不完美 ,才导致有分工].

《精力管理》读书笔记-1

- 黎明 - 战隼的学习探索
这本书是我前几天阅读的,这是当时的阅读记录:. #每天一本书#,70天,2011年2月25日,阅读书籍《精力管理》这本书的理念不错,但内容水分很大. 但这个理论正好给自己的时间管理观点和规划做个补充,评价3.5分. 时间管理应该根据自己的精力进行安排和调整,周期性地补充精力,来平衡精力消耗. 需要对你的精力进行海战略性的规划和应用,并把它当成一种习惯.

分享读书笔记 Data Mining Concepts and Techniques

- redhobor - BlogJava-首页技术区
Data Mining涵盖的内容非常多,学着学着就走进乱石阵,看不到大的picture了,Data Mining Concepts and Techniques是本经典的好书,虽然有些细节并不详尽,(如果详尽就变成圣经了)可以用它来把data mining的知识点结成一张网. 它包括数据的预处理,frequent patterns,decision tree, netural network, regression, clustering, time series等等很多方面.

读书笔记:少有人走的路

- zhoujg - 博客园-周金根
       记得好像是五六年前在公司投稿后得到一本书,这本书叫做《少有人走的路》. 当时看了一下,简单翻阅之后发现看不下去了,于是一直搁置着. 后来有同事知道我有这本书,她们想我借阅,并且说是听别人介绍才知道这本书的. 我也不知道她们后来得了之后有什么感受,反正还给我之后我还是放着. 这本书于是就静静的在我这个搁置了好几年.

云计算读书笔记(二)

- Gabriel - 博客园-首页原创精华区
google云计算服务包括:google文件系统GFS,分布式计算编程模形MapReduce,分布式锁服务Chubby,分布式结构化数据表Bigtable,分布式存储系统Megastore以及分布式监控系统Dapper等. GFS提供了海量数据的存储和访问能力. 分为三类角色,client(客户端),Master(主服务器)和Chunk Server(数据块服务器).

《思维导图》读书笔记

- Spectrophobia. - 读书笔记
今天分享的图书《思维导图》英国著名心理学家东尼·博赞在研究大脑的力量和潜能过程中,发现伟大的艺术家达·芬奇在他的笔记中使用了许多图画、代号和连线. 他意识到,这正是达芬奇拥有超级头脑的秘密所在. 在此基础上,博赞于19世纪60年代发明了思维导图这一风靡世界的思维工具. 这本书中过于夸大思维导图的作用而且废话过多,没有必须细读.

读书笔记 - How Google Test Software

- - CSDN博客研发管理推荐文章
(《谷歌如何测试软件》)的确为神秘谷歌公司揭开一层面纱,讲到了谷歌的代码文化和测试文化,讲到了角色划分,职责划分,测试种类划分,讲到优秀的不同角色的人应该具有什么样子的,讲到测试的创新和工具,还有大量的人物访谈. 这里的笔记主要包含:个人感兴趣的,值得备忘的,需要后续关注的东西记录.

《百问知识管理》读书笔记

- - 海涛的成长碎碎念
当时是为了买给妹子买 @秋叶 的大项目售前的那本书的,为了凑单免运费顺手把这本书也扔到了购物车里面,这也算是真爱了,支持大叔的同时还不忘支持下大叔的红颜知己,整本书大概花了两趟地铁的时间加上晚上睡觉前的一个多小时的时间看完的,不是很厚的一本很实用的工具手册. 公司部门在年中开会的时候提到了知识管理这块的一些东西,因为之前我一直在做个人知识管理的一些东西,业界除了一些企业知识管理的内容,所以部门知识管理这块就交给我在负责了,因为对企业知识管理大多了解都是理论上的,实践性的东西还真没怎么做过,还是有点发虚的,读完这本书算是松了口气.

《精益创业》读书笔记

- - CSDN博客推荐文章
        创业的过程是否可以总结、规范、提炼出共性和成功的方法. 《精益创业》无疑是这样的一本书,书中提到的很多创业观点其实平时我也领悟过,但是能以书面、可描述的语言总结出来,这是作者的厉害之处.         精益创业 (Lean Startup) 总结起来就是用3个动词驱动3个名词的轮回迭代过程:IPD -> BML ,即: .