緊接著 上篇 

經過上篇折騰，我們已經有了：

①手工測試的流程規範

②測試用例的管理 

對於開發出身的我，我覺得一個專案上線流程應該主要瓶頸只能是開發本身，因為我認為最複雜過程應該就是開發，而肯定不能是測試。

對於測試流程我能接受對新功能測試的時候需要耗費大量時間的說法，但是我不接受迴歸測試需要耗費大量時間的說辭。

對於需求上線前由於需求沒有固化下來，我是接受手工測試的，但是一旦這個業務需求上線後，意味著需求已經固化，那麼此時就應該進行自動化。

後續上線其他任務的時候是否會有連帶影響的迴歸測試，我認為是應該要靠自動化解決絕大部分問題。

什麼？你沒自動測試？那平常幹嘛去了

自動測試測啥

以前我們也折騰過自動測試，但是就是很難繼續推進，我覺得其中一個原因在於自動測試測啥這個問題上的不明確。

我的想法是：

要明白自動測試應該測什麼，那我們首先應該要明白手工測試在測什麼，然後再將有必要的部分將這部分手工測試轉為自動化，那這就是自動測試的內容裡。

也因此我覺得首先是要規範手工測試，也因此上篇裡重點說了如何用TFS進行手工測試的管理。

之後按照每次迭代是一個測試計劃的模式，每次迭代完後，可能要從之前測試計劃裡挑選出一定程度需要日常回歸的測試。

畢竟有些測試其實一次性就完了，但是有一些則每次都要回歸下的，先將這部分挪到一個專門的測試計劃叫“xxx專案迴歸測試” 

裡面專門挑選了有必要回歸的用例 

如何進行自動化測試

這就牽扯到自動化框架的選擇了，甚至包括配套測試開發的語言選擇。

由於我們開發團隊是以C#為主，所以我們也選擇了C#作為測試開發語言（咱不黑不捧不踩不槓，不要糾結為什麼是C#而不是Js/Python/Java…熟悉什麼用什麼，重點是解決問題）

然後再開發體驗上我是希望測試開發能使用最接近他們實際測試時候的體驗，所以選擇了基於BDD模式的Specflow。 

關於什麼是Specflow這麼不過多介紹，可以自行在各大搜索引擎或者部落格園自身的搜尋裡搜下一大堆介紹，我這裡就簡單說兩句：

Specflow它會有一個.feature檔案，一個feature裡包含若干個Scenario場景，一個場景理解為就是我們一個測試用例

一個場景下可以包含由若干個行為構成的一個執行序列，在這裡你可以定義各種行為，一個簡單的例子如：

它由最基礎的Given(給定xxx)/Then(然後呢？）/When（當xxx的時候，上圖沒展示）構成一個行為描述 

基礎這個行為描述，每一段背後會對應一個程式碼 

上圖瞎寫的C#先別吐槽，只是表明feature檔案裡每一個行為，其實背後會對映到一段程式碼，然後通過行為的組合拼裝，完成一個完整的業務。

具體是怎麼做的呢

然後遵照著之前手工的測試用例，使用Specflow來撰寫它的測試行為可能會類似於這樣 

這是一個在TFS裡託管的手工測試用例的Test Case

然後我對照著這個手工的測試用例我撰寫的Specflow的feature下的Scenario

然後背後在將這每段程式碼做實際的實現，實現的時候可以直接調介面處理也行，通過Selenium走UI測試也行，這個無所謂。

然後就能在VS裡的測試管理器裡跑起來這個測試了 

我通過Specflow寫了自動測試用例了，TFS能知道麼

能！

為了避免後面大家不理解這些操作的含義我大概先說下TFS下整個流程的套路：

①先在測試管理器裡，然後你測試和TFS的測試用例關聯，此步驟後對應測試用例會關聯上你匹配的程式集裡的對應測試程式碼

②配置一個生成（Build）要編譯出你對應的測試專案

③配置一個釋出（Release）用於執行你的測試專案

④當你在TFS進行測試自動執行時候，它建立一個釋出（Release）獲取到程式集在執行你對應的測試，然後將狀態彙報關聯到對應的測試用例。

重點：這套機制只支援.Net Framework,請不要在.Net Core上浪費時間，我已經摺騰了2天，它永遠找不到測試程式集，實在無解

廢話不多說，開始do it 

和TFS測試用例關聯

請先確保你的vs連線了tfs，比如確保你的團隊管理器看起來應該長得是這個樣子 

然後在測試管理器裡，對著你的測試，郵件，關聯到測試用例 

然後關聯你的測試用例的Id

此時你在TFS裡看你對應測試用例會變成已經自動化的狀態 

而正常其他沒做這個步驟的則是未自動，如 

Note: 上述步驟可參考微軟官方文件（只有英文） https://docs.microsoft.com/en-us/azure/devops/test/associate-automated-test-with-test-case?view=azure-devops 

在TFS上執行自動測試

然後需要在TFS裡配置你這個測試計劃關聯的生成（Build）和（Release）。

配置生成（Build）的這個步驟省略，就找找常規的Azure Pipeline相關就行。

主要釋出（Release）裡有一點點不一樣 

在“通過以下方式選擇測試”這裡我們選擇Test Plan或者Test run。

Test Run

如果你要支援在TFS的測試裡隨便選取某個已被自動化的測試用例進行執行，請使用Test Run 

Test Run是用於這個場景 

Test Run不支援在CD（持續部署）場景下執行，也就是你不能直接在TFS的“生成和釋出“裡建立一個釋出（Release）然後對它進行執行，準報錯。

配置這個之後以後可以直接在測試管理器裡隨意點選執行任意已自動化的用例 

Test Plan

Test Plan可以使得VSTest的步驟選擇你規劃的測試計劃裡指定已自動化的測試進行執行，我自己就是讓它每晚自動跑的時候用。

後續你這個測試計劃里加了啥新的測試用例它也會接著自動跑。

配置下用Test Plan的那個工作日上每天凌晨自動跑，跑完放個Budget出來就好了。

上述步驟可以參考微軟官方文件（只有英文） https://docs.microsoft.com/en-us/azure/devops/test/run-automated-tests-from-test-hub?view=azure-devops

最後 

上述就是近些日子在折騰的一些測試的東西。

俗話說一個好的流程不是設計出來的，而應該是迭代出來的，所以我也是一切在摸索中，然後再改進。

但是整體目標是明確的：敏捷，科學，