构建之法阅读笔记05

  阅读了构建之法第十三章及其后面的内容，我对软件测试、软件质量保障、软件稳定和发布有了更深的了解和认识。

  第十三章的主要内容是软件测试，这一章介绍了很多关于测试的方法，比如说单元测试，代码覆盖率测试，构建验证测试，验收测试等。Bug被分解为：症状（Symptom）、程序错误（Fault）、根本原因（Root Cause）。往往我们所发现的只是软件的症状bug，也就是一些从用户角度出发由非法输入引发的程序闪退等。这种bug往往不会带来太大麻烦，只会让用户体验感大打折扣。而深入一层的程序错误就比较严重了。所谓程序错误，即从代码的角度看，代码的什么错误导致了软件的问题。例如，代码在输入为某种情况下访问了非法的内存地址——0X0000000C。这会使程序根本无法调试运行，也会给程序员带来极大麻烦。根本原因则是在编码过程中可能一开始的设计思路就有问题。这些或大或小的bug让我们必须对软件进行测试。测试设计有两类方法：黑箱（Black Box）和白箱（White Box）。黑箱：指的是在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。白箱：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法。在我看来黑箱测试会比白箱测试好一点，因为我们作为程序的开发者，往往在测试时会被自己的代码所限制而导致不能尽可能全面地测试，而抛开软件的内部结构，选择各种方法去测试软件则会使软件更加稳定。

  实战中的测试是在项目的稳定阶段执行的。团队在这一阶段的核心任务是：在满足最低接受条件的前提下，提高各个部分的质量。我们经常会因为一些bug而不得不舍弃一些我们觉得自己做的很炫的东西。这都是在所难免的。我们往往在测试阶段做的最多的事情就是找bug而总是忘掉了对文档的书写和保存。书中提到，在计划阶段，我们就要制定测试计划（Test Plan），特别是测试总纲。然后还要写测试设计说明书（TDS）、测试用例（Test Case）、程序错误报告（Bug Report）和测试报告（Test Report）。这些我们真正做到的团队很少，也正是少量的练习与积累，让我们在面对bug时感到很头疼。因此会有一种，不是我们再找bug，而是bug找到了我们的感觉。在以后的软件测试阶段我们应该先制定好测试设计说明书（TDS）、测试用例（Test Case）而不是在电脑前守株待兔，等着bug跳到我们眼前。

  软件的开发看似是一项很简单的工作，用户告诉软件工程师自己需要什么，软件工程师在此基础上开发了各种完美的功能，按时交付给用户。看似两者皆大欢喜，实则不然。这里就牵扯到了软件的质量问题。如何衡量既然软件工程的质量对最终软件的质量有举足轻重的意义，人们当然希望衡量一下各个机构的软件工程质量究竟如何，其中一套比较成熟的理论是CMMI（全称Capacity Maturity Model Inte-grated，能力成熟度模型集成）。资料显示，运用CMMI模型管理项目，不仅降低了项目的成本，而且提高了项目的质量和按期完成率。要达到一定的软件质量，是要付出成本的。SWEBOK特别定义了软件质量成本（Cost of Software Quality，CoSQ）的组成部分，其中包括预防、评审、内部故障、外部故障这四个方面，作者认为还要加上流程分析改进、投资改进等各种成本。因此一款好有质量保障的软件想要开发出来不单单仅靠简单的编码就可以实现了，还需要对软件的测试及维护。

  我们目前所处的阶段主要是停留在编程层面的，而我们的测试能力和对软件的质量保障和稳定发布还有待提高。在以后的团队开发中，我们在练习自己编程能力的同时也不能忘了对各类文档的书写与总结，软件开发不能急于求成，我们要学习的还有很多。