讀書筆記--有效軟件測試的50條建議

2015-12-21 10:03:35

一、需求階段

最有效的測試應該始於項目的開始階段，遠遠早於程序代碼的編寫階段。消除需求工做中的缺陷可以使昂貴的返工工做降到最低。

（1）測試人員及早進入

（2）驗證需求

       正確性：根據用戶的需求來進行檢驗

       完整性：用於保證需求中沒有遺漏任何須須的元素

（3）需求就緒後立刻設計測試過程

       和軟件工程師根據需求撰寫設計文檔同樣，測試組也須要根據需求來設計測試過程。

（4）確保需求變化的傳遞

       當測試過程根據需求定義好了之後，在需求發生變動時把這種變化通知到測試組成員是很是重要的。

（5）注意在現存系統上進行開發和測試

       使用肯定的應用程序版本；把現存應用程序文檔化；對現存應用程序的更新也要造成文檔；今後實現有效的開發過程

二、編制測試計劃

測試綱要成功的基石是有效的測試用例。

（6）瞭解手頭的任務和相關的測試目標

（7）考慮風險

       在制定有效的測試策略以前，必須理解測試計劃中的假定、先決條件和風險。這包括不利於按照進度實現和執行測試綱要的任何事件、行爲和環境。例如：預算批的太晚、測試設備延期到貨或者應用程序延期交付到測試部門。

（8）根據功能優先級安排測試工做

（9）牢記軟件方面的問題

       當指定測試計劃的時候，測試組應該瞭解影響項目開發和交付的一些軟件問題，這是很是重要的。其中包括：Beta或預發行版本，新技術和不完善的技術，分階段實現，缺陷，補丁和服務包。

（10）得到有效的測試數據

         測試數據的設計必須使得每一個系統級的需求都能獲得測試和驗證。測試數據的需求評審應該關注數據的幾個關鍵方面，其中包括：深度（測試組必須考慮支持測試工做所需的數據庫記錄的數量和規模）、寬度（測試工程師必須研究數據數值的變化）、範圍（測試數據的範圍與數據的精確度、相關程度和完整程度是有關的）、測試執行期間的數據完整性、條件（建立的數據集應該可以反映應用程序所在領域的特定「條件」，這就是說，特定模式的數據並不須要等到必定的時間以後經過執行特定的操做來得到）。

（11）規劃測試環境

         測試環境是由支持測試工做的全部物質元素組成，例如：測試數據、硬件、軟件、網絡和設備，能夠結合下面的信息和資源的準備情況來設計測試環境:得到客戶環境樣本的描述，肯定測試環境是否須要一個歸檔機制來存儲測試後產生的大文件，肯定客戶環境中的網絡特性，對於客戶端-服務器或基於web的系統肯定服務器的操做系統、數據庫和其餘組件，肯定測試組須要的自動測試工具的許可證數量，肯定執行某些測試過程當中須要的其餘軟件、考慮對測試數據的需求，考慮配置測試須要的特殊資源等等。

（12）估計測試準備和執行所需的時間

三、測試組

測試組能力的高低會極大的影響測試工做的成敗。

（13）定義角色和職責

（14）測試技巧、行業知識和經驗三者缺一不可

（15）評估測試人員的有效性

四、系統構架

瞭解了整個系統的組件和模塊，就能夠減輕測試組的工做量，並且測試組能夠把注意力集中在有缺陷的特定區域或者層次上，從而提升開發人員修正缺陷活動的有效性。

（16）瞭解系統構架和基本組件

         若是測試工程師對對應用程序的構架和基本組件有所瞭解，那麼這些知識會有助於他們查明產生特定測試結果的應用程序中的各個部分。這些瞭解能夠指導測試人員進行灰盒測試，而灰盒是黑盒測試的有力補充。它能提升缺陷報告的質量，提升進行探索式測試的能力，增長測試的精確度。

（17）確認系統的可測試性

         當應用程序的構架還只停留在文檔上面而沒有付諸實施時，對構架可測試性的研究，能夠極大的減小隨後的測試工做中可能出現的意外。

（18）使用日誌增長系統的可測試性

         增長應用程序可測試性最經常使用的方法就是實施日誌機制即跟蹤機制，這種機制提供的信息有:組件正在作什麼（包括他們正在操做的數據）、應用程序的狀態或者應用程序運行中遇到的錯誤。在執行測試過程期間，測試工程師能夠利用這些信息來跟蹤處理流程，他們還能夠利用這些信息對系統中發生的錯誤進行定位。一個形式良好的日誌條目會包含如下一些信息：類名和方法名，主機名和進程id，條目的時間戳（最好精確到毫秒），消息。下面是某個應用程序的日誌記錄的實例，這個應用程序負責從數據庫中檢索一個客戶對象。

在每一個函數中，都標明瞭函數名、產生這個條目的應用程序源代碼的文件名和代碼行號、主機名、進程ID、以及條目產生的時間。每條信息還包含了有關參與當前活動的全部組件的標識信息，例如，數據庫服務是「dbserverl」，數據庫是「customer_db」，客戶ID是A1000723。

（19）驗證系統支持調試和發行兩種執行模式

         調試模式的做用是當遇到問題是幫助開發人員和測試人員診斷問題。而發行模式是去掉大對數或者所有與調試相關的特性，並通過優化的系統版本。經常使用的調試方法：源代碼檢查、輸出日誌、實時調試。

五、測試設計和測試文檔

（20）分而治之

         應該測試什麼，什麼時候開發測試過程，測試過程應該如何設計，誰應該負責測試開發工做

（21）使用測試過程模板和其餘測試設計標準

          爲了測試過程的可重複性、完備性和一致性，在適用的時候應該運用測試過程模板，包含如下關鍵元素：測試過程ID，測試名稱，執行日期，測試工程師的名字，測試過程的做者，測試目標，相關用例/需求編號，前置條件/假設/依賴，驗證方法，用戶動做，預期的結果，跟蹤日誌信息，實際結果，須要的測試數據。

（22）根據需求獲得有效的測試用例

（23）把測試過程當作「動態」的文檔

         大對數軟件項目採用了迭代式和漸進式的開發方法，測試過程的開發也常用這種方法。在一個迭代式和漸進式的開發生命週期中，根據工做版本開發計劃時間表，須要交付大量的軟件工做版本，因此想讓測試過程保持不變是很困難的。和任何動態的或者發展中的文檔同樣，測試過程也應該存儲在一個版本控制系統中。

（24）利用系統設計和系統原型

         原型有多種用途。它們可讓用戶預先看到某個功能的實現結果，而且讓用戶預先對應用程序有所體驗。經過原型用戶能夠提出對正在開發的軟件的反饋意見，這些意見能夠用於改進原型而且使最終的產品對用戶來講更滿意。

（25）設計測試用例場景時採用通過檢驗的測試技術

（26）在測試過程當中避免包含限制和詳細的數據元素

         不管是手動仍是自動測試過程，都應該把數據元素和他們的測試腳本分開保存，在腳本中使用變量而不是使用硬編碼的數值。

（27）運用探索式測試

         在當今軟件開發環境下，定義了全部關係和依賴的完整而詳細的需求是很是罕見的。所以常常要求測試人員運用分析能力來肯定應用程序的本質。有時爲了得到高效的測試設計工做所須要的知識，咱們須要進行探索式的測試工做。

六、單元測試

（28）用結構化的開發方法來支持有效的單元測試

（29）在實現以前或者與實現同時開發單元測試

         隨着XP開發方式的流行，在實際軟件開發以前開發單元測試程序的觀念也被證實是有效的。在這種方法中，由於要用需求來指導單元測試的開發，因此它們必須在單元測試開發以前定義。在實現軟件組件以前開發單元測試有許多好處:一、強迫軟件的開發方式可以知足每一條需求；二、把開發人員的經歷集中在解決某一專門的問題上，而不是開發一個也能知足需求的、巨大的解決方案；三、經過單元測試能夠推測開發人員的實現目標（對照需求陳述的內容）。若是開發人員對需求的理解有問題，那麼這種誤解會在單元測試代碼中反映出來。

（30）使單元測試的執行成爲生成過程的一部分

          把自動執行單元測試加到生成過程當中，使得生成過程增長了另外一種質量保證機制，再也不是語法正確就可以經過編譯。它保證了經過自動生成獲得的產品是一個真正經過單元測試的系統。軟件始終處於可測試的狀態，而且因爲單元測試已經發現了大多數錯誤，因此組件中不會再有重大的錯誤。

七、自動測試工具

（31）瞭解各種測試支持工具

（32）自主生成一個工具

         在有些狀況下，除了製做工具咱們別無選擇：操做系統不兼容；應用程序不兼容；專項測試的須要。

（33）瞭解自動測試工具對測試工做的影響

         自動測試工具只是解決方案的一部分，不能徹底替代手工測試，不能代替指導測試工做的分析能力，不能解決全部測試工做中的問題。

（34）關注組織的須要

         到底哪一種測試工具最佳，這取決於組織的須要和系統工程環境。

（35）在應用程序的原型上對工具進行測試

         驗證備選的測試工具可以在正在開發的系統上使用是很是重要的。完成此項工做的最好方法是：讓提供商在須要測試的應用程序上演示他們的工具。可是，這一般是不可能的，由於在測試工具評估階段，須要測試的系統常常還不存在。一個能夠替代的可行方法是：開發人員爲評估一組測試工具建立一個系統原型。

八、自動測試：選擇最好的實踐

（36）不要過度依賴記錄/回放工具

         只經過記錄/回放直接建立的腳本有一些嚴重的侷限和缺點：硬編碼的數值；非模塊化的、不易維護的腳本；缺少可重用性的標準。

（37）必要時自制開發一個測試工具

 

         定製的測試工具能夠提供比自動測試工具腳本更強有力的測試手段。雖然生成一個定製的測試工具多是很耗時間的，可是它也具備不少優勢，例如：對應用程序的敏感部分能夠有更深的覆蓋、具備比較兩個應用程序的能力，而這些是單個現成的測試工具沒法完成的。

（38）使用通過考驗的測試腳本開發技術

（39）儘可能使迴歸測試自動化

         迴歸測試肯定的是：在修改先前的錯誤或者嚮應用程序添加新功能時，是否引入了新的錯誤，這些錯誤影響之前運行正常的功能。

（40）實現自動生成和煙霧測試

         自動生成一般天天執行一次或者兩次（可能在晚上），它們會使用最新的和穩定的代碼。開發人員能夠天天從負責生成的機器上取得組件，或者在火燒眉毛的狀況下在本地從新生成。

         煙霧測試是迴歸測試套件的精簡版本。它主要是對應用程序關鍵的高層功能進行自動測試。當拿到一個軟件的新版本時，煙霧測試不是手動的反覆執行全部測試，而是有針對性的驗證軟件中的主要功能是否任然可以正常運轉。

九、非功能性測試

是否知足非功能性需求決定了應用程序是勉強實現了它的功能，仍是不只最終用戶和技術支持人員對它的接受程度很高，並且系統管理員也願意對它進行維護。

（41）不要過後才考慮到非功能性測試

         有關非功能性的事宜，最好早在應用程序的構架和設計階段就開始研究。若是不能及早的關注這方面的實現，那麼之後爲了知足非功能性需求而修改或者添加組件就很困難，甚至是不可能的。當規劃一個軟件項目時，須要考慮下列非功能性風險：糟糕的性能，非兼容性，缺少安全性，缺少可以使用性。對測試組來講，若是一個應用程序的非功能性需求，能在開發過程的需求階段和功能性需求一塊兒考慮，那麼這是最理想的狀況。

（42）用產品級數據庫進行性能測試

         若是一個應用程序的功能是管理數據，那麼隨着應用程序中存儲的數據的增長，測試組必須瞭解其性能的降低程度。數據庫和應用程序的優化技術可以極大的下降這種性能的退化。

（43）爲預期受衆定製可以使用性測試

         能夠經過下面幾種方法肯定目標受衆的需求：行業專家，專題組，調研，對同類產品的研究，觀察用戶的操做。

（44）特定需求和整個系統都須要考慮安全性

（45）研究系統對併發性測試計劃的實現

         在應用軟件領域，併發性指的是對多個用戶試圖同時訪問相同數據的處理。處理併發性問題有如下若干方法：保守方式（數據加鎖），開放方式（在模型中，容許用戶讀取數據，甚至容許更新數據，但在保存時，系統會檢查自從這個用戶檢索數據之後是否有其餘人更新過數據，若是數據發生了變化，那麼更新就失敗了），沒有併發保護（勝利屬於最後一個用戶）。

（46）爲兼容性測試創建高效的環境

十、管理測試的執行

（47）明肯定義測試執行週期的開始和結束

         無論是哪一個測試階段，爲軟件測試周期定義入口標準（測試開始時間）和出口標準（測試完成時間）都是十分重要的。

（48）隔離測試環境和開發環境

         測試環境必需要和開發環境隔離開來，這是避免測試期間的嚴重疏忽和沒法追蹤軟件的變化。若是沒有獨立的測試環境，那麼測試工做會遇到下面的一些問題：環境的變化，版本的管理，操做環境的變化。

（49）實現缺陷追蹤生命週期

（50）追蹤測試工做的進行 

         一個軟件項目所涉及的全部人都但願知道測試什麼時候結束。爲了可以回答這個問題，須要對測試的執行進行有效的跟蹤。爲了完成這項工做，咱們須要收集數據或者度量來顯示測試進度。有關進度的度量包括：測試過程執行狀況（%）=已經執行的測試過程數量/測量過程總數；缺陷持續時間=從發現缺陷到改正缺陷的時間跨度；從缺陷糾正到返測的時間=從缺陷被修正而且在新版本中發佈的時間到缺陷被返測的時間跨度；缺陷趨勢分析=在測試生命週期內，隨着測試工做的進行，發現缺陷的數量的變化趨勢；修改的質量=修改後剩餘的缺陷數量（在之前已經正常工做的功能上新引入或者從新出現的缺陷）；缺陷密度=一個需求中發現的缺陷總數/爲這個需求執行的測試過程數量。