軟體測試與驗證

軟體測試與驗證 台北科技大學資訊工程系郭忠義

軟體測試重要性 (1) • 2007 • 台灣高鐵售票系統上線後當機連連，系統無法應付突然湧現的購票人潮（no stress testing) • 2007 • 台灣彩卷系統：十億獎金引爆人潮，當機連連。 • 2000-2005 • 巴拿馬國家癌症中心，5個病人接受過量迦瑪射線照射死亡，15人引發嚴重併發症。 • 2003 • 軟體錯誤造成美國東北部及加拿大停電，5000萬人受影響，3人喪生。

軟體測試重要性 (2) • 2000 • 控制軟體問題，美國海軍飛機墜落，4人喪生。 • 1997 • 韓國空難，225人喪生（雷達控制軟體問題） • 1995 • 美國航空在哥倫比亞撞山159人喪生（導航軟體問題） • 1994 • 華航名古屋空難：自動駕駛軟體(Auto-Pilot)重飛模式和手操作的控制桿之昇降舵相互對抗。

軟體測試重要性 (3) • 1963年美國太空總署，一個FORTRAN 程式迴圈敘述案例 • DO 5 I=1,3 ------(正確) • 被人為錯誤打成 • DO 5 I=1.3 -------(錯誤) • FORTRAN編譯器視為 • DO5I=1.3 --------(缺陷) • 導致飛往火星的火箭爆炸(失效)，造成一千萬美元的損失。

品質控管 • 2002 • 美國國家標準局報告─軟體品質問題，每年造成595億美元（0.6％ GDP） • 軟體是一項產品(product) • 好的產品需要品質控管(Quality control, QC)和品質保證(Quality assurance, QA)

製造業原則 • 製造業的世界 • 產品品質(quality)是很重要的因素 • 當投入成本與原物料後，生產出100個產品，永遠希望這100個都是可以賣的。 • QC (Quality Control) 品質控管 • 製造過程從設計到生產可能有數十道到幾百道程序。 • 每一道程序都可能影響到後面的品質。 • 如何透過製造流程的改善(process improvement)提高良率，一直是製造工業的重要課題。

製造業品質改善 • 最好的改善品質的方式 • 製造過程中使用機器-自動化。 • 機器不容易犯錯且可不斷重複單調無聊工作。 • 機器出錯時通常由於其磨損，須重新校正。 • Ex.日本步進馬達精確度超高的秘密。 • Question • 當某部分工作不能由機器來做時，製造過程如何做到品質控管？

製造業生產線 (1)

製造業生產線 (2) • 每個生產線員工只做一件簡單到不容易出錯的工作。 • 生產線員工不需要太聰明。 • 生產線將複雜產品製造切割成許多小步驟，可在短時間及最少技術內完成。 • 發現產品的問題、錯誤，並不難。

製造業流程 • Idea(概念） • Marketing analysis (市場分析） • Analysis and Design(分析與設計） • Manufacturing (QC) (製造） • Testing (QA)(測試） • Release product(產品出廠）

軟體製造流程 • 概念(Idea） • 需求分析與規格 (Requirement analysis and specification-100% design) • 分析與設計(System analysis and design - QC) • 程式實做(Implementation- QC) • 製造(Manufacturing - compilation – no cost manufacturing) • 測試(Testing-QA)

Question • 寫程式是設計還是製造過程？ • 程式碼是一種設計還是產品？ • 如果寫程式不是設計過程，是否可請生產線女工製造，控制品質？ • 如果寫程式是設計過程，則，會發生不可見的錯誤，因為設計是一種複雜的過程。

QC趨勢 產品缺陷率軟體開發其他工程製造 QC改進時程

Joke (1) • 有個電腦工程師A參加一個老同學喜宴，同桌有律師、會計師。 • A說羨慕其他行業的人，因在學校學的那一套終生都受用，每年就算有新法條也不會改太多。 • 不像電腦界，每天都在K新技術手冊，新產品、技術隨時翻新，改朝換代的速度讓人措手不及，所以學電腦的人看起來都比較蒼老。 • 會計師：其實我們最羨慕電腦界的人，因為沒有任何行業的消費者像電腦界的消費者好欺負。

Joke (2) • 另一位仁兄：「如果傢俱業和電腦業一樣，世界會變成什麼樣子？」 • 比如說到傢俱店買一張桌子，搬回家往地板上一放，啪啦一聲桌子就塌了。這時候我不會生氣、不會罵人，會先自己檢查一下出了什麼錯。或是對桌子的使用不夠熟悉。 • 於是買書來看，書名可能是《快快樂樂學用桌子》、《21天學會用桌子》、《修桌子技巧與實例》。 • 要是書看得不懂，會再花錢報名上修桌子課程。學完之後還是修不好，會請其他較懂修桌子的朋友幫忙。 • 最後沒有辦法，終於打電話給原先的傢俱行，可能還要購買《技術支援方案》，結果他們說：「唉呀！你買到的是搶鮮版！本來就應該有問題的」。 • 於是恍然大悟原來是自己的錯，再去買一張「正式版」的桌子。

Joke (3) • 回家一擺還是啪啦又塌了！修了半天還是有問題，再請傢俱行技術人員來仔細檢查，最後終於發現問題所在─「我家的地板和桌子不相容」。 • 又是自己的錯，於是趕快幫家裡地板升級。 • 等一切都忙完了，桌子可以使用，趴在桌上寫字，心裡充滿成就感，很得意地跟網友分享修理桌子的經驗，並暗自慶幸自己在科技潮流上沒有落伍。

軟體品質(1) • 由於軟體產業的生產工具是人，人注定會犯錯，還會犯很多錯。 • 不能相信『程式設計師」。 • 這是為什麼軟體測試在軟體工業重要的原因。

軟體品質(2) • 一座橋蓋好了，需要大量的測試嗎？

如何測試DVD撥放器 (1)

如何測試DVD撥放器 (2) • DIVX/MPEG4/DVD/VCD/CD/CD-R/CD-RW/HDCD/MP3/WMA/JPEG • 電視制式：NTSC/PAL/AUTO • 螢幕顯示比例：4:3/ 16:9 可供選擇 • 多重 OSD 語言及字幕語言 • 孩童智能安全鎖定 • 電源供應：AC 110V ， 60Hz • 自動電源短路保護 • 視頻 • 1組色差輸出 (Y ， Cb/Pb ， Cr/Pr) • 1組 S 端子視頻輸出 • 1組 CVBS 一般視頻輸出 • 音頻 • 杜比解碼輸出：2 聲道 1 組 • 光纖數位輸出端子

如何測試MP4 撥放器 (1)

如何測試MP4 撥放器 (2) • 3.5吋大螢幕多重觸控介面320 x 480 像素 • 可播放音樂、電影、視訊、有聲書、podcast、相片幻燈片 • Wi-Fi(802.11b/g) • 容量：16GB • 最多可儲存 3,500 首歌曲 • 最多可儲存 20,000 張照片 • 最多可儲存長達 20 小時視訊影片 • 音樂播放的電池電力：長達 20 小時 • 影片播放的電池電力：長達 4.5 小時

如何測試軟體

如何測試防毒軟體

如何測試線上遊戲

QA 要測什麼 • 完整性(completeness) • 軟體是否具備軟體規格書，設計文件中所描述的功能與性能 • 正確性(correctness) • 可靠性(reliability) • 相容性(compatibility) • 效率(efficiency) • 可使用性(usability) • 可攜性(portability) • 可變比例性(scalability) • 易測性(testability)

軟體測試的複雜性 • 軟體有複雜的介面， • 包括使用者介面、網路介面、檔案介面 • 軟體測試必須考慮更多的情境 • 正確的執行路徑 • 不正確的路徑 • 不同應用軟體，測試的理論，技術，實做，程式能力的要求都不低 • 安全性測試 • 嵌入式軟體系統測試

一般軟體錯誤 • 軟體需求規格，並不精確。 • 70% 發生在軟體設計階段，而且難以更正 • 20%發生在Coding • 需求功能變更，會影響其他軟體元件 • 別人寫好的軟體元件可能產生錯誤，不相容

軟體測試的迷思 • 軟體測試目的在於證明程式沒有問題 • 測試無法證明程式是無誤的。 • 軟體測試只能展現程式錯誤的存在。 • 軟體有問題是測試人員的錯 • 軟體測試只是一種有效的提高軟體品質手段，但無法百分之百解決軟體品質的問題。 • 軟體測試技術要求不高，比程式設計容易 • 兩種人無法類比，程式設計能力好的人，可能可以更勝任軟體測試。 • 自動化測試常需要程式設計高手

軟體測試的限制 (1) • 輸入狀態空間大小 • 計算是為哪種三角形，輸入三個邊。 • 輸入值整數：1~10000 • 104 x 104 x 104= 1012組合數量。正三角形等腰三角形直角三角形不能成為三角形 a, b, c

軟體測試的限制 (2) • 執行順序的數量 • 一個包含 if Conditional的Loop • 2n + 1 (2100 + 1次可能執行路徑) for if Loop n =100

軟體測試的限制 (3) • 輸入範圍：-32768 ~ 32768 • 正確：j=2999, 回傳 1; j=3000, 回傳 1 • 錯誤：j=2999, 回傳 0; j=3000, 回傳 0 • 正確：j=5999, 回傳 2; j=6000, 回傳 2 • 錯誤：j=5999, 回傳 1; j=6000, 回傳 1 • 發生錯誤的機率 = 40/65536=0.0006 int scale(int j) { j=j-1; //正確為 j=j+1 j=j/3000; return j; }

Joke (1) • 在一個資訊展覽會上，微軟公司創辦人語重心長：「如果通用汽車(美國最大汽車製造商)能使他們科技進展速度如同資訊產業，那麼今天汽車售價僅需廿五美元(台幣825元)，每一加侖(3.8公升)汽油可跑1000英哩(1600公里)。 • 為回應評論，通用汽車總裁發佈一篇新稿：如果通用汽車發展科技的方式如同微軟一樣，那麼： • 汽車每週會毫無理由的撞毀(Crash)兩次。 • 每次道路標線重漆或是交通標識改變時，你就必須買一輛新車。 • 有時汽車會毫無理由在高速公路上停下，你只好接受事實，然後重新發動，重新上路。 • 麥金塔(Macintosh，著名電腦製造商)製造一種非常耐用的汽車，由太陽能(Sun，著名系統軟體供應商)推動，速度快五倍，使用方式易學易熟練，但它只使用百分之五的道路。

Joke (2) • 安全氣囊彈出之前會問：「你確定嗎？」 • 有時汽車會毫無理由將你鎖在門外，唯一進入方式是同時間右手拉開關、左手轉動車鑰匙、口內咬著汽車天線。 • 每次通用汽車推出新車型，車主須重新學習駕駛方式，因新車和舊車控制方式都不相同。 • 車子儀表板不時出現「這部車子馬上就要熄火，請再重新發動」 • 行駛時有時還會出現『方向盤驅動程式：這個程式執行作業無效，即將關閉，是否要回報通用公司』 • 車主手冊最後一頁：如果所有救急措施都無效時,請關掉所有窗子,出去再進來。

Joke (3) • 把車裡的配件換新時,會發現舊的配件無論如何都拆不乾淨。 • 常常車開到一半，它會告訴你說『系統資源嚴重不足！請你拋棄部分零件，重新啟動！』等你把輪胎、方向盤丟掉，車子還是掛在路邊不會動！ • 車子排氣量會自動增加，必須不斷搪缸，以滿足需求 (換大硬碟，更多的記憶體) • 當踩下煞車，有時候會出現訊息：『這個裝置無效，即將關閉！』或是『這個裝置沒有回應』，只好重新啟動，嚴重的你會撞車，導致整台車都不能開！ • 這車子的故障率極高，容易出事，但是卻是大家最愛用也是最常用的車型。

市場概觀 (1) • 美國的軟體產業 • 大公司有測試團隊 • 小公司將測試外包 • 台灣的軟體產業 • 大公司有QA團隊，如微軟、趨勢科技 • 小公司，程式設計人員兼測試人員

市場概觀 (2) • 程式設計人員寫完程式，自己找bugs • 如同法官判完案後，承認自己判案錯誤 • 如果真找出很多bug ，決不敢聲張與邀功，因這代表自己程式寫太爛 • 找bug越多，表示待完成工作越多，沒有人會自己找碴，讓自己無法喘息 • 「人」的因素使 • QA 必須在軟體品質上與程式設計人員站在對立面 • QA升遷管道須是抓到越多bug，功勞越高，QA才會努力找碴 • QA 不能歸開發部門管轄，如同司法不能在行政部門底下一樣

軟體測試團隊 • 程式設計者 • 較瞭解軟體技術問題，正確切入重點，易傾向證明軟體是正確的。 • 使用者 • 較了解自己需求及重點，測試技術較弱，較不能有效測試錯誤。 • 測試工程師 • 測試技術較強，能適時以使用者角度、瞭解其需求。 • 主導大部份測試工作，以具有程式設計經驗者較佳。 • 定期向專案經理報告測試進度和發現問題，尤其是嚴重問題。 • 提供好的軟體問題報告，使程式師更快修復軟體錯誤。

測試的意義 • 測試定義 • 以一套系統方法執行與檢查軟體，以發現錯誤。 • 測試目的 • 發現軟體錯誤並進而修改軟體，以提昇軟體品質，避免錯誤造成嚴重損失。 • 花費最小精力及時間設計能發現最多錯誤的測試 • 錯誤原因 • 軟體發展過程中，可能因溝通不良造成規格不符或設計錯誤、或程式撰寫時發生疏漏。

軟體測試時機 • 越早發現軟體問題，開發費用越低 • 撰寫程式後修改軟體錯誤的成本是撰寫程式前的10倍 • 產品交付後修改軟體錯誤的成本是交付前的10倍 • 軟體品質越高，軟體發行後的維護費用越低 • 軟體開始規畫時即應考慮測試的規畫時程及人力。 • 測試花費，占整個軟體發展工作至少30%以上時間及成本。 • 需求分析與設計發生錯誤約占65%，程式撰寫約占35% • 早期觀點：Analysis  Design  Building Testing • 現在觀點：Analysis, Design, Building, Maintenance，全程Testing

User Reqt. Acceptance Testing Logical Design System Testing Integration Testing Physical Design Unit Testing Program Unit Design Coding 軟體測試V模型 (1)

軟體測試V模型 (2) 啟始概念維護階段計劃開始產品逐步淘汰再改進需求分析評估與簽訂合約驗收測試與交貨可交付項目的驗收測試細部需求規格需求規格已驗證的系統結構設計系統整合與測試品質保證品質保證已測試軟體設計規格整合的軟體細部軟體設計整合軟體與測試已測試的已除錯的模組模組規格軟體模組撰寫程式及單元測試計劃管理

驗證和確認(1) • 驗證(Verification) • 確保開發過程產品正確實現其規範。 • Boehm: You build it right. • 我們是否正確的建立產品。 • 確認(Validation) • 確保軟體產品符合使用者需求。 • Boehm: You built the right thing. • 我們是否建立了正確的產品。

驗證和確認(2) • Verification &Validation方法 • 包括靜態分析和動態測試 • 需求規格應包含驗證和確認標準，作為往後測試方法的根據。 • 目的是使軟體功能被使用者合理接受。

整合軟體 系統需求使用者文件動態測試有效軟體管理認可軟體發行使用者文件設計文件程式列表測試文件靜態分析有效組態驗證和確認(3)

軟體測試方法 • 靜態分析(Static Analysis) • 不直接執行受測軟體，以人工或自動化方法評估軟體是否滿足規範。 • 分為審查與檢視方法。 • 規範技術複審、文件複審、資料庫複審、演算法分析審查 • 動態測試 • 程式開發後進行，執行軟體程式碼。 • 分為黑箱測試與白箱測試。 • 功能測試、性能測試 • 檢查軟體界面及內部機制正確性。

靜態分析優點 (1) • 降低專案整體成本。 • 超過一半的軟體錯誤發生在需求或設計規格錯誤，審查與檢視可以在程式撰寫前發現錯誤，早期發現問題，可降低除錯與重測成本。

靜態分析優點 (2) • 靜態分析比動態測試有效率(1/3) • 清楚發現錯誤所在及原因，不需經過繁複鑑定錯誤、分析原因、修改與重測，可迅速修正錯誤。 • 有效找出規格模糊、程式撰寫風格錯誤、不合規定程式、與無效程式段落等動態測試難以發現之問題。 • 審查與檢視透過小組討論可以有效交換成員觀念與想法，協助經驗傳承與訓練溝通。 • 動態測試 • 須從系統非預期的行為、或錯誤結果推斷錯誤程式碼. • 必須花許多時間診斷

動態測試案例設計(1) • 測試案例 • 測試程式設計問題。 • 包含編號、名稱、目標、條件、輸入資料、測試步驟、期望正確結果 • 盡可能在系統發展早期，設計測試案例。 • 測試案例 • 有一個合理的機率可以偵測錯誤 • 同類中最好或較好的 • 不會太複雜，也不會太簡單 • 不要有重複出現 • 可以明顯的呈現軟體的錯誤

動態測試案例設計(2) • 白箱測試(White-box testing) 測試輸入執行結果與期望結果比對

軟體測試與驗證