晕了
文章要看就看仔细点,走马观花会害人的。LZ的每项的第一句话,正是他要反驳或者是要分析的,可不一定是他所持的观点,别给搞错了,自己误导自己. ^_^,,原来是我大哥来法帖了,,顶一个先 学习学习
覆盖率既然是个率那只能说去慢慢提高呢,不可能完全达到的。至少以我的能力是不能的。呵呵
谢谢楼主 写的非常好,可是中国的软件公司啊!不知道什么什么好啊!要不就是不给我们测试人员需求,要不就不给设计,他们大都不会给你数据库的,你就根本不知道到底什么数据存在什么表里面,什么时候什么字段置位 原帖由 Amsure 于 2005-9-15 14:36 发表
我前几天就遇到很麻烦的问题,我们写的测试脚本跑在自己开发的框架下,提高了测试的效率,但是上面说看不懂,要写文档,最后还补了大批的文档,唉~~~郁闷,其实文档只是个形式上的东西,我们最精髓的脚本没有 ...
不认同楼上的观点,一个软件,脚本,代码好不好不单单取决它的执行效率,它的可移植性,可读性,文档都是非常重要,一个程序再好,移植性不好,语句晦涩难懂。也难以生存下去。而文档(注释)就是对其最好的补充。缺少了文档的产品就不是一个完整的东西。如同一个人失去对声音大小以及颜色的辨别。
不错
sdlkfj3,楼主说的蛮好。看了之后有点感受
如题 写的的确不错!从中也学习了点点!加了你的GMAIL有机会聊下啊! 挺好的。 我觉得在设计测试数据时,我们只是需要总结对于某个功能点的数据集合类,不需要把它写的非常详细,这样测试用的可重用性太差 4、测试用例不应该包含实际的数据;有实际数据,会使用例的维护很困难。但我认为如果没有发生需求点的变动的话,这个是让不懂系统的人最好上手的一种方式。
没有实际数据的话,用逻辑语言描述的话,我认为是对spec 的一种分化表述,同样存在需求点变化导致该用例的生命周期的问题。 我想请问一下,什么才是写的很详细的测试用例,什么是写的简单的测试用例? “用例还应该包含对测试结果的显式的验证手段:在数据库中执行查询语句进行查询,看查询结果是否与预期的一致。
“非常赞同!
实际的测试数据也是很不错的
原帖由 sogoc 于 2005-9-23 15:57 发表4、测试用例不应该包含实际的数据;
这个我觉得楼主有点问题,不应该有实际数据那应该有什么?没实际数据怎么对比BUG的存在呢?
个人认为:实际的测试数据也是很不错的; 不熟悉业务,写不错好的用例的. 不错的文章,可也有一点偏颇 爽哈!!又学到了东西了!!