关于编写有效测试用例的思考和方法- 第一篇 优秀测试用例标准

发表于:2013-7-31 11:03

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

 作者:blacksilk    来源:51Testing软件测试网采编

分享:

  最近一直在研究软件测试相关理论,个人认为测试其实这是一个复杂的学科,一个优秀的测试工程师需要具备多方面的能力和扎实的计算机理论,软件工程理论和编程思想。测试用例的设计更多地依赖你的逻辑是否完整,还需要一定统计学上基本东西,毕竟我们不能做到全路径覆盖。

  测试用例是测试的核心,如何设计出能发现问题,有效能覆盖需求,没有冗余的用例是每个测试工程师必须跨过的一道门槛。结合本人这么多年来在测试领域的经验总结,我们下面先探讨一下衡量和检验测试用例的标准?然后怎么做?为什么要这么做?还能做什么?测试用例的选择策略也可以谈谈,你如何来建立回归测试库?

  我心目中优秀测试用例的标准如下:

  有可能发现bug的

  执行起来效率高,没有冗余步骤,每步都是最佳选择

  能验证需求的,可追溯的

  粒度问题,不要超过3个检查点,如果很复杂,需要讨论怎么分解需求,最多做到5个

  逻辑上一定是正确的,清晰的

  用例应该有级别,为以后选择用例提供参考。

  一一来分解:

  1 测试的主要目的是发现问题,查找错误,所以设计case的思路应该是”程序可能会怎样实效?“

  2 测试步骤不能太详细,派出一些冗余的步骤。另外有可能两个用例比较起来也会发现冗余,这样的用例执行起来效率低下,浪费时间。

  3 确认测试的主要目的就是确认产品,软件的需求是否实现,因此每一天用例可以追溯到某条需求或者它的合理分解。最怕就是自己杜撰需求,设计出来的用例最好能找到开发,或者市场,产品经理的review.

  4 测试用例应该有期望结果,期望结果里包含就是检查点,检查点过多,过于复杂,难于被执行测试人员理解,影响测试执行效果。我的经验一个用例不要超过5个检查点。

  5 测试用例的顺序很重要,谁是谁的必要条件,逻辑上不能出错,否则很难执行,或者会误导测试执行人员,最严重的情况失去测试人员信任,测试工程师最后按照自己的想法执行,造成漏洞。

  6 不可能每条用例都要被执行,在最后时间紧迫的情况下,测试经理会挑选级别高的测试用例来执行,保证主要功能被测试过。

  还有其他吗?希望大家积极思考,积极反馈!!

  如何能做到这些呢,我会根据大家的反馈,在下一篇里继续和大家探讨。

《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • xiaogx
    2013-8-15 16:33:08

    ‘6 不可能每条用例都要被执行’对于这点我想作者要表达的意思是,在回归测试的时候由于进度的原因可能需要来甄别用例的优先级,验证系统在主干流程或关键流程的正确性。

  • yemo2013
    2013-8-11 22:14:45

    '6 不可能每条用例都要被执行'不被执行的用例写出来的意义在哪?

  • hickey_hy
    2013-8-07 11:04:23

    对于你说的“测试步骤不能太详细,派出一些冗余的步骤。”测试步骤不能太详细是什么意思呢?目前我的认知是:测试用例前面一列有个概括的测试点,第二列就是详细的操作步骤。不知道这个认知是否正确呢?

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号