登录
注册
停车场管理系统软件技术要求
作者：杭州立方自动化工程有限公司 施广明
来源：RFID世界网
日期：2008-09-25 15:53:19
摘要：停车场管理系统软件技术要求
1 ．总则（略）
2 ．停车场管理系统术语（部分）
下列术语和定义适用于本标准（分配章节相关部分）
停车场 / 库：专指供车辆泊车使用的具有固定车辆进出通道的非立体机械式封闭场所；
停车场 / 库管理系统：具有管理和控制停车场配套设备功能的应用于停车场 / 库管理的应用软件。
长期卡：在许可条件下可在停车场 / 库长期流通的卡片，它由停车场 / 库管理者预先发放给车主 , 出场时不回收卡片。
临时卡：每次泊车临时收费泊车费用的卡片，卡片在入场时临时发放，出场时临时回收。
期限卡：在一段指定有效期内收取指定泊车费用的卡片，如：年卡、月卡等，它属于长期卡的范畴。
储蓄卡：卡片对应一个储蓄帐户，通过预先向帐户充值，泊车过程自动从帐户扣除泊车费用，它属于长期卡的范畴。
免费卡：不收费泊车费用的卡片，它属于长期卡的范畴。
固定卡：一次性收费泊车费用的卡片，它属于长期卡的范畴。
非法卡：在停车场 / 库管理系统中没有登记过的卡片。
黑名单卡：已经挂失的卡片。
防跟车：一种防止前一辆合法车刷卡而后一辆车不刷卡跟入的处理机制。
防倒车：一种防止车辆在刷卡并放行后车辆不正常进入而倒出的处理机制。
双卡认证：一种车主卡和车载卡同时认证有效方能通行的车辆防盗处理机制。
一车多卡：允许一车对应多张合法卡，但同一时刻只能允许一张卡泊车。
车流量检测：一种可以有效提高通道车辆通行效率和延长机械寿命的处理机制，当多卡刷卡后，待所有合法车辆通过通道后，方可关闭道闸。
3 ．停车场管理软件的基本规定
3 ． 1 停车场管理软件总体规定
• 应具备操作权限管理功能：能够设定操作员监控和管理指定通道的权限，能够定义操作员对每个菜单项的使用许可。
• 应具备系统日志管理功能：能够明细记录操作员的操作过程，能够明细记录系统配套设备的运行记录，能够记录第三方系统相关的输入 / 输出事件及数据。
• 应具备系统集成接口模块：能够支持数据库级（如存储过程、触发定义、调度规则等）和应用软件级（如 SDK 、 DLL 等）的系统集成模块。
• 应具备系统数据存储安全机制，支持数据库的手动和自动备份功能，自动备份功能要求可以自定义数据库自动备份规则。
• 应具备系统长期运行的性能保障机制，可有效避免因长期运行产生的大容量数据对系统性能造成影响。
• 应具备系统访问控制和通信安全管理机制，可有效实现数据库的访问控制、应用软件通信连接访问控制、数据通信报文的动态加密机制。
• 应具备数据自动同步功能，能够自动向下同步各种配套设备的运行参数、成员资格等，能够自动向上传配套设备的脱网运行进出记录、原始记录、警报记录等。
• 应具备一定的网络兼容性，能够兼容 LAN 、 WAN 和总线网络；通信方式上支持 Tcp/IP 通信方式和总线通信方式。
• 系统应该采用模块化设计，可扩展性强，能够方便增加本规定中‘可选功能规定’部分的要求。
• 能够和小额支付系统、安防系统、物业管理系统、城市交通信息管理系统联动，能够实现集成系统输入与停车场 / 库系统输出的自定义功能。
• 停车场 / 库管理系统应能进行手动 / 自动两种方式选择。
• 能够对停车场的车位数、收费规则等基本参数进行设置、修改。
3 ． 2 软件的基本功能规定
3 ． 2 ． 1 应具备的通行校验功能
• 能够识别非法卡、黑名单卡、过期卡；
• 能够识别长期卡（期限卡、储蓄卡、免费卡、固定卡）和临时卡；
• 应具有入场车位满位的校效功能；
• 应具有车辆是否重复入场的校验；
• 应具有期限卡过期、储蓄卡帐户余额不足的校验；
• 应具有当前车辆是否具有通行权限的约束校验；
• 应具有出场时车辆无入场记录的校验；
3 ． 2 ． 2 应具备的通行安全管理功能
• 应具有车辆防砸保护功能。
• 应具有人卡和车卡双卡认证功能，有效实现车辆防盗；
• 应具有可以防止前一辆合法车刷卡而后一辆车不刷卡跟入的防跟车处理机制；
• 应具有可以防止车辆在读卡并放行后车辆不正常进入而倒出的防倒车处理机制；
• 应具有视频监控与图文监控功能，可实时视频监控通道状态，可实时图文监控各种车辆进出事件和报警事件，当警报产生时，以多种方式给出提示或报警；
• 应具有图像对比功能，实现自动调取进场抓拍的图片与出场所抓拍的车图进行对比；
3 ． 2 ． 3 应具备的通行策略控制功能
• 能够指定不同操作员管理不同通道；
• 能够控制指定用户类型在指定时间段内对指定通道的通行权限；
• 能够在指定时间范围内控制车辆的通行线路；
• 应具有进出同一通道的通行红绿信号灯控制功能；
• 应具有卡片丢失后的出场车辆放行和收费机制；
• 应具有自定义的车位分配规则功能；
• 应具有车位预留功能；
• 应具有一车多卡的功能，满足家庭成员或公车多卡同车的应用；
• 应具有通道车辆流量检测的功能，有效提高通道车辆通行效率和延长机械寿命；
• 应具备通行告示系统，对认证后不允许通行的情况能够按多种方式给车主以告示；
3 ． 2 ． 4 应具备的报警与告示功能
• 能够提供多种提示或报警方式，包括文字报警、电子显示报警、报警输出和声效报警。
• 能够对非法卡、黑名单卡、过期卡等无效卡产生提示或报警；
• 能够对合法卡的过期或余额不足等产生提示或报警；
• 能够对合法卡的将要过期或余额将要不足等现象给出预提示；
• 能够对在指定时间内在指定通道无权通行的合法卡产生提示或报警；
• 能够对在指定时间内不按规定线路行驶的车辆位产生提示或报警；
• 能够对车位满位的情况产生提示或报警；
• 能够对试图重复进入的情况给出提示或报警；
• 能够对出场时车辆无入场记录的现产产生提示或报警；
• 能够对入口发票机无卡现象产生提示或报警；
• 能够对检测到的火灾、防盗等信号产生提示或报警；
• 能够对检测到的设备网络故障及时产生提示或报警。
• 能够对车辆非法闯入和闯出的现象产生提示或报警。
• 能够对跟车和倒车现象产生提示或报警；
• 能够对火警、防盗警、跟车报警、倒车报警等警报解除后产生提示；
• 能够对车辆驶入通道后给出欢迎词或取卡提示，如取卡提示、刷卡提示等；
• 能够对车辆在车道停留时间过长产生提示或报警。
3 ． 2 ． 5 应具备的车位管理功能
• 能够统计和显示整个停车场余位信息，并具有向周边告示功能；
• 能够统计和显示具体区域的余位信息，并具有向周边告示功能；
• 区域余位的统计和显示在车辆不按车位分配规则泊车时亦能正确统计和公示；
• 能够按用户自定义的规则自动分配泊车位；
应具备脱机运行后的场内余位信息纠正功能；
4 ．停车场管理软件的数据结构
4． 1 数据库的选择
• 应选用具有安全机制的关系型数据库管理系统。
• 所选用的数据库要求具有多种安全性认证模式，支持数据库之角色和用户管理功能，能够方便实现权限许可的验证、授予、修改和收回。
• 所选用的的数据库要求具有表、图表、索引、视图、存储过程、触发器等数据库组件。
• 所选用的数据库应具有数据完整性检查功能，包括实体完整性、域完整性、参考完整性、用户自定义完整性；支持约束（ Default 约束、Ｃ heck 约束、Ｐ riMary Key 约束、 Unique 约束和 Foreign 约束）、缺省和规则定义；
• 所选用的数据库应具有强大的数据备份与恢复功能，支持多种备份／恢复介质、多种备份／恢复类型，并要求应有联机备份 / 恢复功能。
• 所选用的数据库应具有数据控制语言（ DCL ）、数据定义语言（ DDL ）、数据操作语言（ D ＭＬ）。
• 选用的数据库要求具有良好的开放性、可移植和可扩展性，应具有多种数据转换（类型运算、导入导出等）功能和多种数据复制功能。
• 所选用的数据库应具有事务控制功能，可满足事物的自动性、一致性、独立性和持久性要求，能有效应对市电故障和网络故障等原因造成的事物递交和回退。
• 所选用的数据库具有良好的并发控制功能，支持行级锁（记录锁）、页级锁、簇级锁、表级锁和数据库级锁，并能有效避免用户控制的死锁问题和事务引用的会话级和表级死锁问题。
• 所选用的数据库应能够满足 ODBC 接口规范。
4 ． 2 数据结构
4． 21 车主基本资料（用户信息）信息数据结构 包括：
（ 1 ）车主编号；（ 2 ）车主名称；（ 3 ）对应卡号；（ 4 ）用户类型（区别不同的收费方式）；
（ 5 ）用户性质（区别是普通车位，预留车位或固定车位用户）；（ 6 ）身份证号码；
（ 7 ）车身款式；（ 8 ）车牌号码；（ 9 ）车身颜色；（ 10 ）汽车品牌；（ 11 ）联系电话；
（ 12 ）联系地址。
4 ． 22 收费人员信息数据结构 包括：
（ 1 ）收费员编号；（ 2 ）收费员姓名；（ 3 ）年龄；（ 4 ）性别；（ 5 ）工作时间；（ 6 ）联系电话；（ 7 ）联系地址。
4 ． 23 收费记录数据结构 包括：
（ 1 ）收费类型（区分办卡收费或泊车收费）；（ 2 ）证卡类型（区分期限卡、储蓄卡、免费卡、固定卡和临时卡等）；（ 3 ）车主证件编号；（ 4 ）车主姓名；（ 5 ）车主卡号；（ 6 ）入场时间；（ 7 ）出场时间；（ 8 ）泊车计时；（ 9 ）收费金额；（ 10 ）收费日期；（ 11 ）收费操作员；
4 ． 24 车辆进出记录数据结构 包括：
（ 1 ）车主证件编号；（ 2 ）车主姓名；（ 3 ）车主卡号；（ 4 ）进出时间；
（ 5 ）进出抓拍车图；（ 6 ）车主证卡类型；（ 7 ）进出状态；（ 8 ）进出通道；
（ 9 ）汽车车型；（ 10 ）车牌号码；（ 11 ）车身颜色；（ 12 ）汽车品牌；
（ 13 ）车主联系电话；（ 14 ）车主联系地址；（ 15 ）所泊车位；
4 ． 25 原始监控事件记录数据结构 包括：
（ 1 ）事件记录类型；（区分进出记录、通道地磁输入记录等）；（ 2 ）事件记录对应控制器；（ 3 ）事件记录对应通道；（ 4 ）事件记录卡号；（ 5 ）事件记录从设备号；（ 6 ）事件记录进出状态；（ 7 ）事件记录输入输出点号；（ 8 ）事件记录时间；
4 ． 26 手动控闸记录数据结构 包括：
（ 1 ）手动控闸时间；
（ 2 ）手动控闸者；
（ 3 ）手动控闸通道；
（ 4 ）手动控闸类型（区分普通开闸、关闸、紧急开闸、紧包关闸等）；
4 ． 27 警报记录数据结构 包括：
（ 1 ）系统警报发生源；
（ 2 ）系统警报类型；
（ 3 ）系统警报描术；
（ 4 ）系统警报发生时间；
4 ． 28 操作日志记录数据结构 包括：
（ 1 ）操作员编号；（ 2 ）操作员姓名；（ 3 ）操作类型；（ 4 ）操作时间；（ 5 ）操作对象；
（ 6 ）操作内容；（ 7 ）操作结果；
4 ． 3 数据接口标准
由于本标准规定所选用的数据库要求能够满足 ODBC 接口规范，所以数据接口标准将基于开放式数据链路来实现。
4 ． 31 数据接口标准涉及的数据结构
• 车主基本资料数据接口标准；
• 收费人员数据接口标准；
• 收费记录数据接口标准；
• 进出记录数据接口标准；
• 原始监控记录数据接口标准；
• 手动控闸记录数据接口标准；
• 警报记录数据接口标准；
系统日志记录数据接口标准；
4 ． 32 数据接口标准实现过程：
• 定义数据源及驱动：
• 数据源选择：数据源可以是所有满足 ODBC 接口规范的数据对象，如：文本文件 (*.txt;*.Csv) 、 Excel(*.xls) 、 Access(*.mdb) 、 Dbase(*.dbf) 、 Paradox(*.db) 、 InterBase(*.gdb) 、 SqlServer 、 Sybase 、 Oracle 等等；
• 数据源驱动定义：根据不同的数据源类别，选择相应的数据源驱动，再根据数据源驱动提供的标准参数配置数据源的连接、列标题、列分隔符、字符集、数据类型、字段宽度等等，不同的数据源类别按区别配置不同的驱动定义。
• 连接数据源：根据 ODBC 标准，按照数据源名称的定义连接所配置的数据源，然后选择需要进行数据交互的数据表格。
• 字段对应：连接数据源后，进行数据源字段到数据目标字段的对应。需要能够支持的数据结构有：
一、车主基本资料数据结构：
（ 1 ）车主编号；（ 2 ）车主名称；（ 3 ）对应卡号；（ 4 ）用户类型（区别不同的收费方式）；
（ 5 ）用户性质（区别是普通车位，预留车位或固定车位用户）；（ 6 ）身份证号码；
（ 7 ）车身款式；（ 8 ）车牌号码；（ 9 ）车身颜色；（ 10 ）汽车品牌；（ 11 ）联系电话；
（ 12 ）联系地址。
二、收费人员数据结构：
（ 1 ）收费员编号；（ 2 ）收费员姓名；（ 3 ）年龄；（ 4 ）性别；（ 5 ）工作时间；（ 6 ）联系电话；（ 7 ）联系地址。
三、收费记录数据结构：
（ 1 ）收费类型（区分办卡收费或泊车收费）；（ 2 ）证卡类型（区分期限卡、储蓄卡、免费卡、固定卡和临时卡等）；（ 3 ）车主证件编号；（ 4 ）车主姓名；（ 5 ）车主卡号；（ 6 ）入场时间；（ 7 ）出场时间；（ 8 ）泊车计时；（ 9 ）收费金额；（ 10 ）收费日期；（ 11 ）收费操作员；
四、进出记录数据结构：
（ 1 ）车主证件编号；（ 2 ）车主姓名；（ 3 ）车主卡号；（ 4 ）进出时间；（ 5 ）进出抓拍车图；（ 6 ）车主证卡类型；（ 7 ）进出状态；（ 8 ）进出通道；（ 9 ）汽车车型；（ 10 ）车牌号码；（ 11 ）车身颜色；（ 12 ）汽车品牌；（ 13 ）车主联系电话；（ 14 ）车主联系地址；（ 15 ）所泊车位；
五、原始监控记录数据结构：
（ 1 ）事件记录类型；（区分进出记录、通道地磁输入记录等）；（ 2 ）事件记录对应控制器；（ 3 ）事件记录对应通道；（ 4 ）事件记录卡号；（ 5 ）事件记录从设备号；（ 6 ）事件记录进出状态；（ 7 ）事件记录输入输出点号；（ 8 ）事件记录时间；
六、手动控闸记录数据结构：
（ 1 ）手动控闸时间；（ 2 ）手动控闸者；（ 3 ）手动控闸通道；
（ 4 ）手动控闸类型（区分普通开闸、关闸、紧急开闸、紧包关闸等）；
七、警报记录数据结构：
（ 1 ）系统警报发生源；（ 2 ）系统警报类型；（ 3 ）系统警报描术；（ 4 ）系统警报发生时间；
八、系统日志记录数据结构：
（ 1 ）操作员编号；（ 2 ）操作员姓名；（ 3 ）操作类型；（ 4 ）操作时间；（ 5 ）操作对象；
（ 6 ）操作内容；（ 7 ）操作结果；
• 接口数据实现：
• 键字段要求有数据唯一性校验；
• 所有字段要有数据合法性校验；
• 数据源对象要有字段完整性校验；
• 代码数据或类型不匹配数据要进行逻辑转换；
图片数据采用图片文件名形多交互；
5 ．停车场管理的开放性（略）
5 ． 1 对外信息的交互协议
5 ． 1 ． 1 以采用 GPRS 方式进行数据传输。
5 ． 1 ． 2 应采用 TCP 方式进行网络链路连接。
5 ． 1 ． 3 应对数据的发送和接受提供 ACK 回复确认。
5 ． 1 ． 4 设备主动发送传输的协议内容应包括设备识别码，指今命令字，设置正常运行期间的流水递增的消息编码和发送的信息内容。
5 ． 1 ． 5 系统主动发送的协议内容必须包括设备的识别码，指令命命令字，系统合局的流水递增的消息编码和发送的信息内容。
5 ． 1 ． 6 设备对于系统发来的信息的回复的协议内容应包括设备识别码，指令的命令字，由系统发来的消息编号和回复的内容。
5 ． 1 ． 7 系统对于终端设备发来的信息的回复的协议内容必须包括设备识别码，指令命令字，出设备发送来的消息编号和回复的内容。
5 ． 1 ． 8 设备补充发送的数据要求具有时间戳信息。
5 ． 2 对外信息的交互数据结构
5 ． 2 ． 1 符合 TCP/IP 协议
5 ． 2 ． 2 数据结构开放：便于二次开发，便于与其它软件数据的共巷。
5 ． 3 其它规定
5 ． 3 ． 1 可以与各种现场线兼容，如 CAN 线， 485 总线等。
5 ． 3 ． 2 能与 Internet 联网，实现数据共享。
5 ． 3 ． 3 应支持无线通讯，配有 GPRS 数据传输模块。
5 ． 3 ． 4 应能与交通信息系统，安防系统，智能建筑等系统兼容。
6．停车场管理软件的测评
6 ． 1 软件测试：
软件测试应采用黑盒测试方法，通过测试来检查是否每个功能都能正常使用，它可完全不考虑程序内部结构和处理过程，在程序的接口进行测试，它只检查程序功能是否能按照要求正常使用，程序是否能适当地接收输入数据并产生正常的输出信息。软件测评的主要依据是随应用软件一起发行的软件说明书。
6 ． 11 单元测试
在遵循模块化设计思想的软件中，每个模块完成一个清晰定义的子功能。而且这个子功能和同级其它模块的功能之前相互依赖度很小，因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易检验模块的正确性，单元测试的目的是保证每个模块作为一个单元是能正确运行的，单元测试任务包括：
（ 1 ）模块接口测试：是否能在正确输入的条件下产生与预期一样的的输出，是否能屏蔽不正确的输入或在不正确输入的条件下能够捕捉并处理这些不正确的输入。
（ 2 ）模块边界条件测试：长期的软件测试研究表明，大量错误往往发生在输入或输出的边界上，因此针对各种边界情况设计测试用例，可以查出更多的错误。
（ 3 ）执行通路测试：它对模块中对每一条独立执行的路径进行测试，以发现所有可能的，潜在的执行逻辑性错误。
（ 4 ）出错处理测式：一个好的设计应能预见各种出错条件，并预设各种出错处理通路，校验模块中是否存在无法处理的错误出口。
6 ． 12 集成测试
集成测试又称构件测试它是把经过单元测试的模块放在一起形成一个构件系统来进行测试，模块相互间的协调和通信是这个测试过程的主要问题，因此这个步骤着重测试模块间的交互，应采用如下的测试思想：
（ 1）自顶向下集成：自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起，其工作步骤为：
• 以主控模块作驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；
• 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；
• 每集成一个模块立即测试一遍；
• 只有每组测试完成后，才着手替换下一个桩模块；
• 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）；
• 从第 2 步开始，循环执行上述步骤，直至整个程序结构构造完毕。
（ 2）自底向上集成：自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块，其工作步骤为：
• 把低层模块组织成实现某个子功能的模块群；
• 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；
• 对每个模块群进行测试；
• 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群；
• 从第一步开始循环执行上述各步骤，直至整个程序构造完毕。
6 ． 13 系统测试
系统测试是把经过测试的构件装配成一个完整的系统来测试。在这个过程中不仅应发现设计和编码的错误，还应验证系统确实能提供设计时指定的功能，而且系统的动态特性也符合要求。在这个测试中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。
系统测试的基本方法有：
• 恢复测试：恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。
• 安全测试：安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员应采用各种办法试图突破防线。例如，试图截取或破译口令、专门定做软件破坏系统的保护机制、故意导致系统失败，企图趁恢复之机非法进入等等。
• 强度测试：强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。
• 性能测试：测试系统对大容量数据的处理能力、对长期运行后的运行性能保障能力以及各种性能测试是否能够符合软件说明书的要求。
6 ． 14 验收测试
验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但它是在用户（或验收组）积极参与下进行的，而且可能主要使用实际数据（系统将来要处理的数据）进行测试，验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的常常是系统需求说明中的错误。验收测试包括两个方面：
• 测试应用软件符合软件说明书的内容；
• 测试应用软件能够满足软件购销合同中用户特别指定的个性化功能；
6 ． 2 测试用例
边界值测试用例：
• 如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据；
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多 1 格、比最小个数少 1 个的数做为测试数据；
• 根据每一个输出条件，验证在边界输入条件下是否可以正确的输出
• 如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例；
• 如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例。
• 如果输入条件规定了值的范围，验证是否允许非法的输入，合法的输入是否违反逻辑输入。（如：输入条件为开始和结束时间，首先必须测试合法性输入，然后再验证结束时间大于开始时间这种违反逻辑的情况下得出的输出结果。
环境测试用例
• 电源掉电的测试，包括软件在待机时的掉电和软件在处理数据时的掉电。
• 强行结束软件任务的测试。
• 操作系统 CPU 和内存资源耗尽的测试，多开一些需要大资源的其它程序，使要测试的软件处理非常‘饥饿’的状态下，测试其性能和数据处理的正确性。
• 如果系统包含网线通讯线路，物理通讯线路突然中断的测试。
• 对于处理任务较重的部分，如果条件允许，可以考虑用性能很差的计算机去测试，这时候可能会暴露出很多问题。
特殊操作测试用例
某些特殊的操作可以发现程序中潜在的问题，如：
• 软件没有正常退出就关闭操作系统；
• 不正常关闭应用软件人机交互窗口；
• 软件正在执行一项较耗时命令时退出应用软件；
• 以复制 / 粘贴的方式代替键盘输入数据；等等。
6．3 软件评价：
6． 31 软件功能评阶：
• 应用软件功能符合设计说明的规定；
• 能够较好的满足停车场 / 库管理需求的扩充（可选部分规定的内容）；
• 系统完整性：因具有完整的系统设计相关文档资料、具有完整的系统二次开发集成接口、具有完整的数据输入与输出接口、具有完整的系统集成方案、具有完整的通道进出管理系统，车位引导管理系统，报警处理系统、取车系统、节能照明控制系统等停车场管理的可选子系统。
• 应具有足够的容错性，能有效捕捉各种网络异常、操作异常的能力；
• 具有良好的数据自动同步机制，能够主动上传脱网运行后产生的记录，能够自动向停车场管理软件配套设备同步在停件中的参数设置；
• 具有良好的车辆通行校验机制；
• 具有良好的车辆通行安全管理机制；
• 具有良好的车辆通行策略控制机制；
• 具备车位管理与车位显示系统；
• 能够正确并完整的记录车辆进出记录、收费记录、操作员操作日志、集成系统输入输出数据、警报记录等；
• 具备良好的收费制度设置功能，能够由用户自定义收费规则；
• 具有完善的的报表等数据输出系统；
• 软件模块化清晰、软件设计具有友好性；
6 ． 32 软件性能评阶：
• 应具有大容量数据处理的能力，具有系统长期运行效率保证机制；
• 应具有足够的容错性，能有效捕捉各种网络异常、操作异常的能力；
• 应具有与其它应用软件的使用环境兼容性；
• 具有良好的数据存储安全机制；
• 具有良好的系统安全与访问控制机制、具有良好的数据报文通信高效处理机制；
• 系统因具有良好的可扩充性，满足管理需求的调整和变更；
• 系统因具有良好的可移植性，包括数据库的移植和应用软件的移植；
6 ． 33 软件商品化程度评阶：
• 应具有完整的系统设计文档、通信协议文档、数据库设计文档、软件集成说明文档、软件说明书等文档资料；
• 应具有很好的运行稳定性；
• 应具有良好的集成开发方便性；
• 应具有良好的软件操作方便性；
• 应具有良好的可维护性；
• 应具有良好的安装方便性；
• 应具有良好的系统升级和功能扩充机制；
6 ． 34 软件技术先进性：
• 构模型先进性；
• 通道进出管理逻辑先进性；
• 车位管理逻辑先进行；
• 通信机制先进性；
• 数据存储安全机制先进性；
• 系统安全与访问控制先进性；
• 技术指标先进性；
• 报文通信的严密性（加密机制、数据报文错包处理机制、数据通信校验机制）；
6 ． 35 软件应用评价：
• 具有较好的停车场 / 库管理适用性；
• 用户需求变更、扩充的配置灵活性；
• 具有良好的网络兼容性，能够支持 LAN 、 WAN 和总线网络；
• 具有良好的风险控制，能够避免局部故障影响整个系统的正常运行；
• 具有良好的软件操作权限管理机制；
• 具有良好的通行权限管理；
• 应具有良好的系统升级和功能扩充机制；
• 具有完善的的报表输出；
作者：杭州立方自动化工程有限公司 施广明
2 ．停车场管理系统术语（部分）
下列术语和定义适用于本标准（分配章节相关部分）
停车场 / 库：专指供车辆泊车使用的具有固定车辆进出通道的非立体机械式封闭场所；
停车场 / 库管理系统：具有管理和控制停车场配套设备功能的应用于停车场 / 库管理的应用软件。
长期卡：在许可条件下可在停车场 / 库长期流通的卡片，它由停车场 / 库管理者预先发放给车主 , 出场时不回收卡片。
临时卡：每次泊车临时收费泊车费用的卡片，卡片在入场时临时发放，出场时临时回收。
期限卡：在一段指定有效期内收取指定泊车费用的卡片，如：年卡、月卡等，它属于长期卡的范畴。
储蓄卡：卡片对应一个储蓄帐户，通过预先向帐户充值，泊车过程自动从帐户扣除泊车费用，它属于长期卡的范畴。
免费卡：不收费泊车费用的卡片，它属于长期卡的范畴。
固定卡：一次性收费泊车费用的卡片，它属于长期卡的范畴。
非法卡：在停车场 / 库管理系统中没有登记过的卡片。
黑名单卡：已经挂失的卡片。
防跟车：一种防止前一辆合法车刷卡而后一辆车不刷卡跟入的处理机制。
防倒车：一种防止车辆在刷卡并放行后车辆不正常进入而倒出的处理机制。
双卡认证：一种车主卡和车载卡同时认证有效方能通行的车辆防盗处理机制。
一车多卡：允许一车对应多张合法卡，但同一时刻只能允许一张卡泊车。
车流量检测：一种可以有效提高通道车辆通行效率和延长机械寿命的处理机制，当多卡刷卡后，待所有合法车辆通过通道后，方可关闭道闸。
3 ．停车场管理软件的基本规定
3 ． 1 停车场管理软件总体规定
• 应具备操作权限管理功能：能够设定操作员监控和管理指定通道的权限，能够定义操作员对每个菜单项的使用许可。
• 应具备系统日志管理功能：能够明细记录操作员的操作过程，能够明细记录系统配套设备的运行记录，能够记录第三方系统相关的输入 / 输出事件及数据。
• 应具备系统集成接口模块：能够支持数据库级（如存储过程、触发定义、调度规则等）和应用软件级（如 SDK 、 DLL 等）的系统集成模块。
• 应具备系统数据存储安全机制，支持数据库的手动和自动备份功能，自动备份功能要求可以自定义数据库自动备份规则。
• 应具备系统长期运行的性能保障机制，可有效避免因长期运行产生的大容量数据对系统性能造成影响。
• 应具备系统访问控制和通信安全管理机制，可有效实现数据库的访问控制、应用软件通信连接访问控制、数据通信报文的动态加密机制。
• 应具备数据自动同步功能，能够自动向下同步各种配套设备的运行参数、成员资格等，能够自动向上传配套设备的脱网运行进出记录、原始记录、警报记录等。
• 应具备一定的网络兼容性，能够兼容 LAN 、 WAN 和总线网络；通信方式上支持 Tcp/IP 通信方式和总线通信方式。
• 系统应该采用模块化设计，可扩展性强，能够方便增加本规定中‘可选功能规定’部分的要求。
• 能够和小额支付系统、安防系统、物业管理系统、城市交通信息管理系统联动，能够实现集成系统输入与停车场 / 库系统输出的自定义功能。
• 停车场 / 库管理系统应能进行手动 / 自动两种方式选择。
• 能够对停车场的车位数、收费规则等基本参数进行设置、修改。
3 ． 2 软件的基本功能规定
3 ． 2 ． 1 应具备的通行校验功能
• 能够识别非法卡、黑名单卡、过期卡；
• 能够识别长期卡（期限卡、储蓄卡、免费卡、固定卡）和临时卡；
• 应具有入场车位满位的校效功能；
• 应具有车辆是否重复入场的校验；
• 应具有期限卡过期、储蓄卡帐户余额不足的校验；
• 应具有当前车辆是否具有通行权限的约束校验；
• 应具有出场时车辆无入场记录的校验；
3 ． 2 ． 2 应具备的通行安全管理功能
• 应具有车辆防砸保护功能。
• 应具有人卡和车卡双卡认证功能，有效实现车辆防盗；
• 应具有可以防止前一辆合法车刷卡而后一辆车不刷卡跟入的防跟车处理机制；
• 应具有可以防止车辆在读卡并放行后车辆不正常进入而倒出的防倒车处理机制；
• 应具有视频监控与图文监控功能，可实时视频监控通道状态，可实时图文监控各种车辆进出事件和报警事件，当警报产生时，以多种方式给出提示或报警；
• 应具有图像对比功能，实现自动调取进场抓拍的图片与出场所抓拍的车图进行对比；
3 ． 2 ． 3 应具备的通行策略控制功能
• 能够指定不同操作员管理不同通道；
• 能够控制指定用户类型在指定时间段内对指定通道的通行权限；
• 能够在指定时间范围内控制车辆的通行线路；
• 应具有进出同一通道的通行红绿信号灯控制功能；
• 应具有卡片丢失后的出场车辆放行和收费机制；
• 应具有自定义的车位分配规则功能；
• 应具有车位预留功能；
• 应具有一车多卡的功能，满足家庭成员或公车多卡同车的应用；
• 应具有通道车辆流量检测的功能，有效提高通道车辆通行效率和延长机械寿命；
• 应具备通行告示系统，对认证后不允许通行的情况能够按多种方式给车主以告示；
3 ． 2 ． 4 应具备的报警与告示功能
• 能够提供多种提示或报警方式，包括文字报警、电子显示报警、报警输出和声效报警。
• 能够对非法卡、黑名单卡、过期卡等无效卡产生提示或报警；
• 能够对合法卡的过期或余额不足等产生提示或报警；
• 能够对合法卡的将要过期或余额将要不足等现象给出预提示；
• 能够对在指定时间内在指定通道无权通行的合法卡产生提示或报警；
• 能够对在指定时间内不按规定线路行驶的车辆位产生提示或报警；
• 能够对车位满位的情况产生提示或报警；
• 能够对试图重复进入的情况给出提示或报警；
• 能够对出场时车辆无入场记录的现产产生提示或报警；
• 能够对入口发票机无卡现象产生提示或报警；
• 能够对检测到的火灾、防盗等信号产生提示或报警；
• 能够对检测到的设备网络故障及时产生提示或报警。
• 能够对车辆非法闯入和闯出的现象产生提示或报警。
• 能够对跟车和倒车现象产生提示或报警；
• 能够对火警、防盗警、跟车报警、倒车报警等警报解除后产生提示；
• 能够对车辆驶入通道后给出欢迎词或取卡提示，如取卡提示、刷卡提示等；
• 能够对车辆在车道停留时间过长产生提示或报警。
3 ． 2 ． 5 应具备的车位管理功能
• 能够统计和显示整个停车场余位信息，并具有向周边告示功能；
• 能够统计和显示具体区域的余位信息，并具有向周边告示功能；
• 区域余位的统计和显示在车辆不按车位分配规则泊车时亦能正确统计和公示；
• 能够按用户自定义的规则自动分配泊车位；
应具备脱机运行后的场内余位信息纠正功能；
4 ．停车场管理软件的数据结构
4． 1 数据库的选择
• 应选用具有安全机制的关系型数据库管理系统。
• 所选用的数据库要求具有多种安全性认证模式，支持数据库之角色和用户管理功能，能够方便实现权限许可的验证、授予、修改和收回。
• 所选用的的数据库要求具有表、图表、索引、视图、存储过程、触发器等数据库组件。
• 所选用的数据库应具有数据完整性检查功能，包括实体完整性、域完整性、参考完整性、用户自定义完整性；支持约束（ Default 约束、Ｃ heck 约束、Ｐ riMary Key 约束、 Unique 约束和 Foreign 约束）、缺省和规则定义；
• 所选用的数据库应具有强大的数据备份与恢复功能，支持多种备份／恢复介质、多种备份／恢复类型，并要求应有联机备份 / 恢复功能。
• 所选用的数据库应具有数据控制语言（ DCL ）、数据定义语言（ DDL ）、数据操作语言（ D ＭＬ）。
• 选用的数据库要求具有良好的开放性、可移植和可扩展性，应具有多种数据转换（类型运算、导入导出等）功能和多种数据复制功能。
• 所选用的数据库应具有事务控制功能，可满足事物的自动性、一致性、独立性和持久性要求，能有效应对市电故障和网络故障等原因造成的事物递交和回退。
• 所选用的数据库具有良好的并发控制功能，支持行级锁（记录锁）、页级锁、簇级锁、表级锁和数据库级锁，并能有效避免用户控制的死锁问题和事务引用的会话级和表级死锁问题。
• 所选用的数据库应能够满足 ODBC 接口规范。
4 ． 2 数据结构
4． 21 车主基本资料（用户信息）信息数据结构 包括：
（ 1 ）车主编号；（ 2 ）车主名称；（ 3 ）对应卡号；（ 4 ）用户类型（区别不同的收费方式）；
（ 5 ）用户性质（区别是普通车位，预留车位或固定车位用户）；（ 6 ）身份证号码；
（ 7 ）车身款式；（ 8 ）车牌号码；（ 9 ）车身颜色；（ 10 ）汽车品牌；（ 11 ）联系电话；
（ 12 ）联系地址。
4 ． 22 收费人员信息数据结构 包括：
（ 1 ）收费员编号；（ 2 ）收费员姓名；（ 3 ）年龄；（ 4 ）性别；（ 5 ）工作时间；（ 6 ）联系电话；（ 7 ）联系地址。
4 ． 23 收费记录数据结构 包括：
（ 1 ）收费类型（区分办卡收费或泊车收费）；（ 2 ）证卡类型（区分期限卡、储蓄卡、免费卡、固定卡和临时卡等）；（ 3 ）车主证件编号；（ 4 ）车主姓名；（ 5 ）车主卡号；（ 6 ）入场时间；（ 7 ）出场时间；（ 8 ）泊车计时；（ 9 ）收费金额；（ 10 ）收费日期；（ 11 ）收费操作员；
4 ． 24 车辆进出记录数据结构 包括：
（ 1 ）车主证件编号；（ 2 ）车主姓名；（ 3 ）车主卡号；（ 4 ）进出时间；
（ 5 ）进出抓拍车图；（ 6 ）车主证卡类型；（ 7 ）进出状态；（ 8 ）进出通道；
（ 9 ）汽车车型；（ 10 ）车牌号码；（ 11 ）车身颜色；（ 12 ）汽车品牌；
（ 13 ）车主联系电话；（ 14 ）车主联系地址；（ 15 ）所泊车位；
4 ． 25 原始监控事件记录数据结构 包括：
（ 1 ）事件记录类型；（区分进出记录、通道地磁输入记录等）；（ 2 ）事件记录对应控制器；（ 3 ）事件记录对应通道；（ 4 ）事件记录卡号；（ 5 ）事件记录从设备号；（ 6 ）事件记录进出状态；（ 7 ）事件记录输入输出点号；（ 8 ）事件记录时间；
4 ． 26 手动控闸记录数据结构 包括：
（ 1 ）手动控闸时间；
（ 2 ）手动控闸者；
（ 3 ）手动控闸通道；
（ 4 ）手动控闸类型（区分普通开闸、关闸、紧急开闸、紧包关闸等）；
4 ． 27 警报记录数据结构 包括：
（ 1 ）系统警报发生源；
（ 2 ）系统警报类型；
（ 3 ）系统警报描术；
（ 4 ）系统警报发生时间；
4 ． 28 操作日志记录数据结构 包括：
（ 1 ）操作员编号；（ 2 ）操作员姓名；（ 3 ）操作类型；（ 4 ）操作时间；（ 5 ）操作对象；
（ 6 ）操作内容；（ 7 ）操作结果；
4 ． 3 数据接口标准
由于本标准规定所选用的数据库要求能够满足 ODBC 接口规范，所以数据接口标准将基于开放式数据链路来实现。
4 ． 31 数据接口标准涉及的数据结构
• 车主基本资料数据接口标准；
• 收费人员数据接口标准；
• 收费记录数据接口标准；
• 进出记录数据接口标准；
• 原始监控记录数据接口标准；
• 手动控闸记录数据接口标准；
• 警报记录数据接口标准；
系统日志记录数据接口标准；
4 ． 32 数据接口标准实现过程：
• 定义数据源及驱动：
• 数据源选择：数据源可以是所有满足 ODBC 接口规范的数据对象，如：文本文件 (*.txt;*.Csv) 、 Excel(*.xls) 、 Access(*.mdb) 、 Dbase(*.dbf) 、 Paradox(*.db) 、 InterBase(*.gdb) 、 SqlServer 、 Sybase 、 Oracle 等等；
• 数据源驱动定义：根据不同的数据源类别，选择相应的数据源驱动，再根据数据源驱动提供的标准参数配置数据源的连接、列标题、列分隔符、字符集、数据类型、字段宽度等等，不同的数据源类别按区别配置不同的驱动定义。
• 连接数据源：根据 ODBC 标准，按照数据源名称的定义连接所配置的数据源，然后选择需要进行数据交互的数据表格。
• 字段对应：连接数据源后，进行数据源字段到数据目标字段的对应。需要能够支持的数据结构有：
一、车主基本资料数据结构：
（ 1 ）车主编号；（ 2 ）车主名称；（ 3 ）对应卡号；（ 4 ）用户类型（区别不同的收费方式）；
（ 5 ）用户性质（区别是普通车位，预留车位或固定车位用户）；（ 6 ）身份证号码；
（ 7 ）车身款式；（ 8 ）车牌号码；（ 9 ）车身颜色；（ 10 ）汽车品牌；（ 11 ）联系电话；
（ 12 ）联系地址。
二、收费人员数据结构：
（ 1 ）收费员编号；（ 2 ）收费员姓名；（ 3 ）年龄；（ 4 ）性别；（ 5 ）工作时间；（ 6 ）联系电话；（ 7 ）联系地址。
三、收费记录数据结构：
（ 1 ）收费类型（区分办卡收费或泊车收费）；（ 2 ）证卡类型（区分期限卡、储蓄卡、免费卡、固定卡和临时卡等）；（ 3 ）车主证件编号；（ 4 ）车主姓名；（ 5 ）车主卡号；（ 6 ）入场时间；（ 7 ）出场时间；（ 8 ）泊车计时；（ 9 ）收费金额；（ 10 ）收费日期；（ 11 ）收费操作员；
四、进出记录数据结构：
（ 1 ）车主证件编号；（ 2 ）车主姓名；（ 3 ）车主卡号；（ 4 ）进出时间；（ 5 ）进出抓拍车图；（ 6 ）车主证卡类型；（ 7 ）进出状态；（ 8 ）进出通道；（ 9 ）汽车车型；（ 10 ）车牌号码；（ 11 ）车身颜色；（ 12 ）汽车品牌；（ 13 ）车主联系电话；（ 14 ）车主联系地址；（ 15 ）所泊车位；
五、原始监控记录数据结构：
（ 1 ）事件记录类型；（区分进出记录、通道地磁输入记录等）；（ 2 ）事件记录对应控制器；（ 3 ）事件记录对应通道；（ 4 ）事件记录卡号；（ 5 ）事件记录从设备号；（ 6 ）事件记录进出状态；（ 7 ）事件记录输入输出点号；（ 8 ）事件记录时间；
六、手动控闸记录数据结构：
（ 1 ）手动控闸时间；（ 2 ）手动控闸者；（ 3 ）手动控闸通道；
（ 4 ）手动控闸类型（区分普通开闸、关闸、紧急开闸、紧包关闸等）；
七、警报记录数据结构：
（ 1 ）系统警报发生源；（ 2 ）系统警报类型；（ 3 ）系统警报描术；（ 4 ）系统警报发生时间；
八、系统日志记录数据结构：
（ 1 ）操作员编号；（ 2 ）操作员姓名；（ 3 ）操作类型；（ 4 ）操作时间；（ 5 ）操作对象；
（ 6 ）操作内容；（ 7 ）操作结果；
• 接口数据实现：
• 键字段要求有数据唯一性校验；
• 所有字段要有数据合法性校验；
• 数据源对象要有字段完整性校验；
• 代码数据或类型不匹配数据要进行逻辑转换；
图片数据采用图片文件名形多交互；
5 ．停车场管理的开放性（略）
5 ． 1 对外信息的交互协议
5 ． 1 ． 1 以采用 GPRS 方式进行数据传输。
5 ． 1 ． 2 应采用 TCP 方式进行网络链路连接。
5 ． 1 ． 3 应对数据的发送和接受提供 ACK 回复确认。
5 ． 1 ． 4 设备主动发送传输的协议内容应包括设备识别码，指今命令字，设置正常运行期间的流水递增的消息编码和发送的信息内容。
5 ． 1 ． 5 系统主动发送的协议内容必须包括设备的识别码，指令命命令字，系统合局的流水递增的消息编码和发送的信息内容。
5 ． 1 ． 6 设备对于系统发来的信息的回复的协议内容应包括设备识别码，指令的命令字，由系统发来的消息编号和回复的内容。
5 ． 1 ． 7 系统对于终端设备发来的信息的回复的协议内容必须包括设备识别码，指令命令字，出设备发送来的消息编号和回复的内容。
5 ． 1 ． 8 设备补充发送的数据要求具有时间戳信息。
5 ． 2 对外信息的交互数据结构
5 ． 2 ． 1 符合 TCP/IP 协议
5 ． 2 ． 2 数据结构开放：便于二次开发，便于与其它软件数据的共巷。
5 ． 3 其它规定
5 ． 3 ． 1 可以与各种现场线兼容，如 CAN 线， 485 总线等。
5 ． 3 ． 2 能与 Internet 联网，实现数据共享。
5 ． 3 ． 3 应支持无线通讯，配有 GPRS 数据传输模块。
5 ． 3 ． 4 应能与交通信息系统，安防系统，智能建筑等系统兼容。
6．停车场管理软件的测评
6 ． 1 软件测试：
软件测试应采用黑盒测试方法，通过测试来检查是否每个功能都能正常使用，它可完全不考虑程序内部结构和处理过程，在程序的接口进行测试，它只检查程序功能是否能按照要求正常使用，程序是否能适当地接收输入数据并产生正常的输出信息。软件测评的主要依据是随应用软件一起发行的软件说明书。
6 ． 11 单元测试
在遵循模块化设计思想的软件中，每个模块完成一个清晰定义的子功能。而且这个子功能和同级其它模块的功能之前相互依赖度很小，因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易检验模块的正确性，单元测试的目的是保证每个模块作为一个单元是能正确运行的，单元测试任务包括：
（ 1 ）模块接口测试：是否能在正确输入的条件下产生与预期一样的的输出，是否能屏蔽不正确的输入或在不正确输入的条件下能够捕捉并处理这些不正确的输入。
（ 2 ）模块边界条件测试：长期的软件测试研究表明，大量错误往往发生在输入或输出的边界上，因此针对各种边界情况设计测试用例，可以查出更多的错误。
（ 3 ）执行通路测试：它对模块中对每一条独立执行的路径进行测试，以发现所有可能的，潜在的执行逻辑性错误。
（ 4 ）出错处理测式：一个好的设计应能预见各种出错条件，并预设各种出错处理通路，校验模块中是否存在无法处理的错误出口。
6 ． 12 集成测试
集成测试又称构件测试它是把经过单元测试的模块放在一起形成一个构件系统来进行测试，模块相互间的协调和通信是这个测试过程的主要问题，因此这个步骤着重测试模块间的交互，应采用如下的测试思想：
（ 1）自顶向下集成：自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起，其工作步骤为：
• 以主控模块作驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；
• 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；
• 每集成一个模块立即测试一遍；
• 只有每组测试完成后，才着手替换下一个桩模块；
• 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）；
• 从第 2 步开始，循环执行上述步骤，直至整个程序结构构造完毕。
（ 2）自底向上集成：自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块，其工作步骤为：
• 把低层模块组织成实现某个子功能的模块群；
• 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；
• 对每个模块群进行测试；
• 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群；
• 从第一步开始循环执行上述各步骤，直至整个程序构造完毕。
6 ． 13 系统测试
系统测试是把经过测试的构件装配成一个完整的系统来测试。在这个过程中不仅应发现设计和编码的错误，还应验证系统确实能提供设计时指定的功能，而且系统的动态特性也符合要求。在这个测试中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。
系统测试的基本方法有：
• 恢复测试：恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。
• 安全测试：安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员应采用各种办法试图突破防线。例如，试图截取或破译口令、专门定做软件破坏系统的保护机制、故意导致系统失败，企图趁恢复之机非法进入等等。
• 强度测试：强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。
• 性能测试：测试系统对大容量数据的处理能力、对长期运行后的运行性能保障能力以及各种性能测试是否能够符合软件说明书的要求。
6 ． 14 验收测试
验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但它是在用户（或验收组）积极参与下进行的，而且可能主要使用实际数据（系统将来要处理的数据）进行测试，验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的常常是系统需求说明中的错误。验收测试包括两个方面：
• 测试应用软件符合软件说明书的内容；
• 测试应用软件能够满足软件购销合同中用户特别指定的个性化功能；
6 ． 2 测试用例
边界值测试用例：
• 如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据；
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多 1 格、比最小个数少 1 个的数做为测试数据；
• 根据每一个输出条件，验证在边界输入条件下是否可以正确的输出
• 如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例；
• 如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例。
• 如果输入条件规定了值的范围，验证是否允许非法的输入，合法的输入是否违反逻辑输入。（如：输入条件为开始和结束时间，首先必须测试合法性输入，然后再验证结束时间大于开始时间这种违反逻辑的情况下得出的输出结果。
环境测试用例
• 电源掉电的测试，包括软件在待机时的掉电和软件在处理数据时的掉电。
• 强行结束软件任务的测试。
• 操作系统 CPU 和内存资源耗尽的测试，多开一些需要大资源的其它程序，使要测试的软件处理非常‘饥饿’的状态下，测试其性能和数据处理的正确性。
• 如果系统包含网线通讯线路，物理通讯线路突然中断的测试。
• 对于处理任务较重的部分，如果条件允许，可以考虑用性能很差的计算机去测试，这时候可能会暴露出很多问题。
特殊操作测试用例
某些特殊的操作可以发现程序中潜在的问题，如：
• 软件没有正常退出就关闭操作系统；
• 不正常关闭应用软件人机交互窗口；
• 软件正在执行一项较耗时命令时退出应用软件；
• 以复制 / 粘贴的方式代替键盘输入数据；等等。
6．3 软件评价：
6． 31 软件功能评阶：
• 应用软件功能符合设计说明的规定；
• 能够较好的满足停车场 / 库管理需求的扩充（可选部分规定的内容）；
• 系统完整性：因具有完整的系统设计相关文档资料、具有完整的系统二次开发集成接口、具有完整的数据输入与输出接口、具有完整的系统集成方案、具有完整的通道进出管理系统，车位引导管理系统，报警处理系统、取车系统、节能照明控制系统等停车场管理的可选子系统。
• 应具有足够的容错性，能有效捕捉各种网络异常、操作异常的能力；
• 具有良好的数据自动同步机制，能够主动上传脱网运行后产生的记录，能够自动向停车场管理软件配套设备同步在停件中的参数设置；
• 具有良好的车辆通行校验机制；
• 具有良好的车辆通行安全管理机制；
• 具有良好的车辆通行策略控制机制；
• 具备车位管理与车位显示系统；
• 能够正确并完整的记录车辆进出记录、收费记录、操作员操作日志、集成系统输入输出数据、警报记录等；
• 具备良好的收费制度设置功能，能够由用户自定义收费规则；
• 具有完善的的报表等数据输出系统；
• 软件模块化清晰、软件设计具有友好性；
6 ． 32 软件性能评阶：
• 应具有大容量数据处理的能力，具有系统长期运行效率保证机制；
• 应具有足够的容错性，能有效捕捉各种网络异常、操作异常的能力；
• 应具有与其它应用软件的使用环境兼容性；
• 具有良好的数据存储安全机制；
• 具有良好的系统安全与访问控制机制、具有良好的数据报文通信高效处理机制；
• 系统因具有良好的可扩充性，满足管理需求的调整和变更；
• 系统因具有良好的可移植性，包括数据库的移植和应用软件的移植；
6 ． 33 软件商品化程度评阶：
• 应具有完整的系统设计文档、通信协议文档、数据库设计文档、软件集成说明文档、软件说明书等文档资料；
• 应具有很好的运行稳定性；
• 应具有良好的集成开发方便性；
• 应具有良好的软件操作方便性；
• 应具有良好的可维护性；
• 应具有良好的安装方便性；
• 应具有良好的系统升级和功能扩充机制；
6 ． 34 软件技术先进性：
• 构模型先进性；
• 通道进出管理逻辑先进性；
• 车位管理逻辑先进行；
• 通信机制先进性；
• 数据存储安全机制先进性；
• 系统安全与访问控制先进性；
• 技术指标先进性；
• 报文通信的严密性（加密机制、数据报文错包处理机制、数据通信校验机制）；
6 ． 35 软件应用评价：
• 具有较好的停车场 / 库管理适用性；
• 用户需求变更、扩充的配置灵活性；
• 具有良好的网络兼容性，能够支持 LAN 、 WAN 和总线网络；
• 具有良好的风险控制，能够避免局部故障影响整个系统的正常运行；
• 具有良好的软件操作权限管理机制；
• 具有良好的通行权限管理；
• 应具有良好的系统升级和功能扩充机制；
• 具有完善的的报表输出；
作者：杭州立方自动化工程有限公司 施广明
