《颠覆完美软件》读书笔记

Paste_Image.png

《颠覆完美软件-软件测试必须知道的几件事》这本书是“温伯格技术思想三部曲”的第二本，同《程序开发心理学》一样，温伯格先生的切入点仍然是心理学，从心理学角度揭示软件测试的必要性、本质，以及软件项目管理过程中出现的、与测试相关的种种现象的深层原因。我认为这本书更适合软件开发项目的管理者、测试团队管理者和对管理感兴趣的开发者阅读。

一、 测试的原因与目的

测试的根基在于心理学，在于对人脑行为的研究。如果人类是完美的思考者，我们就不需要对工作进行测试。如果我们是没有感情的机器人，就可以通过合理的方式使用测试，降低我们做出的决定中蕴含的风险。如果我们是从一个模子里克隆出来的，那么我们就会用相同的方法评估风险。但是，我们是不完美的、不理智的、价值驱动的、不同的人，因此我们要进行测试，并对测试进行测试。

测试的作用在于提供信息，帮助管理者对软件的状态（实现了哪些功能，存在哪些缺陷，具有哪些特性等等）有更准确的认识，帮助管理者作出决策，降低项目风险。

测试并不会改进产品，根据测试提供的信息，对产品缺陷进行的修复才是。

不良的测试也许比不测试更糟。
考虑不周的测试或者执行过程不佳的测试都归于“不良测试”或“恶劣测试”这一统称。这样的测试可能会让人以为产品的质量高于实际质量，导致产品在就绪之前就被交付。不良的测试也可以能会让人以为产品质量低于其实际质量，导致推迟交付，结果损失潜在的效益。

测试可以揭示缺陷的存在，而不能表明它们不存在。

二、关于信息免疫

测试的目的是提供信息，但是大家常常会将这些信息看成某种威胁。当我们面对那些不想听到的信息时，“免疫系统”会跳出来保护自己。信息免疫会破坏你为测试作出的最大努力，使有关缺陷的消息变成对牛弹琴。

在我们的自尊程度比较低，而某些交互触发了生存规则的时候，我们就会采取防卫措施。因为如果生存规则被打破，会导致我们对自身安全产生强烈的恐惧感。测试极容易触及这样的生存规则。例如：

• 如果某人指出你程序中的一个缺陷，你很可能会触发自己的生存规则，说：‘我一定要保持完美。’
• 如果你正试图使用一个程序而无法让它正确工作，你可能会触发自己的生存规则，说：‘我一点儿也不笨。’
• 如果测试发现了一堆缺陷，项目无法顺利完成，你可能会触发自己的生存规则，说：‘我必须按进度工作’或者‘我必须实现承诺’。
  。。。。。。

心理学家将防卫措施分成了六个类别：1、压抑无法接受的事情（死不承认存在缺陷）；2、让不可接受的事物合理化（将缺陷硬说成是特性）；3、将自己的负面品质投射给其他人（说用户没有足够的耐心）；4、转移指责从而免除自己的责任（指责用户太挑剔、太笨）；5、对自己的不足进行过度补偿（被指出缺少校验后为其添加过度校验）；6、在觉得失去控制时开始强迫自己（拒绝承认事实）。

如何应对防卫反应？
首先辨识对方是否处于防卫状态，如果是，先耐心讲道理，实在讲不通就算了，千万别跟他生气。
更重要的一点，是注意使自己保持警醒、深思熟虑和主动，尽量避免自己陷入防卫反应之中。

三、有关测试的主要误区

学会识别一些有关测试的主要误区可以消除项目经理大约一半的常犯错误。

常见错误

1、认为指责可以起长期作用：我们也许可以看到指责带来短期的结果，但是它带来的后果可能不是有益的，而会像是拿棍子去捅一条狗一样，反倒被咬一口。
2、认为对问题的第一印象总是正确的：第一印象是重要的，但是测试问题通常要求进行更多的分析，尤其是如果你发现自己正在指责别人时。
3、认为可以对任何事物进行“穷举”测试：如果要求“穷举测试”，通常得到的就是测试人员以不同的方式进行欺骗，对他们的经理进行隐瞒，直至最终的反叛。
4、认为可以采用“投机取巧”的方法开发软件，然后通过测试提高质
量：投机取巧就是投机取巧，它是低质的，而且会很难测试。
5、以为系统测试可以捕获所有缺陷而将单元测试当作冗余加以忽略
6、期望测试可以产生质量：质量是整个开发过程的产物。不良的测试会导致不良的质量，但是良好的测试并不一定能导致良好的质量，除非整个开发过程的其他部分都是恰当的并且得到了正确的执行。

四、萨提亚交互模型

一个有助于测试人员改进他们对软件状态进行观察和沟通的系统。
（这个模型其实适用于各种沟通情况）

萨提亚交互模型将任何沟通过程都分解成四个主要阶段：摄取-》确定含义-》确定重要性-》做出反应

1、摄取

摄取是一个主动的过程。要尽可能地了解那些限制摄取的因素，信息的来源，以及数据如何获得了带有偏差的含义，被动等待别人将数据给你或许不会让你成为受害者，但至少会让他们可以潜在地控制你将会得到哪些数据。

2、确定含义

数据本身并不会说话，它们也不是没有任何模糊含义。不同的思维会确定不同的含义，不同的思维会确定不同的重要性，最好记住对同样的数据可以有很多种可能的解释。

我们在谈论软件故障的时候，不是指责别人。

我们希望他们做的是单纯地找出改进的可能性，所以一定要注意检查，避免导致其他人进入防卫状态。

3、确定重要性

我们的情绪承载了关于事情有多重要的信息。如果我们多注意情绪，认真听取，先解决重要的事，再解决不重要的事，就可以对获得的数据做出最好的处理。

4、做出反应
对缺陷的正确反应：发现（find）它们； 评估（figure）它们；修复（fix）它们

接近项目结束时如何反应：

即使是获得了最佳管理的项目，也几乎无法避免在接近交付期的时候仍然存在一些缺陷。因此，即使是在管理良好的项目中，第一反应都应该是为最后阶段安排好时间，在计划中不能只是一个简单的测试工作块，而应该是类似于下面这样的。
1、停止所有测试，开始为最后阶段做计划。
2、根据重要性对剩余的已知故障排序。
3、估算在剩余的时间内能够按照重要性从高到低的顺序可靠地修复其中的多少故障。
4a、从交付计划中去掉无法修复的特性。
4b、如果步骤4a要求放弃某些特性会让产品变得不可接受，就取消交付并重新制定交付计划。
5、接下来按照步骤2中确定的重要性顺序去除缺陷。

结尾的话

这本书与《程序开发心理学》的共同点是都用了大量来自实践中的具体事例来说明问题，我在读书的过程中每每会由于看到熟悉的情景描述而会心微笑。此外，每个章节结尾都一个小节列出与本章内容相关的常见错误，我只把其中极小一部分摘录到了笔记中。常见问题是信息量较大且集中的部分，值得反复读。
这本书比《程序开发心理学》薄得多，翻起来也更容易，感兴趣不妨找来读读。
最后附上天津图书馆的索书号：复康路中文图书借阅 : TP311.55/61