【问题标题】:Test case design for Max() functionMax() 函数的测试用例设计
【发布时间】:2016-11-18 21:54:44
【问题描述】:

这里是 C# 新手。

我理解测试用例应该是:

  • 简单透明
  • 重复次数最少
  • 确保 100% 的代码覆盖率

我也了解边界值分析和等价分区的基础知识,但是使用下面的函数,什么是基本的测试用例?

    static public int Max(int a, int b, int c)
    { // Lines of code: 8, Maintainability Index: 70, Cyclomatic Complexity: 4, Class Coupling: 0
        if (a > b)
            if (a > c)
                return a;
            else
                return c;
        else
            if (b > c)
                return b;
            else
                return c; 
    }

这是我目前所拥有的......

  using Microsoft.VisualStudio.TestTools.UnitTesting;
    using ConsoleApplication10;
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    using System.Threading.Tasks;

    namespace ConsoleApplication10.Tests
    {
        [TestClass()]
        public class ProgramTests
        {
            [TestMethod()]
            public void MaxTestNulls(int a, int b, int c)
            {
                Assert.IsNotNull(a, "The first parameter must be present.");
                Assert.IsNotNull(b, "The second parameter must be present.");
                Assert.IsNotNull(c, "The third parameter must be present.");
            }
            [TestMethod()]
            public void MaxTestTypes(int a, int b, int c)
            {
                Assert.IsInstanceOfType(a, typeof(int));
                Assert.IsInstanceOfType(b, typeof(int));
                Assert.IsInstanceOfType(c, typeof(int)); 
            }
            [TestMethod()]
            public void MaxTestBasics(int a, int b, int c)
            {
                if (a > int.MaxValue || b > int.MaxValue || c > int.MaxValue)
                {
                    Assert.Fail();
                }

                if (a < int.MinValue || b < int.MinValue || c < int.MinValue)
                {
                    Assert.Fail();
                }
            }
        }
  }

我完全不在这儿吗?我的老师不会鼓起勇气给我任何提示。。我还可以使用哪些其他测试用例有用?

【问题讨论】:

    标签: c# unit-testing testing tdd


    【解决方案1】:

    一种可行的测试策略称为分支覆盖。在那里,您尝试编写覆盖被测系统中每个执行分支的单元测试。

    在您的情况下,不同的执行分支是 return 指令:return areturn creturn b 和底部的 return c

    您可以使用这些用例(分别为 a、b 和 c 的值)覆盖整个功能:

    4, 2, 3
    4, 2, 5
    4, 2, 4 <-- boundary condition
    2, 4, 3
    2, 2, 3 <-- boundary condition
    2, 4, 5
    2, 4, 4 <-- boundary condition
    

    正好有四个测试用例确保所有分支都被覆盖。另外三种情况是为了涵盖仍然存在于特定分支中的边界条件。

    下面是这些测试用例在 xUnit 中的实现。我之所以选择 xUnit,是因为它通过使用 InlineData 属性支持一种测试方法的多个测试用例:

    [Theory]
    [InlineData(4, 2, 3, 4)]
    [InlineData(4, 2, 5, 5)]
    [InlineData(4, 2, 4, 4)]
    [InlineData(2, 4, 3, 4)]
    [InlineData(2, 2, 3, 3)]
    [InlineData(2, 4, 5, 5)]
    [InlineData(2, 4, 4, 4)]
    public void Max_ReturnsExpectedValue(int a, int b, int c, int expectedMax)
    {
        int actualMax = Program.Max(a, b, c);
        Assert.Equal(expectedMax, actualMax);
    }
    

    仅作记录,所有七个测试用例都通过了您的上述实现。

    在相关说明中,这种测试称为白盒测试。您可以访问具体的实现,然后您正在为该实现编写测试。如果您想实现黑盒测试,那么您的测试用例将仅由您对该功能的期望驱动。例如,这些可能是黑盒测试的合法测试用例:

    1, 1, 1 -> 1
    1, 1, 2 -> 2
    1, 2, 1 -> 2
    1, 2, 2 -> 2
    1, 2, 3 -> 3
    1, 3, 1 -> 3
    1, 3, 2 -> 3
    1, 3, 3 -> 3
    2, 1, 1 -> 2
    ...
    

    这里的问题是我们不知道哪些边界条件是相关的,因此我们必须添加相当多的边界条件来涵盖所有选项。如果你继续朝着同一个方向前进,那么测试的总数将是 3^3=27。

    【讨论】:

    • 这很有帮助,谢谢。还有一个问题,我将如何在单元测试中实现这一点?每当我尝试在 TestMethods() 中调用 Max() 时,都会出错。
    • 我想我对实现感到困惑。
    • @dotKn0ck 参见上面的测试方法实现。
    【解决方案2】:

    第一个明显的加法就像 itsme86 说你应该测试 3 个输入中的任何一个是否相等。

    其次,您应该测试依赖关系,这意味着输入的值可能是每次评估都会更改的函数的输出,因此请确保在测试类中获取输入的单个实例(即评估一次) 并继续在此本地实例上进行测试,并且不要重新评估输入

    我对 C# 了解不多,但让我给你看一个通用的例子

    public static TestFunction (int A, int B, int C)
    {
    // Your test methods
    }
    

    如果这样调用

    boolean Result = TestFunction((int)Math.sin(System.currentTimeMillis()),(int)Math.sin(System.currentTimeMillis()),(int)Math.sin(System.currentTimeMillis()));
    

    每次在您访问 A、B 或 C 的函数中,它们的值都会被重新评估,并且可能会否定之前测试的结果

    我会添加额外的测试,例如 X = A、Y = A、X-Y = 0 以确保 A 在重新评估时不会改变,可能会添加时间延迟以防它依赖于时间并且程序执行速度太快而无法反映(您需要纳秒级的分辨率来反映小而简单的代码的不间断执行)

    【讨论】:

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