![參考資料
• [如何提升系統品質-Day24]測試 – Code Coverage
http://ithelp.ithome.com.tw/question/10080981
• Wiki Code Coverage
http://en.wikipedia.org/wiki/Code_coverage#Software_tools
• 使用 EclEmma 进行覆盖测试
http://www.ibm.com/developerworks/cn/java/j-lo-
eclemma/index.html
• Java Code Coverage for Eclipse
http://www.eclemma.org/index.html
13](https://image.slidesharecdn.com/foundationofsoftwaredevelopment2-121023044241-phpapp02/85/Foundation-of-software-development-2-13-320.jpg)
![Linux下的偵測Memory Leak
• 使用
– Commend line下輸入 valgrind –leak-check=yes [your program]
• 範例: 結論報告
==6968== ERROR SUMMARY: 1 errors from 1 contexts
(suppressed: 11 from 1)
==6968== malloc/free: in use at exit: 40 bytes in 1 blocks.
==6968== malloc/free: 1 allocs, 0 frees, 40 bytes allocated.
==6968== For counts of detected errors, rerun with: -v
==6968== searching for pointers to 1 not-freed blocks.
==6968== checked 57,912 bytes.
==6968==
==6968==
==6968== 40 bytes in 1 blocks are definitely lost in loss
record 1 of 1
==6968== at 0x401B7E9: malloc (vg_replace_malloc.c:207)
==6968== by 0x80483E7: f (in /root/test/lm)
==6968== by 0x804841C: main (in /root/test/lm)
==6968==
==6968== LEAK SUMMARY:
leak summary中確切寫出
==6968== definitely lost: 40 bytes in 1 blocks.
definitely lost:40 bytes in 1
==6968== possibly lost: 0 bytes in 0 blocks.
http://daydreamer.idv.tw/rewrite.php/read-18.html ==6968== still reachable: 0 bytes in 0 blocks.
block
==6968== suppressed: 0 bytes in 0 blocks.
69](https://image.slidesharecdn.com/foundationofsoftwaredevelopment2-121023044241-phpapp02/85/Foundation-of-software-development-2-69-320.jpg)
Foundation of software development 2
- 1. Software Development for Large and Open Source Projects Kun-Ta Chuang Department of Computer Science and Information Engineering National Cheng Kung University 1
- 2. Software Development Foundation II Kun-Ta Chuang Department of Computer Science and Information Engineering National Cheng Kung University 2
- 3. Code Coverage 3
- 4. 介紹 • 歷史 – Code coverage觀念於1963年在Communications of the ACM 第一次被發表出來。 • 定義 – 測試程式碼的涵蓋範圍，涵蓋率越高，代表系 統如預期正常運作的面也會比較廣。 – 精髓在於” 評估準備的測試案例，程式能執行 到的程度為何? ” – 程式好壞 & 測試案例好壞，皆會影響code coverage。 4
- 5. Code coverage 種類 • Line Coverage : – 檢測每行程式碼是否都有被執行到(1行可能有多個 statement)。 • Function Coverage： – 以function為單位，檢測哪些function曾經被測試程 式測試過。 • Statement Coverage： – 以statement為測試單位。 • Decision Coverage : – 就像決策樹一般，以每一個決策分歧點，也就是程 式執行路徑，為檢測單位。目標為使得每種判定路 徑都能執行一次。 5
- 6. Code coverage 種類 – Example: • 於Statement Coverage, case1 (a,b,x) = (2,0,2) 可達到 100% • 於Decision Coverage 需要加上case2 (a,b,x) = (-2,0,2)才能 達到100% Fig1. 要測試的程式 Fig2. case1 coverage Fig3. case2 coverage 6
- 7. Code coverage 種類 • Condition Coverage： – 將判斷式裡面的陳述式(sub-expression)，每一種陳 述式所回傳的False及True兩種情境都要測到。 – 補足Decision Coverage僅測試程式路徑的不足之處。 – Example. Fig1的程式，要準備哪些測試案例才能達 到Condition Coverage100%呢? • Ans : case1 (2,1,-1) -> exp1(True, False), exp2(True, False) case2 (-1,0,1) -> exp1(False, True), exp2(False, True) 7 Fig1. 要測試的程式
- 8. Code coverage 種類 • Condition/Decision Coverage : – 綜合版測試法。 – 除了判斷式中每個陳述式都要測true/false，也要測試各種路 徑結果。 • Multiple Condition Coverage： – 將每一陳述式，以2^n種組合一一去測試。 – Example. If (a && b || c) then ~ • Case1 : a=false, b=false, c=false • Case2 : a=false, b=false, c=true • Case3 : a=false, b=true, c=false • Case4 : a=false, b=true, c=true • Case5 : a=true, b=false, c=false • Case6 : a=true, b=false, c=true • Case7 : a=true, b=true, c=false • Case8 : a=true, b=true, c=true 8
- 9. 使用工具介紹 • EclEmma – 於Eclipse平台，測試Java程式coverage的免費工具。 – 優點 • 於workbench直接執行，快速分析程式執行的coverage。 • 直接於code editor，使用不同顏色，標記每行程式執 行情況。 • 每支java code 執行的coverage，以表格形式呈現。 • 執行EclEmma，使用者不需做額外專案設定。 9
- 10. 使用工具介紹 • 輸入http://update.eclemma.org/便可安裝 EclEmma工具到eclipse上。 10
- 11. 使用工具介紹 • Coverage測試結果 完全沒被執行 部分被執行 完整被執行 每支java程式執 行的coverage(%) 11
- 12. 結論 • 要開始做coverage測試以前，依據專案需求， 想想需要做到哪種程度的測試。 – 隨著測試嚴謹度的提升，成本也會相對提高。 – 如果是做小型tool開發，或許decision coverage 就相當足夠了。 – 如果是核子反應爐控制系統呢 ? 或者NASA火箭 發射系統，就非得用最終極Multiple Condition Coverage了。 12
- 13. 參考資料 • [如何提升系統品質-Day24]測試 – Code Coverage http://ithelp.ithome.com.tw/question/10080981 • Wiki Code Coverage http://en.wikipedia.org/wiki/Code_coverage#Software_tools • 使用 EclEmma 进行覆盖测试 http://www.ibm.com/developerworks/cn/java/j-lo- eclemma/index.html • Java Code Coverage for Eclipse http://www.eclemma.org/index.html 13
- 14. Performance Analysis 14
- 15. 介紹 • 歷史 – 於1970，出現為IBM/360、IBM/370平台使用的性能 分析工具，根據計時器中斷，找尋程式的”hot spots”。 – 於1974，Instruction Set Simulator可以進行完整追蹤。 – 於1979，Profiler-driven program analysis問世。 • 於Unix上，透過prof這個工具，列出每個function以及對 應花費的執行時間。 – 於1994，Amitabh Srivastava 和 Alan Eustace 發表一 份關於ATOM的paper。 • 可以將程式於compile time時插入幾行分析用程式碼，這 些程式碼將會輸出分析結果。 15
- 16. 介紹 • performance analysis又稱profiling • 為動態程式分析的形式，分析的要點可能 有以下 : – 程式的空間(使用的memory)複雜度 – 程式的時間複雜度 – 特定指令的使用比例 – Function call的頻率以及持續時間 • 為什麼要做性能分析? – 主要原因在於想辦法將程式最佳化 16
- 17. Profiler的使用 • Profiler使用多種技術來進行資料蒐集 – hardware interrupts – code instrumentation • 插入特定程式於某元件中，當程式執行後便會輸出 分析結果。但缺點可能會拉大程式執行時間。 – instruction set simulation – operating system hooks – performance counters • 可用來記錄電腦系統中硬體相關動作執行次數。 17
- 18. 相關工具介紹 - VisualVM • 提供於JVM上執行的應用程式的詳細訊息。 • 提供圖形化介面，讓使用者更方便觀看Java 應用程式性能相關訊息，如CPU使用量、執 行緒狀態、記憶體使用量等等。 18
- 19. 相關工具介紹 - VisualVM 應用程式 詳細資訊 列出使用 最多空間 的前幾個 物件的類 別名稱 19 Fig1. 應用程式資訊圖
- 20. 相關工具介紹 - VisualVM CPU使用(%) 記憶體(heap)使用量 Fig2. 監視器圖 20
- 21. 相關工具介紹 - VisualVM 21 Fig3. 程式每個執行緒狀態
- 22. 相關工具介紹 - VisualVM Fig4. 每種類別物件於記憶體使用量(Live) 22
- 23. 參考資料 • Wiki Profiling (computer programming) http://en.wikipedia.org/wiki/Performance_an alysis • VisualVM 1.3.4 http://visualvm.java.net/ 23
- 24. Issue tracking system 24
- 25. Outline • What is issue tracking system? • Why we need issue tracking system? • Issue tracking system 25
- 26. What is issue tracking system? • Issue Tracking system – 紀錄、追蹤問題的系統 • 一個好的Issue紀錄應該包含: – 總結 • 以大約一個句子來描述issue(bug)，讓人能清楚知道這個issue是什麼 – 重新產生issue(bug)的步驟 • 描述如何找到bug的 – 預期會發生什麼以及實際發生什麼 • 說明你認為應該發生什麼，而實際又發生什麼，對於尋找與使用情節或需求 有關的問題特別有幫助 – 版本、平台、location(地區與語言)資訊 • 使用什麼軟體版本、基於什麼平台等等的基礎資訊 – 嚴重性(severity)與優先權(priority) • 此issue有多嚴重?資料損毀?系統當掉? • 修復此issue的重要性如何? • 優先權與嚴重性是分開的 – ex:有可能對系統嚴重性高，但只會出現在某些特別的操作情形，那可能 就是個低優先權高嚴重性的issue 26
- 27. Why we need issue tracking system? • 在沒有使用issue tracking system前… – 很難知道現在每個人手上正在處理那些 issue(bug) – bug的處理優先權難以紀錄、界定 – 無法追蹤過往issue – 沒人知道到底發生了多少bug 27
- 28. Why we need issue tracking system? • 使用issue tracking system後… – 紀錄討論、測試、程式碼修改、驗證、與issue相關 決策歷程，藉由追蹤記錄每一件事情，整個團隊知 道issue的進展狀況、如何修正、或者原開發者認為 該如何修正 – 讓你深入了解專案的實際進度，多數的issue都來自 於哪裡? 剩下多少issue尚未被解決?解決了多少 issue? – 有些團隊會在產品釋出以前，尋求zero-bug-bounce， 表示所有重要的issue跟bug都在產品釋出前被修復 – 若搭配CI，更可以快速抓到issue，且責任歸屬清楚， issue透明化 28
- 29. Issue tracking system • Issue tracking的工具很多，有免費也有付費， 有的除了issue tracking，也另外整合許多專 案管理的內容，比較像是project management system • Bugzilla • codeBeamer • Trac • JIRA 29
- 30. Bugzilla • Track bugs and code changes • Communicate with teammates • Submit and review patches • Manage quality assurance (QA) • Free • Many companies, organizations and projects use Bugzilla. – Mozilla – Linux kernel – Apache Project – Red Hat – Facebook – NASA – Yahoo! 30
- 31. Bugzilla Login 31
- 32. Bugzilla 創建bug record Status & Email setting 32
- 35. Bugzilla 35
- 36. Bugzilla-graphical report 36
- 37. Bugzilla-graphical report 37
- 38. Reference • Head First Software Development – Dan Pilone & Russ Miles • http://en.wikipedia.org/wiki/Bug_tracking_system • http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems#Notification _interfaces • http://www.bugzilla.org • http://tw.myblog.yahoo.com/embedded_system_book/photo?pid=0&prev=693&fi d=12 38
- 39. Software release life cycle 39
- 40. • 軟體版本週期是指電腦軟體的發 展及發行過程，如右圖 – 開發期 • Pre-alpha（準預覽版本） • Alpha（預覽版本） • Beta（測試版本） • Released candidate （最終測試版本） – 完成期 • RTM(Release to Manufacturing) • GA(General Availability) • Gold（完成版） 40
- 41. • Pre-alpha – 有時候軟體會在Alpha或Beta版本前先釋出Pre- alpha版本。 – 相對於Alpha或Beta版本，Pre-alpha版本是一個 功能不完整的版本 41
- 42. • Alpha – Alpha版本仍然需要測試，其功能亦未完善，因 為它是整個軟體釋出周期中的第一個階段，所 以它的名稱是「Alpha」 42
- 43. • Beta – 軟體最早對外公開的軟體版本，由公眾參與測 試 – 包含所有功能，但可能有一些已知問題和較輕 微的程式錯誤（BUG） – 測試者通常是開發軟體組織的客戶，他們會以 免費或優惠價錢得到軟體 43
- 44. • Release Candidate(簡稱RC) – 可能成為最終產品的候選版本，如果未出現問 題則可釋出成為正式版本 – 此階段的產品通常包含所有功能、或接近完整， 亦不會出現嚴重問題 – 多數開源軟體會推出兩個RC版本，最後的RC2 則成為正式版本 – 亦稱Gamma（更後期的稱為Delta，及其後的希 臘字母） 44
- 45. • RTM（Release To Manufacturing） – 意思是：發放給生產商 – RTM版本並不一定意味著創作者制定了軟體所 有問題;仍有可能向公眾發布更新的版本。 – 另外一種RTM的稱呼是RTW（Release To Web） • 表示正式版本的軟體發布到 Web 網站上供客戶免費 下載 • 這個名詞在ASP.NET元件以及Silverlight的發布上很常 見 45
- 46. • GA(General Availability) – 正式發佈的版本，在國外都是用GA來說明 release版本的 – the point where all necessary commercialization activities have been completed and the software has been made available to the general market 46
- 47. Hotfix • 針對某一個具體的系統漏洞或安全問題而發佈的專 門解決該漏洞或安全問題的小程式，通常稱為修補 程式 • WindowsXP-KB823980-x86-CHS32λ.exe – Windows XP——產品名稱，說明該補丁適用的作業系統 – KB823980——KB是Knowledge Base的首字母縮寫，意即 基本知識庫，823980是該補丁在微軟知識庫中相應的 說明性文章的編號 – x86——處理器平臺的標識，示例中x86說明該補丁應用 於Intel 公司的x86構架的處理器平臺 – CHS32λ.exe——語言版本的標識。示例中的CHS表明該 補丁應用於中文版的Windows作業系統
- 48. Service Pack • 意即補丁包 • 微軟的作業系統及軟體產品漏洞很多，微 軟不得不頻繁地發佈各種Hotfix來進行修補 • 對一般用戶來說，要查看自己的電腦是否 安裝了某個Hotfix是一件麻煩事，下載安裝 各種Hotfix也很繁瑣 – 微軟為了解決問題，就開始發佈SP補丁包，SP 補丁包中包含有SP發佈日期前所發佈的所有 Hotfix
- 49. Reference • http://en.wikipedia.org/wiki/Software_releas e_life_cycle • http://forum.icst.org.tw/phpbb/viewtopic.php ?t=3953 49
- 50. GNU General Public License 50
- 51. Overview • Software license – Open-source/free software licenses • GNU General Public License(GPL) – GPL歷史 – CPL與Copyright/Copyleft比較 – GPL的優勢 – 結論 51
- 52. Software license • 軟體授權條款(Software license) – 具有法律性質的合約或規範，目的在規範受著 作權保護的軟體的使用或散佈行為。 – 若無授權而徑予使用該軟體，將違反著作權法 給予該軟體開發者的專屬保護。 – 主要分為 • Proprietary software • Open source software 52
- 53. Open-source/free software licenses • 自由軟體是開放原始碼的一種 • 自由軟體要視該軟體的授權條件是否合乎Free Software Foundation所下的定義 • Free software licenses – 與GPL 2相容 • Boost Software License, BSD license (modified version) ,Public Domain ,etc. – 與GPL 2不相容 • Academic Free License (AFL) , Apache License , BSD license (original version) , Common Public License ,etc. 53
- 54. GPL歷史 • 由Richard M. Stallman發起於1983年9月27日的 Free Software Mass collaboration • 目標是建立一套完全自由的作業系統GNU • GNU是「GNU’s Not Unix」的縮寫 • GPLv1 – 其目的是防止那些阻礙自由軟體的行為 • GPLv2 – 添加了“Liberty or Death”條款 • GPLv3 54
- 55. GNＵ General Public License • GNU GPL是一種授權聲明 – 即有一軟體宣稱是以GPL釋出的，就代表他是 完全自由的，有的會提供原始碼供人下載、使 用、複製，甚至販賣、修改 • GPL的特別之處 – 須先接受GNU GPL的條款才可使用GNU GPL，如 果修改了GPL的軟體，但不願釋出，僅僅是失 去釋出的權力而已。一旦釋出即代表接受條款， 此釋出版本也自動成為GNU GPL軟體，而其他 人可以放心使用及修改此軟體 55
- 56. GPL和Copyright • GNU GPL 是一種授權聲明，卻不是Copyright – Copyright 是軟體作者在創作軟體時所產生的權利 – GNU GPL 則是軟體作者所採用的授權條款 – 同一個軟體可以有多種授權，使用者可以從其中挑選 一個對自己最有利的授權。軟體作者也可以隨時改變 該軟體的授權(需要其著作權擁有者一致同意) – GNU GPL 本身是無法修改的。當軟體以 GNU GPL 發行 時，它就是以完整的 GNU GPL 發行，不能再加上任何 其它額外的限制或但書。 56
- 57. GPL和Copyleft • 將 GNU GPL / GNU LGPL / GNU GFDL 的軟體 或文件，其著作權稱為 Copyleft ---Richard M. Stallman http://www.gnu.org/copyleft/copyleft.html – 因為它的授權已回歸於大眾，即使是作者反悔， 也無法將授權取回 57
- 58. GNU GPL 的優勢 • 採用 GPL 授權的軟體一定會同時公開它的 原始碼，所以程式設計師可以自由的在 GPL 軟體中加入新的功能、修正舊有的問題 • 和傳統商業軟體之間最顯著的差異在於： – 自由軟體鼓勵你拷貝 – 自由軟體允許你研究、改良 • 「站在巨人的肩膀上」，對於科技的進步 有著巨大的影響。 58
- 59. 結論 • Linus' Law：只要有夠多的眼睛注視，所有 的蟲兒 (bugs) 都很淺顯。 • 自由軟體的發展就是在開放網路社群這樣 的運作方式下進行，社群人數到達一定的 臨界點之後，Linus' Law 就會成立 • 自由軟體的成長循環：社群越大，軟體越 好；軟體越好，使用者越多；使用者越多， 社群越大。 59
- 60. Memory Leak 60
- 61. Overview • 簡介 • C/C++ • Java/C# • 避免與偵測Memory Leak 61
- 62. 簡介 • Memory Leak定義 – 通常因為人為的程式設計失誤，被配置的 memory無法再被使用，也無法被釋放 • 消耗過多內部記憶體會導致 – 降低電腦效能 – 可能會使得部分或全部裝置停止工作 62
- 63. Ｃ/Ｃ＋＋ • 由於無Garbage Collector(GC)的機制，程式 設計師必須在使用完資源後人為釋放。 • 例子 配制memory 但是並無釋放 雖然後面有使用 free 但此處memory 並沒有被釋放 63
- 64. C發生memory leak 導致記憶體使用量過多 關閉程式 且開始發生swapping 64
- 65. Java/C# • 有Garbage Collector(GC)的機制，不需要人 為釋放記憶體，降低發生memory leak的可 能性 • 仍有發生memory leak的可能 – 例子: 只要memoryLeakArea仍在使用 GC也無法回收沒用到的Integer 65
- 66. Java 發生memory leak 當資料量不大時， 有極大的可能是發 生memory leak Heap memory已被用完 66
- 67. Java發生memory leak的原因 • 其中classA佔了很長的生命週期，當中classA使用了classB 的物件，即使便沒再用到，但是classB卻因為classA仍然在 使用，所以占了此部分的記憶體，並不會被GC回收 http://www.ibm.com/developerworks/library/j-leaks/ 67
- 68. 避免Memory Leak • C++除了在每次new配置記憶體後，需要小心的delete 之外，C++的STL中，提供smart pointer的概念 改成 無須寫delete • 以偵測工具偵測memory leak – VC++可使用VLD 明確指出發生memory leak的行數 可查看未釋放記憶體中的詳 http://eagle-sw.blogspot.tw/2011/11/vc-vldmemory-leak.html 細內容 68
- 69. Linux下的偵測Memory Leak • 使用 – Commend line下輸入 valgrind –leak-check=yes [your program] • 範例: 結論報告 ==6968== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 1) ==6968== malloc/free: in use at exit: 40 bytes in 1 blocks. ==6968== malloc/free: 1 allocs, 0 frees, 40 bytes allocated. ==6968== For counts of detected errors, rerun with: -v ==6968== searching for pointers to 1 not-freed blocks. ==6968== checked 57,912 bytes. ==6968== ==6968== ==6968== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==6968== at 0x401B7E9: malloc (vg_replace_malloc.c:207) ==6968== by 0x80483E7: f (in /root/test/lm) ==6968== by 0x804841C: main (in /root/test/lm) ==6968== ==6968== LEAK SUMMARY: leak summary中確切寫出 ==6968== definitely lost: 40 bytes in 1 blocks. definitely lost:40 bytes in 1 ==6968== possibly lost: 0 bytes in 0 blocks. http://daydreamer.idv.tw/rewrite.php/read-18.html ==6968== still reachable: 0 bytes in 0 blocks. block ==6968== suppressed: 0 bytes in 0 blocks. 69