top100summit 微软郭贤忠-通过代码覆盖来进行有效回归测试 2

揭示研发管理白金定律，分享那些激动人心的创新与变革，使得团队获得过多源动力与更大的推动力！

通过代码覆盖来进行有效回归测试Jacky Guo 测试经理腾讯


摘要

业界的回归测试策略基本上有两种：全部回归，也就是把之前的所有的测试用例，无论是手动的，还是自动的，全部跑一遍部分回归，定性分析代码改动有哪些影响，代码改动的文件/模块和其他的文件/模块的依赖性，然后选择被影响到的文件/模块相应的测试用例来跑一遍

有没有定量的方法来分析受到哪些影响？


案例标题

a)案例简述通过第一次跑所有的测试用例，然后把对应的代码覆盖的情况存储到数据库；

以后修改代码的时候，通过查询数据库来找到对应的测试用例，这样跑测试用例就更加有针对性；b)　当初启动此案例时（或实施后）达到的目标

建立测试用例和代码覆盖的对应关系以及耦合关系；定量的分析回归测试的有效性；更有针对性的跑测试用例；有线跑重要级别的测试用例


谁，哪来的

业界的回归测试策略基本上有两种：全部回归，也就是把之前的所有的测试用例，无论是手动的，还是自动的，全部跑一遍部分回归，定性分析代码改动有哪些影响，代码改动的文件/模块和其他的文件/模块的依赖性，然后选择被影响到的文件/模块相应的测试用例来跑一遍

第一种的好处就是，通过大量的跑测试用例，可以尽量多的发现哪些功能是否有被影响到，缺点就是如果你的测试用例库很大，那这个是相当消耗时间和人力的；第二种的好处就是，不需要消耗大量的时间和人力，缺点就是因为是定性分析，所以有可能漏掉一些没有被分析出的影响；

那么有没有其他第三种办法，用定量分析的方法来进行回归测试？如果每次的系统回归测试用例需要5到7天来跑（以WINSE为例）；跑完全部才发现问题；

是否太迟？


怎么做到的


实践 1.1

- Block Change Analysis

- Coverage Impact Analysis

- Impacted trace prioritization report


实践 1.2

Compare existing coverage data for a binary to a new version of the binary.

Perform code coverage prediction for new blocks of the binary.

Organize tests for the binary in sets that will maximize coverage of the impacted blocks in the new binary in the minimum number of tests.


实践 1.3


5

2

4

1

3

T1

T2

T3

T4

T5

Set 1Set 1Set 1Set 1T1

T2

Set 2Set 2Set 2Set 2T3T5

Set 3Set 3Set 3Set 3

T4

4

1

3

0

1

1

Test Selection AlgorithmTest Selection AlgorithmTest Selection AlgorithmTest Selection AlgorithmImpacted Block Map

Denotes that a trace T covers the impacted block

Weights

2

0

0

0


Demo command linescout.exescout.exescout.exescout.exe -Build Build Build Build "Data Source=WinSECov01; Initial Catalog=vista_rtm.merged;Persist Security Info=True; User ID=coverage_user; Password=coverage_user; Connection Timeout=600" 6000.16386.x86fre.vista_rtm.061101-2205.merged "\\codecovfs01\builds\vista_rtm_6000.16386.x86fre.vista_rtm.061101-2205\dll" -NewBinaryNewBinaryNewBinaryNewBinary "\\tt\ccbins\vista\sp1\vista_ldr\fre\neutral\wininet.dll\6.0.6000.21015\x86\(root)\wininet.dll” -SourceInfoSourceInfoSourceInfoSourceInfo All –GroupSameCoverageTracesGroupSameCoverageTracesGroupSameCoverageTracesGroupSameCoverageTraces -NoCumulativeCoverageNoCumulativeCoverageNoCumulativeCoverageNoCumulativeCoverage -NumberOfSetsNumberOfSetsNumberOfSetsNumberOfSets 10101010 -OutputOutputOutputOutput "D:\temp\scout_wininet.xml“

Demo: Scout tool


案例ROI分析

投入：

只要第一遍跑Baseline的测试用例并且存储相应的代码覆盖；以后每次只要看Diff，知道哪些东西被更改了，就可以从数据库找出Diff代码对应的测试用例；一

劳永逸；

产出：

WinSE的数据统计显示，通过这样的方法， 62%到67%的Bug都可以尽早发现。


案例启示

除了开发做单元测试需要熟悉代码；做API测试需要熟悉API；做黑盒测试/灰盒测试也可以多考虑通过代码来提高准确率和效率；

通过代码覆盖率来定量分析测试的效果是其中之一；通过寻找关键API，找出如果修改了关键API会造成的影响；此外还可以通过分析Bug，看看Component 直接的耦合性，找出文件与文件之间，或者是控件(dll)与控件之间的依赖性；

只有做到定量分析，才能更好的做系统测试，回归测试；而不是单纯的黑盒测试。

top100summit 微软郭贤忠-通过代码覆盖来进行有效回归测试 2

Documents