笨笨的思想片断

业务驱动用例测试

笨笨所知的测试大致分类

单元测试/Unit test
基于代码中类或函数一级的测试

用例测试/Use case test.
基于一个完整业务用例的测试，可以不包括用户业务系统环境的完整操作流程。
如，银行网银系统的转账测试可以认为是一个完整业务用例测试，但是不必要要求测试用例先执行登录过程，再进行转账业务代码的测试。

集成测试/Integration test
由业务人员主导，业务系统作为一个完整黑盒，测试系统功能和性能。

用户接受测试/User Accept test
集成测试通过后，用户基于生产系统剥离的实际数据，再一次对业务系统执行测试；如果集成测试不充分，可以再一次有机会暴露系统的缺陷。

项目实施过程与测试

从项目的实施过程来说，单元测试是程序员自测，算在开发阶段，集成测试和用户接受测试所占用时间能够达到项目代码开发阶段的一倍到两倍，大型项目的测试阶段可能还要长。
而用例级测试目前很少作为一个正式的阶段在项目实施过程中存在，或由程序员自行自测，或合并到集成测试过程中。

对于大型业务系统，集成测试和用户测试所花费的主要工作量如下，可能不全。
1 数据准备，测试人员调配准备。
2 测试过程中，测试人员要找到哪些测试数据还能用，再手工操作系统界面，执行测试过程。对于大型业务系统来说，可用测试数据是随着测试进展不断变化的，很有可能某个用户数据刚刚状态正常，现在就欠费了。要想找到合适的数据来测试系统，这是个费劲且混乱的过程。
3 集成回归测试，业务系统如果有升级或改动，需要将所有交易重新测试一遍，以防止变更给原有代码引入缺陷。

用例测试
用例测试关注业务。

用例测试集中在业务服务这一层，业务服务直接对应了业务用例。
用例测试注重业务服务运行环境的模拟和重现，从而支持业务服务层的自动测试。

用例测试的价值
1 减少集成测试的时间和成本，降低集成测试发现缺陷数，从而降低项目总缺陷修复代价。
 用例测试缺陷修复代价远低于集成测试的缺陷修复代价；用例测试发现大部分缺陷后，集成测试就相对轻松了。
2 可回归的用例测试支持快速代码重构。
3 ...

单元测试无法覆盖用例测试
业务代码运行需要底层资源如数据库或其它业务系统配合，单元测试工具缺乏提供业务服务运行所需环境的模拟，从Junit系列单元测试工具来说，它还是主要从技术角度考虑，从业务角度的考虑如：
底层资源（数据库，JMS）模拟
依赖服务模拟
服务访问模拟
自动检测、重放和比对服务运行时的输入输出参数、资源、依赖服务。
服务接口变动波及分析

代码重构的成本
代码重构需要付出代价。集成测试费时费力，但用户不可能因为程序员说“我保证代码重构不会改变系统功能”，就不对变动后代码进行测试。
用例回归测试支持可以以较小代价支持代码重构，因为它可在业务服务级自动对功能进行验证，集成测试工作能够相应的减少。