探索性测试，笔记一
一些有意义的条目：
1、考虑自动化是否能发现有价值的缺陷，是否经得起时间的考验，是否值得付出维护费用
2、决定需要测试什么和何时测试
*对于每一个被发现的缺陷，明确的讨论它应该在什么时候被发现
3、决定如何测试
*是否有一种特殊的路径引导人员找到这个缺陷
*这种功能或特许最好用哪种给定的方法来测试
*知道当前已经进行了哪些测试，以及我们目前和将要进行的测试如何才能增加总体测试效果
*发现软件问题，需要实际用户在实际的环境中，用实际的数据，去做实际的工作
*简单重复的工作实现测试自动化
4、测试中最困难的部分是：决定测什么，决定测试的完整性，确认用户场景等
5、哪些是好的测试，哪些是不好的测试；完成测试后，团队学会了什么？
测试修行：（很重要）
1、将测试分为两部分，即“测试今天的项目，准备明天的项目”
*保证当前的测试项目获得成功
*学习应该做些什么以便下一个测试项目更紧容易
2、警惕重复做一件事情，尝试能不能自动化
3、思考：
*我们用什么技术找到了那个缺陷？
*我们是否可以创建一种方法来找到更多这类缺陷？
*是否可以记住一些实际的测试经验并不断加以应用来提高测试效率？
*软件的哪些症状可以提示我们它有缺陷？
*我们将来能否从那些症状中得到更多的警示？
*这个缺陷教会了我们什么？
因而总结一系列的测试技术、建议和工具
4、反思：
*自己的测试流程是否有问题？
*测试流程里有没有缺陷？
*这里面是否存在妨碍我提高效率的障碍
*例如：
1）收集我们发布给用户的所有缺陷（特别是安全漏洞或者数据缺陷）：
反思我们是否有流程问题，思路是否有方向性错误，或者是否犯了错误
2）分析每个缺陷，争取做到：
停止写出类似的缺陷；更擅长寻找类似的缺陷；当类似缺陷发生时，该如何识别它们
3）能让团队的开发人员、测试人员或者策划等，知道和明白自己所写过的每个缺陷
4）将学到的内容整理成文档，构成已知缺陷的知识体系的基础部分，也尝试通过新的方法，或者自动化的方式来预防错误
5、当发布每个缺陷时，多问问自己几个why 和how：
*一开始是什么错误导致了这个缺陷？能帮助开发小组建立一套系统知识，来减少错误么？
*出现什么样的失败症状时，能告诉我们现在存在这个缺陷？如何将有缺陷的行为从正确行为中分离出来？
*哪些测试技术可以找到这个缺陷
6、学会使用工具，和掌握信息，了解信息如何影响测试
*来自应用程序的信息，包括：需求、体系结构、代码结构、源代码、程序执行时做了哪些事情的运行信息
*确认代码更新或缺陷修复时，哪些测试会受到影响
对自己的训练：
1、理解软件：
*软件可以做什么？本意是什么？
*它使用哪些外部资源来完成任务？
*它的的主要行为是什么？
*它如何和环境交互？
2、理解软件故障：
*是否存在某些编程习惯或者程序语言特别倾向于导致这种类型的故障
*这些特定的故障是否可能出现在某些特定类型的软件行为中
*这些特定的故障是如何使自己显示为失效的
3、理解软件失效：
*为什么软件失效
*软件如何失效
*是否有软件失效的症状可以揭露我们的应用程序的健康状况
*某些功能是否有系统问题
*我们如何迫使特定的功能失效
自我总结：
1、记录测试完整性的部分
*测试用例的执行情况
*测试用例的覆盖面
*版本更新情况和用例维护情况的对比
*版本复杂度和重要性，与用例的覆盖的对比
2、考虑哪些可以用图形来表示：
*测试了哪些，哪些没测试
*测试的功能模块的复杂度
*功能模块内部的依赖关系和外部的依赖关系
*哪些需要重点测试
*测试了的部分的完成度，特别是针对重点模块的
3、找出软件缺陷的能力，需要同考虑如何减少软件中的错误结合起来，这样的能力才是真正的有意义。（回顾起来这也是我以前做的很不好的一点）
*想起以前看到的一个有意思的观点是：
“软件测试的真正价值并不体现在代码中找到多少缺陷，而是发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足。”
PS：我不是自动化测试的fans，也不是人工测试的fans；不相信有包治万灵的银弹，但是如果只有一种锤子，那么所有的钉子也会被看成是同一种钉子了！那是悲剧，不是福音！
探索性测试，笔记二
测试十戒律：
1、你应该使用大量输入，来反复锤炼被测的应用程序
*大规模的随机测试（自动化），而且有助于理解输入和输出的关系
2、你应当贪图你的邻居的应用程序
3、你应当亲自寻找睿智的预言家
*对应的输入是否有对应的输出，也就是测试基准是否清楚的了解特定输入和环境条件组合的情况；
*尝试让测试基准自动化，也许做不到，但是这样思考你可以选择做更有效率的工作
4、你不应该崇拜无法重现的失效
*尽最大努力注意并记住（或记录下）对软件采取的动作次序，同时记住应用程序的响应
*考虑使用调试器之类能追踪动作和软件状态的工具
*警惕为它白白花去了一整天的时间
5、你应该尊重你的模型和自动化测试
*测试模型是关于应用程序做些什么（即模型）和怎么去做（即自动化测试）的点滴智慧的结晶
*即使做不到自动化，也应该尝试
6、你应该利用开发人员的过错与他们作对
*总结开发人员的错误类型，理解他们自己的错误模式，然后将该类型错误的测试运用到该开发人员编写的每个模块
7、你应该醉心于应用程序的谋杀（诸如让你的机器蓝屏吧^_^）
*对于任何一个缺陷应该深入调查，而不是轻易放过
*确认自己是否确实了解缺陷的影响程度和破坏力
8、你应该保持产品发布时刻的圣洁
*不要抱怨发布日期，当时间不够以前，应提前警告后果
9、你应该贪图开发人员的源代码
*理解错误处理代码，以及哪些输入能触发他们
10、不能假设任何东西
*在我们验证某个缺陷是真之前，不要相信它是真的
*测试时，应该什么都不期待，既不期待他应该发生，也不期待他不应该发生
个人总结：
1、重点关注错误处理代码
*输入过滤器：用于防止错入得输入进入被测试的软件
*输入检查：用于保证软件不会使用错误的输入
*异常处理
*输入类型，输入长度，和边界值
2、应该具备的特点：
*不断超越自己、质量至上、持续教育
*不要为逃脱的缺陷而懊恼，把它们当做是一个学习的机会
对自己的训练：
有趣的观点：
1、软件测试是门学科，不是技艺，也不是艺术，是需要通过训练的；训练的意思是理解学科的每一个细节！
2、在事先不了解如何正确编制软件的情况下，不存在建立一种软件开发方法，让质量更好的可能！
3、评估测试人员，不要用软件缺陷的数量、软件缺陷的严重性、测试用例的多少、自动化测试的代码量、回归测试套件的数目以及任何具体的指标来衡量。测试人员是有责任教育破坏质量的人，哪些行为是错误的，以及如何改进。
探索性测试，笔记三
*把所有要做的事情按照优先级排序，然后从最重要的事情做起
进行局部探索式测试的决策的5要素：输入、状态、代码路径、用户数据、执行环境
输入：
1、识别哪些输入值和其他输入有关联，在同一个测试用例中使用它们
2、识别和考虑输入的先后顺序
3、注意区分非法输入是input filter、还是input check，还是使用exception
*留意是否可以绕过input filter
*留意ctrl,alt,shift按键组合的字符，找出特殊字符
4、注意测试不输入任何值的情况、默认值的情况
*留意默认值能否修改、删除
5、根据输出结果来选择输入
*可以有时候先观察输出结果，然后再选择新的输入
*注意初始状态对输出地影响，是否要重复运行测试几遍
*输出结果是否可以保存？尝试改变保存的输出值，看看改动这些值后，是否会重新生成，或者有新的问题
状态：
1、确认软件状态是临时的，还是长期保存的
2、使用状态信息来帮助寻找相关的输入
3、使用状态信息来辨识重要的输入序列
*例如状态变化在某种方式上被累加起来，就必须考虑是否会发生溢出
代码路径：
1、弄清输入会导致软件走的那条分支
用户数据：
1、使用用户的真实数据（你可能不清楚所有数据的相互关系和结构，用真实的数据可以弥补这点）
探索性测试，笔记四
*建立起一个全局目标后，再开始测试
探索式测试的几个目标：
1、理解应用程序如何工作、它的接口看起来怎样、它实现了哪些功能
2、强迫软件展示全部能力：
*目的是让软件努力运行，证明软件确实实现了设计时所要求达到的功能
3、找到缺陷，并有目的的使缺陷数量降为零
把软件特性划分成几个相互重叠的“区域”，具体区域和测试方法如下：
商业区：
*含义：用户所要使用的软件特性和功能，你的软件包装盒上描述的特性和掩饰的特性及代码
测试方法：
1、指南测试法：根据用户说明书来测试
2、卖点测试法：观摩哪些销售演示，测试演示过程，并且可以加上质疑测试法
3、地标测试法：提前确定关键的软件特性，确定他们的前后顺序
4、极限测试法：向软件提出最困难的问题
5、快递测试法：关注于数据，找到每个和数据有接触的软件特性
6、遍历测试法：通过选定一个目标（例如所有菜单项、所有错误消息或所有对话框），然后使用可以发现的最短路径来访问目标包含的所有对象
历史区：
*含义：从前版本遗留下的代码，还有那些曾经出现较多缺陷的特性和功能
测试方法：
1、恶邻测试法：反复测试缺陷特别多的地方
2、博物馆测试法：关注被接受重新修改的老代码，或者是没被改动就放到新环境中运行的老代码
3、上一版测试法：回归测试，关注新版本中无法再运行的测试用例
娱乐区：
*含义：软件的辅助特性，而不是主线特性
测试方法：
1、配角测试法：关注和主要的特性非常邻近的特性，例如和主要的特性一同出现在显示器上，容易被用户注意
2、深巷测试法：软件中最不可能被用到的或者最不吸引用户的特性，有助于提高代码覆盖率
*注：多个特性混合在一起测试时，比如重要的和不重要的混在一起时，可以考虑：
**有关输入的问题：这两个特性会不会处理同一输入
**有关输出的问题：这两个特性功能是否在可见的用户界面上操作同一块区域？他们会产生同一个输出吗？
**有关数据的问题：这两个特性会操作其共享的一些内部数据？是读取共享数据、还是修改共享数据
3、通宵测试法：性能测试和压力测试，永远不关闭程序，连续不断的使用某些特性来测试软件
旅游区：
*含义：只对新用户有吸引力的特性和功能，它关心的是快速访问软件的各种功能，而不是关心软件是否工作
测试方法：
1、收藏家测试法：收集软件的输出，收集的越多越好
*背后的思想是测试人员到达所有那些可到达的地方并把观察到的输出结果记录下来
2、长路径测试法：测试离应用程序开始点尽可能远的特性，例如：哪个特性需要点击N次才能被用到，选定该特性，一路点击过去，然后测试它
*指导思想：到达目的地前尽量多的在应用程序中穿行，因而要选取埋在应用程序最深处的特性
*可以结合收藏家测试法
3、超模测试法：只关心表面的东西
4、测一送一测试法：测试时运行一个应用程序，然后运行该应用程序的另外一个拷贝，然后再运行一个拷贝时，关注网络传输数据、文件操作等方面
旅馆区：
*含义：指一些经常被忽视的或者在测试计划中较少描述的次要的及辅助功能
测试方法：
1、取消测试法：
*启动操作然后停止它，并花些时间在应用程序里四处检查
*找应用程序中最耗时的操作来充分实施这种方法
*可以尝试开始一个操作，不要停止它，然后再开始另一个同时的操作
*在取消被测对象之前应该改变被测对象的状态，这点也很重要
2、懒汉测试法：做尽量少的实际工作，
*可以尝试接受所有的默认值，测试程序对默认值的处理情况
破旧区：
*含义：指一些经常被忽视的或者在测试计划中较少描述的次要的及辅助功能
测试方法：
1、注意输入的限制，哪些是非法输入；注意不按照指定的顺序做事情
2、重复执行同样的操作，重复输入同样的数据
总结：
1、跟踪哪种测试法发现的缺陷最多，哪种执行时间最少，哪种的代码、界面、功能覆盖最多等
探索性测试，笔记五：混合探索式测试
通过场景操作引入变化来测试场景，包括：插入步骤、删除步骤、替换步骤、替换数据、替换环境
插入步骤：
*给场景插入一个或多个步骤能增加软件失败的机会
1、插入更多数据：
*问自己：“这个场景用到哪些数据？怎样有意义的增加测试所使用的数据”
*提供超过场景要求的信息，或者超过场景要求数目的信息
2、使用附加输入
*了解哪些附加功能和场景提到的功能有关联
*了解哪些其他输入和场景使用的输入有关
3、访问新的界面：
*了解哪些界面和现有场景使用的界面相关
删除步骤：
*去掉冗余和可选的步骤，让场景的步骤尽可能少
替换步骤：
*研究其他替代的方法来执行场景中的每个步骤和动作
重复步骤：
*重复执行某些特定动作，或重复多个动作
替换环境：
1、替换硬件
2、替换容器：例如被测程序运行在所谓的容器应用程序中（如浏览器）
3、替换容器版本
4、修改本地设置
*注意程序是否使用一些本地设置，和对这些本地设置的假设
里面提到了一种叫做混票测试法，简言之，就是测试通用的数据或通用的场景