民生熱線服務方案

民聲熱線服務建設方案

1.服務方案

1.1.系統建設內容

1.1.1.建設方案需求

需求名稱

數字中繼

IVR

人工坐席

錄音系統

定制型業務軟件系統

需求內容

PRI信令數字中繼

交互式語音應答

IP話機+耳麥

手機APP+網站+PC端

1

10

10

10

1

數量

1.1.2.業務軟件要求

分類模塊

我要發帖

結果查詢

滿意度評價

功能名稱

我要發帖

結果查詢

滿意度評價

天氣查詢

公積金查詢

隨手拍

便民服務

公共自行車查詢

違章查詢

PM2.5查詢

快遞查詢

手機版民聲手機版結果查詢（手機版）

模塊

模塊

模塊

模塊

模塊

1

1

1

1

1

火車票查詢

飛機票查詢

單位

模塊

模塊

模塊

模塊

模塊

模塊

模塊

數量

1

1

1

1

1

1

1

滿意度評價（手機版）

我要發帖（手機版）

民聲簡介（手機版）

民聲發布（手機版）

常見問題（手機版）

結果查詢

滿意度評價

我要發帖

民聲網站民聲網站

民聲簡介

民聲發布

常見問題

熱線管理來電受理

事件管理

延期申請

審核部門回復

事件查詢

知識提交審批

受理熱線

轉辦未查看

后臺管理系統

后臺管理

轉辦處理中

已回復/撤銷/退回/催辦/超時

/辦結事件

本人受理事件

知識提交

知識庫查詢

未接收事件

未處理事件

已處理事件

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

延時事件

已辦結事件

事件打印/導出

在線預覽

回訪記錄

流轉記錄

不滿意工單

登錄/退出

公告發布

通知公告

公告管理

組織架構

即時通訊

信息框

滿意度統計

辦結率統計

回復率統計

一次辦結統計

每日受理事件

事件總統計

數據分析

各部門承辦情況統計

事件類型統計

鎮街事件統計

坐席工作量統計

坐席回訪量統計

坐席的一次辦結率統計

權限維護

系統設置

欄目內容維護

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

模塊

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1.2.“隨手拍”系統

1.2.1.系統功能介紹

?我要發帖

市民通過手機進入隨手拍，進入我要發帖界面，選擇發帖類型（咨詢、投訴、

建議、舉報、求助）。

用手機拍照上傳圖片，寫問題描述，描述清楚自己需要發布的信息；設置查

詢密碼。設置6位字母+數字查填詢密碼，方便快速查詢到自己帖子的回復情況。

填寫姓名、等個人信息；點擊提交按鈕，發帖成功。

?結果查詢

市民通過帖子編號和查詢密碼來查詢自己的帖子處理情況，結果查詢為保密

查詢。

?滿意度評價

市民查看帖子后，可對部門的處理結果進行滿意度評價，選擇滿意、基本滿

意或不滿意。

?便民服務

可進行天氣查詢、公積金查詢、火車票查詢、飛機票查詢、公共自行車查詢、

違章查詢、PM2.5查詢、快遞查詢。

1.2.2.流程說明

1.2.3.系統功能

1.2.3.1.網站平臺

A.上傳人：

上傳人在網站平臺無操作。

B.管理者

1)待受理信息列表

顯示待受理的信息，包括上傳人提交的和被處理者退回的信息。

2)已受理信息列表

顯示已受理但未處理的信息

3)已處理信息列表

顯示已處理的信息

4)信息分類與轉發

選擇該信息的分類并將信息轉發給相應的處理人，信息狀態變為已受理，上傳人

將不能修改此信息。

如信息為垃圾信息，管理員直接關閉該條信息，此信息將停止流轉，狀態變成已

處理，處理意見默認為“垃圾信息”。

5)查詢統計

可根據處理種類或者處理人查詢統計相應的信息量。

6)向上傳人下達“月度任務”

管理者通過網站向上傳人簡要下達月度工作任務，推送至上傳人手機客戶端，上

傳人據此安排月度重點工作，并每月據此填寫“工作總結”。

7)設置上傳人等級和星級

默認可每周統計一次，通過受理數量區分等級；管理者可手動設置用戶的等級。

每月由管理者根據受理數量和月度完成情況評定上傳人星級（按五星級評定），

并在網站手動將星級推送至上傳人手機客戶端顯示。

C.處理者

1)本人待處理信息列表

本人未處理的信息列表，可通過信息分類篩選。

2)本人已處理信息列表

本人已處理的信息列表，可通過信息分類篩選。

3)反饋處理結果

如能處理，上傳相應的圖片、音視頻和處理人、處理時間、處理描述的處理結果

提交，信息狀態變為已處理；

4)退回無法處理的信息

如不能處理，則填寫意見退回到管理員處重新分配，信息狀態對于上傳人仍是已

受理，但對于管理員是待分配狀態，能看到是被退回的和退回原因。

5）任務分解到下一人處理

如需要其他人處理或多人處理，可進行層級分解

D.系統管理員

1)組織機構管理和授權

單位、部門的管理，按模塊或人員進行授權管理。

2)上傳人用戶信息管理

可添加、禁用、修改上傳人用戶信息及其密碼。

包括姓名、性別、頭像、手機號（用戶名）

3)管理者用戶信息管理

可添加、禁用、修改管理者用戶信息及其密碼。

4)處理者用戶信息管理

可添加、禁用、修改處理者用戶信息及其密碼。

包括姓名、性別、手機號（用戶名）、單位、部門信息。

5)信息分類類別維護

維護信息分類的名稱，可添加、禁用、修改。

1.2.3.2.手機客戶端

A.上傳人：

1)用戶注冊與登錄

用戶注冊需要提供手機號、密碼、姓名、性別，以手機號作為唯一驗證，可通

過驗證碼短信驗證手機號是否正確

2)首頁

a/純介紹類信息：分為關于隨手拍、使用幫助、審核流程說明、。

b/互動信息：在同一個頁面顯示“月度任務”和“月末總結”兩個窗口。

“月度任務”：由管理者編輯下達后，推送至上傳者手機客戶端，上傳者只閱看，

無編輯權限。

“月末總結”：由上傳者在手機客戶端小窗口編輯，上傳至管理者，供管理者評

價。

3)我的信息列表

可通過待受理、已受理、已處理進行篩選；進入頁面后先顯示全部、待受理、已

受理、已處理三類和相應數量，再次點擊后顯示信息列表，列表中包含問題標題、

提交時間、受理時間、受理狀態。

4)信息上傳

內容包括上傳時間、相關位置、問題標題、問題描述、語音（1個）、視頻（1個）、

圖片（6個以內）。

5)設置

包括我的賬號、修改密碼、退出。我的賬號中包括頭像、姓名、手機號、性別、

等級、星級等信息，其中：“等級”和“星級”信息由管理者賦值后，推送至上

傳者手機客戶端顯示。

B.管理者

1)用戶登錄

2)首頁

a/純介紹類信息：分為關于隨手拍、使用幫助、審核流程說明、。

b/互動信息：顯示個上傳人列表，點擊每個上傳人后，在同一個頁面顯示“月

度任務”和“月末總結”兩個窗口。

“月度任務”：由管理者從網站后臺/手機客戶端編輯下達后，推送至不同的上傳

者手機客戶端，上傳者只閱看，無編輯權限。

“月末總結”：由上傳者在手機客戶端小窗口編輯，上傳至管理者，供管理者評

價。

3)已受理列表

進入已受理列表后，先出現全部、分類1、分類2等列表，列表后面有相應的信

息總數量和紅數字顯示新增未讀數量，可通過右上方按鈕過濾顯示全部、待處

理、已處理進行篩選。點擊每個分類后進入顯示具體的上傳信息列表。

4)待受理列表

形式同3），但只顯示待受理的信息。

5)設置

包括我的賬號、修改密碼、退出。我的賬號中包括頭像、姓名、手機號、性別信

息。

C.處理者

1)用戶登錄

2)首頁

分為關于隨手拍、使用幫助、審核流程說明、。都是純介紹類。

3)本人已處理列表

進入已處理列表后，先出現全部、分類1、分類2等列表，列表后面有相應的信

息總數量和紅數字顯示新增未讀數量，點擊每個分類后進入顯示具體的上傳信

息列表。

4)本人待處理列表

形式同3），只顯示待處理信息。

5)設置

包括我的賬號、修改密碼、退出。我的賬號中包括頭像、姓名、手機號、性別信

息。

D.系統管理員

系統管理員在手機端無操作。

1.2.4.民聲網站（含手機版）

?我要發帖(手機版)

為方便市民隨時隨地都能發帖，電腦端的民聲網站和手機端的隨手拍都有獨

立發帖功能，為方便使用和高效反饋，其功能設計如下：

市民通過網站、手機進入某區民聲，選擇發帖類型（咨詢、投訴、建議、舉

報、求助），進入發帖界面。

填寫問題標題、問題內容，描述清楚自己需要發布的信息，也可上傳圖片；

針對自己所提問題選擇相關部門。設置6位字母+數字查詢密碼，方便快速查詢

到自己帖子的回復情況。填寫姓名、、等個人信息。點擊提交

按鈕，發帖成功；民聲服務平臺后臺可審核和接收發帖信息，進行處理。

?結果查詢

市民通過嗎密碼查詢自己帖子處理情況。

?滿意度評價

市民查看帖子后，可對部門的處理結果進行滿意度評價，選擇滿意、基本滿

意或不滿意。

?民聲簡介

對民聲的基本信息進行介紹。

?民聲發布

根據實際發布通知、部門公告等文件。

?常見問題

各部門可自行維護、更新常見問題知識庫

1.2.5.統一后臺管理平臺

民聲熱線、聲網站（含手機版和隨手拍）和政務，三個平臺管理系

統整合建設，后臺管理數據整合，市民問題統一處理和回復，三個系統管理后臺

融合成為統一的后臺管理系統，三個系統的數據歸屬于同一后臺管理，單位回復

途徑統一化，部門管理規范化。

將已有三個業務系統整合成民聲服務平臺，硬件資源充分利舊，融合到民聲

服務平臺物理資源池內，實現業務系統統一運維管理、物理資源統籌調度分配和

信息化建設整體合力。

建設數據資源統一存儲與管理系統，具備分布式、可擴展、存儲與管理海量

異構數據的能力，將各個業務系統數據資源、政府部門單位信息資源、互聯網信

息資源，經清洗、轉換、加工、標準化后，加載到統一存儲與管理平臺。全局信

息資源的統一整合，實現全局視角的信息資源價值發現。

1.2.5.1.民聲熱線

有的市民不想通過發布帖子的途徑來提出訴求，還可以通過撥打民聲熱線提

出問題或訴求，坐席人員接聽電話后，進行來電受理登記，登記下用戶基本情況，

包括：姓名、性別、來電電話、（可復制來電）、家庭住址。受理內容：

處理情況、滿意度、處理意見、事件備注。并可通過短信方式將相關部門的聯系

電話和地址及相應的處理流程推送至眾手機上。

1.2.5.2.統一后臺管理

為了減少職能部門來回切換系統，充分利用后臺資源，提高工作效率，市民

發布的帖子信息與來電內容，統一匯總至同一后臺進行回復處理，進行統一后臺

管理。

某區政務的數據字段與民聲熱線和網站及隨手拍的帖子信息差異

較大，信息無法匯總統一，將某區政務的來電事件采用“一鍵復制”

方式錄入。信息統一管理后，職能部門無需切換系統，在同一系統內完成接收并

進行處理，其后臺管理設計功能如下：

?事件管理

市民通過電話、網站反映的內容，信息統一匯總至同一后臺，某區政務服務

熱線承辦單直接導入，能區分信息來源，管理員查看市民的反映內容，初審后通

過平臺轉交至責任單位處理。審核不通過的，管理人員根據實際情況處置。

?延期申請

因特殊原因不能及時處理的事項，責任單位可申請延期，但需管理員審核通

過后。

?審核部門回復

管理員查看回復信息，審核回復內容，通過后發布“前臺”。審核不通過的，

退回相關部門繼續處理。

?事件查詢

查詢模塊是整個平臺的核心功能，可根據的欄目內容、信息關鍵字、問題分

類等進行單詞組和多詞組聯合查詢，展示不同的內容。

?知識提交與審核

審核承辦單位和話務人員上傳的針對某事件的解決方案及法律法規。

?熱線受理

市民通過撥打熱線提出問題或訴求，座席人員接聽電話后，進行來電受理登

記，登記用戶基本情況，包括：姓名、性別、來電電話、（可復制來電）、

家庭住址。信息情況：客服工號、受理來源（用戶來電等）、內容分類、處理時

限（天）、來電性質。受理內容：是否保密、處理情況、滿意度、處理意見、事

件備注。

坐席人員可根據姓名、電話查信息存根打入電話是否有記錄，是否問過同

樣的問題。可根據座席號、編號、部門、電話、提問時間、來電人反映查看歷史

記錄和事件答復情況。

?轉辦未查看

提示辦理相應事件的部門還未查看的事件。

?轉辦處理中

已經轉到相應部門正在處理的事件。

?已回復/撤銷/退回/催辦/超時/辦結事件

對事件處理的進度分類顯示。

?本人受理事件

對座席人員已受理的事件進行統計和查看。

?知識庫提交

承辦單位和話務人員上傳事件解決方案及法律法規。

?知識庫查詢

快捷完成知識庫的查詢。

?未接收/未處理/已處理/延時/已辦結

系統內分類設置

?事件打印/導出

系統內信息內容可導出Excel表格，打印承辦單等。

?在線預覽

民聲熱線信息內容在線查看，方便職能部門處理。

?回訪記錄

展示事件的回訪記錄情況。

?流轉記錄

展示事件的流轉記錄情況。

?不滿意工單

滿意情況以某區政務處理系統為準，可一鍵覆蓋本平臺內所有編號

相同的工單。

?登錄/退出

用戶和管理員通過用戶名、密碼、驗證碼登錄系統，可修改密碼、退出系統。

1.2.5.3.數據分析

?滿意度統計

根據滿意度調查結果完成統計。

?辦結率統計

根據限時內辦結數量統計，區分一次、二次、三次、四次及以上。

?回復率統計

根據實際回復數量統計。

?一次辦結統計

根據一次辦結數量進行統計。

?每日受理事件

對每個坐席人員每日處理的事件進行統計。

?事件總統計

對所有事件進行匯總統計和查看。

?各部門承辦情況統計

對各部門承辦的情況進行統計。

?按事件類型統計

按事件類型進行分類統計。

?座席工作量統計

統計座席的工作量。

?座席回訪量統計

統計座席的回訪量。

1.2.5.4.通知公告

該模塊主要包括公告發布和公告管理功能，通過相關權限用戶進行公告發布

操作，系統內所設置相關用戶均可接收到公告通知，簡化線下公告通知繁雜的流

程，提升公告信息發布的效率。

1.2.5.5.即時通訊

各類即時通訊設備已成為日常工作和生活交流的必備工具，但未經安全防護

的即時通訊設備可能會帶來風險，安全起見，該模塊需要滿足工作人員內部溝通

需求（消息瀏覽和消息管理）。

1.2.5.6.系統設置

?權限設置

上級部門可根據需要設置下級部門所能查看的內容。

?欄目內容維護

事前維護工單中可點選欄目的內容。

1.3.資源數據庫建設

某區民聲服務平臺數據庫的建設。某區民聲熱線、某區民聲網站（含手機版

和隨手拍）和政務，通過不同途徑獲取數據，大量的基礎數據整合到同

一后臺，需要建設強大的資源數據庫來存儲和分析基礎數據。

以“業務導向”和“數據導向”為出發點，通過資源數據庫的建設，解決數

據的存儲、管理、共享問題，使分散不規范、難以共享的數據標準化、集中化，

形成數據的快速訪問和高效利用。通過云計算、大數據技術來改變傳統數據庫的

建設思路，最終把某區民聲服務平臺建設成為具備“物理資源按需分配”、“海量

存儲”、“高效檢索”、“智能分析”、“可控共享”的應用平臺。同時資源數據庫的

建設需要保證平臺的擴展性、高效性及先進性，為某區民聲服務平臺打下堅實的

基礎。

堅持統一規劃，三個系統將在統一規劃指導下開展工作，共同規劃、統一落

實。

堅持統一標準，統一標準是實現互聯互通、資源共享、避免業務條塊化、信

息孤島化的根本前提。

堅持統一建設，避免各層級、各系統之間存在壁壘、互不兼容的情況，實現

系統平臺統一設計、統一開發、統一接口，做到上下統一、有效對接，形成完整

統一的平臺。

堅持統一平臺，建立統一平臺是實現業務融合、數據整合、資源共享、協調

同步的重要基礎，在統一平臺上，才能形成一個完善、規范、可控、高效的信息

化系統建設和業務支撐。

堅持統一管理。統一管理是提高效率、規范操作的重要基礎。從樹立長遠的、

全局的、統一的觀點著手，做到統一運維、統一監管，降低運維管理的復雜度和

成本，提高信息化建設成效。

資源數據庫規劃將以某區政務受理中心基本業務需求為基礎，實現

以下建設目標：

（1）全面盤活現有信息資源，解決信息孤島問題，建立統一的數據資源平

臺。

（2）整合各類數據，建立統一的標準規范，為業務決策提供更多視角的可

視化分析，出各類訴求背后的共性、傾向性問題，為領導決策提供更加科學的

參考依據。

1.4.呼叫中心功能描述

呼叫中心業務支撐層介紹

1、綜述

為了更加方便、快捷地部署IPT呼叫中心系統，使最終用戶通過簡單的配置

或少量的編程就能完成整個呼叫中心的實施，我們提供基于CTI技術，實現了呼

叫中心控制的很多高級功能，如：IVR（自動語音應答），ACD（人工座席排隊），

REC（數字錄音），Conf（語音會議），FAX（傳真），DB（數據庫），E-mail（郵

件），SMS（短信），TTS（文本轉語音），信息到達提醒，知識庫，工單生成/

流轉，座席監管，黑紅名單，排班表，數據統計，報表生成等功能，中間件還向

應用層（系統集成、應用開發商）提供標準的開發程序接口，方便第三方廠商開

發各種具體應用。其具有強大的靈活性和可擴展性，同時這些所有組件功能都集

成與一個硬件設備中，為呼叫中心穩定運行提供了可靠的軟件平臺，并廣泛適用

于各種行業的呼叫中心的建設，有效降低了呼叫中心的建設和維護難度。

2、IPT呼叫中心中間件的基本組成

?自動語音應答系統（IVR）；

?智能話務排隊系統（ACD）；

?通用座席接口（AGET）；

?座席全程錄音系統（REC）；

?統計報表系統（REPORT）；

?座席監管系統等；(MAAGER)

?知識庫系統；(KBS)

?工單生成；(WORKFLOW)選配

?自動外呼系統；(OUTBOUD)選配

?黑/紅名單系統；(BRL)

3、呼叫中心中間件協同工作流程

呼叫中心的系統運行過程中，為了使系統運行效率達到最佳狀態，及時處理

各種事件，中間件中的各部件是緊密結合，相互協調工作的。

首先，座席工作人員啟動座席應用程序，通用座席接口（AGET）即將該座

席的狀態以及座席信息等告知智能話務排隊系統（ACD）,自動排隊系統將座席的

這些信息保存并實時維護這些信息。

當一個來自PST或WEB的呼叫進入呼叫中心時，自動語音應答系統（IVR）

首先應答該來話并獲取來話信息（主叫號碼），甚至可以向該用戶播放語音提示

音收集用戶的相關資料，同時通知ACD有一個來電要轉移到座席并把來電的相

關信息一起送給ACD，ACD根據有關信息（排隊策略）去查一個最適合的空閑

座席，如果到相應的座席，則將該座席的分機號碼告訴IVR，IVR將來電轉移

到分機，由座席繼續為該來電服務，直至通話結束。如果沒有合適的座席，IVR

將對來話播放等待音樂或提示“沒有空閑座席”，用戶可選擇是否繼續等待，如

果用戶繼續等待，則ACD將該來話納入排隊隊列，一旦有合適的空閑座席，V_IVR

將收到來自ACD的通知，此時IVR即可將來話轉到對應座席。

呼叫中心中間件各功能組件介紹

1.4.2.1.自動語音應答系統(IVR)

我們提供的IVR系統是動態的，應用設計人員可以很輕松的修改語音流程。

我們提供了一種直觀的圖形化編輯工具----自動業務流程編輯器（下圖），客戶

可在應用編成器里自行設計自己的語音應答流程，設計人員只須將語音流程的步

驟組件從組件面板中拖放到主設計窗口，設置相應的屬性即可。修改后，一個叫

做應用引擎的流程實施工具將加載以文件形式存儲的語音流程文件。

如給IVR服務器配備傳真卡，IVR還可實現對客戶傳真訪問響應，通過自動

業務流程生成器還可實現傳真自動外撥服務，并且，IVR支持對任何關系型數據

庫的訪問和文本到語音的轉換（TTS）技術。

主設計窗

組件面板

1.4.2.2.智能話務排隊系統（ACD）

ACD也是呼叫中心中間中的一個重要組成部分，它也是一個純軟件的產品，

它運行于一臺獨立服務器上，對所有的座席進行實時監控、對來話進行智能排隊，

為了讓每一個訪問的客戶都能得到恰當的服務，需要按不同的策略分配話務至座

席，對呼叫中心內部的所有具備接待能力的座席進行分組、排隊，每次從隊列中

選出隊首，分配給當前呼叫用戶。

目前，系統提供多種座席排隊策略，比如，將所有座席按照空閑時間長短進

行排隊，每次選擇空閑時間最長的座席來接待當前的來話，或者按工作強度、技

能等級的順序進行分配，并可依據用戶需求訂制特殊排隊策略。

1.4.2.3.通用座席應用示例（AGET）

AGET是中間件產品中的座席應用接口模塊，它是連接客戶具體應用程序與

中間件其它產品的紐帶。通過AGET，系統集成應用開發商在開發座席應用程序

過程中無須投入太多的精力來實現復雜的座席端電話功能，可以把精力集中在具

體應用上，這樣能大大縮短開發的時間。

圖標說明：

狀態條

操作條

客戶信息記錄

分機號

置閑：表示座席員現在的狀態可以正常接電話，這時如有電話會分配到

該座席。

置忙：表示座席員現在正在接電話或處理別的事情，這時電話不會不會

被分配到該座席。

離席：表是座席員暫時不在作為上。

摘機：如有電話進來，按此鍵表示將電話接起來以進行通話。

掛機：當結束一個電話時，按此鍵掛斷電話。

外撥：往外撥電話。

外撥分機：如果往外打電話，而對方需要輸入分機號等按鍵提示時，按

此鍵。

呼叫轉移：接到一個電話后轉給其他的座席。

保持：在與某個客戶進行通話時，選此鍵后則客戶聽到背景音樂，而聽不

見座席員的聲音。

釋放：選此鍵后則客戶有可以與座席員正常對話。

1、登陸

（1）雙擊及運行桌面的快捷方式TelControl；彈開狀態條；

（2）在左側的紅箭頭處點右鍵，選“座席注冊”，在彈開的登陸界面上輸入用

戶名和密碼（通過E-mail方式告知），點確定登陸。

（3）在左側的紅箭頭處點右鍵，選“修改密碼”，在彈開的修改密碼界面上輸

入用新的密碼和確認密碼（最長為10位），點確定后下次登陸時新密碼生效。

（4）在左側的紅箭頭處點右鍵，選“座席復位”，可以在座席工具條的狀態非

正常時重新使狀態條的工作狀態恢復初試狀態，從而繼續正常工作。

（5）登陸后狀態條最上方蘭區域會顯示出該座席員的工號和姓名，以及最近

來電人的電話、聯系人、處理電話的次數。右冊的小框則顯示時間和該分機的號

碼。

（6）剛登陸后系統會自動默認為空閑狀態，這時如果有客戶打電話進來，服務

器會將電話分配給該座席。

2、接電話

（1）當有電話呼入的時候，狀態條如下，選“摘機”鍵可以接聽。該人的電話

號碼在上方蘭條框會顯示出來點號碼，如果以前該人已經來過電并做過記錄，

還會顯示出該人的姓名。

（2）摘機后，則可以和客戶進行通話，蘭狀態條會顯示通話時間。當摘機后，

該座席被標記為置忙狀態，再有電話近來服務器則不會分配給該座席。

（3）點開左側的紅箭頭，顯示客戶信息記錄條，如果該客戶已經做過記錄，則

會顯示出該用戶的記錄，可以點修改或刪除對該用戶信息進行操作。如果該用戶

未被登記，則先按“新建”鍵，然后可以在該欄下進行信息登記，登記后選保存

即可。

（4）當結束一個通話后，可以按“掛斷”掛斷電話。

掛斷鍵

（5）當一個電話被掛斷后，該座席默認為置忙狀態，因為在剛掛斷電話后，座

席員可能會做一些錄入之類的操作，因此，需要座席手動點一下“置閑鍵”以確

認自己可以接下一個電話。

置

3、轉移電話

置閑鍵

（1）當接到一個電話需要轉給其他座席人員，點一下轉移鍵，會彈開轉移窗口；

轉移

（2）在彈開的窗口下輸入要轉移的分機或從列表中選擇座席，按確定鍵，這時

將撥通對方的電話。

4、外撥電話

（1）先按“置忙鍵”，將座席狀態變為“忙”；

置忙

（2）在“置忙”狀態下點“外撥”鍵，在彈開的窗口輸入分機號碼，然后按確

定；

外撥

高級外

（3）在外撥電話窗口點“高級撥號”鍵，在彈出的窗口中進行高級的用戶號碼

查，選定用戶進行外撥。

（4）撥通后如果需要再次輸入分機號碼或雙音頻鍵，則選“撥雙音頻鍵”，在彈

開的窗口下輸入雙音頻即可；

撥雙音

通用狀態條由

網音提供

電話控制區

應用數據查詢區

1.4.2.4.座席全程錄音系統（REC）

錄音模塊REC可以對座席實行全程純軟件錄音方式，所有錄音記錄由錄音服

務器（班長席）集中管理，在錄音服務器上可進行錄音記錄的查詢、回放等，同

時也可實現對座席的進行實時監聽。IPT呼叫中心系統不需采用任何語音板卡，

這樣既降低了硬件投資成本，省去了錄音布線的麻煩與多故障根源，也大大提高

了錄音系統與呼叫中心的整合程度，提高了監控水平。這是國內第一套純軟件的

錄音實現方案，充分體現了IP呼叫中心系統的優勢。

主要優勢：

?純軟件，無須數字信號處理（DSP）卡，無須部署任何語音線路，從根本

上避免了傳統錄音解決方案中由于錄音線路松動而造成的無效錄音記錄

等故障，同時解決了語音板卡普遍存在錄音有所失真的現象；

?分散式錄音、集中式管理模式，避免了傳統錄音解決方案的集中式錄音

由于錄音服務器發生故障，而導致錄音系統整個癱瘓的狀況；

?支持IP應用環境，錄音服務器可置于IP網絡的任何地點；

?支持多個錄音站、多個錄音查詢站；

1.4.2.5.統計報表系統（REPORT）

REPORT支持各種統計報表輸出，直觀地反映出呼叫中心各個時間段內的各

種環節的具體運營情況，幫助管理人員進行決策。REPORT支持多種統計方式如：

IVR呼叫總量統計、平均座席服務時間統計、線路占用時間統計、座席話務量統

計、呼叫損失量統計、接通率統計，排隊占用時間統計等，另外REPORT還支持

用戶自行定義的統計模式。

數據統計管理系統在新的版本中做了很大的改動和完善，以下列出了一些功

能特點：

?統計結果的體現形式靈活多樣

系統將統計結果自動導入到Excel表格中，用戶可以方便靈活地生成各種

圖表

1.4.2.6.座席監管系統(MAAGER)

IPT呼叫中心提供了對系統各個部件的全面監視能力，提供了針對座席的多

種媒體的全面質檢能力，包括：

?提供了對各個核心部件的監視能力，可以查看系統的各個資源的占用，

直觀查看各個部件的運行狀況，收集各種運行參數。

?提供傳統的質檢，如強制置忙、強制置閑、強制插入功能，以及多種媒

體的全面攔截功能。

?提供班長對座席的錄制、回放功能。

?提供針對多種媒體的監視、監聽、錄制功能，能夠進行多種媒體的同步

回放。提供按業務類型對呼叫進行監聽的功能。

1.5.安裝測試方案

從廣泛意義上講，安裝、測試需要經過以下列性能測試，包括：壓力測

試、穩定性測試、負載能力測試和可擴展性測試等。在不同應用系統的性能測

試中，需要根據應用系統的特點和測試目的的不同來選擇具體的測試方法。

在性能測試中，壓力測試主要是為了獲取系統在較大壓力狀況下的性能表

現而設計并實現的，壓力測試主要是獲取系統的性能瓶頸和系統的最大吞吐

率。穩定性測試主要是測試系統的穩定性，即在不同情況下，系統仍能夠正常

運行。負載測試是測試系統的承受能力，測試其在大量并發情況下的運行情

況。而可擴展性測試指的是系統的擴展能力，即本系統跟其他系統直接的交互

對接能力以及本系統功能、性能等方面的擴展能力。

1.5.1.衡量系統性能的常見指標

一般來說，性能是一種指標，表明軟件系統或構件對于其及時性要求的符

合程度；其次，性能是軟件產品的一種特性，可以用時間來進行度量。

軟件系統常見的性能指標如下：

?響應時間（Responsetime）

響應時間就是用戶感受軟件系統為其服務所耗費的時間，對于網站系統來

說，響應時間就是從點擊了一個頁面計時開始，到這個頁面完全在瀏覽器里展

現計時結束的這一段時間間隔，看起來很簡單，但其實在這段響應時間內，軟

件系統在幕后經過了一系列的處理工作，貫穿了整個系統節點。根據“管轄區

域”不同，響應時間可以細分為：

（1）服務器端響應時間，這個時間指的是服務器完成交易請求執行的時

間，不包括用戶端到服務器端的反應（請求和耗費在網絡上的通信時間），這個

服務器端響應時間可以度量服務器的處理能力。

（2）網絡響應時間，這是網絡硬件傳輸交易請求和交易結果所耗費的時

間。

（3）用戶端響應時間，這是用戶端在構建請求和展現交易結果時所耗費的

時間，對于普通的瘦用戶端Web應用來說，這個時間很短，通常可以忽略不

計；但是對于胖用戶端Web應用來說，比如Javaapplet、AJAX，由于用戶端

內嵌了大量的邏輯處理，耗費的時間有可能很長，從而成為系統的瓶頸，這是

要注意的一個地方。

那么用戶感受的響應時間其實是等于用戶端響應時間+服務器端響應時間+

網絡響應時間。細分的目的是為了方便定位性能瓶頸出現在哪個節點上。

?吞吐量（Throughput）

吞吐量是常見的一個軟件性能指標，對于軟件系統來說，“吞”進去的是請

求，“吐”出來的是結果，而吞吐量反映的就是軟件系統的“飯量”，也就是系

統的處理能力，具體說來，就是指軟件系統在每單位時間內能處理多少個事務/

請求/單位數據等。但它的定義比較靈活，在不同的場景下有不同的詮釋，比如

數據庫的吞吐量指的是單位時間內，不同SQL語句的執行數量；而網絡的吞吐

量指的是單位時間內在網絡上傳輸的數據流量。吞吐量的大小由負載（如用戶

的數量）或行為方式來決定。舉個例子，下載文件比瀏覽網頁需要更高的網絡

吞吐量。

?資源使用率（Resourceutilization）

常見的資源有：CPU占用率、內存使用率、磁盤I/O、網絡I/O。

?點擊數（Hitspersecond）

點擊數是衡量WebServer處理能力的一個很有用的指標。需要明確的是：

點擊數不是我方通常理解的用戶鼠標點擊次數，而是按照用戶端向WebServer

發起了多少次http請求計算的，一次鼠標可能觸發多個http請求，這需要結

合具體的Web系統實現來計算。

?并發用戶數（Concurrentusers）

并發用戶數用來度量服務器并發容量和同步協調能力。在用戶端指一批用

戶同時執行一個操作。并發數反映了軟件系統的并發處理能力，和吞吐量不同

的是，它大多是占用套接字、句柄等操作系統資源。

另外，度量軟件系統的性能指標還有系統恢復時間等，其實凡是用戶有關

資源和時間的要求都可以被視作性能指標，都可以作為軟件系統的度量，而性

能測試就是為了驗證這些性能指標是否被滿足。

1.5.2.軟件性能的不同層面

通常，對軟件性能的關注是多個層面的：用戶關注軟件性能，管理員關注

軟件性能，產品的開發人員也關注軟件性能，這些不同的關注者所關注的“性

能”的具體內容也是不同的。因此，對于不同的人，軟件的性能標準也是不

同的，需要做不同的應對。

?用戶視角的軟件性能

從用戶的角度來說，軟件性能就是軟件對用戶操作的響應時間。說得更明

確一點，對用戶來說，當用戶單擊一個按鈕、發出一條指令或是在Web頁面上

單擊一個鏈接，從用戶單擊開始到應用系統把本次操作的結果以用戶能察覺的

方式展示出來，這個過程所消耗的時間就是用戶對軟件性能的直觀印象。下圖

以一個Web系統為例，說明了用戶的這種印象。

圖WEB系統的響應

必須要說明的是，用戶所體會到的“響應時間”既有客觀的成分，也有主

觀的成分。例如，用戶執行了某個操作，該操作返回大量數據，從客觀的角度

來說，事務的結束應該是系統返回所有的數據，響應時間應該是從用戶操作開

始到所有數據返回完成的整個耗時；但從用戶的主觀感知來說，如果采用一種

優化的數據呈現策略，當少部分數據返回之后就立刻將數據呈現在用戶面前，

則用戶感受到的響應時間就會遠遠小于實際的事務響應時間。

?管理員視角的軟件性能

從管理員的角度來看，軟件系統的性能首先表現在系統的響應時間上，這

一點和用戶視角是一樣的。但管理員是一種特殊的用戶，和一般用戶相比，除

了會關注一般用戶的體驗之外，他還會關心和系統狀態相關的信息。例如，管

理員已經知道，在并發用戶數為100時，A業務的響應時間為8秒，那么此時

的系統狀態如何呢？服務器的CPU使用是不是已經達到了最大值？是否還有可

用的內存？應用服務器的狀態如何？我方設置的JVM可用內存是否足夠？數據

庫的狀況如何？是否還需要進行一些調整？這些問題普通的用戶并不關心，因

為這不在他們的體驗范圍之內；但對管理員來說，要保證系統的穩定運行和持

續的良好性能，就必須關心這些問題。

另一方面，管理員還會想要知道系統具有多大的可擴展性，處理并發的能

力如何；而且，管理員還會希望知道系統可能的最大容量是什么，系統可能的

性能瓶頸在哪里，通過更換哪些設備或是進行哪些擴展能夠提高系統性能，了

解這些情況，管理員才能根據系統的用戶狀況制定管理措施，在系統出現計劃

之外的用戶增長等緊急情況的時候能夠立即制定相應措施，進行迅速的處理；

此外，管理員可能還會關心系統在長時間的運行中是否足夠穩定，是否能夠不

間斷地提供業務服務等。

因此，從管理員的視角來看，軟件性能絕對不僅僅是應用的響應時間這么

一個簡單的問題。

下表給出了管理員關注的部分性能相關問題的列表。

管理員關心的問題

服務器的資源使用狀況合理嗎

應用服務器和數據庫的資源使用狀況合理嗎

系統是否能夠實現擴展

系統最多能支持多少用戶的訪問？系統最大的業

務處理量是多少

系統性能可能的瓶頸在哪里

更換哪些設備能夠提高系統性能

系統能否支持7×24小時的業務訪問

?開發視角的軟件性能

從開發人員的角度來說，對軟件性能的關注就更加深入了。開發人員會關

心主要的用戶感受——響應時間，因為這畢竟是用戶的直接體驗；另外，開發

人員也會關心系統的擴展性等管理員關心的內容，因為這些也是產品需要面向

的用戶（特殊的用戶）。但對開發人員來說，其最想知道的是“如何通過調整設

計和代碼實現，或是如何通過調整系統設置等方法提高軟件的性能表現”，和

軟件性能描述

資源利用率

資源利用率

系統可擴展性

系統容量

系統可擴展性

系統可擴展性

系統穩定性

“如何發現并解決軟件設計和開發過程中產生的由于多用戶訪問引起的缺陷”，

因此，其最關注的是使性能表現不佳的因素和由于大量用戶訪問引發的軟件故

障，也就是我方通常所說的“性能瓶頸”和系統中存在的在大量用戶訪問時表

現出來的缺陷。

舉例來說，對于一個沒有達到預期性能規劃的應用，開發人員最想知道的

是，這個糟糕的性能表現究竟是由于系統架構選擇的不合理還是由于代碼實現

的問題引起？由于數據庫設計的問題引起？抑或是由于系統的運行環境引發？

或者，對于一個即將發布到現場給用戶使用的應用，開發人員可能會想要

知道當大量用戶訪問這個系統時，系統會不會出現某些故障，例如，是否存在

由于資源競爭引起的掛起？是否存在由于內存處理等問題引起的系統故障？

因此，對開發人員來說，單純獲知系統性能“好”或者“不好”的評價并

沒有太大的意義，他們更想知道的是“哪些地方是引起不好的性能表現的根

源”或是“哪里可能存在故障發生的可能”。

下表給出了開發人員關注的部分性能相關問題的列表。

開發人員關心的問題

架構設計是否合理

數據庫設計是否存在問題

代碼是否存在性能方面的問題

系統中是否有不合理的內存使用方式

系統中是否存在不合理的線程同步方式

系統中是否存在不合理的資源競爭

問題所屬層次

系統架構

數據庫設計

代碼

代碼

設計與代碼

設計與代碼

1.5.3.系統測試目標

通過對定制系統進行單元測試、與業務系統組合后的系統測試以及用戶現

場業務模擬測試三個階段，對功能正確性、可靠性、易用性、安全性、系統性

能等進行測試，為濰坊市某區委宣傳部民生熱線服務系統順利上線并運行、后

期維護提供可靠、安全的質量保障。

1.5.4.系統測試流程

1.5.5.系統應用測試

1.5.5.1.功能測試

功能測試主要在單元集成測試階段完成，目的是確保測試的功能正常，如

數據輸入，處理、查詢是否正確，以及業務規則是否恰當。即對交互的輸出或

結果進行分析，以此來核實系統所涉及到的各模塊的工作正常。

1、測試目標

單元測試完成，確保為濰坊市某區委宣傳部民生熱線服務系統定制開發系

統各功能及業務流程正常等。

2、測試方法及要點

整體各功能點測試基于黑盒方法，通過圖形用戶界面與應用程序交互并分

析輸出結果來驗證應用程序及其內部進程。利用有效的和無效的數據執行各用

例、用例流或功能，核實以下內容：

?在使用有效數據時得到預期的結果。

?在使用無效數據時顯示相應的錯誤消息或警告消息。

?各業務規則都得到了正確的應用。

3、完成標準

?所計劃的測試已全部執行。

?所發現的缺陷已全部解決或遺留的缺陷給出解決方案。

1.5.5.2.接口測試

用于驗證濰坊市某區委宣傳部民生熱線服務系統與其他業務系統間的交互

是否正常，確保本系統與其他系統數據傳遞的正確性。

1、測試目標

驗證本管理平臺內部模塊之間以及跟其他業務系統間數據傳遞的正確性。

2、測試方法及要點

通過該管理平臺傳遞到其他業務系統中的數據，驗證功能及數據正確性。

通過其他業務系統傳遞到該管理平臺中，驗證數據傳遞及回寫正確性。

3、完成標準

各接口數據傳遞正確。

1.5.5.3.易用性測試

驗證各功能用戶操作體驗及易用性，確保各種瀏覽以及各種訪問方法（鼠

標移動、快捷鍵等）都使用正常，確保窗口對象及其特征（菜單、大小、位

置、狀態和中心），各功能說明及提示信息都符合標準。

1、測試目標

驗證濰坊市某區委宣傳部民生熱線服務系統是否符合《我方軟件產品易用

性規范及指南》，主要包括頁面大小是否合適，布局是否合理，顏搭配是否易

于接受，鏈接功能是否正常，提示信息正確、易理解。

2、測試方法及要點

測試人員依據《我方軟件產品易用性規范及指南》對定制系統各功能點逐

一驗證。

3、完成標準

確保各功能窗口都達到需求，符合《我方軟件產品易用性規范及指南》。

1.5.5.4.性能測試

主要驗證定制開發系統對響應時間、事務處理速率和其他與時間相關的需

求進行評測和評估。性能評測的目標是核實性能需求都已滿足。

1、測試目標

驗證定制開發系統常用、重點業務功能在以下情況下的性能行為：

?正常的預期工作量。

?預期的最繁重工作量。

?測試用戶對服務器訪問的反應時間。

?大數據量的各功能的單點性能測試。

2、測試方法及要點

?通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務的迭代次

數。

?腳本應該在一臺計算機上運行（最好是以單個用戶、單個事務為基準），并在多

臺用戶機（虛擬的或實際的用戶機，請參見下面的“需考慮的特殊事項”）上重

復。

?通過創建“虛擬的”用戶負載來模擬許多個（通常為數百個）用戶機。

?使用多臺實際用戶機（每臺用戶機都運行測試腳本）在系統上添加負載。

3、完成標準

?單個事務或單個用戶：在每個事務所預期或要求的時間范圍內成功地完成測試

腳本，沒有發生任何故障。

?多個事務或多個用戶：在可接受的時間范圍內成功地完成測試腳本，沒有發生

任何故障。

1.5.5.5.壓力測試

從負載測試，強力測試以及壓力測試等方面，測試定制開發系統在給定時

間內能夠持續處理的最大負載或工作量（包括長時間處理多個用戶相同的且性

能最壞的業務）；確定并確保系統在超出最大預期工作量的情況下仍能正常運

行，并評估其性能特征，包括響應時間、事務處理速率和其他與時間相關的內

容。

1、測試目標

測試定制開發系統正常工作時，能夠承受的最大并發用戶達到濰坊市某區

委宣傳部民生熱線服務系統要求的并發數量，且系統能夠正常工作。

?正常的預期工作量。

?預期的最繁重工作量。

?測試用戶對服務器訪問的反應時間。

?大數據量的各功能的單點性能測試。

2、測試方法及要點

?用腳本模擬并發用戶數量，同時對系統進行訪問，逐步增大模擬的用戶數，測

試直到系統出現故障為止。

?在濰坊市某區委宣傳部民生熱線服務系統要求的并發用戶數量下，測試服務器

能夠正常運行的時間。

?減少或限制服務器的內存，增加并發用戶數量。

3、完成標準

?達到濰坊市某區委宣傳部民生熱線服務系統所要求的并發用戶數時，定制開發

系統運行正常，服務器不會出現故障，可以正常工作，檢查其性能指標是否符

合要求。

1.5.5.6.安全保密測試

確保定制開發系統的安全性，各人員權限控制正確，并確認系統是否有超

時的限制，相關的重要信息是否寫進日志、是否可追蹤，測試加密是否正確，

信息是否完整。

?系統認證鑒別管理

1、測試目標

通過系統認證鑒別管理測試，檢查定制開發系統是否符合認證方式、口令

復雜度、登錄失敗控制、空閑重鑒別控制以及密碼定期更換控制等安全保密要

求。

2、測試方法及要點

?系統登錄認證方式選擇，復雜口令錄入設置，以及登錄重鑒別控制設置等。根

據設置的認證方式進行登錄檢查，驗證口令是否符合安全保密要求。

?系統需具有基本的“賬號/密碼”驗證方式。

?用戶設置密碼時，系統強制位數要達到機關事務管理局要求，且需是復雜組合

（即大小寫英文字母、數字、特殊字符三種字符中的兩者以上組合而成）的密

碼。

?登錄密碼強制要求規定時間內至少修改一次，如不修改密碼則不允許訪問其它

功能。可以設置修改密碼不能重復的次數。

?登錄密碼在存儲和傳輸過程中都以加密方式存在。

?用戶身份鑒別成功后，當其空閑操作的時間超過規定值（通常為10分鐘）后，

本系統會要求對該用戶重新進行身份鑒別。

?當用戶身份鑒別嘗試連續五次失敗時，本系統會對該賬號實行凍結，再由專門

的系統管理員進行解凍。如身份鑒別成功，則重新進行次數累計。

?安全保密員能夠為指定的賬號重置登錄密碼，任何人都無法查閱登錄密碼的原

文。

3、完成標準

以上測試要點實現并控制正確。

?安全審計日志管理

1、測試目標

通過安全審計日志測試，檢查定制開發系統是否具有完整、可追溯的日志

記錄，保障系統的安全可靠。

2、測試方法及要點

安全審計員可以通過日志審計功能根據授權查看相應的操作記錄。

1）系統具有完整、可追溯的日志記錄：

?每條日志記錄都按照時間順序編制順序號，從而保證完整性。

?在日志中記錄各種相關信息以保證其可追溯性。

?人員信息：操作人員的賬號；所使用的機器的IP地址。

?時間信息：操作發生的日期和時間。

?操作內容：所訪問的功能模塊，具體的功能點，必要時還要記錄所操作的具體

內容（比如創建賬號的操作，就要記錄所創建的是哪個賬號）。

2）應在日志中進行記錄的事項包括：

?使用人員進入、退出系統。

?使用人員在系統中進行的各項操作（增、刪、改、查等等）。

3）對系統日志中諸如人員、日期、時間、IP地址、功能模塊、操作內容

等等的分類檢索、排序、數據輸出等。支持以下查詢條件以及“邏輯與”組

合：

?日期和時間范圍。

?所操作的功能模塊名稱。

?操作的類型名稱。

4）系統日志的管理同樣受制于系統權限控制，除安全審計員以外，其他用

戶不能訪問日志信息。

5）安全審計員可以對系統日志進行審計，并可以將日志以XLS文件形式導

出。安全審計員不能進行其他與日志無關的操作。

3、完成標準

以上測試要點實現并控制正確。

?關鍵信息防篡改

1、測試目標

定制開發系統涉密信息在傳輸、存儲過程中的可靠性。

2、測試方法及要點

?涉密信息傳輸過程中以密文傳輸，存儲在數據庫以密文存儲并不允許非法篡改

?數據傳輸防篡改。

?數據庫（存儲）防篡改。

3、完成標準

以上測試要點實現并控制正確。

1.5.5.7.故障恢復測試

確保系統能從各種意外數據損失或完整性破壞的各種軟/硬件故障中恢復包

括：用戶/服務機斷電，網絡通信中斷，異常關閉某個功能，錯誤的操作順序

1、測試目標

?確保恢復進程（手工或自動）將數據庫、應用程序和系統正確地恢復到了預期

的已知狀態。測試中將包括以下各種情況：

?用戶機斷電。

?服務器斷電。

?通過網絡服務器產生的通信中斷。

?周期未完成（數據過濾進程被中斷，數據同步進程被中斷）。

?數據庫指針或關鍵字無效。

?數據庫中的數據元素無效或遭到破壞。

2、測試方法及要點

?用戶機斷電：關閉PC的電源。

?服務器斷電：模擬或啟動服務器的斷電過程。

?通過網絡服務器產生的中斷：模擬或啟動網絡的通信中斷（實際斷開通信線路

的連接或關閉網絡服務器或路由器的電源）。

?一旦實現了上述情況（或模擬情況），就應該執行其他事務。而且一旦達到第二

個測試點狀態，就應調用恢復過程。

?在測試不完整的周期時，所使用的方法與上述方法相同，只不過應異常終止或

提前終止數據庫進程本身。

?對以下情況的測試需要達到一個已知的數據庫狀態。當破壞若干個數據庫字

段、指針和關鍵字時，應該以手工方式在數據庫中（通過數據庫工具）直接進

行。其他事務應該通過使用“應用程序功能測試”和“業務周期測試”中的測

試來執行，并且應執行完整的周期。

3、完成標準

在所有上述情況中，應用程序、數據庫和系統應該在恢復過程完成時立即

返回到一個已知的預期狀態。

1.5.5.8.配置和兼容性測試

1、測試目標

測試該系統可在濰坊市某區委宣傳部民生熱線服務系統項目要求的硬件和

軟件配置中正常運行。在各種瀏覽器下工作正常。

2、測試方法及要點

?在測試過程中或在測試開始之前，打開各種與非測試對象相關的軟件（例如

Microsoft應用程序：Excel和Word），然后將其關閉。

?執行所選的事務，以模擬主角與測試對象軟件和非測試對象軟件之間的交互。

?用戶端操作系統，系統軟件兼容性測試。

3、完成標準

對于測試對象軟件和非測試對象軟件的各種組合，所有事務都成功完成，

沒有出現任何故障。

1.5.5.9.系統集成測試

1、測試目標

集成測試的主要目標是檢測濰坊市某區委宣傳部民生熱線服務系統所涉及

的應用支撐平臺、定制開發系統的集成是否達到要求，對業務流程及數據流的

是否可以平滑處理，檢測各個系統之間業務流處理是否存在邏輯不嚴謹及錯

誤，并對全部功能進行回歸測試。

2、測試方法及要點

利用有效的和無效的數據來執行各個用例、用例流或功能，以核實以下內

容：

?在使用有效數據時得到預期的結果。

?在使用無效數據時顯示相應的錯誤消息或警告消息。

?各業務規則都得到了正確的應用。

?各系統直接數據流傳遞正確。

3、完成標準

濰坊市某區委宣傳部民生熱線服務系統可以穩定運行。

1.5.6.業務模擬測試

1.5.6.1.業務模擬測試流程

圖業務模擬測試流程

1.5.6.2.業務模擬測試組織

圖業務模擬測試組織

1.5.6.3.業務模擬測試過程

測試經理與項目經理、實施經理溝通制定業務模擬測試計劃、確定業務模

擬測試環境。

測試人員、實施人員依據項目實施方案，以用戶基礎數據、業務表單、業

務操作流程，形成本次業務模擬測試用例集，并提交用戶確認。

測試執行：由測試人員、實施人員、用戶代表組成測試團隊按業務模擬測

試計劃，依據業務模擬測試用例集驗證我方平臺產品與定制開發系統滿足項目

實施方案。

業務模擬測試發現的缺陷，必須24小時響應解決。

測試結果統計：測試經理依據項目要求，按時匯總、分析業務模擬測試情

況，編制業務模擬測試進展報告及最終的業務模擬測試報告。

業務模擬測試完成，系統可以上線試運行。