前言：
从2018年10月30日开始，阅读由微软工程师邹欣老师撰写的《构建之法》一书，全书共435页，每天阅读15页，在一个月（30天）完成。每天阅读完成后，需要思考当日的阅读要点和一些思考。
真正让自己感受到积累的效果和伟大！
以下是该书的封面：
| 周序号 | Mon | Tue | Web | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|---|
| 第1周 | 10.30(1~15) | 10.31(16~31) | 11.01(32~47) | 11.02(48~63) | 11.03(64~79) | 11.04(80~95) | |
| 第2周 | 11.05(96~111) | 11.06(112~127) | 11.07(128~153) | 11.08(154~169) | 11.09(170~185) | 11.10(186~201) | 11.11(202~217) |
| 第3周 | 11.12(218~233) | 11.13(234~249) | 11.14(250~269) | 11.15(270~285) | 11.16(286~301) | 11.17(302~317) | 11.18(318~333) |
| 第4周 | 11.19(334~349) | 11.20(350~369) | 11.21(370~385) | 11.22(386~401) | 11.23(402~417) | 11.24(418~435) |
每日打卡阅读和写作：
10月30日打卡：
阅读页码： 1～15页
阅读概要：
今天阅读了《构建之法》的前15页。这一节是整个软件工程的概论，邹欣老师从大家众所周知的一个命题：程序= 数据结构+算法，引出了程序的这一个概念。然后又用一个实际的案例，就是一个家长帮自己的孩子写了一个每天出算术题的小程序，到随着学校老师新提的不断需求，而扩展到一个比较大的系统的软件工程的范畴。引出了一个扩展链：
程序->应用软件->软件服务.
然后又扩展出了整个软件工程的技术名词，包括：
源程序
数据
软件架构
软件设计与实现
源代码管理
配置管理
质量保障
软件测试
需求分析
程序理解
软件维护
服务运营
软件生命周期
项目管理
用户体验
国际化和本地化
软件商业模式
职业道德规范
由此从最原始的公式逐渐推演和扩展：
- 程序= 算法 + 数据结构
- 软件= 程序 + 软件工程
- 软件企业= 软件 + 商业模式
由此得出一个结论：程序（算法，数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。软件从业人员和软件企业的道德操守会极大地影响软件用户的利益。
然后，通过类比人类对飞机的发展阶段：从叠纸飞机（玩具阶段），到用气球实现飞屋环游（业余爱好阶段），再到莱特兄弟发明飞机（探索阶段），再到现在的商业大飞机（成熟的产业阶段）。作者指出一个软件的开发阶段也是从简单到复杂的阶段，并且进行了对比，指出在每一个阶段如果成功或失败，会引起的不同结果。
在大家对软件工程有了一个模糊的印象后，作者用专业化的定义对软件工程做了定义。同时又指出了软件的特殊性。
然后针对目前全国各大高校，开的与计算机和软件相关的专业，指出了这些专业在培养侧重点方面的区别。
通过这一天的阅读，对软件工程的了解，也从原来的模糊逐渐到清晰。而作为身在其中的工程人员，也清楚了自己在整个软件工程中的定位，其中的很多词汇也都是平时自己工作中耳熟能详的。
期待明天的继续阅读！
10月31日打卡：
阅读页码： 16～31页
阅读概要：
作者之前已经对计算机和软件工程进行了一个大致的描述，相信读者已经跃跃欲试了。然而，作者给大家提了一个醒，就是关于如何去衡量一个软件是否合格的标准或评价。那就是软件测试了！
接下来作者讲解了软件测试的概念和一些分类。
软件测试的概念：
软件测试的分类：
（1）单元测试
（2）回归测试
（3）用户测试
结合一个例子，作者讲解了这三类软件测试的概念和区别。
11月01日打卡：
阅读页码： 32～47页
阅读概要：
作者针对之前提到的软件测试，介绍微软发明的一套用于程序性能的工具：
在微软Visual Studio中选择Tools->Performance Tools->Performance Wizard，可以进行两种方式的效能分析：抽样（Sampling）和代码注入（Instrumentation）。
并且针对一个具体的程序，统计词频的程序，来讲解如何用这两种方法来进行分析和性能改进。而后，作者又强调：虽然优化很重要，但是如果我们不经分析就盲目优化，也许只会事倍功半。
然后作者开始讲述软件的个人开发流程，有CMMI（软件能力成熟度模型）和PSP（Personal Software Process），主要讲解后者对软件开发流程的分配。
并且对大四学生和工作三年的软件开发工程师，针对PSP这套模型，得出了一个时间分配的对比表格。根据对比得出一个结论：
工程师在“需求分析”和“测试”这两方面要花更多的时间（多60%以上）；但是在具体编码上，工程师比学生要少花1/3的时间。从学生到程序员，并不是更加没完没了地写程序。
然后作者又指出了目前在高校中，软件设计作业的局限性。就是无法体现出真正的软件工程。
师生们身处轰轰烈烈的软件产业大环境，但是在软件工程课上做的题目却是非常简陋，没有起到应有的作用，这的确是一件很有讽刺意义的事情。
作者指出目前软件工程课一个基本的作业“图书馆信息系统”存在着很多问题，并由此对需求进行扩展，指出：
（1）从数据方面扩展
（2）从需求方面扩展
（3）从用户方面扩展
（4）从软件构建方面扩展
等等，指出在开发软件时需要考虑的各种扩展因素。
最后，在本章最后，作者布置了一个作业，实现一个类似wc.exe（代码行统计）的软件作业。并且在布置作业时，非常具体的指出了这个作业的：
基本功能，扩展功能，高级功能。然后，希望学生们按照之前讲的PSP，来记录在完成这个作业的过程中，是如何体会软件工程的各个组成部分的。最后，又指出如何来测试自己所完成作业
的质量。
11月02日打卡：
阅读页码： 48～63页
阅读概要：
今天作者主要讲述的是关于“软件工程师的成长”的话题。相信这个话题也是所有身处这个行业的工程师们最关注的。
要衡量一个软件工程师的能力，那么必须设计一定的衡量指标。就像衡量一个NBA的职业运动员，或者是一个俱乐部的足球运动员，有很多的衡量指标一样，软件工程师也是有很多的衡量指标的。
作者指出，软件项目的确需要创造性，需要一些意外，一些惊喜。但是，更多的是常规的、可重复的任务。一个成熟的软件工程师应该能够降低任务交付时间的标准方差。如果你能长时间稳定而按时地交付工作的结果，内部和外部的顾客就会对你的工作有信心，更喜欢与你合作。
作者讲述了团队对个人的一些期望点。与PSP想对应的一个概念是TSP（Team Software Process），TSP对团队成员的要求如下：
（1）有效的交流；
（2）说到做到，按时交付；
（3）接受团队赋予的角色并按角色要求工作；
（4）全力投入团队的活动；
（5）按照团队流程的要求工作；
（6）时刻做好准备；
（7）理性的工作。
著名的艺术家Chuck Close说：我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续今天的工作，最终你会有所成就。
接下来作者提出了软件工程师的一些思维误区：
（1）分析麻痹；
（2）不分主次，想解决所有依赖问题；
（3）过早优化；
（4）过早扩大化/泛化（Premature Generalization）——画扇画，调侃目标和远景。
接下来作者提出了软件工程师的职业发展，指出了专和精的关系，职业成长，自我评估。
接下来作者根据自己对魔方的真实案例，指出了如何准确地评价自己的能力。并且用一个实际的案例，一个简历上写着是“精通”Visual Studio C#编程的大学生，在进行面试时解决的问题，都是一些最最基本的问题。结果，你发现他把时间都花在“解决（低层次）问题”上了，面试官想考察的“算法技能”、“C#程序设计技能”都无暇顾及。
那怎么提高技能呢？
答案很简单，通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。
作者指出，这正好对应教育理论中的三个区域的理论（舒适区，学习区，恐慌区）。
我们不应该一开始就让自己处于恐慌区，这样会极大的打消自己的学习积极性。而应该选择合适的“学习区”来学习，不断构建自己的舒适区，从而扩展学习区，最后在某些领域达到技能的精通，是一个循序渐进的好办法。
本章的最后，作者还是对大家比较熟悉的魔方，来描述不同的精通程度，相对应的魔方的技能。那么作者如何考察一个“精通”魔方的面试者呢：
（1）给面试者一个打乱颜色的魔方；
（2）要求他把六面还原；
（3）如果还原了，要求他把魔方恢复成面试官最初给他的那个混乱的局面，必须一模一样。
11月03日打卡：
阅读页码： 64～79页
阅读概要：
这部分主要分为两个部分的内容。
前半部分63～67页，是作者针对前面的章节提出的一些课后思考题，诸如：
（1）选哪一种医生；
（2）软件开发到底是工程，还是艺术；
（3）绞刑架和职业发展的故事；
（4）针对案例，在博客中撰写观点；
（5）成长和代码量的关系；
（6）学什么，怎么学，核心竞争力是什么？
（7）各式各样的工程师；
（8）对职业梯子的思考；
等等。
接下来是新的一章：第4章 两人合作
这章主要讲述了代码规范，极限编程，结对编程等概念，以及代码复审的重要概念。
并且详尽地列出了代码规范的一些要求，以及为什么要进行代码审查，如何进行代码审查。
这些都和自己平时的工作有密切的联系，受益匪浅。
11月04日打卡：
阅读页码： 80～95页
阅读概要：
本段依然承接上述，关于代码复审进行描述，包括代码复审的步骤和核查表。
代码复审的核查表包括：
（1）概要部分
（2）设计规范部分
（3）代码规范部分
（4）具体代码部分
（5）效能
（6）可读性
（7）可测试性
接下来讲述了结对编程，描述了结对编码产生的原因，方式。
在关于两人结对编程时，两个人之间如何正确地进行反馈时，作者指出当一个人对另一个人的行为进行反馈时，有三个层次：
（1）最外层：行为和后果；
（2）中间层：习惯和动机；
（3）最内层：本质和固有属性。
在接下来的练习与讨论中，有关于代码审查的讨论，值得深思。
11月05日打卡：
阅读页码： 96～111页
阅读概要：
本章的标题为《团队和流程》。
主要讲解了团队，软件团队模式，开发流程。
开发流程是每一个成熟的软件团队，都必须要制定和遵守的。其中比较著名的开发流程有：
（1）瀑布模型（Waterfall Model）
（2）瀑布模型的各种变形
（3）统一流程（Rational Unified Process, RUP）
（4）渐进交付流程（Evolutionary Delivery），包括MVP和MBP
MVP （Minimum Viable Product, 最小可行产品）， 如互联网公司快速迭代的产品。
MBP（Maximal Beautiful Product, 最强最美产品），如iPhone, iPad等。
最后介绍TSP（Team Software Process）的一些原则。
11月06日打卡：
阅读页码： 112～127页
阅读概要：
本部分是第6章《敏捷流程》，主要讲解敏捷的流程简介，问题和解法，敏捷的团队和敏捷总结。
- 敏捷的流程简介：
主要讲解了敏捷的12条原则：主要包括
（1）尽早并持续地交付有价值的软件以满足顾客需求
（2）敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
（3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
（4）业务人员和开发人员在项目开发过程中应该每天共同工作
（5）以有进取心的人为项目核心，充分支持并信任他们
（6）面对面的交流始终是最有效的沟通方式
（7）可用的软件是衡量项目进展的主要指标
......
敏捷的步骤：
（1）找出完成产品需要做的事情——Product Backlog
（2）决定当前的冲刺（Sprint）需要解决的事情——Sprint Backlog
（3）冲刺
冲刺期间，团队通过每日例会（Scrum meeting）进行面对面的交流。每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时团队要启动每日构建（Continous Integration, CI），让大家每天都能看到一个逐渐完善的版本。
Scrum master根据项目的情况，可以用燃尽图，任务看板等，显示任务完成进度。
冲刺阶段，是以时间驱动的（Time-boxed）。时间一到就结束。
（4）得到软件的一个增量版本，发布给用户。
-
敏捷流程的问题和解法
针对上面提到的敏捷流程的四个步骤，每个步骤中都会有一些可能出现的问题。作者结合案例都给予了总结和分析。 -
敏捷团队
敏捷能成功实施的关键在于Scrum master.
敏捷对团队的要求：
（1）自主管理（Self-managing）
（2）自我组织（Self-organization）
（3）多功能型（Cross-functional） -
敏捷总结
作者提出一些思考：
敏捷是很特别的吗？敏捷流程的经验和教训，以及关于敏捷的问答。
11月07日打卡：
阅读页码： 128～153页
阅读概要：
本部分为第7章《实战中的软件工程》。
作者指出，前面的章节介绍了软件开发的各种方法论以及一些原则和宣言。宣言令人激动，但不能代替软件，用户不会看了宣言就掏钱买软件。
因此，作者介绍世界上最大的软件公司——微软公司的方法论——微软解决方案框架（Microsoft Solution Framework, MSF）。
MSF有9条基本原则：
（1）推动信息共享与沟通
（2）为共同的远景而工作
（3）充分授权和信任
（4）各司其职，对项目共同负责
（5）交付增量的价值
（6）保持敏捷，预期和适应变化
（7）投资质量
（8）学习所有的经验
（9）与顾客合作
针对每一个原则，作者都采用问答的方式，来介绍这个原则的具体含义，以及在现实中会遇到的实际问题。
接下来作者介绍了：
MSF团队模型
MSF过程模型
最后作者用微软创业时的实例，讲述了微软的这套框架是如何根据公司的实际情况，从无到有的（MS的软件开发流程的演进）。
11月08日打卡：
阅读页码： 154～169页
阅读概要：
本部分是系列的第8章《需求分析》。
作者在这章主要讲解了：
- 软件需求
- 软件产品的利益相关者
- 获取用户需求——用户调研
- 竞争性需求分析的框架
- 功能的定位和优先级
- 计划和估计
- 分而治之（Work Breakdown Structure）
今天读的是关于需求分析的前4部分。
8.1 软件需求
软件团队如何才能准确而全面地找到用户的需求呢？
（1）获取和引导需求
（2）分析和定义需求
（3）验证需求
（4）在软件产品的生命周期中管理需求
软件的需求，也可以从其他角度来划分，如：
（1）对产品功能性的需求
（2）对产品开发过程的需求
（3）非功能性需求
（4）综合需求
8.2 软件产品的利益相关者
软件团队在分析软件需求时，需要考虑如下这些利益相关者：
用户（User, End-user）
顾客（Customer, Client），这些人不一定是软件的直接用户
市场分析者
监管机构
系统/应用集成商
软件团队
软件工程师
8.3 获取用户需求——用户调研
本节作者介绍了几种，用于用户调研的方法。
8.4 竞争性需求分析的框架
NABCD是一个有效的方法。
N（Need, 需求）
A, Approach, 方法
B，Benefit, 好处
C，Competitors，竞争
D，Delivery，推广
11月09日打卡：
阅读页码： 170～185页
阅读概要：
本部分是接上一天的内容，继续介绍需求分析的四个点。
8.5 功能的定位和优先级
（1）杀手功能/外围功能
（2）必要需求/辅助需求
作者用四个象限的方法，指出每一组组合，软件团队应该采取的措施和态度去应对这些需求。
8.6 计划和估计
（1）目标、估计和决心
（2）找出估计后面的假设
（3）提高估计能力的招数
8.7 分而治之
WBS，通常从最终的产品开始，一层一层往下，把大型交付件分割为小型、具体的交付件。
WBS的基本原则如下：
（1）保证所有的子节点覆盖了全部父节点包含的内容
（2）保证各个子节点不要相互覆盖
（3）叶子节点要保证足够小，能在一个里程碑中完成
（4）从结果出发构建WBS，而不是从团队的活动出发
11月10日打卡：
阅读页码： 186～201页
阅读概要：
本部分开始第9章《项目经理》。
PM有几种分类。
Product Manager
Project Manager
Program Manager
PM的核心要求是：根据市场和用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化产品。
作者接下来介绍了微软PM 的来历。
主要是解决：
交流成本问题
开发和测试搞不定的事情
PM做开发和测试之外的所有事情
成为合格的PM，需要具备的能力：
（1）观察、理解和快速学习的能力
（2）分析管理能力
（3）一定的专业能力
（4）自省的能力
PM的领导力——高效的团队讨论
11月11日打卡：
阅读页码： 202～217页
阅读概要：
本节阅读主要分为两个部分。
第一部分是接着昨天的阅读，关于PM的领导力——高效的团队讨论的介绍。
组织会议的人应该做到：
（1）明确会议目的，要解决的问题是什么；
（2）推动会议进程，促使与会者在每一个阶段做合适的事情；
（3）总结会议，记录要点。
会议的思维活动包括：
（1）理清事实
（2）表达直觉和感情
（3）从乐观的角度分析问题
（4）从悲观的角度分析问题
（5）从创意角度去分析问题
总结：
改进会议的方法：大家同时从一个角度出发分享，进行类似的思维活动，然后转到另一个角度。
（备注：这个和之前我在得到上订阅的刘润的《5分钟商学院》中的开会议的六顶帽子有异曲同工之妙～）
9.5 PM和风险管理
PM要在整个项目的生命周期管理风险。对于软件项目来说，风险是在正常软件生命周期事件之外的，可能发生的影响项目的成功的事件。
风险管理的几个层次：
第一层次：啊呀！大问题（Crisis!）
第二层次：缓和并防止问题
第三层次：预计（Anticipation）
第四层次：把问题变为机会（Opportunity）
接下来是第10章 典型用户和场景
该章主要分为：
- 典型用户和典型场景
（1）Visual Studio的典型用户
（2）典型用户的价值
（3）怎么定义典型用户
（4）从典型用户到场景
（5）从场景到任务
（6）场景/故事/Story的模板
11月12日打卡：
阅读页码： 218～233页
阅读概要：
本节续前一天的章节，主要讲述了典型用户到场景的部分。
（4）从典型用户到场景
典型用户和他要达到的目标要相互对应。对于每一个目标，列出达到目标所必须经历的过程，这就是场景。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。
银行从业者的一次经历，体会本行“ATM无卡取现”功能的强大：
特意带上手机和令牌，不带银行卡，感受一下我行ATM的无卡取现，结果连自助银行的门儿都没进去，不刷卡怎么开门啊......
（5）
明确了场景的概念后，接下来由架构设计师和各个模块的负责人一起，沿着子系统/模块的所属关系把场景划分开。
不同的任务将会把一个场景编织起来，虽然有多个开发者参与这项工作，但是应该有一个开发者对整个场景负责。得到开发任务后，就可以创建和分配测试任务。
10.2 用例（Use Case）
用例也是很常用的需求分析工具。用例的基本构成元素：
（1）标题
（2）角色
（3）主要成功场景
（4）扩展场景
使用Use Case的原则如下：
（1）通过讲简单的故事来传递信息
（2）保持对全系统的理解
（3）关注用户的价值
（4）逐步构建整个系统，一次完成一个用例
（5）增量开发，逐步构建整个系统
（6）适应团队不断变化的需求
10.3 规格说明书（Specification, Spec）
10.3.1 功能说明书
功能说明书从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率、国际化、本地化、异常情况等，不涉及软件内部的实现细节。
写Spec的一个基本步骤：
（1）定义好相关的概念
（2）规范好一些假设
（3）避免一些误解，界定一些边界条件
（4）描述主流的用户/软件交互步骤
（5）一些好的功能还可能有副作用
（6）服务质量的说明
10.3.2 功能说明书的模板
10.3.3 技术说明书
技术说明书又叫设计文档，它用于描述开发者如何去实现某一功能，或相互联系的一组功能。
设计文档应该说明工程师的设计是如何体现下列原则的：
（1）抽象
（2）内聚/耦合/模块化
（3）信息隐藏和封装
（4）界面和实现的分离
（5）如何处理错误情况
（6）程序模块对于运行环境、相关模块、输入输出参数有什么假设？这些假设和相关的人员验证过么？
（7）应对变化的灵活性
10.4 功能驱动的设计
如何才能把用户的需求变成团队成员可以直接操作的开发工作，然后源源不断地实现这些需求？
功能驱动的设计（Feature Driven Design, FDD）是一种方法。
该方法论的原则如下：
第一步，构造总体模型
第二步，构造功能列表
第三步，制定开发计划
第四步，功能设计阶段
第五步，实现具体功能
11月13日打卡：
阅读页码： 234～249页
阅读概要：
本次阅读开始新的章节，第11章，软件设计与实现
11.1 分析和设计方法
11.2 图形建模和分析方法
11.3 其他设计方法
11.4 从Spec到实现
11.5 开发阶段的日常管理
11.6 实战中的源代码管理
11.7 代码完成
以下依次进行介绍：
11.1 分析和设计方法
写软件是为了解决用户的需求，整个软件开发周期我们需要表达、传递和处理下面的这些信息：
（1）需求分析阶段：
在问题领域的现实世界里，都有哪些实体，如何抽象出我们真正关心的属性，实体之间的关系是什么，在这个基础上，用户的需求是什么，软件如何解决用户的需求。
（2）设计与实现阶段：
软件是怎么解决需求的？现实世界的实体和属性在软件系统中是怎么表现和交换信息的？
（3）测试和发布阶段：
软件真的解决了用户需求了吗？软件解决需求时候的效率如何？用户还有什么新需求？
11.2 图形建模和分析方法
我们要给事物建造出一个“模型”，描述事物、事物的属性、事物之间的关系（静态的）以及各个事物之间的信息传递（动态的）。
11.2.1 表达实体和实体之间的关系
11.2.2 表达数据的流动
11.2.3 表达控制流
11.2.4 统一的表达方式
11.5 开发阶段的日常管理
11.5.1 闭门造车
11.5.2 每日构建（Daily Build）
11.5.3 构建大师
11.5.4 宽严皆误
11.5.5 小强地狱
小强地狱——让Bug多的队员专心修复Bug，不要开发新功能。
11月14日打卡：
阅读页码： 250～269页
阅读概要：
本次阅读紧接着昨天的阅读。
11.6 源代码管理
软件工程的质量要靠软件工具和软件流程来保证。
软件的源代码管理工具，加上构建系统，能保证一个复杂软件在多个角色、多个团队的合作下，按时以合适的质量发布。如果你写一个Hello World程序，当然不需要这些工具，就像你用儿童积木搭房子过家家那样，但这不是建筑工程。
11.7 代码完成
如果项目管理有两个主要的工作项类型：Task, Bug。那这个阶段就是所有的代码任务都完成了。
也许我们现在还有许多缺陷（Bug），还有一些与测试相关的任务。这些要留到以后稳定阶段才能全部解决。
接下来开始全新的一章， 第12章，用户体验
12.1 用户体验的要素
12.1.1 用户的第一印象
用5W1H来衡量用户体验：
Who
When
Where
What
Why
How
12.1.2 从用户的角度考虑问题
12.1.3 软件服务始终都要记住用户的选择
长期使用之后，软件会更好用么？
a. 软件用得越多，一样难用
b. 软件用得越多，越发难用
c. 软件用得越多，越来越好用
12.1.4 短期刺激和长期影响
12.1.5 不要让用户犯简单的错误
12.1.6 用户体验和质量
12.1.7 情感设计
11月15日打卡：
阅读页码： 270～285页
阅读概要：
本节继续昨天的讲解，用户体验
12.2 用户体验设计的步骤和目标
用户体验设计的一个重要目的就是要降低用户的认知阻力，即用户对于软件界面的认知和实际结果的差异。
用户体验设计的步骤：
（1）概要设计
（2）行为（交互）设计
（3）界面设计
12.3 评价标准
（1）尽快提供可感触的反馈
（2）系统界面符合用户的现实惯例
（3）用户有控制权
（4）一致性和标准化
（5）适合各类型的用户
（6）帮助用户识别、诊断并修复错误
（7）有必要的提示和帮助文档
12.4 贯穿多种设备的用户体验
接下来进入全新的一章，第13章 软件测试
13.1 基本名词解释及分类
Bug
Test Case
Test Suite
Bug可以分解为：
症状
程序错误
根本原因
13.1.1 按测试设计的方法分类
黑箱和白箱测试
13.1.2 按测试的目的分类
- 功能测试
- 非功能测试
13.1.3 按测试的时机和作用分类
13.2 各种测试方法
13.2.1 单元测试和代码覆盖率测试
13.2.2 构建验证测试
13.2.3 验收测试
13.2.4 探索式的测试
13.2.5 回归测试
13.2.6 场景/集成/系统测试
13.2.7 伙伴测试
13.2.8 效能测试
13.2.9 压力测试
13.2.10 内部/外部公开测试（Alpha/Beta Test）
13.2.11 易用性测试
13.2.12 小强大扫荡
11月16日打卡：
阅读页码： 286～301页
阅读概要：
现在是11月27日了。虽然上周末已经终于把这本书看完了，但还是无法保证及时地把内容摘要记录下来。看来一件事，要坚持一个月不动摇，还真的是很难的呀。
这节还是接上一次内容，主要讲解了测试的知识。
包括：上一节提到的13.2.5～13.2.12的全部内容。
关于13.2.6的场景/集成/系统测试：
在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，各方面均能满足用户的需求。这类测试叫系统/集成测试。
（我之前在公司的时候，还给新同事进行过类似的培训，关于单元测试，集成测试，验收测试的区别）
但是作者在这里提到一个疑问——那到底应该什么时候做集成测试呢？是不是越早越好？
答：原则上是当一个模块稳定的时候，就可以把它集成到系统中，和整个系统一起进行测试。在模块本身稳定之前就提早做集成测试，可能会报出很多bug。但是这些由于提早测试而发现的Bug，有点像汽车司机在等待绿灯时不耐烦而拼命地按喇叭——也就是说，有点像噪音。所以，测试也需要把握时机。
关于13.2.8 效能测试
用户使用软件，不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平。软件的效能是这些“非功能需求”或者“服务质量需求”的一部分。
以下的概念包括：
设计负载：首先要定义什么是正常的设计负载。从需求说明出发，可得出系统正常的设计负载。
令用户满意的服务质量
设计负载的细化
服务质量的细化（现实的静态数据，现实的动态数据）
关于13.2.9 压力测试
压力测试严格地说不属于效能测试。压力测试要验证的问题是：软件在超过设计负载的情况下，是否仍能返回正常结果，没有产生严重的副作用或奔溃。
在测试的时候，如何增加负载呢？可以从以下两个方面来考虑：
-
沿着用户轴延长
比如，以购物网站为例，正常的负载是20个请求/秒钟。如果有更多的用户登录，怎么办？那么负载就会变成30、40、100个请求/秒钟，或更高。 -
沿着时间轴延长
网络的负载有时间性，负载压力的波峰和波谷相差很大，那么如果每时每刻负载都处于波峰，程序会不会垮掉？这就是沿着时间轴延长。一般要模拟48小时的高负载才能认为系统通过测试。
13.3 实战中的测试
13.3.1 似是而非的测试观念
13.3.2 测试工作中的文档
（1）测试设计说明书（TDS）
（2）测试用例（Test Case）
a. 等价类划分
b. 边界值分析
c. 决策表、因果图和功能图方法
d. pair-wise和正交实验设计方法
（3）错误报告
（4）测试修复，关闭缺陷报告
（5）测试报告
11月17日打卡：
阅读页码： 302～317页
阅读概要：
本节接上一天的讲解，主要讲解：运用测试工具进行测试。
13.4 运用测试工具
13.4.1 运用工具记录手工测试
13.4.2 运用工具记录自动测试
13.4.3 如何测试效能
除了测试功能方面，还需要测试服务质量，如效能测试, 负载测试，压力测试.
体会一下这三种测试的区别：
（１）效能测试：在１００个用户的情况下，产品搜索必须在３秒钟内返回结果．
（２）负载测试：在２０００个用户的情况下，产品搜索必须在５秒钟内返回结果．
（３）压力测试：在高峰压力（４０００个用户）持续４８小时的情况下，产品搜索的返回时间必须保持稳定．系统不至于崩溃．
备注：不同的角色在开发过程中有相互合作，相互制约的作用，不能替代．测试人员在做验证测试时，需要做多方面，多平台的测试，这些工作量，也许远远超过了开发人员的能力范围．因此，必须要由测试人员来验证并处理已经修理好的bug．
接下来开始新的一章： 第１４章 质量保障
记住如下的公式：
软件（质量） ＝ 程序（质量） ＋ 软件工程（质量）
程序的质量体现在软件外在功能的质量．
软件工程的质量，则体现在如下方面：
（１）软件开发过程的可见性
（２）软件开发过程的风险控制
（３）软件内部模块，项目中间阶段的交付质量，项目管理工具的因素
（４）软件开发成本的控制
（５）内部质量指标的完成情况
１4.1.3 软件工程的质量如何衡量
一个比较成熟的理论是ＣＭＭＩ：Ｃapacity Maturity Model Integrated, 能力成熟度模型集成．
ＣＭＭＩ总共分为五级．
初始级，管理级，明确（定义）级，量化管理级，优化级．
ＣＭＭＩ有两种不同的实施方法，其级别表示不同的内容：
（１）连续式：主要是衡量一个企业在某一项目中的管理能力
（２）阶段式：主要是衡量一个企业的成熟度．
１4.1.4 质量的成本
预防
评审
内部故障
外部故障
流程分析改进
提高职业技能
技术投资
１４.2 软件的质量保障工作
要注意软件测试和软件质量保障的区别．
软件测试：运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作流程和结果通常是可量化的．正因为流程和结果是明确定义的，可量化的，所以很多测试工作可以自动化．
软件质量保障：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试活动．
14.2.1 测试的角色（Test）要独立出来么
独立的测试角色从用户的角度出发验证产品质量．独立专业的测试等同于代表客户对产品进行认证．
任何产品成熟到一定阶段，独立的质量保障角色都是不可避免的．团队内部有QA角色，团队外部也有独立的QA角色．
以药品和食品为例，除了生产厂家自己的检测之外，这些产品还要接受行业主管部门相关机构的检测和认可（药品检验，食品检验），才能上市．出现争议时，还要由第三方机构来进行测试或认证．
１4.2.2 和测试角色相关的问题
问题1 既然有专人负责，那我就不用负责了！
尽管有专人负责测试工作，但是保证质量仍然是所有成员的职责．
问题2 盲目信任“专业人士”扮演的角色
每个角色的水平不一样，水平最差的角色往往对软件质量的影响最大。
问题3 为了自己的角色而做绩效优化
分工之后，每个角色为了自己的绩效而优化，会出现局部最优而全局未必最优的情况。
问题4 画地为牢的分工
有时分工链条过长，信息丢失。一个开发者对自己写的程序有什么潜在问题还是很有感觉的，有些问题可以用文字表述出来（如果开发人员有耐心的话），有些问题是一些预感......现在都交给测试人员了，那么，让他们测吧，我也懒得说了。
分工还可能会导致一个软件的灵魂被切碎分割各个角色，每个功能都做得很卖力，但是整体就是不行，明显看出来是费了老大的劲给强行“集成”起来的。
问题5 无明确责任的分工
11月18日打卡：
阅读页码： 318～333页
阅读概要：
这一节继续上面的关于软件质量保障的章节。
“快速重现用户报过的bug”，这是专业测试人员的价值所在。没有测试人员之后，开发人员并没有负责这个新的任务，他们的主要目标还是“快速开发功能”。
针对bug的修复，也要一级一级地发出去，增加很多成本。
还是那句话，没有责任，就没有质量。
第15章 稳定和发布阶段
15.1 从代码完成到发布
软件生命周期的最后阶段往往是最考验团队的 ，不但考验团队项目管理水平、应变能力，也考验团队的“血型”。
A型：他们知道优秀的软件公司会发布有已知缺陷的软件
B型：他们不相信这一点
O型：他们不知道这一点，因此嘴巴惊讶成O型
AB型：他们对于自己开发的软件是A型，对于别人开发的软件是B型
做商用软件的人都在为此苦恼，只有优秀的软件公司能找到一个平衡点，及时发布能够解决用户问题的软件，并且能及时修改软件中的问题。
看一下关于软件发布的常用名词：
Alpha：指集成了主要功能的第一个试用版本
Beta： 功能基本完备，稳定性较Alpha版本高，用户可以在实际工作中小范围使用。可以有beta1, beta2, beta3, ......
ZBB(Zero Bug Build)
RC(Release Candidate): 发布候选版本， RC1, RC2, ......, 直至RTM为止，版本间隔时间较短
RTM(Release to Manufacturer): 最终发布版本
RTW(Release to Web)
15.1.1 会诊小组
软件团队的各个角色代表（PM/Dev/Test/UX 等）组成了会诊小组，处理每一个影响产品发布的问题。
对于每一个bug， 会诊小组要决定采取下面哪一种行动：
（1）修复
（2）设计本来如此
（3）不修复
（4）推迟
15.1.2 复杂项目的会诊
在项目稳定阶段的初期，团队只要决定需要修复哪些缺陷，然后团队成员就会进行必要的设计、实现、测试工作，并签入代码修改。
但是，随着项目进展和发布日期的临近，团队还要保证修改方案不会给产品带来负面的影响。这时，会诊会议也会有更高的要求，包括以下三个方面：
第一步，开发者提交参加会诊的bug和修改方案；
第二步，会议决定是否同意修改方案；
第三步，执行。
项目接近尾声时，要确保门槛越来越高。
提升门槛是放走一些无伤大雅的bug，换取项目能如期完成。其指导思想是抓大放小，既然没法全解决，就集中精力解决最重要的bug。避免频繁地到处改动代码而引入新的bug，是以谓之”稳定“。
15.1.3 招数：设计变更（Design Change Request）
要分清楚重构和重写的区别：
重构——在尽量保持原有界面的基础上优化部门代码；
重写——重新实现原有功能，同时，要分清是全部重写原有功能，还是偷偷加上许多新的功能。
要记住，项目的当前阶段是一个阻尼振荡的过程，要收敛和稳定。等到下一个版本开始的时候再进行发散的思考吧。
11月19日打卡：
阅读页码： 334～349页
阅读概要：
本节继续前面的介绍。
15.1.4 招数：ZBB
团队要有把Bug都搞定的执行力。ZBB = Zero Bug Build, 即这一版本的构建把所有已知的Bug都解决掉了。
15.1.5 招数：最后回归测试
项目临近结束时，所有人员（开发、管理、测试）都要回归测试所有的bug。每个人都要帮助团队确保这些Bug的确是被修复了，而且别的更改没有导致功能的”回归“。
15.1.6 招数：砍掉功能
软件的三个目标：快、便宜、好。一般团队只能达到三个目标中的两个。
15.1.7 招数：修复Bug的门槛逐渐提高
15.1.8 招数：逐步冻结
15.2 不同频率和不同覆盖范围的渐进发布