也说回归测试regression testing

注意红色字体部分。
到处有警车和电子眼=>城市安全设施是否完善
城市安全设施是否完善=>安全城市？

好多大城市的安全设施比乡村先进多了，但是好多大城市里的人们的安全感要差的多。

回到最开始，瀑布模型同样能导致完善的自动化测试。所以自动化测试只是敏捷的一个结果。同样，没有自动化测试就未必不敏捷。

很好，回到正题了，不然你再搞一个“面朝大海，春暖花开”那大众就又被悠忽了。呵呵，开个玩笑

如果自动化测试不敏捷，那么手把手地debug和测试那叫敏捷？

其实听想听听大家所谓的敏捷经历的…… 整点儿实在的。

敏捷当然不一定非要自动化测试。功能测试，一百个测试用例，一个人带报bug也就两天时间差不就完成了。如果每晚能跑一遍自动化测试，开发人员早上上班时就能看到新的测试结果，这样当然更理想、更敏捷。回归周期尽量短也是我们追求的目标。

感觉自动化测试没法完全取代人工测试吧？

到底什么是敏捷呢~~
我有个同事说是不用设计 拿起来就写 用代码对付~

JimHighSmith:


敏捷宣言：http://agilemanifesto.org/

好像在《Joel说软件》中，Joel就专门这么批评过敏捷（强调必须要有设计），已经记不清在哪一章了，也不知道自己当时是不是误解人家的意思了。
我理解的敏捷就是软件开发过程中要快速的得到反馈。
不是没有设计，但从做事方法上，是尽快的让程序跑起来（或尽快的通过单元测试），不要“长考出臭棋”。

皮皮鲁的“长考出臭棋”比较形象，过度计划和过度设计都是过程式开发的严重弊端，所以称之为heavyweight。
让程序尽快跑起来的好处有让问题尽早暴露出来，让客户尽早能参与进来，得到良性反馈和循环。

自动化工具其实并不是银弹，自动化的结果总归还是要有人来分析吧。而且很多人以为自动化测试就是让它不停的跑啊跑，结果那一堆的结果文件，分析起来头疼阿

测试运行的结果要么通过，要么失败，
只有失败的时候需要分析一下日志而已啊。