我来公司快一年了，开始一个多月都没有完善功能，我就没什么事情做，可以天天泡在51testing 里面吸取精华，开始测试以后就倍感压力然后忙着报bug，好久没来看看这里的兄弟姐妹们了，看着以前和我一样生涩的朋友们天天都泡在这里已经长进不少，我特伤感，我光顾着闭门造车了，外面的世界这么精彩。
    不过也不能说我完全没有收获，现在测试问题终于有了自己的一套思路。开发的同事们也都很配合我的工作，刚开始的时候老板就告诉我测试的压力会很大，因为始终会面临开发的同事不配合的情况，不过还好，至少目前为止，大家都很重视我的bug report，产品的质量也确实提高不少。看着我们的项目越来越完善我也蛮自豪的，当然比起开发GG来说，他们的辛劳更多了。
    对了，我想说个问题，我以前完整跑完test case 要三天，现在完全跑完test case 只要一天半，还有一天半可以进行随机测试，其实很多问题都是随机测试的时候发现的，我报告的bug80%都是随机测试而来。说实话我对test case不是很重视了，以前总是一来先打开它，然后看测到哪了，然后继续，现在都看厌了，我常常觉得很疑问，test case真的那么重要吗？或者我的test case 不够全面呢，公司比较小，就我一个QA，所以很多问题要我自己琢磨，最近报的一百多个bug我都没用test case了。不知道各位兄弟姐妹是不是也是这样的呢？

说实话偶现在干活的时候发现的BUG也不是由test case 发现的
可是我们还是要写test case,不是说发现不了bug它就没用了,偶觉得这更对是针对基础功能的~
你随机发现的那个bug,其实你可以把发现的过程写成test case,不光回归的时候用得上,没准下次再测别的东西的时候,你新加的test case就能发现bug了呢!

呵呵，这种情况你应该感到高兴才是啊，说明你那些开发的GG没有再出现相同的错误！

test case是需要不断完善的，怎么可以吃老本啊？

其实一套好的测试用例，重要的不是它有多少好的设计思想，而是他是否覆盖全面
同样一套产品，你是愿意交给一个自称设计思想很牛的人，让他用大量的时间去设计一个有好的思想所谓的少而精的用例来测试呢，还是愿意交给一个也许设计能力不强，但是他写用例却重视覆盖率的人呢？
我以前负责过一个日本的项目，他们的测试用例，一套不多的功能，他们的测试用例却都能到几千个。其实没有什么思想，就是扫雷式的覆盖，不放过任何一个功能点，这样的用例基本上可以放心的交给刚入门的测试人员去做了。所以所谓的设计用例方法，不是让你按照他去做，而是让你学习或者说练习他的方法，没有人会拿到功能，然后开始一丝不苟的画因果图、等价类，边界值，因为这些方法都已经融入到自己的动作中了。
测试用例其实有一个重要的作用，是解放设计人员的工作量，按道理是一个设计人员可以同时负责几个项目，而测试用例的执行是交给初级测试人员来做的，但是在国内，由于中国人的劣根性和现有国情，这样的工作方法是无法做到的，因此最后都是自己按照自己设计的用例去操作，当然没有意义了。

[ 本帖最后由 renfish 于 2008-5-7 10:32 编辑 ]

支持2楼的测试用例复用思想

引用:

原帖由 李靖之 于 2008-5-6 10:38 发表
说实话偶现在干活的时候发现的BUG也不是由test case 发现的
可是我们还是要写test case,不是说发现不了bug它就没用了,偶觉得这更对是针对基础功能的~
你随机发现的那个bug,其实你可以把发现的过程写成t ...

呵呵，我现在就是随机的测试然后编成test case ，以便回归，不过我基本就是写了就写了，很少再看，因为在报告bug的时候，过程写的很清楚，开发GG修改完了，我再verified的时候会按照我自己写的过程再测，基本上一个新的程序类bug在reopen三次左右在一段时期内就不再出现了。相比较而言我非常重视bug report。靖之是MM吧，我也是哦，幸会幸会，MM测试员越来越多了呢，呵呵

引用:

原帖由 renfish 于 2008-5-7 10:31 发表
其实一套好的测试用例，重要的不是它有多少好的设计思想，而是他是否覆盖全面
同样一套产品，你是愿意交给一个自称设计思想很牛的人，让他用大量的时间去设计一个有好的思想所谓的少而精的用例来测试呢，还是愿意交 ...

看来还是得重视起来，以便以后新来的QA方便看着操作，这QA不能永远我一个人嘛，呵呵，想通了，还是得写，而且要很认真的写，造福下一代，呃，不，下一批进来的QA，嘿嘿。
谢谢你，确实很中肯。

引用:

原帖由 mildshark 于 2008-5-6 18:25 发表
test case是需要不断完善的，怎么可以吃老本啊？

主要是我们报告bug有个条件要加TEST CASE ID，但是我的test case 是用execl写的，我希望我的test case 归类，所以把一类的都放一起，常常需要插入操作，那case ID就不断变化啊，到现在我报告bug的时候那个case ID 是我一个大问题，常常报完了再去case 里找相关的ID写进去，好苦恼哦。对了，你的test case用啥写的？我是用execl写的。

在现在的情况下，我认为编写测试用例最大的好处：
1，查漏补缺：能够弥补随即测试的最大缺陷--测试完成后心理没底，完整的测试用例至少可以保证基本功能的正常，这就基本可以保证发布后不会引起很大的麻烦
2，理顺测试思路：在编写用例的过程中，如果足够认真、负责，就基本能够将需求、业务搞清楚，并且能够理顺测试的提纲；提纲搞清楚了、搞定了，其他的都是次要的了

以前我的看法和你一样，现在发现自己错了。不错，大部分的BUG都是在自由测试中发现的。但是自由测试不能保证覆盖面，甚至你哪里测试了哪里没有测试，你都吧知道。所有要些测试用例，这样能保证覆盖面，而且测试用例刚好是自己自由测试基点，我们自由测试的操作往往是从测试用例的每个CASE里面发散想出来的。

可以把随机测试发现的bug归类，总结规律，更新到测试用例中。