这次所阅读的为构建之法第一第二章内容，虽然之前的编程作业中，使用到了一些方法，也接受了一些概念，但没有进行深入了解。这次阅读，便是对这些知识进行理论上的回顾与掌握，深入了解其体系，与之前所为相印证。
第一章：软件概论
在第一章概论中，本书提到了软件这一概念的关键。软件是什么？软件即相当于程序加上软件工程。看完第一章后，我觉得，软件的开发，程序的编写重要，但是对于其工程方面，也需花费心思去攻克。首先，从程序方面上看，程序值指的是源程序，即代码，其对数据进行操作，并获得相应预期的结果。于此同时，还需兼顾解决源代码架构，管理的问题，使得软件的质量有所保证。在软件工程方面，所更需面对的则是与现实息息相关的需求，如所面向的客户的需求，软件维护的需求，项目管理，以及用户体验的需求，更甚者，还有软件营销策略，竞争手段的选择。
什么样的软件才算“足够好”呢？通常的衡量标准有，用户满意度，可靠性，软件流程的质量，可维护性。书中还提到，如何判断一个软件什么时候能“足够好”，可以发布。我觉得，重点其实还有在所面向的用户的选择上。有实际应用又同时完美，即满足所有需求的软件，在世界上是不存在的。但是，对于某一些用户来说，虽然它不够完美，但它恰恰好解决了某一方面的燃眉之急，满足了客户的主要需求，（简单来说，如符合了老师布置作业的要求与规范）那么，它应该就是足够好的，可以发布出去的。
第二章：测试
第二章主要讲的是如何进行各种各样测试。我的收获如下：
单元测试方面：
①单元测试越早进行越好，在后期修复BUG，往往需要花费更多的时间。
②用单元测试试用例子书写技术模块的规格说明书。与此同时，单元测试这个过程还能帮
助程序员记录这个模块的历史和设计变更的理由。
③好的单元测试应该有以下标准：单元测试应该在最基本的方面上验证程序的正确性。单元测试必须由最熟悉代码的人编写（编写者在设计的时候就写好单元测试是最好的）。单元测试后，机器的状态保持不变。单元测试要有效率。同一数据多次重复单元测试所得结果相同（尽量别用随机数进行测试）。可通过认为伪造数据，使得单元测试的结果不依赖于别的测试，保持独立性。单元测试应该覆盖所有代码路径（借此，可对复杂代码，效能问题，同步问题，与外部条件相关问题进行优化）。单元测试应该集成到自动测试的框架中。单元测试必须和产品代码一起保存和版本维护（便于在出现错误时的来源）。
回归测试方面：
回归测试，即在新发行的模块版本上，再次测试之前版本所通过的单元测试，用来确认这个模块有没有出现一个“退化”，即从正常工作的稳定状态，退化到不正常工作的不稳定状态。这个过程很有必要，可以用来改良测试用例基准，或者修复一些发行新版本过程中没考虑到的额外添加的错误。与此同时，回归测试最好也要自动化，因为能提高效率，尽早发现问题，尽早解决。一般在一个项目的最后稳定阶段，还会将之前所发现修复的BUG找出来，进行一次全面的回归测试，以保证所有已经修复的BUG的确得到了修复，没有复发。
性能测试方面：
性能分析主要有两种方法，一是抽样，运行速度快，不用改动程序，易找出瓶颈，但难以得出精确的数据。二是代码注入，可以精确测量各个效能的数据，但会使得程序运行时间大大加长，增加了数据分析时间，甚至有时候还会影响程序的真实运行情况。
但无论如何，在性能方面上的改进，一定要深思熟虑，要经过分析，不能草草就开始改动，盲目优化。