软件测试用例设计方法之切面设计
一、测试用例的切面设计
所谓测试切面设计，其实是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。
事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例设计要有分有合，针对具体功能的只围着这个功能转：而在业务流程测试项中，再完全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。
(3)、某种特定情况下的系统运行
这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾、月头、年尾、年头，对所有相关功能中的日期处理进行测试;又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如;再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之是要尽可能从实际应用的角度出发考虑，来进行测试补充。
(4)、其它相关系统
即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数;以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时不需要单独划分测试项;若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。
(5)、除功能测试外的其它测试类型
包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。
所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来可以了。
(1)、具体
功能测试
根据需求分析设计，按页面提供的各个功能项，采用黑盒测试的各种方法，设计用例。比如页面提供了增、删、改、查功能，那么这四个功能是否正确实现是我要验证的。这是简单、基本，同时也是必须的测试用例，通常我们的编码人员自测也是做到这个程度。^_^
这是从上一角度扩展出来的，相对而言也是编码人员不会去测试的，所以需要测试人员多作考虑。
一般来说我们会考虑功能项之间的数据是否会存在关联，若有需要考虑这种组合了。常见的如查询功能，需要将各条件逐一累加进行测试;增完的数据能否改，改完能否删，删完能否再增，这之间能否查询到正确结果;按钮的连续多次点击会否出现异常;有严格前后顺序要求的几个操作，尝试颠倒顺序去操作，系统能否控制等等。
不仅在某功能内部，扩展到有关联的多个功能项之间，同样有组合操作测试的存在。如申报完了能才反馈;如申报成功或失败后再尝试申报等。当然对于这类用例既可以写到某个功能切面中，也可以单独写到完整业务流程的切面中，这取决于可能涉及用例的数量了，若关系比较复杂，当然是单独写比较好;若也是三五个用例数，那直接在某个功能的用例中补充好了。
