﻿<?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>BlogJava-xiekai-blog-随笔分类-软件测试</title><link>http://www.blogjava.net/xiekai-blog/category/33858.html</link><description>北冥有鱼，其名为鲲。鲲之大，不知其几千里也。化而为鸟，其名为鹏。鹏之背，不知其几千里也。怒而飞，其翼若垂天之云。是鸟也，海运则将徙于南冥。南冥者，天池也。
</description><language>zh-cn</language><lastBuildDate>Wed, 20 Aug 2008 00:09:54 GMT</lastBuildDate><pubDate>Wed, 20 Aug 2008 00:09:54 GMT</pubDate><ttl>60</ttl><item><title>程序中错误量的估算</title><link>http://www.blogjava.net/xiekai-blog/archive/2008/08/19/222929.html</link><dc:creator>小言身寸</dc:creator><author>小言身寸</author><pubDate>Tue, 19 Aug 2008 01:55:00 GMT</pubDate><guid>http://www.blogjava.net/xiekai-blog/archive/2008/08/19/222929.html</guid><wfw:comment>http://www.blogjava.net/xiekai-blog/comments/222929.html</wfw:comment><comments>http://www.blogjava.net/xiekai-blog/archive/2008/08/19/222929.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/xiekai-blog/comments/commentRss/222929.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/xiekai-blog/services/trackbacks/222929.html</trackback:ping><description><![CDATA[<h2><a id="AjaxHolder_ctl01_TitleUrl" href="http://www.cnblogs.com/guanhe/archive/2007/06/25/794512.html">错误植入法与老祖宗的智慧</a> </h2>
<div class="postText">
<div style="margin-left: 40px"><span style="color: #5508ff">两个小组独立地测试同一个程序，第一组发现25个错误，第二组发现30个错误，在两个小组发现的错误中有15个是共同的，那么可以估计程序中的错误总数是 ___个。</span><br style="color: #5508ff" />
<br style="color: #5508ff" />
<span style="color: #5508ff">A．25 B．30 C．50 D．60</span><br />
</div>
<br />
&nbsp;&nbsp;&nbsp; 当然，任何一个了解估算方法的朋友都可以根据公式计算出最终的结果是50个，这没有什么问题。——但是，我在这里引用这个题目，是希望我们可以把学习这件事情通过类比变得更加有趣一点。<br />
<br />
&nbsp;&nbsp;&nbsp; 其实，如何估算一个系统中存在的缺陷数，我们的老祖宗早就有现成的方法了。不信，请看我在我们老祖宗的数学专著中找到的一个实践问题：&#8220;有一口鱼塘，不知道其中有多少条鱼，如何才能估算出池塘中鱼的数量？&#8221;（当然，原文不是这样，请原谅我一下子找不到出处，只好凭记忆用我的语言描述一下了）。我们老祖宗给出的答案是这样的：<br />
<br />
<ol>
    <li style="color: #5508ff">首先，从鱼塘中打捞出一些鱼（假设数量为m）；
    <li style="color: #5508ff">将这些鱼做上记号，然后将其放回鱼塘；
    <li style="color: #5508ff">等待一段时间，等到鱼均匀分布在鱼塘中了之后，再次打捞上来一些鱼（假设数量为n）；
    <li style="color: #5508ff">统计第二次打捞上来的鱼中的带记号者（假设数量为p）；
    <li><span style="color: #5508ff">计算得出鱼塘中鱼的数量为 S = m / (p/n) </span></li>
</ol>
<br />
&nbsp;&nbsp;&nbsp; 对这个答案最简单的理解是：<span style="font-weight: bold">假设第一次做了记号的鱼在鱼塘中是均匀分布的，第二次打捞上来的n条鱼中有p条是有记号的，则说明有记号的鱼的分布密度是p/n，鱼塘中一共有m条有记号的鱼，当然总的鱼数量就是 S = m / (p/n)了</span>。<br />
<br />
&nbsp;&nbsp;&nbsp; 再回到我们的原始问题，很容易做一个类比，第一个小组发现了25个缺陷（相当于第一次打捞的鱼m），第二个小组发现了30个缺陷（相当于第二次打捞上来的鱼n），两者相同的是15个（相当于是p），所以答案是 50。<br />
<br />
&nbsp;&nbsp;&nbsp; 所以，从现在开始，不要再认为这个方法是什么深奥的方法——看看，我们的老祖宗都能熟练运用呢<img src="http://www.cnblogs.com/CuteSoft_Client/CuteEditor/images/emsmile.gif" align="absMiddle" border="0"  alt="" /><br />
<br />
&nbsp;&nbsp;&nbsp; 本来，到这里就可以告一段落了，可是我们能不能再深入点思考这个问题呢？<br />
<br />
&nbsp;&nbsp;&nbsp; 这种方法显然是可以得到一个估算结果，但这种方法在哪些情况下不合适，使用时有什么注意事项没有呢？<br />
<br />
&nbsp;&nbsp;&nbsp; 还是回过头看我们养鱼的例子，很显然，我们讨论的前提是&#8220;做记号的鱼在池塘中分布均匀&#8221;，如果这个条件不满足，我们的估算结果显然是有很大的偏差的。就鱼塘来说，不同类型的鱼由于喜欢的食物种类不同，喜欢分布在不同的层次，这样一来的话，在打捞的时候就要注意，如果只侧重在某一个水层，显然结果是有很大的偏差的，另外，由于鱼塘边上的温度相对较低，夏天鱼更加喜欢在鱼塘边休息&#8230;&#8230;，可见，要达到&#8220;平均&#8221;这样的条件还是有难度的&#8230;&#8230; —— 等等，我们讨论了这么久的鱼，和我们的缺陷有什么关系呢？<br />
<br />
&nbsp;&nbsp;&nbsp; 别忘了，缺陷在系统中的分布和鱼在鱼塘中的分布可是有异曲同工之妙的哦<img src="http://www.cnblogs.com/CuteSoft_Client/CuteEditor/images/emwink.gif" align="absMiddle" border="0"  alt="" />。缺陷有不同的类型（功能缺陷，性能缺陷，安全性缺陷&#8230;&#8230;），分布在不同的模块，由于模块设计和实现人员的水平的差异，模块自身复杂度的差异等，不同模块中的缺陷分布显然是不同的，一个系统中，由于测试的测试不同，不同类型缺陷的发现效率也是不同的&#8230;&#8230;——再看看，这和我们的鱼塘是不是一回事？<br />
<br />
&nbsp;&nbsp;&nbsp; 关于鱼塘和缺陷的故事，如果我们要深究下去，还会发现他们的很多共同点，当然，你也可以提出各种方法来修正我们这个简单的模型——但这不是我们的重点。<span style="font-weight: bold">我要说的重点是：无论如何，在这条路上的思考是不是会比简单的背公式更有趣一些呢？<br />
<br />
</span><span style="font-weight: bold">&nbsp;&nbsp;&nbsp;&nbsp; </span>经常有测试工程师问到，应该怎样才有最高的学习效率呢？<br />
<br />
&nbsp;&nbsp;&nbsp; 我的回答是：<span style="font-weight: bold">学习、思考是乐趣，不是负担。我们学习是为了追求它自身的乐趣——获得知识的乐趣，在自己头脑中天马行空的乐趣，发现的乐趣，以及分享的乐趣。<br />
</span></div>
<img src ="http://www.blogjava.net/xiekai-blog/aggbug/222929.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/xiekai-blog/" target="_blank">小言身寸</a> 2008-08-19 09:55 <a href="http://www.blogjava.net/xiekai-blog/archive/2008/08/19/222929.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>微软的测试方法</title><link>http://www.blogjava.net/xiekai-blog/archive/2008/08/18/222794.html</link><dc:creator>小言身寸</dc:creator><author>小言身寸</author><pubDate>Mon, 18 Aug 2008 07:52:00 GMT</pubDate><guid>http://www.blogjava.net/xiekai-blog/archive/2008/08/18/222794.html</guid><wfw:comment>http://www.blogjava.net/xiekai-blog/comments/222794.html</wfw:comment><comments>http://www.blogjava.net/xiekai-blog/archive/2008/08/18/222794.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/xiekai-blog/comments/commentRss/222794.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/xiekai-blog/services/trackbacks/222794.html</trackback:ping><description><![CDATA[<p>要点：<br />
<br />
<strong>两类经典的软件测试方法</strong><br />
第一类测试方法是试图验证软件是&#8220;工作的&#8221;，所谓&#8220;工作的&#8221;就是指软件的功能是按照预先的设计执行的；<br />
第二类测试方法则是设法证明软件是&#8220;不工作的&#8221;。<br />
<br />
<strong>两类方法的优劣对比<br />
</strong>很明显这两类测试方法在具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很大的差别，并各有利弊的。<br />
第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。<br />
第二类测试方法与需求和设计没有必然的关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。<br />
第一类测试方法的缺点是缺乏灵活性，不利于测试人员主观能动性的发挥，不容易找到软件的错误（Bug）。而这方面正是第二类测试方法的长处。<br />
<br />
<strong>微软的策略</strong><br />
正是因为认识到两类测试方法各有利弊，微软在软件测试活动中将两类方法结合起来，以第一类测试方法为基础和主要线索，阶段性地运用第二类测试方法。<br />
<br />
<strong>微软的第一类测试</strong><br />
微软的第一类测试总体上说分为三个步骤进行：审核需求和设计—〉设计测试—〉实施运行测试。<br />
需求和设计本身也有正确性的问题。依据不正确的需求和设计不可能开发出正确的软件产品，测试也将是徒劳的。因此验证需求和设计是微软进行第一类测试的第一步。<br />
同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。<br />
从测试的过程来看，总是先运行或执行简单用例，然后再复杂用例；先验证单一的基本功能，再综合的端到端的功能；先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。<br />
为了防止质量回归有很多测试用例是要反复运行的。<br />
<br />
<strong>微软的第二类测试</strong><br />
微软的第二类测试是阶段性的，常常根据需要而带有随机性和突击性。对于这类测试，在微软有一个专门的名称：&#8220;Bug Bash（Bug大扫除）&#8221;。 <br />
Bug Bash通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。<br />
这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：<br />
（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；<br />
（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；<br />
（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。<br />
（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。</p>
通常Bug Bash会产生超乎寻常数量的Bug。<br />
一般我们认为，产生Bug的量越大越好。因为，如果产生Bug的数量少，你很难判断是因为产品的质量确实很高，还是Bug Bash做得不彻底。而且事实往往是后者。<br />
但同时会造成收敛的缺陷趋势出现严重的发散现象。<br />
<br />
那么对Bug Bash所产生的大量Bug该怎么办？<br />
在微软，有&#8220;Bug Triage （测试，开发和项目管理，三方会审）&#8221;的制度。<br />
对于每个Bug，经过会审后不外乎有以下三中归宿（总体上来说）： <br />
（1）被确认为&#8220;缺陷性&#8221;Bug，这样的Bug必须交开发人员解决，然后由原发现人验证。<br />
（2）被调整为非&#8220;缺陷性&#8221;Bug，不用开发人员作任何更改，但必须将问题纳入产品用户文档，明确向用户解释，并告诉用户如何避免和应对。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 考虑到，一方面这种情况在用户实际使用产品时发生的机率很低，而另一方面，从开发角度，解决这个问题有很大的技术难度，影响面也太大。这种情况下会把这个Bug改为&#8220;文本性&#8221;Bug，也就是要求文本编写人员将这一情况作一技术性解释。这类的Bug在Bug Bash中很常见，因为大家在这种测试活动中思维方式比较超常。 <br />
（3）被完全否定，立刻关闭，不再纠缠。<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 这类的情况在Bug Bash中也很常见。因为参与Bug Bash人并不都很了解产品功能的准确用法，误报是难免的。尽管对这类问题没有直接的后续措施，但这些信息仍然是有一定价值的，因为将来用户中的新手很可能会犯同样的毛病，而产品支持部门如果预先有这样的经验，就能及时准确地提供帮助。所以这些信息要保存在Bug的管理库中，以备将来产品支持部门查询。<br />
经过这样的会审，筛选，如果（1）（2）类Bug，特别是（1）类Bug仍然很多，那测试部门很可能需要重新论证原先的测试计划和测试用例设计，看是否需要增加测试用例。必要时还要尽早提出更改项目总体计划和发布日期。 大量Bug的出现也许不是件愉快的事，但和把这些Bug留给用户相比，代价要小得太多了。<br />
<br />
<strong>一些基本的事实<br />
</strong>微软的测试人员和开发人员数量大致相等或略多<br />
微软的产品成本中测试大约占40%以上<br />
<br />
<strong>历史回顾</strong>&nbsp;<br />
软件开发历史四个阶段：<br />
<u>第一个阶段</u>是60年代及其以前，那时软件规模都很小、复杂程度低，软件开发的过程随意。开发人员的Debug过程被认为是唯一的测试活动。其实这并不是现代意义上的软件测试，当然一阶段也还没有专门测试人员的出现。<br />
<u>第二个阶段</u>是70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考开发流程问题，并提出&#8220;软件工程Software Engineering&#8221;的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻，而且测试活动仅出现在整个软件开发流程的后期，虽然测试由专门的测试人员来承担，但测试人员都是行业和软件专业的入门新手。 <br />
<u>第三个阶段</u>是80年代及其以后，软件和IT行业进入了大发展。软件趋向大型化。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。<br />
<u>第四个阶段</u>是90年代以后，软件的规模和复杂程度迅速提高，测试与开发流程的融合也迅速走向更深层次，具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开发的实践证明，不仅软件的质量控制依赖于测试，开发本身离开测试也将无法推进，项目管理离开了测试也从根本上失去了依据。在微软，测试的确有这样的地位和作用。这就是为什么微软在软件测试上有如此大的投入。<br />
<br />
在微软，产品开发团队（主要包括开发、测试和项目管理）一般都有百人以上规模，有些产品甚至上几千人（Windows2000的开发部门曾有3000多人）。这样大规模的人力资源作用在一个动态的，内部相互联系的系统中，若没有有效的协同，其混乱是不可避免的。试想，有两个开发人员，分别在开发两个不同的功能模块，其相互有依赖关系。为了相互协调，他们可以随时进行当面讨论。如果这种关系发生在五个开发人员和五个功能模块之间，这种协调就只能通过定期的会议来进行。而一个大型项目，会有许许多多这样的关系，而且很多时候这种关系有着不确定性和不可预见性。<span style="color: red">当一个开发人员编写一段新的代码或对已有代码进行改动和调整时，他（或她）常常无法确定，或无法完全确定究竟有哪些相关的模块会受到影响，以及在什么请况下这种影响会带来什么结果。因为系统的复杂性已远远超出了人的逻辑思维、技能和经验所能力及的范畴。</span>因此这种传统的协调手段是远不能满足需要的。 <br />
在微软，这种协调是<span style="color: red">通过测试来实现</span>的。具体来说就是：<span style="color: red">每日建造+自动化测试</span>。<br />
关于每日编译和自动化测试，这里简单的说就是每天都建造一个新版本，每个版本都要运行通过一定量的自动测试用例，以检验当天工作的质量。<br />
全面的自动测试，到早晨上班时间之前就会把结果自动通过e-mail等方式发送出来。开发人员上班后的第一件事往往就是检查测试结果。如果没有问题就会开始新的工作。如果有测试有用例没有通过，开发人员则必须协同测试人员一起立刻找出原因，解决后才能开始新的代码。有时一个小的失误会引起大面积的测试用例失败，很大一部分开发团队会受到影响。为尽量避免这种情况，要求开发人员在存入代码之前先在自己的个人建造版本上运行一定量的自动测试，全部通过后在存入。如开发人员没有按照这样的要求，而擅自存入质量不高的代码而造成大量测试失败，这种不负责任的行为是要受到严厉批评的。 <br />
从这一过程可以看出，开发人员依赖测试来保证开发工作的质量，使开发整体地协调地向前推进。<br />
<br />
开发对测试的这种依赖性对测试和测是人员提出了更高的要求。<br />
在理念上，软件测试已远不仅仅只是软件功能的验证和Bug的搜寻；<br />
在具体方法上，自动测试和测试工具的使用已成为基本的要求。<br />
<br />
一个软件企业要提高其软件开发的能力，特别是针对大型软件的大规模的快速开发能力，在测试方面对传统理念和方法进行突破是必要的。<br />
<br />
<hr />
<br />
原文全文：<font style="background-color: #cfe4d2"><a href="http://www.51testing.com/?157364/action_viewspace_itemid_90429.html">http://www.51testing.com/?157364/action_viewspace_itemid_90429.html</a></font><br />
<img src ="http://www.blogjava.net/xiekai-blog/aggbug/222794.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/xiekai-blog/" target="_blank">小言身寸</a> 2008-08-18 15:52 <a href="http://www.blogjava.net/xiekai-blog/archive/2008/08/18/222794.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>