平民化的安卓測試工具--ThreadingTest介紹

1、軟件測試領域30餘年的主題----黑盒測試與白盒測試

測試在軟件開發的整個生命週期中佔據非常重要的地位,這一點從測試所佔的時間上可見一斑,我們經常使用的測試方法大體上可分爲黑盒測試和白盒測試,這是測試方法中的最典型的代表。


圖1 常規軟件工程各階段所佔時間比例


黑盒測試又稱爲功能測試或者數據驅動測試, 是把要測試的軟件看成一個 “黑盒子”, 不管其內部結構如何以及以什麼算法實現所要求提供的功能,而是按照需求的功能化要求, 設計相應的測試用例(包括測試的輸入數據與條件設置和所預期的軟件運行輸出結果), 通過軟件運行後所給出的輸出(包括字符形式的輸出與圖象輸出)與所預期的結果進行人工或者自動化比較, 來驗證被測試軟件是否能給出正確的結果, 從而判斷該軟件是否滿足需求, 是否與該軟件系統的規格說明書和用戶手冊相關部分一致。

      白盒測試也稱爲結構測試或者邏輯驅動測試,它與黑盒測試方法相反: 它不管所被測試的軟件是否滿足需求,是否實現了所設計的功能, 而只注重該軟件內部的結構, 以便設計足夠多的測試用例, 使得百分百或者儘可能多的程序組成要素能被測試到最少一次, 從而儘可能地將其中的軟件錯誤暴露出來。測試市場上的白盒測試在測試領域本來就不是非常流行,那是因爲傳統的白盒測試是需要很高的編程能力,在測試人員中很難流行起來。而TT則對傳統的白盒測試過程和方法進行了大規模的創新,甚至不改變傳統黑盒測試的方法和過程的基礎上,自動產生完整的白盒分析數據。TT採用的方法更接近於測試理論界的灰盒子測試方法,而傳統的白盒測試廠商對該理論方法並不理解,縱觀全球市場也鮮有相關產品。

 

2、全新的穿線測試

       黑盒測試和白盒測試從概念上來說是比較對立的,黑盒測試得到的結果很難定位到內部結構的所在位置,即功能性的錯誤不能定位到錯誤的代碼處,只能由開發人員根據錯誤現象憑經驗手工排查和定位;白盒測試的結果也很難跟功能應用直接掛鉤,因爲不是所有的內部結構都和功能應用有直接的關係。鑑於這些問題,灰盒測試的概念就自然而然的被提出,它介於黑盒與白盒之間,既關注功能的輸入輸出的正確性測試,也注重內部結構的測試。既包含了黑盒和白盒的優點,又彌補了兩者的不足。但灰盒測試在市場上幾乎鮮見有商用的測試工具支持,其主要方法僅僅停留在概念階段,並沒有在此基礎上上設計可商用的工具和功能。

      

灰盒測試這個理念要想真正發揮作用,必須使其“平民”化,而將一件複雜的工作簡化成一個普通從業者都能完成,通常的做法使用專業的工具,簡單的說,要輕鬆的實現灰盒測試,工具必不可少。TT正是這樣一種可以結合黑盒測試和白盒測試進而產生灰盒測試效果的工具。

 

3、TT的灰盒測試技術

TT通過全局共享測試技術,穿線式的連接測試人員和開發人員,測試人員仍然以黑盒測試的方法,測試過程配合開發人員,在黑盒測試的基礎上,零成本實現白盒測試結果,從而產生灰盒測試的效果。

TT工具灰盒測試的典型工作流程如下:

1)           測試人員建立一個測試工程,由開發人員(對代碼保密要求不高的話也可以由測試人員操作)將源代碼通過TT編譯成爲插樁後的應用。

2)           測試人員使用上述由開發人員編譯後的應用進行測試用例編寫,並對應用進行黑盒測試方式的操作,操作過程通過TT提供的示波器進行測試路徑、覆蓋率等信息的記錄。


圖2 實時監控界面

3)           在測試過程中出現問題時,測試用人隨時停止記錄,在圖2界面的示波器下部的控制檯區域(Console),實時記錄了測試用例最近運行的50個函數,開發人員根據測試路徑,可以輕鬆直觀的定位問題代碼的範圍。

4)           測試過程中,開發人員和測試人員通過TT的雙向追溯(測試用例到源碼的追溯、源碼到測試用例的追溯)提供的測試信息共享平臺,可以共同制定和優化測試用例,比如增加一些目標功能以外的測試用例,使得應用程序的關鍵模塊測試覆蓋率達到100%,在黑盒測試的同時幾乎可以零成本實現白盒測試。

TT以其獨特的技術特性,協同開發和測試人員進行高效的溝通互動,讓開發和測試融爲一體,通過2+1(測試、開發+TT)的模式讓灰盒測試成爲“平民”化的測試方法。

 

3、TT開啓開發與測試的破冰之旅

 

 

在軟件開發生命週期中,開發和測試之間的有效溝通和互動一個業界一直未有效解決的問題。在穿線測試理論出現之前,開發與測試通常只能通過自然語言進行互動和溝通,效率與精確性難以保障。例如當測試人員在執行一個測試用例發現缺陷的時候,他必須靠自然語言描述該故障出現的場景、條件等,這樣開發就必須按照測試人員的描述來重現缺陷,然後再通過debug來解決問題。而通常基於測試人員自然語言描述的問題的重現會消耗大量的時間,甚至在更換環境以後無論怎樣都無法重現,這個週期在寶貴的軟件開發時間裏面會顯得異常的冗長。而TT在測試人員執行用例的過程中,自動的記錄了測試人員進行操作的過程中,程序內部的精細到每一個路徑、分支的執行情況,開發人員可以通過TT直接拿到測試實施這

些數據,快速定位問題。TT通過自動化手段進行灰盒測試的優化應用,並提供開發測試解決方案。它採用的專利問題解決方案技術,從以下幾個方面大大加速了測試過程中問題解決流程:提供了自動化的信息採集、捕獲現場操作並將所有的相關信息統一打包處理;消除了通常情況下需要完整重現問題發生的過程,避免在重現問題上耗費的時間開銷;大大加速了問題分析的過程,使得開發人員能夠快速分析問題並隔離根源問題。

 

另外一個角度,由於一般測試人員無法看到程序的內部邏輯,僅僅從功能表象上對被測程序的特性進行測試,因此沒有量化的數據,通常沒有辦法和開發人員進行詳細和高小的溝通,而由於二者本職工作方面差異的原因,通過開發人員也不會非常主動的幫助測試人員設計非常精準的用例。而有了TT以後,測試人員可以很明確的看到自己黑盒測試對應的程序內部的邏輯的覆蓋情況,這樣測試人員就可以通過這些量化、可視化的數據,而開發人員進行很容易的互動,因爲拿着數據說話,很容易獲得認同,開發人員就可以和測試進行非常有效的溝通和配合,一起爲達到對關鍵模塊精細化的,接近於100%的覆蓋率進行努力。一同協作來對測試人員的用例進行補充。

 

 

對於測試人員來講,每個版本的變更對迴歸測試時非常重要的依據,TT會給測試人員非常精確的每個版本的變化信息,而不再是通常由開發給出的模糊且帶有大量遺漏的信息。另外基於TT的智能的雙向追溯技術特性,它甚至可以直接告訴測試人員,這些變更應該會影響到哪些測試用例。幫助測試人員在海量用例集裏面,針對本次的變更,直接定位那些需要進行復測的測試用例。同樣,開發人員在計劃對代碼邏輯進行變更的時候,也可以利用測試人員建立的測試用例與代碼邏輯的關係庫,去分析一個功能點是如何實現的,對某些代碼的改變會影響到那些其他功能點。TT的最大創新在於,測試人員在測試過程中由TT產生的數據,將被開發與測試共享使用,從技術手段將開發與測試之間的距離拉近。

 

TT在黑盒測試過程中自動記錄用例與代碼的邏輯對應關係,應用問題解決方案非常適用於測試人員和開發人員。對於測試人員來說,由於自動記錄了測試場景和問題發生過程,避免了開發人員和測試人員之間相互推諉,同時開發人員可以通過“黑盒子”直接從測試人員那裏得到更多信息,並幫助直接定位到代碼行。

 

 

 



發佈了41 篇原創文章 · 獲贊 3 · 訪問量 11萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章