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

十、怎样让软件更容易测试和更容易成功？（第15章）

　　当上一个项目失败，需要考虑下一个项目应该如何改善。本章介绍几种让软件更容易测试和更容易成功的方法。

　　1、软件测试变得困难的原因

　　从根本上来看，软件测试变得更困难的原因在于我们变得更有野心。我们希望有大型的软件来完成更有效率更好的事情。

　　1.软件越大，可能出现故障的地方就越多（故障数目）。

　　2.软件越大，越难查明故障的原因（查明花的时间）。

　　3.软件越大，工厂为维修而关闭，就会导致生产上更大的损失（损失的机会成本）。

　　2、让测试更容易和成功的方法

　　2.1 让系统尽可能小

　　　　让系统尽可能小（但是不要过小）。让需求受控，需要决策者或相关人来区分某件事对于产品是否真的是必需的。

　　2.2 让“系统”模型是可扩展的

　　　　应该警醒地检查你开发的简单系统是如何与更大的、及其复杂的系统纠缠在一起的。

　　2.3 增量构建有清晰接口的分立组件

　　　　例如就像“不要一次做所有事”策略所建议的，可以采用增量方式进行构建，在完成一个部分的构建、测试和修复工作后再开始下一个部分。

　　　　增量构建是测试先行的思想，即开始构建每个组件前先建立一组验收测试。

　　2.4 减少进入产品的缺陷数目

　　　　测试的难度不仅和从系统中去掉多少缺陷有关，还和他们何时被去掉有关。一般而言，越早去掉一个缺陷，它造成的损失就越小。所以尽早开始测试，并贯穿整个开发过程。

　　3、相关常识

　　1.测试人员只是信息的提供者。他们并不做出有关交付的决定。

　　2.测试人员是“质量警察”，但他们不是法官、陪审团或立法者。　　

十一、关于技术评审的一些建议（第16章）

　　尽早和尽可能频繁的对项目进行技术评审，对产品进行测试，可以收获意想不到的好处。

　　1、技术评审的好处和特性

　　1.1 通过投入大量脑力对一个系统进行测试的最简单方法

　　1.2 技术评审可以分析和记录某些技术产品、例如代码、设计或规格说明的优劣

　　1.3 技术评审也是一种测试，是一种白盒或“开盒”测试

　　1.4 技术评审可以用于那些不能马上通过机器来测试的项目内容

　　1.5 通过技术评审和机器测试两者结合可以发现90%以上的缺陷

　　2、阻止技术评审的原因

　　通过了解一些人阻止技术评审的原因，不仅可以了解制造者思维中的缺陷，还能发现对产品进行测试的方法。

　　2.1 “如果评审那个产品，会花太多时间”：问题可能是产品的规模不适当，应该设法将它分解成几个部分进行评审。

　　2.2 “产品无法分解成可以评审的多个部分”：产品是一堆无法理解的东西，应将产品重建成可以评审的对象。

　　2.3“除了作者，没人能理解那些代码”：这个产品需要被重建成可以使用和维护的形式。

　　2.4“这是不证自明的”：是不证自明的，为什么不能花几分钟时间进行评审呢？

　　2.5“它太小了，不值得为它操心。有什么可能出错的地方呢？”：如果小，评审可以非常迅速而方便地告诉你哪里有可能出错。有些产品可能修改一行代码，导致超过十几亿的损失。

　　2.6“现在要评审它已经太晚了”：当收到大堆缺陷时不要吃惊哦。

　　2.7“现在评审还太早”：如果进度计划上说某些东西已经准备好要评审，但还没有准备好，那么问题就是已经落后进度要求了。

　　2.8“没错，是评审的时候了，不过我还在修复里面的缺陷”：如果一个产品有很多的缺陷，马上评审它可能是一个好想法，可能帮助某些遇到困难的开发人员。

　　2.9“我们不能评审它，因为我们不清楚它应该要解决什么问题”：为什么要构建呢？可能产品的规格文档并没有被理解清楚，评审建议是“扔掉它，不要浪费钱”。

　　2.10“我们的问题说明，并没有针对我们正在解决的问题”：继续工作之前要先获得问题说明。

　　2.11“我们不清楚正在解决什么问题，因为我们一边前进一边定义问题”：可能开发者并不理解敏捷开发。

　　2.12“我们需要花几周时间来为评审做准备”：还没有生产出需要测试/评审的可交付产品。真正的开发过程有一条基本原则：你应该一直在生产这些东西，你没有生产他们，你就没有实施整个过程。

　　2.13“我们不希望别人看着我们做事，因为我们的人过于敏感”：可能是错误的人正在处理这个产品，可能是对他们的管理不善。

　　2.14“你没法评审它的性能，因为我们只有构建了它以后才能知道它的性能，然后我们可以优化它，所以这不会是个问题”：继续进行评审并提问，产品表现正常吗？怎么优化的？

　　2.15“我们一准备好就会让你知道”：评审结束。原因是产品还没有完成。

　　2.16“我们这些构建者已经在内部评审过了，所以再次评审时浪费时间”：产品完成的很好，再次评审不会花很多时间，并保证构建者之外的其他人可以理解他。

　　2.17“我们以前评审过类似的东西”：你可以更为迅速的评审这个新的。也可以对两次评审的结果加以比较，获得额外信息。

　　2.18“你和你那些评审者在这个领域没有很充分的资格。实际上，唯一有资格的人都在这个项目中”：项目之外的人没有有资格的评审者，这个产品可能不能维护，且会有严重安全问题。

　　2.19“这里真的没有什么新东西；都是可重用的代码”：这样，评审会快而美好。只要我们对每个可重用部件的状态及其接口都有记录良好的证据。

　　2.20“如果你按照指示做，就不能出错”：这种警告意味着，构建者不知道用户没按照指示做会发生什么事情。

　　2.21“我们[测试][常识][演示]了它，而且它工作得不错”：问题在于对“不错”的定义，比较模糊的废话。

　　2.22“它工作了”：意味着“没有让这个产品失效，而且我们也没有让它运行很长时间或者在差别很大的条件下运行。”

　　2.23“根本没有任何问题”：对他评审也没有任何问题。

　　2.24“我们从来没有遇到过困难”：对构建者是好事，对构建者之外的人是否也这么幸运吗？

　　2.25“我们不知道它如此糟糕要进行评审”：不要将评审当作对你认为可能不好的工作的惩罚。对产品评审应该是标准的、普遍的过程。它暗示的因该是产品的质量的重要性。所以要求对你的工作进行评审意味着你的工作室重要的。任何找这个接口的人都没有理解评审所扮演的角色。要不就是你的公司确实是用评审作为惩罚。

　　2.26“我们不知道我们需要评审它”：你不了解你的开发过程。修正它的方法是培训和交流。

　　2.27“我们的进度稍微有点落后，所以还没有准备好，不过我们希望能有运气使进度赶上来”：软件开发中不能靠运气。

　　2.28“我们认为我们的工作做得不是很好，而且我们不想让管理层知道”：评审往往表明这些产品并不想构建者所希望的那么好，但是也么有他们担心的那么差。

　　2.29“我们不想和那些过程狂合作”：如果评审成为政治的演练，那些爱管闲事的人希望通过它来表现自己的力量。应该对评审系统进行评审。

　　3、首先对最差的部分进行评审可以让人了解缺陷的严重性

　　　　最迅速的评审方法是对“最差的”部分先评审。这样可以简单的要求每名评审者从他或她发现的最差的问题开始处理，然后再处理相对次要的问题。例如，程序中使用了有瑕疵的算法，再去关心界面上的拼写错误就没有意义了。

　　4、如何说服别人进行评审

　　技术评审可以投入很少时间提供大量重要的早期信息。别人很难相信可以通过如此简单的方法获得那么多的信息。

　　1.可以让构建者经历一次完整的对各个部分的评审，让他们了解评审结果的产生。

　　2.可以先开始测试，让测试结果来说明这些问题本应该通过评审来发现的。

　　3.需要将即时结果评审交给管理层，让他们决定是否要浪费时间来召集一次正式的评审。

　　5、测试人员也是有价值的评审者

　　测试人员不仅能在评审过程中找到缺陷，还可以从评审经历中学到一些东西。

　　1.通过观察开发人员可能产生的存在瑕疵的思维模式，测试人员可以了解如何设定更好的测试。

　　2.通过较早地对规格说明书进行评审，测试人员可以更早了解到他们测试计划的范围。

　　3.通过熟悉设计，测试人员可以加快检测缺陷的过程，然后帮助查明他们。

　　4.通过参加评审，测试人员可以学习如何能对他们自己的测试用例、测试设计、测试驱动程序和工具进行更好的评审。

　　5.测试人员参加评审，与那些单纯坐等开发人员交给他们一些东西进行测试的人相比，他们可以更快地进入项目。

　　6、相关常识

　　1.一个项目没有包含经常性的技术评审的过程，那么无论机器测试过程有多好，它都不可能超过正常水平。

　　2.要培养一种气氛，让每次评审成为对所有参与者都有益的经历。

　　3.不能为节省时间而省掉评审。错误是导致损失项目时间的首要原因。省掉评审总会让项目花掉更多的时间。

　　4.只要在设计系统的时候考虑了它的可测试行，那么在开始运行任何测试之前，就可以节约至少一半的测试成本。

　　5.评审中需要包含测试人员：a.测试人员可以提供他们独特的视角，提高评审的有效性；b.测试人员也需要每次评审提供的教育机会。

　　6.没有认识到学习的价值：学习是评审中最有价值的部分。　

十二、测试中由别人和自己所带来的欺诈有哪些？（第17章和第18章）

　　当自己想快速清除缺陷和交付产品时，要特别注意别人推荐的测试工具，可能这个工具就是一个欺诈。当我们希望所有事情都进展顺利，可能也是对自己的一种欺骗。

　　1、第三方测试工具引发的欺诈

　　1.1 测试工具欺诈场景

　　我们在测试中会用到测试工具辅助我们进行测试，测试工具并不是万能的，当某些软件提供者给你提供测试工具时，要小心其中的欺骗性。

　　1）当他们在给你演示工具的优越性时，你要知道这并不是在测试，只是在证明某个已经设计好的观点。

　　2）当你要购买的测试工具有很多证书或者证明材料时，也不能保证这个测试工具很好。

　　3）当软件的定价很高时，也不能说明这个测试工具的优势。

　　4）当提供商宣称工具可以测试很多项目时。不要相信。工具只是工具，他们需要会思考的人进行有意义的操作。

　　1.2 如何避免测试工具引发的欺诈

　　这些欺诈方法总是承诺不劳而获。唯一能够不劳而获的只有后悔。如果某件事好德不像是真的，那它可能就不是真的。

　　2、自我忘却型欺诈

　　有很多欺诈时我们无意中忘却而犯下，当我们希望让所有事情都进展顺利，可能就会生产一些不真实的数据。

　　1）推迟文档化

　　　　测试人员不及时对测试缺陷和测试数据进行记录

　　2）测试报告不明确

　　　　测试人员所提供的测试报告的含义不是很明确，你不知道他提供的测试报告的意思。

　　3）伪造测试报告

　　　　测试人员通过不报告缺陷来帮助开发人员。

　　4）不能区分数量和质量

　　　　进行大量测试和发现大量的缺陷，不意味着进行测试的质量有多好。　

　　5）过分关注报告的形式