下载文档原格式
懒惰是很奇怪的东西，它使你以为那是安逸，是休息，是福气；但实际上它所给你的是无聊，是倦怠，是消沉;它剥夺你对前途的希望，割断你和别人之间的友情，使你心胸日渐狭窄，对人生也越来越怀疑。
—罗兰天才是百分之九十九的勤奋加百分之一的灵感The Art of SoftWare Testing》读书笔记（1）_引子有关自己与软件测试之间的渊源而言，获悉这个领域的时间不长，接触的时间就更可谓短暂，但仔细想来，还要从大学期间说起比较好。
软件测试这个概念第一次出现在我的眼前时，是大四上学期开的软件工程这个科目中所涉及到的一点点。
由于某些因素，使我在大学期间忽略了对测试领域相关知识的储备。
第二次面对它时，是考研复习准备阶段。
那时，我对测试这个领域也仅仅只是知道，就是中文书面表达的“测试”这两个汉字的含义而已。
工作的前两年里，或许是因为从事的是有关算法方面性质的工作，所以并未对测试这个领域给予过多的关注，还好，或多或少还是接触到了一些。
直到最近一年多来，由于一个大型项目人手不够的缘故，所以临时从自己负责的另一个研究项目中抽过来（刚好该项目阶段性完成），负责有关此项目的测试部署与规划。
而这个时候，才能说是：真正意义上接触到了软件测试这个领域。
虽然，在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。
但，从这个项目阶段性结束后自己的体会而言，给我感悟最深的还是有关软件测试这个领域的。
通过在这个项目里的工作，让我真正体会到了：软件测试是一门艺术。
恰恰也是因为这个缘故，这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。
《The Art of SoftWare Testing》读书笔记（2）_前言喜欢在网上书店中遛达，看到不错的书就买下。
为什么不去书店？一个字，懒呗！总觉得，有那去书店的时间，完全可以好好睡一美觉，亦或可亲手烹制一顿美味可口的美食。
哎，反正就是，懒得走出家门去逛街！恰巧，此次浏览书籍时，无意间看到了《The Art of Software Testing》这本书。
软件测试必备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）:一组相互协作的组件的集合，能够实现一个或多个测试域中的一系列问题的解决方案。
《软件评测师学习笔记一》二、软件测试基础1.度量。
命周期的过程。
2.软件测试只能证明软件有错误，不能证明软件没有错误；23要从软件在内部、外部和使用中的表现来衡量。
4.质量保证（QA QA跟进中；软件测试的重点不在于此，运行软件，以找出问题，报告质量。
软件测试不可能无休止地测下去，原因在于：123（关键在于对程序内部结构的态度上）6.进行测试寻找错误，而需求分析阶段隐藏的问题到后期的验收测试才被发现；优点是测试与开发过程是同步进行的，有利于测试的及早介入与执行；缺点是对开发阶段需要有明确的起点和终点，这点在实际情况中很难做到这点；复的。
只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。
针对单独程序片段进行互相分离的编码和测试，之后频繁的交接通过集成最终合成为可执行的程序。
特点：将开发和测试的生命周期整合在一起，对每一个交付的开发结果都进行一定方式的测试，设计阶段是做测试计划和测试设计的最好时机，程序片段一旦编写完成就会立即进行测试，让验收测试和技术测试保持相互独立。
8.1 所有的软件测试都应追溯到用户需求8.2尽早地和不断地进行软件测试8.3 完全测试是不可能的，测试需要终止8.4 测试无法显示软件潜在的缺陷8.5 充分注意测试中的群集现象8.6 程序员应避免检查自己的程序8.7 尽量避免测试的随意性9.测试模型的使用：灵活运用各种模型的优点，在W模型的框架下运行H模型的思想进行独立测试，并同时将测试和开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按其完成预订目标。
10.软件设计阶段的评审：10.1 需求评审《需求说明书评审规范》10.2 设计评审《概要设计说明书评审规范》和《详细设计说明书评审规范》10.3 编码评测《编码规范》11.软件开发阶段的测试：12345、11.2（又叫渐增式组装方式）、11.4 系统测试11.5 验收测试验收测试是以用户为主，软件开发人员和质量保证人员也应参加的测试。
吹风吹到疯：《软件测试的艺术》读书笔记《软件测试的艺术》在长假的第四个悠闲的中午，灭掉了《软件测试的艺术》这本书，好像最近看的号称“艺术”的书比较多，《生活的艺术》，《项目管理的艺术》还包括这本《软件测试的艺术》。
一般来说，在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、根据定义，如果产品没有一组书面的、可度量的目标，系统测试也就无法进行。
软件测试学习心得体会精品6篇软件测试学习心得体会篇1通过这次课程设计的实训，增加了我学习软件技术的兴趣，虽然还不明确软件技术包含的具体内容，但从C++语言这门课程开始，已发现程序设计的乐趣，在学习C++语言的过程中也学到了许多计算机应用基础知识，对计算机的机体也有了一个大体的了解。
在实际操作过程中犯的一些错误还会有意外的收获，感觉实训很有意思。
在具体操作中对这学期所学的C++语言的理论知识得到巩固，达到实训的基本目的，也发现自己的不足之出，在以后的上机中应更加注意，同时体会到C++语言具有的语句简洁，使用灵活，执行效率高等特点。
发现上机实训的重要作用，特别是对数组和循环有了深刻的理解。
通过实际操作，学会C++语言程序编程的基本步骤、基本方法，开发了自己的逻辑思维能力，培养了分析问题、解决问题的能力。
深刻体会到“没有做不到的，只有想不到的”，“团结就是力量”，“实践是检验真理的标准”，“不耻下问”的寓意。
在此希望以后应多进行这样的实训，加长设间，培养学生独立思考问题的能力，提高实际操作水平。
通过本次项目实训我要感谢学校领导给我们提供了这次机会，让我们自己有出去体会生活，自己做项目的深刻体会。
这次实训让我明白我自己之前的学习还是差很多，只有不断的努力，才能学好。
还要感谢达内公司对我的指导，我自己的努力固然重要，但是达内的优秀教师给我做的培训，讲的理论都让我受益匪浅，让我对软件有了一个新的概念新的理解。
软件测试学习心得体会篇2大三的时候，一次计算机等级考试，由于考c，数据库，都没过，就报了个四级软件测试工程师。
抱着试试看的态度学了一个月做了几套题，就拿下了一个四级证书。
当时想的是，这都行，水分有点大吧……本来想找一份网站开发的工作，技术不够硬，一直在北京飘着飘着啊。
通过一个学姐，得到了一个软件测试面试的机会。
于是半只脚踏入了软件测试的大门，因为我现在刚开始写测试用例，还没有真正的融入到团队中去。
实习生，直接领导给我安排了一个实习计划，严格按照实习计划执行。
软件测试方法与技术的学习笔记软件测试从不同的角度出发会派生出两种不同的测试原那么，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以承受该产品，从开发者的角度出发，就是希望测试能说明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。
测试的原那么就是从用户和开发者的角度出发进展软件产品测试的，通过测试，可以为用户提供放心的产品，并对优秀的产品进展认证。
为了到达上述的原那么，那么需要注意以下几点：1．应当把“尽早和不断的测试”作为开发者的座右铭2．程序员应该防止检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比方网络异常中断、电源断电等情况。
4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进展讨论和分析。
6．制定严格的测试方案，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档在测试实施之前，软件测试工程师必须确定将要采用的测试策略和测试方法，并以此为依据制定详细的测试案例。
而一个好的测试策略和测试方法必将给软件测试带来事半功倍的效果，它可以充分利用有限的人力和物力资源，高效率、高质量地完成测试。
那么，终究如何才能确定一个好的测试策略和测试方法呢，一般来说，在确定测试方法时，应该遵循以下原那么：第一，要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点；第二，要认真研究测试策略，以便能使用尽可能少的测试用例，发现尽可能多的程序错误，因为一次完整的软件测试过后，如果程序中遗留的错误过多并且很严重，那么说明本次测试是失败的，是缺乏的，而测试缺乏意味着让用户承当隐藏错误带来的危险，同时反过来说如果过度测试那么又会浪费许多珍贵的资源。
软工学习资料推荐软件工程（Software Engineering）是一门研究和应用如何以系统化和规范化的方法去构建、运行、维护和管理软件的学科。
对于软件工程学习者来说，掌握优质的学习资料是非常重要的，它们可以帮助我们深入了解软件工程的理论和实践，提升我们的编程能力和项目管理技巧。
本文将向广大软工学习者推荐一些值得阅读的软工学习资料。
一、软件工程导论1. 《软件工程导论》（Introduction to Software Engineering）- Ian Sommerville这本书是软件工程学习的经典教材，已经成为了许多大学软工专业的教材之一。
作者通过清晰简洁的语言，详细介绍了软件工程的各个方面，包括软件开发过程、需求分析、软件设计、软件测试等。
它不仅适合软件工程专业的学生，也适合其他对软工感兴趣的读者。
2. 《软件工程：实践者的研究方法》（Software Engineering: A Practitioner's Approach）- Roger S. PressmanPressman的这本书是软件工程领域的经典著作之一，对软件开发的整个过程进行了深入的介绍和剖析。
书中包含丰富的案例和实践经验，让读者能够更好地理解软件工程中的实际问题和解决方法。
二、软件需求工程1. 《软件需求工程》（Software Requirements Engineering）- Karl Wiegers、Joy Beatty这本书主要介绍了软件需求工程的理论和实践。
作者通过大量的示例和案例，详细讲解了如何正确地进行需求分析和需求管理，以及如何定义和验证软件需求。
对于从事软件需求工程的工程师和项目经理而言，这本书是一本不可或缺的好资料。
2. 《需求工程：基础》（Requirements Engineering: Fundamentals）- Klaus Pohl、Chris Rupp本书系统地介绍了需求工程的基本概念和方法，帮助读者全面理解需求工程的整个过程。
天才是百分之九十九的勤奋加百分之一的灵感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.要清楚这样一个道理：每当测试一个程序，实质上是想为其增加一些价值。
通过测试来增加程序的价值，及是指测试提高了程序的可靠性或质量。
