緊接着 上篇
經過上篇折騰，我們已經有了：
①手工測試的流程規范
②測試用例的管理
對於開發出身的我，我覺得一個項目上線流程應該主要瓶頸只能是開發本身，因為我認為最復雜過程應該就是開發，而肯定不能是測試。
對於測試流程我能接受對新功能測試的時候需要耗費大量時間的說法，但是我不接受回歸測試需要耗費大量時間的說辭。
對於需求上線前由於需求沒有固化下來，我是接受手工測試的，但是一旦這個業務需求上線后，意味着需求已經固化，那么此時就應該進行自動化。
后續上線其他任務的時候是否會有連帶影響的回歸測試，我認為是應該要靠自動化解決絕大部分問題。
什么？你沒自動測試？那平常干嘛去了
自動測試測啥
以前我們也折騰過自動測試，但是就是很難繼續推進，我覺得其中一個原因在於自動測試測啥這個問題上的不明確。
我的想法是：
要明白自動測試應該測什么，那我們首先應該要明白手工測試在測什么，然后再將有必要的部分將這部分手工測試轉為自動化，那這就是自動測試的內容里。
也因此我覺得首先是要規范手工測試，也因此上篇里重點說了如何用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
最后
上述就是近些日子在折騰的一些測試的東西。
俗話說一個好的流程不是設計出來的，而應該是迭代出來的，所以我也是一切在摸索中，然后再改進。
但是整體目標是明確的：敏捷，科學，規范