﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>IT博客-三原的测试生活-随笔分类-软件测试</title><link>http://www.cnitblog.com/lyfever/category/6771.html</link><description>希望点亮梦想</description><language>zh-cn</language><lastBuildDate>Tue, 27 Sep 2011 21:54:38 GMT</lastBuildDate><pubDate>Tue, 27 Sep 2011 21:54:38 GMT</pubDate><ttl>60</ttl><item><title>各种覆盖率方法介绍(2)</title><link>http://www.cnitblog.com/lyfever/archive/2008/01/19/39061.html</link><dc:creator>三原</dc:creator><author>三原</author><pubDate>Sat, 19 Jan 2008 12:32:00 GMT</pubDate><guid>http://www.cnitblog.com/lyfever/archive/2008/01/19/39061.html</guid><wfw:comment>http://www.cnitblog.com/lyfever/comments/39061.html</wfw:comment><comments>http://www.cnitblog.com/lyfever/archive/2008/01/19/39061.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cnitblog.com/lyfever/comments/commentRss/39061.html</wfw:commentRss><trackback:ping>http://www.cnitblog.com/lyfever/services/trackbacks/39061.html</trackback:ping><description><![CDATA[<strong><span>2 </span><span>基本的度量</span><span> </span></strong><span><br></span><span>有许多覆盖率度量存在，这里介绍一些基本的度量的益处和弱点。</span>&nbsp;<span><br></span><strong><span>2.1 </span><span>语句覆盖（</span><span>Statement&nbsp;Coverage&nbsp;</span><span>）</span><span> </span></strong><span><br></span><span>这个度量报告每一个可执行语句是否被执行。</span>&nbsp;<span><br></span><span>也称为：行覆盖（</span><span>line&nbsp;coverage</span><span>）</span><span>,&nbsp;</span><span>段覆盖（</span><span>segment&nbsp;coverage</span><span>）</span><span>&nbsp;[Ntafos1988],&nbsp;C1&nbsp;[Beizer1990&nbsp;p.75]&nbsp;</span><span>和基本块覆盖（</span><span>basic&nbsp;block&nbsp;coverage</span><span>）。基本块覆盖当每一个序列的语句是无分支的语句时和语句覆盖相同。</span>&nbsp;<span><br></span><span>这个覆盖度量的主要好处是它可以直接应用在目标码上，不需要对源代码进行处理。执行轮廓就完成了这个度量。</span><span> </span><span><br></span><span>这个覆盖度量的主要缺点是对一些控制结构很迟钝。例如，考虑下列的</span><span>C/C++&nbsp;</span><span>代码：</span>&nbsp;<span><br></span><span>int*&nbsp;p&nbsp;=&nbsp;NULL; </span><span><br></span><span>if&nbsp;(condition) </span><span><br></span><span>&nbsp;&nbsp;&nbsp;&nbsp;p&nbsp;=&nbsp;&amp;variable; </span><span><br></span><span>*p&nbsp;=&nbsp;123; </span><span><br></span><span>如果当</span><span>condition&nbsp;</span><span>取假的情况下，语句覆盖率显示这四句都覆盖到了，但是代码执行是失败的。这是一个语句覆盖率的严重的缺陷，</span><span>IF</span><span>语句是很普通的一种情况。</span>&nbsp;<span><br></span><span>语句覆盖不能报告循环是否到达它们的终止条件―――只能显示循环是否被执行了。</span>&nbsp;<span><br></span><span>既然</span><span>do-while&nbsp;</span><span>循环通常要至少执行一次，语句覆盖认为它们和无分支语句是一样的。</span>&nbsp;<span><br></span><span>语句覆盖率对逻辑运算符反映是迟钝的</span><span>(||&nbsp;and&nbsp;&amp;&amp;)</span><span>。</span>&nbsp;<span><br></span><span>语句覆盖不能区分连续的</span><span>switch&nbsp;</span><span>语句。</span>&nbsp;<span><br></span><span>测试用例通常和判定有关而不是和语句有关。你可能不必用</span><span>10</span><span>个单独的测试用例来测试一个有</span><span>10</span><span>个无分支语句的语句，你可能只用一个测试用例就够了；考虑一个</span><span>IF</span><span>－</span><span>else</span><span>语句，包含一条语句在</span><span>then</span><span>子句，</span><span>99</span><span>条语句在</span><span>else</span><span>子句，当执行两个可能路径的其中之一时，语句覆盖率得到如下的结果：</span><span>&nbsp;1&nbsp;&nbsp;</span><span>或</span><span>&nbsp;99&nbsp;&nbsp;</span><span>的覆盖率。基本块覆盖率就忽略了这个问题。</span>&nbsp;<span><br></span><strong><span>2.2 </span><span>判定覆盖（</span><span>Decision&nbsp;Coverage&nbsp;</span><span>）</span><span> </span></strong><span><br></span><span>这个度量报告是否</span><span>BOOL</span><span>型的表达式取值</span><span>true&nbsp;</span><span>和</span><span>false</span><span>在控制结构中被测试到了</span><span>(</span><span>例如</span><span>if-statement</span><span>和</span><span>while-statement)</span><span>。</span>&nbsp;<span>整个的</span><span>BOOL</span><span>型的表达式被认为是取值一个</span><span>true&nbsp;</span><span>和</span><span>false</span><span>，而不考虑是否内部包含了</span><span>logical-and&nbsp;</span><span>或</span><span>&nbsp;logical-or&nbsp;</span><span>操作符。另外，这个度量包括</span><span>switch-statement&nbsp;cases,&nbsp;exception&nbsp;handlers,&nbsp;and&nbsp;interrupt&nbsp;handlers</span><span>的覆盖</span><span>.&nbsp; </span><span><br></span><span>也被称为：分支覆盖（</span><span>branch&nbsp;coverage</span><span>）</span><span>,&nbsp;</span><span>所有边界覆盖（</span><span>all-edges&nbsp;coverage</span><span>）</span><span>&nbsp;[Roper1994&nbsp;p.58],&nbsp;</span><span>基本路径覆盖（</span><span>basis&nbsp;path&nbsp;coverage&nbsp;</span><span>）</span><span>[Roper1994&nbsp;p.48],&nbsp;C2</span><span>覆盖</span><span>&nbsp;[Beizer1990&nbsp;p.75],&nbsp;</span><span>判定到判定路径覆盖（</span><span>decision-decision-path</span><span>或</span><span>DDP&nbsp;testing&nbsp;[Roper1994&nbsp;p.39].&nbsp;</span><span>）</span><span>"Basis&nbsp;path"&nbsp;</span><span>测试就是选择路径来达到所有的判定覆盖</span><span>.&nbsp; </span><span><br></span><span>这个度量有语句覆盖的简单性，但是没有语句覆盖的问题。</span>&nbsp;<span><br></span><span>缺点是这个度量忽略了在</span><span>BOOL</span><span>型表达式内部的</span><span>BOOL</span><span>取值。例如考虑如下的</span><span>C/C++/Java&nbsp;</span><span>代码：</span>&nbsp;<span><br></span><span>if&nbsp;(condition1&nbsp;&amp;&amp;&nbsp;(condition2&nbsp;||&nbsp;function1())) </span><span><br></span><span>&nbsp;&nbsp;&nbsp;&nbsp;statement1; </span><span><br></span><span>else </span><span><br></span><span>&nbsp;&nbsp;&nbsp;&nbsp;statement2; </span><span><br></span><span>这个度量可以完全可以不用调用</span><span>function1.&nbsp;</span><span>测试表达是为真时可以取</span><span>condition1&nbsp;</span><span>为</span><span>true&nbsp;</span><span>和</span><span>condition2&nbsp;</span><span>为</span><span>true</span><span>，测试表达是为假时可以取</span><span>condition1&nbsp;</span><span>为</span><span>false</span><span>。</span>&nbsp;<span><br></span><strong><span>2.3 </span><span>条件覆盖（</span><span>Condition&nbsp;Coverage&nbsp;</span><span>）</span><span> </span></strong><span><br></span><span>条件覆盖报告每一个子表达式的结果的</span><span>true&nbsp;</span><span>或</span><span>false&nbsp;</span><span>。</span><span>logical-and&nbsp;</span><span>和</span><span>logical-or&nbsp;</span><span>独立起来。条件覆盖独立的度量每一个子表达式</span><span>. </span><span><br></span><span>这个度量和</span><span>decision&nbsp;coverage&nbsp;</span><span>相似，但是对控制流更敏感。</span>&nbsp;<span><br></span><span>但是，完全的条件覆盖并不能保证完全的判定覆盖。例如，考虑下列的</span><span>C++/Java&nbsp;</span><span>代码。</span>&nbsp;<span><br></span><span>bool&nbsp;f(bool&nbsp;e)&nbsp;{&nbsp;return&nbsp;false;&nbsp;} </span><span><br></span><span>bool&nbsp;a[2]&nbsp;=&nbsp;{&nbsp;false,&nbsp;false&nbsp;}; </span><span><br></span><span>if&nbsp;(f(a&nbsp;&amp;&amp;&nbsp;b))&nbsp;... </span><span><br></span><span>if&nbsp;(a[int(a&nbsp;&amp;&amp;&nbsp;b)])&nbsp;... </span><span><br></span><span>if&nbsp;((a&nbsp;&amp;&amp;&nbsp;b)&nbsp;?&nbsp;false&nbsp;:&nbsp;false)&nbsp;... </span><span><br></span><span>所有三个</span><span>IF</span><span>语句不管</span><span>a</span><span>和</span><span>b</span><span>取值是什么，判定覆盖率只能达到</span><span>50</span><span>％。但是条件覆盖率却能达到</span><span>100</span><span>％。</span><span> </span><span><br></span><strong><span>2.4 </span><span>多条件覆盖（</span><span>Multiple&nbsp;Condition&nbsp;Coverage&nbsp;</span><span>）</span><span> </span></strong><span><br></span><span>多条件覆盖报告每一个可能的</span><span>BOOL</span><span>型子表达式的组合发生了。相对于条件覆盖，即通过</span><span>logical-and</span><span>和</span><span>logical-or</span><span>把子表达式独立起来相比，</span>&nbsp;<span>多条件覆盖需要的测试用例是用一个条件的逻辑操作符的真值表来确定的。</span>&nbsp;<span><br></span><span>对于</span><span>C,&nbsp;C++</span><span>和</span><span>Java</span><span>等具有</span><span>short&nbsp;circuit&nbsp;operators</span><span>的语言，多条件覆盖的益处是它需要一个彻底的测试。</span><span> </span><span><br></span><span>缺点是它可能是非常冗长乏味的来决定一个需要的测试用例的最小设置，尤其是对于非常复杂的</span><span>BOOL</span><span>型表达式。另一个缺点是，这个度量需要的测试用例对于相似的复杂性的条件却需要非常大的变化。例如，考虑如下的</span><span>C/C++/Java&nbsp;</span><span>条件：</span><span> </span><span><br></span><span>要达到完全的多条件覆盖，第一个需要</span><span>6</span><span>个测试用例，</span><span> </span><span><br></span><span>而第二个需要</span><span>11</span><span>个测试用例。</span><span> </span><span><br><br></span><span>但是两个条件却有相同的操作数和操作符。</span>&nbsp;<span><br></span><span>对于</span><span>Visual&nbsp;Basic&nbsp;</span><span>和</span><span>Pascal</span><span>等不具有</span><span>short&nbsp;circuit&nbsp;operators</span><span>的语言</span><span>,&nbsp;</span><span>多条件覆盖对于逻辑表达式是非常有效的路径覆盖，具有相同的优缺点。考虑下列的</span><span>Visual&nbsp;Basic&nbsp;</span><span>代码：</span>&nbsp;<span><br></span><span>If&nbsp;a&nbsp;And&nbsp;b&nbsp;Then </span><span><br></span><span>... </span><span><br></span><span>多条件覆盖需要四个测试用例，</span><span>a&nbsp;</span><span>和</span><span>b</span><span>分别取值</span><span>true&nbsp;</span><span>和</span><span>false.&nbsp; </span><span><br></span><span>2.5 </span><span>分支条件组合覆盖（</span><span>Condition/Decision&nbsp;Coverage&nbsp;</span><span>）</span><span> </span><span><br></span><span>分支条件组合覆盖是条件覆盖（</span><span>condition&nbsp;coverage</span><span>）和分支覆盖（</span><span>decision&nbsp;coverage</span><span>）的一个混血。</span>&nbsp;<span>它有两者的简单性但是没有两者的缺点。</span>&nbsp;<span><br></span><strong><span>2.6 </span><span>修正条件</span><span>/</span><span>判定覆盖（</span><span>Modified&nbsp;Condition/Decision&nbsp;Coverage</span><span>）</span><span> </span></strong><span><br></span><span>也被称为</span><span>MC/DC&nbsp;</span><span>和</span><span>MCDC.&nbsp; </span><span><br></span><span>这个度量需要足够的测试用例来确定每个条件能够影响到包含的判定</span><span>[Chilenski1994]</span><span>的结果。这个度量是最早是被波音公司创建被用于航空软件中</span><span>RCTA/DO-178B</span><span>。</span>&nbsp;<span><br></span><span>这个度量起初是是设计来对于无</span><span>short&nbsp;circuit&nbsp;operators</span><span>的语言。</span><span>&nbsp;short&nbsp;circuit&nbsp;logical&nbsp;operators&nbsp;</span><span>在</span><span>C,&nbsp;C++</span><span>和</span><span>Java</span><span>语言中的作用仅仅是当它们的结果能够影响到被包含的判定的评估条件。</span><span> </span><span><br></span><span>当以下的需求遇到时，需要考虑用</span><span>MCDC</span><span>覆盖：</span><span> </span><span><br></span><span>&#8226;</span>&nbsp;<span>需求</span><span>1</span><span>：</span>&nbsp;<span>每一个程序模块的入口和出口点都要考虑要至少被调用一次，每个程序的判定到所有可能的结果值要至少转换一次。</span><span> </span><span><br></span><span>&#8226;</span>&nbsp;<span>需求</span><span>2</span><span>：程序的判定被分解为通过逻辑操作符</span><span>(AND,&nbsp;OR,&nbsp;etc.)</span><span>连接为</span><span>BOOL</span><span>条件。每一个条件对于判定的结果值是独立的，或者说单条件的变化将导致判决的变化。</span><span> </span><span><br></span><span>所以，据以上的定义，以下三组数据是必须的。</span><span>(</span><span>单条件的变化将导致判决的变化</span><span>) </span><span><br></span><span>其中</span><span>T1&nbsp;&amp;&nbsp;T2,</span><span>或</span><span>T1&amp;T3</span><span>已经满足要求</span><span>1</span><span>，但要求满足条件</span><span>2</span><span>，就必须存在同时存在</span><span>T1&amp;T2&amp;T3</span><span>。</span><span> </span><span><br></span><span>T4</span><span>：（</span><span>F</span><span>，</span><span>F</span><span>），是多余的，因为一个条件改变并不能导致判决的改变。</span><span> </span><span><br></span><span>T1</span><span>（</span><span>T</span><span>，</span><span>T</span><span>）与</span><span>T2</span><span>（</span><span>T</span><span>，</span><span>F</span><span>）表明</span><span>Y</span><span>独立影响了判决，</span><span>Y</span><span>的独立对；</span><span> </span><span><br></span><span>T1</span><span>（</span><span>T</span><span>，</span><span>T</span><span>）与</span><span>T3</span><span>（</span><span>F</span><span>，</span><span>T</span><span>）表明</span><span>X</span><span>独立影响了判决，</span><span>X</span><span>的独立对。</span><span> </span><span><br></span><span>再如：</span><span> </span><span><br></span><span>测试用例</span><span>1&nbsp;(T,T,T)&nbsp;</span><span>和测试用例</span><span>5&nbsp;(F,T,T)&nbsp;,</span><span>对于</span><span>X</span><span>独立。</span>&nbsp;<span><br></span><span>测试用例</span><span>2&nbsp;(T,T,T)&nbsp;</span><span>和测试用例</span><span>6&nbsp;(F,T,T)&nbsp;,</span><span>对于</span><span>X</span><span>独立。</span>&nbsp;<span><br></span><span>测试用例</span><span>3&nbsp;(T,T,T)&nbsp;</span><span>和测试用例</span><span>7&nbsp;(F,T,T)&nbsp;,</span><span>对于</span><span>X</span><span>独立。</span>&nbsp;<span><br></span><span>测试用例</span><span>2&nbsp;(T,T,T)&nbsp;</span><span>和测试用例</span><span>4&nbsp;(F,T,T)&nbsp;,</span><span>对于</span><span>Y</span><span>独立。</span>&nbsp;<span><br></span><span>测试用例</span><span>3&nbsp;(T,T,T)&nbsp;</span><span>和测试用例</span><span>4&nbsp;(F,T,T)&nbsp;,</span><span>对于</span><span>Z</span><span>独立。</span>&nbsp;<span><br></span><span>结果，测试用例组</span><span>{1,5,2,4,3}&nbsp;</span><span>满足</span><span>MCDC</span><span>覆盖对表达式</span><span>X,&nbsp;Y</span><span>和</span><span>Z</span><span>的要求。</span><span> </span><span><br></span><span>明显，这不是唯一的组合，例如还有｛</span><span>6,2,4,3</span><span>｝。</span>&nbsp;<span><br></span><strong><span><br><st1:chsdate w:st="on" IsROCDate="False" IsLunarDate="False" Day="30" Month="12" Year="1899">2.6.1</st1:chsdate> </span><span>覆盖率的计算公式：</span><span> </span></strong><span><br></span>&nbsp;<span><br></span><span>或者：</span><span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><u>number of tests<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></u></span><span><br></span><span>&nbsp;<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>number of tests&nbsp;+ minimal nuber of test required</span><span><br><br></span><strong><span>2.7 </span><span>路径覆盖（</span><span>Path&nbsp;Coverage&nbsp;</span><span>）</span><span> </span></strong><span><br></span><span>这个度量报告是否函数的每一个可能的分支都被执行了。一个路径就是一个从函数的入口到函数的出口的唯一的系列分支。</span>&nbsp;<span><br></span><span>也称呼为断言覆盖（</span><span>predicate&nbsp;coverage</span><span>）。断言覆盖可以看出可以组合的逻辑条件的路径</span><span>[Beizer1990&nbsp;p.98]</span><span>。</span><span> </span><span><br></span><span>因为循环引入了一个很大的路径数，这个度量只考虑一个有限数量的循环可能性。有很多的变种来处理循环，内部边界路径测试（</span><span>Boundary-interior&nbsp;path&nbsp;testing</span><span>）只考虑循环的两个可能性。重复零次和多于零次的重复</span><span>[Ntafos1988]</span><span>。对于</span><span>do-while&nbsp;</span><span>循环，两种，零次反复和多于零次反复。</span>&nbsp;<span><br></span><span>路径覆盖的一个好处是：需要彻底的测试。</span><span> </span><span><br></span><span>但有两个缺点：</span><span> </span><span><br></span><span>一是，路径是以分支的指数级别增加的，例如：一个函数包含</span><span>10</span><span>个</span><span>IF</span><span>语句，就有</span><span>1024</span><span>个路径要测试。如果加入一个</span><span>IF</span><span>语句，路径数就达到</span><span>2048</span><span>。</span><span> </span><span><br></span><span>二是，许多路径不可能与执行的数据无关。例如</span>&nbsp;<span><br></span><span>if&nbsp;(success) </span><span><br></span><span>&nbsp;&nbsp;&nbsp;&nbsp;statement1; </span><span><br></span><span>statement2; </span><span><br></span><span>if&nbsp;(success) </span><span><br></span><span>&nbsp;&nbsp;&nbsp;&nbsp;statement3; </span><span><br></span><span>路径覆盖认为以上语句包含四个路径，实际上只有两个是可行的：</span><span>success=false&nbsp;</span><span>和</span><span>&nbsp;success=true.&nbsp; </span><span><br></span><span>研究者发明了很多种的路径覆盖技术来避免大数量的路径。如，</span><span>n-length&nbsp;sub-path&nbsp;coverage&nbsp;</span><span>报告你是否</span><span>exercised&nbsp;each&nbsp;path&nbsp;of&nbsp;length&nbsp;n&nbsp;branches.</span><span>其它变种包括</span><span>linear&nbsp;code&nbsp;sequence&nbsp;and&nbsp;jump&nbsp;(LCSAJ)&nbsp;coverage&nbsp;</span><span>和</span><span>data&nbsp;flow&nbsp;coverage.&nbsp; </span><span><br><br></span>
<img src ="http://www.cnitblog.com/lyfever/aggbug/39061.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cnitblog.com/lyfever/" target="_blank">三原</a> 2008-01-19 20:32 <a href="http://www.cnitblog.com/lyfever/archive/2008/01/19/39061.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>各种覆盖率方法介绍(1)</title><link>http://www.cnitblog.com/lyfever/archive/2008/01/19/39060.html</link><dc:creator>三原</dc:creator><author>三原</author><pubDate>Sat, 19 Jan 2008 12:29:00 GMT</pubDate><guid>http://www.cnitblog.com/lyfever/archive/2008/01/19/39060.html</guid><wfw:comment>http://www.cnitblog.com/lyfever/comments/39060.html</wfw:comment><comments>http://www.cnitblog.com/lyfever/archive/2008/01/19/39060.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cnitblog.com/lyfever/comments/commentRss/39060.html</wfw:commentRss><trackback:ping>http://www.cnitblog.com/lyfever/services/trackbacks/39060.html</trackback:ping><description><![CDATA[&nbsp; <strong><span>1 </span><span>简介</span></strong><span> </span><span><br></span><strong><span>1.1 </span><span>代码覆盖率分析</span><span> </span></strong><span><br></span><span>这篇文章给出了一个完整的代码覆盖率分析方面的概念。</span>&nbsp;<span><br></span><span>代码覆盖率分析是这样一个过程：</span>&nbsp;<span><br></span><span>&#183;</span><span> </span><span>找出程序经过一系列测试而没有执行的部分代码</span>&nbsp;<span><br></span><span>&#183;</span><span> </span><span>创建一个附加的测试用例来增加覆盖率</span>&nbsp;<span><br></span><span>&#183;</span><span> </span><span>决定代码覆盖的定量度量。</span>&nbsp;<span><br></span><span>代码覆盖率分析的一个有效方面是：</span>&nbsp;<span><br></span><span>&#183;</span><span> </span><span>识别出没有增加覆盖率的无效的测试用例。</span>&nbsp;<span><br></span><span>覆盖率分析需要被测试程序的源代码，并且经常需要用一个特殊的命令重新编译它。</span>&nbsp;<span><br></span><span>这篇文章讨论你应当考虑你的测试计划中应该如何增加覆盖率分析的细节问题。覆盖率分析有一定的好处和弱点。你应该选择一个测量方法的范围。你应该建立一个覆盖率要达到的最小百分比，来决定你什么时候停止覆盖率分析。覆盖率分析只是许多测试技术的一种，你不能只是依靠它。</span>&nbsp;<span><br></span><strong><span>1.2 </span><span>结构化测试和功能测试（</span><span>Structural&nbsp;testing&amp;Functional&nbsp;testing</span><span>）</span><span> </span></strong><span><br></span><span>代码覆盖率分析是一种结构化测试技术</span><span>&nbsp;(AKA&nbsp;glass&nbsp;box&nbsp;testing&nbsp;and&nbsp;white&nbsp;box&nbsp;testing).&nbsp;</span><span>结构化测试是比较被测试程序的行为和源代码的外观目的。和功能测试相比</span><span>&nbsp;(AKA&nbsp;black-box&nbsp;testing),&nbsp;</span><span>功能测试是比较被测试程序的行为和确定的需求。结构化测试检查程序的工作，考虑结构中可能存在的逻辑缺陷。功能测试检查被测试程序的完成需求的能力，不考虑它是怎么工作的。</span>&nbsp;<span><br></span><span>结构化测试也叫路径测试（</span><span>path&nbsp;testing</span><span>），</span>&nbsp;<span>因为你选择测试用例来通过程序结构的路径。不要和路径覆盖率度量（</span><span>path&nbsp;coverage</span><span>）混淆，下面会介绍。</span>&nbsp;<span><br></span><span>粗略的看，结构化测试似乎不安全，结构化测试不能发现需求疏忽的错误，但是，需求定义有时并不存在，而且并不完整。这个现象是实际存在的，当产品开发的时间线就要到的时候，当需求定义很少更新，产品自身代替了需求定义的作用的时候。</span>&nbsp;<span><br></span><strong><span>1.3 </span><span>假定</span><span> </span></strong><span><br></span><span>一些基本原理的假定如下所列：</span>&nbsp;<span><br></span><span>&#183;</span><span> Faults&nbsp;</span><span>―――和控制流相关的缺陷，你可以发现这些缺陷通过变更控制流</span><span>[Beizer1990&nbsp;p.60]</span><span>。例如，一个程序写为</span><span>"if&nbsp;(c)"&nbsp;</span><span>比</span><span>"if&nbsp;(!c)"</span><span>好</span>&nbsp;<span>。</span><span> </span><span><br></span><span>&#183;</span><span> </span><span>你可以寻找缺陷而不必知道这个缺陷可能引起的后果和所有测试的可靠性。</span>&nbsp;<span><br></span><span>&#183;</span><span> </span><span>其它的假定包括可完成需求的定义、没有疏忽的缺陷和没有不可以达到的代码等。</span>&nbsp;<span><br><br></span>
<img src ="http://www.cnitblog.com/lyfever/aggbug/39060.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cnitblog.com/lyfever/" target="_blank">三原</a> 2008-01-19 20:29 <a href="http://www.cnitblog.com/lyfever/archive/2008/01/19/39060.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>成功测试管理的九大原则(以前翻译的旧文)</title><link>http://www.cnitblog.com/lyfever/archive/2008/01/19/39058.html</link><dc:creator>三原</dc:creator><author>三原</author><pubDate>Sat, 19 Jan 2008 12:02:00 GMT</pubDate><guid>http://www.cnitblog.com/lyfever/archive/2008/01/19/39058.html</guid><wfw:comment>http://www.cnitblog.com/lyfever/comments/39058.html</wfw:comment><comments>http://www.cnitblog.com/lyfever/archive/2008/01/19/39058.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cnitblog.com/lyfever/comments/commentRss/39058.html</wfw:commentRss><trackback:ping>http://www.cnitblog.com/lyfever/services/trackbacks/39058.html</trackback:ping><description><![CDATA[简介
<p>　　许多测试管理者是从技术部门进到管理阶层的。尽管他们有可能受过很多测试或软件工程的培训和指导，但他们还是很难经常从失败和错误中学到管理技巧。作为一个管理者，你有两项基本工作：找出为你工作的最好的员工并且建立一个能够使员工完成工作的环境（使他们最好地完成工作）。这篇文章讲述了一些我学过的关于这些管理工作的经验。</p>
<p>　　总是那些人――帮助人们最好地完成工作</p>
<p>　　1． 为工作雇佣最好的员工</p>
<p>　　我遇到许多管理者，他们要雇佣的员工仅仅是他们上一个雇佣的翻版。作为一个测试管理者，你必须对你需要什么人做出评估。假设现在你的部门满是极好的探索型的测试员。如果你还要雇另一个探索型的测试员，也许比你现在的要好，但是他对你的空白领域有作用吗？也许有，也许没有。</p>
<p>　　工作的最佳人选也许就是你现在这个小组里所没有的类型。最佳人选或许并不&#8220;适合&#8221;你通常的工作方式。作为一个测试管理者，雇佣一个最佳的员工要用发展的雇佣策略，面试时要检验他是否符合这个策略。这可以让你找到最适合这份工作的人员，他能够完成必要的工作。</p>
<p>　　2.安排每周与你的每个小组成员在不被打扰的环境进行谈话</p>
<p>　　最为一个测试经理，主要工作之一就是定期的评定你的组织做了些什么并且是怎样做的。你还要为你的员工做一个报告，关于充分了解他们正在做什么和他们是怎样做的，以此来给做他们正式的和非正式的工作成绩考核。如果你没有了解到每个人的动态你就不应该对你的报告满意。</p>
<p>　　我定期地给我的小组成员每周在不被打扰的条件下做一对一的谈话。（当我管理12个员工的时候，我安排在另外一周会见另一些人）。我每周用30分钟来和每个员工谈谈他们的工作：他们工作中的问题或是意见；他们是否需要帮助，他们的表现和他们达到目标的兴奋。我一般安排一周的某天来进行一对一谈话。我事先安排出和每个人的特定时间，接下来我亲自会见他们每个人。如果我们不能把所有需要谈到的细节都包括，我们会安排另外一个时间来继续。</p>
<p>　　许多管理者说他们没有时间在一周会见每一个员工来谈他们的工作。据我的经验，如果我不能安排时间和我的员工进行每周的谈话，他们会来打扰我的工作，因为他们无论如何还是必须要来找我。</p>
<p>　　如果你安排和你员工的谈话，你必须减少计划外的打扰（既有他们的也有你自己的），并且更多的了解他们在做什么。当你清楚你的小组正在做的，你才能更有效率地帮助他们明确优先应该做的工作，重聚资源，重新计划工程的部分，排除障碍等等。 <br><span class=f14>　　3.假定员工知道如何完成他们的工作的人员<br><br>　　因为很多管理者起初做的是技术工作，他们知道他们的员工现在从事的工作。他们认为他们现在知道。如果你已经管理了两三年，你也许还没有你的技术员工知道的多，尤其是怎么样完成日常工作。<br><br>　　你或者你的前任者雇佣你小组的员工。假设你雇佣这些人因为你认为他们能够完成工作，如果你设想每个人都知道如何完成他们的工作，你将得到比假设他们都不知道怎么完成的更好的效果。即使有些员工在无论你设想是否都能成功完成工作，但是有些员工将会被你对他们的想法所影响工作。<br><br>　　因为我知道我的员工都知道怎样做他们的工作，我给他们分派任务。问他们是否需要帮助，然后留他们独自完成（除非他们寻求帮助）。我的意思并不是你不应该在他们工作的时候和他们说话，你只是不该打扰他。打扰可以分为几种不同的形式：<br><br>　　&#183; 如果你在不知不觉的情况下来到他身后，来到他的肩膀旁边，问他：&#8220;进行的如何了？&#8221;，尤其是在他们绞尽脑汁仍不得其解时, 这将仍然不能使你对他们的要求达到。。<br><br>　　&#183; 如果你每天都问，更糟的是每个钟头都问,他们是如何做的。这看起来就像对你员工进行微机管理，很惹人烦。毕竟,你没有工作要做吗？另外, 他们会以为你认为他们不知道该如何完成工作。<br><br>　　&#183; 如果当他们没有问你意见，你说&#8220;我会用这种方法&#8221;。这种予以打击的帮助不会有用。<br>.如果你不确定怎样能知道你的员工是否胜任，和每一个小组成员商讨寻求帮助的时机。每个人，包括你自己，应该选择一个规则来知道他或她什么时候成为了一个令人讨厌的家伙了。我的一个客户有一个15分钟法规。如果有人在某方面令人讨厌持续15分钟以上，他就必须停止并且和别人谈谈他的工作。<br><br>　　当你分配工作时，问问你的员工是否明白该做什么，他或她是否有方法完成。确定工作进程，如果员工遇到麻烦，他应该主动找你寻求帮助，但是如果你坚决干涉，你的员工将会把找你寻求帮助作为最后的解决方法。<br><br>　　4.对待你的员工要用他们能接受的方式,而不是你可以自己可以接受的方式&#8220;对待别人要用你愿意接受的方式&#8221;（己之不予，勿施于人）――这条黄金法则可能会对许多生活中的纯的社交因素有效，但是并不是总对工作有用。<br><br>　　有效率的管理者知道他的每一个员工需要怎样的对待方式。当其他的人更乐意接受更多的信息。一些人去需要特定的任务和指示。一些因为解决新的，很棒的，复杂的问题而更有冲劲，但是还有一些只是对他们已经知道如何去处理的问题而感到舒服。<br><br>　　另外，针对于不同的工作，我们都喜欢不同的认同方式。金钱不是表示认同的唯一方式，你可以用其他的方式来酬劳你的员工。有些人喜欢对他个人的感谢，有人乐意在公众面前的认可，一些喜欢以M﹠M方式，或者是奖励电影票，还有人希望有团队的排队来庆祝。记住无论什么的激励你的方式都不一定能激励你小组的每一个其他成员。和你的小组成员们通过讨论来了解他们每个人对奖励比较喜欢的给予方式。创造一个好的工作环境<br><br>　　5．重视结果而非时间<br><br>　　许多认可建立在员工完成工作的时间上，而不是他们最后的成绩上。但是，花费在工作上的时间不一定和创造性有必然的联系。如果你真的想改善对创作性和工作效率的认可的话，不妨考虑保证你员工每周只工作40个小时。 我常常听到一种表示对员工的异议就是&#8220;你整整一天什么都做不出来。&#8221;假设你自己处在一个巨大的障碍前，考虑你可以做什么来解决的时候，你是不是取消了会议？你的小组成员能否井然有序地安排他们的工作以至于能够最大限度发挥创造性？<br><br>　　当人们每周工作超过40个小时的时候，他们开始在工作的时候关心他们自己的事。他们花钱，他们给很久没有联系的人打电话，因为他们一直都在工作。<br><br>　　一旦你创造了一个环境，让员工在工作时间完成工作，开始鼓励他们每周不要超过40小时，接着你就可以基于他们在40个小时能够完成的工作量给他们酬劳。我总是发现这样能够提升创造力（因为员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己）。<br><br>　　当你开始注意规律，不仅仅是时间，还包括更容易地给员工的表现给予精确的适度的评价。你的员工是否完成了他们的计划和测试设计？当他们开发测试的时候，他们还要修订那些他们需要的改进的部分？（如果你只是注意有多少测试可以使用，我可以重复地开展相同的测试）计划每周工作40个小时，并且为你要在这段时间完成的工作付报酬。<br><span class=f14>　　6.承认自己的错误<br><br>　　每个人都会犯错。他们会因为忘记开会而使客户发怒。承认你犯错是令人尴尬的。我们中的许多人认为对小组承认自己犯错会失去尊严。<br><br>　　如果你不是经常犯错，你承认错误的时候其实能够赢得尊敬。如果你忘记一次会议，你为此道歉，其他的人会理解你并且最终原谅你。<br><br>　　不管你做了什么，不要否认或故意忽略你的失误。故意忽略不会让错误消失这只会让错误成长为怪物。最近，有一个委托人在会上对他的员工大声斥责。会后，他认识到他不应该那样在小组会上那样做。他只是想让他们安心工作，等过几天再道歉。<br><br>　　我建议在他们对他积累怒气之前，应该用正确的方式和他的员工交谈。他起初不愿意，但是他后来还是温和地在两天后和他的每个员工单独进行了交谈。每个人都是这样对他说的：&#8220;我只是在会后才对你感到生气的。如果您能够立即和我谈谈，我就不会把它们积累起来。但是现在已经两天过去了,我仍然对您感到生气，事实上，我还更加恼火，我现在不能确信现在是否能相信您。我不介意你对我们大吼，但是我不能确定是否还会再这样做。<br><br>　　我的客户不知道应该如何处理这种情况。他认为他的等待是正确的，但是却让问题变得更加严重。.他已经决定再也不会犯这样的错误了，而且会立刻和会员工交流。<br><br>　　他的员工用了好几个月来重新相信他，但是我的这位客户的确通过承认过错而增加了他的个人魅力。现在，他和他的员工对这件事可以当做是玩笑来说。他们说这是他的认知和能力的巨大转折点。 </span></span></p>
<p>　　7.决定承担一个项目必须首先问你的组员是否有能力完成当你是一个下级的员工，你的老板对你说&#8220;我们是否可以在下个十月完成项目？&#8221;回答说&#8220;当然&#8221;会令人惊讶。但是，你的员工会因为你回答&#8220;我要考虑一下。&#8221;而表示赞赏。<br><br>　　即使你已经在考虑这个问题，告诉了你的员工你们将来做它，你还是应该得到足够的信息来考虑。你应该从这几方面来看：<br><br>　　&#183;一段时间内，你也许会因为另一件工作而感到对这个问题迷惑。<br><br>　　&#183; 也许有你正被其它需要考虑的问题所累，因为你不再有相同的时间像你第一次看到它的时候。<br><br>　　&#183; 如果你&#8220;训练&#8221;你的上司让你的回答有漏洞，你的上司会继续给你让你回答他的压力。<br><br>　　当你与你的员工在做决定之前讨论问题时，你应该把这些和他们说一说：<br><br>　　&#183; 我想知道是什么让你想做这个项目。<br><br>　　&#183; 我不怕告诉我的上司要怎么处置它。<br><br>　　在决定做一个项目之前先好好做考虑是一种对你员工的尊重。另外，考虑他们的想法也会使你从他们那里赢得尊重和忠诚。<br><br>　　8.计划定期的培训<br><br>　　作为管理学的一部分，测试是一种挑战和对规则的经常性的改变。因为经常的改变，要制定定期的培训计划。如果你没有基于不断的变化而培训你的员工，你就会有损失。<br><br>　　培训可以是关于特定项目或者是技术。你可以进行训练用不同的方法：<br><br>　　&#183; 提供一个简单的午餐，让每个你的每个组员讨论一个特定的领域。这特别对同时要做很多不同项目的小组有用。当每个人做不同的项目，这会有助于每个人了解你小组所有的工程。<br><br>　　&#183; 做一个对每个部门的阶段说明。无论幸运与否，每个部门都会有和你小组相仿的工作，但是一般来说其它部门都不知道另外的部门在做什么。<br><br>　　&#183; 如果你们有交叉利益的小组，你可以让两个小组都展现他们各自为公司所作的项目，或者只是针对你的测试小组。<br><br>　　&#183; 邀请外面的专家来讲一个特定的技术或者一种项目。这些专家或者是专业的顾问，善演讲的人，也或是一个博学的朋友或同事。<br><br>　　&#183; 如果你买了工具或者已经进行了培训，考虑组织一个内部的&#8220;使用者&#8221;会议。人们可以在那里分享他们使用这种工具的感受并且讨论它的问题，优点和恶作剧。这特别对有缺陷的追踪系统和构造管理系统有效果。<br><br>　　9.计划测试<br><br>　　作为一个测试经理，你不可能有时间去做所有你想做的事。所以，计划你和你小组能做什么。作为测试经理，首先应该确定自己的任务，是在发布之前找到大的缺陷？还是评估软件的状态？或者是帮助开发经理在发布之前做风险评估？你的任务有可能是其中一项又或者是其中几项结合。无论是怎样，在进入的玩命工作时期之前, 对测试进行计划, 你组里的每个人都要竭尽全力你不需要做所有的事。你不是对所有事都计划而是精简，你就会有时间, 然后你就可以计算出你能再做什么。<br><br>　　测试的计划是对每个产品或是对各个开发阶段的产品开展测试的策略。测试要多严格？什么测试不用进行？你在测试里要用硬件和软件的那些组合？什么样的组合不能作为彻底的，可能的，在所有的测试里都运用到的。<br><br>　　测试是一种危险的评估。你和你项目里的其它成员能够进一步做出决定：你乐意对产品的测试部分和非测试部分冒多大的的险？<br><br>　　一旦你决定要测试什么，对每个产品发展发布标准。发布标准是对每一项发布挑剔的重要性评判的客观的标准。&#8220;如果那样将会不错&#8221;不是步伐标准。&#8220;如果不那样做客户将会置我们于死地&#8221;才是发布标准的组成部分。<br><br>　　如果你计划一个测试并和你的组员一起开展项目, 你不能一直只扮演一个守门人的角色。你无须停止准许运用.你和你的项目小组或者你和项目经理一起制定评判的标准。当你们都通过了这些标准，就可以交货了。加入你们没有达成共识 ，诚实的，决定你下一步该做什么。我所有做过的项目当中，我们都必须对发布标准达成共识,所以我们为此一直工作.一些客户提出了很苛刻的标准，我们最后也达成了共识。他们更换了文件当中的发布标准, <br><br>　　解释他们在项目小组里的位置, 并且支配管理, 最后交接工作</p>
<img src ="http://www.cnitblog.com/lyfever/aggbug/39058.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cnitblog.com/lyfever/" target="_blank">三原</a> 2008-01-19 20:02 <a href="http://www.cnitblog.com/lyfever/archive/2008/01/19/39058.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>