一些測試的心得

0事務爲衡量服務器的性能,需要定義事務。 LoadRunner運行到該事務的開始點時,LR就會開始計時,直到運行到該事務的結束點,這個事務的運行時間在結果中會有反映。集合點(Rendezvous)
00 插入集合點是爲了衡量在加重負載的情況下服務器的性能情況。 在測試計劃中,可能會要求系統能夠承受1000 人同時提交數據,在LR 中可以通過在提交數據操作前面加入集合點,當虛擬用戶運行到提交數據的集合點時,LR 就會檢查同時有多少用戶運行到集合點,從而達到測試計劃中的需求。
000 集合點經常和事務結合起來使用。集合點只能插入到Action 部分,vuser_init和vuser_end中不能插入集合點00
01 (Text/Image)檢查和contents check點 在進行壓力測試時,爲了檢查Web 服務器返回的網頁是否正確,這些檢查點驗證網頁上是否存在指定的Text 或者Image,還可以測試在比較大的壓力測試環境中被測的網站功能是否保持正確。
1 使用LOADRUNNER時系統的瓶頸:1 CPU限制vmstat, 當%user|%sys超過80%時 2 磁盤I/O限制vmstat,當iowait超過40%時 3 應用磁盤限制 虛擬內存空間少 當%tm_act超過70%時,當分頁空間的活動率超過70%時 4 換頁限制,系統失效 虛擬內存邏輯卷超過I/O的30%,激活的虛擬內存率超過CPU數量的10倍時,頁交換增大,CPU等待並運行隊列
2 (1)監視服務器資源? 在Controller的場景運行中,在Graphs中選中System Resource Graphs下Windows Resources節點,點擊Windows Resources的右鍵菜單項add measurements,加入你要監視的機器名稱。注意監視的服務器必須啓動Remote Registry Service。(2)找不到設置多IP運行方式 必須在Cotroller中設置Expert Mode才能設置多ip方式。(3)分析結果中如何處理think time  Analysis 可以設定 Filter,Filter 就可以把 think time 過略掉。
3 使用loadrunner完成測試分爲四個步逐:1 創建虛擬用戶腳本,包括創建腳本->選擇協議->錄製腳本->編輯腳本->檢查腳本是否有錯2 使用中央控制器來調度虛擬腳本,包括創建場景,->選擇腳本->設置虛擬用戶數->設置schedule進度表 3 運行腳本 分析scenario  4 分析測試結果
手機軟件:第一層次是Operating System(OS,操作系統),主要與RF(射頻信號)芯片進行溝通與指令處理,它基於一些基礎的網絡協議(如GSM、GPRS或CDMA、W-CDMA)等;第二層次是內置的手機本地應用,例如電話簿、短信息等內容,更爲重要的是,在一些手機上已經集成了J2ME開發平臺,即它可以運行第三方開發的應用程序;第三層次是在J2ME平臺上開發的一些KJava應用程序(如各種遊戲、圖片瀏覽等),還有一些API的接口函數,可以同外部的PC通過線纜進行數據傳送,也可以通過無線方式與外界應用服務提供商傳遞數據。
4 就OS而言,由於硬件設備(主要是芯片)是不同的,因此各個廠商都擁有自己的操作系統,現在還不完全開放。目前主流的操作系統有Symbian、Linux、Win-CE等。中間的KVM平臺基本上是開放的,國際上通行的是J2ME MIDP1.0 標準,只要大家都遵照這個標準,就可以保證最上層的開放性。但在這一層,因爲手機的鍵盤或觸屏方式等設備功能是不同的,各個廠商及不同型號的手機在接口方面有一些差異。最上面的應用層是比較開放的,使用KJava這種開放的語言,第三方也可以進行手機應用軟件的開發。
PIN碼(PIN1)就是SIM卡的個人識別密碼。如果啓用了開機PIN碼,那麼每次開機後就要輸入4位數PIN碼,PIN碼是可以修改的,用來保護自己的SIM卡不被他人使用。需要注意的是,如果輸入三次PIN碼錯誤,手機便會自動鎖卡,並提示輸入PUK碼解鎖,這個時候已經接近了危險的邊緣,因此,如果擅自修改了PIN碼,一定要牢記。 PIN2碼是設定手機計費時使用的。如果輸入三次錯誤,手機會需要用PUK2碼解鎖,過程與先前介紹的PIN碼、PUK碼相同。不過這兩種密碼與網絡計費及SIM卡內部資料的修改有關,所以不會公開,而且即便PIN2密碼鎖死,也不會影響手機的正常使用。因此,PIN2碼和PUK2碼不必去刻意理會。  PUK碼(PUK1)由8位數字組成,這是用戶無法更改的。當手機PIN碼被鎖,並提示輸入PUK碼時,千萬不要輕舉妄動,因爲PUK碼只有10次輸入機會,10次都輸錯的話,SIM卡將會被永久鎖死,也就是報廢。
6  POP服務器會將用戶郵箱中的郵件下載到客戶端的計算機中,同時會在服務器端刪除郵件(可以設置不刪除)。用戶可以離線閱讀郵件。 IMAP協議在驗證身份後,並不把所有的郵件直接下載到本地,而是下載郵件的一個摘要,用戶在閱讀摘要決定是否下載郵件,還是在服務器端就對郵件進行處理。IMAP支持三種操作模式:離線模式、在線模式和中斷連接模式。
7 軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不同測試策略也不同。 用戶認證安全的測試要考慮問題:明確區分系統中不同用戶權限 系統中會不會出現用戶衝突  系統會不會因用戶的權限的改變造成混亂用戶登陸密碼是否是可見、可複製 是否可以通過絕對途徑登陸系統(拷貝用戶登陸後的鏈接直接進入系統)用戶退出系統後是否刪除了所有鑑權標記,是否可以使用後退鍵而不通過輸入口令進入系統 系統網絡安全的測試要考慮問題 測試採取的防護措施是否正確裝配好,有關係統的補丁是否打上 模擬非授權攻擊,看防護系統是否堅固 採用成熟的網絡漏洞檢查工具檢查系統相關漏洞(即用最專業的黑客攻擊工具攻擊試一下,現在最常用的是 NBSI 系列和 IPhacker IP ) 採用各種木馬檢查工具檢查系統木馬情況 採用各種防外掛工具檢查系統各組程序的外掛漏洞 數據庫安全考慮問題:系統數據是否機密(比如對銀行系統,這一點就特別重要,一般的網站就沒有太高要求)系統數據的完整性(我剛剛結束的企業實名覈查服務系統中就曾存在數據的不完整,對於這個系統的功能實現有了障礙)系統數據可管理 系統數據的獨立性系統數據可備份和恢復能力(數據備份是否完整,可否恢復,恢復是否可以完整)
8 關聯腳本  關聯目的是爲了讓你在一個併發中用到一個商業流程的結果,在web腳本中有這樣的過程,從web腳本中sessionid關係到後面的流程能不能運行,winsock腳本有同樣的問題。所以需要捕獲到session id然後把它關聯起來在一個典型的web腳本中,你用web_create_html_param函數,用“PID“ 和“q2”定義邊界撲獲數據。 在Winsock腳本中,用lrs_save_param函數從靜態數據或收到的數據包中截獲數據
9  web_find函數。找到要截取的腳本
10 壓力測試/負載測試  按照設計連接的客戶端連接數量進行測試,把應用服務器處理請求的設計頻度增加1-10倍,分別測試出現錯誤的狀態和和出現錯誤的比率,考察是否出現不可恢復錯誤,系統設計要考 慮出現嚴重錯誤情況下負荷減輕錯誤自動恢復的實現方法。 在測試過程中每隔一段時間記錄一次計算機或者服務器的內存及CPU使用情況,包括被測程序的內存佔用百分比、數據庫管理系統的內存佔用百分比、操作系統的內存佔
11  LoadRunner transaction(事務)”用於度量一個或者多個業務流程的性能指標,如登陸或者提交或者多用戶使用等,或者下訂單使用 LoadRunner transactions(事務)可以度量: 業務流程中每一步所花費的時間 整個業務流程所花費的時間 業務流程中每一步的性能指標可以自動度量
12  壓力測試前需要蒐集和準備哪些資料  首先要對系統使用信息的分析 包括(1)任務分配圖 有哪些任務?同一時間內有多少次操作? 事務統計文件 事務平均值、和峯值是多少? 數據庫連接是多少? 如果任務失敗會產生多少業務風險? 用戶統計文件 每個真實用戶會執行多少任務? 不同任務在每個真實用戶中的分配比例?
13  我對腳本中的一個變量進行參數化,共10條數據。運行時有100個虛擬用戶,那我參數化的時候應該做怎樣的設置, 答: 可以將參數類型定義爲FILE(文件)類型,連接數據庫取得數據,在參數屬性頁面中可以設置,如更新值時間的選擇:每次迭代選擇下一行中設置選擇:順序這樣的效果是這樣的:所有的vuser在第一次迭代中用的都是第一條數據,在第二次迭代中用的是第二條數據
14 判斷LoadRunner返回的頁面是否正確  驗證的方法是從返回的頁面中查找關鍵的字符串,如果能找到,則說明系統行爲正確。當然,我們不可能手工去完成這個工作,因此,在實際工作中,我們藉助於LR的一個函數web_reg_find來完成這個工作。web_reg_find的具體使用可以查看LR的Function Reference文檔,這裏簡單描述一下幾個要點。
15 controller顯示聯機監視器的最多數量是16個
16 打開:開始-〉程序-〉loadrunner-〉tools-〉ip wizard  說明:如果想增加新IP選擇第一項; 使用保存的文件增加IP選擇第二項; 釋放已經設置的IP選擇第三項。點“下一步” 此步讓輸入web server的IP地址(尚不清楚有何意義),不輸入,直接點‘下一步’,說明:使用remove按鈕可以刪除選定的虛擬IP ,點add按鈕
17  用telnet <MI> 443互測服務監視器與MI的443端口是否打開
18  函數賦值時不能使用關係運算符“==”來比較兩個字符串,只能用strcmp() 函數來處理
19  在“監視服務器配置”中,要同時添加幾個服務器可用逗號分隔服務器名或IP範圍。如:255.255.255.0-255.255.255.5,server1,server219  
20  爲了不讓出錯後停止繼續運行:  Run-time Settings->Error Handing->Continue on error.
21  一般要保留10%的可用內存。最低最低不能<4M,此值過小可能是內存不足或內存泄漏Page Faults/sec、Pages Input/sec、Page Reads/sec     注(重要):導致嚴重的延遲原因:是因爲硬件分頁錯誤。     說 明: Page Faults/sec 是指處理器處理錯誤頁的綜合速率。Pages Input/sec 指爲解決頁錯誤從磁盤上讀取的頁數  Page Reads/sec 是指爲解析硬頁錯誤而讀取磁盤的次數 Processor錯誤,處理器一般情況下速率小於90%,如果大於則處理器性能不能滿足需求   Avg. Disk Queue Length 指讀取和寫入請求(爲所選磁盤在實例間隔中列隊的)的平均數。正常值<0.5,此值過大表示磁盤IO太慢  網絡容量、等待時間及帶寬  分析關鍵應用程序的性能 ,定位問題的根源是在客戶端、服務器、應用程序還是網  哪些應用程序佔用大量帶寬  服務器在受壓情況下,cpu最佳佔用率爲60%~80%,多了cpu受不了,少了資源浪費;
5、服務器在不受壓情況下,內存佔用率最佳爲25%,多了影響服務器性能;
壓力負載測試中也需要注意:
22 如何監視服務器資源輸入要監控性能的機器ip,如//111.111.111.111 .在彈出的登陸窗口輸入那臺機器的管理員帳戶和密碼 .運行CONTROLLER添加那臺機器的性能指標後就可以監控到了
23  如果Process/Private Bytes計數器和Process/Working Set計數器的值持續升高  同時Memory/Available bytes計數器的值缺卻持續降低的話 說明很有可能是存在內存泄漏
24  一般在吞吐量最大時,也就是事務響應時間最長的時候
25  監視服務器資源?在Controller的場景運行中,在Graphs中選中System Resource Graphs下Windows Resources節點,點擊Windows Resources的右鍵菜單項add measurements,加入你要監視的機器名稱。注意監視的服務器必須啓動Remote Registry Service
26  找不到設置多IP運行方式  必須在Cotroller中設置Expert Mode才能設置多ip方式
27   分析結果中如何處理think time  Analysis 可以設定 Filter,Filter 就可以把 think time 過略掉。
28 tracert IP地址或主機名 [-d][-h maximumhops][-j host_list] [-w timeout]  參數含義:  -d 不解析目標主機的名字;
-h maximum_hops 指定搜索到目標地址的最大跳躍數;  -j host_list 按照主機列表中的地址釋放源路由;  -w timeout 指定超時時間間隔,程序默認的時間單位是毫秒。
29  netstat [-r] [-s] [-n] [-a]  參數含義:  -r 顯示本機路由表的內容;  -s 顯示每個協議的使用狀態(包括TCP協議、UDP協議、IP協議);  -n 以數字表格形式顯示地址和端口;  -a 顯示所有主機的端口號。
30  性能測試過程中如何需要記錄什麼數據?
性能測試過程中,根據性能測試的不同類型和不同目標,記錄的數據也不同。例如,對於一個以調優爲目的的性能測試,可能需要重點關注測試過程中各可能的性能制約點(例如磁盤IO、網絡擁塞狀況、服務器內存使用情況、數據庫使用情況等),通過對參數調整後的系統進行反覆測試來找到制約性能的因素;而一個以驗證爲目的的性能測試可能會重點關注是否能達到性能指標要求,重點集中在用戶體驗上。
31 時間設置  Run Logic: 重複的數目 Øacing:在每次循環時的等待時間ØThink Time:在每個步驟間用戶的思考時間Log:記錄在回放時的各種信息
32如何看腳本運行選擇Tools > General Options, 選擇Display標籤  選擇Show browser during replay 和 auto arrange window 選項,清除腳本執行選項末端的Display report選項 單擊Run按鈕
33如何知道測試是否通過  選擇 View > Test Result 可以看到所用時間及執行結果
34如何查找過濾結果(錯誤結果)展開循環分支  展開第一個分支,然後點擊左側面板中的”+”號展開動作摘要分支。在展開的分支中你可以看到在循環中的每個步驟。展示結果鏡像 選擇Submit Form. 在結果窗口中顯示了那個相關步驟的回放鏡像  查看這個步驟摘要  結果窗口右上側的面板顯示了該步驟的信息摘要:對象或者步驟名。頁面是否正確加載等信息,結果(Passed, Failed, Done, 或者 Warning),以及該步驟的執行時間
35幾種場景類型的選擇  錄製好腳本之後,就可以把腳本加入到場景裏面去了,這裏首先介紹一下LR的場景類型,LR有2種大的場景類型:  1. Manual Scenario:該項要完全手動的設置場景,可以設置爲每一個腳本分配要運行的虛擬用戶的百分比,可在Controller的Scenario菜單下設置。2. Goal—Oriented Scenario:如果測試計劃是要達到某個性能指標,比如:每秒多少點擊,每秒多少transactions,能到達多少VU,某個Transaction在某個範圍VU(500-1000)內的反應時間等等,那麼就可以使用面向目標的場景。

1 快照顯示執行步周後的客戶端窗口顯示內容或情況
2 每次回放文件時VUGEN(虛擬用戶生成器)把快照放到SCRIPT文件中,擴展名爲.inf,回放腳本位於ITERATION中
3 Vuser腳本函數分兩種 1 常規腳本函數(ir_start_transition(標記事務開始) ir_end_transition(標記事務結束)) 2 基於協議的腳本函數(),他們共同構成了Vuser API,該API可以直接與服務器通信
4 數據庫協議格式(ird.h) FTP協議格式(mic_ftp.h) 常規C函數(irun.h) POP3(mic_pop3.h) SMTP(mic_smtp.h) WAP(as_wap.h) WEB(as_web.h) WINDOWS套接字(irs.h)
5 錄製部分(除WEB服務,C和不可錄製的協議外)包含兩部分:錄製應用程序和錄製概要
6 事務編輯器使用規則:1事務必須開始和結束於單個操作,不能跨越多個操作2事務名必須是唯一的3 要更改事務的起始點,將事務起始點括號移至新位置,結束點同 4 在事務中可以創建事務,稱嵌套事務
7 設置負載的步逐1 迭代 (要指定迭代次數使用F4打開運行時設置,選擇運行邏輯節點,指定迭代次數)2併發用戶(使用loadrunner->controller創建場景的過程,在場景中可以指定併發用戶的個數,也可以查看系統在併發用戶下行爲)
8 錄製腳本包括三部分Vuser_int(登陸信息,執行時間:Vuser初始化) action(客戶活動 執行時間:Vuser運行時) Vuser_end(註銷信息 執行時間:Vuser完成或停止)
9 選擇生成代碼的腳本 ->單擊腳本選項 指定端口信息->單擊端口映射
10 如果啓用了出現錯誤時仍繼續,則在出現錯誤後,腳本仍然會被執行,若對特定的腳本出錯了仍繼續則使用 ir_continue_on_error()將其括起來
11 同步VuserTE_wait_cursor 等待光標在窗口的指定位置出現 TE_wait_silent 以指定秒數等待用戶應用程序的靜默 TE_wait_text 等待字符串在指定的位置出現 ir_think_time 模擬用戶思考時間(手動添加思考時間語句:插入->添加步住-> 選擇思考時間->輸入思考時間)
  12 ir_get_attrib_double 檢雙精度浮點型變量索ir_get_attrib_long 檢索長整形變量ir_get_attrib_string 檢索字符串變量
13 設置端口映射錄製選項步逐: 打開錄製選項->選擇 網絡:端口映射->新建項(打開服務器項)->在套接字服務部分輸入服務ID,服務類型,目標服務器,目標端口和連接類型
14 在LR中可以定義事務來度量服務器的性能,每個事務度量服務器響應指定Vuser請求所用的時間
15 執行負載測試時,需要模擬系統上有較重任務的負載,可以通過創建集合點配製多個Vuser同時執行操作,當到達指定要求時釋放所有的Vuser,然後進行操作(插入集合點步逐:插入->集合->鍵入集合點名稱->)
16 創建文件或表類型參數時,必須創建一個.dat文件以存儲數據,或打開一個現有文件,然後定義參數的其他屬性(如參數類型文件路徑,參數名等)
17 從Vuser創建場景 工具->創建controller場景,將打開創建場景對話框,選擇面向目標的場景或手動場景,面向目標場景中LR將根據指定目標自動創建場景,手動場景中需要指定虛擬用戶數量,在負載生成器中輸入要運行的虛擬用戶的計算機的名稱,手工場景中具有共同特徵的用戶將組織成組,需要在組名框中指定一個新組名,而面向目標的場景需要指定腳本名,在結果目錄框中輸入要保存結果的位置
18 怎樣使多臺測試機均能對系統施壓: 默認模式下使用控制功能(controller) 添加多臺虛擬機時真正起作用的只有一臺,爲使多臺同時對系統施壓我們要把組 模式改爲百分比模式(選擇場景下的改變組模式爲百分比模式),然後在生成負載 選香裏邊同時選中所有機器
19 LR性能參數解析:WEB資源參數 每秒點擊次數:虛擬用戶每秒向WEB服務器提交的HTTP請求數,吞吐量:按運行過程中服務器上每秒的吞吐量(表示虛擬用戶在任何給定的一秒從服務器上獲得的數據量)每秒HTTP響應數,每秒下載頁面數,每秒重試次數,每秒TCP/IP連接數,依據這些來評估虛擬用戶產生的負載量
20 系統性能分析命令: 監視CPU使用情況(vmstat 2;iostat -t 26;sar -PALL23;)監視內存使用情況(vmstat 2 10; ps aux;svmon -Pau 10;)監視I/O使用情況iostat 5;sar -d 33)監視網絡使用情況:netstat -i;netstat  m;netstat –v 21 NGOSS  NGOSS從系統(即插即用規則)、過程(企業事務過程模型)、信息(關聯處理公用數據)、產品四個方面保證OSS體系具備標準化、能夠逐步演化、保證互連互操作(開放)、實現端到端的管理和高度自動化的特點。 NGOSS目標是建立一種以構件爲基礎的分佈式系統結構以及一套關鍵的系統服務,保證OSS具備標準化、能夠逐步演化、保證互連互通、實現端到端的管理等特點。NGOSS關注的是運營系統和軟件,注重通過軟件來實現業務流程的自動化,它強調包含有文檔、模型和代碼等知識庫的創建,側重於業務流程和信息模型的定義、系統框架的定義、合作催化試點項目的實施等關鍵元素。
22 手機測試:1、壓力測試 用自動測試軟件連續對手機撥打1000/10000個電話,檢查手機是否會發生故障。2、抗摔性測試 還仿真人把手機拋到桌面,拋上幾百次看會不會壞,而手機所用的電池,也要經過最少4m的高度,單獨的向着地面撞擊跌落100次而不能有破裂的情況出現。 3、高/低溫測試 讓手機處於不同溫度環境下測試手機的適應性,低溫一般在零下20攝氏度,高溫則在80攝氏度左右。 4、高溼度測試 用一個專門的櫃子來作滴水測試,仿真人出汗的情況(水內滲入一定比例的鹽分),約需進行30個小時。 5、性能測試 用鉛筆在手機外殼上畫很多格子,看看手機的外殼是否會掉下油漆,有些要求更嚴格的手機,會在手機的外殼上再塗抹上一些“名牌”的化妝品,看看是否因有不同的化學成分而將手機的油漆產生異味或者掉漆的可能。 6、翻蓋可靠性測試 對翻蓋手機進行翻蓋10萬次,檢查手機殼體的損耗情況,是用一部翻蓋的仿真機來進行,它可以設置翻蓋的力度、角度等 7、扭矩測試 直機用夾具夾住兩頭,一個往左擰,一個往右擰。扭矩測試主要是考驗手機殼體和手機內面大型器件的強度。8、靜電測試 進行這種測試的工具,是一個被稱爲“靜電槍”的銅板,靜電槍會調較到10-15KV的高壓低電流的狀況,對手機的所有金屬接觸點進行放電的擊試,時間約爲300ms-2s左右,並在一間有溼度控制的房間內進行,而有關的充電器(火牛)也會有同樣的測試9、按鍵壽命測試 藉助機器以給設定的力量對鍵盤擊打10萬次,假使用戶每按鍵100次,就是1000天,相當於用戶使用手機三年左右的時間。10、密封性測試 察看手機密封性是否完好,容易進灰塵不,11比如把手機放在鐵板上打電話加以測試,是否可以找到SIM卡,信號是否會變弱是否會沒有信號等。12用鐵絲在手機底部連接器內撥來撥去,主要是要考慮到手袋內有鎖匙的情況下,是否會令手機出現短路的問題。13把充電器/電池反接測試,看看手機的保護電路設計是否能正常運作14 多次插拔充電器看手機是否可以正常工作15 不插入SIM卡看手機是否支持緊急呼叫功能 16 當手機正在通話時,另有人打電話過來,看是否可以呼叫轉移(前提開通遇忙呼叫功能)17 當設置了無應答呼叫轉移時,用戶在無應答時呼叫轉移功能是否實現
22概要設計的目的    將軟件系統需求轉換爲未來系統的設計;   逐步開發強壯的系統構架;   使設計適合於實施環境,更好的提高系統性能;   結構應該被分解爲模塊和庫。
23概要設計的任務    1制定規範:代碼體系、接口規約、命名規則。這是項目小組今後共同合作的基礎,有了開發規範和程序模塊之間和項目成員彼此之間的接口規則、方式方法,大家就有了共同的工作語言、共同的工作平臺,使整個軟件開發工作可以協調有序地進行。2總體結構設計:   功能(加工)->模塊:每個功能用那些模塊實現,保證每個功能都有相應的模塊來實現; 3 模塊層次結構:某個角度的軟件框架視圖;
 模塊間的調用關係:模塊間的接口的總體描述;   模塊間的接口:傳遞的信息及其結構;   處理方式設計:滿足功能和性能的算法   用戶界面設計;數據結構設計: 詳細的數據結構:表、索引、文件; 算法相關邏輯數據結構及其操作;上述操作的程序模塊說明(在前臺?在後臺?用視圖?用過程?······)   接口控制表的數據結構和使用規則   其他性能設計。
24 概要設計寫什麼   結構化軟件設計說明書結構    任務:目標、環境、需求、侷限(遵循1 軟件設計應該表現出層次結構,應巧妙的利用各個軟件部件之間的控制關係 2 設計應該從邏輯上被劃分成多個部件,分別實現各種特定功能和子功能 3 設計最終應當給出具體的模塊(如子程序和過程),這些模塊應具有獨立的功能特性);   總體設計:處理流程、總體結構與模塊、功能與模塊的關係;   接口設計:總體說明外部用戶、軟、硬件接口;內部模塊間接口(注:接口≈系統界面)   數據結構:邏輯結構、物理結構,與程序結構的關係;   模塊設計:每個模塊“做什麼”、簡要說明“怎麼做”(輸入、輸出、處理邏輯、與其它模塊的接口,與其它系統或硬件的接口),處在什麼邏輯位置、物理位置;   運行設計:運行模塊組合、控制、時間;   出錯設計:出錯信息、處錯處理;   其他設計:保密、維護;   OO軟件設計說明書結構   1 概述    系統簡述、軟件設計目標、參考資料、修訂版本記錄   這部分論述整個系統的設計目標,明確地說明哪些功能是系統決定實現而哪些時不準備實現的。同時,對於非功能性的需求例如性能、可用性等,亦需提及。需求規格說明書對於這部分的內容來說是很重要的參考,看看其中明確了的功能性以及非功能性的需求。這部分必須說清楚設計的全貌如何,務必使讀者看後知道將實現的系統有什麼特點和功能。在隨後的文檔部分,將解釋設計是怎麼來實現這些的。   2 術語表   對本文檔中所使用的各種術語進行說明。如果一些術語在需求規格說明書中已經說明過了,此處不用再重複,可以指引讀者參考需求說明。   3 用例   此處要求系統用用例圖表述(UML),對每個用例(正常處理的情況)要有中文敘述。   4 設計概述   4.1 簡述   這部分要求突出整個設計所採用的方法(是面向對象設計還是結構化設計)、系統的體系結構(例如客戶/服務器結構)以及使用到的相應技術和工具(例如OMT、Rose)5. 從應用方面看,相對而言,結構化方法更加適合數據類型比較簡單的數值計算和數據統計管理軟件的開發;面向對象方法更加適合大型複雜的人機交互式軟件和數據統計管理軟件的開發
25  客戶端——服務器模式
在這種環境下進行的測試由數據庫客戶端向數據庫服務器直接發起測試,不需要其他配合設備
功能測試的方法  功能測試採用直接通過數據庫客戶端軟件進行數據庫服務器功能驗證的方法;測試中,由數據庫客戶端發起相應的測試請求進行驗證,對於不需要客戶端發起請求的功能驗證,可以採用直接驗證服務器提供的相應功能組件的方法進行。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章