构建之法05

      第十三章写的是软件测试，软件测试的主要步骤有单元测试、集成测试和确认测试。

　　单元测试也称模块测试。通常单元测试可放在编码阶段，程序员在编写好一个模块后，总会（也应该）对自己编写的模块进行测试，检查它是否实现了详细设计说明书中规定的模块功能和算法。单元测试主要发现编码和详细设计中产生的错误，通常采用白盒测试。

　　测试一个模块时需要编写一个驱动模块和若干个桩（stub）模块，如下图所示。驱动模块的功能是向被测试模块提供测试数据，驱动（即调用）被测模块，并从被测模块中接受测试结果。桩模块的功能是模拟被模块所调用的子模块，它接受被测模块的调用，检验调用参数，模拟被

　　调用的子模块功能，把结果送回给被测模块。在模块结构图中，顶层模块测试时不需要驱动模块，最底层的模块测试时不需要桩模块。

　　集成测试也称组装测试，它是对由各模块组装而成的程序进行测试，主要检查模块间的接口和通信。集成测试主要发现设计阶段产生的错误，通常采用黑盒测试。

　　集成的方式可分成非渐增式集成和渐增式集成。非渐增式集成是先测试所有的模块，然后把这些模块集成在一起对整个程序进行测试。渐增式集成是将单元测试和集成测试合并在一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它同已经测试好的模块组合在一起对整个程序进行测试，每次增加一个模块，直至所有模块全部集成在程序中。

　　渐增式集成又可分成自顶向下集成和自底向上集成。自顶向下集成先测试上层模块，再测试下层模块。由于测试下层模块时它的上层模块已测试过，所以可以用其上层模块作为它的驱动模块，而不必另编驱动模块。自底向上集成先测试下层模块，再测试上层模块。同样道理，在自底向上集成时可用下层模块作为上层模块的桩模块，而不必另外编写桩模块。

　　确认测试的任务是检查软件的功能、性能及其他特征是否与用户的需求一致，它是以需求规格说明书（即需求规约）作为依据的测试。确认测试通常采用黑盒测试。

　　确认测试首先测试程序是否满足需求规格说明书所列的各项要求，然后要进行软件配置复查，特别是文档是否齐全，各方面的质量是否符合要求等。如果一个软件是为某个客户定制的，那么最后由客户来实施验收测试（acceptance testing），以便客户确认该软件是否他所需要的。如果一个软件是作为产品被许多客户使用的话，那不可能为每个客户进行验收测试。大多数软件生产者使用一种Alpha测试和Beta测试的过程，来揭露仅由最终用户才能发现的错误。

　　Alpha测试是在开发者的现场由客户来实施的，被测试的软件是在开发者从用户的角度进行常规设置的环境下运行的。Beta测试是在一个或多个客户的现场由该软件的最终用户实施的。与Alpha测试不同的是，Beta测试时开发者通常是不在场的。Alpha测试和Beta测试除了进一步发现程序中的错误外，还能发现使用上的问题。经过确认测试后的软件通常就可交付使用了。

      第十四章强调的是质量保障，软件质量包括程序的质量，软件工程的质量，软件工程的质量体现在一下方面：软件开发过程的可见性、软件开发过程的风险控制、软件内部模块，项目中间阶段的交付质量，项目管理工具的因素、软件开发成本的控制和内部质量指标的完成情况。运用CMMI模型管理项目，不仅降低了项目的成本，还提高了项目质量和按期完成率。

      软件的质量需要测试人员的努力。首先在需求讨论上，测试人员可以站在客户角度上来阐述自己的观点，和产品人员、开发人员等进行充分的交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。其次，在开发过程中，测试人员不仅扮演“用户代表”角色，而且可以及时提供更全面的质量反馈，包括代码质量、接口一致性等。测试人员不写代码，可以参与代码复审（code review），将质量问题及时提交给项目组，保证在产品构造的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。然后测试人员还是可以参与单元测试。即使单元测试由开发人员做，测试人员可以推进开发人员进行单元测，检查单元测试状态，如确保单元测试达到80%以上覆盖率，以及帮助开发人员开发出具有良好可测试性的代码。即使在敏捷方法中，集成测试、端到端（end-to-end）测试、性能测试等是不可少的。因为在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块/组件），集成测试和端到端（end-to-end）测试显得更重要。测试人员在功能测试上工作量会降低，但在这些测试上发挥更大的作用。随着迭代的不断深入，回归测试的工作量很大，这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本，这也是一种持续的努力，使回归测试自动化。最后测试人员对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。

      第十五章则是写稳定和发布阶段，应对软件发布前软件出现的各种问题需要以下方面：1.会诊小组：软件团队的各个角色代表组成会诊小组。处理每一个影响产品发布的问题2.复杂项目的会诊：在稳定阶段的初期，团队只要决定需要修复哪些缺陷，然后团队成员就会进行必要的设计、实现、测试工作，并签入代码修改3.招数：设计变更：重写或重构4.招数：ZBB：把这一版本的构建把所有已知的Bug都解决掉5、招数：最后回归测试：项目临近结束时，所有人员（开发，管理，测试）都要回归测试所有的Bug6.招数：砍掉功能7.招数：修复Bug的门槛逐渐提高8.招数：逐步冻结，随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。

      第十六章写的是IT行业的创新，任何技术都有自身的发展规律，随着一个新技术经历不同的阶段，工总对它的期望值、炒作值也有很大的差别

1.技术触发期2.期望膨胀期3.迷茫期4.低调发展期5.主流发展期

      第十七章 写的是人，绩效和职业道德，团队成长有以下几个阶段：萌芽阶段、磨合阶段、规范阶段和创造阶段。