本書內容主要是微軟測試團隊的成功經驗,方法與技術
Part I 關於微軟
第一章 微軟的軟體工程
- 微軟的遠景,價值及我們為何"愛這家公司"
- 微軟是一間大型的軟體工程公司,對微軟來說,大其實代表廣,每年要推出的產品類型數量,微軟所參與的競爭市場的廣度,以及為了符合需求而面臨的各種工程設計方面的挑戰.
- 發展大型且有效率的企業
- 共享式團隊模型
- 大公司裡的小成就
- 雇用多種類型的工程師
- 工程領域
- 成為全球軟體開發廠商
第二章 微軟的軟體測試工程師
- 名稱的意涵
- 微軟的測試人員不一定都是SDETs(SW Development Engineer in Test)負責軟體測試的開發人員
- 我們不能叫他們SQE(軟體品質工程師)
- 我需要更多測試人員,現在就要
- 十種專業能力:
- 問題的分析能力:這對測試人員很重要
- 以客為尊
- 技術優勢
- 專案管理:時間管理的能力
- 對品質的熱忱
- 策略的眼光
- 自信
- 衝擊和影響力:影響力來自信心和經驗,衝擊來自於知道如何促進改變.
- 跨界合作
- 人與人之間的觀察:這項能力主要與自覺有關,能講出改進自身技能的方法
- 校園徵才
- 業界徵才:在微軟的開發人員對測試人員的比例約是1:1,一般業界則是5:1,當二者比例懸殊過大,那麼測試小組通常只會關心能否生存下去,而無心於磨練和改善其技術.
- 學習如何成為微軟的SDET:新進員工先有NEO新人共同課程,結束後向所屬主管報到,然後會有技術訓練課程,例如"微軟SDET的測試工作"課程是由經驗豐富的測試人員傳授.
- 微軟工程人員的生涯發展
- 測試工作的生涯發展路徑:
測試架構師
IC測試人員(IC:個人貢獻者)
成為經理並非升官:工程部門經理所管理的團隊包含開發,測試和計劃管理.
測試經理:在設計和執行測試上不需要實際動手做,測試經理也要有技術能力,但著重於測試的流程與工具,而不是執行某種測試.測試經理會花許多時間在發展和提升測試團隊技能的工作上.也要和產品經理合作,協助評估產品品質和恰當的發行日期.第三章 工程生命週期
- 微軟的軟體工程
- 傳統的軟體工程模型:
瀑布型,特點是某一個階段開始時,代表前一個階段的工作已經完成,缺點是缺乏彈性,因為不允許重複各個階段.
螺旋型是一種反覆式流程,包含決定目標,風險評估,工程和規畫下一次反覆.螺旋型的另一個重要觀念是重複使用雛形(prototypes)來降低風險.雛形是基於初步設計和接近最後產品的特性所建構.
敏捷(Agile)方法論,相對於螺旋型的笨重,和瀑布型的嚴格階段流程,敏捷方法比較著重於輕快和漸進的開發方法.其特點如下:
- 簡短而多次的反覆
- 強調面對面的溝通與合作
- 能接受需求變動
- 擁有品質
- 其他模型:
里程碑模型能建立專案發行的時程,幫助個別團隊了解整個專案預定的發展過程,並檢查專案的狀態是否符合預期.要達成一個里程碑,還要滿足一些特定規格和準則如下:
- 關鍵功能已經"完成程式碼",雖還沒有完全測試過,但功能已經實作完成.
- 達成過度期測試計畫,例如達成程式碼涵蓋率的目標或完全測試目標
- 符合bugs目標:例如沒有發現嚴重等級1的問題
- 符合非功能性目標
微軟的敏捷方法:
特色小組是一支小型,跨單位,擁有3到10人的小組.其成員來自不同部門(通常是開發,測試,計畫管理),而且都能獨立完成系統的特定功能.這個團隊的結構包括1位計畫經理,3到5位測試人員,以及3到5位開發人員.他們會在短期的反覆中共同合作,一起進行設計,實作,測試並將功能整合到整個產品中.
此團隊的特點:
它是獨立運作,可以自主決定採用的方法.
它能完成某元件的需求定義,程式開發,測試和整合工作,已產生對客戶有價值的功能.
達成任務:針對團隊訂出所謂的"品質關卡",以確保特色小組都已完成,而且在整合方面沒有太大風險.品質關卡類似里程碑的結束條件.
敏捷方法與里程碑方法一起搭配運用
由程式碼形成功能,功能結合成特色,許多特色集合成一個專案.流程改善(PDCA流程)
微軟的正式流程改善系統:
ISO9000:強調滿足客戶需要,方法是透過品質需求,監督流程以及持續改善. 六標準差:Motorola所發展,使用統計工具和DMAIC(定義,度量,分析,實作,控制)流程來度量和改善流程.
CMMI:這是有五種成熟度等級的模型,強調專案管理,軟體工程,以及流程改善的應用.CMMI比較針對企業本身而不是專案.
精實:強調減少工程流程中的浪費(例如瑕疵,延誤以及不必要工作)
從戰情室發行軟體:
開發團隊每天在為產品做決策,而作戰小組要對整個產品的所有元件和系統有通盤的了解.決定那些bugs要修正,那些功能要捨棄,團隊的哪個部分需要更多資源,或者是否要調整發行日期等等.一般來說,作戰小組是由產品各個領域的代表(通常是經理)所組成.成功的作戰小組或作戰會議應該要考慮:
- 確定戰情室裡的人都是適當人選.
- 別想解決會議裡的所有問題,如果問題需要進一步研究,指派某一個人負責,然後進行下一個議題.
- 明白列出行動項目,負責人以及預定完成日期
- 要有明確的問題追蹤流程,並一貫落實,經過一段時間之後,人們會習慣這樣的流程,而且碰到問題時也更清楚該如何處理.
- 清楚表達你想要的是甚麼,應儘量確定每個人都達成共識.
- 專注於事實而不要靠臆測.不是有就是沒有.
- 每個人的意見都很重要,
- 在里程碑開始時就先設定好完成標準,希望達到的品質目標也要事先決定.
- 由1人主持會議,並且按照既定的會議主題進行.
定義發行版本------微軟用語
LKG: Last Known Good,指的是最近一次發行符合特定水準的發行版本.
Self-host:指的是品質足以供日常作業使用的版本.
Self-toast:指的是會毀掉(烤焦)你日常作業的版本
Self-test:這版本已經通過大部分測試,但還有一些待克服的問題,還未到Self-host的程度.
Visual freeze:這是在產品開發週期中,決定凍結使用者介面的時間點或是里程碑,而且直到產品發行之前都不會改變.
Debug/check build:此版本會包含一些用來協助除錯和測試的功能.Release/free build:專為發行而準備的最佳版本.
Alpha release:這是非常早期的版本,主要是為了獲得功能和易用性方面的意見.
Beta release:這是產品的搶鮮版,此版本會提供給客戶和合作夥伴評估,試用,以獲得他們的回饋意見.
Part II 關於測試
第四章 測試案例設計的實務做法
- 學習設計好的軟體和測試
- 運用測試模式,可以讓測試人員用以傳達測試方法的意圖,也可以透過一種易於理解與運用的方式分享不同的測試設計技術.該樣板有10種屬性:
名稱
問題
分析
設計
預測
範例
缺點或限制
相關模式
- 預估測試時間:一個常用的原則是:等同開發時間,這個方法通常準確,但還有許多因素會影響測試,如團隊的目標,客戶的期望,測試團隊的技術能力,以及專案的複雜性等等,都會影響到測試作業流程.預估測試時間的重要因素:
- 歷史資料
- 複雜性
- 商業目標:應用程式是雛形或展示程式?還是它是太空船的飛行控制軟體?商業目標會影響測試工作的廣度和深度.
- 一致性/依從性:應用程式是否要符合某項標準?
- 開始測試:
測試設計的起點,可以選在複閱需求文件或軟體規格書的時候.若有詳細的需求文件,就可以據以設計測試,若沒有需求文件(或寫得不好),那麼開始進行測試設計的最佳方式,可能就是提問了.要問這個軟體是要做甚麼用的,問它如何處理資料,以及問他如何處理錯誤.提出該軟體有關的問題.將有助於測試人員在撰寫程式碼以前,先對整體設計有初步的概念.
問問題:
如果程式已經寫好,但是需求文件和功能規格都付之闕如或不夠完整,那麼開始設計測試的最佳方式,就是跑跑看應用程式.首先問自己這個程式如何運作,你可能有辦法找出這些問題的答案,也可能引出更多的問題.如果碰到不明白的地方,就問問題.如果能取得原始碼,就參考程式碼,並在必要時提出更多問題.探索測試的作法,是同時進行測試和設計測試的動作,它對測試設計有很大的影響,而且對整個測試設計的過程很有幫助.
如果你正在測試以前沒有測過的功能,或某種類型的應用程式,你可以詢問有經驗的人,這樣通常會有幫助.許多軟體錯誤沒有辦法在測試時找到,是因為測試人員提出的問題不夠多,或者沒有問對問題.擬定測試策略:
簡介:說明如何運用此策略,策略的擬定是基於專案的功能和品質目標.
規格需求:列出測試小組的文件計畫.以及來自其他工程部門對文件的期望.
關鍵情報:主要的客戶情境是甚麼?這個部分要回答此問題,並將測試工作與產品計畫結合.
測試方法:描述用來測試產品的方法,以及評估使用各種方法的價值和風險.程式碼涵蓋範圍,測試自動化,測試案例管理,以及其他方法或工具.
測試產出:測試團隊應有那些產出?
.測試結果
.程式碼涵蓋範圍
.規格確認狀態
.瑕疵率和瑕疵成長趨勢
.效能測試結果
訓練:如果該策略需要教育訓練方能成功,則應該詳細描述,內容應包括訓練如何支援該策略的分析.
思考可測試性:可測試性是指軟體測試的效率及完整的程度.這裡列舉幾個提升可測試性的方法:
選擇特定的設計方法
選擇簡單的演算法
使用測試掛勾(hooks)(為了方便測試而特別撰寫的額外功能),顯示內部變數的值.
可測試性的簡單模型(SOCK):
簡單:簡單的元件和應用程式比較容易測試
可觀察:顯現內部的結構和資料,有助於精確判斷測試會通過還是失敗.
控制:如果應用程式有門檻值,提供設定與重設門檻值的功能可以讓測試更容易.
知識:藉由參考相關文件(規格書,輔助說明文件等),測試人員便能確保結果是正確的.
測試設計規格:提出相關可測試性問題,可強迫相關人員思考該如何測試軟體?同時也會要求測試人員考慮測試案例的設計.該文件同時描述測試流程的方法和意圖.
好的壞的都要測:測試案例包含驗證測試(使用預期的輸入值來驗證功能)和反證測試(使用非預期的輸入值來驗證功能)
測試案例設計所要考慮的其他因素
進度,資源(預算)和品質也是影響軟體測試的重要因素,如同它們影響軟體開發一樣.好的測試案例設計要求測試人員事先思考測試的範圍,也要思考測試案例的優先次序,以便符合進度的需求.絕不可能每個地方都測到,因此我們必須在給定的期限內,選擇最有效率,最完整的測試項目組合.
另外也要考慮產品的範圍,主要客戶群的規模,測試團隊的人數,以及測試團隊的技能.思考這些因素,可以幫助你選擇那些測試項目能夠驗證功能,發現錯誤,以及迅速有效處理客戶的問題.
黑箱,白箱,灰箱
分類測試案例設計的一個方法是描述測試人員對於受測應用程式的了解程度.黑箱測試不用了解應用程式底層功能或程式碼,它在乎的是軟體能否符合使用者的需求,而非軟體是如何設計.黑箱測試方法可以模擬和預想使用者將如何使用產品.純粹的黑箱測試方法會對軟體的某些部份過度測試,而某些部分卻測試不足.相反地,白箱測試則是針對使用者看不到的底層機制或原始碼所進行的測試,白箱方法的測試案例通常很完整詳細,但通常會遺漏主要的使用者情節.
解決之道就是灰箱測試方法,有時也稱為玻璃箱測試.在設計案例時,先從客戶觀點著手(即是黑箱測試),但也要用白箱方法來確保測試的有效性與全面性.測試人員必須了解客戶的觀點,並且判斷應用程式的正確性,如果沒有同時考慮黑箱和白箱方法,就無法兼顧這兩個層面.
微軟的探索測試
探索測試是一種人工方法(就一般情況而言),它的每個測試步驟會影響到後續的步驟.在進行探索測試的過程中,測試人員會應用他們對受測應用程式的了解以及測試方法的專業知識來迅速找出錯誤.並且用這些資訊來輔助後續的自動化測試設計.
微軟有一種新的探索測試方法就叫做搭檔測試,由兩個測試人員一起進行探索測試,一個坐在鍵盤前操作應用程式,專注於功能面,另一個站在後面或坐在旁邊協助,從更高的層次來思考.經過一段時間以後,兩人交換角色操作.
結論
測試時沒有絕對正確或錯誤的方法,重點在於要花時間了解元件,功能和應用程式,並且依據你所了解的部分,搭配各種技術來設計測試案例.測試人員最好在進入測試工作的初期就接受適當的教育訓練,以了解正確的觀念和實務的作法.
第五章 功能測試技術:稱職的測試人員不只會利用他們的好奇心來探索產品,也會更深入底層和細節,以便對受測軟體的功能和特性有進一步的深入分析.蒐集深層資訊的一個方法是分解產品的功能,並針對各元件的功能和特性來做測試.
功能測試的必要性
探索測試是其中一種方法,它著重於行為測試,幫助測試人員快速認識和熟悉軟體,它對於小型的軟體專案,銷售量有限的軟體或市場生命週期短的軟體來說,應該是足以應付.
不過探索測試一般而言,不適用於大型且複雜的專案或關鍵性的軟體,在微軟,我們已經了解到探索測試對於軟體版本的長期維護而言並不是最好的方法.我們也知道只靠測試人員和領域專家,從使用者介面來找出產品功能的問題,並不能提供專案經理有關軟體品質和風險情況的有用資訊.當管理團隊想要有更多資訊來減少可能的風險以及訂出合理決策,就必須對受測軟體的功能元件進行更完整的分析.
黑箱方法的行為測試大概佔了測試的35%~65%,從使用者介面操作而來的行為測試很重要,但如果它是主要或唯一的測試方法,那我們可能會浪費時間在一些沒效率的測試,也會漏掉測試產品的重要部分.從微軟和一些業界內部研究的實證資料可知,行為測試的效果相當有效,因此測試人員要問的是:"我們要如何提高測試的有效性,並且減少重複的動作?"
第六章 結構測試技術
第七章 分析複雜程式碼的風險
第八章 以模型為基礎的測試
Part III 測試工具和系統
第九章 管理臭蟲和測試案例
成功的問題追蹤系統的屬性:
- 容易使用
- 組態可調整
- 可靠度
- 其他的屬性:
為什麼要寫臭蟲報告?
- 臭蟲通知
- 互通性
- 外部使用者的存取
第十章 測試自動化
- 臭蟲報告是用來紀錄軟體瑕疵和解決方法的紀錄.當所有程式臭蟲都有紀錄時,根本原因分析和DRE(瑕疵移除效率)才會更有效.
- 當團隊要開發新版本時,臭蟲報告常被用來做為歷史參考資料,用來了解產品,輔助決策或協助客戶.
- 臭蟲報告也可以做為法律上的辯護工具
自動化的價值:自動化的價值取決於實際的環境.有時候,每一項測試都可以自動化,有時候,都不要自動化才是適當作法.有些錯誤要有人盯著螢幕才找得到.例如:當關閉對話窗時,螢幕就在閃動.or當滑鼠移過控制項時,指標會閃爍.這些都是人比電腦更容易觀察的現象.不過對於其他類型的錯誤,自動化測試通常比較有效率.
自動化or不要自動化?要考慮的因素有:
- 人工成本
- 測試的壽命
- 測試的類型,應用程式介面(API)or程式物件等比較適合自動化測試,使用者介面(UI)就比較不適合自動化測試.
- 價值:考慮自動化測試在它的整個生命週期的價值,有些測試人員會說測試案例的價值是在尋找錯誤,但是由自動化測試找到的錯誤,都是在第一次執行時所找到的,一旦錯誤修正後,這些測試就變成了回歸測試(regression test)---每當程式有修改時,再度執行這些測試,以確保原先完成的功能依然運作正常.許多自動化技術可以改變測試所使用的資料或每次執行測試時的路徑,以便讓這個測試能持續發現錯誤.對於有較長生命週期的產品而言,持續成長的回歸測試套件是有幫助的---對非常複雜的軟體而言,在持續開發新功能之前,若有大量確保既有功能正常運作的測試,對軟體品質的提升大有助益.
- 涉入的時間點:測試團隊在專案一開始就使用自動化技術相對於在程式碼完成or快完成時才嘗試在專案中加入自動化測試,前者比較容易成功.
- 準確性:好的自動化測試會在每次執行後報告精確的結果.管理這些自動化測試時,最大的抱怨是誤報太多,誤報指的是測試結果顯示有錯誤,但是這個錯誤是測試本身所導致的,而非來自產品本身的錯誤.專案的某些領域,例如UI可能就很難用自動化測試來分析,而且可能比較容易產生誤報的情形.
- 複雜度: 自動化測試比人工測試到底多複雜?有些測試光用現有架構或技術,還是難以自動化.例如圖形程式是利用"像素比對演算法"來比對兩張影像,但是影像比對容易產生誤報,而模糊配對有時可以達到比較好的結果,但實作卻相當複雜.而且需要不斷調整自動化參數,才能達到預期結果.
- 其他因素:自動化所需時間以及測試人員撰寫自動化測試方面的能力.自動化是一項投資,不可能在最後一分鐘才拿出來用,也不可能只因為某個測試人員在學校裡有程式設計經驗,就把這項工作交給他負責.請記住,如果沒有在專案設計一開始就考慮自動化測試技術的相關因素,日後在撰寫自動化測試時將非常困難.最後要考慮的因素是自動化管理的哲學.自動化不是萬靈丹,但也不能完全忽略.自動化程度的多寡並沒有絕對的標準,重點是:在決定需要多少自動化以及對那些工作自動化時,必須考慮到前面所提的幾項因素,而不是單從管理的角度來決定.
誤報與漏報:當某測試失敗,而目標功能卻能正常運作,這就是誤報,也就是說測試報告顯示有錯,但實際上該功能是正常的.相反的,若一項測試通過了,實際上它是有問題的,那麼這種情形就稱為漏報.
UI自動化測試:軟體測試市場上提供了許多工具,可以幫助測試人員處理UI的自動化測試,這些工具也提供錄製和播放功能,如此一來,撰寫測試的人員只要錄製人工測試的動作,然後就可以用自動化測試反覆測試.但是錄製和播放工具也受到一些批評,因為只要UI的一點點變動,原先錄製的測試就不能使用,而且當UI元素眾多時,自動化就更加困難. 微軟的做法是,在自動化測試UI時,略過展現層,並直接使用底層的物件模型,或使用類似的方法來處理UI的核心邏輯.在一些個案中,UI自動化是利用模擬滑鼠點擊和鍵盤按鍵的動作來直接和UI互動. 模擬滑鼠點擊和鍵盤按鍵的程式碼是最常用的自動化範例,它們可以重現使用者和軟體互動的情形.不過它們也是UI自動化測試中最脆弱的方法,因為控制項可能會移動,底層的識別名稱會改變,顯示的文字也可能更動或經過本地語系化.我們也許可以單靠模擬滑鼠點擊和鍵盤按鍵方式設計出強固的自動化測試,但實際做起來依然非常困難. 自動化的另一種形式是自動化測試那些使用者和UI互動的動作.比如說,它並不模擬按鈕按下的事件,而是直接呼叫觸發按鈕動作的內部程式碼. 在許多情況下,透過物件模型或類似方法來存取控制項,這種UI自動化測試的效果跟操作使用者介面的按鈕或鍵盤是一樣的.不過純粹透過模型所做的自動化可能會遺漏一些嚴重的臭蟲.
自動化測試裡面有甚麼? (SEARCH:Setup,Execution,Analysis,Reporting,Cleanup,Help)
- Setup設置 :準備測試的環境,以便開始進行軟體測試.
- Execution執行:測試的核心,指驗證功能,錯誤處理,或其他相關動作的必要步驟.
- Analysis分析:分析是決定測試通過或失敗的程序,它是最重要的步驟,通常也是最複雜的步驟.
- Reporting報告:報告包括分析的呈現和解釋,例如,記錄檔,資料庫或其他產生的檔案.
- Cleanup清除:清除階段指的是將軟體恢復至原先狀態,以便進行下一輪的測試.
- Help輔助:輔助系統可以用來加強測試案例的可維護性和穩固性.
開發自動化測試時,必須要考慮從安裝到維護的整個測試範圍.若自動化測試的範圍夠廣,將能夠涵蓋SEARCH的每一個步驟,但有時候只自動化其中一小部分也挺有幫助. 許多自動化之所以失敗,是因為它們只針對測試執行的階段做自動化.一個全面的自動化方法不能只針對執行做自動化.如果自動化策略沒有包含一份讓應用程式達到可以執行以及自動產生分析報表的計畫,這樣的自動化就沒有太大的效用.完整的自動化所包括的範圍不只是執行測試,以電腦為基礎的工具和軟體對於支援測試執行的各種自動化工作而言都是很好的解決方案.
常見的自動化錯誤:
- 寫死的路徑
- 複雜性
- 難以除錯,令除錯困難的重要關鍵是紀錄資料不足, 有好的紀錄資訊,失敗的情況才容易修正,甚至可能不需要用到除錯程式.
- 誤報&漏報
結論
自動化測試的一個主要目標是延長測試的壽命,即使完成一個自動化測試就要費不少功夫,但是當這樣的測試可以執行在多種不同的應用程式組態,還能讓工程維護團隊使用長達十年以上時,就能顯現它的價值.將這些測試納入一個能夠自動設定測試環境,執行測試,回報結果,以及記錄問題的自動化測試架構,是優秀的,可長期化使用的自動化測試的基礎.第十一章 非功能性測試
結論
非功能性測試補足了功能測試欠缺的部份,而且是建立高品質產品的關鍵,非功能性的品質屬性不易測量,其中一個原因在於許多層面都必須在開發過程的早期階段就要先考慮到,但是這些屬性卻往往要等到客戶真正使用軟體之後才能測量.解決此難題的關鍵,是在進行所有測試活動時,透過人物代表或其他類似的方法來充分反應客戶的聲音.第十二章 其他工具
測試人員的工具就是能夠幫助他們更有效率地完成測試工作的應用程式,微軟的測試人員在整個測試過程中會使用大量的測試工具,這些工具能執行測試,檢測系統,追蹤處理過程,以及提供其他各種協助.除錯是一項偵察工作,在進行除錯時檢查變數的狀態,檢查紀錄檔案,以及檢查原始程式碼的變動,這些都是除錯的方法,也就是要找出錯誤的原因.
測試人員使用的工具不計其數,像是螢幕錄製程式,檔案剖析器,自動化工具的增益程式,甚至字型顯示工具,這些都是用來解決特定測試問題的軟體程式.
除了工具外,測試人員習慣上也會在他們的團隊中共享函式庫(可重複使用的函式),如此團隊中的每個人都可以使用相同,穩定的方案來解決類似的問題.
優秀的測試人員有一項特徵,他們評估問題並比較適合的軟體工具來解決,或者自行開發新工具來解決問題.一個好用的工具箱,加上運用這些工具的技能和知識,是測試人員最重要的資產.
第十三章 用戶反饋系統
第十四章 測試軟體加服務
Part IV 關於未來
第十五章 防患未來
第十六章 創建未來
沒有留言:
張貼留言