第五講可靠性與程序設計風格

第五講可靠性與程序設計風格第1頁，共18頁，2023年，2月20日，星期一1.什么是軟件可靠性

軟件可靠性在特定環(huán)境特定時間內(nèi)程序不是擺地運行的概率信息安全可靠性：訪問控制、加密程序運行可靠性：編程風格、測試軟件錯誤統(tǒng)計

功能錯：占整個軟件錯誤27%，是需求分析設計不完整而引起的系統(tǒng)錯：占整個軟件錯誤16%，是總體設計錯誤而引起的數(shù)據(jù)錯：占整個軟件錯誤10%，由編碼錯誤引起的編碼錯：占整個軟件錯誤4%，程序員編碼錯誤引起的其它錯：占整個軟件錯誤4%，由文檔錯和硬件錯所引起的第2頁，共18頁，2023年，2月20日，星期一軟件錯誤分類詞法錯誤：打字錯誤語法錯誤：編譯錯誤語義錯誤：連接錯誤邏輯錯誤：運行錯誤錯誤越“高級”，解決代價越高昂非常難以發(fā)現(xiàn)的錯誤常常是小錯誤第3頁，共18頁，2023年，2月20日，星期一2.軟件測試評審和測試是發(fā)現(xiàn)錯誤的主要途徑軟件測試就是為了盡可能多地發(fā)現(xiàn)錯誤和缺陷軟件測試不能證明軟件沒有錯誤第4頁，共18頁，2023年，2月20日，星期一測試用例：測試數(shù)據(jù)+預期結果不僅設計合法的測試用例，也要設計非法的和非預期的測試用例用少量測試用例發(fā)現(xiàn)盡可能多的錯誤測試用例、測試計劃、測試統(tǒng)計都應保留應避免程序員測試自己的程序徹底測試整個軟件錯誤群集：若發(fā)現(xiàn)錯誤數(shù)目多，則殘存錯誤數(shù)目也比較多

第5頁，共18頁，2023年，2月20日，星期一單元測試模塊接口測試局部數(shù)據(jù)結構測試路徑測試錯誤處理測試邊界測試：±1驅(qū)動模塊：相當于所測模塊的主程序。它接收不同測試用例的測試數(shù)據(jù)，并把這些數(shù)據(jù)傳給所測模塊，最后輸出實測結果樁模塊：也稱存根模塊、連接模塊。用以代替所測模塊調(diào)用的子模塊。樁模塊不需要具備子模塊所有功能，但也不能什么事情都不做，要模擬實際子模塊的功能第6頁，共18頁，2023年，2月20日，星期一組裝測試：也叫做集成測試或聯(lián)合測試，發(fā)現(xiàn)與接口相聯(lián)系的問題

數(shù)據(jù)穿過接口時可能會丟失某個模塊可能會破壞另一個模塊的功能各子模塊組合起來可能達不到預期要求的主功能全局數(shù)據(jù)結構可能出問題單個模塊可以接受的誤差，裝配以后可能會放大（或積累）到不能接受的程度確認測試：又稱驗收測試驗證軟件的功能和性能及其他特性是否與用戶的要求一致軟件需求規(guī)格說明書既是軟件開發(fā)依據(jù)，也是軟件驗收標準

第7頁，共18頁，2023年，2月20日，星期一黑盒測試：又稱功能測試，完全不考慮程序的內(nèi)部結構和處理過程等價類劃分：把所有可能的輸入數(shù)據(jù)（有效的和無效的）劃分成若干個等價類，從每個等價類中只取一組數(shù)據(jù)作為測試數(shù)據(jù)邊界值分析：處理邊界情況時程序最容易發(fā)生錯誤。選取剛好等于、稍小于和稍大于等價類邊界值的數(shù)據(jù)作為測試數(shù)據(jù)錯誤推測：靠直覺和經(jīng)驗列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況，并且根據(jù)它們選擇測試方案，作為輔助手段綜合策略：將各種技術結合起來，取長補短，形成綜合的測試策略第8頁，共18頁，2023年，2月20日，星期一白盒測試：又稱結構測試，完全了解程序的結構和處理過程邏輯覆蓋一系列測試過程逐漸進行越來越完整的通路測試語句覆蓋：至少每個語句應該執(zhí)行一次判定覆蓋：又叫分支覆蓋，不僅每個語句必須至少執(zhí)行一次，而且每個判定的每種可能的結果都應該至少執(zhí)行一次條件覆蓋：不僅每個語句至少執(zhí)行一次，而且使判定表達式中的每個條件都取到各種可能的結果。條件覆蓋通常比判定覆蓋強、更細判定/條件覆蓋：使得判定表達式中的每個條件都取到各種可能的值，而且每個判定表達式也都取到各種可能的結果；也可能有相反的情況條件組合覆蓋：選取足夠多的測試數(shù)據(jù)，使得每個判定表達式中條件的各種可能組合都至少出現(xiàn)一次路徑覆蓋：每條可能路徑都至少執(zhí)行一次第9頁，共18頁，2023年，2月20日，星期一3.軟件糾錯

軟件測試：盡可能多地暴露程序中的錯誤軟件調(diào)試：發(fā)現(xiàn)錯誤的最終目的是為了改正錯誤

調(diào)試方法輸出存儲器內(nèi)容適當插入打印語句使用專門的調(diào)試工具：設置斷點調(diào)試策略試探法：分析錯誤征兆，猜想故障的大致位置回溯法：人工沿程序的控制流往回追蹤程序代碼，直到找出錯誤的根源或確定故障范圍為止歸納法：收集、整理數(shù)據(jù)，發(fā)現(xiàn)規(guī)律，提出假設，證明假設演繹法：從一般原理出發(fā)，經(jīng)過刪除和精化推導出結論第10頁，共18頁，2023年，2月20日，星期一4.編程風格高效+技巧安全+可靠時間、空間效率可用性、可維護性、可移植性良好的編程風格可以減少軟件錯誤程序設計風格源程序文檔化：標識符名，注釋，視覺組織數(shù)據(jù)說明：變量名，排列順序語句構造：易讀>效率,避免復雜的語句輸入和輸出：校驗，允許缺省值，輸出加注釋效率:追求效率要建立在不損害程序可讀性或可靠性基礎之上。要先使程序正確、再提高效率，要先使程序清晰，再提高程序效率第11頁，共18頁，2023年，2月20日，星期一命名約定當同時多個程序員合作從事一個項目時當把程序移交給另一個程序員修改和維護時當其他程序員評審程序時當程序過大需要分部分考慮時當一個項目中頻繁使用不常見詞匯命名約定可以強化相關項之間的關系命名約定可以彌補語言的缺陷命名約定可以幫助程序員更快熟悉項目的代碼命名約定可以防止一個變量多名命名約定可以增強程序的可讀性第12頁，共18頁，2023年，2月20日，星期一命名注意事項堅持使用英語命名，不用漢語拼音及縮寫名稱最佳長度：介于MaximumNumberOfPointsSince1896和x之間名稱的作用域：短名稱總是不好么？反義詞可以保持名稱的連續(xù)性：add/removebegin/endcreate/destroyinsert/deletefirst/lastget/releaseincrement/decrementput/getup/downlock/unlockmin/maxnext/previousold/newopen/closeshow/hidesource/destinationstart/stop循環(huán)變量：i/j/k狀態(tài)變量：Flag/StatusFlag/PrintFlag/DataReady/Type臨時變量：temp/t/x邏輯變量：Done/Error/Found/Success常量：PI/CYCLES_NEEDED第13頁，共18頁，2023年，2月20日，星期一匈牙利命名法：見名知義小寫前綴與大小寫混合的單詞組合一整套對子程序和變量的詳細命名約定發(fā)明者CharlesSimonyi原為匈牙利人組成部分基本類型、一個以上前綴、一個限定詞基本類型（小寫）：程序語言中沒有的抽象數(shù)據(jù)類型例如：wn:窗口scr：屏幕區(qū)fon：字體ch：字符pa：段落WNwnMain;SCRscrUserWorkspace;前綴（小寫）：標準化的，可以與基本類型組合 例如：a:數(shù)組c:數(shù)目e:數(shù)組元素g:全局變量

i:數(shù)組下標m:模塊層次的變量p(lp,np):指針h:處理限定記號（大小寫混合）：名稱的描述部分舉例：achDeleteichMinpachInsertcscrMenu第14頁，共18頁，2023年，2月20日，星期一注釋：源代碼中的文檔代碼的重復：沒有附加信息代碼的解釋：應當改進代碼代碼中的標記：開發(fā)記錄提示，后續(xù)的工作代碼的總結：增加可讀性代碼意圖的描述：問題一級的注釋要注釋還是不要注釋注釋一定要準確不精確的(錯誤的)注釋比沒有注釋更糟第15頁，共18頁，2023年，2月20日，星期一序言性注釋安排在每個程序模塊的起始部分，對程序的整體說明，對于理解程序本身具有引導作用程序或模塊的功能方面的說明：程序或模塊標題、功能界面描述：調(diào)用形式、輸入輸出參數(shù)的意義、引用的子程序重要變量的使用、限制及其它信息開發(fā)歷史：編者（日期）、審查者（日期）、修改（日期）功能性注釋嵌入在源程序體內(nèi)，描述其后的語句或程序段的處理功能描述的對象是一段程序，而不是每一個語句適當使用縮進和空行，使程序與注釋容易區(qū)別第16頁，共18頁，2023年，2月20日，星期一空間布局每行僅寫一條語