技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 其他 --> 什么样的测试用例是好的

什么样的测试用例是好的

浏览:2094次  出处信息
    作为测试人员,设计测试用例是干活的第二步(第一步当然是了解测试对象嘿嘿),这一步做的好与否,对后续工作起着决定作用,那么如何评价一个测试用例的好坏,或者说,设计的成功与否呢,本文大概讨论一下,抛砖引玉吧,记录在这里,看看是不是可以作为一次团队讨论的话题。

    在此之前,我们需要明确测试工程师的工作原则:用最小的成本找出最多的问题。

    1.用例覆盖程度

    毫无疑问,这一点应该是最重要的,无需多说,覆盖率最大化是一套测试用例的最重要评价标准,如果漏测就杯具了。

    2.用例是否已经达到工作量最小化

    在满足用例覆盖程度最大化的前提下,应该尽量减小执行用例所需要的工作量。这些方面的方法有不少,如条件覆盖,分支覆盖,正交覆盖等方法。面对不同的测试对象,也有不同的方法来保证:对于网页背后的php逻辑,可以通过在网页上测试后,用一些工具比如xdebug来统计代码覆盖率;对于向外提供接口的server,采用的方式就是分析在外面暴露的接口设计用例,大致的通过接口参数来估计一下分支判断的情况。

    3.用例的分类以及描述是否足够清晰

    用例的分类,在这里是指相同类型的用例是否放在一起了。例如:接口类的用例,参数的取值范围是1-3,但是现在却传入4;数据类用例,状态机现在位于状态2,却要求状态跳转到无法到达的4;逻辑类用例,正常功能的产出等。将相同类型的用例放在一起,有助于理清思路,清楚了解用例设计是否完备。

    用例的描述,是指描述的清晰程度是否能够形成文档。例如上面参数取值范围的例子,用例这样写:“传入错误的值”或者“传入非1-3的值”,明显没有写成“传入值4”有效。这与写程序一样,总是写闭区间的范围而不是开区间。

    4.用例是否表明了测试目的

    写明用例的测试目的,对文档的易于理解性和工作交接的好处不言而喻,现代软件工程不可能只有一个人在做事情,项目于人员的变动也是难免的。在过程中留下足够的信息,可以在后续工作提高很多效率。

    5.测试用例的易于维护性

    如果被测对象有所升级,测试用例的说明或者脚本是不是容易维护呢?例如在有状态机的情况下,测试用例之间是相互依赖的(即需要一定的执行顺序),这样被依赖的用例修改后,后端不需要同步根据修改。而如果用例之间没有相互依赖关系(如用例是自己造的数据,不是依赖于前端的产出),可能一旦有变化,就需要修改这两个。当然,这两种情况不能绝对的说哪种好,是需要看实际使用时候的情况进行取舍的。不过,通过一些系统性的工具支持,也会出现一种做法绝对性的好于另外一种的情况,情况很多,做法也有很多,在这里就不多说了。

    说了这么多,其实这个第二步,还是严重依赖于第一步的,如果对测试对象的需求,实现等都不了解,设计用例也就无从谈起了。

建议继续学习:

  1. Xvfb+YSlow+ShowSlow搭建前端性能测试框架    (阅读:54226)
  2. 安全测试与渗透测试区别    (阅读:23709)
  3. 使用Fiddler对手机应用进行抓包测试    (阅读:6940)
  4. 服务器性能测试工具推荐    (阅读:6486)
  5. 给Apache做压力测试时遇到的问题    (阅读:5935)
  6. WEB性能测试工具推荐    (阅读:5660)
  7. 可用性测试好助手——Morae软件的应用    (阅读:5511)
  8. 12款很棒的浏览器兼容性测试工具推荐    (阅读:4871)
  9. 可用性测试的权衡之道(二)    (阅读:4813)
  10. 性能测试工具sysbench简介    (阅读:4763)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1