本学期第六周我阅读了《构建之法》的第13-15章。
第十三章讲的是软件测试，介绍了各种测试方法(包括单元测试、代码覆盖率测试、构建验证测试、验收测试、探索式的测试、回归测试、场景/集成/系统测试、伙伴测试、效能测试、压力测试、内部/外部公开测试、易用性测试、小强大扫荡等等)、实战中的测试以及测试工具等。
通过对这一部分的学习，我认为在测试过程中，我们不是不鼓励开发人员主动帮助测试，而是我们是要避免导致职责不清的越界行为。我们在测试经验交流的过程中，总会与其他同伴有不同的见解。在测试的过程中，可以选定一个典型用户（Persona），然后按照典型人物的思路和看问题的角度，把整个系统的各项功能都经历一遍。如果有什么你觉得典型用户不满意的，那就可以考虑开一个Bug。
第十四章是质量保障，里边主要讲到软件的质量，即软件质量=程序质量+软件工程质量，由此可以看出“程序的质量”和“软件工程的质量”影响软件的质量很大。并且讲到了软件工程的质量如何衡量，即用CMMI(全称Capacity Maturity Model Integrated，能力成熟度模型集成)最后讲到了软件的质量保障工作，介绍了一些与测试的角色相关的问题。
我认为在初始阶段（新项目，团队进入一个新领域，人员刚进入一个项目），每个团队成员都要尽量打通各个环节，多负责，把所有事情都搞懂，培养通才。当项目/产业发展到一定阶段（进入阵地战的时候），要大力提倡分工合作，培养专才。同时，要把好的工具和流程集成起来，从每日构建，到基本功能的自动化，都要尽快实现。
第十五章主要讲的是代码的稳定和发布阶段，其中介绍了软件团队的血型、会诊小组、复杂项目的会诊(包括三个方面：1、开发者提交参加会在的BUG和修改方案；2、会议决定是否同意修改方案；3、执行)，还有不同频率和不同覆盖范围的渐进发布，以及发布之后的事后诸葛亮会议。
软件的测试完后，接下来就是软件的稳定，以及发布阶段了。我们身为软件的开发者，自然会了解到我们的软件有哪些不好的，有哪些缺陷，书本有建议几种方法让程序保持稳定：设计变更，砍掉功能，修复Bug的门槛逐渐提高等。在发布后，书中提到的“事后诸葛亮会议”。确保大家不会因为一个里程碑的结束而一哄而散，没了踪影。
通过这几章的学习，我认为如果一个团队是认真严肃地做软件，那他们一定要考虑如何保证程序的质量/软件工程的质量，以及达到这些质量，需要多少成本。