69
Software Development for Large and Open Source Projects Kun-Ta Chuang Department of Computer Science and Information Engineering National Cheng Kung University 1

Foundation of software development 2

Embed Size (px)

Citation preview

Page 1: Foundation of software development 2

Software Development for Large and Open Source Projects

Kun-Ta Chuang Department of Computer Science and Information Engineering

National Cheng Kung University

1

Page 2: Foundation of software development 2

Software Development Foundation II

Kun-Ta Chuang Department of Computer Science and Information Engineering

National Cheng Kung University

2

Page 3: Foundation of software development 2

Code Coverage

3

Page 4: Foundation of software development 2

• 歷史 – Code coverage觀念於1963年在Communications

of the ACM 第一次被發表出來。

• 定義 –測試程式碼的涵蓋範圍,涵蓋率越高,代表系統如預期正常運作的面也會比較廣。

–精髓在於” 評估準備的測試案例,程式能執行到的程度為何? ”

–程式好壞 & 測試案例好壞,皆會影響code coverage。

介紹

4

Page 5: Foundation of software development 2

• Line Coverage : – 檢測每行程式碼是否都有被執行到(1行可能有多個

statement)。

• Function Coverage: – 以function為單位,檢測哪些function曾經被測試程式測試過。

• Statement Coverage: – 以statement為測試單位。

• Decision Coverage : – 就像決策樹一般,以每一個決策分歧點,也就是程式執行路徑,為檢測單位。目標為使得每種判定路徑都能執行一次。

Code coverage 種類

5

Page 6: Foundation of software development 2

– Example:

• 於Statement Coverage, case1 (a,b,x) = (2,0,2) 可達到100%

• 於Decision Coverage 需要加上case2 (a,b,x) = (-2,0,2)才能達到100%

Code coverage 種類

Fig1. 要測試的程式 Fig2. case1 coverage

Fig3. case2 coverage 6

Page 7: Foundation of software development 2

• 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)

Code coverage 種類

Fig1. 要測試的程式 7

Page 8: Foundation of software development 2

• 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

Code coverage 種類

8

Page 9: Foundation of software development 2

• EclEmma

–於Eclipse平台,測試Java程式coverage的免費工具。

–優點

• 於workbench直接執行,快速分析程式執行的coverage。

• 直接於code editor,使用不同顏色,標記每行程式執行情況。

• 每支java code 執行的coverage,以表格形式呈現。

• 執行EclEmma,使用者不需做額外專案設定。

使用工具介紹

9

Page 10: Foundation of software development 2

• 輸入http://update.eclemma.org/便可安裝EclEmma工具到eclipse上。

使用工具介紹

10

Page 11: Foundation of software development 2

• Coverage測試結果

使用工具介紹

完全沒被執行

部分被執行

完整被執行

每支java程式執行的coverage(%)

11

Page 12: Foundation of software development 2

• 要開始做coverage測試以前,依據專案需求,想想需要做到哪種程度的測試。

–隨著測試嚴謹度的提升,成本也會相對提高。

–如果是做小型tool開發,或許decision coverage就相當足夠了。

–如果是核子反應爐控制系統呢 ? 或者NASA火箭發射系統,就非得用最終極Multiple Condition Coverage了。

結論

12

Page 13: Foundation of software development 2

• [如何提升系統品質-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

Page 14: Foundation of software development 2

Performance Analysis

14

Page 15: Foundation of software development 2

• 歷史 – 於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

Page 16: Foundation of software development 2

• performance analysis又稱profiling

• 為動態程式分析的形式,分析的要點可能有以下 : –程式的空間(使用的memory)複雜度

–程式的時間複雜度

–特定指令的使用比例

– Function call的頻率以及持續時間

• 為什麼要做性能分析? –主要原因在於想辦法將程式最佳化

介紹

16

Page 17: Foundation of software development 2

• Profiler使用多種技術來進行資料蒐集

– hardware interrupts

– code instrumentation

• 插入特定程式於某元件中,當程式執行後便會輸出分析結果。但缺點可能會拉大程式執行時間。

– instruction set simulation

– operating system hooks

– performance counters

• 可用來記錄電腦系統中硬體相關動作執行次數。

Profiler的使用

17

Page 18: Foundation of software development 2

• 提供於JVM上執行的應用程式的詳細訊息。

• 提供圖形化介面,讓使用者更方便觀看Java應用程式性能相關訊息,如CPU使用量、執行緒狀態、記憶體使用量等等。

相關工具介紹 - VisualVM

18

Page 19: Foundation of software development 2

相關工具介紹 - VisualVM

應用程式 詳細資訊

列出使用 最多空間 的前幾個 物件的類 別名稱

Fig1. 應用程式資訊圖 19

Page 20: Foundation of software development 2

相關工具介紹 - VisualVM

Fig2. 監視器圖

CPU使用(%)

記憶體(heap)使用量

20

Page 21: Foundation of software development 2

相關工具介紹 - VisualVM

Fig3. 程式每個執行緒狀態 21

Page 22: Foundation of software development 2

相關工具介紹 - VisualVM

Fig4. 每種類別物件於記憶體使用量(Live) 22

Page 23: Foundation of software development 2

• Wiki Profiling (computer programming) http://en.wikipedia.org/wiki/Performance_analysis

• VisualVM 1.3.4

http://visualvm.java.net/

參考資料

23

Page 24: Foundation of software development 2

Issue tracking system

24

Page 25: Foundation of software development 2

• What is issue tracking system?

• Why we need issue tracking system?

• Issue tracking system

Outline

25

Page 26: Foundation of software development 2

• Issue Tracking system – 紀錄、追蹤問題的系統

• 一個好的Issue紀錄應該包含: – 總結

• 以大約一個句子來描述issue(bug),讓人能清楚知道這個issue是什麼

– 重新產生issue(bug)的步驟 • 描述如何找到bug的

– 預期會發生什麼以及實際發生什麼 • 說明你認為應該發生什麼,而實際又發生什麼,對於尋找與使用情節或需求

有關的問題特別有幫助

– 版本、平台、location(地區與語言)資訊 • 使用什麼軟體版本、基於什麼平台等等的基礎資訊

– 嚴重性(severity)與優先權(priority) • 此issue有多嚴重?資料損毀?系統當掉? • 修復此issue的重要性如何? • 優先權與嚴重性是分開的

– ex:有可能對系統嚴重性高,但只會出現在某些特別的操作情形,那可能就是個低優先權高嚴重性的issue

What is issue tracking system?

26

Page 27: Foundation of software development 2

• 在沒有使用issue tracking system前…

–很難知道現在每個人手上正在處理那些issue(bug)

– bug的處理優先權難以紀錄、界定

–無法追蹤過往issue

–沒人知道到底發生了多少bug

Why we need issue tracking system?

27

Page 28: Foundation of software development 2

• 使用issue tracking system後… – 紀錄討論、測試、程式碼修改、驗證、與issue相關決策歷程,藉由追蹤記錄每一件事情,整個團隊知道issue的進展狀況、如何修正、或者原開發者認為該如何修正

– 讓你深入了解專案的實際進度,多數的issue都來自於哪裡? 剩下多少issue尚未被解決?解決了多少issue?

– 有些團隊會在產品釋出以前,尋求zero-bug-bounce,表示所有重要的issue跟bug都在產品釋出前被修復

– 若搭配CI,更可以快速抓到issue,且責任歸屬清楚,issue透明化

Why we need issue tracking system?

28

Page 29: Foundation of software development 2

• Issue tracking的工具很多,有免費也有付費,有的除了issue tracking,也另外整合許多專案管理的內容,比較像是project management system

• Bugzilla

• codeBeamer

• Trac

• JIRA

Issue tracking system

29

Page 30: Foundation of software development 2

• 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!

Bugzilla

30

Page 31: Foundation of software development 2

Bugzilla Login

31

Page 32: Foundation of software development 2

Bugzilla 創建bug record

Status & Email setting

32

Page 33: Foundation of software development 2

Bugzilla

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

33

Page 34: Foundation of software development 2

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

34

Page 35: Foundation of software development 2

Bugzilla

35

Page 36: Foundation of software development 2

Bugzilla-graphical report

36

Page 37: Foundation of software development 2

Bugzilla-graphical report

37

Page 38: Foundation of software development 2

• 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&fid=12

Reference

38

Page 39: Foundation of software development 2

Software release life cycle

39

Page 40: Foundation of software development 2

• 軟體版本週期是指電腦軟體的發展及發行過程,如右圖 – 開發期

• Pre-alpha(準預覽版本)

• Alpha(預覽版本)

• Beta(測試版本)

• Released candidate (最終測試版本)

– 完成期 • RTM(Release to Manufacturing)

• GA(General Availability)

• Gold(完成版)

40

Page 41: Foundation of software development 2

• Pre-alpha

–有時候軟體會在Alpha或Beta版本前先釋出Pre-alpha版本。

–相對於Alpha或Beta版本,Pre-alpha版本是一個功能不完整的版本

41

Page 42: Foundation of software development 2

• Alpha

– Alpha版本仍然需要測試,其功能亦未完善,因為它是整個軟體釋出周期中的第一個階段,所以它的名稱是「Alpha」

42

Page 43: Foundation of software development 2

• Beta

–軟體最早對外公開的軟體版本,由公眾參與測試

–包含所有功能,但可能有一些已知問題和較輕微的程式錯誤(BUG)

–測試者通常是開發軟體組織的客戶,他們會以免費或優惠價錢得到軟體

43

Page 44: Foundation of software development 2

• Release Candidate(簡稱RC)

–可能成為最終產品的候選版本,如果未出現問題則可釋出成為正式版本

–此階段的產品通常包含所有功能、或接近完整,亦不會出現嚴重問題

–多數開源軟體會推出兩個RC版本,最後的RC2則成為正式版本

–亦稱Gamma(更後期的稱為Delta,及其後的希臘字母)

44

Page 45: Foundation of software development 2

• RTM(Release To Manufacturing)

–意思是:發放給生產商

– RTM版本並不一定意味著創作者制定了軟體所有問題;仍有可能向公眾發布更新的版本。

–另外一種RTM的稱呼是RTW(Release To Web)

• 表示正式版本的軟體發布到 Web 網站上供客戶免費下載

• 這個名詞在ASP.NET元件以及Silverlight的發布上很常見

45

Page 46: Foundation of software development 2

• 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

Page 47: Foundation of software development 2

Hotfix

• 針對某一個具體的系統漏洞或安全問題而發佈的專門解決該漏洞或安全問題的小程式,通常稱為修補程式

• WindowsXP-KB823980-x86-CHS32λ.exe – Windows XP——產品名稱,說明該補丁適用的作業系統 – KB823980——KB是Knowledge Base的首字母縮寫,意即

基本知識庫,823980是該補丁在微軟知識庫中相應的說明性文章的編號

– x86——處理器平臺的標識,示例中x86說明該補丁應用於Intel 公司的x86構架的處理器平臺

– CHS32λ.exe——語言版本的標識。示例中的CHS表明該補丁應用於中文版的Windows作業系統

Page 48: Foundation of software development 2

Service Pack

• 意即補丁包

• 微軟的作業系統及軟體產品漏洞很多,微軟不得不頻繁地發佈各種Hotfix來進行修補

• 對一般用戶來說,要查看自己的電腦是否安裝了某個Hotfix是一件麻煩事,下載安裝各種Hotfix也很繁瑣 –微軟為了解決問題,就開始發佈SP補丁包,SP補丁包中包含有SP發佈日期前所發佈的所有Hotfix

Page 50: Foundation of software development 2

GNU General Public License

50

Page 51: Foundation of software development 2

Overview

• Software license

– Open-source/free software licenses

• GNU General Public License(GPL)

– GPL歷史

– CPL與Copyright/Copyleft比較

– GPL的優勢

–結論

51

Page 52: Foundation of software development 2

Software license

• 軟體授權條款(Software license)

–具有法律性質的合約或規範,目的在規範受著作權保護的軟體的使用或散佈行為。

–若無授權而徑予使用該軟體,將違反著作權法給予該軟體開發者的專屬保護。

–主要分為

• Proprietary software

• Open source software

52

Page 53: Foundation of software development 2

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

Page 54: Foundation of software development 2

GPL歷史

• 由Richard M. Stallman發起於1983年9月27日的Free Software Mass collaboration

• 目標是建立一套完全自由的作業系統GNU

• GNU是「GNU’s Not Unix」的縮寫

• GPLv1 – 其目的是防止那些阻礙自由軟體的行為

• GPLv2 – 添加了“Liberty or Death”條款

• GPLv3

54

Page 55: Foundation of software development 2

GNU General Public License

• GNU GPL是一種授權聲明 –即有一軟體宣稱是以GPL釋出的,就代表他是完全自由的,有的會提供原始碼供人下載、使用、複製,甚至販賣、修改

• GPL的特別之處 –須先接受GNU GPL的條款才可使用GNU GPL,如果修改了GPL的軟體,但不願釋出,僅僅是失去釋出的權力而已。一旦釋出即代表接受條款,此釋出版本也自動成為GNU GPL軟體,而其他人可以放心使用及修改此軟體

55

Page 56: Foundation of software development 2

GPL和Copyright

• GNU GPL 是一種授權聲明,卻不是Copyright – Copyright 是軟體作者在創作軟體時所產生的權利

– GNU GPL 則是軟體作者所採用的授權條款

– 同一個軟體可以有多種授權,使用者可以從其中挑選一個對自己最有利的授權。軟體作者也可以隨時改變該軟體的授權(需要其著作權擁有者一致同意)

– GNU GPL 本身是無法修改的。當軟體以 GNU GPL 發行時,它就是以完整的 GNU GPL 發行,不能再加上任何其它額外的限制或但書。

56

Page 57: Foundation of software development 2

GPL和Copyleft

• 將 GNU GPL / GNU LGPL / GNU GFDL 的軟體或文件,其著作權稱為 Copyleft

---Richard M. Stallman

http://www.gnu.org/copyleft/copyleft.html

–因為它的授權已回歸於大眾,即使是作者反悔,也無法將授權取回

57

Page 58: Foundation of software development 2

GNU GPL 的優勢

• 採用 GPL 授權的軟體一定會同時公開它的原始碼,所以程式設計師可以自由的在 GPL 軟體中加入新的功能、修正舊有的問題

• 和傳統商業軟體之間最顯著的差異在於:

–自由軟體鼓勵你拷貝

–自由軟體允許你研究、改良

• 「站在巨人的肩膀上」,對於科技的進步有著巨大的影響。

58

Page 59: Foundation of software development 2

結論

• Linus' Law:只要有夠多的眼睛注視,所有的蟲兒 (bugs) 都很淺顯。

• 自由軟體的發展就是在開放網路社群這樣的運作方式下進行,社群人數到達一定的臨界點之後,Linus' Law 就會成立

• 自由軟體的成長循環:社群越大,軟體越好;軟體越好,使用者越多;使用者越多,社群越大。

59

Page 60: Foundation of software development 2

Memory Leak

60

Page 61: Foundation of software development 2

Overview

• 簡介

• C/C++

• Java/C#

• 避免與偵測Memory Leak

61

Page 62: Foundation of software development 2

簡介

• Memory Leak定義

–通常因為人為的程式設計失誤,被配置的memory無法再被使用,也無法被釋放

• 消耗過多內部記憶體會導致

–降低電腦效能

–可能會使得部分或全部裝置停止工作

62

Page 63: Foundation of software development 2

C/C++

• 由於無Garbage Collector(GC)的機制,程式設計師必須在使用完資源後人為釋放。

• 例子

配制memory 但是並無釋放

雖然後面有使用free 但此處memory 並沒有被釋放

63

Page 64: Foundation of software development 2

C發生memory leak 導致記憶體使用量過多

且開始發生swapping

關閉程式

64

Page 65: Foundation of software development 2

Java/C#

• 有Garbage Collector(GC)的機制,不需要人為釋放記憶體,降低發生memory leak的可能性

• 仍有發生memory leak的可能

–例子:

只要memoryLeakArea仍在使用 GC也無法回收沒用到的Integer

65

Page 66: Foundation of software development 2

Java 發生memory leak

Heap memory已被用完

當資料量不大時,有極大的可能是發生memory leak

66

Page 67: Foundation of software development 2

Java發生memory leak的原因

• 其中classA佔了很長的生命週期,當中classA使用了classB的物件,即使便沒再用到,但是classB卻因為classA仍然在使用,所以占了此部分的記憶體,並不會被GC回收

http://www.ibm.com/developerworks/library/j-leaks/

67

Page 68: Foundation of software development 2

避免Memory Leak

• C++除了在每次new配置記憶體後,需要小心的delete之外,C++的STL中,提供smart pointer的概念

• 以偵測工具偵測memory leak

– VC++可使用VLD

改成

無須寫delete

明確指出發生memory leak的行數 可查看未釋放記憶體中的詳細內容 http://eagle-sw.blogspot.tw/2011/11/vc-vldmemory-leak.html

68

Page 69: Foundation of software development 2

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: ==6968== definitely lost: 40 bytes in 1 blocks. ==6968== possibly lost: 0 bytes in 0 blocks. ==6968== still reachable: 0 bytes in 0 blocks. ==6968== suppressed: 0 bytes in 0 blocks.

leak summary中確切寫出definitely lost:40 bytes in 1 block

結論報告

http://daydreamer.idv.tw/rewrite.php/read-18.html

69