Nwfads2011-学习资料大全：《软件测试的艺术》读书笔记.doc
《Nwfads2011-学习资料大全：《软件测试的艺术》读书笔记.doc》由会员分享，可在线阅读，更多相关《Nwfads2011-学习资料大全：《软件测试的艺术》读书笔记.doc（25页珍藏版）》请在冰豆网上搜索。
-+
懒惰是很奇怪的东西，它使你以为那是安逸，是休息，是福气；但实际上它所给你的是无聊，是倦怠，是消沉;它剥夺你对前途的希望，割断你和别人之间的友情，使你心胸日渐狭窄，对人生也越来越怀疑。
—罗兰
知识改变命运勤奋塑造成功
整理人
落叶
时间
2011-4-15
天才是百分之九十九的勤奋加百分之一的灵感
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.心理上，对于证明不存在是一个不可能完成的任务，无论该工程多么小；但若是一个寻找错误的任务，是可以完成的。
就心理承受而言，也是更容易接受的。
·“软件测试的目的在于证明软件能够正确完成其预订的功能。
”
1.心态上，不要本着只是为了证明程序能够正确运行而去测试程序，而应该一开始就假设程序中隐藏着错误（这种假设对于几乎所有的程序都成立）。
这样测试程序时，才能够发现尽可能多的错误。
2.要清楚这样一个道理：
每当测试一个程序，实质上是想为其增加一些价值。
通过测试来增加程序的价值，及是指测试提高了程序的可靠性或质量。
而提高了程序的可靠性，就是指找出并最终修改了程序的错误。
·“软件测试就是建立一个‘软件做了其应该做的’信心的过程。
”
1.错误认识的关键在于：
程序即使能够完成预定的功能，也仍然可能隐藏错误。
即，当程序没有实现预期功能时，错误是清晰地显现出来的。
但如果程序做了其不应该做的，这同样也是一个错误。
2.而后一方面一般都会人为的想当然，认为系统不会做那些事情的。
但不通过实践去证明，一切都是不可预计到的。
总
升级会员 