锁定老帖子 主题:测试写到什么程度算足够?
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2006-11-20
Tin 写道 taowen 写道 说实话,没有TDD也可以XP。
如果任务真的很简单,干嘛要放两个人在同一件的事情上? 嗯,说得好呀。这是自我解放,做事可以Pragmatic,从心。制度应该给不动脑子的人。 测试的入手点的确是需要动脑子保证的,同样的场景可能有很多种测试的思路,所以如你所说这应该是由写测试的人决定,而不能通过另外一个测试保证。TDD让你从开始考虑验收的检查点,从一开始就在让思路清晰。 质量?与简单不简单没有直接关系 我们认为简单的东西出错的机会要比难的东西出错机会要高的多 不信可以看我们组的bug表... 一个制度如果是为了让人不动脑子那么这个制度就是个好制度.... 从心?去画画,去写诗, 不要作工人..程序员...和我组员... |
|
返回顶楼 | |
发表时间:2006-11-21
抛出异常的爱 写道 Tin 写道 taowen 写道 说实话,没有TDD也可以XP。
如果任务真的很简单,干嘛要放两个人在同一件的事情上? 嗯,说得好呀。这是自我解放,做事可以Pragmatic,从心。制度应该给不动脑子的人。 测试的入手点的确是需要动脑子保证的,同样的场景可能有很多种测试的思路,所以如你所说这应该是由写测试的人决定,而不能通过另外一个测试保证。TDD让你从开始考虑验收的检查点,从一开始就在让思路清晰。 质量?与简单不简单没有直接关系 我们认为简单的东西出错的机会要比难的东西出错机会要高的多 不信可以看我们组的bug表... 一个制度如果是为了让人不动脑子那么这个制度就是个好制度.... 从心?去画画,去写诗, 不要作工人..程序员...和我组员... 就我这种比较笨的人而言,稍微复杂一点的东西我都理解不了,不把它弄简单怎么办? |
|
返回顶楼 | |
发表时间:2006-11-21
kan kan
|
|
返回顶楼 | |
发表时间:2006-11-22
测试不是目的,
只是一种手段, 不管怎么玩, 得把软件质量搞上去 把开发维护成本搞下来, |
|
返回顶楼 | |
发表时间:2006-11-23
我认为对于一个类来说,测试如果能重现所有的使用方式,再加上契约的测试,应该就算是一个完整的测试了。
|
|
返回顶楼 | |
发表时间:2006-11-23
抛出异常的爱 写道 Tin 写道 taowen 写道 说实话,没有TDD也可以XP。
如果任务真的很简单,干嘛要放两个人在同一件的事情上? 嗯,说得好呀。这是自我解放,做事可以Pragmatic,从心。制度应该给不动脑子的人。 测试的入手点的确是需要动脑子保证的,同样的场景可能有很多种测试的思路,所以如你所说这应该是由写测试的人决定,而不能通过另外一个测试保证。TDD让你从开始考虑验收的检查点,从一开始就在让思路清晰。 质量?与简单不简单没有直接关系 我们认为简单的东西出错的机会要比难的东西出错机会要高的多 不信可以看我们组的bug表... 一个制度如果是为了让人不动脑子那么这个制度就是个好制度.... 从心?去画画,去写诗, 不要作工人..程序员...和我组员... 我想大家所说的简单是指架构简单化,而你所说的简单是指那些重复的,常常不能引起别人注意的东西(这里面带着许多个人特征,比如代码习惯,使用工具等),简单确实不能完全避免错误,但对于发现错误却是很有帮助的。测试能在一定程度上减少错误,其中也包含了许多的简单的错误。也由于编写测试需要从使用角度来分析编写,也从另一个角度促进了架构的简单化。但这里并不意味着做工人(蓝领也是好样的,只是大家兴趣缺缺),因为从某种角度来说,简化架构才是最难的。 |
|
返回顶楼 | |
发表时间:2006-11-24
lingate 写道 抛出异常的爱 写道 Tin 写道 taowen 写道 说实话,没有TDD也可以XP。
如果任务真的很简单,干嘛要放两个人在同一件的事情上? 嗯,说得好呀。这是自我解放,做事可以Pragmatic,从心。制度应该给不动脑子的人。 测试的入手点的确是需要动脑子保证的,同样的场景可能有很多种测试的思路,所以如你所说这应该是由写测试的人决定,而不能通过另外一个测试保证。TDD让你从开始考虑验收的检查点,从一开始就在让思路清晰。 质量?与简单不简单没有直接关系 我们认为简单的东西出错的机会要比难的东西出错机会要高的多 不信可以看我们组的bug表... 一个制度如果是为了让人不动脑子那么这个制度就是个好制度.... 从心?去画画,去写诗, 不要作工人..程序员...和我组员... 我想大家所说的简单是指架构简单化,而你所说的简单是指那些重复的,常常不能引起别人注意的东西(这里面带着许多个人特征,比如代码习惯,使用工具等),简单确实不能完全避免错误,但对于发现错误却是很有帮助的。测试能在一定程度上减少错误,其中也包含了许多的简单的错误。也由于编写测试需要从使用角度来分析编写,也从另一个角度促进了架构的简单化。但这里并不意味着做工人(蓝领也是好样的,只是大家兴趣缺缺),因为从某种角度来说,简化架构才是最难的。 测试就如同小学作算数题目 每写完一题就用逆运算进行验算一下 不能保证一定会把错找到但大大减少了人为错误 很多男生从不验算.... 认为太简单不会作错.... 但是能得一百分的很少 简化架构...那是重构要作的事吧 作测试只会把架构作的更复杂... 由于重用变多了代码会被化简 |
|
返回顶楼 | |
发表时间:2006-11-24
抛出异常的爱 写道 lingate 写道 抛出异常的爱 写道 Tin 写道 taowen 写道 说实话,没有TDD也可以XP。
如果任务真的很简单,干嘛要放两个人在同一件的事情上? 嗯,说得好呀。这是自我解放,做事可以Pragmatic,从心。制度应该给不动脑子的人。 测试的入手点的确是需要动脑子保证的,同样的场景可能有很多种测试的思路,所以如你所说这应该是由写测试的人决定,而不能通过另外一个测试保证。TDD让你从开始考虑验收的检查点,从一开始就在让思路清晰。 质量?与简单不简单没有直接关系 我们认为简单的东西出错的机会要比难的东西出错机会要高的多 不信可以看我们组的bug表... 一个制度如果是为了让人不动脑子那么这个制度就是个好制度.... 从心?去画画,去写诗, 不要作工人..程序员...和我组员... 我想大家所说的简单是指架构简单化,而你所说的简单是指那些重复的,常常不能引起别人注意的东西(这里面带着许多个人特征,比如代码习惯,使用工具等),简单确实不能完全避免错误,但对于发现错误却是很有帮助的。测试能在一定程度上减少错误,其中也包含了许多的简单的错误。也由于编写测试需要从使用角度来分析编写,也从另一个角度促进了架构的简单化。但这里并不意味着做工人(蓝领也是好样的,只是大家兴趣缺缺),因为从某种角度来说,简化架构才是最难的。 测试就如同小学作算数题目 每写完一题就用逆运算进行验算一下 不能保证一定会把错找到但大大减少了人为错误 很多男生从不验算.... 认为太简单不会作错.... 但是能得一百分的很少 简化架构...那是重构要作的事吧 作测试只会把架构作的更复杂... 由于重用变多了代码会被化简 两者也缺一不可。 |
|
返回顶楼 | |
发表时间:2006-11-25
这里有篇文章讨论的是类似的问题
Test Smarter, Not Harder 从统计学的角度看,就算测试没有覆盖全部的路径,你也可以对自己的产品质量有足够的信心。那篇文章分析了在不同的要求下,多少测试才是足够的。 |
|
返回顶楼 | |
发表时间:2006-11-26
Unit test测试的是你预期发生的事,即使程序路径被100%覆盖到,其实还有一部分你没有预期到的情况并没有被测试到。对安全性要求高的应用可以用随机值测试来检测意外情况。
|
|
返回顶楼 | |