关于测试用例评审

发表于:2013-11-15 11:33

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:daqing_1223    来源:51Testing软件测试网博客

分享:
  今天来说下测试用例的评审吧,大家都知道测试用例对一个测试人员的重要性,之于测试,如果没有测试用例,就如同不带武器上战场的士兵,既然测试用例这么重要,我个人觉得测试用例的评审也是更为重要的一个环节,因为设计测试用例跟个人的专业知识、对行业的了解程序、对需求的理解程序及个人工作经验是息息相关的,而且一个人的思路毕竟是有限的,如果有多人参与到测试用例的评审,在测试开始之初就提出遗漏及有可能避免的测试风险,那测试用例的覆盖率也会大大提高,产品的质量也会得到更好的保证。至于测试用例的设计我这里就不多说了,论坛里有很多资深的人士都有写过这个话题,文章也写了很多。
  在上一家公司的时候,我曾经跟我们部门经理提过用例的评审,但是他说测试用例这么多,不可能让开发、产品的人员去看完那么多的用例然后来给出建设性的意见,即便是测试组的,一个同事写了发出去给其他同事看,说实在的,没几个人愿意去看,一、没有那么多时间,二、没有组织过用例评审,三、一般情况下,人都是觉得不关已事,高高挂起。而且很多同事,一般情况下如果上级要求你去审查、修改别人的用例,大部分人的想法是:还不如自己写来得快。
  以前写测试用例都是用excel表,现在用testlink,一开始有点不习惯,但是也发现了2者都各有好处,也有弊端,excel比较方便编写、直观、便会统计测试结果及数据,但是如果功能模块比较多的情况下要分成很多张表格来编写,层级模块间的关系不太明显,而且如果操作步骤太多的话,移动下拉框查看不方便查看内容;testlink系统速度太慢,但是功能模块层级表现的较为明显,如果操作步骤多看起来也很直观;编写用例比较麻烦,复制粘贴都不方便,而且在创建测试步骤,中间删除了一步,就得重新插入,下面一步序号连不到一起,移到到另一产品下项目非得导出再导入,这个是比较麻烦,而且执行用例的时候也很麻烦,必须把所有测试用例关联到测试计划,执行的时候容易出现问题,统计数据也没那么方便。
  以前在聚晖,其实测试组也是有做个内部的评审的,就先按需求规格说明书将各测试的功能点列到excel表里,然后给测试组的同事看,提出遗漏的地方及各自的观点。到多玩后,发现在一个新功能开始编写用例前都会先用MindManager按规格说明书将各测试的功能点及相关兼容性等全部列出来,然后发起会议通知开发、产品相关人员对其进行用例评审,提出遗漏的、有问题的地方。我觉得这是个非常好的方法,因为以前用excel的方式不是很方便查看,如果功能点都分开的话看起来就会显示很凌乱。但是用MindManager做出来的用例心导图是非常直观明了的,各功能模块及测试点都列出来了,一目了然,很方便做用例评审。这也是我呆过2家公司用过2个方式比较后觉得后者更佳,是比较方便做用例评审的一个方法吧,不知道其他公司是怎样做用例评审的,大家如果有什么好的方法不如一起分享、一起探讨吧。
版权声明:本文出自 daqing_1223 的51Testing软件测试博客:http://www.51testing.com/?318592
原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • lyscser
    2013-11-18 14:33:32

    建议MindManager发律师函到所谓的“聚晖”

  • qqqfresh
    2013-11-18 12:51:10

    Testlink已经升级了,很多问题已经解决了。
    例如复制粘贴,序号不连续的问题。

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号