(2)、完整业务流程的测试
我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线,其中的某个按钮是点,多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。
事实上目前公司的软件本来都是业务型应用软件,将各种功能从业务流中切割出来单独写用例,肯定也会有涉及到整体流程的情况。若不加以区分,将细节与全局搅在一起,不仅思路混乱,也容易考虑不周。因此在系统测试阶段,建议用例设计要有分有合,针对具体功能的就只围着这个功能转:而在业务流程测试项中,再完全从整体的业务流角度出发去考虑用例,这样不仅不容易产生疏漏,用例阅读与执行也更清楚。
(3)、某种特定情况下的系统运行
这类用例的设计往往与系统实际业务情况密不可分。比如财务软件,通常需要在月尾一天、月头一天、年尾一天、年头一天,对所有相关功能中的日期处理进行测试;又比如WIN 2000环境开发测试的系统,要测试在98、XP、2003等操作系统下是否能运行自如;再有如存在大量动态图片视频等的网页,在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑,来进行测试补充。
(4)、其它相关系统
即指在当前项目中直接使用的其它成果,包括公司自有的系统模块、组件、函数;以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚,是否需要测试。若时间紧张或其它原因决定不测的,应在测试计划中说明。若需要测试的,则具体可根据实际情况来设计,可以是通过系统某个功能的测试来涉及,此时就不需要单独划分测试项;若相对比较独立的,也可以通过单独的测试项来对其专门进行测试。
(5)、除功能测试外的其它测试类型
包括可靠性、安全性、恢复性、配置安装测试等等,这些测试类型都是一个单独的测试项。
所谓好的开始是成功的一半,保证测试项划分的完整、合理、正确,会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑,并要在测试过程中随着对软件的深入了解,不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。