“黑-白”单元测试

*Q&PXdn/}%wR0　　近期查看了一些关于敏捷开发，极限编程的一些资料。在敏捷开发中有一种比较出名的方式即TDD（Test Driven Development，测试驱动开发），这些都包含测试先行的思想。细细分析一下，发现其中有一些还是很有用的思想，也就是我今天要讨论的问题，用“黑-白”流程来做单元测试。51Testing软件测试网X[&sG2fql@(s

l4G5szOv0　　其实这只不过是一种古老的思想了，Ron Patton的那本著名的《Software Testing》中已经提起过这种方法，我只不过是拿来念叨一下而已。所谓“黑-白”思想，其实很简单就是在做单元测试的时候，先按照黑盒的理解来写测试用例或者Test Code /Test Methods,然后再去看代码，在从代码的角度来更新用例：删除“多虑”的用例，增加“漏网”的用例，更新“不合时宜”的用例。51Testing软件测试网b+Hp_K
^ P

　　“黑”，要求我们按照已有的需求分析文档，以及PM提供的Feature Spec文档来定义我们的测试用例，我们一开始要避免直接拿来代码就写单元测试，而是要思考我们需要避免哪些问题。比如再考虑一个用户文本框输入验证的类的时候，我们按照黑盒测试的思想来考虑，例如非法字符的输入验证的问题，我们可能需要考虑“<>/'”等等这些用例，然后为了可以在用例执行完毕从执行结果中直接拿到导致失败的字符，我们可能就需要写一个验证“'”的用例,写一个“<”相关的用例等等。

8`.Eb7_ sO3MK0　　“白”，在“黑”之后，即拿到代码之后我们开始单元测试用例或者Test Code/Test Methods,这个时候我们拿到了代码，知道了代码的实现逻辑，我们就要对刚才“黑”出来的用例进行更新了。还是拿上面用户登陆的例子来讲，我们可能考虑了用户输入中一些非法字符对于数据库的影响，当我们看到数据访问层中的代码是通过存储过程来实现对数据库的访问，我们就大可放心了，这个时候我们就可以更新我们的用例，将我们那些用例删除，当然最好的办法是将所有的东西写在一个用例中，可能只需要一个VerifyChars(string s)就可以了。

&^U'Gze4\G6ZB0　　上面的例子比较牵强，我只是用来解释我的想法而已。对于测试来讲，方法是最重要的。测试远不是随便点点或者会一两个工具就可以摆平的事情，对于测试，我将它作为职业，而不是工作。51Testing软件测试网cYf5i%Ol