软件工程15我的阅读做业2

阅读《构建之法》提出的问题

Q一、经过好的单元测试就能说明程序是好的吗？

本书第21页，做者提到

“如何能让本身负责的模块功能定义尽可能明确，模块内部的改变不会影响其余模块，并且模块的质量能稳定的、量化的保证？单元测试就是一个颇有效的解决方案。"

对此我产生疑惑，经过好的单元测试就能说明程序是好的吗？单元测试有什么作不到的地方吗？
(1)单元测试解决不了设计失误带来的问题，即便最低劣的设计也可能经过单元测试。单元测试只是能测试模块的质量好坏，至于设计的好坏是没法测试出来的。
(2)单元测试不能解决产品的可用性和易用性问题。产品的可用性和易用性跟用户有关，单元测试的测试数据也这是机器产生或开发者自行设计的数据，并不包括图形界面的美观，功能界面的设计。书后面有提到能够用回归测试解决。在书第13.1.1节也就是281页，做者提到

另外一个例子是软件的“易用性测试”，在设计此类测试时，不必纠缠于程序的内部结构，而是应该着重于软件的界面和行为。

这句话也说明了对于解决易用性，单元测试是不适用的，这时候就要用到黑箱测试，同时做者也提到软件易用性测试须要不少专业知识。

(3)单元测试解决不了因为设计和编码不当带来的性能问题。
(4)单元测试一般不能解决类和类的一些逻辑问题。
(5)单元测试不能用来测试须要很长时间才能完成的操做(例如：数据链接超时)

我认为单个模块质量高当然好，可是软件是总体，应该经过多种测试，而不是单一对某个模块或功能进行测试。（在第13章有详细给出其余测试的方法和做用。）

下面是对好的单元测试不理解的地方：
在这本书第26页，做者在讲好的单元测试的标准其中一个标准是

“单元测试事后，机器状态保持不变”。

我当时看到这个标准第一反应是什么是机器状态？单元测试不是测试程序，怎么跟机器状态扯上关系？虽做者有解释说这样就能够不断地运行单元测试。对于这个解释，我仍是很不理解做者是怎么提炼这个标准，如何作到这个标准。
我以为我首先要先明白什么是机器状态。为此我上网查了一下，并无一个系统的解释。（有可能我查阅的资料不够多。）我大概理解为内存、寄存器等的状态。也就是说机器状态不变应该是说代码运行过程当中，怎么调用，变量放在哪一个内存，地址是啥，测试单元不能进行干预。换句话说测试单元不会改变程序运行的总体功能。因此测试单元应该作到只是提供测试的数据，而不能有改变被测试程序的语句或者记录。可是测试单元原本就是测试，通常人不会在测试单元写能够执行改变程序的代码。后来看到做者提到测试单元建立了临时的文件或目录应该在Teardown阶段删除。那什么是Teardown阶段？

teardown标记单元测试完成并开始回收初始化数据垃圾

Teardown阶段的理解仍是不是很清楚，可能须要本身实际动手写一次单元测试才会清楚。

Q二、关于回归测试最好要自动化的问题

在本书2.1.3节也就是书第29页，做者有写道

“回归测试最好要自动化。”

缘由是能够对于每个构建快速运行全部回归测试，以保证尽早发现问题。对于为何有回归测试咱们是知道了，可是如何作到回归测试自动化和何时不须要自动化（由于做者用了“最好”这个词，也就是说也能够不用）做者并无详细说明。
那我仍是以为先知道什么是回归测试?做者对回归测试中的“回归”，理解为“回归到之前不正常的状态”。我当时看到这句话，脑中只有不理解。你代码改进后，哎呀你状态还还有回归到不正常的状态。这是啥意思？这个不正常的状态应该是指未修改程序以前的状态。我以为这句话很让人误解。我以为回归测试是修改了旧代码后，从新进行测试以确认修改没有引入新的错误或致使其余代码产生错误的时候作的。那你既然修改了代码，而一些测试用例可能会失去针对性和有效性，而另外一些测试用例可能会变得过期，还有一些测试用例将彻底不能运行，也就是说你的测试数据也会有改变，怎么能回到不正常的状态呢？那我不是又回去了？我认为是测试的态度是要像第一次测试的态度才比较合理。
那回来讲一下自动化回归测试怎么自动？以我如今目前所了解是可使用自动测试工具。基于没有真正使用自动测试工具，我仍是说一下为何最好自动化的问题。为何要自动化？由于每次重复的的回归测试所需时间太长，并且每每被证明功能并没有明显变化。我以为关键仍是懒吧！！那自动化后，你就不用手动作，多爽啊，为何不用？可是你要懒也要必须知道怎么懒？自动化回归测试你须要知道测试将覆盖哪些功能、自动测试架构还要选择回归测试自动化所使用的工具。再知道这些状况下你才能够作到自动化测试，否则你测试出来的结果你可能本身都不相信是对的。因此不知道如何自动化测试的时候，不用硬要自动化（固然能够学习后使用）。并且也不是手动就很差。在回归测试:人工测试仍是自动化?的博客有提到

手工测试的优势是清楚地看到 - 它不依赖于任何东西，能够在全部的时间完成。抛弃手动测试不会带来什么好处。自动和手动测试是相互联系，相辅相成的测试方法，每一个人都有优势和缺点。思考回归方案的自动化以前先考虑为其编写测试和支持的时间支出。另外，要注意手动测试专家一般薪水比那些拥有将测试自动化技能的人要低。

可是我我的认为仍是要自动化，毕竟科技再进步。（可能我也懒吧）

Q三、对开放-封闭的原则的理解？

做者在书38页，提到了

开放-封闭的原则，对其解释是“软件实体应该是能够扩展的，同时是不可修改的”。

个人理解应该就是扩展是开放的，修改是封闭的。虽然字面上的意思能懂，可是仍是比较抽象。但愿有具体的例子能够更好的解释这句话？或者说具体该如何作到？

可能我的缘由对于这种一对矛盾的词语的原则，感受这真的很矛盾。你说让人有开放又封闭的，是要开放仍是封闭？纠结啊！可是想到这一对矛盾的词说的是不一样的动词就不会以为矛盾。也就是说这个原则能够分为两个原则，一个是模块扩展原则，一个是模块修改原则。我认为这样比较好理解。

Q四、有关敏捷流程的问题

做者在第六章详细的写了敏捷流程。对于这个章节，在敏捷流程第二步是决定当前的冲刺须要解决的事情，那若是在这互相关联的阶段出现bug是不是直接进入下一阶段仍是停留该阶段直到解决？那这样是否就不够敏捷？做者在介绍敏捷流程的问题其中一个是

各个需求和任务之间是有复杂的依赖关系的，除了优先级外，咱们还要考虑相互依赖关系。怎么在计划中体现依赖关系？

是否意味着没法分析细化关系，敏捷流程只能停留在第一步？或者若是在第一步没有计划好，是否致使整个项目的失败？

Q五、对于软件测试方法的理解

做者在第13章写了不少关于软件测试的方法，共有12个测试方法。可是我看完之后以为有的测试本质实际上是差很少的，就是可能叫法不一样侧重点不一样。那为何把差很少的测试方法归为一种，把测试方法分为代码前期测试，代码完成后测试，可用性测试等。我我的认为构建验证测试跟回归测试没什么很大的区别，都是再修改代码后进行的测试。那我作了回归测试后还须要作构建验证测试吗？还有“小强”大扫荡测试跟“探索式的测试，若是在公司作了“小强”大扫荡测试，公司成员已经作了能够称为“探索式的测试的测试（由于公司成员在大扫荡过程能够就是随机的测试），那么还须要在特地的作“探索式的测试吗？对于现实生活中的项目，这十三种测试都须要一个个测试吗？

附加题

豆瓣连接：https://book.douban.com/annotation/54370216/