停車場管理系統軟件技術要求
1．停車場管理系統術語
停車場 / 庫：專指供車輛泊車使用的具有固定車輛進出通道的非立體機械式封閉場所；
停車場 / 庫管理系統：具有管理和控制停車場配套設備功能的應用于停車場 / 庫管理的應用軟件。
長期卡：在許可條件下可在停車場 / 庫長期流通的卡片，它由停車場 / 庫管理者預先發放給車主 , 出場時不回收卡片。
臨時卡：每次泊車臨時收費泊車費用的卡片，卡片在入場時臨時發放，出場時臨時回收。
期限卡：在一段指定有效期內收取指定泊車費用的卡片，如：年卡、月卡等，它屬于長期卡的范疇。
儲蓄卡：卡片對應一個儲蓄帳戶，通過預先向帳戶充值，泊車過程自動從帳戶扣除泊車費用，它屬于長期卡的范疇。
免費卡：不收費泊車費用的卡片，它屬于長期卡的范疇。
固定卡：一次性收費泊車費用的卡片，它屬于長期卡的范疇。
非法卡：在停車場 / 庫管理系統中沒有登記過的卡片。
黑名單卡：已經掛失的卡片。
防跟車：一種防止前一輛合法車刷卡而后一輛車不刷卡跟入的處理機制。
防倒車：一種防止車輛在刷卡并放行后車輛不正常進入而倒出的處理機制。
雙卡認證：一種車主卡和車載卡同時認證有效方能通行的車輛防盜處理機制。
一車多卡：允許一車對應多張合法卡，但同一時刻只能允許一張卡泊車。
車流量檢測：一種可以有效提高通道車輛通行效率和延長機械壽命的處理機制，當多卡刷卡后，待所有合法車輛通過通道后，方可關閉道閘。
2．停車場管理軟件的基本規定
2． 1 停車場管理軟件總體規定
• 應具備操作權限管理功能：能夠設定操作員監控和管理指定通道的權限，能夠定義操作員對每個菜單項的使用許可。
• 應具備系統日志管理功能：能夠明細記錄操作員的操作過程，能夠明細記錄系統配套設備的運行記錄，能夠記錄第三方系統相關的輸入 / 輸出事件及數據。
• 應具備系統集成接口模塊：能夠支持數據庫級（如存儲過程、觸發定義、調度規則等）和應用軟件級（如 SDK 、 DLL 等）的系統集成模塊。
• 應具備系統數據存儲安全機制，支持數據庫的手動和自動備份功能，自動備份功能要求可以自定義數據庫自動備份規則。
• 應具備系統長期運行的性能保障機制，可有效避免因長期運行產生的大容量數據對系統性能造成影響。
• 應具備系統訪問控制和通信安全管理機制，可有效實現數據庫的訪問控制、應用軟件通信連接訪問控制、數據通信報文的動態加密機制。
• 應具備數據自動同步功能，能夠自動向下同步各種配套設備的運行參數、成員資格等，能夠自動向上傳配套設備的脫網運行進出記錄、原始記錄、警報記錄等。
• 應具備一定的網絡兼容性，能夠兼容 LAN 、 WAN 和總線網絡；通信方式上支持 Tcp/IP 通信方式和總線通信方式。
• 系統應該采用模塊化設計，可擴展性強，能夠方便增加本規定中‘可選功能規定'部分的要求。
• 能夠和小額支付系統、安防系統、物業管理系統、城市交通信息管理系統聯動，能夠實現集成系統輸入與停車場 / 庫系統輸出的自定義功能。
• 停車場 / 庫管理系統應能進行手動 / 自動兩種方式選擇。
• 能夠對停車場的車位數、收費規則等基本參數進行設置、修改
2 ． 2 軟件的基本功能規定
2． 2 ． 1 應具備的通行校驗功能
• 能夠識別非法卡、黑名單卡、過期卡；
• 能夠識別長期卡（期限卡、儲蓄卡、免費卡、固定卡）和臨時卡；
• 應具有入場車位滿位的校效功能；
• 應具有車輛是否重復入場的校驗；
• 應具有期限卡過期、儲蓄卡帳戶余額不足的校驗；
• 應具有當前車輛是否具有通行權限的約束校驗；
• 應具有出場時車輛無入場記錄的校驗；
2． 2 ． 2 應具備的通行安全管理功能
• 應具有車輛防砸保護功能。
• 應具有人卡和車卡雙卡認證功能，有效實現車輛防盜；
• 應具有可以防止前一輛合法車刷卡而后一輛車不刷卡跟入的防跟車處理機制；
• 應具有可以防止車輛在讀卡并放行后車輛不正常進入而倒出的防倒車處理機制；
• 應具有視頻監控與圖文監控功能，可實時視頻監控通道狀態，可實時圖文監控各種車輛進出事件和報警事件，當警報產生時，以多種方式給出提示或報警；
• 應具有圖像對比功能，實現自動調取進場抓拍的圖片與出場所抓拍的車圖進行對比
2． 2 ． 3 應具備的通行策略控制功能
• 能夠指定不同操作員管理不同通道；
• 能夠控制指定用戶類型在指定時間段內對指定通道的通行權限；
• 能夠在指定時間范圍內控制車輛的通行線路；
• 應具有進出同一通道的通行紅綠信號燈控制功能；
• 應具有卡片丟失后的出場車輛放行和收費機制；
• 應具有自定義的車位分配規則功能；
• 應具有車位預留功能；
• 應具有一車多卡的功能，滿足家庭成員或公車多卡同車的應用；
• 應具有通道車輛流量檢測的功能，有效提高通道車輛通行效率和延長機械壽命；
• 應具備通行告示系統，對認證后不允許通行的情況能夠按多種方式給車主以告示；
2． 2 ． 4 應具備的報警與告示功能
• 能夠提供多種提示或報警方式，包括文字報警、電子顯示報警、報警輸出和聲效報警。
• 能夠對非法卡、黑名單卡、過期卡等無效卡產生提示或報警；
• 能夠對合法卡的過期或余額不足等產生提示或報警；
• 能夠對合法卡的將要過期或余額將要不足等現象給出預提示；
• 能夠對在指定時間內在指定通道無權通行的合法卡產生提示或報警；
• 能夠對在指定時間內不按規定線路行駛的車輛位產生提示或報警；
• 能夠對車位滿位的情況產生提示或報警；
• 能夠對試圖重復進入的情況給出提示或報警；
• 能夠對出場時車輛無入場記錄的現產產生提示或報警；
• 能夠對入口發票機無卡現象產生提示或報警；
• 能夠對檢測到的火災、防盜等信號產生提示或報警；
• 能夠對檢測到的設備網絡故障及時產生提示或報警。
• 能夠對車輛非法闖入和闖出的現象產生提示或報警。
• 能夠對跟車和倒車現象產生提示或報警；
• 能夠對火警、防盜警、跟車報警、倒車報警等警報解除后產生提示；
• 能夠對車輛駛入通道后給出歡迎詞或取卡提示，如取卡提示、刷卡提示等；
• 能夠對車輛在車道停留時間過長產生提示或報警。
2． 2 ． 5 應具備的車位管理功能
• 能夠統計和顯示整個停車場余位信息，并具有向周邊告示功能；
• 能夠統計和顯示具體區域的余位信息，并具有向周邊告示功能；
• 區域余位的統計和顯示在車輛不按車位分配規則泊車時亦能正確統計和公示；
• 能夠按用戶自定義的規則自動分配泊車位；
應具備脫機運行后的場內余位信息糾正功能
3 ．停車場管理軟件的數據結構
3． 1 數據庫的選擇
• 應選用具有安全機制的關系型數據庫管理系統。
• 所選用的數據庫要求具有多種安全性認證模式，支持數據庫之角色和用戶管理功能，能夠方便實現權限許可的驗證、授予、修改和收回。
• 所選用的的數據庫要求具有表、圖表、索引、視圖、存儲過程、觸發器等數據庫組件。
• 所選用的數據庫應具有數據完整性檢查功能，包括實體完整性、域完整性、參考完整性、用戶自定義完整性；支持約束（ Default 約束、Ｃ heck 約束、Ｐ riMary Key 約束、 Unique 約束和 Foreign 約束）、缺省和規則定義；
• 所選用的數據庫應具有強大的數據備份與恢復功能，支持多種備份／恢復介質、多種備份／恢復類型，并要求應有聯機備份 / 恢復功能。
• 所選用的數據庫應具有數據控制語言（ DCL ）、數據定義語言（ DDL ）、數據操作語言（ D ＭＬ）。
• 選用的數據庫要求具有良好的開放性、可移植和可擴展性，應具有多種數據轉換（類型運算、導入導出等）功能和多種數據復制功能。
• 所選用的數據庫應具有事務控制功能，可滿足事物的自動性、一致性、獨立性和持久性要求，能有效應對市電故障和網絡故障等原因造成的事物遞交和回退。
• 所選用的數據庫具有良好的并發控制功能，支持行級鎖（記錄鎖）、頁級鎖、簇級鎖、表級鎖和數據庫級鎖，并能有效避免用戶控制的死鎖問題和事務引用的會話級和表級死鎖問題。
• 所選用的數據庫應能夠滿足 ODBC 接口規范。
3 ． 2 數據結構
3． 21 車主基本資料（用戶信息）信息數據結構 包括：
（ 1 ）車主編號；（ 2 ）車主名稱；（ 3 ）對應卡號；（ 4 ）用戶類型（區別不同的收費方式）；
（ 5 ）用戶性質（區別是普通車位，預留車位或固定車位用戶）；（ 6 ）身份證號碼；
（ 7 ）車身款式；（ 8 ）車牌號碼；（ 9 ）車身顏色；（ 10 ）汽車品牌；（ 11 ）聯系電話；
（ 12 ）聯系地址。
3 ． 22 收費人員信息數據結構 包括：
（ 1 ）收費員編號；（ 2 ）收費員姓名；（ 3 ）年齡；（ 4 ）性別；（ 5 ）工作時間；（ 6 ）聯系電話；（ 7 ）聯系地址。
3 ． 23 收費記錄數據結構 包括：
（ 1 ）收費類型（區分辦卡收費或泊車收費）；（ 2 ）證卡類型（區分期限卡、儲蓄卡、免費卡、固定卡和臨時卡等）；（ 3 ）車主證件編號；（ 4 ）車主姓名；（ 5 ）車主卡號；（ 6 ）入場時間；（ 7 ）出場時間；（ 8 ）泊車計時；（ 9 ）收費金額；（ 10 ）收費日期；（ 11 ）收費操作員；
3 ． 24 車輛進出記錄數據結構 包括：
（ 1 ）車主證件編號；（ 2 ）車主姓名；（ 3 ）車主卡號；（ 4 ）進出時間；
（ 5 ）進出抓拍車圖；（ 6 ）車主證卡類型；（ 7 ）進出狀態；（ 8 ）進出通道；
（ 9 ）汽車車型；（ 10 ）車牌號碼；（ 11 ）車身顏色；（ 12 ）汽車品牌；
（ 13 ）車主聯系電話；（ 14 ）車主聯系地址；（ 15 ）所泊車位；
3 ． 25 原始監控事件記錄數據結構 包括：
（ 1 ）事件記錄類型；（區分進出記錄、通道地磁輸入記錄等）；（ 2 ）事件記錄對應控制器；（ 3 ）事件記錄對應通道；（ 4 ）事件記錄卡號；（ 5 ）事件記錄從設備號；（ 6 ）事件記錄進出狀態；（ 7 ）事件記錄輸入輸出點號；（ 8 ）事件記錄時間；
3 ． 26 手動控閘記錄數據結構 包括：
（ 1 ）手動控閘時間；
（ 2 ）手動控閘者；
（ 3 ）手動控閘通道；
（ 4 ）手動控閘類型（區分普通開閘、關閘、緊急開閘、緊包關閘等）；
3． 25 原始監控事件記錄數據結構 包括：
（ 1 ）事件記錄類型；（區分進出記錄、通道地磁輸入記錄等）；（ 2 ）事件記錄對應控制器；（ 3 ）事件記錄對應通道；（ 4 ）事件記錄卡號；（ 5 ）事件記錄從設備號；（ 6 ）事件記錄進出狀態；（ 7 ）事件記錄輸入輸出點號；（ 8 ）事件記錄時間；
3． 26 手動控閘記錄數據結構 包括：
（ 1 ）手動控閘時間；
（ 2 ）手動控閘者；
（ 3 ）手動控閘通道；
（ 4 ）手動控閘類型（區分普通開閘、關閘、緊急開閘、緊包關閘等）；
3． 27 警報記錄數據結構 包括：
（ 1 ）系統警報發生源；
（ 2 ）系統警報類型；
（ 3 ）系統警報描術；
（ 4 ）系統警報發生時間；
3 ． 28 操作日志記錄數據結構 包括：
（ 1 ）操作員編號；（ 2 ）操作員姓名；（ 3 ）操作類型；（ 4 ）操作時間；（ 5 ）操作對象；
（ 6 ）操作內容；（ 7 ）操作結果；
3． 3 數據接口標準
由于本標準規定所選用的數據庫要求能夠滿足 ODBC 接口規范，所以數據接口標準將基于開放式數據鏈路來實現。
3 ． 31 數據接口標準涉及的數據結構
• 車主基本資料數據接口標準；
• 收費人員數據接口標準；
• 收費記錄數據接口標準；
• 進出記錄數據接口標準；
• 原始監控記錄數據接口標準；
• 手動控閘記錄數據接口標準；
• 警報記錄數據接口標準；
系統日志記錄數據接口標準；
3 ． 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 ）操作結果；
• 接口數據實現：
• 鍵字段要求有數據唯一性校驗；
• 所有字段要有數據合法性校驗；
• 數據源對象要有字段完整性校驗；
• 代碼數據或類型不匹配數據要進行邏輯轉換；
圖片數據采用圖片文件名形多交互；
4 ．停車場管理的開放性
4 ． 1 對外信息的交互協議
4 ． 1 ． 1 以采用 GPRS 方式進行數據傳輸。
4 ． 1 ． 2 應采用 TCP 方式進行網絡鏈路連接。
4 ． 1 ． 3 應對數據的發送和接受提供 ACK 回復確認。
4 ． 1 ． 4 設備主動發送傳輸的協議內容應包括設備識別碼，指今命令字，設置正常運行期間的流水遞增的消息編碼和發送的信息內容。
4 ． 1 ． 5 系統主動發送的協議內容必須包括設備的識別碼，指令命命令字，系統合局的流水遞增的消息編碼和發送的信息內容。
4 ． 1 ． 6 設備對于系統發來的信息的回復的協議內容應包括設備識別碼，指令的命令字，由系統發來的消息編號和回復的內容。
4 ． 1 ． 7 系統對于終端設備發來的信息的回復的協議內容必須包括設備識別碼，指令命令字，出設備發送來的消息編號和回復的內容。
4 ． 1 ． 8 設備補充發送的數據要求具有時間戳信息。
4 ． 2 對外信息的交互數據結構
4 ． 2 ． 1 符合 TCP/IP 協議
4 ． 2 ． 2 數據結構開放：便于二次開發，便于與其它軟件數據的共巷。
4 ． 3 其它規定
4 ． 3 ． 1 可以與各種現場線兼容，如 CAN 線， 485 總線等。
4 ． 3 ． 2 能與 Internet 聯網，實現數據共享。
4 ． 3 ． 3 應支持無線通訊，配有 GPRS 數據傳輸模塊。
4 ． 3 ． 4 應能與交通信息系統，安防系統，智能建筑等系統兼容。
5．停車場管理軟件的測評
5 ． 1 軟件測試：
軟件測試應采用黑盒測試方法，通過測試來檢查是否每個功能都能正常使用，它可完全不考慮程序內部結構和處理過程，在程序的接口進行測試，它只檢查程序功能是否能按照要求正常使用，程序是否能適當地接收輸入數據并產生正常的輸出信息。軟件測評的主要依據是隨應用軟件一起發行的軟件說明書。
5 ． 11 單元測試
在遵循模塊化設計思想的軟件中，每個模塊完成一個清晰定義的子功能。而且這個子功能和同級其它模塊的功能之前相互依賴度很小，因此，有可能把每個模塊作為一個單獨的實體來測試，而且通常比較容易檢驗模塊的正確性，單元測試的目的是保證每個模塊作為一個單元是能正確運行的，單元測試任務包括：
（ 1 ）模塊接口測試：是否能在正確輸入的條件下產生與預期一樣的的輸出，是否能屏蔽不正確的輸入或在不正確輸入的條件下能夠捕捉并處理這些不正確的輸入。
（ 2 ）模塊邊界條件測試：長期的軟件測試研究表明，大量錯誤往往發生在輸入或輸出的邊界上，因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
（ 3 ）執行通路測試：它對模塊中對每一條獨立執行的路徑進行測試，以發現所有可能的，潛在的執行邏輯性錯誤。
（ 4 ）出錯處理測式：一個好的設計應能預見各種出錯條件，并預設各種出錯處理通路，校驗模塊中是否存在無法處理的錯誤出口。
5 ． 12 集成測試
集成測試又稱構件測試它是把經過單元測試的模塊放在一起形成一個構件系統來進行測試，模塊相互間的協調和通信是這個測試過程的主要問題，因此這個步驟著重測試模塊間的交互，應采用如下的測試思想：
（ 1）自頂向下集成：自頂向下集成是構造程序結構的一種增量式方式，它從主控模塊開始，按照軟件的控制層次結構，以深度優先或廣度優先的策略，逐步把各個模塊集成在一起，其工作步驟為：
• 以主控模塊作驅動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代；
• 依據所選的集成策略（深度優先或廣度優先），每次只替代一個樁模塊；
• 每集成一個模塊立即測試一遍；
• 只有每組測試完成后，才著手替換下一個樁模塊；
• 為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地重復已做過的測試）；
• 從第 2 步開始，循環執行上述步驟，直至整個程序結構構造完畢。
（ 2）自底向上集成：自底向上測試是從“原子”模塊（即軟件結構最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊，其工作步驟為：
• 把低層模塊組織成實現某個子功能的模塊群；
• 開發一個測試驅動模塊，控制測試數據的輸入和測試結果的輸出；
• 對每個模塊群進行測試；
• 刪除測試使用的驅動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群；
• 從第一步開始循環執行上述各步驟，直至整個程序構造完畢。
5 ． 13 系統測試
系統測試是把經過測試的構件裝配成一個完整的系統來測試。在這個過程中不僅應發現設計和編碼的錯誤，還應驗證系統確實能提供設計時指定的功能，而且系統的動態特性也符合要求。在這個測試中發現的往往是軟件設計中的錯誤，也可能發現需求說明中的錯誤。
系統測試的基本方法有：
• 恢復測試：恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤并重新啟動系統。恢復測試首先要采用各種辦法強迫系統失敗，然后驗證系統是否能盡快恢復。
• 安全測試：安全測試檢查系統對非法侵入的防范能力。安全測試期間，測試人員應采用各種辦法試圖突破防線。例如，試圖截取或破譯口令、專門定做軟件破壞系統的保護機制、故意導致系統失敗，企圖趁恢復之機非法進入等等。
• 強度測試：強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。
• 性能測試：測試系統對大容量數據的處理能力、對長期運行后的運行性能保障能力以及各種性能測試是否能夠符合軟件說明書的要求。
5 ． 14 驗收測試
驗收測試把軟件系統作為單一的實體進行測試，測試內容與系統測試基本類似，但它是在用戶（或驗收組）積極參與下進行的，而且可能主要使用實際數據（系統將來要處理的數據）進行測試，驗收測試的目的是驗證系統確實能夠滿足用戶的需要，在這個測試步驟中發現的常常是系統需求說明中的錯誤。驗收測試包括兩個方面：
• 測試應用軟件符合軟件說明書的內容；
• 測試應用軟件能夠滿足軟件購銷合同中用戶特別指定的個性化功能
5 ． 2 測試用例
邊界值測試用例：
• 如果輸入條件規定了值的范圍，則應該取剛達到這個范圍的邊界值，以及剛剛超過這個范圍邊界的值作為測試輸入數據；
• 如果輸入條件規定了值的個數，則用最大個數、最小個數、比最大個數多 1 格、比最小個數少 1 個的數做為測試數據；
• 根據每一個輸出條件，驗證在邊界輸入條件下是否可以正確的輸出
• 如果程序的規格說明給出的輸入域或輸出域是有序集合（如有序表、順序文件等），則應選取集合的第一個和最后一個元素作為測試用例；
• 如果程序用了一個內部結構，應該選取這個內部數據結構的邊界值作為測試用例。
• 如果輸入條件規定了值的范圍，驗證是否允許非法的輸入，合法的輸入是否違反邏輯輸入。（如：輸入條件為開始和結束時間，首先必須測試合法性輸入，然后再驗證結束時間大于開始時間這種違反邏輯的情況下得出的輸出結果。
環境測試用例
• 電源掉電的測試，包括軟件在待機時的掉電和軟件在處理數據時的掉電。
• 強行結束軟件任務的測試。
• 操作系統 CPU 和內存資源耗盡的測試，多開一些需要大資源的其它程序，使要測試的軟件處理非常‘饑餓'的狀態下，測試其性能和數據處理的正確性。
• 如果系統包含網線通訊線路，物理通訊線路突然中斷的測試。
• 對于處理任務較重的部分，如果條件允許，可以考慮用性能很差的計算機去測試，這時候可能會暴露出很多問題。
特殊操作測試用例
某些特殊的操作可以發現程序中潛在的問題，如：
• 軟件沒有正常退出就關閉操作系統；
• 不正常關閉應用軟件人機交互窗口；
• 軟件正在執行一項較耗時命令時退出應用軟件；
• 以復制 / 粘貼的方式代替鍵盤輸入數據；等等。
5．3 軟件評價：
5． 31 軟件功能評階：
• 應用軟件功能符合設計說明的規定；
• 能夠較好的滿足停車場 / 庫管理需求的擴充（可選部分規定的內容）；
• 系統完整性：因具有完整的系統設計相關文檔資料、具有完整的系統二次開發集成接口、具有完整的數據輸入與輸出接口、具有完整的系統集成方案、具有完整的通道進出管理系統，車位引導管理系統，報警處理系統、取車系統、節能照明控制系統等停車場管理的可選子系統。
• 應具有足夠的容錯性，能有效捕捉各種網絡異常、操作異常的能力；
• 具有良好的數據自動同步機制，能夠主動上傳脫網運行后產生的記錄，能夠自動向停車場管理軟件配套設備同步在停件中的參數設置；
• 具有良好的車輛通行校驗機制；
• 具有良好的車輛通行安全管理機制；
• 具有良好的車輛通行策略控制機制；
• 具備車位管理與車位顯示系統；
• 能夠正確并完整的記錄車輛進出記錄、收費記錄、操作員操作日志、集成系統輸入輸出數據、警報記錄等；
• 具備良好的收費制度設置功能，能夠由用戶自定義收費規則；
• 具有完善的的報表等數據輸出系統；
• 軟件模塊化清晰、軟件設計具有友好性；
5 ． 32 軟件性能評階：
• 應具有大容量數據處理的能力，具有系統長期運行效率保證機制；
• 應具有足夠的容錯性，能有效捕捉各種網絡異常、操作異常的能力；
• 應具有與其它應用軟件的使用環境兼容性；
• 具有良好的數據存儲安全機制；
• 具有良好的系統安全與訪問控制機制、具有良好的數據報文通信高效處理機制；
• 系統因具有良好的可擴充性，滿足管理需求的調整和變更；
• 系統因具有良好的可移植性，包括數據庫的移植和應用軟件的移植；
5 ． 33 軟件商品化程度評階：
• 應具有完整的系統設計文檔、通信協議文檔、數據庫設計文檔、軟件集成說明文檔、軟件說明書等文檔資料；
• 應具有很好的運行穩定性；
• 應具有良好的集成開發方便性；
• 應具有良好的軟件操作方便性；
• 應具有良好的可維護性；
• 應具有良好的安裝方便性；
• 應具有良好的系統升級和功能擴充機制；
5 ． 34 軟件技術先進性：
• 構模型先進性；
• 通道進出管理邏輯先進性；
• 車位管理邏輯先進行；
• 通信機制先進性；
• 數據存儲安全機制先進性；
• 系統安全與訪問控制先進性；
• 技術指標先進性；
• 報文通信的嚴密性（加密機制、數據報文錯包處理機制、數據通信校驗機制）；
5 ． 35 軟件應用評價：
• 具有較好的停車場 / 庫管理適用性；
• 用戶需求變更、擴充的配置靈活性；
• 具有良好的網絡兼容性，能夠支持 LAN 、 WAN 和總線網絡；
• 具有良好的風險控制，能夠避免局部故障影響整個系統的正常運行；
• 具有良好的軟件操作權限管理機制；
• 具有良好的通行權限管理；
• 應具有良好的系統升級和功能擴充機制；
• 具有完善的的報表輸出；
- 上一篇：譽澄某集貿市場停車場管理系統方案設計 2012/5/31
- 下一篇：現代智能停車場管理技術及其發展趨勢 2020/4/10