2.自動化測試策略

2.1 自動化測試的工做方式

功能自動化測試：

經過軟件工具（測試腳本）模擬用戶實際的鼠標、鍵盤、觸屏等操做，實現自動化執行和操做被測對象的預期功能。

 

性能測試：

經過軟件工具（測試腳本）模擬多個虛擬用戶併發請求，來檢驗服務器的性能行爲是否知足系統要求。

 

自動化測試的基本工做流程：

自動化測試用例設計->編寫自動化測試腳本->執行自動化測試腳本->收集自動化測試報告->分析測試結果

 

 

自動化測試框架成熟後，最主要的工做是自動化測試用例的設計和自動化測試腳本的編寫，至關於一個測試人員的測試思想和測試能力。

2.2 如何在項目中引入自動化測試

在項目中引入自動化測試，須要評估：
該項目是否適合作自動化測試？是否有合適的人力和時間去作自動化測試？

以上問題答案都爲是的條件下，能夠將自動化測試列爲一個項目。前期須要搭建自動化測試框架，而後分析自動化測試的需求，自動化測試任務排期，自動化測試腳本驗收、提交、執行，繼而是自動化測試的迭代。

2.3 BDD及TDD思想在自動化測試中的應用

TDD - Test-Driven Development，即測試驅動開發：它是一種測試先於編寫代碼的思想用於指導軟件開發。測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。

TDD的原理：在開發功能代碼以前，先編寫單元測試用例代碼，測試代碼肯定須要編寫什麼產品代碼。

 

BDD - Behavior Driven Development，行爲驅動開發是一種敏捷軟件開發的技術，它鼓勵軟件項目中的開發者、QA和非技術人員或商業參與者之間的協做，是對TDD的理念進行了擴展。

 

 

 

TDD側重點偏向開發，經過測試用例來規範約束開發者編寫出質量更高、bug更少的代碼。而BDD更加側重設計，其要求在設計測試用例的時候對系統進行定義，倡導使用通用的語言將系統的行爲描述出來，將系統設計和測試用例結合起來，從而以此爲驅動進行開發工做。

BDD描述的行爲就像一個個的故事(Story)，系統業務專家、開發者、測試人員一塊兒合做，分析軟件的需求，而後將這些需求寫成一個個的故事。開發者負責填充這些故事的內容，測試者負責檢驗這些故事的結果。一般，會使用一個故事的模板來對故事進行描述。

   BDD的通用語言是一種近乎天然語言的描述軟件的形式。基於這種通用語言形式能夠儘量的避免客戶和開發者在溝通上的障礙，實現客戶和開發者同時定義系統的需求。避免了由於理解需求不充分而帶來的沒必要必要的工做量。

 

Story：

As a 角色

I want 特徵

so that 利益

As a標識出這個系統行爲是爲哪個角色而定義的。

I want和so that則指明瞭該角色想作的事， 以及想達到的目的。這三個斷句定義了這個系統行爲的參與者、範圍。

一樣的一個Story，可能會有不一樣的場景。經過上面的模板描述了故事以後，再經過下面的模板對不一樣場景進行描述

Scenario:

Given [上下文]

 And [更多的上下文]

When [事件]

Then [結果]

 And [其餘結果]

這些場景中的Given…When…Then…實際上就是設定該場景的狀態、適用的事件，以及場景的執行結果。

其實經過這樣的Story描述和場景設置，基本就完成了一個完整測試的定義。