|
锁定老帖子 主题：测试写到什么程度算足够？
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：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%覆盖到，其实还有一部分你没有预期到的情况并没有被测试到。对安全性要求高的应用可以用随机值测试来检测意外情况。
|
| 返回顶楼 | |
