软件测试的艺术(原书第3版)

软件测试的艺术(原书第3版) Glenford J.Myers Tom Badgett Corey Sandler 53个想法 ◆ 序言 >> 如何确保所开发的所有软件做了其应该做的，并且同样重要的是，未做其不应该做的？ ◆ 第1章 一次自评价测试 >> 所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。 ◆ 2.1 软件测试的心理学 >> 如果我们的目标在于证明程序中存在错误，我们设计的测试数据就有可能更多地发现问题 >> 软件测试是一个破坏性的过程，甚至是一个“施虐”的过程 >> 所谓“不成功的”测试，仅指未能适当地对程序进行检查，在大多数情况下，未能找出错误的测试被认为是“不成功的”，这是因为认为软件中不包含错误的观点基本上是不切实际的。 ◆ 2.2.1 黑盒测试 >> 黑盒测试是一种重要的测试策略，又称为数据驱动的测试或输入/输出驱动的测试。 ◆ 2.2.2 白盒测试 >> 白盒测试或称逻辑驱动的测试，允许我们检查程序的内部结构。 ◆ 2.3 软件测试的原则 >> 原则1：测试用例中一个必需部分是对预期输出或结果的定义。 >> 克服这种倾向的一种方法，就是通过事先精确定义程序的预期输出，鼓励人们对所有的输出进行仔细检查。 >> 原则2：程序员应当避免测试自己编写的程序。 >> 当程序员“建设性”地设计和编写完程序之后，很难让他突然改变视角以一种“破坏性”的眼光来审查程序。 >> 原则3：编写软件的组织不应当测试自己编写的软件。 >> 原则4：应当彻底检查每个测试的执行结果。 >> 原则5：测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。 >> 原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。 >> 原则7：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。 >> 保留测试用例，当程序其他部件发生更动后重新执行，这就是我们所谓的“回归测试”。 >> 原则8：计划测试工作时不应默许假定不会发现错误。 >> 原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。 >> 假如某个程序由两个模块、类或子程序A和B组成，模块A中已经发现了五个错误，而模块B中仅仅找到了一处错误。如果模块A所经过的测试并不是故意设计得更为严格，那么该原则告诉我们，模块A与模块B相比，存在更多错误的可能性要大。 >> 错误总是倾向于聚集存在，而在一个具体的程序中，某些部分要比其他部分更容易存在错误 ◆ 第3章 代码检查、走查与评审 过于心急而引入新的缺陷 >首先，人们普遍认识到错误发现得越早，改正错误的成本越低，正确改正错误的可能性也越大。其次，程序员在开始基于计算机的测试时似乎要经历一个心理上的转变。从内部产生的压力似乎会急剧增长，并产生一个趋势，要“尽可能快地修正这个缺陷”。由于这些压力的存在，程序员在改正某个由基于计算机测试发现的错误时所犯的失误，要比改正早期发现的问题时所犯的失误更多一些。 >> 首先，人们普遍认识到错误发现得越早，改正错误的成本越低，正确改正错误的可能性也越大。其次，程序员在开始基于计算机的测试时似乎要经历一个心理上的转变。从内部产生的压力似乎会急剧增长，并产生一个趋势，要“尽可能快地修正这个缺陷”。由于这些压力的存在，程序员在改正某个由基于计算机测试发现的错误时所犯的失误，要比改正早期发现的问题时所犯的失误更多一些。 ◆ 3.1 代码检查与走查 >> 代码检查、走查以及可用性测试是三种主要的人工测试方法。 每月月底进行一次桌面检查 >代码检查与走查是对过去桌面检查过程（在提交测试前由程序员阅读自己程序的过程）的改进。与原方法相比，代码检查与走查更为有效，同样是因为在实施过程中，除了软件编写者本人，还有其他人参与进来。 >> 程序中的错误总数始终是未知的。 >> 然而，一些测试人员在使用了人工方法之后发现，对于某些特定类型的错误，人工方法比基于计算机的方法更有效，而对于其他错误类型，基于计算机的方法更有效。这就意味着，代码检查/走查与基于计算机的测试是互补的。缺少其中任何一种，错误检查的效率都会降低。 ◆ 3.2.2 检查议程与注意事项 >> 这份错误清单也要进行分析、归纳，用以提炼错误列表，以便提高以后代码检查的效率 ◆ 3.2.3 对事不对人，和人有关的注意事项 >> 大多数人建议应对代码检查的结果进行保密，仅限于参与者范围内部 ◆ 3.2.4 代码检查的衍生功效 >> 其一，程序员通常会得到编程风格、算法选择及编程技术等方面的反馈信息。其二，其他参与者也可以通过接触程序员的错误和编程风格而同样受益匪浅。 ◆ 3.3.4 比较错误 >> 6.在二进制的计算机上，是否有用二进制表示的小数或浮点数的比较运算？ ◆ 3.3.6 接口错误 所有文档里的数字都要有单位 >3.实参的量纲是否与对应形参的量纲相匹配 >> 3.实参的量纲是否与对应形参的量纲相匹配？ ◆ 3.5 桌面检查 >> 它是一个完全没有约束的过程 ◆ 4.1 白盒测试 通过系统测试来覆盖 >因此，条件覆盖或判定/条件覆盖准则不一定会发现逻辑表达式中的错误 >> 因此，条件覆盖或判定/条件覆盖准则不一定会发现逻辑表达式中的错误 ◆ 4.2.1 等价划分 有效等价类可以一条测试用例测试多个目的，无效等价类一条测试用例尽量只用于测试一个目的。 >1.为每个等价类设置一个不同的编号。 2.编写新的测试用例，尽可能多地覆盖那些尚未被涵盖的有效等价类，直到所有的有效等价类都被测试用例所覆盖（包含进去）。 3.编写新的用例，覆盖一个且仅一个尚未被涵盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。 用单个测试用例覆盖无效等价类，是因为某些特定的输入错误检查可能会屏蔽或取代其他输入错误检查。举例来说，如果规格说明规定了“请输入书籍类型（硬皮、软皮或活页）及数量（1～999）”，代表两个错误输入（书籍类型错误，数量错误）的测试用例“XYZ 0”，很可能不会执行对数量的检查，因为程序也许会提示“XYZ是未知的书籍类型”，就不检查输入的其余部分了。 ◆ 第6章 更高级别的测试 >> 首先，我们可以使软件开发过程更加精密，以防其中出现很多错误；其次，在每个阶段结束时可以引入一个独立的验证过程，在进入下一个阶段之前尽可能多地发现问题。 ◆ 8.4 回溯法调试 >> 换句话说，从程序产生不正确结果（如打印了不正确的数据）的地方开始，从该处观察到的结果推断出程序变量应该是些什么值。在头脑中，从这个位置开始逆向执行程序，重复使用“如果程序在此处的状态是这样的，那么程序在上面位置的状态就必然是那样的”过程，就能很快定位出错误。 ◆ 8.5 测试法调试 >> 供测试的测试用例，其目的是暴露出以前尚未发现的错误；供调试的测试用例，其目的是提供有用的信息，供定位某个被怀疑的错误之用。 ◆ 8.6.1 定位错误的原则 >> 1.动脑筋 >> ·让自己置身于安静、没有干扰的环境之中，这些干扰通常指同事的谈话声、打电话、手机铃声以及其他潜在的干扰因素，确保这些不会分散你的注意力。·不看代码，在脑海中思考程序是怎么设计的，并思考表现异常的地方本应该是什么样的。·把注意力集中在思考程序正确行为的过程上，并想象那些可能导致错误设计的代码实现方式。 >> 2.如果遇到了僵局，就留到稍后解决 第二天写的代码明显比昨晚加班写的代码质量高 >如果在合理时间内（也许小型程序为30分钟，大一点的程序为几个小时），我们还不能定位某个问题，就丢开它，做些其他的事情，因为思维的效率开始明显下降。 >> 如果在合理时间内（也许小型程序为30分钟，大一点的程序为几个小时），我们还不能定位某个问题，就丢开它，做些其他的事情，因为思维的效率开始明显下降。 >> 3.如果遇到了困境，就把问题描述给其他人听与其他人交谈可能会帮助我们发现一些新的东西。事实上，经常是仅仅将问题描述给一个好的倾听者时，我们就会突然找到问题的解决之道，而无须倾听者提供任何帮助。 ◆ 8.6.2 修改错误的技术 >> 1.存在一个缺陷的地方，很有可能还存在其他缺陷 >> 2.应纠正错误本身，而不仅是其症状 >> 3.正确纠正错误的可能性并非100% >> 我们永远也不要假设为纠正错误而增加到程序中的代码是正确的。用新的语句替换原来的语句，这种修改要远比程序中原先的代码更易发生错误。 >> 4.随着程序规模的增加，正确修改错误的可能性反而降低 >> 5.应意识改正错误会引入新错误的可能性 >> 6.修改错误的过程也是临时回到设计阶段的过程

不懂软件开发，也不懂软件测试。这个周末快速学习了本书。从几个方面都值得推荐：一，项目管理，尤其项目复杂到一定程度，而质量的重要性又生死攸关时；二，对于复杂技术的质量的管控，这点可以稍微展开一点，近年来几个概念非常热，包括元宇宙，数字孪生，工业软件，甚至大模型。这几个概念，都涉及对复杂的物理世界的建模。建模的质量，受限于数据的可获取性，开发人员的知识结构和能力，大模型对常识和因果关系的欠缺等等因素。从验证的角度，确保模型的缺陷及早发现，从而获得质量的提升，是非常关键的一环。本书从相对成熟的软件测试的领域提炼出的方法论，技术，和流程，对于上述的更广泛的事项的质量提升，具有很强的参考意义，值得进一步细读

举例的编程语言有点过时，如cobol语言，但是测试知识还是值得一看。

很基础的一本书，系统例子也有点老，不过测试方法论真是几十年没变了。

很经典的软件测试书籍。 用通俗易懂的语言表达测试场景和测试方法。对软件测试感兴趣的朋友可以阅读学习。

在阅读《软件测试艺术》这本书的过程中，我深感其不仅是一本关于技术层面的书籍，更是一本关于思维方式和方法的艺术指南。这本书从多个角度和层面展示了软件测试的重要性和复杂性，同时也揭示了如何运用智慧和策略来应对软件测试中的各种挑战。 书中提到的一个观点让我印象深刻，那就是软件测试并不仅仅是找出错误，更是一种对软件质量的全面评估。这种评估需要测试人员具备深入的技术知识和敏锐的洞察力，以便在复杂的软件系统中发现问题并提出改进建议。这让我意识到，作为一名软件测试人员，我们不仅要具备扎实的技术基础，还需要拥有一种独特的思维方式和洞察力，以应对不断变化的软件环境和需求。 在阅读过程中，我也深刻体会到了测试用例的重要性。测试用例是测试工作的基础，其质量直接影响到测试的效果和效率。书中提到的关于测试用例的编写、评审和执行的策略和方法，让我更加明白了如何编写高质量的测试用例，并如何在测试过程中不断优化和完善它们。同时，我也认识到了测试用例编写中可能存在的问题，如冗余、错误或缺失等，这些问题都可能影响到测试的质量和效果。 此外，书中还提到了许多关于软件测试的理念和方法，如黑盒测试、白盒测试、自动化测试等。这些理念和方法不仅让我对软件测试有了更深入的了解，也为我提供了在实际工作中解决问题的思路和方法。同时，我也认识到了不同测试方法之间的优缺点和适用范围，这让我能够更加灵活地选择和应用不同的测试方法，以适应不同的测试需求和环境。 总的来说，《软件测试艺术》这本书不仅提供了丰富的技术知识和实践经验，更重要的是它教会了我如何以一种艺术的眼光来看待软件测试工作。这本书让我深刻认识到，软件测试不仅是一项技术工作，更是一种需要智慧和策略的艺术。通过学习和实践书中的理念和方法，我相信我能够更好地应对软件测试中的各种挑战和问题，为软件质量的提升贡献自己的力量。

本书主要讲方法论和经验总结，本人看次数2次了，5年前和现在。本书适合有一定经验的测试或者开发人员看，可以查漏补缺，纠正错误的测试思想，但不适合小白，5年前本人没有生产经验很难感同身受，看的打瞌睡，但现在看能引发很多思考。

快速翻阅看完了，总体来看比较陈旧，同时结合实际测试工作中内容较少，收获较小。 不过能看出，上次看的测试架构师一书中有参考此内容。

让我收获很多 以后可以多复习一下

「202603 —— 软件测试的艺术」 基础概念解释的很详尽，对初学者很友好的一本入门测试书📖