軟件工程原理與實踐（碩士）課件 7 軟件質(zhì)量管理與測試

高級軟件工程

SoftwareEngineering軟件質(zhì)量管理與測試軟件災難蘇聯(lián)導彈預警系統(tǒng)軟件故障差點導致第三次世界大戰(zhàn)（1983年）造價80億美元的Ariane5型火箭因浮點數(shù)溢出，被迫引爆自毀。原因是5型的發(fā)射系統(tǒng)直接重用了4型的相應代碼，而4型的飛行條件和5型的截然不同（1996年）由北京南站開往福州站的D301次列車與杭州站開往福州南站的D3115次列車發(fā)生追尾事故，造成40人死亡，直接經(jīng)濟損失2億元。原因是信號設(shè)備存在嚴重缺陷，遭雷擊發(fā)生故障后，導致本應顯示為紅燈的信號機錯誤顯示為綠燈（2011年）區(qū)塊鏈業(yè)界最大的眾籌項目TheDAO遭到攻擊，導致300多萬以太幣資產(chǎn)被盜，原因是其智能合約中splitDAO函數(shù)有漏洞（2016年）印尼獅航一架波音737MAX8客機途中墜落，189人罹難，失事原因為軟件設(shè)計缺陷，飛機的迎角傳感器“數(shù)據(jù)錯誤”觸發(fā)“防失速”自動操作，導致機頭不斷下壓，最終墜海（2018年）2問題軟件系統(tǒng)功能齊全是不是就是質(zhì)量好？沒有BUG是不是就是軟件的質(zhì)量好？什么是用戶滿意的軟件項目？軟件測試是不是軟件質(zhì)量的全部？那么，什么是軟件的質(zhì)量？如何保證軟件的質(zhì)量？302-軟件質(zhì)量管理01-基本概念03-軟件評審404-軟件測試軟件質(zhì)量的定義ANSI/IEEEStd729-1983定義“與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體”。M.J.Fisher定義“所有描述計算機軟件優(yōu)秀程度的特性的組合”。5何謂軟件質(zhì)量好明確聲明的功能和性能需求、明確文檔化過的開發(fā)標準、以及專業(yè)人員開發(fā)的軟件所應具有的所有隱含特征都得到滿足。軟件需求是進行質(zhì)量度量的基礎(chǔ)，與需求不符就是質(zhì)量不合格指定的標準定義了一組指導軟件開發(fā)的準則，如果不能遵照這些準則，就極有可能導致質(zhì)量不好通常有一組隱含需求是不被提及的，如易維護性，如果軟件符合了明確的需求卻沒有滿足隱含需求，軟件質(zhì)量仍然值得懷疑6軟件的質(zhì)量屬性質(zhì)量的三種視角：內(nèi)部、外部、和使用質(zhì)量ISO/IEC25010:2011《軟件工程產(chǎn)品質(zhì)量》使用周境7ISO/IEC25010(SQuaRE)–Systemandsoftwarequalitymodels產(chǎn)品質(zhì)量模型（外部質(zhì)量和內(nèi)部質(zhì)量）8使用質(zhì)量模型9質(zhì)量與質(zhì)量特性軟件質(zhì)量是各種質(zhì)量特性的綜合體現(xiàn)但具體產(chǎn)品中各質(zhì)量特性的重要性與產(chǎn)品類型相關(guān)，例如關(guān)鍵任務系統(tǒng)(如銀行)強調(diào)可靠性和安全性大眾娛樂軟件強調(diào)用戶可用性廣泛分發(fā)的軟件服務(銀行支付服務等)強調(diào)互操作性實時系統(tǒng)特別強調(diào)時間效率嵌入式系統(tǒng)特別強調(diào)資源效率具有一定用戶面的特定領(lǐng)域產(chǎn)品強調(diào)可配置性和可維護性10質(zhì)量特性之間的關(guān)系無關(guān)互補或依賴易理解性與易操作性可靠性與容錯性：特性與子特性沖突安全性與性能可移植性與效率11質(zhì)量成本12分類質(zhì)量成本典型成分一致性成本預防成本質(zhì)量管理體系建立和維持、軟件過程改進、培訓、工具、供應商評價等評價成本測試、評審、審核等非一致性成本內(nèi)部故障成本重新設(shè)計、工期延期、BUG修復、返工、回歸測試、糾錯、資源閑置等外部故障成本客戶投訴處理、故障處理、處罰及賠償、市場影響、銷售影響等02-軟件質(zhì)量管理01-基本概念03-軟件評審1304-軟件測試如何進行質(zhì)量管理？ISO9000：質(zhì)量計劃、質(zhì)量控制、質(zhì)量保證、質(zhì)量改進。ISO12207和SWEBOK

：軟件質(zhì)量保證、驗證和確認、軟件評審、軟件審核、配置管理。SQuBOK：從組織級和項目級進行質(zhì)量管理。14軟件質(zhì)量管理15項目級軟件質(zhì)量管理16軟件質(zhì)量計劃是軟件項目計劃的子計劃內(nèi)容：質(zhì)量目標開展質(zhì)量活動的質(zhì)量標準、方法、規(guī)程和工具驗證、確認、評審、測試、審核、問題解決等質(zhì)量活動和任務的安排開展質(zhì)量活動的資源、日程和職責質(zhì)量記錄的標識、收集、歸檔、維護和處理的規(guī)程17驗證和確認的定義V&V是一個用以分析、評價、測試系統(tǒng)和軟件文檔以及代碼系統(tǒng)的過程，從而盡可能地確保質(zhì)量、可靠性以及系統(tǒng)需求和目標滿意度。

[IEEEStandardGlossary]驗證(Verification)是“對系統(tǒng)或單元評價的過程，以確定一個給定的開發(fā)階段的產(chǎn)品是否滿足在此階段開始時所給定的條件”確認(Validation)是“在軟件開發(fā)過程期間或結(jié)束時評價系統(tǒng)或單元的過程，以確定它是否滿足給定的需求”我們是否正確地完成了產(chǎn)品?我們是否完成了正確的產(chǎn)品？18質(zhì)量評價在軟件開發(fā)和運維過程中，收集與其執(zhí)行過程、執(zhí)行結(jié)果和成果相關(guān)的數(shù)據(jù)，進行質(zhì)量評價。評價結(jié)果作為判定能否批準接收成果和進度狀況的依據(jù)，并運用于過程改進。質(zhì)量評價的對象軟件產(chǎn)品（包括中間產(chǎn)品和最終產(chǎn)品）例如，項目在每個開發(fā)迭代結(jié)束時，都會以本次迭代的軟件版本為對象，以軟件需求規(guī)約為依據(jù)，遵循軟件產(chǎn)品質(zhì)量模型，進行正式的產(chǎn)品質(zhì)量的評價，以確定項目是否進入下一個迭代？需求是否必須改動？軟件開發(fā)是否需要更多的資源？等。軟件過程例如，項目在每個開發(fā)迭代結(jié)束時，在產(chǎn)品質(zhì)量評價的同時，對項目過程的質(zhì)量進行評價，以確定是否要對過程進行修改。尤其當產(chǎn)品質(zhì)量出現(xiàn)問題時，需分析是否由于過程的問題引起的。19軟件質(zhì)量管理技術(shù)20如何檢測軟件中的缺陷開發(fā)活動軟件制品缺陷檢測活動需求分析軟件設(shè)計軟件實現(xiàn)軟件運行需求模型設(shè)計模型源代碼可執(zhí)行代碼軟件系統(tǒng)評審模擬形式化驗證代碼靜態(tài)分析軟件測試運行時監(jiān)控靜態(tài)方法動態(tài)方法21可靠性預測符號執(zhí)行各種方法的缺陷檢測效果來源：“美國國防部：軟件技術(shù)進展”，2010年221)軟件評審審查小組評審走查結(jié)對編程同級桌查輪查臨時評審正式化程度23系統(tǒng)分析和設(shè)計需求分析設(shè)計編碼系統(tǒng)方案評審需求規(guī)范評審設(shè)計文檔評審單元測試集成測試確認測試系統(tǒng)測試2)軟件測試驗收測試ɑ

測試

?

測試試運行內(nèi)部外部項目產(chǎn)品243)代碼靜態(tài)分析不運行代碼，通過詞法分析、語法分析、控制流分析等技術(shù)，對代碼進行檢查，分析代碼的結(jié)構(gòu)，查找代碼的問題（例如內(nèi)存泄漏、安全漏洞、重復代碼、未使用變量等），度量代碼的質(zhì)量（例如耦合度、內(nèi)聚度、復雜度、重用度等）分析對象：源代碼、bytecode或二進制代碼可以由人工進行，也可以借助代碼分析工具進行商用代碼分析工具：Understand(多語言)、Sourceinsight(多語言)等開源代碼分析工具：PMD和Checkstyle(Java)、flake8和pylint(Python)、SonarQube(多語言)等25常用的代碼靜態(tài)分析技術(shù)詞法分析：從左至右一個字符一個字符的讀入源程序，對構(gòu)成源程序的字符流進行掃描，通過使用正則表達式匹配方法將源代碼轉(zhuǎn)換為等價的符號（Token）流，生成相關(guān)符號列表，Lex為常用分析工具。語法分析：判斷源程序結(jié)構(gòu)上是否正確，通過使用上下文無關(guān)語法將相關(guān)符號整理為語法樹，Yacc為常用工具。抽象語法樹分析：將程序組織成樹形結(jié)構(gòu)，樹中相關(guān)節(jié)點代表了程序中的相關(guān)代碼，目前已有javacc等抽象語法樹生成工具。語義分析：對結(jié)構(gòu)上正確的源程序進行上下文有關(guān)性質(zhì)的審查。控制流分析：生成有向控制流圖，用節(jié)點表示基本代碼塊，節(jié)點間的有向邊代表控制流路徑，反向邊表示可能存在的循環(huán)；還可生成函數(shù)調(diào)用關(guān)系圖，表示函數(shù)間的嵌套關(guān)系。數(shù)據(jù)流分析：對控制流圖進行遍歷，記錄變量的初始化點和引用點，保存相關(guān)數(shù)據(jù)信息。污點分析：基于數(shù)據(jù)流圖判斷源代碼中哪些變量可能受到攻擊，是驗證程序輸入、識別代碼表達缺陷的關(guān)鍵。

264)符號執(zhí)行

符號執(zhí)行（symbolicexecution）是指在不執(zhí)行代碼的前提下，用符號值表示代碼中變量值，然后模擬程序執(zhí)行來進行相關(guān)分析的技術(shù)，分析代碼的語義信息。符號執(zhí)行分為：過程內(nèi)分析是指只對單個過程的代碼進行分析；過程間分析（又稱全局分析）指對整個軟件代碼進行上下文敏感的分析。27intm=M,n=N,q=Q;intx1=0,x2=0,x3=0;if(m!=0){x1=-2;}if(n<12){

if(!m&&q){x2=1;}

x3=2;}assert(x1+x2+x3!=3)分析什么樣的輸入向量<M,N,Q>的情況下，得到的三個輸出變量的和等于35)形式化驗證形式化驗證用以驗證軟件是否滿足其規(guī)約的要求，常用于驗證關(guān)鍵軟件的安全性主要技術(shù)：定理證明(Theoremproving)模型檢驗（modelchecking）286)模擬

模型的動態(tài)模擬用于需求分析與設(shè)計模型的質(zhì)量控制例如：狀態(tài)圖與工作流的模擬運行等目的：更深入地看到需求和設(shè)計的完整性、正確性和合理性等，從而確保需求反映了用戶的真實要求，設(shè)計能滿足預期的需求。代碼在宿主機/開發(fā)環(huán)境上的模擬運行模擬目標機/運行環(huán)境297)運行時監(jiān)控系統(tǒng)監(jiān)控是對運行時軟件系統(tǒng)的性能和可靠性等進行實時監(jiān)視的技術(shù)，記錄和分析運行日志、軌跡和拋出異常，檢查系統(tǒng)的在線服務質(zhì)量，并及時發(fā)現(xiàn)問題。三種監(jiān)控手段：日志（Logging）、指標（Metrics）、追蹤（Tracing）工具舉例：Actuator、Prometheus、Grafana、LogStash、APM等308)可靠性預測采用可靠性增長模型定量地評價軟件可靠性?？煽啃栽鲩L模型能根據(jù)測試階段和運行階段的數(shù)據(jù)推斷出軟件可靠性。因為隨著測試及運行，缺陷被不斷發(fā)現(xiàn)與排除，可靠性會隨之增長，故稱為可靠性增長模型。軟件可靠性增長模型一般可分為：故障發(fā)生時間模型，如NHPP模型、馬爾可夫過程模型等故障發(fā)現(xiàn)數(shù)量模型，如貝葉斯模型、危險率模型等31七種基本質(zhì)量工具（7QC）32質(zhì)量控制圖33魚骨圖34Pareto圖Pareto法則：80%的缺陷經(jīng)常由于20%的原因引起的3502-軟件質(zhì)量管理01-基本概念03-軟件評審3604-軟件測試評審目的提高質(zhì)量減少軟件開發(fā)/維護的時間和費用提高生產(chǎn)率提高估算準確性培訓EngineeringDocumentsRulesForwritingEng.Docs.軟件評審Defects發(fā)現(xiàn)缺陷、預防缺陷37投資回報率從4:1到30:1Review:評審方法審查小組評審走查結(jié)對編程同級桌查輪查臨時評審正式化程度從高到低38審查Inspection最系統(tǒng)化、最嚴密的評審技術(shù)被認為是軟件工業(yè)中最實用的、最有效的評審方法嚴格定義的審查過程，明確的分工審查組長、讀者、審查者作者、記錄員39審查過程初始工件基線工件規(guī)劃總體會議準備審查會議重寫重審40受審查的工件初始工件基線工件規(guī)劃總體會議準備評審會議重寫重審項目計劃需求規(guī)格說明書概要設(shè)計、詳細設(shè)計系統(tǒng)測試計劃、用例和報告代碼

等41審查的規(guī)劃初始工件基線工件規(guī)劃總體會議準備審查會議重寫重審審查組長判斷是否已滿足審查的進入標準作者和審查組長協(xié)同對審查進行規(guī)劃，確定審查員和時間進度審查會議效率：每小時4~6頁

審查人員不超過7人或者更少審查人員可以是開發(fā)人員、測試人員、項目經(jīng)理、用戶等42RelativeTeamEfficiency:MajorDefects/timeused(uniquetotal)2367CheckersonteamRelative

Effectiveness:MajorDefectsfoundperpage(totalbyteam).Source:S?renSkogstadNielsen,Denmark’sTechnologicalInstitute(DTI),Lyngby,Denmark(Switch+4543504350).MajorDefectsfoundperPage45MajordefectsfoundperHourNote:thischartisanapproximationandisnotexactEffectivenesspeaksataround5or6checkersEfficiencypeaksataround3to4checkers評審小組人數(shù)對效率的影響143審查的準備初始工件基線工件規(guī)劃總體會議準備審查會議重寫重審將需求說明書等到交給每位審查員每個審查員以審查清單為指導，檢查文檔可能出現(xiàn)的錯誤，并提出問題75%的錯誤是在準備階段發(fā)現(xiàn)的44審查會議初始工件基線工件規(guī)劃總體會議準備審查會議重寫重審參加人員：審查組長、作者、記錄員、審查人員（選其中一個為讀者）每次會議不超過2小時審查目標：盡可能多地發(fā)現(xiàn)問題，而不是解決問題遞交：會議記錄（問題和缺陷）、審查結(jié)論45重寫初始工件基線工件規(guī)劃總體會議準備審查會議重寫重審由作者根據(jù)審查發(fā)現(xiàn)的問題，重寫文檔46重審初始工件基線工件規(guī)劃總體會議準備審查會議重寫重審由審查組長或指派人單獨重審由作者重寫的文檔，確保所有問題得到解決，所有錯誤得到修改。由審查組長判斷：是否已滿足審查的退出標準47小組評審TeamReview評審過程計劃、準備、開會、返工作者或評審組長主持會議讀者這個角色被省略了，改由評審組長詢問其他評審者這一部分是否有問題使用記錄員使用缺陷檢查表48走查Walkthrough評審過程計劃、開會、返工作者主持會議，起主導作用，陳述產(chǎn)品常用走查方法使用一些樣品數(shù)據(jù)一步步執(zhí)行一個模塊，和同事一道檢查以確保正確的邏輯和行為。使用交互式調(diào)試器按腳本執(zhí)行，腳本描述了一項具體的任務或場景，用以說明系統(tǒng)如何在用戶會話中發(fā)揮功能49結(jié)對編程PairProgramming極值編程XP中的一個實踐兩個開發(fā)者在一個工作站上同時編寫同一個程序，進行實時的、持續(xù)的、非正式的評審。司機和搭檔的角色還要不時地交換。由于搭檔的實時評審，結(jié)對者可以迅速糾正錯誤。快速的迭代能使設(shè)計和程序更加強壯。結(jié)對編程技術(shù)除了能應用于編碼，還能應用需求、設(shè)計、測試等文檔。50同級桌查PeerDeskcheck在兩次編譯之間仔細地檢查源代碼以保證程序正確執(zhí)行，這就是桌查。桌查是PSP的組成部分,是一種自評審，不屬于同級評審。在同級桌查中，除作者外的一位評審者對工作產(chǎn)品進行檢查。評審者可以和作者坐在一起討論，也可以獨立檢查。評審完成后，評審者把錯誤表交給作者，或者兩人一起坐下來共同準備錯誤表，或者簡單地將做過標記的工作產(chǎn)品交給作者。要尋找一位足夠?qū)I(yè)且值得信賴的人擔任評審者。51輪查Passaround輪查是由多人組成的并行同級桌查輪查有助于緩和同級桌查的兩個主要風險評審者不能及時提供反饋評審效果太糟52選擇合適的評審方法評審目標審查小組評審走查結(jié)對編程同級桌查輪查查找產(chǎn)品缺陷√√√√√√檢查規(guī)范的一致性√√

√√檢查是否符合標準√

√√檢查完整性/正確性√

√

評估可理解性/可維護性√√

√

√證實關(guān)鍵構(gòu)件的質(zhì)量√

過程改進√√

測量文檔質(zhì)量√

培訓其他組員熟悉產(chǎn)品

√√√

√對方法達成共識

√√√

確保修改和糾錯正確

√√

√

尋找可替換的方法

√√

模擬執(zhí)行程序

√

評審開銷最小化

√

5302-軟件質(zhì)量管理01-基本概念03-軟件評審5404-軟件測試軟件測試技術(shù)白盒測試黑盒測試基于直覺和經(jīng)驗即興測試*探索式測試*基于代碼控制流測試*基本路徑測試*數(shù)據(jù)流測試基于規(guī)約等價類劃分*邊界值分析*隨機測試*基于錯誤錯誤猜測*變異測試基于模型因果圖/判定表基于有限狀態(tài)機的測試基于形式化規(guī)約的測試專用測試技術(shù)（即基于應用類型）面向?qū)ο蟮臏y試基于構(gòu)件的測試并發(fā)程序的測試基于Web的測試圖形用戶界面的測試協(xié)議一致性的測試實時系統(tǒng)的測試55軟件測試的層次56單元測試（unittesting）又稱為模塊測試，是針對軟件結(jié)構(gòu)中獨立的基本單元（如函數(shù)、子過程、類）進行的測試。單元測試可看作是編碼工作的一部分，應該由程序員完成，也就是說，經(jīng)過了單元測試的代碼才是已完成的代碼，提交產(chǎn)品代碼時也要同時提交測試代碼。測試驅(qū)動開發(fā)（testdrivendevelopment）:在詳細設(shè)計的時候就編寫測試用例，然后再編寫程序代碼來滿足這些測試用例。自動化的單元測試:目前最流行的單元測試工具是xUnit系列框架，如JUnit(Java)，CppUnit(C++)，Cunit(C)，Dunit(Delphi)，Nunit(.net)，PhpUnit(PHP)，PyUnit/unittest/pytest(Python)，Jest(Javascript)等等。57單元測試技術(shù)–白盒測試白盒測試：基于代碼的測試控制流測試數(shù)據(jù)流測試基本路徑測試581）語句覆蓋2）判定覆蓋（分支）3）條件覆蓋4）判定/條件覆蓋5）條件組合覆蓋6）路徑覆蓋集成測試（integrationtesting）又稱組裝測試，根據(jù)設(shè)計將軟件模塊組裝起來，進行有序的、遞增的測試，并通過測試評價它們之間的交互。集成測試重點關(guān)注：在把各個軟件單元連接起來的時候，穿越單元接口的數(shù)據(jù)是否會丟失；一個軟件單元的功能是否會對另一個軟件單元的功能產(chǎn)生不利的影響；各個子功能組合起來，能否達到預期要求的父功能；全局數(shù)據(jù)結(jié)構(gòu)是否有問題；單個軟件單元的誤差累積起來，是否會放大，從而達到不能接受的程度。集成測試工具：postman、APIfox、SoapUI等API測試工具；Spring后端應用的集成測試工具SpringBootTest；ReactNative集成測試工具Cavy等59集成測試技術(shù)–灰盒測試灰盒測試(白盒+黑盒):基于設(shè)計的測試舉例：服務端的接口測試，采用Apifox測試工具白盒：API

signature;黑盒：根據(jù)API的輸入和輸出，采用黑盒測試技術(shù)進行測試60系統(tǒng)測試（systemtesting）對整個軟件系統(tǒng)進行一系列測試，以驗證系統(tǒng)是否滿足需求規(guī)約功能測試性能測試可靠性測試易用性測試安全性測試兼容性測試……61系統(tǒng)測試技術(shù)–黑盒測試黑盒測試：基于需求規(guī)約的測試等價類劃分邊界值分析判定表法錯誤推測法62等價類劃分邊界值分析

1234條件兒童1100白天時段0110動作票價8折

票價9折

票價不打折

測試用例

TC1TC2TC3TC4判定表法功能測試功能測試（functionalitytesting），又稱為正確性測試或一致性測試，其目的是用以確認軟件在指定條件下使用時，軟件產(chǎn)品提供滿足明確和隱含要求的功能的能力。測試方法采用場景法測試所有用例的所有事件流采用等價類劃分、邊界值分析、判定表法、錯誤推測法等進行輸入輸出的測試人工測試或自動化測試自動化的功能測試工具，又稱為回歸測試工具，或UI測試工具，例如Web應用的開源Selenium工具App應用的開源Appium工具63性能測試性能測試（performancetesting）用來測試軟件在規(guī)定條件下，相對于所用資源的數(shù)量，可提供適當性能的能力。壓力測試（stresstesting），又稱強度測試，是一種超常情況下的性能測試。它需要在超常數(shù)量、頻率或資源的方式下執(zhí)行系統(tǒng)，以獲得系統(tǒng)對非正常情況下（如大數(shù)據(jù)量的輸入、處理和輸出，大并發(fā)數(shù)等）的承受程度。自動化的性能/壓力測試工具：HP的Loadrunner開源的Jmeter……64可靠性測試軟件可靠性測試（reliabilitytesting）用以測試在故障發(fā)生時，軟件產(chǎn)品維持規(guī)定的績效級別的能力。

廣義的可靠性包括可靠性和可用性可靠性使用MTBF（MeanTimeBetweenFailure）度量。平均故障間隔時間，或稱為平均無故障工作時間，指相鄰兩次故障之間的平均工作時長。易恢復性使用MTTR（MeanTimeToRecover）度量，即平均故障修復時間?？捎眯杂嬎悖篗TBF/(MTBF+MTTR)可靠性測試方法：系統(tǒng)運行一段時間，觀察正常工作的時間，以及故障發(fā)生的頻率和修復時間以主動制造故障的方法來驗證容災和恢復能力65易用性測試易用性測試（usabilitytesting）用以評價用戶學習和使用軟件（包括用戶文檔）的難易程度、支持用戶任務的有效程度、從用戶的錯誤中恢復的能力。易用性測試可以采用模擬用戶的方式進行，也可以通過觀察用戶的操作行為來執(zhí)行。66易用性原則說明狀態(tài)可見針對用戶的操作，系統(tǒng)能及時反饋操作是否生效環(huán)境貼切用戶常用操作和大部分系統(tǒng)設(shè)計保持一致，不應出現(xiàn)“反人類”的設(shè)計用戶可控為了避免用戶的誤操作，系統(tǒng)應支持撤銷的功能，并以方便的形式允許用戶使用，從而使得用戶能夠方便地回退到之前的狀態(tài)一致性系統(tǒng)中同一用語、功能、操作保持一致，同樣的語言、同樣的情景、操作應該出現(xiàn)同樣的結(jié)果防錯系統(tǒng)應防止用戶的誤操作易取系統(tǒng)應減少用戶記憶負擔，把需要記憶的內(nèi)容放在可見界面上靈活高效系統(tǒng)應提供特定能力以使得用戶在使用某些功能時更加靈活、操作更加高效優(yōu)美簡約系統(tǒng)界面上多余的信息會分散用戶對有用或者相關(guān)信息的注意力，因此界面應貼合實際場景，突出重點，弱化和剔除無關(guān)信息容錯系統(tǒng)應幫助用戶從錯誤中恢復并將損失降到最低。如果無法自動挽回，則應提供詳盡的說明文字和指示方向，而不應該使用代碼人性化幫助系統(tǒng)應提供幫助性提示，包括一次性提示、常駐提示、幫助文檔等安全性測試（SecurityTesting）

常見的面向Web應用的信息安全測試的測試內(nèi)容67類型測試內(nèi)容服務器信息測試運行賬號測試；web服務器端口版本測試；HTTP方法測試文件目錄測試目錄遍歷測試；文件歸檔測試；目錄列表測試認證測試驗證碼測試；認證錯誤測試；找回、修改密碼測試會話管理測試會話超時測試；會話固定測試；會話標識隨機性測試授權(quán)管理測試橫向越權(quán)測試；縱向越權(quán)測試；跨站偽造請求測試文件上傳下載測試文件上傳測試；文件下載測試信息泄露測試數(shù)據(jù)庫賬號密碼測試；客戶端源代碼測試；異常處理測試輸入數(shù)據(jù)測試SQL注入測試；XML注入測試；LDAP注入測試跨站腳本攻擊測試反射型測試；存儲型跨站測試；DOM型跨站測