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

四、测试和修改软件BUG有什么分别？（第4章）

　　不能正确定义测试，就可能会产生无休止的争论。让测试人员或开发人员不知道自己的本质工作是什么，同时也会导致项目的失败。

　　1、大机构和小机构对任务的分工

　　在小机构或者小公司，一个人可以同时分饰多种角色，可以发现问题，查明问题，定位，确定重要性，修改和解决问题。

　　在大型机构或公司，必须要定义测试和开发的具体职责和分工，这样才能避免项目冲突和失败。当个人的职权范围覆盖测试团队、开发团队和支持团队，就需要明确谁负责哪项工作。只有对工作进行明确分工，才能对整个项目加以改善，提高项目成功的可能性。

　　2、时间试探法的管理法则

　　项目中没人可以随意浪费任何人的时间。

　　通过这一原则，有两种应用：

　　1）测试人员在通知开发人员之前，对单个缺陷进行研究的时间限制在10分钟以内

　　　　10分钟后，如果对缺陷或缺陷所导致的问题还是不了解，可以请求他人帮助。

　　2）不要浪费时间来做细微的区分

　　　　发现和查明缺陷之间没有一个很清晰的界限，不要浪费时间争论特定的活动是否属于查明问题，而让测试人员和开发人员都投入进来共同完成工作。例如建立讨论组，或者测试人员和开发人员一起定位问题。

　　3、相关常识

　　1）定位缺陷需要花费时间，不要估算定位错误的时间。

　　2）每次任务切换都会损失一些时间，如果要切换的任务数目达到了五项，可能就会无法完成任何工作。给人员分配工作时，不要随意添加工作，最好不要超过3项。

　　3）如果需要进行可靠的测试，就需要集中精力，不能将其当做低优先级的工作而被打断。

　　4）不能要求测试人员查明每个故障，如果测试人员有相应时间，可以安排帮助开发人员。但这项工作实质上还是开发人员的职责。

　　5）不能要求开发人员定位每个问题，这完全是开发人员的工作。

　　6）程序完成修改，如果不赶时间，一定要重新测试（回归测试）。

　　7）在设计和构建代码时就需要考虑可测试性，这样可以显著降低测试方面所需要的时间和精力。

　　8）对间歇出现的缺陷要投入大量精力来追踪，而不是把它作为推迟测试和推迟修改的借口。可以使用已经获得的缺陷信息，而不要浪费测试人员时间，让测试人员持续测试,去“重现”问题。

　　9）测试人员的工作不能仅通过确定的测试用例来包含，应转换为按照测试活动进行思考。比如测试人员应能够根据项目建立测试用例，并执行测试用例。？？需要再考虑这一条。

　　10）当有以下这些特征，可能需要公司改变一下：1.认为测试人员需要查明和定位缺陷；2.认为给开发人员送茶递水是测试人员的工作。

五、关于软件产品质量的元信息有哪些？（第5章）

　　软件测试的目的是提供有关产品质量的信息，本章作者提供很多导致测试失败的元信息，通过观察和识别这些元信息，可以显著提高测试的效率并降低成本。

　　1、各种关于产品质量的信息

　　1）没有规格说明书

　　我们要对产品进行测试，就需要有测试所针对内容的规格说明书。如果找不到这些规格说明书，则就需要对所要测试的内容进行质疑了。

　　2）测试人员没有对非自己组内的测试问题进行记录

　　3）测试人员也许测试的就是错误的应用程序

　　4）因为最差的组件花费时间较多，所以不对最差的组件进行测试

　　5）忽略测试人员提供的信息

　　6）因害怕开发人员发脾气而不去报告缺陷

　　7）因为开发人员水平比较高而不进行测试

　　2、相关常识

　　1）测试报告中不会包括所有相关信息，里面顶多也只包含一半你所需要的信息

　　2）应对测试的执行过程及其所隐含的情况进行直接的观察，从而验证测试报告

　　3）测试只能显示某些事情失败了，或者在特定条件下没有失败。测试不是关于证实的，而是关于证据和推论的。

　　4）文档不使用的情况下没有任何价值。如果使用了导向错误的文档，比没有价值更槽糕。

　　5）如果修改缺陷的速度慢于缺陷增长的速度，可以停止制造新的缺陷，进而修复已有的那些缺陷。

　　6）有效的测试是，既要集中精力又要有目的。没有目的地集中精神，看似不错，但不会取得多少成果。

　　7）对发现故障应进行记录，不应该进行忽略。为了“节省时间”而不记录故障情况，会导致事与愿违的效果。

　　8）不应该过度记录发现的每一个缺陷。因为记录每一个缺陷的代价是很高的，对于某些缺陷，不用准备正规的详细说明，而是将相关信息放到电子邮件中，或在会议中进行提及，或向开发经理进行口头报告。提高报告的成本会提升测试人员自我审查的可能性。有些类型的缺陷可以作为一个记录按批提交。

　　9）某个模块或者某个项目，已经发现的缺陷越多，将要发现的缺陷就会越多。完美的开发人员是不存在的。

　　10）模板保证了文档的形式是标准的，可能会掩饰一些不可靠的信息。

六、如何应对由于不同人因恐惧造成的防卫反应？（第6章和第7章）

　　测试的目的是提供信息，但人们常常会将这些信息看成某种威胁。测试很容易触及人们的恐惧点，我们要做的就是识别每个人表现出的防卫行为，然后主动的去应对，这样才能避免混乱的情绪而影响测试工作。

　　防卫反应的类别和特征

　　在我们的自尊程度比较低而某些交互触发了生存规则的时候，我们会采取防卫措施。因为如果生存规则被打破，会导致我们对自身安全产生强烈的恐惧感。而测试非常容易触及这样的生存规则。比如测试发现了一堆缺陷，项目无法顺利完成可能会触发自己的生存规则，说：“我必须按进度工作”或者“我必须实现承诺”。

　　心理学家将这些防卫错误分成六个类别：压抑、合理化、投射、转移、过度补偿和强迫。

　　1、压抑无法接受的事物

　　压抑就是不承认或者忽略我们认为无法接受的想法、感觉和记忆。压抑的一个例子：鸵鸟将自己脑袋埋到沙子里：“如果我看不见，那就不存在”，掩耳盗铃。

　　2、让不可接受的事物合理化

　　合理化就是试图让没有意义的、愚蠢的或者是无理的举动看上去合理。例如，一名开发人员声称：“我在程序中留下错误就是为了检验测试人员是否工作得很好”就是在进行合理化。对于测试人员，应如何引起开发人员的注意而不让他们感到威胁增加？他可以通过解除掉开发人员的防卫（用合乎逻辑的过程进行解释），然后说明需要做出一个修复。

　　3、将自己的负面品质投射给其他人

　　负面的投射，就是批评其他人具有我们自己身上也有的某种并不希望的品质。比如，如果我私底下怀疑自己有些自私或者专横，我可能会在其他人身上找出这些负面品质，抱怨说：“他很贪婪”，或者“他很有控制欲”。

　　4、转移指责从而免除自己的责任

　　转移就是指责并非问题真正来源的人或事，从而免除我们自己的责任。例如，“我的铅笔断了，所以我没法完成家庭作业。”。当开发人员面对测试人员提出的“无法接受”的问题时，可能将抱怨向测试人员，向其他开发人员，向他们的经理，向整个世界进行转移。

　　5、对自己的不足进行过度补偿

　　过度补偿就是为了弥补某些真实的或者是想象的个人不足而做得过了头。例如，某个人因为觉得自己不够可爱而变成一个工作狂。

　　6、我们觉得失去控制时开始强迫自己

　　强迫就是无法摆脱某种负面的行为模式。例如，某人不允许对已定义的过程有任何微小的偏差。

　　7、相关常识

　　1）在人们害怕时，需要注意观察，很容易看出别人采取的防卫机制。

　　2）不能制造恐慌的环境，因为报信的人带来了不想听到的消息而指责他，你将再也无法听到你应该听到的信息了。

　　3）一个人的强迫行为，往往会导致其他人产生恐惧和防卫行为。最优的做法应该是努力让自己的行为合乎道理。

　　4）学会带着赞赏的态度听取异议和辩解。试着在反对观点中寻找和尊重那些有价值的内容，实际上总会有些内容是有价值的。争论者辩解说“太难修复了”，也许是为了表示，“我不知道如何才能快速或者廉价地修复它，我也不确定我花时间在这里是否是个好主意。”

　　5）防卫行为是人的普遍反应，在任何地方都可能发生。

　　如何应对防卫反应

　　对于应对防卫反应，不需要了解他们为什么这样进行防卫，需要通过建立合理的规则和指导原则来纠正这种情况。规则：首先不将对方的行为定义为防卫性的，但按照它是防卫性反应来看待，看看它是否会在温和的测试下表现出来。

　　1、确定恐惧

　　首先，需要了解防卫性反应是受恐惧驱动的。尝试一下能否确定对方害怕的是什么，再看看在找到方法减轻那种恐惧之后会怎么样。 

　　2、使用危机思维

　　危机思维：在顺境中要有警惕心。对某些防卫反应用危机思维来思考，就是，某些防卫反应可能就是无效的论点，可能就是一些个人攻击。这种情况下，通过使用逻辑方法找到比人论点是否是基于逻辑。

　　3、实践，实践，再实践

　　通过足够的时间，可以更好的辨识别人的防卫反应，并加以解决。例如，一些常见的防卫反应说法：“这是为了用户自身利益”，“这是按照我设计的方式工作”，“修复它“太冒险””。

　　4、相关常识

　　1）要考虑差异，每个人都有自己的规则。每个人在自己的规则受到威胁的时候都会感到恐惧。规则不同，做出的反应也是不同的。要平等地对待每个人，但不一定要采取完全相同的方法。

　　2）不要对别人说他们不关心质量。每个人都是相当关心质量，他们也许不了解如何获得高质量。每个人对质量的看法都是不一致的，要教育他们，使得大家对于质量的理解统一。

　　3）需要通过实践来学习如何辨识和有效地应对防卫反应。如果出了一些错误，让自己稍微放松一下。

　　4）如果你是经理，需要处理其他人可能影响他们工作完成情况的反应就是你的职责。