選取最適合用來實作測試的技術。對於您要執行的每一項測試,考量至少實作一個「測試 Script」。 特定測試的實作有時會跨越多個「測試 Script」。 有時單一「測試 Script」會提供多項測試的實作。
實作測試的一般方式包括以 Script 形式撰寫要遵循的文字說明(用於手動測試), 以及使用 Script 程式設計語言來設計、擷取/錄製或產生(用於自動化測試)。 下列各節探討每一種方法。
如同大多數方法一樣,建議您混合使用下列技術來取得更有用的結果。 雖然不必照單全收,但也不應該自我局限在單一技術上。
子主題:
有許多測試最好手動執行,請避免陷入嘗試不當地自動化測試的陷阱。 使用性測試就是手動測試通常優於自動化測試的一個領域。另外,需要在軟體系統的實際輸出上驗證精確性和品質的測試,通常也需要手動驗證。
根據一般的經驗,最好以手動實作來進行特定「目標測試項目」的初期測試; 這種方式可讓測試人員瞭解目標項目、順應非預期的行為來調整,以及透過人為判斷來決定下一步要採取的適當行動。
有時,手動執行的測試後來會形成自動化,並在迴歸測試策略中重複使用。 然而,請注意,您可手動執行的每一項測試,並非都必須或適合(或甚至可能)自動化。 在測試執行、可見度及對照詳細測試結果的速度和精確度上,以及在建立和維護複雜測試的效率上,
自動化確實帶來優點,但就像所有實用的工具一樣,不可能解決您的所有需求。
自動化有某些缺點:基本上是在測試執行期間缺乏人為判斷和推理。 目前可用的自動化解決方案完全沒有人類具備的認知能力 - 相信永遠也不可能有。 在手動測試的實作期間,人為推理可運用在系統對於刺激因素的觀察反應上。
目前的自動化測試技術及支援工具,通常不太有能力注意到某些系統行為的含意,更沒有什麼能力透過演繹推理來推測可能的問題。
大多數採用測試自動化的測試人員所認同的最佳方式。純粹以理論來說,此慣例的執行方式和採用的通則同於軟體程式設計。 因此,軟體程式設計上使用的大多數方法和工具,通常也適用且有益於測試自動化程式設計。
在標準的軟體開發環境(例如 Microsoft Visual Studio 或 IBM Visual Age)或特殊的測試自動化開發環境下(例如 Rational Robot 提供的 IDE),
測試人員可以不受約束地將開發環境的特性和功能發揮得淋漓盡緻。
程式設計自動化測試的缺點在於直接以程式設計當做一般技術的缺點。 為了讓程式設計發揮效用,在適當的設計上應該有所考量:否則實作很可能失敗。
如果開發的軟體很可能歷經不同的人來修改(常見的情況),則必須考量在程式開發中採用一般的樣式和格式,並確保用法正確。 有兩項最重要的考量大多肇因於誤用這項技術。
首先,測試人員會全神貫注在程式設計環境的功能上,投入太多時間在問題上精心製作講究又精密的解決方案,然而有更簡單的方法可以解決。 結果,測試人員在原本是程式設計的工作上浪費寶貴的時間,排擠掉可以實際測試和評估「目標測試項目」的時間。
需要規範和經驗才能避免落入這個陷阱。
其次,用來實作測試的程式碼將因為人為錯誤或疏忽而潛藏錯誤。 有些錯誤在正常實作自動化測試期間很容易除錯和更正:但有些則不可能。 就像有些錯誤無法在「目標測試項目」中偵測到一樣,在測試自動化軟體中也同樣難以偵測到錯誤。
再者,當自動化測試實作中採用的演算法是根據軟體實作本身採用的同一種錯誤演算法時,也可能引起錯誤。 這會導致未偵測到錯誤,被表面上執行成功的自動化測試的安全假象所蒙騙。 請儘量在自動化測試中採用不同的演算法來降低這種風險。
有許多測試自動化工具可以錄製或擷取軟體應用程式的人機交談過程,然後產生基本的「測試 Script」。 這有許多不同的工具解決方案。大多數工具會產生以某種高階(通常可編輯的)程式設計語言來實作的「測試 Script」。
最常見的設計有下列運作方式:
-
將用戶端硬體過邊輸入裝置(滑鼠、鍵盤等)的輸入攔截到用戶端作業系統,以擷取與應用程式用戶端 UI 的互動。
有些解決方案會攔截作業系統和裝置驅動程式之間交換的高階訊息,這些訊息以稍具意義的方式描述互動; 另外一些解決方案會擷取低階訊息,通常根據滑鼠座標上的時間性移動,或 key-up 和 key-down 事件。
-
攔截用戶端應用程式和一或多個伺服器應用程式之間透過網路收送的訊息。 成功攔截這些訊息通常仰賴於使用標準、公認的傳訊通訊協定, 例如 HTTP、SQL 等。 有些工具也可以擷取「基本」通訊協定,例如 TCP/IP,但用於這種性質的「測試 Script」會很複雜。
雖然這些技術通常適合納入自動化測試方法中,但部分業者認為這些技術有所限制。 其中一項主要的考量是有些工具只是擷取應用程式互動,此外毫無功用。 如果不加入觀察點來捕捉和比較後續 Script 執行期間的系統狀態,基本「測試
Script」不能視為完整的測試。 在此情況下,最初的錄製功能必須再加強,加入其他自訂的程式碼在「測試 Script」內實作觀察點。
關於此點及其他以測試程序錄製或擷取做為測試自動化技術的議題上,有許多作者已出版書籍和評論。 若要深入瞭解這些議題,建議您閱覽下列作者公佈在網際網路上的著作:James Bach、Cem Kaner、Brian Marick 及 Bret Pettichord, 以及 Lessons Learned in Software
Testing 這本書的相關內容 [KAN01]
有些較精密的測試自動化軟體可以根據產生演算法,實際產生測試的各種層面 -「測試 Scriipt」的程序化層面或「測試資料」層面。 這種自動化有利於您的測試工作,但本身不足以成為完整的方法。 Rational TestFactory 工具和
Rational TestManager 資料儲存池產生特性是這種技術的實作例子。
|