阅读《构建之法》第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模型管理项目，不只下降了项目的成本，还提升了项目质量和定期完成率

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

答：

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

 

第十五章 稳定和发布阶段

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

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

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

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

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

五、招数：最后回归测试：项目临近结束时，全部人员（开发，管理，测试）都要回归测试全部的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每一个人，总会有一段时期是要忍的，可是要知道本身的目标在哪？本身忍的底线在哪？本身给本身制定的原则是不能轻

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

的过程是你最大的财富。

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

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

咱们不难发现，他仍是慢慢获得了本身想要的生活。其实无论本身是什么背景，身处那里，只要本身肯勤奋，努力，坚持，

命运 不会把咱们逼上绝路。咱们的生活必定会愈来愈好。