颠覆完美软件：软件测试必须知道的几件事（读书笔记5）

九、一种改善软件测试沟通问题的模型（第11、12、13和14章）

　　本部分通过介绍萨提亚交互模型：摄取-->确定含义-->确定重要性-->做出反应，来应对软件测试和项目推进过程中的相关问题。

　　1、萨提亚模型

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

　　　　摄取（Intake）：一个人从外部世界取得信息，摄取不是简单的输入，还包括信息的选择过程。

　　　　确定含义（Meaning）：某人会对感官摄取的内容进行考虑并给它一个含义。

　　　　确定重要性（Significance）：确定信息的重要性，可以让某些摄取及其含义获得优先权。

　　　　做出反应（Response）：一个人会构想出准备采取的行动。

　　2、信息摄取

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

　　　　2.1 人们听取的信息是有选择性的

　　　　经理们尤其选择性听取有关发布和交付日期。如果测试人员说，根据目前发现和修复缺陷的速率，几乎不可能在9月1日之前交付。经理可能会听成，9月1日前交付。为了避免这类问题，有两种方式：1.只采用书面形式给出和接受某个日期；2.不要给出或接受“点日期”，要这么说，估计会在8月1日到8月21日发布某个版本。

　　　　2.2 数据来源会影响到摄取

　　　　如果有些人不愿意接受你的测试报告，而愿意接受其他人递交的报告。你可以从自己找找原因：1.自己以前是不是做过什么让大家认为我不是一个可靠的信息来源的事。2.我应该做些什么来提高他们对我作为信息来源的信任。

　　　　2.3 提供信息的时机也会导致差异

　　　　别人将注意力转向其它地方的时候会遗漏某些信息。如果没有得到别人的注意，就没有什么必要提供信息，因为对方不太可能接受这些信息。

　　　　2.4 人们会出现信息过载

　　　　人们受到过多信息，会停止或者在一定程度上减少摄取信息。比如缺陷数目太多，就是信息过载，这时候不知道应该先处理哪一个缺陷。

　　　　好的方法是，将缺陷按照重要性进行分类。将缺陷报告类别分为4个级别：0级、1级、2级和3级。

　　　　0级：阻碍其他测试，未能在1分钟内进行分类。

　　　　1级：该问题没有解决，产品不能交付。

　　　　2级：该问题没有解决，产品的价值会显著降低。

　　　　3级：产品交付时有大量类似问题，该缺陷才是重要的。

　　　　2.5 减少测试的数量可以传递更多信息

　　　　通过回答“哪些测试会对将来的测试和开发产生最大的影响”这个问题可以缩减可能的测试集合，进而通过很少的测试数量，就可以传递很重要的信息。

　　　　2.6 寻找测试之外的信息摄取

　　　　测试之外，是不是有其他原因也会导致问题，比如静电、震动、雷达等。一台测试机器没有按预期方式工作，可能是别人使用后更改其状态。

　　　　2.7 不要混淆理解和摄取

　　　　当人们根据随机的一点数据，猜测这些数据的含义时，就会非常迅速地从摄取阶段移动到确定含义的阶段。

　　　　2.8 使用数据质疑来过滤理解

　　　　当某人在你需要数据的时候向你提供对测试的理解，可以使用数据质疑的方法：“你看到或听到（或者闻到、尝到、感觉到）让你产生这样的理解？”，通常需要重复数据质疑，直到得到你所期望的不带含义的数据。

　　　　2.9 相关常识

　　　　1.你需要对接受的信息进行选择，不要来了什么信息就去接受。

　　　　2.测试工作中得到的信息中有99%是没有用的，你要有一双慧眼，从大量数据中捕获有用的信息。

　　　　3.不要混淆摄取和含义：

　　　　　　在确定数据之前，数据时没有意义的；对相同的数据，不同的人会给出不同的含义。

　　　　　　先收集数据，然后坐下来考虑这些数据可能具有的至少三种含义。

　　　　4.不要禁止测试人员在某些地方寻找缺陷，应扩展测试人员的思维。

　　　　5.要为测试人员提供充足的设备和工具。

　　　　6.有些昂贵的测试工具本身设计有问题、并且不可靠，那就大胆的抛弃它。

　　3、确定含义

　　　　数据本身是没有意义的，需要由接收的人给它加上含义，而不同的人会给出不同的含义。所以对同样的数据最好给他多种可能的解释。如果对测试结果不能想出至少三种可能的解释，就说明思考得还不够。

　　　　3.1 对缺陷要思考多种含义

　　　　对缺陷进行解释以确定含义需要勤奋和开放的态度。同时对缺陷而想到的含义应该越多越好。

　　　　3.2 解释含义之前应弄清楚期望的是什么

　　　　如果不清楚一个程序被期望做什么，就永远不能确定地说它是错误的。在你给测试报告赋予含义之前，先要弄清楚你期望的是什么。

　　　　3.3 不知道期望时的做法

　　　　如果在解释测试结果时不清楚产品被期望要做什么，可以提出下列问题。

　　　　1.它是否完成了重要的人希望它完成的工作？

　　　　2.它是否没有做重要的人不希望它做的事？

　　　　3.这些测试结果告诉我哪些与这个两个问题有有关的情况？

　　　　3.4 使用已经获得的信息

　　　　确定测试报告的含义时需要考虑测试报告中未包含的信息。但是在盲目地要求更多的信息前，应该从已经获得信息入手。要充分地利用已经获得的信息。

　　　　3.5 使用间接信息

　　　　间接信息包括：每个测试运行的日期和时间，报告提交的日期和时间，测试是谁运行的，每份报告是谁提交的，测试的软件及其版本的明确标识，使用的操作系统、浏览器、计算机、配置，测试工具和原始开发语言，对较早缺陷报告的引用，及各种形式的补充说明。

　　　　只有利用这些似乎是附属品的数据才有可能理解很多最困难的缺陷。

　　　　3.6 使用未获得的信息

　　　　根据缺失的信息推断含义。

　　　　3.7 同样的话可能具有不同的含义

　　　　3.8 “相同”可能并不一样

　　　　表面相同，但实际来自于不同来源的事物进行理解时要保持怀疑的态度。

　　　　3.9 某些时候不精确会更好

　　　　在试图对含义进行沟通时，有时候使用模糊的语言更有效。

　　　　3.10 相关常识

　　　　1.根据“三法则”，在采取行动之前至少考虑三种可能的含义。

　　　　2.在测试之前，要记录好对测试结果的预期。

　　　　3.不要完全靠自己确定含义，要让整个团队都参与进来，从而降低忽略某个重要结论的可能性。因为不同思维会确定不同的含义。

　　　　4.确定数据含义时使用“三法则”是不够的。对不同的人而言，同样的含义可能具有完全不同的重要性。不同的思维会确定不同的重要性。　　　

　　4、确定重要性

　　　　重要性是由负责决定要如何对缺陷进行处理的人赋予该缺陷的价值。每个人因为思维的不同，所确定的重要性都是不一样的。如果我们注意情绪，认真听取，先解决重要的事情再解决不重要的事，就可以对获得的数据做出最好的处理。　

　　　　4.1 不同人会给同样的信息赋予不同的重要性

　　　　作为项目经理，工作就是将所有看法放在一起进行权衡，并得出这个缺陷对于整个项目的重要性。--前提条件是它确实是一个缺陷。

　　　　4.2 公共的重要性也许和个人的不一样

　　　　如果每个人都是合乎逻辑的、公正的、开放的，对重要性的评估就会很简单。但是，可能每个人对缺陷问题做出重要性的回答时都参杂了个人打算在其中。如果项目经理想对重要性做出明智的估算，就要想办法消除所有这些个人打算，包括项目经理自己在内。

　　　　4.3 重要性依赖于上下文环境

　　　　重要性不仅取决于单个缺陷和单个人的一项性质，还依赖于上下文环境。

　　　　1.某段代码，第一次出现缺陷和多次出现缺陷，评定第n次缺陷的重要性是不同的

　　　　　　某段代码，第n次出现问题，可能意味着以后还会发现更多的错误。这就是记录所有缺陷的原因。

　　　　2.对某个用户可能碰到的程序缺陷的可能性进行猜测

　　　　　　一百亿用户中只有一个用户可能遇到这种缺陷，重要性如何呢？

　　　　4.4 不能总是根据金钱来确定重要性

　　　　比如说人的生命。

　　　　4.5 不要采用过细的尺度

　　　　因为所有对重要性的度量都是主观的，不要愚蠢地让自己相信重要性是客观的。

　　　　将评定重要性的类别数量变为4个，该评定类别可以让测试人员从测试角度确定重要性。

　　　　0级：该问题阻碍了其他测试。

　　　　1级：如果该问题不解决，我们的产品就无法使用。

　　　　2级：如果该问题不解决，我们产品的价值就会显著降低。

　　　　3级：只有在产品交付时还存在大量类似问题时，该问题才是重要的。

　　　　4.6 首先解决重要问题

　　　　对已发现的故障，应先解决重要性高的故障。而通过对测试的重要性进行估计，首先执行那些重要的测试。

　　　　4.7相关常识

　　　　1.混淆重要性和修改的难度。

　　　　　　比如，系统崩溃的问题可能是不重要，而某个拼写错误确实是灾难性的。

　　　　2.认为有“理性的”或者客观的方法来评估重要性：

　　　　　　也许可以使用数字和算法来为评估重要性提供帮助，但是最终的评估步骤总是要度量人对那些数字的情绪反应。

　　　　3.获得新信息后也要重新评估重要性。

　　　　　　重要性是整个系统的一种性质，包括用于构建该系统的系统或过程。经常回顾对重要性做出的评估，并做好改变它的准备。

　　　　4.不要让废话影响到对重要性的评估：有意或无意使用，某些会掩盖有意的信息的词。

　　　　　　比如，某人说“反应应该会非常快”的时候，到底是什么意思呢？“应该”，“非常”和“快”给表达的信息添加了什么含义。

　　　　5.测试人员会对自己发现的缺陷不会在下一版本中进行修复而感到失望。

　　　　　　没有人希望自己的工作被忽视。但是要尽可能区分开忽视某些缺陷和有意识地选择不修复某些缺陷的行为。

　　5、做出反应

　　　　对缺陷正确的反应是：发现（find）他们；评估（figure）他们；修复（fix）他们。项目早期，会这样做。但是发现的缺陷越来越多，我们应该如何做出反应？

　　　　除了从一开始就采取正确的项目管理做法，没有那种反应可以挽救项目。如果项目进行到测试之前都没有获得良好管理，大部分良好的反应都无法使用。

　　　　5.1 运气不好？管理不善？

　　　　成功项目和失败项目对比，是管理不良导致项目失败。

　　　　因外部原因破坏软件配置，通过恢复安全的备份，即可以投入工作。团队一半成员请病假，结对编程和技术评审提供的冗余信息，允许人们继续在关键路径上工作。　　

　　　　5.2 项目赶进度的原因

　　　　主要同管理的质量有关。

　　　　管理不良的软件项目具有如下特征。

　　　　1.经理们不了解测试、查明和除错之间的区别。

　　　　2.由于不了解这些区别，所以认为这些在项目中遇到的大部分问题都是测试导致的。

　　　　3.由于他们会认为测试会导致问题，更倾向于尽可能推迟所有类型的测试。

　　　　4.由于他们选择在开发过程中推迟测试，测试成为了第一次进展不利的时候。

　　　　5.由于选择在开发过程中推迟测试并出现信息免疫，即便测试发现问题还继续假装一切顺利。

　　　　6.由于他们出现了信息免疫，在项目早期的各个阶段一切都会看上去进展“顺利”。

　　　　7.由于经理们出了问题，缺陷到后期测试的时候才会显现出来，而其中很多从最初的需求开始就隐藏在产品中。

　　　　8.由于整个系统中的缺陷很多都难以查明，所以很难应对大部分的缺陷。

　　　　9.开发人员在最后期限的压力下试图修复新发现的错误，同时也会制造新的错误，他们脾气上升，缺勤增多，同时会议也越开越长，开发策略事与愿违。

　　　　10.于是参与者得出结论：“测试之前没有任何问题，是测试弄糟了所有事情”

　　　　错误管理的其他类型包括：过于雄心勃勃的承诺，太差的工具、人员职位安置不当。所有这些都会造成进展缓慢，导致最后削减测试和修改的时间。

　　　　对缺陷最初也是最重要的反应是要预见他们会出现。没人会侥幸地不遇到缺陷，所以从项目一开始就采取正确的做法。

　　　　最那些少量遗留下来的缺陷，立即开始FFF（发现-评估-修复）方法。

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

　　　　管理良好的项目中，在交付日期临近时仍然存在一些缺陷，按照如下方式进行。

　　　　1.停止所有测试，开始为最后阶段做计划。

　　　　2.根据重要性对剩余的已知故障排序。

　　　　3.估算剩余的时间内，按照重要性由高到低可以修复多少缺陷。

　　　　4.从交付计划中去掉无法修复的特性。

　　　　5.如果步骤4中有些特性会让产品变得不可接受，就取消交付并重新制定交付计划。

　　　　6.接下来按照步骤2中确定的缺陷重要性进行修复。

　　　　5.4 对测试所需时间的估算与现实差距很大的原因

　　　　项目开始时的不良估算很可能是在项目结束时要赶进度的一个原因。常见的计划误差如下

　　　　1.好天气误差

　　　　按照项目按计划进行，没有缺陷进行修复来估算时间。

　　　　2.不切实际的过程模型

　　　　会忽略掉查明缺陷、修改缺陷，然后重新测试缺陷的时间。

　　　　3.低质的过程数据

　　　　4.没有过程数据

　　　　5.5 错过所有可以改变的时刻应该怎么办

　　　　1.按照现状交付产品；2.把故障当成一种特性；3.可以向用户提出有关这些故障的警告；4.可以撤回某些部分或者整个产品；5.可以从问题开始的地方重新开始。

　　　　5.6 相关常识

　　　　1.运气总是宠爱管理良好的项目。

　　　　2.不要因为赶进度而减少分配给测试的时间和资源，如果不关心质量，为什么还要测试。

　　　　3.在测试提供了有关产品实际状态的信息后应调整进度和估算的时间。

　　　　4.注意收集过程数据。对犯错的位置和时间越了解，就越容易发现、查明、定位和修复他们，或者在下一次出现类似的情况避免错误。

　　　　5.测试在产生项目概念甚至更早的时候就已经开始了。如果不了解这一点，就根本无法了解测试。