abezsx《软件测试的艺术》读书笔记.docx
《abezsx《软件测试的艺术》读书笔记.docx》由会员分享，可在线阅读，更多相关《abezsx《软件测试的艺术》读书笔记.docx（25页珍藏版）》请在冰豆网上搜索。
abezsx《软件测试的艺术》读书笔记
-+
懒惰是很奇怪的东西，它使你以为那是安逸，是休息，是福气；但实际上它所给你的是无聊，是倦怠，是消沉;它剥夺你对前途的希望，割断你和别人之间的友情，使你心胸日渐狭窄，对人生也越来越怀疑。
—罗兰
TheArtofSoftWareTesting》读书笔记
（1）_引子
有关自己与软件测试之间的渊源而言，获悉这个领域的时间不长，接触的时间就更可谓短暂，但仔细想来，还要从大学期间说起比较好。
软件测试这个概念第一次出现在我的眼前时，是大四上学期开的软件工程这个科目中所涉及到的一点点。
由于某些因素，使我在大学期间忽略了对测试领域相关知识的储备。
第二次面对它时，是考研复习准备阶段。
那时，我对测试这个领域也仅仅只是知道，就是中文书面表达的“测试”这两个汉字的含义而已。
工作的前两年里，或许是因为从事的是有关算法方面性质的工作，所以并未对测试这个领域给予过多的关注，还好，或多或少还是接触到了一些。
直到最近一年多来，由于一个大型项目人手不够的缘故，所以临时从自己负责的另一个研究项目中抽过来（刚好该项目阶段性完成），负责有关此项目的测试部署与规划。
而这个时候，才能说是：
真正意义上接触到了软件测试这个领域。
虽然，在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。
但，从这个项目阶段性结束后自己的体会而言，给我感悟最深的还是有关软件测试这个领域的。
通过在这个项目里的工作，让我真正体会到了：
软件测试是一门艺术。
恰恰也是因为这个缘故，这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。
《TheArtofSoftWareTesting》读书笔记
（2）_前言
喜欢在网上书店中遛达，看到不错的书就买下。
为什么不去书店？
一个字，懒呗！
总觉得，有那去书店的时间，完全可以好好睡一美觉，亦或可亲手烹制一顿美味可口的美食。
哎，反正就是，懒得走出家门去逛街！
恰巧，此次浏览书籍时，无意间看到了《TheArtofSoftwareTesting》这本书。
在看了大家所给予它极高的评价留言后，虽然有些疑惑（毕竟这个时代，枪手太多了！
），但我深信：
一本书能够“活”25年，应该还是很不简单的。
于是，就半信半疑的订购了这本书，期望能够从这本书中获悉到有用的知识，来丰富一下自己面对这个领域时的贫乏困境，亦作为知识储备。
晕，这么薄！
这是我拿到这本书后的第一反应。
真的！
没有预料到这书会这么薄！
原以为这本经典的书，会诸如《C++Primer》、《TheC++ProgrammingLanguage》、《ProgrammingWindows》等这些著作那么厚。
而当翻看了几章后，觉得确实很经典，也明白了为什么这本书会“活”了25年。
于是，就诞生了我对这本书的第二感觉：
薄而精！
看来是需要自己多花些时间去慢慢的品味，这样才方可体味到最纯最美的底酝。
打住自己对这本书的侃侃而谈（怕跑题太远，拽不回来），还是关注一下软件测试这个领话题吧！
软件测试，怎么说呢？
就自身经历而言，确实如书上所说：
测试依然是软件开发中的“黑色艺术”。
大学期间，计算机课程开的不少，没听说有专门开一门关于测试的课程。
所以，在学生阶段，测试就属于是个被抛弃掉的名词！
毕业时，不是做软件就是去搞网络，没有听到一个同学去应聘测试的！
工作中，有专门的测试组（或部门），就更不用自己怎么上心去研究了！
如今的氛围就是：
红的够红，黑的够黑！
那叫一个“专”！
哎，为什么不实行“两手都要抓，两手都要硬”的政策呢（一己之见，偏颇在所难免）？
或许，我还不明白：
“术业有专攻”的深刻含义吧！
算了，最后还是谈谈对这本书的总观吧！
1.该书是针对测试这一主题进行的实践探讨，而不是理论研究，顺便捎带了些对新的语言和过程的探讨；
2.前言中提到了一个最为重要而又是长期、基本的指南：
如何确保所开发的所有软件做了其应该做的，并且同样重要的是，未做其不应该做的？
3.引言里指出一条著名的经验：
即在一个典型的编程项目中，软件测试或系统测试大约占用50%的项目时间和超过50%的总成本。
《TheArtofSoftWareTesting》读书笔记（3）_一次自我检测
有创意！
这是我对该书第一章的评价，也是唯一一次在看新书开篇时，能够把第一章给透透彻彻看完的。
为何？
还不是实在不能恭维有些书籍在开篇就进行枯燥而繁多的总结性、介绍性的文字。
虽心里也清楚这些文字存在的重要性。
但每每，还总是先粗略瞄过，在通读全书后，才会再次认认真真的看那些文字（这时，才真的能感悟到“提纲携领”的中文含义啊）。
创意在于：
它只通过展示一次自评价测试，就能吸引我的眼球，并涌出一种想继续向下读的冲动；更能引起对自身一些有关逻辑思维（考虑欠周全、缜密，存在盲点）、联想能力（需拓展思维，要富于联想与想像，即：
思维“活”起来）、角度问题（要巧妙转换角度）等方面，所可能存在的不足进行深思。
当然，能够引起深思的缘故，还不是在于那个评价测试嘛！
提起来，汗颜！
依据所谓的测试用例（即：
特定的数据集合）自测试后，发现自己只能考虑到11项（总14项）需要测试的关键点。
文尾，谈谈作者对“软件测试”这个概念的定义吧。
所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。
软件应当是可预测且稳定的，是不会给用户带来意外惊奇的。
《TheArtofSoftWareTesting》读书笔记（4）_初次探究
“软件测试是一项技术性工作，但同时也涉及经济学和人类心理学的一些重要因素”，这是该书第二章中最吸引我的话，耐人深思。
而对于该章的内容，我个人觉得可概括为以下三个方面：
o心理学角度：
驳斥了一些社会普遍存在的错误认识，并给出了测试的正确定义及在含义上进行了延伸。
（用写文章上常用的术语来说，是：
先破后立。
）
o经济学角度：
验证软件测试不能够发现“所有”的错误。
（术语是：
各个击破。
）
o归纳了软件测试中的一些基本原则（术语是：
归纳与演绎。
），及三个重要的测试原则：
1.软件测试是为发现错误而执行程序的过程；
2.一个好的测试用例具有较高的发现某个尚未发现的错误的可能性；
3.一个成功的测试用例能够发现某个尚未发现的错误。
文尾，值得一提的是：
在本章能明显感到作者侧重于从心理学角度来分析一些潜在的问题。
TheArtofSoftWareTesting》读书笔记（5）_心理学视角解析（上）
先谈谈从心理学角度所需要分析的问题。
在章节的开始，作者就明确的给予了一个认知：
要成功地测试一个软件应用程序，测试人员也需要有正确的态度。
在某些情况下，测试人员的态度可能比实际的测试过程本身还要重要。
并且，分析了现在社会上普遍存在的两种“本末倒置”的错误认识。
∙针对程序员：
一开始就把“测试”这个术语的定义搞错了。
所以可想而知，作者肯定要先破其错误的根源和弊端，然后再立其正确的认知，为了能更深入的理解和在实践上的把握，作者又对正确的认知给予了进一步延伸的阐述；
∙针对项目经理：
针对测试方面而言，对“成功的”和“不成功的”的理解认识上的错误。
文尾，值得一提的是：
作者在这引荐一个病人去医生那里看病的例子，于是将一些绕人的关系和原理，刹那间弄的清晰易懂了。
看来恰当适宜的举例还是比枯燥的讲解概念间的区别与联系要容易的多，也生动的多，并且使人也能理解的更加深刻。
《TheArtofSoftWareTesting》读书笔记（6）_心理学视角解析（中）
上次谈到了两个错误认识，那就继续这个话题吧。
先分析与项目经理有关的这个错误认识吧。
因为这个因素可能会导致一些在测试问题上的根本性错误的认识。
作者主要是从“成功的”和“不成功的”这两个方面来剖析的：
∙指明了错误认识的本源：
“成功的测试”是指没有发现错误的测试用例；而“不成功的测试”是指发现了某个新错误的测试。
∙明确正确认识的本质：
如果在测试某段程序时发现了错误，而且这些错误是可以修复的，就将这次合理的设计和由此得到有效执行的测试称为是“成功的”；并对如果在本次测试中可以最终确定再无其他可查出的错误，同样也被称作是“成功的”；而对未能适当地对程序进行检查，且在大多数情况下，未能找出错误的测试被称为是“不成功的”。
∙引荐病人去找医生看病的这一生动的例子，加以引申理解并给予了结论：
能发现新错误的测试用例不太可能被认为是“不成功的”，相反，能发现错误就证明它是值得设计的。
一个“不成功的”测试用例，会使程序输出正确的结果，但不能发现任何错误。
细想：
如果规划的测试用例是能使程序输出正确的结果，但不能发现任何错误的话，那是多么的可怕阿。
那么测试就等于没有测试，或者是在徒劳。
而潜在的错误还依然潜在，这会开发人员跟用户来说，都是有不小的隐患的。
这才真正认识到：
发现测试真的是一门需要去潜心研究的艺术。
不仅仅是为了我们开发人员自己，也为了用户，更为了将来软件能够更好的维护跟升级。
《TheArtofSoftWareTesting》读书笔记（7）_心理学视角解析（下）
接着，来谈谈程序员方面会产生的错误认识吧！
这个方面可能在具体实践中显的更重要。
由于作者在开篇就先把三个错误认识给摆到读者的眼前；然后就立马表明了其正确的定义，并给予了分析和对错误认识的驳斥。
洋洒洒的写了许多，条理上未免会有些混乱。
因此，我就按照自己理解的来小结一下吧！
首先，测试的正确定义是：
测试是为发现错误而执行程序的过程。
该定义暗示了两层含义：
∙软件测试是一个破坏性的过程，甚至是一个“施虐”的过程。
（就自己的亲身经历而言，大部分的开发人员在测试期间，对测试人员或多或少都会暂时产生一点厌烦或恐惧的心态。
主要是会让开发人员的代码改的面目全非的，且这个过程是反反复复的。
）
∙对于一个特定的程序，应该如何设计测试用例（测试数据）、哪些人应该而哪些人又不应该执行测试。
（这是有关测试人员构成的问题。
就自己的亲身经历而言，这一点很重要，因为测试人员的态度要比测试的过程更为重要。
）
然后，明确测试的正确含义后，探究了一下现今面临的三个错误认识并逐一给予了充分的驳斥。
∙“软件测试就是证明软件不存在错误的过程”。
1.若目的仅是为了证明程序中不存在错误，就会在潜意识中倾向于实现这个目标；即，会倾向于选择可能较少导致程序失效的测试数据；若目标在于证明程序中存在错误，设计的测试数据就有可能更多地发现问题。
后者肯定比前者会更多地增加程序的价值。
2.心理上，对于证明不存在是一个不可能完成的任务，无论该工程多么小；但若是一个寻找错误的任务，是可以完成的。
就心理承受而言，也是更容易接受的。
∙“软件测试的目的在于证明软件能够正确完成其预订的功能。
”
3.心态上，不要本着只是为了证明程序能够正确运行而去测试程序，而应该一开始就假设程序中隐藏着错误（这种假设对于几乎所有的程序都成立）。
这样测试程序时，才能够发现尽可能多的错误。
4.要清楚这样一个道理：
每当测试一个程序，实质上是想为其增加一些价值。
通过测试来增加程序的价值，及是指测试提高了程序的可靠性或质量。
而提高了程序的可靠性，就是指找出并最终修改了程序的错误。
∙“软件测试就是建立一个‘软件做了其应该做的’信心的过程。
”
5.错误认识的关键在于：
程序即使能够完成预定的功能，也仍然可能隐藏错误。
即，当程序没有实现预期功能时，错误是清晰地显现出来的。
但如果程序做了其不应该做的，这同样也是一个错误。
6.而后一方面一般都会人为的想当然，认为系统不会做那些事情的。
但不通过实践去证明，一切都是不可预计到的。
总体而言，软件测试更适宜用来作为一个试图发现程序中错误（假设其存在）的破坏性的过程。
一个成功的测试用例，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。
当然，最终还要通过软件测试来建立某种程度的信心；软件做了其应该作的，未做其不应该作的。
通过对错误的不断研究是实现这个目的的最佳途径。
需要明确的一点是，针对有人可能会声称“本人的程序完美无缺（不存在错误）”的这种情况而言，建立起信心的最好办法就是尽量去反驳他，即努力发现不完美指出，而不只是确认程序在某些输入情况下能够正确地工作。
文尾，我想到了高尔基先生在《海燕》里边的一句话：
让暴风雨来的更猛烈些吧！
不妨，让测试变的更加疯狂一些吧！
《TheArtofSoftWareTesting》读书笔记（8）_经济学视角解析
再从经济学视角来分析一下吧。
需明确：
对一个复杂的应用程序进行完全的测试，将耗费大量的时间和人力资源，以致于在经济上是不可行的。
即，从经济学的角度来说，软件测试是不能够发现“所有”的错误。
换言之，要发现程序中的所有错误是不切实际的，也常常是不可能的。
这也体现了测试人员对被测试软件的期望和对测试用例的设计方式。
由此，有了两种策略，即：
黑盒测试和白盒测试（均从三个方面进行阐述：
原理、方法、利弊）。
黑盒测试（又称为数据驱动的测试或输入/输出驱动的测试）
o原理：
将程序视为一个黑盒子，测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。
o方法：
测试数据完全来源于软件规范（不需要去了解程序的内部结构）。
如果想用这种方法来发现程序的所有错误，判定的标准就是“穷举输入测试”，将所有可能的输入条件都作为测试用例。
o利弊：
穷举输入测试是无法实现的。
原因有二：
一是无法测试一个程序以确保它是无错的；二是软件测试中需要考虑的一个基本问题是软件测试的经济学，即，测试投入的目标在于通过有限的测试用例，最大限度地提高发现的问题的数量以取得最好的测试效果。
白盒测试（又称为逻辑驱动的测试）
o原理：
允许我们检查程序的内部结构的。
这种测试策略对程序的逻辑结构进行检查，从中获取测试数据（但常忽略了程序的规范）。
o方法：
穷举路径测试。
即，如果使用测试用例执行了程序中所有可能的控制流路径，那么程序有可能得到了完全的测试。
o利弊：
程序中不同逻辑路径的数量可能会达到天文数字，那么穷举路径测试就同穷举输入测试一样，非但不可能也是不切合实际的。
文尾，值得提一下一个错误认知：
“穷举路径测试即完全的测试”。
因为，即使可以测试到程序中的所有路径，但是程序可能仍然存在着错误。
其原因有三：
o即使是穷举路径测试也决不能保证程序符合其设计规范；
o程序可能会因为缺少某些路径而存在问题，可穷举路径测试不能发现到底是缺少了那些必需路径；
o穷举路径测试可能不会暴露数据敏感错误。
《TheArtofSoftWareTesting》读书笔记（9）_原则解析
该章最后，作者给予了十大测试原则：
o测试用例中一个必需部分是对预期输出或结果的定义。
一个测试用例必需包括两个部分：
对程序的输入数据的描述和对程序在上述输入数据下的正确输出结果的精确描述。
o程序员应当避免测试自己编写的程序。
原因有三：
1.当程序员“建设性”地设计和编写完程序之后，很难让他突然改变视角以一种“破坏性”的眼光来审查程序，即，他们无法改变思维方式来尽力暴露自己程序中的错误；
2.程序员可能会下意识地避免找出错误来，担心受到同事、上司、客户或正在开发的程序或系统的主管的惩罚；
3.由于程序员错误地理解了疑难定义或规范，导致程序中存在错误。
如果是这种情况，程序员可能会带着同样的误解来测试自己的程序。
需要指出的是：
“调试”还是由程序的编写人员来完成会更加有效的。
o编写软件的组织不应当测试自己编写的软件。
应该是由客观、独立的第三方来进行测试。
理由雷同于上条规则中所涉及到的。
o应当彻底检查每个测试的执行结果。
在项目测试的时候，总是会发现在后续测试中发现的错误，往往是前面的测试遗漏掉的。
o测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况。
其实在软件产品中暴露出来的许多问题是当程序以某些新的或未预料到的方式运行时发现的。
所以这条原则的重要性可能在测试中的地位还应该是更要值得引起注意的才是。
o检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
o应避免测试用例用后放弃，除非软件本身就是一个一次性的软件。
在交互式系统上来测试的话，这条原则可能就会显现的更加重要了。
这条原则体现的会更加省时省力。
因为如果对程序的更改导致了程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的。
保留测试用例，当程序其他部分发生更动后重新执行，这就是我们所谓的“回归测试”了。
o计划测试工作时不应默认假定不会发现错误。
o程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
作者所说的而言，错误总是倾向于聚集存在，而在一个具体的程序中，某些部分要比其他部分更容易存在错误。
那么为了使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。
o测试是一项极富创造性、极具智力挑战性的工作
《TheArtofSoftWareTesting》读书笔记（10）_人工测试技术
本书第三章作者着重讲述了测试领域里的一个与机器测试相当重要，且在机器测试之前进行，也与之相辅相成的技术，即：
人工测试技术。
该技术共涉及四种方法：
代码检查、代码走查、桌面检查、同行评审；其更着重详细讲述的是第一个方法。
同时，作者在开章也提到一种错误认识：
人工测试技术由于包含了人为因素在内，导致很多方法的正规性要差于由计算机执行的数学证明，所以人们可能会怀疑某些如此简单和不正规的东西是否有用。
反之亦然。
就个人经历而言，确实这种认知普遍存在，并且对人工测试技术没有给予足够的重视。
文尾，有必要记叙一下，人工测试技术的重要性。
它会在两个方面显著地提高软件测试的功效和可靠性。
o错误发现得越早，改正错误的成本越低，正确改正错误的可能性也越大；
o程序员在开始基于计算机的测试时似乎要经历一个心理上的改变。
压力会急剧增长，且要“尽可能快地修正这个缺陷”。
由于这些，所以，程序员在改正某个基于计算机测试发现的错误时所犯的失误，可能要比改正早期发现的问题时所犯的失误会更多一些的。
《TheArtofSoftWareTesting》读书笔记（11）_优之共通
上篇，提到人工测试技术的四种方法。
其中，代码检查和代码走查稍略胜一筹。
于是，作者在本章着重讲了这两个方法。
其实，这两种方法很类似，那就先看看这两种方法的优之共通点吧！
具体可分为一下几个点：
o方法：
组成一个小组来阅读或直观检查特定的程序；并在“头脑风暴会”上要形成统一的目标：
找出错误，但不必找出改正错误的方法。
换句话说，是测试，而不是调试。
该组开发人员（三至四人为最佳）是对代码进行审核，其中参加者当中只有一人是程序编写者；也可以说它是对过去桌面检查过程的改进。
o优点：
一旦发现错误，就可以在代码中对其进行精确定位，这就降低了调试的成本；还通常可以发现成批的错误，这样就可以一同得到修正，这也优于机器测试，因为后者只能暴露出错误的某个表症。
o效果：
通常是能够有效地查找出30%-70%的逻辑设计和编码错误，但不能有效地查找出高层次的设计错误。
o地位：
是与计算机的测试互补的，缺少其中任何一种错误检查的效率都会降低。
值得提出的是：
该处的错误发现率，并不是说所有错误中多达70%可能会被找出来，而是讲这些方法在测试过程结束时，可以有效地查找出多达70%的已知错误。
应始终记住的是：
程序中的错误总数始终是未知的。
否则就会浪费大量的精力跟人力，也会在经济效益上或多或少有一些损失的。
不过，就经验而言，修改一个现存的程序比编写一个新程序更容易产生错误，这依据于以每写一行代码的错误数量来计的。
《TheArtofSoftWareTesting》读书笔记（12）_代码检查
代码检查，怎么说呢？
经验而言，我挺喜欢用的。
因为，跟项目经理（或设计人员）读设计，能够非常容易发现设计上的逻辑错误或遗漏的问题等等。
因此，有必要好好叙述下。
∙定义上：
所谓的代码检查，其实就是以组为单位阅读代码，是一系列规程和错误检查技术的集合。
该过程通常将注意力集中在发现错误上，而不是纠正错误。
∙成员组成：
一个代码检查小组通常是由四人组成，其中一人发挥着协调作用、一人是该程序的编码人员、一人是其他成员通常是程序的设计人员、一人是测试专家。
这里，值得一提的是：
那个发挥着协调作用的成员。
该协调人应该是个称职的程序员，但不是该程序的编码人员，不需要对程序的细节了解得很清楚。
协调人的职责包括几点：
为代码检查分发材料、安排进程；在代码检查中起主导作用；记录发现的所有错误；确保所有错误随后得到改正。
有关代码检查的具体流程，个人归纳为一个流程表，就不在这里详述了。
不过，这里需要值得注意的是代码检查这个过程。
1.在代码检查的时间和地点上的选择上，应避免所有的外部干扰；
2. 代码检查会议的理想时间应在90-120分钟之内；
3. 大多数的代码检查都是按每小时大约阅读150行代码的速度进行；
4. 对大型软件的检查应安排多个代码检查会议同时进行，每个代码检查会议处理一个或几个模块或子程序。
除此之外，还需要从心理学角度给予提前的心理筹备。
因为，要使检查过程有成效，还必须树立正确的态度。
其心理因素必须要提前分析正确，否则事倍功半。
假设程序员将代码检查视为对其个人的攻击、采取了防范的态度，那么检查过程就不会有效果。
而正确的做法应该是：
∙一方面：
提出的建议应针对程序本身，而不应针对程序员，即：
软件中存在的错误不应被视为编写程序的人员本身的弱点，且这些错误应被看做是伴随着软件开发的艰难性所固有的；
∙另一方面：
程序员必须怀着非自我本位的态度来对待错误检查，对整个过程采取积极和建设性的态度：
代码检查的目标是发现程序中的错误，从而改进程序的质量。
正因为这个原因，大多数人建议应对代码检查的结果进行保密，仅限于参与者范围内部。
尤其是如果管理人员想利用代码检查的结果，那么就与检查过程的目的背道而驰了。
文尾，顺便提一下代码检查附带的几个有益的作用吧。
∙程序员通常会得到编程风格、算法选择及编译技术等方面的反馈信息；
∙其他参与者也可以通过接触其他程序员的错误和编程风格而同样受益匪浅；
∙代码检查还是早期发现程序中最易出错部分的方法之一，有助于在基于计算机的测试过程中将更多的注意力集中在这些地方。
《TheArtofSoftWareTesting》读书笔记（13）_错误列表
在代码检查过程中，一个重要的部分是需要对照一份编程错误列表，来分析程序是否存在常见的错误。
于是，作者接下来就给出了一份错误列表，该份错误列表在很大程度上是独立于编程语言的，即：
大多数的错误都可能出现在用任意语言编写的程序中的。
并建议读者可以把自己使用的编程语言中特有的错误，以及代码检查发现的错误补充到这份错误列表中去。
作者给出的该列表比较详细，因此，不在这里详述，只是给出该错误列表的总的构架。
该列表共分为八个部分：
数据引用错误、数据声明错误、运算错误、比较错误、控制流程错误、输入/输出错误、接口错误、其他检查。
《TheArtofSoftWareTesting》读书笔记（14）_代码走查
说完代码检查，现在来谈谈
升级会员 