2011-学习资料大全：《软件测试的艺术》读书笔记
Nwfads2011-学习资料大全：《软件测试的艺术》读书笔记
懒惰是很奇怪的东西，它使你以为那是安逸，是休息，是福气；但实际上它所给你的是无聊，是倦怠，是消沉;它剥夺你对前途的希望，割断你和别人之间的友情，使你心胸日渐狭窄，对人生也越来越怀疑。
—罗兰天才是百分之九十九的勤奋加百分之一的灵感The Art of SoftWare Testing》读书笔记（1）_引子有关自己与软件测试之间的渊源而言，获悉这个领域的时间不长，接触的时间就更可谓短暂，但仔细想来，还要从大学期间说起比较好。
软件测试这个概念第一次出现在我的眼前时，是大四上学期开的软件工程这个科目中所涉及到的一点点。
由于某些因素，使我在大学期间忽略了对测试领域相关知识的储备。
第二次面对它时，是考研复习准备阶段。
那时，我对测试这个领域也仅仅只是知道，就是中文书面表达的“测试”这两个汉字的含义而已。
工作的前两年里，或许是因为从事的是有关算法方面性质的工作，所以并未对测试这个领域给予过多的关注，还好，或多或少还是接触到了一些。
直到最近一年多来，由于一个大型项目人手不够的缘故，所以临时从自己负责的另一个研究项目中抽过来（刚好该项目阶段性完成），负责有关此项目的测试部署与规划。
而这个时候，才能说是：真正意义上接触到了软件测试这个领域。
虽然，在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。
但，从这个项目阶段性结束后自己的体会而言，给我感悟最深的还是有关软件测试这个领域的。
通过在这个项目里的工作，让我真正体会到了：软件测试是一门艺术。
恰恰也是因为这个缘故，这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。
《The Art of SoftWare Testing》读书笔记（2）_前言喜欢在网上书店中遛达，看到不错的书就买下。
为什么不去书店？一个字，懒呗！总觉得，有那去书店的时间，完全可以好好睡一美觉，亦或可亲手烹制一顿美味可口的美食。
哎，反正就是，懒得走出家门去逛街！恰巧，此次浏览书籍时，无意间看到了《The Art of Software Testing》这本书。
软件测试的艺术
（6）误区之六：软件测试是没有前途的工作，只有程序员才是软件高手
由于我国软件整体开发能力比较低，软件过程很不规范，很多软件项 目的开发都还停留在“作坊式”和“垒鸡窝”阶段。项目的成功往往靠个 别全能程序员决定，他们负责总体设计和程序详细设计，认为软件开发就 是编写代码，给人的印象往往是程序员是真正的牛人，具有很高的地位和 待遇。因此，在这种环境下，软件测试很不受重视，软件测试人员的地位 和待遇自然就很低了，甚至软件测试变得可有可无。随着市场对软件质量 的不断提高，软件测试将变得越来越重要，相应的软件测试人员的地位和 待遇将会逐渐提高。在微软等软件过程比较规范的大公司，软件测试人员 的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至比程序员 还要高。软件测试将会成为一个具有很大发展前景的行业，软件测试大有 前途，市场需要更多具有丰富测试技术和管理经验的测试人员，他们同样 是软件专家。这两年来国内软件测试人员的需求不断增大,越来越多的IT企 业认识到了软件测试的重要性,这种可喜的现状与发展趋势让笔者对我国软 件业的发展重新抱有较大的希望。
Summary
尽管这是一门崭新的学科,目前在国内的发展仍处于"婴儿"阶
段,但看到越来越多的软件公司为软件测试招兵买马,看到越来越
多的技术人员投入到软件测试中,我就情不自禁地感叹:机会来了! 这机会不仅仅是某一个人的,而是所有人的,它对每个人都是公平
的,学的领域需要新的理论新的工具新的方法,由于国内的软件测
件项目实施过程中的重要性日益突出。但是，现实情况是，与软件 编程比较，软件测试的地位和作用，还没有真正受到重视，对于很
多人（甚至是软件项目组的技术人员）还存在对软件测试的认识误
区，这进一步影响了软件测试活动开展和真正提高软件测试质量。
软件测试_读书笔记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）:一组相互协作的组件的集合，能够实现一个或多个测试域中的一系列问题的解决方案。
2011软考软件评测师笔记整理
《软件评测师学习笔记一》二、软件测试基础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篇
软件测试学习心得体会精品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 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应用系统性能测试流程
《软件测试的艺术》阅读整理（二）
《软件测试的艺术》阅读整理（⼆）第三章代码检查、⾛查与评审编写的代码⼀开始时，只是给机器执⾏的，并没有想着供⼈们阅读，到了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 软件测试是一项极富创造性、极具智力挑战性的工作。
测试方法读书笔记
读书笔记--软件测试(11)--黑盒测试案例设计技术--等价类划分法什么是测试用例所谓的测试用例设计就是将软件测试的行为活动，作一个科学化的组织归纳。
软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。
软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。
基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。
简单地说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。
如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件测试人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。
软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内，软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已修改完成。
因为我们不可能进行穷举测试，为了节省时间和资源，提高测试效率，必须要从数据量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。
使用测试用例的好处主要体现在以下几个方面：①在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
②测试用例的使用令软件测试的实施重点突出，目的明确。
③在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度，缩短项目周期。
④功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化，其效率也不断攀升。
下面将具体介绍几种常用的黑盒测试用例设计方法。
等价类划分法等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的要求和说明，即需求规格说明书。
我们必须仔细分析和推敲说明书的各项需求，特别是功能需求。
软件测试的心得体会7篇
软件测试的心得体会7篇心得体会是一种分享和倾诉的方式，可以让我们与他人建立更深层次的连接和理解，在写心得体会时，我们应该用自己的语言表达，而不是简单地抄袭他人的观点，网作者今天就为您带来了软件测试的心得体会7篇，相信一定会对你有所帮助。
软件测试的心得体会篇1软件测试方法和技术》这门课程，还是由张建东老师教我们的。
在张老师的讲解下，我深刻的体会到软件测试是很有必要的。
一个软件，从最开始的可行性分析、需求分析、概要设计、详细设计、编写代码。
这一系列的开发之下。
千辛万苦的，花费了大量的人力物力、金钱时间，终于把软件给做出来了。
你试着想一下，要是送到客户的手上，客户突然发现，软件用不了，或者是软件存在很大的缺陷。
导致软件不好用、甚至比原先没有这个软件，还麻烦了。
客户是很愤怒的。
客户一愤怒，就导致客户不会付钱。
这最终，项目失败，造成资源的大量浪费，所以说软件测试还是很有必要的。
再者就是，软件测试可以发现软件的缺陷，从而通知编程人员不断改进软件。
在这样不断测试，不断改进的情况下。
将软件性能不断提高，软件变得越来越好用。
软件测试，旨在发现软件的缺陷。
可以这样说，软件测试就是以发现软件缺陷，为最终目的'的测试活动。
它通过软件测试方法，白盒的、黑盒的、静态的或是动态的。
借助软件测试工具，来找到缺陷。
然后在缺陷评审和确认之后将缺陷记录下来，并用缺陷管理工具管理，详细描述，关注软件缺陷的发生周期。
对它的严重性、和优先级下一个定义。
书写软件缺陷报告，具名缺陷的重现步骤、测试的期望结果与实际结果、还有相关图片、文字资料。
提交给软件编程人员，来完成软件缺陷的修复。
软件测试的方法，包括：白盒测试和黑盒测试。
其中，白盒测试之中，有含有：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖、等方法。
黑盒测试方法中，有：等价类划分法、边界值分析法、判定表法、因果图法等。
软件测试方法，按照是否运行代码来看，可以分为：静态测试和动态测试。
软件测试学习笔记
软件测试学习笔记之一/软件测试概述一、什么是软件测试？简单的说，如果你写了一段代码，我来帮你查看代码并找出里面的错误，这就是测试。
IEEE的定义：―使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
‖有位大师曾说过：―软件测试的目的在于发现错误，一个好的测试用例在于发现从来未发现的错误，一个成功的测试是发现了从未发现的错误的测试。
‖二、常见导致软件错误的根源1、缺乏有效的沟通，甚至根本就没有进行沟通。
2、软件复杂度过大。
3、编程出现错误。
4、不断变更的需求，项目失败的最大杀手。
5、时间的压力，为了赶时间交付，错误也就伴随发生了。
6、缺乏文档的代码。
7、软件开发工具本身存在问题。
8、人员过于自信。
三、软件测试中的误区1、测试和调试是一样的。
2、测试组的人应当为保证质量负责。
3、过分依赖Beta测试。
4、把测试作为新员工的一个过渡工作。
5、把不合格的开发人员安排做测试工作。
6、关注与测试的执行而忽略测试的设计。
7、测试自动化是万能的。
8、测试时可以穷尽的。
9、测试是为了证明软件的正确性。
10、测试是枯燥乏味，缺乏创造力的工作。
软件测试是一种检测手段，目的是为了寻找软件系统中的缺陷。
业界越来越多的公司已经意识到软件测试的重要性，并在测试方面加大了投入。
软件测试有很多误区，只有认识到了这些误区才能真正理解测试本身的含义，才能以正确的态度看待测试。
软件测试学习笔记之二/白盒测试与黑盒测试一、为什么要进行白盒测试？1、逻辑错误和不正确假设与一条程序路径被执行可能性成反比。
当我们设计和实现主流之外的功能、条件和控制时，错误往往开始出现在我们的工作中。
日常处理往往能被很好的理解，而―特殊情况‖的处理则难于发现。
2、我们经常相信某个逻辑路径不可能被执行，而事实上，它可能在正常的情况下被执行。
程序的逻辑流有时候是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路经测试才能发现这些错误。
心得体会 软件测试心得体会(精选5篇)
软件测试心得体会（精选5篇）软件测试心得体会（精选5篇）关于软件测试的心得体会虽然一如继往地写读书笔记，笔墨也浪费了不少。
但真正坐下来利用大段的时间将自己的思路理清还没有过。
因为最近有了一定的时间,更因为狠狠地泡了一段时间51Testing测试论坛,下载学习了该网站的电子测试杂志之后，自己的思路终于开始清晰起来，朦朦胧胧地开始看清了远方的路,麻着胆子去分析一下自己,也学着展望一下未来了,毕竟摸黑走路的感觉很不好。
我觉得学习软件测试的通用技术与针对某类软件的测试技术外,还有一个重要的与技术无关的方面:业务知识.没有具体的业务知识很难发现软件中潜在的逻辑错误甚至是需求上的错误,当然需求要依据特定的软件,但软件测试人员对需求理解的深入程度不应低于软件开发的人员.因为软件测试所有的依据来自于需求,而所有的需求来自于客户,甚至是我们的全部都来自于客户.识别需求后还必须转化为测试上的需求,毕竟测试人员看需求的角度和开发人员还是有区别的.关于学习，我知道我并非计算机专业的学生,初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。
但是,总该知道如何去学习，然而我认为，学习总该有必要的方法1.找个好师傅这是最重要的一条了,也是公司提供的最好的一个条件.刚进来的时候,td,测试案例都有一个pm细心的和你讲,案例有什么方法来设计?要注意哪些错误?软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，一大堆的东西马上够你头晕的了.呵呵,还好,悟性不错,都囫囵吞枣地吞下去了.2.学会读书无论是神马专业，我始终确信，万变不离其宗，我知道，我不是这个专业的，但这个并不代表这我就不了解这个，再怎么不济，我也是从书本中走出来的，我相信，只要我努力地吧书本啃熟，我能够灵活地融入到这个职业中去，从书本中找寻解决问题的方法。
标记出自己所错误的。
3.与前辈们一起讨论，多说总有一天，我们会成为一位前辈，不过不是现在，至少现在我们应该好好的向别人学习，所以，我觉得，前辈是我们前进道路上不可或缺的一部分，他会成为引领我们前进的发动机，给我们指点，跟我们道工作的经验。
- 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.要清楚这样一个道理：每当测试一个程序，实质上是想为其增加一些价值。
通过测试来增加程序的价值，及是指测试提高了程序的可靠性或质量。