单元测试用例和功能测试用例
任何类型的测试都应该有自己的测试用例。但是 ，我一直在想，是不是功能测试用例可以运用到单元测试用例上来？如果可以的话，是否可以不用写单元测试用例了？在我的理解里面，单元测试也是根据实际输出于预期输出（包括在各种输入情况下的输出）是否相符来判断程序是否正确。在我设计功能测试用例的时候，也是这样的设计的，所以，我认为是可以把功能测试用例拿到单元测试上来运用的。唯一的可能就是功能测试用例里面的用例有些在单元测试的时候是执行不了的。
不知道大家的见解如何。
单元测试用例和功能测试用例
我觉得楼上说的有道理。单元测试是处于最开始的阶段，在使用具体技术的时候当然可以借鉴功能测试的方法。 “单元”这个词的意义不明确，一个类或小模块或函数都可以算是“单元”，流行的说法是与类为单元，但在实际开发中，不要说很复杂的类，就是比较简单的类如十几个成员函数，三五个成员变量，如果以类作为单元测试的单元，做起来也太复杂了，不实用，所以我主张以函数为“单元”，实际上，测试一个比较复杂的函数，也不见得很简单，有些可能要十几个测试用例。明确了单元的意义，再来谈测试用例就比较容易理解了。单元测试的测试用例，就是测试一个函数在某种输入时是否产生正确的输出，例如，对于函数int Add(int a, int b){return a+b;};，输入两个1，判断是否返回2，这就是一个典型的测试用例，测试的就是函数的功能。可以说，单元测试的测试用例，主要是功能测试用例，只不过，功能所针对的是代码单元。 多谢楼上的朋友。现在我基本上能区分出单元测试用例和系统测试的功能测试用例的区别。单元测试我也主张细化到函数，针对函数的输入输出设计测试用例。这样一来和功能测试用例的最大的区别就是功能测试用例是完全黑盒的，不管实现的路径是什么，也就是说他的实现可能是一个类，可能是类里面的一个方法。我们在设计功能测试用例的时候都是从form表单上看界面元素设计，而不管内部东西。太感谢了～ 单元测试是白盒吧，功能测试属于黑盒，用例能在一块用吗？ 原帖由 myth007 于 2006-11-22 10:52 发表
单元测试是白盒吧，功能测试属于黑盒，用例能在一块用吗？
单元测试也有黑盒的！
关于黑盒与白盒
黑盒与白盒是测试方法，单元测试、集成测试之类的是测试阶段，每个测试阶段都可以用黑盒方法或白盒方法。简单地说，根据被测试程序的功能来设计测试用例，就是黑盒方法，根据被测试程序的内部结构来设计测试用例，就是白盒方法。黑盒方法与白盒方法各有优缺点，最好结合起来使用。C/C++单元测试工具Visual Unit的“三步法”就是黑盒方法和白盒方法相结合的。下面贴出来可供参考：（引自：http://www.kailesoft.cn/products/result.htm，具体应用示例可以看这个FLASH：http://www.kailesoft.cn/flash/070010.htm）
关于“三步法”：
1. 基本功能测试：自动生成测试驱动代码，用户只要在测试用例编辑器中填写输入输出数据即可建立测试用例；用拷贝/修改的方法快速建立其他测试用例，根据文档或代码需要实现的功能，基本测试用例通常是现成的。
2. 完成白盒覆盖：VU自动统计未覆盖的逻辑单位（语句、条件、分支、路径），并在代码窗口和逻辑结构图中标示，用户选中一个逻辑单位，打开测试用例设计器，VU自动从现有测试用例中计算出一个近似用例，并生成修改提示，依据修改提示对近似用例进行修改，即可覆盖该逻辑单位。不可覆盖的分支和路径可以在逻辑结构图中删除，经过已删除分支的所有路径会自动删除，从而减少路径数量。
3. 依据预先定义的边界值，自动生成测试用例进行测试，用于发现“编码时未考虑某些特殊输入”造成的错误，这类错误无法通过白盒覆盖来发现。
使用“三步法”，在实现100%语句、条件、分支、路径覆盖的基础上，还用自动边界测来捕捉“编码时未考虑某些特殊输入”造成的错误，这种测试完整性是空前的。需要多少时间呢？第1步只要在测试用例编辑器中填写或修改输入输出数据，第2步只要依据修改提示在测试用例设计器中修改输入输出数据， 第1步的测试用例基本是现成的，第2步是找出遗漏的测试用例，耗费时间都不多，第3步是完全自动的，可见，“三步法”需时很少。虽然需时很少，还是需要时间，如何“在原来只用于编码的时间内完成编码和单元测试”呢？通过提高编码调试效率来抵消测试时间！
页:
[1]
