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

33. Bugzilla
可以編輯你的Bug record，設定重要程度、cc名單等等, etc
33

34. Bugzilla
當bug被修改後，會依照你設定的名單寄發email，通知相關人員
34

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