阅读《构建之法》第13-17章（包含读后感）

第十三章 软件测试

问题：软件测试的步骤有哪些？

答：测试步骤

　　　软件测试的主要步骤有单元测试、集成测试和确认测试。

　　1.单元测试（unit testing）

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

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

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

　　2.集成测试（integration testing）

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

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

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

　　3.确认测试（walidation testing）

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

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

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

第十四章　质量保障

问题：软件质量包括哪些方面？如何衡量软件工程的质量？

答：软件质量包括程序的质量，软件工程的质量，软件工程的质量体现在一下方面：

1.软件开发过程的可见性

2.软件开发过程的风险控制

3.软件内部模块，项目中间阶段的交付质量，项目管理工具的因素

4.软件开发成本的控制

5.内部质量指标的完成情况

运用CMMI模型管理项目，不仅降低了项目的成本，还提高了项目质量和按期完成率

问题：测试人员如何体现工作的价值？

答：

首先在需求讨论上，测试人员可以站在客户角度上来阐述自己的观点，和产品人员、开发人员等进行充分的交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

在开发过程中，测试人员不仅扮演“用户代表”角色，而且可以及时提供更全面的质量反馈，包括代码质量、接口一致性等。测试人员不写代码，可以参与代码复审（code review），将质量问题及时提交给项目组，保证在产品构造的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。

测试人员还是可以参与单元测试。即使单元测试由开发人员做，测试人员可以推进开发人员进行单元测，检查单元测试状态，如确保单元测试达到80%以上覆盖率，以及帮助开发人员开发出具有良好可测试性的代码。

即使在敏捷方法中，集成测试、端到端（end-to-end）测试、性能测试等是不可少的。因为在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块/组件），集成测试和端到端（end-to-end）测试显得更重要。测试人员在功能测试上工作量会降低，但在这些测试上发挥更大的作用。

随着迭代的不断深入，回归测试的工作量很大，这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本，这也是一种持续的努力，使回归测试自动化。

测试人员对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。

第十五章 稳定和发布阶段

问题：如何应对软件发布前软件出现的各种问题？

答：1.会诊小组：软件团队的各个角色代表组成会诊小组。处理每一个影响产品发布的问题

2.复杂项目的会诊：在稳定阶段的初期，团队只要决定需要修复哪些缺陷，然后团队成员就会进行必要的设计、实现、测试工作，并签入代码修改

3.招数：设计变更：重写或重构

4.招数：ZBB：把这一版本的构建把所有已知的Bug都解决掉

5、招数：最后回归测试：项目临近结束时，所有人员（开发，管理，测试）都要回归测试所有的Bug

6.招数：砍掉功能

7.招数：修复Bug的门槛逐渐提高

8.招数：逐步冻结，随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。

第十六章 IT行业的创新

问题：创新的时机和创新的招数

答：任何技术都有自身的发展规律，随着一个新技术经历不同的阶段，工总对它的期望值、炒作值也有很大的差别

1.技术触发期

2.期望膨胀期

3.迷茫期

4.低调发展期

5.主流发展期

接下来会列举各种因素、原则分析问题的框架，并讨论。

1.框架介绍：SWOT分析

2.栋梁和加速度

3.技术产品的发展周期 图在书本321

4.效能过剩和竞争的各个阶段 表格在书本322

5.影响产品竞争的各种因素 产品行业因素 公司和市场因素 团队执行因素

6.四个象限划分产品 （1）四种处理方式 维持，抵消，优化，差异化

（2）把招数组合成套路‘打出组合拳

第十七章 人，绩效和职业道德

问题：团队成长有几个阶段？

答：萌芽阶段

磨合阶段

规范阶段

创造阶段

连载《一个程序猿的生命周期》读后感

谈谈如果自己处于那样的位置，会怎么办？博主的经历对自己有什么启发？

如果我处于主人公那样的位置，我也会选择D公司，或者是能够转型的公司，总之不想做七年做的那样重复的工作。

因为这也是对自己各方面能力提高的一次机会，如果不是很喜欢做程序员或者能力很好的话，始终有一天会厌倦，而且

很快被淘汰。第二，自己刚结婚，孩子也不大，换个轻松一点的工作还是有必要的，这样既可以满足自己转型的想法，

又能照顾好妻子和孩子。如果公司工资开始第一点还是问题不大的，因为以后还有升值的空间，只要自己做的开心，认

真做，而且主人公本来就是个勤奋的人。

主人公的工作前的经历，我读得比较慢，而且印象深刻，因为自己和他有点相似，家里因为一些特殊情况，经济不

是很好，要勤工俭学。但是这个过程的确学到很多东西，当然也经历了很多，承受了很多压力，有得有失，不是患得患失。

希望自己能够坚持，坚强，主人公文章中有很多道理都是从自己的实践中得出来的，也是很有用的，下面是一些文章一些

我认为比较好的句子，希望能和大家一起共享，努力在计算机这个行业有所成就。

１人生可能从来不曾选择过，只能一步一步走着，背负着“山哈巴儿”的名声开始人生新的阶段。

２有时候人无法改变自己，可能是因为对现实还抱有幻想或内心对自己的恐惧。

３人生总是曲折的，作为个体是很好理解的，但是生活往往不仅仅是以个体存在的，所以活着的意义也不只是为了自己，

不过我们要坚信前途是光明的。

5人生总会有低谷，重要的是你能否承受光明到来之前的黑暗。

6人生中每次的努力都是播种下的种子，总是有收获的时候，只不过收获的周期有长有短。
7毕业的起点确认很低，不同层次的起点，可以走入社会的心态不太一样，我将以什么样的心态走进社会呢，磨练刚刚开

始。

8每个人，总会有一段时期是要忍的，但是要知道自己的目标在哪？自己忍的底线在哪？自己给自己制定的原则是不能轻

易改变的。人是要自己规划自己的道路的，可能会受到客观因素的影响，但是不起决定因素，谋事在人、成事在天，经历

的过程是你最大的财富。

主人公毕业后的生活也是令我印象深刻，因为他感受到了社会的压力，还有家庭的压力，这样的压力是很恐怖的，不是

每一个人都能承受，我相信要不是主人公从小开始独立，他肯定会崩溃的。从工作，恋爱到结婚，一路过的都不容易，但是

我们不难发现，他还是慢慢得到了自己想要的生活。其实不管自己是什么背景，身处那里，只要自己肯勤奋，努力，坚持，

命运 不会把我们逼上绝路。我们的生活一定会越来越好。