软件测试之遗留代码的测试方法

发布: 2009-3-23 09:37 | 作者: 不详 | 来源: 测试时代采编 | 查看: 34次 | 进入软件测试论坛讨论

        }
        menubar = view.getJMenuBar();
    }
    public void testFileIsFirstMenu() {
        JMenu file = menubar.getMenu(0);
        assertEquals(\"File\", file.getText());
    }
    public void testEditIsSecondMenu() {
        JMenu edit = menubar.getMenu(1);
        assertEquals(\"Edit\", edit.getText());
    }
    public void testHelpIsLastMenu() {
        JMenu help = menubar.getMenu(menubar.getMenuCount()-1);
        assertEquals(\"Help\", help.getText());
    }
    // Tests for other menus...
}

　　与典型的 test-first 编程不同，我在此处编写了很多测试代码却没有必要编写任何模型代码。标准的 TDD 只编写能够使一个测试失败的足够多的代码。然后，它就切换到模型代码中直到测试通过为止。我并不是说 TDD 原则是错误的，但当两百万行的遗留模型代码已经存在时，它的确不能成为一个有用的选择。那时的目的是为了尽快地获得尽可能大的覆盖率。
测试还是调试？

　　如果遗留系统是一个好的系统，您的大多数测试还是很有希望通过的。尽管如此，您也会找到 bug。当测试一个以前从未经过测试的代码基础时，这种情况很可能很快就出现而不是以后才出现。这时，标准的 TDD 方法是停止测试并且开始进行修改直到测试通过。然而，这是假设您已经测试了模型中的其他所有内容并且相当自信如果您的修改中断了系统中的其他部分，您可以立即发现。在遗留测试中，这不是一个安全的方法。在修改一个以前的 bug 时，您很有可能将一个新的 bug 引入未经测试的代码中；而且假如这样的话，您可能不能立即注意到这个新 bug。因此，强烈建议首先编写更多的测试，稍后再对 bug 进行修复。归根结底，这是一种基于如下一些因素的判断调用：

　　bug 是不是看起来简单、明显并且是局部的？
　　您是否理 bug 出现的那段代码？
　　您是否理解所作的修复？
　　如果上面问题的回答都是 “是”，那么就去修复这个 bug。如果回答是 “否”，则应该在修复改代码之前首先尽力扩充测试套件。

通过功能划分进行测试

　　在最高层次上开始测试能够以最快速度获得代码覆盖率。对于遗留代码，应该考虑应用程序在做什么而不是考虑单个方法。尽量为它所做的每件事编写测试。对于一个 GUI 应用程序如 jEdit，菜单项提供应用程序功能的一个好的典型。激活每个菜单并且证实它做了应该做的。例如，清单 3 展示了这样的测试，向一个窗口输入一些文本，激活 \"select all\" 菜单项，剪切所选中的文本，然后验证文本在剪贴板中，而不在窗口中：清单 3. 测试 jEdit 菜单

public void testCut() {
      JEditTextArea ta = view.getTextArea();
      ta.setText(\"Testing 1 2 3\");
      JMenu edit = menubar.getMenu(1);
      JMenuItem selectAll = edit.getItem(8);
      selectAll.doClick();
      JMenuItem cut = edit.getItem(3);
      cut.doClick();
      assertEquals(\"\", ta.getText());
      assertEquals(\"Testing 1 2 3\", getClipboardText());
}
private static String getClipboardText() {
      Clipboard clipboard = Toolkit.getDefaultToolkit().getSystemClipboard();
      Transferable contents = clipboard.getContents(null);