《软件测试的艺术》读书笔记

《《软件测试的艺术》读书笔记》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、TheArtofSoftWareTesting》读书笔记（1）_引子 有关自己与软件测试之间的渊源而言，获悉这个领域的时间不长，接触的时间就更可谓短暂，但仔细想来，还要从大学期间说起比较好。 软件测试这个概念第一次出现在我的眼前时，是大四上学期开的软件工程这个科目中所涉及到的一点点。由于某些因素，使我在大学期间忽略了对测试领域相关知识的储备。第二次面对它时，是考研复习准备阶段。那时，我对测试这个领域也仅仅只是知道，就是中文书面表达的“测试”这两个汉字的含义而已。 工作的前两年里，或许是因为从事的是有关算法方面性质

2、的工作，所以并未对测试这个领域给予过多的关注，还好，或多或少还是接触到了一些。直到最近一年多来，由于一个大型项目人手不够的缘故，所以临时从自己负责的另一个研究项目中抽过来（刚好该项目阶段性完成），负责有关此项目的测试部署与规划。而这个时候，才能说是：真正意义上接触到了软件测试这个领域。 虽然，在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。但，从这个项目阶段性结束后自己的体会而言，给我感悟最深的还是有关软件测试这个领域的。通过在这个项目里的工作，让我真正体会到了：软件测试是一门艺术。恰恰也是因

3、为这个缘故，这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。《TheArtofSoftWareTesting》读书笔记（2）_前言 喜欢在网上书店中遛达，看到不错的书就买下。为什么不去书店？一个字，懒呗！总觉得，有那去书店的时间，完全可以好好睡一美觉，亦或可亲手烹制一顿美味可口的美食。哎，反正就是，懒得走出家门去逛街！ 恰巧，此次浏览书籍时，无意间看到了《TheArtofSoftwareTesting》这本书。在看了大家所给予它极高的评价留言后，虽然有些疑惑（毕竟这个时代，枪手太多了！），但我深信：

4、一本书能够“活”25年，应该还是很不简单的。于是，就半信半疑的订购了这本书，期望能够从这本书中获悉到有用的知识，来丰富一下自己面对这个领域时的贫乏困境，亦作为知识储备。 晕，这么薄！这是我拿到这本书后的第一反应。真的！没有预料到这书会这么薄！原以为这本经典的书，会诸如《C++Primer》、《TheC++ProgrammingLanguage》、《ProgrammingWindows》等这些著作那么厚。而当翻看了几章后，觉得确实很经典，也明白了为什么这本书会“活”了25年。于是，就诞生了我对这本书的第二感觉：薄而

5、精！看来是需要自己多花些时间去慢慢的品味，这样才方可体味到最纯最美的底酝。 打住自己对这本书的侃侃而谈（怕跑题太远，拽不回来），还是关注一下软件测试这个领话题吧！ 软件测试，怎么说呢？就自身经历而言，确实如书上所说：测试依然是软件开发中的“黑色艺术”。大学期间，计算机课程开的不少，没听说有专门开一门关于测试的课程。所以，在学生阶段，测试就属于是个被抛弃掉的名词！毕业时，不是做软件就是去搞网络，没有听到一个同学去应聘测试的！工作中，有专门的测试组（或部门），就更不用自己怎么上心去研究了！如今的氛围就是：红的够红，黑

6、的够黑！那叫一个“专”！哎，为什么不实行“两手都要抓，两手都要硬”的政策呢（一己之见，偏颇在所难免）？或许，我还不明白：“术业有专攻”的深刻含义吧！ 算了，最后还是谈谈对这本书的总观吧！1.该书是针对测试这一主题进行的实践探讨，而不是理论研究，顺便捎带了些对新的语言和过程的探讨；2.前言中提到了一个最为重要而又是长期、基本的指南：如何确保所开发的所有软件做了其应该做的，并且同样重要的是，未做其不应该做的？3.引言里指出一条著名的经验：即在一个典型的编程项目中，软件测试或系统测试大约占用50%的项目时间和超过50%

7、的总成本。《TheArtofSoftWareTesting》读书笔记（3）_一次自我检测 有创意！这是我对该书第一章的评价，也是唯一一次在看新书开篇时，能够把第一章给透透彻彻看完的。为何？还不是实在不能恭维有些书籍在开篇就进行枯燥而繁多的总结性、介绍性的文字。虽心里也清楚这些文字存在的重要性。但每每，还总是先粗略瞄过，在通读全书后，才会再次认认真真的看那些文字（这时，才真的能感悟到“提纲携领”的中文含义啊）。 创意在于：它只通过展示一次自评价测试，就能吸引我的眼球，并涌出一种想继续向下读的冲动；更能引起对自身一些

8、有关逻辑思维（考虑欠周全、缜密，存在盲点）、联想能力（需拓展思维，要富于联想与想像，即：思维“活”起来）、角度问题（要巧妙转换角度）等方面，所可能存在的不足进行深思。当然，能够引起深思的缘故，还不是在于那个评价测试嘛！提起来，汗颜！依据所谓的测试用例（即：特定的数据集合）自测试后，发现自己只能考虑到11项（总14项）需要测试的关键点。 文尾，谈谈作者对“软件测试”这个概念