受益匪浅
受益匪浅,顶。 谢谢,收到 确实不错 Originally posted by xuerzj at 2005-2-22 17:53:写的很好,有同感呀。我们的测试用例书写的一个要求就是不要写得太细,不要把一个个步骤都写下来,那样维护量会大的惊人,而且对操作很熟悉的人去读繁琐的操作步骤是一种煎熬。我们要求使用用例的人员是经过业务 ...
同意楼主的看法! 又学到了不少 同意楼主.
写用例跟写代码差不多,要写的别人看得懂才可以.步骤的繁简需要大家约定和项目经理要求.
如果写的太繁琐.不如直接写自动脚本了. 呵呵..学习学习.. 我也是刚刚进入公司做测试的.我没有接触过.也没有经验.现在公司叫我写测试用例和测试计划.我之前一直都在看测试这方面的知识..也在网上看到一些测试用例的例子..现在我的脑海中一片乱..公司的开发人员说.每一块模块都要测试.那是不是每一块模块都要有自己的测试用例.或是进行一个复盖测试就行了?这样可以么?请教一下. 原帖由 山风寂寂 于 2005-6-4 16:10 发表
4、测试用例不应该包含实际的数据;
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出,没有测试数据的用例最多只具有指导性的意义,不具有可执行性。
对于这 ...
=================
既然数据之间有关联关系,就应该进行分析,变成一个新的用例. 一个成功新建功能从场景上 是一个,但输入的不同对划分为不同的等价类,从而要用不同的用例来覆盖. 学习学习!!! 不错,值得反复学习,思考……
没别的谢了!
;):o:(:(:(:(:( 测试需考虑的还有业务的理解程度,建立在了解系统的业务理解之后的测试,简单且要素具备的测试用例才能收到好的效果。否则,工作的进行还是会有阻碍。我认为,测试人员在需求阶段就参与可以事半功倍继续学习
我们公司的产品通常一个界面有很多的字段需要录入数据,这样的情况,用例很不方便写的很细致,不知道哪位朋友可以指点我一二呢? 真的很不错!好!回复 #1 dennis_d 的帖子
受益匪浅!! goodmark 楼主总结的非常精彩,但是我有不同的看法:
1.测试用例设计是一劳永逸的事情;
这句话不能说完全不可取,(我对移动嵌入式设备的系统测试比较熟)就拿NOKIA来说,它们的产品具有很多的共性.
简单说一下NOKIA的产品范围:主要分为CUIS30 , ISA S40 ,SYMBIAN S60 , N SERIES , E SERIERS , VIRTU .这些产品是根
据不同时期,不同客户的需求而产生技术与外观上升级得来的.而这些产品的CASES也是重最初的CASES框架搭建起来
所以我认为CASE的最初设计很重要,可以起到一劳永逸的作用.当然一尘不变是不可能.在产品设计与需求变更的情况下,CASE肯定要更新,但是改动不应该很大.不然会影响整个项目的进度.其实对一个管理先进的公司来说,他们的项目
划分的很细,也很清晰,除非有新开发的项目或是为了市场竞争而必须要重新定位产品,这些公司是不会轻易改变原有
的模式.楼主说的CASE就是这个框架的重要元素.它是TESTER判别产品的标准,所以我觉得一个好的CASE框架是一劳永逸.
2.测试用例不应该包含实际的数据
CASE也不能完全包含实际数据,我认为包含的实际数据是有一定特点的:
比如 数据具有隐蔽性,测试人员很难TOUCH到 ,标准数据(这个很重要,它是判别产品是否按设计标准来开发的).这些是
CASE中应该要具备的,且不可缺少的.但是在MEMORY LEAK TEST中我们是不能限制TESTER具体输入什么数据,输入多少
次,这样做TESTER的IDEA会被BLOCK掉.限制了TESTER的思维对压力测试的效果会有很大的影响.这就是为什么会有
FREE TEST.所以CASE千万不能太过于限制.一个好的CASE既要有标准,还要灵活.
呵呵,就这些,其它的几点我也和楼主观点一样. 最近正在研究这问题,希望能多多交流。 很想学习学习各位高手的测试用例的编制样板,新手刚来,请各位赐教!