阅读《构建之法》提出的问题##
Q1、通过好的单元测试就能说明程序是好的吗？###
本书第21页，作者提到
“如何能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能稳定的、量化的保证？单元测试就是一个很有效的解决方案。"
对此我产生疑惑，通过好的单元测试就能说明程序是好的吗？单元测试有什么做不到的地方吗？
(1)单元测试解决不了设计失误带来的问题，即使最低劣的设计也可能通过单元测试。单元测试只是能测试模块的质量好坏，至于设计的好坏是无法测试出来的。
(2)单元测试不能解决产品的可用性和易用性问题。产品的可用性和易用性跟用户有关，单元测试的测试数据也这是机器产生或开发者自行设计的数据，并不包括图形界面的美观，功能界面的设计。书后面有提到可以用回归测试解决。在书第13.1.1节也就是281页，作者提到
另一个例子是软件的“易用性测试”，在设计此类测试时，没必要纠缠于程序的内部结构，而是应该着重于软件的界面和行为。
这句话也说明了对于解决易用性，单元测试是不适用的，这时候就要用到黑箱测试，同时作者也提到软件易用性测试需要很多专业知识。
(3)单元测试解决不了由于设计和编码不当带来的性能问题。
(4)单元测试通常不能解决类和类的一些逻辑问题。
(5)单元测试不能用来测试需要很长时间才能完成的操作(例如：数据连接超时)
我认为单个模块质量高固然好，但是软件是整体，应该通过多种测试，而不是单一对某个模块或功能进行测试。（在第13章有详细给出其他测试的方法和作用。）
下面是对好的单元测试不理解的地方：
在这本书第26页，作者在讲好的单元测试的标准其中一个标准是
“单元测试过后，机器状态保持不变”。
我当时看到这个标准第一反应是什么是机器状态？单元测试不是测试程序，怎么跟机器状态扯上关系？虽作者有解释说这样就可以不断地运行单元测试。对于这个解释，我还是很不理解作者是怎么提炼这个标准，如何做到这个标准。
我觉得我首先要先明白什么是机器状态。为此我上网查了一下，并没有一个系统的解释。（有可能我查阅的资料不够多。）我大概理解为内存、寄存器等的状态。也就是说机器状态不变应该是说代码运行过程中，怎么调用，变量放在哪个内存，地址是啥，测试单元不能进行干预。换句话说测试单元不会改变程序运行的整体功能。所以测试单元应该做到只是提供测试的数据，而不能有改变被测试程序的语句或者记录。但是测试单元本来就是测试，一般人不会在测试单元写可以执行改变程序的代码。后来看到作者提到测试单元创建了临时的文件或目录应该在Teardown阶段删除。那什么是Teardown阶段？
teardown标记单元测试完成并开始回收初始化数据垃圾
Teardown阶段的理解还是不是很清楚，可能需要自己实际动手写一次单元测试才会清楚。
Q2、关于回归测试最好要自动化的问题###
在本书2.1.3节也就是书第29页，作者有写道
“回归测试最好要自动化。”
原因是可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。对于为什么有回归测试我们是知道了，但是如何做到回归测试自动化和什么时候不需要自动化（因为作者用了“最好”这个词，也就是说也可以不用）作者并没有详细说明。
那我还是觉得先知道什么是回归测试?作者对回归测试中的“回归”，理解为“回归到以前不正常的状态”。我当时看到这句话，脑中只有不理解。你代码改进后，哎呀你状态还还有回归到不正常的状态。这是啥意思？这个不正常的状态应该是指未修改程序之前的状态。我觉得这句话很让人误解。我觉得回归测试是修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的时候做的。那你既然修改了代码，而一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行，也就是说你的测试数据也会有改变，怎么能回到不正常的状态呢？那我不是又回去了？我认为是测试的态度是要像第一次测试的态度才比较合理。
那回来说一下自动化回归测试怎么自动？以我现在目前所了解是可以使用自动测试工具。基于没有真正使用自动测试工具，我还是说一下为什么最好自动化的问题。为什么要自动化？因为每次重复的的回归测试所需时间太长，而且往往被证实功能并无明显变化。我觉得关键还是懒吧！！那自动化后，你就不用手动做，多爽啊，为什么不用？但是你要懒也要必须知道怎么懒？自动化回归测试你需要知道测试将覆盖哪些功能、自动测试架构还要选择回归测试自动化所使用的工具。再知道这些情况下你才可以做到自动化测试，不然你测试出来的结果你可能自己都不相信是对的。所以不知道如何自动化测试的时候，不用硬要自动化（当然可以学习后使用）。而且也不是手动就不好。在回归测试:人工测试还是自动化?的博客有提到
手工测试的优点是清楚地看到 - 它不依赖于任何东西，可以在所有的时间完成。抛弃手动测试不会带来什么好处。自动和手动测试是相互联系，相辅相成的测试方法，每个人都有优点和缺点。思考回归方案的自动化之前先考虑为其编写测试和支持的时间支出。另外，要注意手动测试专家通常薪水比那些拥有将测试自动化技能的人要低。
但是我个人认为还是要自动化，毕竟科技再进步。（可能我也懒吧）
Q3、对开放-封闭的原则的理解？###
作者在书38页，提到了
开放-封闭的原则，对其解释是“软件实体应该是可以扩展的，同时是不可修改的”。
我的理解应该就是扩展是开放的，修改是封闭的。虽然字面上的意思能懂，但是还是比较抽象。希望有具体的例子可以更好的解释这句话？或者说具体该如何做到？
可能个人原因对于这种一对矛盾的词语的原则，感觉这真的很矛盾。你说让人有开放又封闭的，是要开放还是封闭？纠结啊！但是想到这一对矛盾的词说的是不同的动词就不会觉得矛盾。也就是说这个原则可以分为两个原则，一个是模块扩展原则，一个是模块修改原则。我认为这样比较好理解。
Q4、有关敏捷流程的问题###
作者在第六章详细的写了敏捷流程。对于这个章节，在敏捷流程第二步是决定当前的冲刺需要解决的事情，那如果在这互相关联的阶段出现bug是否是直接进入下一阶段还是停留该阶段直到解决？那这样是否就不够敏捷？作者在介绍敏捷流程的问题其中一个是
各个需求和任务之间是有复杂的依赖关系的，除了优先级外，我们还要考虑相互依赖关系。怎么在计划中体现依赖关系？
是否意味着无法分析细化关系，敏捷流程只能停留在第一步？或者如果在第一步没有计划好，是否导致整个项目的失败？
Q5、对于软件测试方法的理解###
作者在第13章写了很多关于软件测试的方法，共有12个测试方法。但是我看完以后觉得有的测试本质其实是差不多的，就是可能叫法不同侧重点不同。那为什么把差不多的测试方法归为一种，把测试方法分为代码前期测试，代码完成后测试，可用性测试等。我个人认为构建验证测试跟回归测试没什么很大的区别，都是再修改代码后进行的测试。那我做了回归测试后还需要做构建验证测试吗？还有“小强”大扫荡测试跟“探索式的测试，如果在公司做了“小强”大扫荡测试，公司成员已经做了可以称为“探索式的测试的测试（因为公司成员在大扫荡过程可以就是随机的测试），那么还需要在特意的做“探索式的测试吗？对于现实生活中的项目，这十三种测试都需要一个个测试吗？
