【问题标题】:How to write Test Cases?如何编写测试用例?
【发布时间】:2013-01-03 12:13:32
【问题描述】:

我想在编写代码之前学习如何编写测试用例。我读了一篇关于测试驱动开发的文章。我想知道开发人员如何编写测试用例?例如这个方法:

    public int divideNumbers(int num1, int num2)
    {
      return num1 / num2;
    }

【问题讨论】:

  • 您知道您在测试之前已经编写了代码吗? :)

标签: c# testing testcase


【解决方案1】:

我们现在从一个空白项目开始。你想做某事,比如说除以两个数字。所以你写了一个测试来描述你想做什么:

Assert.That(divide(10,2), Eq(5))

此测试为您提供了一个入口点:它描述了divide 方法的可接受接口。因此,您继续以int divide(int x, int y) 的形式实现它。

编写描述您希望从代码中获得什么的测试。你不需要考虑太多。编写期望的最正常方式可能是设计代码的最佳方式,然后您可以实现它以满足您的测试。

【讨论】:

    【解决方案2】:

    有几个测试步骤。来自MSDN;

    在你的情况下;

    Assert.AreEqual(divideNumbers(8, 4), 2);
    

    Assert 类使用true/false 命题验证单元测试中的条件。你应该写你的测试用例你期望他们的结果。您可以将TestMethod 属性用于您的测试方法。有一个关于Creating Unit tests for your c# code 的很酷的帖子。分析得很好。

    【讨论】:

    • 其实我想问的答案就是你从codeproject分享的链接。谢谢。
    【解决方案3】:

    从您要开发的函数/类/组件的存根开始。它应该编译,但故意不(还)做它应该做的事情。

    例如:

    public int divideNumbers(int num1, int num2)
    {
        throw new NotImplementedException();
    }
    

        return -42;
    

    考虑预期的行为,将存根视为黑盒的接口。不关心实施(还)。想想接口的“契约”:X进去,Y出去。

    识别标准案例和重要的egde案例。为他们编写测试。

    对于整数除法(假设我们从头开始编写),实际上有很多情况需要考虑:有和没有余数、n/1、n/0、0/n、0/0、负数、等等

    Assert.IsTrue(divideNumbers(4,4) == 1);
    Assert.IsTrue(divideNumbers(4,3) == 1);
    Assert.IsTrue(divideNumbers(4,2) == 2);
    Assert.IsTrue(divideNumbers(4,1) == 4);
    Assert.Throws<ArgumentException>(() => divideNumbers(4,0));
    
    Assert.IsTrue(divideNumbers(0,4) == 0);
    Assert.Throws<ArgumentException>(() => divideNumbers(0,0));
    
    Assert.IsTrue(divideNumbers( 4,-2) == -2);
    Assert.IsTrue(divideNumbers(-4, 2) == -2);
    Assert.IsTrue(divideNumbers(-4,-2) ==  2);
    
    Assert.IsTrue(divideNumbers( 4,-3) == -1);
    Assert.IsTrue(divideNumbers(-4, 3) == -1);
    Assert.IsTrue(divideNumbers(-4,-3) ==  1);
    

    编译并运行单元测试。他们都失败了吗?如果不是,为什么?也许其中一项测试没有按预期工作(测试也可能有问题!)。

    现在,开始实施,直到不再有测试失败。

    【讨论】:

      【解决方案4】:

      从认识理论与实践的区别开始。

      任何现实生活中的系统都会有一些可以通过 TDD 轻松创建的东西,而有些则不是。

      最后一组是一切都依赖于环境,当在一个不寻求抽象环境假设但务实地接受这些假设的系统上工作时。

      可以以 TDD 方式开发该组,但需要额外的工具和对软件工厂的扩展。

      对于 .Net,这将是工具和扩展,例如 MS 虚拟测试实验室和 SpecFlow。

      我想表达的是视情况而定

      对于非常简单的组件/单元测试,想法是在编写要测试的代码之前编写一个失败的测试用例,并在测试成功运行时结束开发。

      对于集成测试及其他测试(系统测试),除了考虑测试什么之外,您还需要考虑如何将测试环境带入某种已知状态。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-09-08
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多