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

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

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

　　一、软件测试变得困难的缘由

　　从根本上来看，软件测试变得更困难的缘由在于咱们变得更有野心。咱们但愿有大型的软件来完成更有效率更好的事情。

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

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

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

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

　　2.1 让系统尽量小

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

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

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

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

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

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

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

　　　　测试的难度不只和从系统中去掉多少缺陷有关，还和他们什么时候被去掉有关。通常而言，越早去掉一个缺陷，它形成的损失就越小。因此尽早开始测试，并贯穿整个开发过程。

　　三、相关常识

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

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

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

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

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

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

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

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

　　1.4 技术评审能够用于那些不能立刻经过机器来测试的项目内容

　　1.5 经过技术评审和机器测试二者结合能够发现90%以上的缺陷

　　二、阻止技术评审的缘由

　　经过了解一些人阻止技术评审的缘由，不只能够了解制造者思惟中的缺陷，还能发现对产品进行测试的方法。

　　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“咱们不想和那些过程狂合做”：若是评审成为政治的演练，那些爱管闲事的人但愿经过它来表现本身的力量。应该对评审系统进行评审。

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

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

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

　　技术评审能够投入不多时间提供大量重要的早期信息。别人很难相信能够经过如此简单的方法得到那么多的信息。

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

　　2.能够先开始测试，让测试结果来讲明这些问题本应该经过评审来发现的。

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

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

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

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

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

　　3.经过熟悉设计，测试人员能够加快检测缺陷的过程，而后帮助查明他们。

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

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

　　六、相关常识

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

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

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

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

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

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

12、测试中由别人和本身所带来的欺诈有哪些？（第17章和第18章）

　　当本身想快速清除缺陷和交付产品时，要特别注意别人推荐的测试工具，可能这个工具就是一个欺诈。当咱们但愿全部事情都进展顺利，可能也是对本身的一种欺骗。

　　一、第三方测试工具引起的欺诈

　　1.1 测试工具欺诈场景

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

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

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

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

　　4）当提供商宣称工具能够测试不少项目时。不要相信。工具只是工具，他们须要会思考的人进行有意义的操做。

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

　　这些欺诈方法老是承诺坐享其成。惟一可以坐享其成的只有后悔。若是某件事好德不像是真的，那它可能就不是真的。

　　二、自我忘却型欺诈

　　有不少欺诈时咱们无心中忘却而犯下，当咱们但愿让全部事情都进展顺利，可能就会生产一些不真实的数据。

　　1）推迟文档化

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

　　2）测试报告不明确

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

　　3）伪造测试报告

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

　　4）不能区分数量和质量

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

　　5）过度关注报告的形式