软件纠错的思考
软件纠错的六个阶段:
这不可能。
我机器上就没事。
不应该呀。
为什么会出现这种问题?
噢,我明白了。
以前怎么就没问题?
下面这幅图形象的解释了为什么要单元测试,每砌上一块砖,就要和拉的水平线比较一下。
这幅图也可以说明TDD(测试驱动开发):先写测试用例,在写代码来通过这个测试用例,然后重构。周而复始。
我们这么开发程序:全部模块写完,然后测试。不行再改
我们这么砌墙:全部砌万,然后再看有没有砌成直线。不行,推到重来?
水平线是怎么来确定的?
先拉一根线(准绳)在哪里(这就是你要满足的测试用例),然后写代码是为了通过这个测试用例。
从技术上讲,有水平尺。
从比喻上讲,测试用例直接来源于用户需求。
软件测试并不是一个功能。它不是一个由客户提出来的需求。它不是“最好测一下”。它是一个软件的任何一段代码的固有组成。
不错,你可以开发出不经测试的软件。它甚至可以运行,就像是摞起来的砖块看起来也是一堵墙。但如果遇到大一点的风,它有可能就会砸到某人的头上。
现场客户:你装修的时候,你不会把钥匙扔给装修队,说:你们搞吧,我N个月后来看。
软件开发与此同理。
即时反馈,不让错误累积起来,这是很重要的!
所以说敏捷,在软件开发的每一个环节,都在强调一个概念:反馈
所以说敏捷,在软件开发的每一个环节,都在强调一个概念:反馈
需求的信息,不是从产品到开发的单向流动,真的理解了吗?真的明白了吗?要反馈,要反复的沟通。
每一两周一个小版本,让用户即时看到开发的进展,这真的是你想要的功能吗?如果不是,现在改还来得及。
每一两周一个小版本,让用户即时看到开发的进展,这真的是你想要的功能吗?如果不是,现在改还来得及。
完成一个模块,测试一下,是否和已有的模块能连起来 来工作,不能,即时修改。