重讀《從菜鳥到測試架構師》-- 黑色的盒子裏有什麼（下）

前面的章節中，咱們說到，在導師的講解下，小艾明白了測試的策略及流程，但依然不知道應該如何作以及具體作什麼。這時導師告訴小艾，功能測試人員除了以前學到的基本技能和策略/流程以外，最重要的是要理解和掌握各類各樣的文檔。

 

文檔

可以很好地理解別人寫的文檔，是對功能測試人員最基本的要求。而可以寫出好的文檔，則是資深功能測試人員，特別是測試組長/測試架構師的基本素質。

功能測試計劃書

功能測試計劃書涵蓋了整個產品的功能測試範圍及各類相關條件。

在敏捷開發模式下，具體功能特徵的功能測試計劃書是一個按照迭代週期迭代開發的測試計劃書。

 

測試場景

測試場景是功能測試中一個很是重要的概念，只有設計好的功能測試場景，纔可以真正表明客戶，站在客戶的立場上進行測試。

每個功能測試場景都是由一個或多個用例組成的：Scenario(S)={UC1, UC2,... UCN}

由於功能測試場景是功能測試用例的邏輯，要完成功能測試用例，功能測試人員須要建立數據和結果驗證。不一樣的功能測試用例能夠是同一個測試場景，可是有不一樣的數據和結果驗證，所以，功能測試用例能夠定義爲：Test Case = (Sf, D, RV), 其中，Sf 爲功能測試場景(由一個設計文檔中的一組用例按照必定的邏輯組織起來的場景)，D爲數據（輸入信息或者場景中須要的材料），RV爲結果驗證（一系列步驟）。

在功能測試場景中列出的每一步，都須要有一對一的數據和結果驗證的對應。

好的測試設計須要對測試產品和目標用戶的商業需求有深刻的理解，同時要對產品的功能很是熟悉，好的測試場景和測試用例的設計對於測試的質量和測試執行的效率是很是有好處的。一個好的測試用例將清楚地描述什麼會被測試，將產生什麼樣的結果以及爲何會產生這樣的結果。

完整的測試用例至少要包含如下幾個方面：輸入、指望值、系統運行的前置條件或說明。

聽完導師的介紹以後，小艾開始動手寫起了第一個功能測試用例，看着本身對功能測試策略、流程的初步理解，小艾也感到頗有成就感。

編寫自動化測試腳本

搭建好測試環境後，小艾正式開始了執行功能測試用例的工做，產品開發初期的迭代過程，主要是以手動執行的方式執行功能測試用例，同時對這些功能測試用例進行自動化的開發，而在後面的迭代過程當中，則會藉助於各類工具進行對執行過程的跟蹤、記錄。

開發自動化測試腳本還可以幫助功能測試人員更好地理解測試用例的邏輯，突出對功能測試用例中的功能點的理解。自動化開發出了要熟悉相關編程技巧，還要有相應的自動化開發的框架做爲支撐，並有完備的自動化測試策略和流程保證自動化代碼的重用性和代碼質量。

仍是一樣的，書中使用的是JUnit + Selenium的方式用java編寫自動化腳本，但本人比較熟悉使用C#語言，很便捷的是，Visual Studio 提供了相應的dll組件幫助咱們完成自動化腳本的開發。

只須要在項目中引用 SHDocVw 以及Microsoft.mshtml，而後使用using將其包含在項目程序中，便可以使用最簡單的方式編寫代碼運行了，例如：

固然，也能夠藉助已有的框架，如NUnit, WatiN, Selenium等等框架支持自動化腳本的開發，其原理都差很少，不過相比較而言，使用這些市場上使用較廣的框架對測試腳本的支持度會比較高~

 

找到了第一條蟲子

經過了上述的講解及本身的親身實踐，小艾很快就發現了產品的第一個bug，小艾的欣喜之情自沒必要說，然而小艾依然忽略了一些小問題，諸如用戶的體驗度。儘管一個產品的一個功能可以正常使用，但如果體驗不夠好，也依然是測試人員在測試過程當中須要指出來的~

 

執行高手

在導師的幫助下，在本身的實踐中，小艾總結到：一個好的功能測試人員須要掌握如下技能並加以持續的錘鍊。

 

文檔的理解

功能測試最重要的是理解業務需求，熟悉產品，熟悉具體的功能模塊，功能特徵的設計文檔，熟悉功能測試場景和用例。

 

產品框架和數據結構的瞭解

更好地尋找問題及分析/定位問題發生的緣由

產品環境的理解和技能的培養

兼容測試用例策略，更好地排除是否由環境引發問題的發生

 測試工具的理解和技能掌握

效率的提高

問題分析能力

對功能測試中出現的問題的分析能力，是一個功能測試人員的一個重要衡量指標。

尾聲

在組長的帶領下，小艾走過了對功能測試知識從初步理解到具體執行的過程，完成了從菜鳥到一個合格的功能測試執行人員的成長。此時，組長又會用怎麼樣的方式帶着小艾繼續從更全面的角度去了解功能測試，帶領小艾成長呢？請聽下回分解~

 

想要第一時間看到這一系列文章的更新及更多精彩內容能夠掃描下面二維碼關注微信公衆號: 倚樓聽風雨的如月