軟件測試重點

1、軟件測試定義的兩面性軟件測試定義的兩面性 評價一個程序或系統(tǒng)的特性或能力并確定是否達(dá)到預(yù)期的結(jié)果測試是為發(fā)現(xiàn)錯誤而針對某個程序或系統(tǒng)的執(zhí)行過程軟軟件件測測試試正向思維正向思維驗證軟件正常工作逆向思維逆向思維假定軟件有錯誤在設(shè)計規(guī)定的環(huán)境下運行軟件的所有功能，直至全部通過。尋找容易犯錯誤的地方和系統(tǒng)的薄弱環(huán)節(jié)，試圖破壞系統(tǒng)，直至找不出問題。軟件測試的定義軟件測試的定義SWEBOK3.0的定義的定義 ：p從一個通常是無限的執(zhí)行域（集合）中選擇合適的、有限的測試用例，對程序所期望的行為進(jìn)行動態(tài)驗證的活動過程。1.4 軟件測試和軟件開發(fā)的關(guān)系軟件測試和軟件開發(fā)的關(guān)系讓人誤解的瀑布模型讓人誤解的瀑布模型

2、需求分析和定義系統(tǒng)設(shè)計詳細(xì)功能設(shè)計編碼單元測試功能測試系統(tǒng)測試驗收測試測試用戶需求驗證系統(tǒng)非功能特性驗證功能驗證代碼驗證構(gòu)建過程驗證過程軟件質(zhì)量軟件質(zhì)量 的內(nèi)涵的內(nèi)涵IEEEIEEE： 質(zhì)量是系統(tǒng)、部件或過程滿足質(zhì)量是系統(tǒng)、部件或過程滿足明確需求客戶或用戶需要或期望的程度不同 p軟件質(zhì)量軟件質(zhì)量：軟件產(chǎn)品具有滿足規(guī)定的和隱含的與需求能力有關(guān)的全部特征和特性(IEEE STD729) p軟件質(zhì)量軟件質(zhì)量：軟件產(chǎn)品滿足使用要求的程度 不同的分類不同的分類按測試的對象或范圍分類，如單元測試、文檔測試、系統(tǒng)測試等）按測試目的分類，如功能測試、回歸測試、性能測試、可靠性測試、安全性測試和兼容性測試等根據(jù)

3、測試過程中被測軟件是否被執(zhí)行，分為靜態(tài)測試和動態(tài)測試根據(jù)是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實現(xiàn)算法來完成測試，可分為白盒測試和黑盒測試2.4 靜態(tài)測試和動態(tài)測試靜態(tài)測試和動態(tài)測試 根據(jù)程序是否運行，測試分為靜態(tài)測試和動態(tài)測試； 靜態(tài)測試靜態(tài)測試包括對軟件產(chǎn)品的需求和設(shè)計規(guī)格說明書的評審、對程序代碼的審查以及靜態(tài)分析等； 動態(tài)測試動態(tài)測試通過真正運行程序發(fā)現(xiàn)錯誤，通過觀察代碼運行過程來獲取系統(tǒng)行為、變量實時結(jié)果、內(nèi)存、堆棧、線程以及測試覆蓋度等各方面信息，來判斷系統(tǒng)是否存在問題，或者通過有效的測試用例，對應(yīng)的輸入輸出關(guān)系來分析被測程序的運行情況，以發(fā)現(xiàn)缺陷。 SWEBOK 3.0中把靜態(tài)測試內(nèi)容放在“

4、質(zhì)量管理”模塊中。2.4 主動測試和被動測試主動測試和被動測試測試人員被測試對象發(fā)送接收接收/檢查發(fā)送/響應(yīng)主動測試被測試對象運行環(huán)境發(fā)送接收/響應(yīng)測試人員接收/監(jiān)控被動測試2.5 黑盒測試和白盒測試黑盒測試和白盒測試功能測試功能測試數(shù)據(jù)驅(qū)動測試數(shù)據(jù)驅(qū)動測試 結(jié)構(gòu)測試結(jié)構(gòu)測試邏輯驅(qū)動測試邏輯驅(qū)動測試 客戶需求事件驅(qū)動輸入輸出功能測試（黑盒）功能測試（黑盒） 完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試人員針對軟件直接進(jìn)行測試，檢查系統(tǒng)功能是否按照需求規(guī)格說明書的規(guī)定正常使用、是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而輸出正確的結(jié)果，檢查相應(yīng)的文檔是否采用了正確的模板、是否滿足規(guī)范要求。 發(fā)現(xiàn)的缺陷類型： 有

5、錯誤的功能或遺漏了某項功能； 不能正確接收輸入數(shù)據(jù)，輸出錯誤結(jié)果； 功能操作邏輯不合理、不夠方便； 界面出錯、扭曲或不美觀； 安裝過程中出現(xiàn)問題，安裝步驟不清晰、不夠靈活； 系統(tǒng)初始化問題。結(jié)構(gòu)測試（白盒）結(jié)構(gòu)測試（白盒） 已知產(chǎn)品內(nèi)部工作過程，清楚最終生成軟件產(chǎn)品的計算機(jī)程序結(jié)構(gòu)及語句，按照程序內(nèi)部結(jié)構(gòu)測試程序，測試程序內(nèi)部的變量狀態(tài)、邏輯結(jié)構(gòu)、運行路徑等，檢查程序中的每條通路是否都能按預(yù)定要求正確工作，檢查程序內(nèi)部動作或運行是否符合設(shè)計規(guī)格要求，所有內(nèi)部成分是否按規(guī)定正常進(jìn)行。 白盒測試原則 在執(zhí)行測試時，先考慮各個分支被覆蓋； 再考慮完成所有邏輯條件分別為真值和假值的測試； 如果有更高質(zhì)

6、量要求，測試對象流程圖中所有獨立路徑至少被運行一次； 檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)，注意上下文的影響，以確保其測試的有效性。黑盒與白盒比較黑盒與白盒比較 功能測試的置信，結(jié)構(gòu)測試的度量特點測試依據(jù)方法舉例黑盒測試不給程序不給程序需求規(guī)格需求規(guī)格說明說明等價類劃等價類劃分分白盒測試給出程序給出程序程序程序邏輯覆蓋邏輯覆蓋測試階段測試階段（SDLC)軟件測試階段輸入和輸出軟件測試階段輸入和輸出階階 段段輸輸 入入 輸輸 出出 需求分析需求分析需求定義需求定義, 市場分析文檔市場分析文檔, 相關(guān)技相關(guān)技術(shù)文檔術(shù)文檔市場需求分析會議記要市場需求分析會議記要 , 功能設(shè)計功能設(shè)計, 技術(shù)設(shè)計技術(shù)設(shè)計設(shè)計審查設(shè)計審查

7、 市場需求文檔市場需求文檔, 技術(shù)設(shè)計文檔技術(shù)設(shè)計文檔 測試計劃測試計劃, 測試用例測試用例功能驗證功能驗證 代碼完成文件包代碼完成文件包,功能詳細(xì)設(shè)計說功能詳細(xì)設(shè)計說明書明書最終技術(shù)文檔最終技術(shù)文檔完整測試用例完整測試用例,完備的測試計劃完備的測試計劃, 缺缺陷報告陷報告,功能驗證測試報告功能驗證測試報告系統(tǒng)測試系統(tǒng)測試代碼修改后的文件包代碼修改后的文件包 完整測試用例完整測試用例,完備的測試計劃完備的測試計劃 缺陷報告缺陷報告缺陷狀態(tài)報告缺陷狀態(tài)報告項目階段報告項目階段報告確認(rèn)測試確認(rèn)測試代碼凍結(jié)文件包代碼凍結(jié)文件包確認(rèn)測試用例確認(rèn)測試用例缺陷狀態(tài)報告缺陷狀態(tài)報告缺陷報告審查缺陷報告審查版

8、本審查版本審查版本發(fā)布版本發(fā)布 代碼發(fā)布文件包代碼發(fā)布文件包 測試計劃檢查清單測試計劃檢查清單當(dāng)前版本已知問題的清單當(dāng)前版本已知問題的清單版本發(fā)布報告版本發(fā)布報告需求和設(shè)計審查需求和設(shè)計審查測試人員參與產(chǎn)品需求分析和系統(tǒng)設(shè)計，認(rèn)真閱讀有關(guān)文檔，真正理解客戶的需求和技術(shù)上的設(shè)計，檢查需求說明書對產(chǎn)品描述的準(zhǔn)確性、一致性等，檢查系統(tǒng)設(shè)計的合理性和可測試性等單元測試單元測試單元測試單元測試的對象是程序系統(tǒng)中的最小單元-類、函數(shù)、模塊或組件上，在編碼階段進(jìn)行，針對每個模塊進(jìn)行測試，主要通過白盒測試方法，從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例，檢查程序模塊或組件的已實現(xiàn)的功能與定義的功能是否一致、以及編碼中是

9、否存在錯誤。多個模塊可以平行地、對立地測試，通常要編寫驅(qū)動模塊和樁模塊。單元測試一般由編程人員和測試人員共同完成，而以開發(fā)人員為主單元測試包括代碼評審，代碼評審可以發(fā)現(xiàn)程序50%70%代碼的缺陷。集成測試集成測試集成測試，也稱組裝測試、聯(lián)合測試、子系統(tǒng)測試，在單元測試的基礎(chǔ)上，將模塊按照設(shè)計要求組裝起來同時進(jìn)行測試，主要目標(biāo)是發(fā)現(xiàn)與接口有關(guān)的模塊之間問題 兩種集成方式：一次性集成方式和漸增式集成方式。功能測試功能測試功能測試一般須在完成集成測試后進(jìn)行，而且是針對應(yīng)用系統(tǒng)進(jìn)行測試。功能測試是基于產(chǎn)品功能說明書，是在已知產(chǎn)品所應(yīng)具有的功能，從用戶角度來進(jìn)行功能驗證，以確認(rèn)每個功能是否都能正常使用。

10、 系統(tǒng)測試系統(tǒng)測試系統(tǒng)測試是將軟件放在整個計算機(jī)環(huán)境下，包括軟硬件平臺、某些支持軟件、數(shù)據(jù)和人員等，在實際運行環(huán)境下進(jìn)行一系列的測試，包括用戶界面、各種操作、不同的數(shù)據(jù)輸入輸出、存儲測試、負(fù)載測試、災(zāi)難恢復(fù)測試、安全測試、可靠性測試和性能測試等 。驗收測試驗收測試 &安裝測試安裝測試驗收測試驗收測試的目的是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作，驗證軟件的功能和性能及其他特性如同用戶所合理期待的那樣。驗收測試一般要求在實際的用戶環(huán)境上進(jìn)行，并和用戶共同完成。lpha（）測試和Beta（）測試進(jìn)一步彰顯全過程測試4.1.3 W模型4.1.2 TMappTMap (Test Managemen

11、t Approach，測試管理方法)是一種結(jié)構(gòu)化的、基于風(fēng)險策略的測試方法體系, 目的能更早地發(fā)現(xiàn)缺陷，以最小的成本、有效地、徹底地完成測試任務(wù)，以減少軟件發(fā)布后的支持成本。pTMap所定義的測試生命周期由計劃和控制、準(zhǔn)備、說明、計劃和控制、準(zhǔn)備、說明、執(zhí)行和完成等執(zhí)行和完成等階段組成參考： http:/ NEXT之背景p測試的獨立性 和開發(fā)更緊密的融合p更多種類的測試組織，包括測試工廠pBDTM, Business Driven Test Managementp新的測試方法、技術(shù)，特別測試設(shè)計方法p測試的基礎(chǔ)設(shè)施、支持流程p測試估算、風(fēng)險分析p增加測試類型TMap NEXThttp:/ 單元

12、測試是對軟件基本的組成單元進(jìn)行獨立的測試p時機(jī) 單元測試和編碼是同步進(jìn)行，但在TDD中，強(qiáng)調(diào)測試在先，編碼在后。單元測試一般由開發(fā)人員完成,QA人員輔助.p概念 模塊、組件、單元模塊、組件、單元 單元測試的目標(biāo)p目標(biāo): 單元模塊被正確編碼p信息能否正確地流入和流出單元p在單元工作過程中，其內(nèi)部數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的形式、內(nèi)容及相互關(guān)系不發(fā)生錯誤，全局變量在單元中的處理和影響p為限制數(shù)據(jù)加工而設(shè)置的邊界處，能否正確工作p單元的運行能否做到滿足特定的邏輯覆蓋任務(wù):模塊獨立執(zhí)行路徑測試檢查每一條獨立執(zhí)行路徑的測試，并保證每條語句被至少檢查每一條獨立執(zhí)行路徑的測試，并保證每條語句被至少執(zhí)

13、行一次。執(zhí)行一次。Checklist:p 誤解或用錯了算符優(yōu)先級p 混合類型運算p 變量初值錯 p 精度不夠 p 表達(dá)式符號錯 p 其它任務(wù)2:局部數(shù)據(jù)結(jié)構(gòu)測試檢查局部數(shù)據(jù)結(jié)構(gòu)完整性檢查局部數(shù)據(jù)結(jié)構(gòu)完整性Checklist:p 不適合或不相容的類型說明p 變量無初值p 變量初始化或默認(rèn)值有錯p 不正確的變量名或從來未被使用過p 出現(xiàn)上溢或下溢和地址異常p 其它任務(wù):模塊接口測試檢查模塊接口是否正確檢查模塊接口是否正確checklist:p輸入的實際參數(shù)與形式參數(shù)是否一致(個數(shù)、屬性、量綱)p調(diào)用其他模塊的實際參數(shù)與被調(diào)模塊的形參是否一致。 個數(shù)、屬性、量綱p全程變量的定義在各模塊是否一致。p外

14、部輸入、輸出p文件、緩沖區(qū)、錯誤處理p其它任務(wù):單元邊界條件測試檢查臨界數(shù)據(jù)處理的正確性檢查臨界數(shù)據(jù)處理的正確性Checklist:p 普通合法數(shù)據(jù)的處理。p 普通非法數(shù)據(jù)的處理。p 邊界值內(nèi)合法邊界數(shù)據(jù)的處理。p 邊界值外非法邊界數(shù)據(jù)的處理。p 其它任務(wù)5: 單元容錯測試預(yù)設(shè)的各種出錯處理是否正確有效。預(yù)設(shè)的各種出錯處理是否正確有效。Checklist:p 輸出的出錯信息難以理解p 記錄的錯誤與實際不相符p 異常處理不當(dāng)p 未提供足夠的定位出錯的信息p 其它任務(wù)6：內(nèi)存分析p內(nèi)存泄漏會導(dǎo)致系統(tǒng)運行的崩潰；p測量內(nèi)存的使用情況，了解程序內(nèi)存分配的真實情況；p系統(tǒng)崩潰前發(fā)現(xiàn)內(nèi)存泄漏錯誤；p發(fā)現(xiàn)內(nèi)

15、存分配錯誤，并精確顯示發(fā)生錯誤時的上下文情況，指出發(fā)生錯誤的原由。驅(qū)動程序和樁程序運行單元程序有時需要基于被測單元的接口，開發(fā)相應(yīng)的運行單元程序有時需要基于被測單元的接口，開發(fā)相應(yīng)的驅(qū)動模塊和樁模塊。驅(qū)動模塊和樁模塊。p驅(qū)動模塊（drive）:對底層或子層模塊進(jìn)行測試所編寫的調(diào)用這些模塊的程序。p樁模塊（stub）：對頂層或上層模塊進(jìn)行測試時所編寫的替代下層模塊的程序。集成測試的模式漸增式測試模式與非漸增式測試模式漸增式測試模式與非漸增式測試模式非漸增式測試模式非漸增式測試模式：先分別測試每個模塊，再把所有模塊按設(shè)計要求放在一起結(jié)合成所要的程序，如大棒模式。漸增式測試模式漸增式測試模式：把下一

16、個要測試的模塊同已經(jīng)測試好的模塊結(jié)合起來進(jìn)行測試，測試完以后再把下一個應(yīng)該測試的模塊結(jié)合進(jìn)來測試。各自的優(yōu)缺點各自的優(yōu)缺點漸增式測試模式需要編寫的軟件較多，工作量較大，而非漸增式測試模式開銷小。漸增式測試模式發(fā)現(xiàn)模塊間的接口錯誤早；而非漸增式測試模式晚。非漸增式測試模式發(fā)現(xiàn)錯誤，較難診斷；而使用漸增式測試模式，如果發(fā)生錯誤則往往和最近加進(jìn)來的那個模塊有關(guān)。漸增式測試模式測試更徹底。漸增式測試模式需要較多的機(jī)器時間。使用非漸增式測試模式，可以并行測試。優(yōu)缺點大棒集成方法(Big-bang Integration)采用大棒集成方法采用大棒集成方法,先是對每一個子模塊進(jìn)行測試（單元測試階段），先是對

17、每一個子模塊進(jìn)行測試（單元測試階段），然后將所有模塊一次性的全部集成起來進(jìn)行集成測試然后將所有模塊一次性的全部集成起來進(jìn)行集成測試 。因為所有的模塊一次集成的，所以很難確定出錯的真正位置、所在的模塊、錯誤的原因。這種方法并不推薦在任何系統(tǒng)中使用，適合在規(guī)模較小的應(yīng)用系統(tǒng)中使用。 自頂向下和自底向上集成方法 自頂向下法(Top-down Integration) 自頂向下法的主要優(yōu)缺點自頂向下法的主要優(yōu)缺點優(yōu)缺點：優(yōu)點：不需要測試驅(qū)動程序，能夠在測試階段的早期實現(xiàn)并驗證系統(tǒng)的主要功能 ，而且能夠在早期發(fā)現(xiàn)上層模塊的接口錯誤。缺點：需要樁程序，可能遇到于此想聯(lián)系的測試?yán)щy，低層關(guān)鍵模塊中的錯誤發(fā)現(xiàn)

18、的比較晚，而且用這種方法在早期不能充分開展人力。自底向上法 Bottom-up Integration 自底向上法的主要優(yōu)缺點自底向上法的主要優(yōu)缺點優(yōu)缺點：與自頂向下模式剛好相反三明治集成方法(Sandwich Integration) 采用三明治方法的優(yōu)點是：它將自頂向下和自底向上的集成方法有機(jī)地結(jié)合起來，不需要寫樁程序因為在測試初自底向上集成已經(jīng)驗證了底層模塊的正確性。采用這種方法的主要缺點是：在真正集成之前每一個獨立的模塊沒有完全測試過。改善的三明治集成方法改進(jìn)的三明治集成方法，不僅自兩頭向中間集成，而且保證每個模改進(jìn)的三明治集成方法，不僅自兩頭向中間集成，而且保證每個模塊得到單獨的測試

19、，使測試進(jìn)行得比較徹底塊得到單獨的測試，使測試進(jìn)行得比較徹底 。幾種集成方法性能的比較 自底向上自底向上 自頂向下自頂向下 混合策略混合策略大棒大棒三明治三明治改進(jìn)三明治改進(jìn)三明治集成集成早早早早早早晚晚早早早早基本程序能工作時間基本程序能工作時間晚晚早早早早晚晚早早早早需要驅(qū)動程序需要驅(qū)動程序是是否否是是是是是是是是需要樁程序需要樁程序否否是是是是是是是是是是工作并行性工作并行性中中低低中中高高中中高高特殊路徑測試特殊路徑測試容易容易難難容易容易容易容易中等中等容易容易計劃與控制計劃與控制容易容易難難難難容易容易難難難難系統(tǒng)測試p系統(tǒng)測試：系統(tǒng)測試：將經(jīng)過集成測試后的軟件，作為計算機(jī)系統(tǒng)的將

20、經(jīng)過集成測試后的軟件，作為計算機(jī)系統(tǒng)的一部分，與計算機(jī)硬件、某些支持軟件、數(shù)據(jù)和平臺等系一部分，與計算機(jī)硬件、某些支持軟件、數(shù)據(jù)和平臺等系統(tǒng)元素結(jié)合起來，在真實運行環(huán)境下對計算機(jī)系統(tǒng)進(jìn)行一統(tǒng)元素結(jié)合起來，在真實運行環(huán)境下對計算機(jī)系統(tǒng)進(jìn)行一系列的嚴(yán)格有效的測試來發(fā)現(xiàn)軟件的潛在問題，保證系統(tǒng)系列的嚴(yán)格有效的測試來發(fā)現(xiàn)軟件的潛在問題，保證系統(tǒng)的正常運行。的正常運行。p目的：目的：充分運行系統(tǒng)，驗證整個系統(tǒng)是否滿足功能和非功充分運行系統(tǒng)，驗證整個系統(tǒng)是否滿足功能和非功能性的質(zhì)量需求。能性的質(zhì)量需求。p非功能性測試是系統(tǒng)測試中更為關(guān)鍵的任務(wù)！非功能性測試是系統(tǒng)測試中更為關(guān)鍵的任務(wù)！回歸測試的目的回歸測試

21、的目的 p 所做的修改達(dá)到了預(yù)定的目的，如錯誤得到了改正，新功能得到了實現(xiàn)，能夠適應(yīng)新的運行環(huán)境等；p 不影響軟件原有功能的正確性。6.2 回歸測試 一旦程序某些區(qū)域被修改了，就可能影響其它區(qū)域，導(dǎo)致受影響的區(qū)域出現(xiàn)新的缺陷（回歸缺陷）。如果這時沒有回歸測試，產(chǎn)品就帶著這樣的回歸缺陷被發(fā)布出去了，造成嚴(yán)重后果?；貧w測試就是為了發(fā)現(xiàn)回歸缺陷而進(jìn)行的測試。什么是性能測試？什么是性能測試？性能測試性能測試（performance test）就是為了發(fā)現(xiàn)系統(tǒng)性能問題或獲取系統(tǒng)性能相關(guān)指標(biāo)而進(jìn)行的測試。一般在真實環(huán)境真實環(huán)境、特定負(fù)載特定負(fù)載條件下，通過工具模擬工具模擬實際軟件系統(tǒng)的運行及其操作，同時監(jiān)

22、控性能各項指標(biāo)，最后對測試結(jié)果進(jìn)行分析來確定系統(tǒng)的性能狀況。性能測試目標(biāo)性能測試目標(biāo)Performance Testingv獲取系統(tǒng)性能某些指標(biāo)數(shù)據(jù)v為了驗證系統(tǒng)是否達(dá)到用戶提出的性能指標(biāo)v發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，優(yōu)化系統(tǒng)的性能壓力壓力/ /負(fù)載測試負(fù)載測試壓力測試壓力測試(Stress test)，也稱為強(qiáng)度測試、負(fù)載測試。壓力測試是模擬實際應(yīng)用的軟硬件環(huán)境及用戶使用過程的系統(tǒng)負(fù)荷，長時間或超大負(fù)荷地運行測試軟件，來測試被測系統(tǒng)的性能、可靠性、穩(wěn)定性等。兩種負(fù)載類型兩種負(fù)載類型“FlatFlat”測試測試: : 對于一次給定的測試，應(yīng)該取響應(yīng)時間和吞吐量的平均值。精確地獲得這些值的唯一方法

23、是一次一次加載所有的用戶加載所有的用戶，然后在預(yù)定的時間段內(nèi)持續(xù)時間段內(nèi)持續(xù)運行。虛擬用戶的數(shù)量虛擬用戶的數(shù)量兩種負(fù)載類型兩種負(fù)載類型 Ramp-upRamp-up測試測試: : 用戶是交錯上升的（每幾秒增加一些新用戶）。ramp-up測試不能產(chǎn)生精確和可重現(xiàn)的平均值，這是因為由于用戶的增加是每次一部分，系統(tǒng)的負(fù)載在不斷地變化。其優(yōu)點是，可以看出隨著系統(tǒng)負(fù)載的改變，測量值是如何改變的據(jù)此選擇要運行的flat測試的范圍。安全性測試安全性測試 p想方設(shè)法截取或破譯口令；p專門開發(fā)軟件來破壞系統(tǒng)的保護(hù)機(jī)制；p故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；p試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息等等。理論上講，只要有足夠的時間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計的準(zhǔn)則是，使非法侵入的代價超過被保護(hù)信息的價值，此時非法侵入者已無利可圖。軟件安全性測試就是檢驗系統(tǒng)權(quán)限設(shè)置有效性、防范非法入侵的能力、數(shù)據(jù)備份和恢復(fù)能力等，設(shè)法找出上述各種安