请教各位:是不是最初的测试用例只是对软件的功能实现方面的测试呢?还是要把算法和一些实际输出考虑进去呢? 我也是刚刚跨入软件测试这个行业的。希望大家多多交流,从此可以提高我们的水平。
请教各位:是不是最初的测试用例只是对软件的功能实现方面的测试呢?还是要把算法和一些实际输出考虑进去呢? 我也是刚刚跨入软件测试这个行业的。希望大家多多交流,从此可以提高我们的水平。
请教各位:是不是最初的测试用例只是对软件的功能实现方面的测试呢?还是要把算法和一些实际输出考虑进去呢? 嗯!我也觉得好多领导都重视bug的量,没办法,我们老板就是的,还说日本人总是比我们速度快,bug多。其实我觉得好多给的测试时间不够,有些人员上也不够。写了好的用例,也不能很好的执行啊! 同意楼上的,足够的时间和不受干扰地完成整个测试过程非常重要。但往往留给测试的时间都不够。 我的一些看法,设计测试用例,首先,要考虑的是测试需求,明确测试的对象和范围. 不管是白盒还是黑盒,都是穷举法,所以测试用例的覆盖率不可能达到100%,这个比率的设定与软件生产周期密切相关.
还有一点,对于测试用例整体而言,要看重其覆盖率,对于单个Case或部分来说,还要考虑其重用性. 谢谢了!!!! 我要把它收藏起来,好好体会,慢慢消化……~~
测试的步骤
因为公司就本人一个人测试 ,所以我的测试用例都只写了些要实现的功能和一些字段的有效值和无效值等的输入,而对测试用例写执行哪个,后执行哪个并没有详细说明,这个执行步骤只有在我实际的测试过程中遇到了BUG时,才把步骤记录的详细,反映给开发人员,请问,那我该怎么样改进下我的测试用例呢??? 今天看了好多帖子了,真想一口气把他们看完,可是真的太多了,在这里谢谢jackey 看了这个帖子很有启发啊谢谢大家了 同意 希望有一天,我也可以写出这么好的心得来。先从读贴回贴做起!!!
请教jackei
看了你的文章,知道你在这方面是高手,但不知道你所说的测试需求是一个抽象理论的概念呢,还是具体在项目开发过程中一个实际存在的文档,因为一般测试用例是根据需求文档而编辑的,那现在这个测试需求文档是何东东?还有有模板吗?盼回复!谢谢! 原帖由 mysel 于 2004-7-27 09:31 发表我是一个新手,做了差不多两个月的测试,昨天看了你的《RUP测试过程实践
之测试需求与测试用例》,很多地方都有同感。但我在测试中,有时好象觉得测试时的操作步骤也是有好多种的,因为要找出BUG,必须做一些随意 ...
是的,你提的问题也是比较普遍的问题,属于ad hoc的测试方法,也就是我们所说得free test,这些是test case所不包括的
如果通过ad hoc测试发现bug,这时候重要的是要及时的update case。
test case对于每个project来说,都是很宝贵的资料。
我们会在submit new bug的时候,给出相应的case number,确保一个bug有一个test case对应,如果是因为ad hoc产生的bug,那会及时的添加一个新的test case for 这个new bug,保证test case的时刻更新。
这样也可以慢慢的提高case的 coverage。 原帖由 jzj 于 2005-10-13 01:33 发表
嗯!我也觉得好多领导都重视bug的量,没办法,我们老板就是的,还说日本人总是比我们速度快,bug多。其实我觉得好多给的测试时间不够,有些人员上也不够。写了好的用例,也不能很好的执行啊!
呵呵,我们和你相反,是日本人比我们速度慢,bug number也比我们少,但是他们在QA方面的technique是蛮好的
其实有时候去评价一个QA,不是单纯的靠bug的数量,这个只是一个小方面而已
bug多,但是都是一些小bug或者是suggestion,那他们的价值也不是很大。
另外一点就是,QA不但要找出bug,更重要的是要push 和帮助Dev去fix bug,否则一堆open的bug放在那里而没有fix掉,对project而言,也不是好事的。 要是有具体示例就好了 想问一下,关于一个业务流程的测试,写到一个用例里面感觉用例的粒度就太大了,但是分开写就体现不料一个业务的流程了,这一点我不知道怎么能很好的解决.谢谢指教!! to jackei :说的很有实践意义,但在编写测试用例中如何应用等价类划分,边界值分析法,错误推测法。我比较困惑,感觉大部分是根据spec的逻辑和自我经验确定一组用例来验证一个需求点。但是总体上觉得缺乏数学逻辑模型上的抽象, 所以对于自己的用例,大部分上是逻辑分支上的覆盖。很难做到用少的用例达到最大的逻辑覆盖率。希望给与一定的建议,谢谢!
to sanjieyu : 感觉上你们的test case 管理很规范,你们公司在需求点变动所引起的test case 的变化,是用工具实现的吗? 什么工具? 还是人工的维护。 我们原先都是使用TD来管理的.每添加一个新的BUG都必须有一个对应的用例的.
但有时候也会出现测试人员增加了BUG,但没有同时去添加用例了.