《软件测试的艺术》读书笔记
《软件测试的艺术》读书笔记
The Art of SoftWare Testing》读书笔记（1）_引子有关自己与软件测试之间的渊源而言，获悉这个领域的时间不长，接触的时间就更可谓短暂，但仔细想来，还要从大学期间说起比较好。
软件测试这个概念第一次出现在我的眼前时，是大四上学期开的软件工程这个科目中所涉及到的一点点。
由于某些因素，使我在大学期间忽略了对测试领域相关知识的储备。
第二次面对它时，是考研复习准备阶段。
那时，我对测试这个领域也仅仅只是知道，就是中文书面表达的“测试”这两个汉字的含义而已。
工作的前两年里，或许是因为从事的是有关算法方面性质的工作，所以并未对测试这个领域给予过多的关注，还好，或多或少还是接触到了一些。
直到最近一年多来，由于一个大型项目人手不够的缘故，所以临时从自己负责的另一个研究项目中抽过来（刚好该项目阶段性完成），负责有关此项目的测试部署与规划。
而这个时候，才能说是：真正意义上接触到了软件测试这个领域。
虽然，在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。
但，从这个项目阶段性结束后自己的体会而言，给我感悟最深的还是有关软件测试这个领域的。
通过在这个项目里的工作，让我真正体会到了：软件测试是一门艺术。
恰恰也是因为这个缘故，这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。
《The Art of SoftWare Testing》读书笔记（2）_前言喜欢在网上书店中遛达，看到不错的书就买下。
为什么不去书店？一个字，懒呗！总觉得，有那去书店的时间，完全可以好好睡一美觉，亦或可亲手烹制一顿美味可口的美食。
哎，反正就是，懒得走出家门去逛街！恰巧，此次浏览书籍时，无意间看到了《The Art of Software Testing》这本书。
在看了大家所给予它极高的评价留言后，虽然有些疑惑（毕竟这个时代，枪手太多了！），但我深信：一本书能够“活”25年，应该还是很不简单的。
于是，就半信半疑的订购了这本书，期望能够从这本书中获悉到有用的知识，来丰富一下自己面对这个领域时的贫乏困境，亦作为知识储备。
软件测试美读书笔记
客户反馈，然后进入下一阶段。（一个螺旋包括6个步骤：1.确定目标，可选方案和限
制条件；2.指出并解决风险；3.评估方案；4.本阶段开发和测试；5.计划下一阶段；
6.确定进入下一阶段的方法。 ）测试一直在进行，知道最后宣布成功！
2.软件出现了产品说明书指明不会出现的错误。
3.软件功能超出产品说明书指明范围。
4.软件未达到产品说明书虽未指出但应达到的目标。
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
二.软件缺陷的产生原因：
导致软件缺陷最大的原因是产品说明书；第二大来源是设计方案；三是代码；
四是某些软件缺陷产生的条件被错误地认定。
三.软件缺陷的修复费用：
随时间增长，修复软件缺陷的费用是呈几何数级增长的，随时间推移，数十倍增长。
四.软件测试人员的目的：
软件测试远的目标就是发现软件缺陷，尽可能早一些，并确保其得以修复。
五.怎么成为优秀测试员：
1.探索精神
2.故障排除能手
二.软件测试的术语和定义
这里引用下网上的术语总结，对原作者表示歉意和谢意和敬意！（不知道是谁）
1.精确和准确：A.精确参照物是目标。与目标越接近，就越准确；B：准确参照物是
每次实施的结果。几次结果相互之间越接近，表示越精确。但与目标可能相去甚远.
2.验证和合法性检查：A.验证保证软件符合产品说明书的过程 B.合法性检查保证软
第一部分 软件测试综述
软件测试-机械工业出版社 （美）Ron Patton著 周予滨 姚静等译
雪舞奉天读书笔记
软件测试的艺术
（6）误区之六：软件测试是没有前途的工作，只有程序员才是软件高手
由于我国软件整体开发能力比较低，软件过程很不规范，很多软件项 目的开发都还停留在“作坊式”和“垒鸡窝”阶段。项目的成功往往靠个 别全能程序员决定，他们负责总体设计和程序详细设计，认为软件开发就 是编写代码，给人的印象往往是程序员是真正的牛人，具有很高的地位和 待遇。因此，在这种环境下，软件测试很不受重视，软件测试人员的地位 和待遇自然就很低了，甚至软件测试变得可有可无。随着市场对软件质量 的不断提高，软件测试将变得越来越重要，相应的软件测试人员的地位和 待遇将会逐渐提高。在微软等软件过程比较规范的大公司，软件测试人员 的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至比程序员 还要高。软件测试将会成为一个具有很大发展前景的行业，软件测试大有 前途，市场需要更多具有丰富测试技术和管理经验的测试人员，他们同样 是软件专家。这两年来国内软件测试人员的需求不断增大,越来越多的IT企 业认识到了软件测试的重要性,这种可喜的现状与发展趋势让笔者对我国软 件业的发展重新抱有较大的希望。
Summary
尽管这是一门崭新的学科,目前在国内的发展仍处于"婴儿"阶
段,但看到越来越多的软件公司为软件测试招兵买马,看到越来越
多的技术人员投入到软件测试中,我就情不自禁地感叹:机会来了! 这机会不仅仅是某一个人的,而是所有人的,它对每个人都是公平
的,学的领域需要新的理论新的工具新的方法,由于国内的软件测
件项目实施过程中的重要性日益突出。但是，现实情况是，与软件 编程比较，软件测试的地位和作用，还没有真正受到重视，对于很
多人（甚至是软件项目组的技术人员）还存在对软件测试的认识误
区，这进一步影响了软件测试活动开展和真正提高软件测试质量。
软件测试技术大全读书笔记
软件测试技术大全读书笔记-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
一．测试是一种服务：
1.可以化解很多测试与开发之间的矛盾；
2.有利于测试客观公正地进行工作。
二．软件测试应该遵循的几个原则：
1.GoodEnough原则；--投入与产出成正比
2.Pareto原则；--80-20原则
3.尽可能早的开展测试；--早发现，代价小
4.在发现比较多错误的地方需要投入更多的测试；--聚集效应。
5.同化效应。
--交叉测试避免出现盲点。
三．IBM公司的软件测试方法
1.单元测试
2.集成测试
3.系统测试
4.验收测试
四．为什么需要回归测试
1.所谓回归：指产品的质量从一个较高的水平回落到一个较低的水平。
2.回归的问题根源是软件系统的内在复杂性。
3.随着系统构建的时间越长回归的问题也会增多。
2。
软件测试_读书笔记1
软件测试必备1、软件测试基本概念和方法三个重要的测试原则：1. 软件测试是为发现错误而执行程序的过程；2. 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性；3. 一个成功的测试用例能够发现某个尚未发现的错误。
1.测试的过程具有一定的破坏性2.测试用例包括：输入数据的详细描述和正确输出结果的精确描述3.检查程序是否‘没有做它应该做的’仅仅是测试一半，另一半是检查‘是否做了它不应该做的’4.全面测试目标：验证是否做了应该做的事情，确保可靠性验证程序是否做了不应该做的事情，确保安全性5.任何多余的功能都应视为安全隐患6.Boehm给出的度量中的头10个表示软件现象遵守Pareto分布：20％的模块消耗80％的资源（人力、经费等）；20％的模块包含80％的错误；20％的错误消耗80％的修改成本；20％的改进包含了80％的适应性为主的成本；20％的模块占用了80％的执行时间；20％的软件工具使用占80％的整个工具使用时间。
补充：20%的软件缺陷造成80%的软件故障20%的软件开发和管理人员（骨干），决定了80%软件开发质量：Pareto原理强调了精力集中在少数重要的事情上（vital few），而不是多数琐碎的事情上(trivial many)。
6.软件测试是一种作为主体的人通过各种手段对客体软件的某种固有属性进行的一种以8.审查的终极目标——确认缺陷9.人工审查包括：文档审查代码审查10. 软件缺陷的类型：可追溯性、逻辑、赋值顺序、控制、数据、接口、文档、注释、例外情况处理、内存等。
11. 只要简单地使用静态代码分析来增强输入验证的正确性就能够避免OWASP（业界领袖的安全性协会）所列出的约70%的安全性问题。
12. 圈度复杂度（独立路径的最大数量=程序控制流图中的区域数）=控制流图边数—控制流图的节点数+2二、测试框架的表述13. 测试框架（Test Framework）:一组相互协作的组件的集合，能够实现一个或多个测试域中的一系列问题的解决方案。
软件测试读书心得(例文7篇).doc
软件测试读书心得（例文7篇）软件测试读书心得篇1通过这次课程设计的实训，增加了我学习软件技术的兴趣，虽然还不明确软件技术包含的具体内容，但从C++语言这门课程开始，已发现程序设计的乐趣，在学习C++语言的过程中也学到了许多计算机应用基础知识，对计算机的机体也有了一个大体的了解。
在实际操作过程中犯的一些错误还会有意外的收获，感觉实训很有意思。
在具体操作中对这学期所学的C++语言的理论知识得到巩固，达到实训的基本目的，也发现自己的不足之出，在以后的上机中应更加注意，同时体会到C++语言具有的语句简洁，使用灵活，执行效率高等特点。
发现上机实训的重要作用，特别是对数组和循环有了深刻的理解。
通过实际操作，学会C++语言程序编程的基本步骤、基本方法，开发了自己的逻辑思维能力，培养了分析问题、解决问题的能力。
深刻体会到“没有做不到的，只有想不到的”，“团结就是力量”，“实践是检验真理的标准”，“不耻下问”的寓意。
在此希望以后应多进行这样的实训，加长设间，培养学生独立思考问题的能力，提高实际操作水平。
通过本次项目实训我要感谢学校领导给我们提供了这次机会，让我们自己有出去体会生活，自己做项目的深刻体会。
这次实训让我明白我自己之前的学习还是差很多，只有不断的努力，才能学好。
还要感谢达内公司对我的指导，我自己的努力固然重要，但是达内的优秀教师给我做的培训，讲的理论都让我受益匪浅，让我对软件有了一个新的概念新的理解。
软件测试读书心得篇5这个暑假惠普派人到我们学校来开展软件测试培训。
老师说机会难得所以我就参加了，说实话每天在教师从早晨坐到下午，中间只有一个半小时休息时间，这样还是相当累人的。
我们第一天开始就觉得这个简直比平常上课还累啊。
不过看到老师讲得如此认真，看到惠普如此强大，我看在座的学员都听得非常认真。
所以向我这种上课从来不听讲的这回都听得认真得不得了，呵呵。
前两天确实还是有点累，讲的也是理论课，而且以前我们从来没有接触过测试这个行业，所以听得也嘿吃力。
软件测试的艺术(第3版)第04章 测试用例的设计
4.2.2 边界值分析
等价划分虽然优于随机选取用例，但不足之处在于忽略了 某些特定类型的高效测试用例
经验证明，考虑了边界条件的测试用例与其他测试用例相 比，具有更高的测试回报率
边界条件：输入和输出等价类中那些恰好处于边界、或超过边界、 或在边界以下的状态P48－49
边界值分析与等价划分的不同
4.1 白盒测试
练习
if (g>3) { x = x / 3; } if (g==0 || x>1) { x = x + 1; }
4.1 白盒测试 ——综合训练
NextDate函数的设计、实现和测试
函数有3个参数：月份、日期和年；它们都具有整数值，且满足以 下条件：
1<=月份<=12 1<=日期<=31 1812<=年<=2012
第4章 测试用例的设计
4.1 白盒测试 4.2 黑盒测试 4.3 错误猜测 4.4 测试策略
第4章 测试用例的设计
软件测试中最重要的因素是设计和生成有效的测 试用例
任何程序的测试必定是不完全的，所以很难做到完全发 现软件中的错误，那么如何发现尽可能多的错误？
软件测试最关键的问题
在给定的时间和成本约束下，在所有可能的测试用例中， 哪个子集最有可能发现最多的错误？
4.1 白盒测试
A
a>1 && b == 0
例子
//被测试的程序段如下
if (a>1 && b==0) { x = x / a; } if (a==2 || x>1) { x = x + 1; }
C
yes x=x/a
B
no
吹风吹到疯：《软件测试的艺术》读书笔记
吹风吹到疯：《软件测试的艺术》读书笔记《软件测试的艺术》在长假的第四个悠闲的中午，灭掉了《软件测试的艺术》这本书，好像最近看的号称“艺术”的书比较多，《生活的艺术》，《项目管理的艺术》还包括这本《软件测试的艺术》。
一般来说，在IT行业一本书能够在25年之后出第二版的，那么这本书的生命力算是强的。
总的来说这本书讲的是中规中矩，感觉还是七十年代那种纯学术化的气息，让人联想到了大学的教科书。
书的开头还是非常精彩的，非常哲理化的开头，讲述了测试的本质，之后是一些看得头晕的名词和方法，最后的两篇关于调试和极限测试的不错，而新加的网站测试内容让人有点失望。
总的来说，对于想了解“软件测试”的同学还是可以去看看的，至于要学到什么的话，可能还要从其他地方继续深入了解。
不过就了解测试的目的，一些常用名词的意义，以及一些基本的原则来说，这本书还是不错的。
开头的经典：- 软件测试心理学：测试是为发现错误而执行程序的过程。
软件不是为了证明软件是好的，发现错误是他的目标。
- 软件测试经济学：软件中包含的错误的总和永远是个未知数，所以要找到软件中包含的所有的错误，几乎是不可能的。
- 原则1：测试用例中一个必需部分是对与其输出或结果的定义。
- 原则2：程序员应当避免自己测试自己编写的程序。
- 原则3：编写软件的组织不应当测试自己编写的软件。
- 原则4：应当彻底检查每个测试的执行结果。
- 原则5：测试用例的编写不仅应当根据有效和与其的输入情况，而且也应当根据无效的和未预料到的输入情况。
- 原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
- 原则7：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
- 原则8：计划测试工作时不应默许假定不会发生错误。
- 原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
- 原则10：软件测试是一项极富创造性，极具智力挑战性的工作。
《软件测试》读书笔记（持续更新）
《软件测试》读书笔记（持续更新）⽂章⽬录#第⼀部分 软件测试综述##第⼀章 软件测试的背景###1.1臭名昭著的软件错误⽤例研究###1.2软件缺陷是什么####1.2.1软件失败的术语确实严重，甚⾄是危险的情况：故障（fault）、失败（failure）、缺点（defect）不那么尖锐，主要指未按预料运⾏，⽽不指全部失败：异常（anomaly）、事件，插曲（incident）、偏差（variance）最常⽤的术语：问题（problem）、错误（error）、缺陷（bug）其他术语：⽭盾（inconsistency）、特殊（feature）软件测试中出现的其他术语：产品说明书（product specification）：简称为说明（spec）或产品说明（product spec）。
它对开发的产品进⾏定义，给出产品的细节、如何做、做什么、不能做什么。
这种协定从简单的⼝头说明到正式的书⾯⽂档有多种形式。
之后《软件开发的过程》会讲述产品说明书和开发过程中的更多内容。
在每个公司，不同的开发⼩组⾥会有不同的术语，但在⽤词上过多的计较是没有意义的。
在这本书中，所有的软件问题都被称为缺陷####1.2.2软件缺陷的官⽅定义 ☟⾄少满⾜下列5个规则之⼀才称发⽣了⼀个软件缺陷（software bug）1）软件未实现产品说明书要求的内容（产品说明书：计算器能够准确⽆误的进⾏加减乘除；按下（+）键，没有反应，或者得到错误答1）软件未实现产品说明书要求的内容（产品说明书：计算器能够准确⽆误的进⾏加减乘除；按下（+）键，没有反应，或者得到错误答案）2）软件出现了产品说明书指明不应该出现的错误（产品说明书：计算器永远不会崩溃、锁死或者停⽌反应；狂敲键盘，计算器停⽌接受输⼊）3）软件实现了产品说明书未提到的内容（计算器求加减乘除还可以求平⽅根，这也是缺陷，虽然有了更好，但会增加测试的⼯作，甚⾄带来更多的缺陷）4）软件未实现产品说明书虽未明确提及但应该实现的⽬标（⽬的为了捕获那些产品说明书上的遗漏之处。
《软件测试的艺术》精华摘要(六)
当程序无法实现其最终用户要求的合理功能时，就发生了一个软件错误。
软件开发过程在很大程度上是沟通有关最终程序的信息，并将信息从一种形式转换到另一种形式。
由于这个原因，绝大部分软件错误都可以归因为信息沟通和转换时发生的故障、差错和干扰。
1、将软件最终用户的要求转换为一系列书面的需求。
这些需求就是该软件产品要实现的目标。
2、通过评估可行性与成本、消除相抵触的用户需求、建立优先级和平衡关系，将用户需求转换为具体的目标。
3、将上述目标转换为一个准确的产品规格说明，将产品视为一个黑盒，仅考虑其接口以及与最终用户的交互。
该规格说明被称为“外部规格说明”。
4、如果该产品是一个系统，而不仅是一个程序，那么下一步骤就是系统设计。
该步骤将系统分隔为单独的程序、部件或子系统，并定义它们的接口。
5、通过定义每个模块的功能、模块的层次结构以及模块间的接口，来设计程序或程序集合的结构。
6、设计一份准确的规格说明，定义每个模块的接口与功能。
7、经过一个或更多的子步骤，将模块接口规格说明转换为每个模块的源代码算法。
需求规格说明定义了为什么要开发程序。
目标定义了程序要做什么，以及应做得怎样。
外部规格说明定义了程序对用户的准确表现。
与后续阶段相关的文档越来越详细地规定了程序是如何建立起来的。
模块测试的目的是发现程序模块与其接口规格说明之间的不一致功能测试的目的是为了证明程序未能符合其外部规格说明系统测试的目的是为了证明软件产品与其初始目标不一致6.1、功能测试功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。
外部规格说明是一份从最终用户的角度对程序行为的精确描述。
6.2、系统测试将系统或程序与其初始目标进行比较。
给定这个目标之后，隐含两方面的含义：1、系统测试并不局限于系统。
如果产品是一个程序，那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程。
2、根据定义，如果产品没有一组书面的、可度量的目标，系统测试也就无法进行。
软件测试的艺术(中文版而且很清晰) 未打印
The Art of Software TestingSecond EditionGlenford J. MyersRevised and Updated byTom Badgett and Todd M.Thomaswith Corey SandlerCopyright© 2004 by Word Association, Inc. All rights reserved.Published by John Wiley & Sons, Inc., Hoboken, New Jersey.Published simultaneously in Canada.整理：丁兆杰,黄墀晖,黄米青,林嘉,马晓靖,王博,吴航,余华兵,俞培源v.1.2 7/1/2008前言1979年Glenford J.Myers出版了一本现在仍被证明为经典的著作，这就是本书的第1版。
本书经受住了时间的考验，25年来一直被列在出版商可供书目的清单中。
这个事实本身就是对本书稳定、基础和珍贵品质的佐证。
在同一时期，本书第2版的几位合著者共出版了120余本著作，大多数都是关于计算机软件的。
其中有一些很畅销，再版了多次（例如Corey Sandler的《Fix Your Own PC》自付印以来已出版到第7版，Tom Badgett关于微软PowerPoint及其他Office组件的著作已经出版到第4版以上）。
然而，这些作者的著作中没有哪一本书能够像本书一样持续数年之后仍畅销不衰。
区别究竟在哪里呢？这些新书只涵盖了短期性的主题：操作系统、应用软件、安全性、通信技术及硬件配置。
20世纪80年代和90年代以来的计算机硬件与软件技术的飞速发展，必然使得这些主题频繁地变功和更新。
在此期间出版的有关软件测试的书籍已数以十计、甚至数以百计。
这些书也对软件测试的主题进行了简要的探讨。
然而，本书为计算机界一个最为重要的主题提供了长期、基本的指南：如何确保所开发的所有软件做了其应该做的，并且同样重要的是，未做其不应该做的？本书第2版中保留了同样的基本思想。
《软件测试(第2版)》读书笔记模板
目录分析
1.1软件、软件危机 和软件工程
1.2软件缺陷与软件 故障
1.3软件质量与质量 模型
1.4软件测试
1.5软件测试人 员的基本素质
习题1
1.1.1软件、软件危机和软件工程的基本概念 1.1.2软件工程的目标及其一般开发过程 1.1.3软件过程模型
1.4.1软件测试的概念 1.4.2软件测试的原则 1.4.3软件测试过程模型 1.4.4软件测试的分类 1.4.5软件测试流程 1.4.6软件测试发展历程和发展趋势
1
2.1软件测试 计划的作用
2
2.2制订测试 计划的原则
3
2.3如何制订 软件测试计划
4 2.4制订测试
计划时面对的 问题
5
2.5衡量测试 计划的标准
2.6制订测试计 划
习题2
1
3.1软件测试 技术概述
2
3.2白盒测试 技术
3
3.3黑盒测试 技术
4
3.4灰盒测试 技术
5
习题3
3.2.1静态测试 3.2.2程序插桩 3.2.3逻辑覆盖 3.2.4基本路径测试 3.2.5其他白盒测试方法 3.2.6白盒测试应用策略
习题8
1
9.1 Web应用 测试概述
2
9.2 Web应用 的性能测试
3
9.3 Web应用 的功能测试
4
9.4 Web应用 的界面测试
5 9.5 Web应用
的客户端兼容 性测试
9.6 Web应用 的安全性测试
习题9
9.2.1 Web性能测试的主要术语和性能指标 9.2.2 Web性能测试的目标和测试策略 9.2.3 Web应用系统性能测试人员应具有的能力 9.2.4 Web应用系统性能测试的种类 9.2.5 Web应用系统性能测试规划与设计 9.2.6 Web应用系统全面性能测试模型 9.2.7 Web应用系统性能测试流程
软件项目的艺术_随笔
《软件项目的艺术》阅读随笔目录一、内容描述 (2)1. 软件项目的重要性 (3)2. 软件项目管理面临的挑战 (4)二、软件项目策划阶段 (4)1. 明确项目目标 (6)2. 制定项目计划 (7)3. 分析项目风险 (9)三、软件项目设计阶段 (10)1. 设计项目架构 (12)2. 设计系统界面 (13)3. 设计数据库结构 (14)四、软件项目编码阶段 (15)1. 编写代码 (17)2. 代码审查 (17)3. 问题解决与调试 (19)五、软件项目测试阶段 (21)1. 测试计划制定 (22)2. 执行测试用例 (23)3. 缺陷追踪与修复 (25)六、软件项目部署阶段 (27)1. 部署环境准备 (28)2. 上线前的最终测试 (29)3. 系统上线与监控 (30)七、软件项目收尾阶段 (31)1. 项目总结与评估 (33)2. 项目经验教训分享 (35)3. 后期维护与优化 (36)八、结语 (37)1. 软件项目管理的艺术性 (39)2. 持续改进与创新的重要性 (40)一、内容描述在软件开发的世界里，每一个项目都如同一件艺术品，充满了创意与挑战。
当我翻开《软件项目的艺术》我仿佛进入了一个全新的世界，被其中关于软件项目管理的深刻见解所吸引。
书中详细描述了软件项目的开发过程，从需求分析、设计、编码到测试、部署和维护，每一个环节都充满了智慧和策略。
作者强调了项目管理的重要性，认为一个成功的软件项目离不开周密的计划和执行。
在阅读过程中，我特别被作者对于团队协作和沟通的阐述所打动。
在软件项目中，团队成员之间的协作和沟通至关重要。
只有通过有效的沟通，才能确保项目的顺利进行。
作者提供了一些实用的沟通技巧和方法，帮助读者更好地与团队成员协作，共同完成项目目标。
书中还谈到了风险管理、质量保证等方面的问题。
这些都是在软件项目中不可避免的挑战，作者通过丰富的案例和经验分享，为读者提供了应对这些挑战的策略和思路。
《软件测试的艺术》阅读整理（二）
《软件测试的艺术》阅读整理（⼆）第三章代码检查、⾛查与评审编写的代码⼀开始时，只是给机器执⾏的，并没有想着供⼈们阅读，到了20世纪的70年代，⼀些程序员才开始意识到阅读代码对于完善软件测试和调试的价值。
到了今天，并不是所有的软件测试⼈员都要阅读代码，但是去研读程序的代码也是测试⼯作的⼀部分，已经得到了⼴泛的认同了。
3.1 影响到特定的测试和调试⼯作需要⼈⼯实际阅读代码可能性的⼏个因素：1. 软件测试规模和复杂度2. 软件开发团队的规模3. 软件开发的时限（例如时间安排表是松散还是紧张）4. 编程⼩组的技术背景和⽂化等3.2 ⼈⼯测试⼈⼯测试技术在查找错误⽅⾯⾮常有效，以⾄于任何编程的项⽬都应该使⽤其中的⼀种或是多种的技术来测试。
在程序开始编码前前期，中期，后期都可来进⾏设计测试。
重要的注意事项：由于包含了⼈为的因素在内，导致很多⽅法的正规性要差于由计算机执⾏的数学证明，我们可能会去怀疑有些简单和不正规的东西是不是有⽤。
反之，这些不正规的⽅法并没有影响到测试取得成功；相反，它们还从以下两个⽅⾯显著的提⾼了测试的功效和可靠性：1. 我们通常认为错误发现的越是早，改错误的成本会越低，正确的改正错误的可能性也越⼤2. 程序员在开始基于计算机的测试时似乎会经历⼼理上⼀个转变。
从程序⼈员⾃⾝的内部压⼒似乎会越来越⼤，产⽣⼀个想法，要：“尽可能的修复这个缺陷”。
由于这些压⼒⼤的存在，程序员在改正某个Bug时，要⽐改正早期发现的问题时所犯的失误会更多⼀些。
3.3 检查与⾛查代码检查和⾛查都是⼈⼯检测的⽅法。
这种测试技术在编码之后计算机测试之前使⽤，要求⼈们组成⼀个⼩组来阅读和检查程序，可以有效的在项⽬早期发现错误，并改正错误。
代码检查和代码⾛查有以下的相同点：1. 组成⼩组来阅读或直观检查特定的程序2. 在代码⾛查中，⼀组开发⼈员（3-4⼈最佳）对代码进⾏审核。
参加者当中只有⼀⼈是程序编写者。
3. 代码检查与⾛查是对过去桌⾯的检查过程（在提交测试前程序员阅读⾃⼰的程序的过程）的改进。
《软件测试》Ron Pantton读书笔记
第1章软件测试背景1.1 臭名昭著的软件错误案例研究1.1.1 迪斯尼的狮子王，1994~1995没有对市场上投入使用的各种PC机型进行正确的测试1.1.2 英特尔奔腾浮点除法软件缺陷，1994这个故事重要的不是软件缺陷，而是英特尔解决问题的方式：1.他们的软件测试工程师在芯片发布之前进行内部测试时发现了这个问题，英特尔的管理层认为这没有严重到要保证修正，甚至公开；2.当软件缺陷被发现时，英特尔通过新闻发布和公开声明试图掩饰这个问题的严重性；3.受到压力时，英特尔承诺更换有问题的芯片，但要求用户必须证明自己受到软件缺陷的影响。
由于这个缺陷，英特尔公开道歉并拿出了4亿多美元来致富更换坏芯片的费用。
（代价惨重呀，汗！）1.1.3 美国航天局火星极地登陆，1999由多个小组测试该项目，各自分工不同，但就是中间空隙出错了。
1.1.4 爱国者导弹防御系统，1991系统时钟错误积累起来拖延100多个小时。
1.1.5 前年虫，大约1974当时发现错误但没有修改，只是着重眼前的任务，不去考虑2000年的兼容问题，导致损失过亿。
1.2 软件缺陷是什么1.2.1 描述软件失败的术语缺点（defect）谬误（fault）问题（problt）错误（error）毛病（incident）异常（anomaly）偏差（variance）失败（failure）矛盾（incosistency）特殊（feature）缺陷（bug）怎样描述测试结果根据开发小组的个性1.2.2 软件缺陷：正式定义1.软件未达到产品说明书标明的功能；2.软件出现了产品说明书指明不会出现的错误；3.软件功能超出产品说明书指明范围；4.软件未达到产品说明书虽未指出但应达到的目标；5.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
注意：作为测试人员，在运用第5条测试规则时应记住要编写令所有用户都喜欢的软件是不可能的，但是最好能全面地客观评价，做到合情合理。
软件测试的艺术
6.1 功能测试 6.2 系统测试 6.3 验收测试 6.4 安装测试 6.5 测试的计划与控制 6.6 测试的结束准则 6.7 独立的测试机构
功能测试 功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。 外部规格说明是一份从最终用户的角度对程序行为的精确描述。
系统测试 系统测试最容易被错误理解，也是最困难的测试过程。系统测 试并非是测试整个系统或程序功能的过程，因为有了功能测试， 这样会显得多余。系统测试有着特定的目的：将系统或程序与 其初始目标进行比较。给定这个目标之后，隐含两方面的含义： 1. 系统测试并不局限于系统。如果产品是一个程序，那么系统 测试就是一个试图说明程序作为一个整体是如何不满足其目标 的过程。 2. 根据定义，如果产品没有一组书面的、可度量的目标，系统 测试也就无法进行。
判定表设计用例的步骤： 1.确定条件桩（输入项）和动作桩（输出项） 2.构建判定表（条件项1的取值*条件项2的取值*条件项3的取值） 3.填写动作项 4.对判定表进行合并/化简 合并的原则：动作桩完全相同，条件项只有一个不相同，可以考虑合 并合并有风险，因为减少了用例，破坏了原有的规则。所以一般来说 条件项小于8个，不建议合并。 5.去除无效的组合
2.3 软件测试的原则
原则l： 测试用例中一个必需部分是对预期输出或结果的定义。 原则2： 程序员应当避免测试自己编写的程序． 原则3： 编写软件的组织不应当测试自己编写的软件． 原则4： 应当彻底检查每个测试的执行结果。 原则5： 测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当 根据无效和未预料到的输入情况。 原则6： 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半 是检查程序是否“做了其不应该做的”。 原则7： 应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。 原则8： 计划测试工作时不应默许假定不会发现错误。 原则9： 程序某部分存在更多错误的可能性，与该部分已发现错误的数目成 正比。 原则10 软件测试是一项极富创造性、极具智力挑战性的工作。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
The Art of SoftWare Testing》读书笔记（1）_引子有关自己与软件测试之间的渊源而言，获悉这个领域的时间不长，接触的时间就更可谓短暂，但仔细想来，还要从大学期间说起比较好。
软件测试这个概念第一次出现在我的眼前时，是大四上学期开的软件工程这个科目中所涉及到的一点点。
由于某些因素，使我在大学期间忽略了对测试领域相关知识的储备。
第二次面对它时，是考研复习准备阶段。
那时，我对测试这个领域也仅仅只是知道，就是中文书面表达的“测试”这两个汉字的含义而已。
工作的前两年里，或许是因为从事的是有关算法方面性质的工作，所以并未对测试这个领域给予过多的关注，还好，或多或少还是接触到了一些。
直到最近一年多来，由于一个大型项目人手不够的缘故，所以临时从自己负责的另一个研究项目中抽过来（刚好该项目阶段性完成），负责有关此项目的测试部署与规划。
而这个时候，才能说是：真正意义上接触到了软件测试这个领域。
虽然，在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。
但，从这个项目阶段性结束后自己的体会而言，给我感悟最深的还是有关软件测试这个领域的。
通过在这个项目里的工作，让我真正体会到了：软件测试是一门艺术。
恰恰也是因为这个缘故，这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。
《The Art of SoftWare Testing》读书笔记（2）_前言喜欢在网上书店中遛达，看到不错的书就买下。
为什么不去书店？一个字，懒呗！总觉得，有那去书店的时间，完全可以好好睡一美觉，亦或可亲手烹制一顿美味可口的美食。
哎，反正就是，懒得走出家门去逛街！恰巧，此次浏览书籍时，无意间看到了《The Art of Software Testing》这本书。
在看了大家所给予它极高的评价留言后，虽然有些疑惑（毕竟这个时代，枪手太多了！），但我深信：一本书能够“活”25年，应该还是很不简单的。
于是，就半信半疑的订购了这本书，期望能够从这本书中获悉到有用的知识，来丰富一下自己面对这个领域时的贫乏困境，亦作为知识储备。
晕，这么薄！这是我拿到这本书后的第一反应。
真的！没有预料到这书会这么薄！原以为这本经典的书，会诸如《C++ Primer》、《The C++ Programming Language》、《Programming Windows》等这些著作那么厚。
而当翻看了几章后，觉得确实很经典，也明白了为什么这本书会“活”了25年。
于是，就诞生了我对这本书的第二感觉：薄而精！看来是需要自己多花些时间去慢慢的品味，这样才方可体味到最纯最美的底酝。
打住自己对这本书的侃侃而谈（怕跑题太远，拽不回来），还是关注一下软件测试这个领话题吧！软件测试，怎么说呢？就自身经历而言，确实如书上所说：测试依然是软件开发中的“黑色艺术”。
大学期间，计算机课程开的不少，没听说有专门开一门关于测试的课程。
所以，在学生阶段，测试就属于是个被抛弃掉的名词！毕业时，不是做软件就是去搞网络，没有听到一个同学去应聘测试的！工作中，有专门的测试组（或部门），就更不用自己怎么上心去研究了！如今的氛围就是：红的够红，黑的够黑！那叫一个“专”！哎，为什么不实行“两手都要抓，两手都要硬”的政策呢（一己之见，偏颇在所难免）？或许，我还不明白：“术业有专攻”的深刻含义吧！算了，最后还是谈谈对这本书的总观吧！1.该书是针对测试这一主题进行的实践探讨，而不是理论研究，顺便捎带了些对新的语言和过程的探讨；2.前言中提到了一个最为重要而又是长期、基本的指南：如何确保所开发的所有软件做了其应该做的，并且同样重要的是，未做其不应该做的？3.引言里指出一条著名的经验：即在一个典型的编程项目中，软件测试或系统测试大约占用50%的项目时间和超过50%的总成本。
《The Art of SoftWare Testing》读书笔记（3）_一次自我检测有创意！这是我对该书第一章的评价，也是唯一一次在看新书开篇时，能够把第一章给透透彻彻看完的。
为何？还不是实在不能恭维有些书籍在开篇就进行枯燥而繁多的总结性、介绍性的文字。
虽心里也清楚这些文字存在的重要性。
但每每，还总是先粗略瞄过，在通读全书后，才会再次认认真真的看那些文字（这时，才真的能感悟到“提纲携领”的中文含义啊）。
创意在于：它只通过展示一次自评价测试，就能吸引我的眼球，并涌出一种想继续向下读的冲动；更能引起对自身一些有关逻辑思维（考虑欠周全、缜密，存在盲点）、联想能力（需拓展思维，要富于联想与想像，即：思维“活”起来）、角度问题（要巧妙转换角度）等方面，所可能存在的不足进行深思。
当然，能够引起深思的缘故，还不是在于那个评价测试嘛！提起来，汗颜！依据所谓的测试用例（即：特定的数据集合）自测试后，发现自己只能考虑到11项（总14项）需要测试的关键点。
文尾，谈谈作者对“软件测试”这个概念的定义吧。
所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。
软件应当是可预测且稳定的，是不会给用户带来意外惊奇的。
《The Art of SoftWare Testing》读书笔记（4）_初次探究“软件测试是一项技术性工作，但同时也涉及经济学和人类心理学的一些重要因素”，这是该书第二章中最吸引我的话，耐人深思。
而对于该章的内容，我个人觉得可概括为以下三个方面：o心理学角度：驳斥了一些社会普遍存在的错误认识，并给出了测试的正确定义及在含义上进行了延伸。
（用写文章上常用的术语来说，是：先破后立。
）o经济学角度：验证软件测试不能够发现“所有”的错误。
（术语是：各个击破。
）o归纳了软件测试中的一些基本原则（术语是：归纳与演绎。
），及三个重要的测试原则：1.软件测试是为发现错误而执行程序的过程；2.一个好的测试用例具有较高的发现某个尚未发现的错误的可能性；3.一个成功的测试用例能够发现某个尚未发现的错误。
文尾，值得一提的是：在本章能明显感到作者侧重于从心理学角度来分析一些潜在的问题。
The Art of SoftWare Testing》读书笔记（5）_心理学视角解析（上）先谈谈从心理学角度所需要分析的问题。
在章节的开始，作者就明确的给予了一个认知：要成功地测试一个软件应用程序，测试人员也需要有正确的态度。
在某些情况下，测试人员的态度可能比实际的测试过程本身还要重要。
并且，分析了现在社会上普遍存在的两种“本末倒置”的错误认识。
•针对程序员：一开始就把“测试”这个术语的定义搞错了。
所以可想而知，作者肯定要先破其错误的根源和弊端，然后再立其正确的认知，为了能更深入的理解和在实践上的把握，作者又对正确的认知给予了进一步延伸的阐述；•针对项目经理：针对测试方面而言，对“成功的”和“不成功的”的理解认识上的错误。
文尾，值得一提的是：作者在这引荐一个病人去医生那里看病的例子，于是将一些绕人的关系和原理，刹那间弄的清晰易懂了。
看来恰当适宜的举例还是比枯燥的讲解概念间的区别与联系要容易的多，也生动的多，并且使人也能理解的更加深刻。
《The Art of SoftWare Testing》读书笔记（6）_心理学视角解析（中）上次谈到了两个错误认识，那就继续这个话题吧。
先分析与项目经理有关的这个错误认识吧。
因为这个因素可能会导致一些在测试问题上的根本性错误的认识。
作者主要是从“成功的”和“不成功的”这两个方面来剖析的：•指明了错误认识的本源：“成功的测试”是指没有发现错误的测试用例；而“不成功的测试”是指发现了某个新错误的测试。
•明确正确认识的本质：如果在测试某段程序时发现了错误，而且这些错误是可以修复的，就将这次合理的设计和由此得到有效执行的测试称为是“成功的”；并对如果在本次测试中可以最终确定再无其他可查出的错误，同样也被称作是“成功的”；而对未能适当地对程序进行检查，且在大多数情况下，未能找出错误的测试被称为是“不成功的”。
•引荐病人去找医生看病的这一生动的例子，加以引申理解并给予了结论：能发现新错误的测试用例不太可能被认为是“不成功的”，相反，能发现错误就证明它是值得设计的。
一个“不成功的”测试用例，会使程序输出正确的结果，但不能发现任何错误。
细想：如果规划的测试用例是能使程序输出正确的结果，但不能发现任何错误的话，那是多么的可怕阿。
那么测试就等于没有测试，或者是在徒劳。
而潜在的错误还依然潜在，这会开发人员跟用户来说，都是有不小的隐患的。
这才真正认识到：发现测试真的是一门需要去潜心研究的艺术。
不仅仅是为了我们开发人员自己，也为了用户，更为了将来软件能够更好的维护跟升级。
《The Art of SoftWare Testing》读书笔记（7）_心理学视角解析（下）接着，来谈谈程序员方面会产生的错误认识吧！这个方面可能在具体实践中显的更重要。
由于作者在开篇就先把三个错误认识给摆到读者的眼前；然后就立马表明了其正确的定义，并给予了分析和对错误认识的驳斥。
洋洒洒的写了许多，条理上未免会有些混乱。
因此，我就按照自己理解的来小结一下吧！首先，测试的正确定义是：测试是为发现错误而执行程序的过程。
该定义暗示了两层含义：•软件测试是一个破坏性的过程，甚至是一个“施虐”的过程。
（就自己的亲身经历而言，大部分的开发人员在测试期间，对测试人员或多或少都会暂时产生一点厌烦或恐惧的心态。
主要是会让开发人员的代码改的面目全非的，且这个过程是反反复复的。
）•对于一个特定的程序，应该如何设计测试用例（测试数据）、哪些人应该而哪些人又不应该执行测试。
（这是有关测试人员构成的问题。
就自己的亲身经历而言，这一点很重要，因为测试人员的态度要比测试的过程更为重要。
）然后，明确测试的正确含义后，探究了一下现今面临的三个错误认识并逐一给予了充分的驳斥。
•“软件测试就是证明软件不存在错误的过程”。
1.若目的仅是为了证明程序中不存在错误，就会在潜意识中倾向于实现这个目标；即，会倾向于选择可能较少导致程序失效的测试数据；若目标在于证明程序中存在错误，设计的测试数据就有可能更多地发现问题。
后者肯定比前者会更多地增加程序的价值。
2.心理上，对于证明不存在是一个不可能完成的任务，无论该工程多么小；但若是一个寻找错误的任务，是可以完成的。
就心理承受而言，也是更容易接受的。
•“软件测试的目的在于证明软件能够正确完成其预订的功能。
”1.心态上，不要本着只是为了证明程序能够正确运行而去测试程序，而应该一开始就假设程序中隐藏着错误（这种假设对于几乎所有的程序都成立）。
这样测试程序时，才能够发现尽可能多的错误。
2.要清楚这样一个道理：每当测试一个程序，实质上是想为其增加一些价值。
通过测试来增加程序的价值，及是指测试提高了程序的可靠性或质量。