也说回归测试regression testing开发人员对回归测试应该有所耳闻，但是并非都很清楚它的确切含义，比如我，以
也说回归测试regression testing
开发人员对回归测试应该有所耳闻，但是并非都很清楚它的确切含义，比如我，以前老听到测试部门的头儿说回归回归，但也没具体去探讨什么叫回归测试，可能回归这个词太熟也太陌生吧，今天终于去探寻一番啥叫回归。
?
回归测试英文名叫regression?testing，regression是复原退步的意思，当然不能想当然的理解为“退了步的测试”，描述为“对退步再进行测试”可能较为恰当。既然是退步，那就还存在“原地踏步”这种状态，相对于“原地”往后退才叫做“退步”，为什么会退步，也就是说测试的缘由是什么，缘由是因为系统、程序或代码的状态被改变了。在系统发布前通常会做多次回归测试，比如第n次发布测试发现了m个bugs（这里假定系统此时处于第n状态），程序被QA部门reject回到开发部门当中，开发人员根据bug系统进行缺陷修正，修正完毕后提交给QA部门进行回归测试，这次回归是针对第n次发布测试，测试目标是m个bugs将得到fixed，回归结果将得到系统的一个新的状态（这里假定系统处于第n+1状态），在第n状态到第n+1状态中间，由于开发人员对代码进行更改，因此这时候系统状态的未知系数（不稳定性）是非常高的，可以称之为“退步”(regresssion)，因此第n+1次测试其实是针对这一“退步”状态进行，因而叫做回归，回归在这里可以有两重意思，一是回到系统的较低级状态，二是将系统的状态“拉回”到新的稳定状态（第n+1状态）。
?
回归测试并非局限于某一种测试，比如发布测试，它可以发生在单元测试(ut)，功能测试(ft)，集成测试(it)等等当中，当代码发生任何变动的时候，所执行的测试就可以说是一次回归测试，回归测试可以是自动的，也可以是手工的，比如前面所举的发布测试通常是手工完成，当回归测试可以自动执行的时候，系统可以较快地到达一个新的稳定状态，比如一个系统如果有良好的ut基础，那么代码的变更一旦检入代码库当中，就可以触发连续构建工具进行build and test（回归测试），失败的结果将在第一时间通知变更代码的程序员，或者通知配置管理员立即处理有问题的代码，这种just-in-time的处理方式将大大减少bug数目并提高代码质量，同时使团队的合作开发更加顺畅。
?
测试的自动化的程度越高，回归的周期就越短，效果越明显，软件的质量也越高，测试是否自动化也是开发是否敏捷的一个主要标志。
?
?
一个字：高
（另：说“监狱是城市的主要表示”，主要是为了回答夸夸其谈玩玩文字游戏的人）
7 楼 daquan198163 2009-04-15 photon 写道daquan198163 写道photon 写道引用测试是否自动化也是开发是否敏捷的一个主要标志
这就好像说，监狱是否人满为患是城市是否安全的一个主要表示。
人家又没说测出的bug多就代表敏捷，
你的比喻毫无道理！
好吧，既然你不理解我的意思，我换个比喻。这就好像说，是否到处有警车和电子眼是城市是否安全的一个主要标志。
敏捷又不等于项目成功，因此不等于城市安全。
到处有警车和电子眼 是 城市安全设施是否完善 的一个主要标志 8 楼 photon 2009-04-15 daquan198163 写道photon 写道daquan198163 写道photon 写道引用测试是否自动化也是开发是否敏捷的一个主要标志
这就好像说，监狱是否人满为患是城市是否安全的一个主要表示。
人家又没说测出的bug多就代表敏捷，
你的比喻毫无道理！
好吧，既然你不理解我的意思，我换个比喻。这就好像说，是否到处有警车和电子眼是城市是否安全的一个主要标志。
敏捷又不等于项目成功，因此不等于城市安全。
到处有警车和电子眼 是 城市安全设施是否完善 的一个主要标志
先背一遍敏捷宣言的第一句话
9 楼 daquan198163 2009-04-15 个体与交互重于过程和工具。
你想说什么？ 10 楼 photon 2009-04-15 注意红色字体部分。
到处有警车和电子眼=>城市安全设施是否完善
城市安全设施是否完善=>安全城市？
好多大城市的安全设施比乡村先进多了，但是好多大城市里的人们的安全感要差的多。
回到最开始，瀑布模型同样能导致完善的自动化测试。所以自动化测试只是敏捷的一个结果。同样，没有自动化测试就未必不敏捷。 11 楼 seemoon 2009-04-15 photon 写道注意红色字体部分。
到处有警车和电子眼=>城市安全设施是否完善
城市安全设施是否完善=>安全城市？
好多大城市的安全设施比乡村先进多了，但是好多大城市里的人们的安全感要差的多。
回到最开始，瀑布模型同样能导致完善的自动化测试。所以自动化测试只是敏捷的一个结果。同样，没有自动化测试就未必不敏捷。
很好，回到正题了，不然你再搞一个“面朝大海，春暖花开”那大众就又被悠忽了。呵呵，开个玩笑
如果自动化测试不敏捷，那么手把手地debug和测试那叫敏捷？
12 楼 agurick 2009-04-15 其实听想听听大家所谓的敏捷经历的…… 整点儿实在的。 13 楼 pipilu 2009-04-16 敏捷当然不一定非要自动化测试。功能测试，一百个测试用例，一个人带报bug也就两天时间差不就完成了。如果每晚能跑一遍自动化测试，开发人员早上上班时就能看到新的测试结果，这样当然更理想、更敏捷。回归周期尽量短也是我们追求的目标。
感觉自动化测试没法完全取代人工测试吧？ 14 楼 whaosoft 2009-04-17 到底什么是敏捷呢~~
我有个同事说是不用设计 拿起来就写 用代码对付~ 15 楼 seemoon 2009-04-17 whaosoft 写道到底什么是敏捷呢~~
我有个同事说是不用设计 拿起来就写 用代码对付~
JimHighSmith:
引用
敏捷是
促进变革并
响应变化以便在
动荡的商业环境中
创造利润的
能力；
敏捷是平衡灵活性和稳定性的
能力；
敏捷更多的是一种
态度而不是一个流程，是一种
氛围而不是方法。
敏捷宣言：http://agilemanifesto.org/
16 楼 pipilu 2009-04-18 whaosoft 写道到底什么是敏捷呢~~
我有个同事说是不用设计 拿起来就写 用代码对付~
好像在《Joel说软件》中，Joel就专门这么批评过敏捷（强调必须要有设计），已经记不清在哪一章了，也不知道自己当时是不是误解人家的意思了。
我理解的敏捷就是软件开发过程中要快速的得到反馈。
不是没有设计，但从做事方法上，是尽快的让程序跑起来（或尽快的通过单元测试），不要“长考出臭棋”。 17 楼 seemoon 2009-04-19 pipilu 写道whaosoft 写道到底什么是敏捷呢~~
我有个同事说是不用设计 拿起来就写 用代码对付~
好像在《Joel说软件》中，Joel就专门这么批评过敏捷（强调必须要有设计），已经记不清在哪一章了，也不知道自己当时是不是误解人家的意思了。
我理解的敏捷就是软件开发过程中要快速的得到反馈。
不是没有设计，但从做事方法上，是尽快的让程序跑起来（或尽快的通过单元测试），不要“长考出臭棋”。
皮皮鲁的“长考出臭棋”比较形象，过度计划和过度设计都是过程式开发的严重弊端，所以称之为heavyweight。
让程序尽快跑起来的好处有让问题尽早暴露出来，让客户尽早能参与进来，得到良性反馈和循环。
18 楼 thinkinnight 2009-04-24 自动化工具其实并不是银弹，自动化的结果总归还是要有人来分析吧。而且很多人以为自动化测试就是让它不停的跑啊跑，结果那一堆的结果文件，分析起来头疼阿 19 楼 daquan198163 2009-04-24 thinkinnight 写道自动化工具其实并不是银弹，自动化的结果总归还是要有人来分析吧。而且很多人以为自动化测试就是让它不停的跑啊跑，结果那一堆的结果文件，分析起来头疼阿
测试运行的结果要么通过，要么失败，
只有失败的时候需要分析一下日志而已啊。 20 楼 老菜刀 2009-04-28 跑题太严重，本来楼主介绍回归挺好的。可总有人要跳出来形而上，太虚了。
务实，务实，同志们，要牢记啊。 21 楼 xly_971223 2009-05-01 回归必须要自动化才有价值。
单纯的靠人力回归， 成本太高、 速度太慢，根本跟不上敏捷开发的速度
22 楼 icefishc 2009-06-02 mock1234 写道thinkinnight 写道自动化工具其实并不是银弹，自动化的结果总归还是要有人来分析吧。而且很多人以为自动化测试就是让它不停的跑啊跑，结果那一堆的结果文件，分析起来头疼阿
为什么会产生“一堆”bug呢？自己好好反思项目管理问题。
自动化测试只是工具，它只能给你尽量提前反映问题。你应该在看到“一堆”问题时扪心自问为什么在只有1、2个问题时自己却在那里整天聊天和休闲？
可以预先做一个断言，好的项目管理即使面对极其复杂的大型项目也如行云流水，非常顺畅简练。
你把测试想简单了
1。并不是只有失败才产生有用报告。
2。并不是测试没通过就意味着bug
3。也不是所有的东西都可以简单的判断通过或失败。
比如性能测试 产生的那一堆报告你不分析谁分析。
23 楼 RCFans 2009-06-02 学习了
对于那些容易在回归测试中出错的模块，设计时尽量把它们分割开来互不影响
