细窥VS 2010中的“测试株连分析”(2) - 以程序员视角

     上回书我通过一个简单的实例为大家展现了TIA (Test Impact Analysis)为测试人员提供的价值——通过“波及面”分析，在进行回归测试时筛除“非亲非故”的测试，通过提高“精确打击”能力减少重复劳动，免作“冤大头”。

 

     今天，我们还是通过前面那个实例，来看一看TIA能为程序员提供哪些价值。有人可能说，Test Impact Analysis，顾名思义，是一种针对测试活动的分析，程序员也不怎么做测试，TIA能对程序员产生什么价值呢？

 

     程序员不做测试，或者只是简单地做些冒烟测试，这一现象随着单元测试观念的日益深入人心（特别是深入软件开发企业头头脑脑的人心）可能很快就要成为历史了，我想在不久的将来，单元测试也将是国内每一个职业程序员必修的功课，彼时为了不做无用功、不做冤大头，程序员们（当然，目前仅限于.NET程序员，用C++的程序员恐怕只能静候Visual Studio的下一个版本了）也会不得不爱上TIA滴 ;)

 

     为了把TIA能给.NET程序员们带来哪些甜头这件事讲清楚，我需要先给前面的那个“加减乘除计算器”项目添加了4个单元测试，分别验证实现加、减、乘、除这4项功能的4个方法，然后把这4个单元测试在Visual Studio 2010中运行一遍，确保这4个单元测试都能跑得通（参考图1）。这里有一点需要提醒大家的是，如果其中有一个测试跑不通的话，那么TIA将无法对该测试进行正确的“株连”分析。

 

图1 验证加减乘除4个方法的4个单元测试

 

     为了能用Visual Studio中进行测试株连分析，我们也得象在Test Manager中那样，在VS的IDE中将Test Impact诊断数据采集器（或者叫诊断数据适配器）启动起来（参考图2）。Test Impact诊断数据适配器的作用就是在执行测试过程中，把每个测试调用的代码或者说每个测试“掠过”的代码路径记录下来。

 

图2 在Visual Studio中启动Test Impact数据适配器

 

     接下来，我们要做的就是把前面新加的那些单元测试的代码签入到位于TFS的源码库中，随后，象上次一样，再运行一次Team Build，为“计算器”程序生成一个新的Build。虽然这个新的Build与以前的Build并无二致，但在运行Build的过程中，TIA会为我们自动采集、比对一些有价值的、有关单元测试代码覆盖范围的数据（参考图3），这些数据可以帮助我们很容易地“揪出”受后续代码改动“牵连”的那些单元测试。

 

图3 在Team Build运行过程中4个单元测试也被自动执行

 

     在以上准备工作做好之后，我们现在就可以对“计算器”程序的源代码做些改动了，上次我们改的是与除法相关的代码，这次我们就“应邀”改一下与乘法相关的代码吧。在我对乘法代码做了些画蛇添足的改动之后，我在IDE中打开了Test Impact View这个窗口（参考图4）

 

图4 在Visual Studio中打开Test Impact View窗口

 

 

     在Test Impact View这个窗口中，我们可以看到，它的上半部分为我们列出了我刚才改动过的方法，即Mult(int, int)，它的下半部分列出了受到此次修改影响的单元测试，即Test Chengfa（参考图5）。

 

图5 Test Impact View窗口

 

     在改完乘法代码之后，如果需要做一次回归测试的话，显然我不必把所有4个单元测试都运行一遍了，而只需把Test Chengfa这一个单元测试再运行一次就足够了。有人会说，对于可以自动运行的单元测试，跑1个和跑4个所耗费的时间能有啥区别呢？没错，跑1个和跑4个单元测试所耗用的时间确实相差无几，可如果你的项目中有400个或者4000个单元测试你还会这么说吗？

 

 

转载于:https://www.cnblogs.com/taokey/archive/2010/04/26/1721297.html