紧接着 上篇
经过上篇折腾，我们已经有了：
①手工测试的流程规范
②测试用例的管理
对于开发出身的我，我觉得一个项目上线流程应该主要瓶颈只能是开发本身，因为我认为最复杂过程应该就是开发，而肯定不能是测试。
对于测试流程我能接受对新功能测试的时候需要耗费大量时间的说法，但是我不接受回归测试需要耗费大量时间的说辞。
对于需求上线前由于需求没有固化下来，我是接受手工测试的，但是一旦这个业务需求上线后，意味着需求已经固化，那么此时就应该进行自动化。
后续上线其他任务的时候是否会有连带影响的回归测试，我认为是应该要靠自动化解决绝大部分问题。
什么？你没自动测试？那平常干嘛去了
自动测试测啥
以前我们也折腾过自动测试，但是就是很难继续推进，我觉得其中一个原因在于自动测试测啥这个问题上的不明确。
我的想法是：
要明白自动测试应该测什么，那我们首先应该要明白手工测试在测什么，然后再将有必要的部分将这部分手工测试转为自动化，那这就是自动测试的内容里。
也因此我觉得首先是要规范手工测试，也因此上篇里重点说了如何用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
最后
上述就是近些日子在折腾的一些测试的东西。
俗话说一个好的流程不是设计出来的，而应该是迭代出来的，所以我也是一切在摸索中，然后再改进。
但是整体目标是明确的：敏捷，科学，规范