构建之法读书笔记05
阅读之前：
Bug之前就听说过，玩游戏也有bug，当然游戏就是一款软件，bug的解决大概也就是修改原有代码吧；那什么才是一款好的软件呢？
第十三章：软件测试
软件测试是一个重要且复杂的工作。首先，要想统一团队思想就要了解一些基本的知识：Bug（软件的缺陷）、Test Case（测试用例：描述一个完整的测试过程，测试环境、输入、期望的结果等）、Test Suite（测试用例集：一组相关的测试用例）。
软件测试可以按测试设计的方法分类，按测试的目的分类，也可以按测试的实际和作用分类。设计测试有两类方法：黑箱（Black Box，指测试过程中，把软件系统当成一个无法了解或使用系统的内部结构及知识，也叫作行为测试设计，从软件的行为而不是内部结构出发来设计软件）和白箱（White Box，在测试过程中，可以看到软件系统的内部结构，可以根据结构以及知识来选择测试数据以及具体方法），实际上，我们不要纠结于测试设计方法，更应该同时结合这两种方法，让结果更加可信。测试目的也可分为两种：功能测试和肺功能测试。
测试方法也有许多种：单元测试，代码覆盖率测试，构建验证测试，验收测试，“探索式”的测试，回归测试，场景/集成/系统测试，伙伴测试，效能测试（设计负载（细化），令用户满意的服务质量（细化）），压力测试（沿着用户轴延长、沿着时间线延长），内部/外部公开测试，易用性测试，“小强”大扫荡（BUG Bash）。实战中的测试是在项目中的稳定阶段执行的，团队的核心任务是：在满足最低接受条件的前提下，提高各个部分的质量，需要我们做的就是改正似是而非的测试观念，重视测试工作中的文档（测试设计说明书、测试用例、错误报告、测试修复，关闭缺陷报告、测试报告、），善于利用测试工具，有错就要及时修改，团队成员之间的交流与协作也是极为重要的。
第十四章：质量保障
软件的质量究竟是什么？这是我们要放在首位要搞懂的东西。软件，就是要符合用户以及利益相关者的需求，总结起来就是：软件质量=程序质量+软件工程质量。程序的质量体现在软件外在功能的质量，是否具备应有的功能。软件工程的质量，软件的开发过程有三个重要的特性：“好”，“快”，“便宜”，“好”指的就是软件即程序的质量，因此软件工程方面的质量与“快”、“便宜”比较相关，短期提高程序质量也许很简单，但是软件工程的质量就需要长时间的过程来提高，具体体现在以下方面：软件非法过程的可见性、软件开发过程的风险控制、软件内部那模块，项目中间阶段的交付质量，项目管理工具的因素、软件开发成本的控制、内部质量指标的完成情况。
为了更好地管理项目，使用CMMI（Capacity Maturity Model Inegrated，能力熟练度模型集成）模型，不仅能降低项目的成本，而且提高了项目的质量和按期完成率。质量的成本由以下几部分组成：预防、评审、内部故障、外部故障、流程分析改进。软件的测试也是一个大问题，我们要①尽管有专人负责软件的测试，但是保证质量仍然是所有成员的职责；不要太过信任“专业人士”，还是要有专人独立检查质量；不要完全着眼于自己的绩效而优化，这会导致局部最优而全局未必如此的局面，我们该做的，应该将全局放在第一位；不要拘泥于画地为牢的分工；不要无明确责任的分工。只有这样，我们做出的软件才有质量保障，能满足用户的需求。
个人体会：
这两章主要是从做软件的后期以及全局出发。首先就是软件的最基本保证，就是软件测试。开始我简单的以为，作为组内的成员，既然已经专门设置了软件测试人员这一职务，索性所有的软件测试工作都尽数交给他即可，我们要做的仅仅就是按照基本要求，将我们的任务要求实现即可，软件的测试不属于我们的工作范畴。实际上，这种想法十分错误，我们既然有自己的任务，就要把它做到尽善尽美，而不是说将问题留给可以解决它的人，就好比垃圾之于清洁工，不是说有清洁工，我们就可以肆无忌惮的随手乱扔垃圾，我们还是要尽我们的一份职责的。测试方法也是多种多样，要想完全掌握，还需要我们不停的学习。软件的质量可谓之为软件项目的根本，如果说一个软件的质量都没有保证，我们还怎么实现用户的需求，我们工作也就毫无意义可言。我们要在工程过程中，在每个部分，不分大小，都尽可能的去以最高的水准去完成，而且也不要仅仅着眼于自己的绩效，而是要将整个团队，全局的质量放到首要位置，这才能让我们的辛苦有价值。