摘要：测试用例是将测试行为具体量化的方法之一。本文通过一个具体的测试实例--122接处警系统测试项目，从系统的功能测试、性能测试和可靠性测试等方面对测试用例进行设计，希望起到抛砖引玉的作用。
0.引言
如何高效地设计测试用例一直是业内人士热衷探讨的话题。下面笔者结合122接处警系统测试项目谈谈测试用例的设计方法及技巧的应用。
1.项目情况
122接处警系统利用现代化的通信技术和计算机技术，综合利用网络和信息资源，以接处警系统为核心，集成了地理信息系统、地图定位系统、大型数据库系统、大屏显示系统等子系统。系统采用指挥中心统一接警，支大队、执勤队分级处警的方式，能够受理事故、拥堵、路况信息、咨询服务、投诉、反映等各类案件，实现接警、处警、指挥调度、监督管理、语音咨询、督察投诉等功能，同时能够对接处警信息进行统计、查询和深层次分析及智能化系统管理，并且提供系统全程数字录音、中英文语音服务等。
本项目的测试内容包括：业务系统功能测试、性能测试和故障测试。
功能测试主要包括接警子系统、处警子系统、305台、地图台、报警查询子系统、监督子系统、管理子系统、统计查询子系统、软电话功能、前端交换机功能等功能点测试和接处警流程、错发流程等业务流程测试。
性能测试包括前端大话务量测试和业务系统负载压力测试。前端大话务量测试主要采用思博伦Abacus5000硬件测试仪来模拟多用户同时拨打电话，度量在大量用户同时接入系统时系统的承受能力。业务系统负载压力测试主要测试的是在特定应用的业务逻辑、用户界面、功能下系统能够承受的用户并发数量、交易数量和响应时间。本次测试采用HP公司的LoadRunner8.0性能测试工具对接警业务、处警业务和案件统计查询分析等典型业务以及混合业务进行测试。
故障测试实际上是一种可靠性检验。主要包括对各类服务器的单点单机、单点双机故障测试及交换机故障测试，在模拟故障的情况下检查系统的运行情况。
2.功能测试设计
为了能够用较少的用例覆盖尽量多的流程分支以及功能点，我们采用了业务流程为主、辅助功能点测试的方法，并运用了等价类划分法、边界值分析法、错误推测法、因果图法、场景法等多种设计方法。
2.1.业务流程测试用例设计
首先介绍如何用场景法设计业务流程的测试用例。场景法主要是对系统运行流程进行分析，从业务流程考虑用例应包括的哪些基本流和备选流，通过用例场景并结合各路径的触发条件来确定用例应遵从的流程。
1、业务流程图
如图1所示为主要模块的业务流程图。
2、主备选流关系图
根据上面的流程图和用户使用手册，我们可以归纳出一个看上去比较清晰的主、备选流关系图，如图2所示。
直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的曲线表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中；也可能起源于另一个备选流，或者终止用例而不再重新加入到某个流。
各路径与触发条件的对照表如表1所示。
3、场景分析
遵循如图2中所示的路径，可以确定不同的用例场景，从基本流开始，将基本流和备选流结合起来，可以确定各种场景。（如表2所示只是列出部分的场景）。
确定场景后，便可对每个场景确定测试用例。在此不再赘述。
2.2.功能点测试用例设计例举
当然，业务流程的测试不可能覆盖全部的功能点，因此在流程测试结束后，我们应及时地查漏补缺，对遗漏的或未涉及流程的功能点进行补充测试。
对功能点的测试通常采用等价类划分法、错误推测法、边界值法等。如在本系统中，在管理台添加代码时只能输入数字，因此，用错误推测法设计测试用例如表4所示：
测试过程终止条件被测软件故障或测试取得预期结果
测试结果评估标准与期望结果一致
前提和约束以用户"0001"进入接处警系统，具有对代码表进行添加、修改、删除等的权限
2.3.功能测试策略
首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的最有效方法。
在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。
可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。
如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。
对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
3.性能测试设计
3.1.前端大话务量测试设计
前端大话务量测试主要涉及多并发用户、不同呼叫持续时长及呼叫持续时间的流程设计。
交管局对系统呼叫处理能力的要求为：
①检测系统在日常时呼入和高峰时呼入的表现，从而得到系统小时/日最大承受能力；
②支持180条中继线数和50个坐席数。
因此，我们设计了从并发20用户开始，20、30、60…递增直至瞬时呼叫占满180路中继，检验系统在日常呼叫和高峰呼叫时的承受能力。同时，为了真实地模拟用户打入电话时各种不同的情况，我们为每个并发呼叫流程设计了不同的呼叫持续时长。如图3所示。
设计呼叫持续时长为2秒的流程主要是为了验证大话务量压力下前端交换机的承受能力，因为交换机是该系统的一个"核心"。而呼叫持续时长为10秒、20秒或50秒的流程主要是为了验证客户端在不同情况的外线接入时的表现。
由此，我们得出前端大话务量的测试流程，如表5所示为并发20用户时的单流程和混合流程设计。
3.2.业务系统负载压力测试设计
根据122接处警系统的业务特点，接警处理、处警处理为该系统主要的日常业务，且对服务器的负载压力较高，因此"接警"、"处警"业务为并发性能测试的重点。
而案件统计查询为一天内某特定时刻系统要进行的操作，且对数据库服务器的负载压力影响较大，因此我们选取"案件统计查询"这一业务进行大数据量测试。
但是若在并发测试的过程中不考虑数据量对系统性能的影响无疑会给系统带来缺陷，因此，我们还采用了并发测试和大数据量测试相结合的综合测试方案，如"接警并发用户50、处警并发用户50和统计查询并发用户20"等案例，以定位问题、分析系统瓶颈从而进行系统调优。
例举接警测试用例如表6所示。
4.故障测试设计
由于交管局对122接处警系统的高可靠性要求，如关键部件包括交换机、存储器、CTI链路等应有热备；交换机必须能做到365天ⅹ24小时的连续运行；交换设备呼叫处理能力不低于设计负荷能力的90%等，因此，我们在大话务量压力和业务系统负载压力的前提下进行了故障测试，以检验和诊断各类服务器在失效的情况下系统的表现。
故障测试主要分为两部分：一部分是前端硬件故障测试；另一部分是业务系统故障测试。在前端硬件故障测试中，我们主要选取影响系统正常运行及主要功能实现的故障点如交换机、中继卡、CTI服务器、NICE存储服务器、NICE录音服务器等，主要验证在该服务器失效的情况下整个系统的状态；在业务系统故障测试中，我们同样选取了影响业务系统运行和负载能力的服务器如应用服务器、数据库服务器、负载均衡器、GIS服务器等，验证在一台服务器失效的情况下系统能否正常工作。部分故障点及期望结果如表7所示。
5.小结
本篇以122接处警系统为例介绍了如何在具体的测试项目中设计测试用例，其中对功能测试用例、性能测试用例和故障测试用例渲染了较多笔墨，希望对读者起到抛砖引玉的作用，在以后的具体测试项目实施中能够灵活、高效地设计测试用例。
