1,268
社区成员
发帖
与我相关
我的任务
分享关于提前编写测试 --=100分=-- 在送一百分，大家活跃一些
开发中测试的重要性因盖不需要在这里讨论了，尤其在XP中，强调在编写代码前先编写测试。对于这一点Cajon举双手+双脚赞成，而且希望在领导的项目中推行。但是实际操作中遇到了很多的问题，这里列出来大家讨论.....
1. 测试用例细化到什么程度？ 按照XP，所有的代码都应该接受测试用例的检验，但是很多时候一些简单的函数或者简单的属性（VB\c#)是否也需要编写测试用例呢？如果编写，工作量就太大了，但是如果不编写，对于重构是否会产生负面影响？因为大家都知道，其实往往简单的错误才是最难查出来的。可能开发时，这些问题还很容易发现，如果进行了重构，可能就因为觉得这里的代码太熟悉而忽略了其中很简单的错误，这样就很难发现了。
2. 编写测试代码要占用多少开发时间？一般可能认为50%左右，Cajon认为也可以接受，但是一半的时间是否足够写出完整的测试用例，如果时间再多，Cajon觉得可以接受，老板可会不接受了。必然要裁减测试用例，从新又回到第一个问题，测试用例应该细化到什么程度。
3. 对于界面的开发，大家是否也写测试用例？Cajon是写不出了......
4. 测试用例的复用有没有做过？说说经验，最好使用XUnit系列做例子......
哈哈。。。。 问题很多，分不够再开......
1. 测试用例细化到什么程度？ 按照XP，所有的代码都应该接受测试用例的检验，但是很多时候一些简单的函数或者简单的属性（VB\c#)是否也需要编写测试用例呢？如果编写，工作量就太大了，但是如果不编写，对于重构是否会产生负面影响？因为大家都知道，其实往往简单的错误才是最难查出来的。可能开发时，这些问题还很容易发现，如果进行了重构，可能就因为觉得这里的代码太熟悉而忽略了其中很简单的错误，这样就很难发现了。
2. 编写测试代码要占用多少开发时间？一般可能认为50%左右，Cajon认为也可以接受，但是一半的时间是否足够写出完整的测试用例，如果时间再多，Cajon觉得可以接受，老板可会不接受了。必然要裁减测试用例，从新又回到第一个问题，测试用例应该细化到什么程度。
3. 对于界面的开发，大家是否也写测试用例？Cajon是写不出了......
4. 测试用例的复用有没有做过？说说经验，最好使用XUnit系列做例子......
哈哈。。。。 问题很多，分不够再开......
...全文
请发表友善的回复…
发表回复
ozzzzzz 2002-12-25
- 打赏
- 举报
提前测试不应该是xp独有 在任何情况下你都可以采取它 唯一注意的是你是不是有合适的工具支持你的工作 也就是你的测试是不是可以自动化
回炉重造，学习编程中。。。 2002-12-25
- 打赏
- 举报
学习一下
Colin-Han 2002-12-25
- 打赏
- 举报
webcat() 兄：
我所说的提前测试并不是传统开发方法中的提前测试原型，而是XP中的先编写测试，后编写代码。用词不当，请见谅。
提前编写测试代码，主要是为了能够提高代码的质量，是程序员能够明确编码的目标，具体内容你可以看一下Kent的《解析极限编程--拥抱变化》
ozzzzzz兄：
是否提前编写测试最好和结对编程配合使用，有没有哪位兄弟进行过这样的实践（不结对编程但提前编写测试），说说感受。
我所说的提前测试并不是传统开发方法中的提前测试原型，而是XP中的先编写测试，后编写代码。用词不当，请见谅。
提前编写测试代码，主要是为了能够提高代码的质量，是程序员能够明确编码的目标，具体内容你可以看一下Kent的《解析极限编程--拥抱变化》
ozzzzzz兄：
是否提前编写测试最好和结对编程配合使用，有没有哪位兄弟进行过这样的实践（不结对编程但提前编写测试），说说感受。
webcat 2002-12-20
- 打赏
- 举报
我觉得提前测试是对即将开始编码的设计上的评审，在降低风险，实际上真正的问题只有代码变出来之后才能测试出来
Colin-Han 2002-12-20
- 打赏
- 举报
我在网上找到了一个cppRefactor的软件，是开源的，大的里面就使用了CPPUnit，但是没有编写任何测试用例，而且工具也没有完成。参考价值不大。
各位谁还有相类似的开源软件，告诉我，我去看看.....
谢谢
各位谁还有相类似的开源软件，告诉我，我去看看.....
谢谢
ozzzzzz 2002-12-18
- 打赏
- 举报
cajon(Cajon)
重构的时候必须保证通过原来所有的测试 也就是说修改代码是允许随便进行的 修改测试则是要有受权的
单元测试的粒度 我想也不要太过分 我想FOWLER也说过 不要对绝对不会出错的地方作测试
界面测试是个大家都要面对的问题（另一个是数据库） 我也没有好办法 好在现在基本上我做的都是MIS之类的东西 依靠VB PB等工具产生的界面不会出什么问题
关于使用xUNIT的例子 我想你可以从网上找一些很多的
重构的时候必须保证通过原来所有的测试 也就是说修改代码是允许随便进行的 修改测试则是要有受权的
单元测试的粒度 我想也不要太过分 我想FOWLER也说过 不要对绝对不会出错的地方作测试
界面测试是个大家都要面对的问题（另一个是数据库） 我也没有好办法 好在现在基本上我做的都是MIS之类的东西 依靠VB PB等工具产生的界面不会出什么问题
关于使用xUNIT的例子 我想你可以从网上找一些很多的
w_rose 2002-12-18
- 打赏
- 举报
什么粒度呢？如果你编码之前有明确的设计文档，就是设计文档上的粒度。
因此，直接从分析过渡到编码（过度XP就是这样），那么就没有粒度。
因此，直接从分析过渡到编码（过度XP就是这样），那么就没有粒度。
termite 2002-12-18
- 打赏
- 举报
good
Colin-Han 2002-12-18
- 打赏
- 举报
谢谢ozzzzzz：
我想我用错了词语，我所说的测试用例是指单元测试，对不起！
另外，现在我自己写的一个程序就采用先测试后编码的方式开发，但是开发的过程中发现很多问题，主要就是上面的4点，希望你能够给我一个可操作的方法！
首先，单元测试应该写到什么样的粒度呢？对于一些很简单的函数是否也需要写出所有的单元测试，找出所有的临界点进行测试呢？
我想我用错了词语，我所说的测试用例是指单元测试，对不起！
另外，现在我自己写的一个程序就采用先测试后编码的方式开发，但是开发的过程中发现很多问题，主要就是上面的4点，希望你能够给我一个可操作的方法！
首先，单元测试应该写到什么样的粒度呢？对于一些很简单的函数是否也需要写出所有的单元测试，找出所有的临界点进行测试呢？
ozzzzzz 2002-12-18
- 打赏
- 举报
测试优先不是XP的创造 这种思想早就存在
这样的思想很好理解 比如你要做一件什么事情 你就会先制订一个考察你做事情结果的标准 这就是一种先写测试后完成
测试用例不能代表所有的测试 其中最重要的问题是它不包括单元测试 而测试用例多数情况下是黑盒测试 是对产品的功能的测试 在XP中这个测试是由现场客户编写的（当然如果是真正的客户 就需要在技术人员的执导下） 这个其实应该很好理解 就是在你制订需求的时候 应该就制订你产品的合格标准
而单元测试也要先写就让许多人感到困惑 其实也很简单 那就是在你编写实际的编码前要首先确定你的接口（也就是你要先有个设计） 然后对这个接口编写单元测试 然后运行 这个测试这个时候应该不能成功（当然不能成功 因为你还什么都没有作) 然后你开始书写代码 使得你编写的测试可以通过 就是这个简单
这样的思想很好理解 比如你要做一件什么事情 你就会先制订一个考察你做事情结果的标准 这就是一种先写测试后完成
测试用例不能代表所有的测试 其中最重要的问题是它不包括单元测试 而测试用例多数情况下是黑盒测试 是对产品的功能的测试 在XP中这个测试是由现场客户编写的（当然如果是真正的客户 就需要在技术人员的执导下） 这个其实应该很好理解 就是在你制订需求的时候 应该就制订你产品的合格标准
而单元测试也要先写就让许多人感到困惑 其实也很简单 那就是在你编写实际的编码前要首先确定你的接口（也就是你要先有个设计） 然后对这个接口编写单元测试 然后运行 这个测试这个时候应该不能成功（当然不能成功 因为你还什么都没有作) 然后你开始书写代码 使得你编写的测试可以通过 就是这个简单
