<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>进化的测试 &#187; defect</title>
	<atom:link href="http://magustest.com/blog/tag/defect/feed/" rel="self" type="application/rss+xml" />
	<link>http://magustest.com/blog</link>
	<description>软件测试，自动化测试，白盒测试，Python</description>
	<lastBuildDate>Wed, 04 Jan 2012 09:09:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
		<item>
		<title>《Software Testing》第一章 &#8211; 软件测试的背景</title>
		<link>http://magustest.com/blog/readingdaily/software-testing-note-part-one/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=software-testing-note-part-one</link>
		<comments>http://magustest.com/blog/readingdaily/software-testing-note-part-one/#comments</comments>
		<pubDate>Sun, 12 Aug 2007 08:29:53 +0000</pubDate>
		<dc:creator>magus</dc:creator>
				<category><![CDATA[读书笔记]]></category>
		<category><![CDATA[defect]]></category>

		<guid isPermaLink="false">http://magustest.com/blog/?p=11</guid>
		<description><![CDATA[这个读书笔记系列是我在上学实习的时候写的，现在要把它从51TESTING搬过来，顺便梳理一下。 从事软件测试的同学获取曾经都遇到过这样一个问题：应该怎么称呼BUG呢？一个专业的定义是：Software Failure，但是还会有很多各种各样的称呼，例如： Defect（很多美国公司都是用这个，例如Reynolds, SPSS, MySpace.com） Fault（过错、毛病之类，听起来比上面的严重） Problem（问题） Error（错误，看起来好像挺严重的） Incident（事件，这个词看着很温和，没那么激进） Anomaly（异常，非正常） Variance（不一致，这个也很“客观”啊） Failure（失灵~故障，听起来也是很吓人的） Inconsistency（矛盾！个人认为比较客观的说法） Feature（特征，） Bug（最后一个，也是最常用的就是这个，MySpace.cn一般都这样叫） 每个公司都有自己的叫法，之所以有那么多叫法根据猪蹄说的原因就是~要估计程序员的感受，不要搞的DEV和QA好像是对立面似的。在埃森哲叫SIR，不是先生的意思，而是System Investigation Report。其实叫啥不重要，就像人的名字，一个符号而已。 现在来探讨一下一个BUG的定义是什么，书上如是说：BUG的定义就是： 1.the software doesn&#8217;t do something that the product specification says it should do. 举例：如果spec上说，只要填好必填的项目，然后按“注册”就能注册成功，但是实际发现不行，注册不了 2.the software does something that the product specification says it shouldn&#8217;t do. 举例：如果spec上说，只要填好必填的项目，然后按“注册”就能注册成功，实际发现没填完必填的项目也能成功注册 3.the software does something that the product specification <a href='http://magustest.com/blog/readingdaily/software-testing-note-part-one/'>[...]</a>
Related posts:<ol>
<li><a href='http://magustest.com/blog/readingdaily/software-testing-note-part-three/' rel='bookmark' title='《Software Testing》第三章 &#8211; 软件测试'>《Software Testing》第三章 &#8211; 软件测试</a></li>
<li><a href='http://magustest.com/blog/readingdaily/software-testing-note-part-twenty-one/' rel='bookmark' title='《Software Testing》第二十一章 &#8211; 软件质量保证'>《Software Testing》第二十一章 &#8211; 软件质量保证</a></li>
<li><a href='http://magustest.com/blog/readingdaily/software-testing-note-part-seventeen/' rel='bookmark' title='《Software Testing》第十七章 &#8211; 计划你的测试'>《Software Testing》第十七章 &#8211; 计划你的测试</a></li>
</ol>]]></description>
			<content:encoded><![CDATA[<p>这个读书笔记系列是我在上学实习的时候写的，现在要把它从51TESTING搬过来，顺便梳理一下。</p>
<p>从事软件测试的同学获取曾经都遇到过这样一个问题：应该怎么称呼BUG呢？一个专业的定义是：Software Failure，但是还会有很多各种各样的称呼，例如：</p>
<ul>
<li>Defect（很多美国公司都是用这个，例如Reynolds, SPSS, MySpace.com）</li>
<li>Fault（过错、毛病之类，听起来比上面的严重）</li>
<li>Problem（问题）</li>
<li>Error（错误，看起来好像挺严重的）</li>
<li>Incident（事件，这个词看着很温和，没那么激进）</li>
<li>Anomaly（异常，非正常）</li>
<li>Variance（不一致，这个也很“客观”啊）</li>
<li>Failure（失灵~故障，听起来也是很吓人的）</li>
<li>Inconsistency（矛盾！个人认为比较客观的说法）</li>
<li>Feature（特征，）</li>
<li>Bug（最后一个，也是最常用的就是这个，MySpace.cn一般都这样叫）</li>
</ul>
<p>每个公司都有自己的叫法，之所以有那么多叫法根据猪蹄说的原因就是~要估计程序员的感受，不要搞的DEV和QA好像是对立面似的。在埃森哲叫SIR，不是先生的意思，而是System Investigation Report。其实叫啥不重要，就像人的名字，一个符号而已。<br />
 <span id="more-11"></span><br />
 现在来探讨一下一个BUG的定义是什么，书上如是说：BUG的定义就是：</p>
<p><strong>1.the software doesn&#8217;t do something that the product specification says it should do.</strong></p>
<p>举例：如果spec上说，只要填好必填的项目，然后按“注册”就能注册成功，但是实际发现不行，注册不了</p>
<p><strong>2.the software does something that the product specification says it shouldn&#8217;t do.</strong></p>
<p>举例：如果spec上说，只要填好必填的项目，然后按“注册”就能注册成功，实际发现没填完必填的项目也能成功注册<strong></strong></p>
<p><strong>3.the software does something that the product specification doesn’t mention.</strong></p>
<p>举例：如果一个网络游戏的spec上没有提及该游戏提供实时语言聊天功能，但是游戏release以后发现多了这个功能，那么这就是一个bug。因为实现的feature越多，把bug带进软件的机会就越大</p>
<p><strong>4.the software doesn&#8217;t do something that the product specification doesn&#8217;t mention but should.</strong></p>
<p>举例：例如一个充电器spec上没有说这个充电器在电池满电的时候会自动断电保护，但是这个自动断电保护的功能是应该有，如果不是大家都被XX电池炸死了。</p>
<p><strong>5.the software is difficult to understand ,hard to use ,slow ,or-in the software tester&#8217;s eyes-will be viewed by the end user as just plain not right.</strong></p>
<p>这个就不举例了，不过我个人觉得这个很难去厘定，什么是难用，什么是慢，其实这一条也增加了一些不可测性<br />
 有了上面的定义现在可以讨论一个问题。如果现在有这样的一个BUG，他在产品的整个开发周期里面都没有被发现，最终release了出去，但是很幸运地客户也没发现这个BUG，那么这个BUG能叫一个BUG么？</p>
<p>这个讨论一定是个很有意思的讨论，嘿嘿，大家可以在什么Seminar上拿出来研究研究。我个人认为，如果根据以上对BUG的定义，那么他就是一个BUG，至于有人会争辩说：这不是一个BUG，都没有人发现他，没有对任何人或者机构造成任何的IMPACT，不过书上有这样的一句话：</p>
<p><strong>If a tree falls in the forest and there is nobody around, does it make a sound?</strong></p>
<p>呵呵，不过这个也就是茶余饭后讨论着玩的问题吧，DEV和QA有一大堆问题需要处理，对这个“未知”的BUG，何必那么较真。</p>
<p>是什么原因导致BUG的出现呢？如果去做一个调查，那么读者可以发现，大多数都BUG都不是由于编程的错误而引起的，更多的BUG是因为设计的错误，需求的不清楚而导致的。同时，越早发现一个BUG，修复的成本就越低。例如如果发现一个需求文档上的BUG，修复它的成本只是改一下文档；如果到了发布以后才发现，那么代价将会是相当大。因此，及早测试，持续测试，能对产品的质量带来更多的保障。</p>
<p>说了那么久，那一个测试工程师究竟是干啥的？</p>
<p><strong>The goal of a software tester is to find bugs.</strong><br />
 <strong>The goal of a software tester is to find bugs and find them as early as possible.</strong><br />
 <strong>The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed.</strong></p>
<p>这里的定义其实是一个Tester的定义，其实作为一个测试工程师，可以做的事情还有很多。</p>
<p>Related posts:<ol>
<li><a href='http://magustest.com/blog/readingdaily/software-testing-note-part-three/' rel='bookmark' title='《Software Testing》第三章 &#8211; 软件测试'>《Software Testing》第三章 &#8211; 软件测试</a></li>
<li><a href='http://magustest.com/blog/readingdaily/software-testing-note-part-twenty-one/' rel='bookmark' title='《Software Testing》第二十一章 &#8211; 软件质量保证'>《Software Testing》第二十一章 &#8211; 软件质量保证</a></li>
<li><a href='http://magustest.com/blog/readingdaily/software-testing-note-part-seventeen/' rel='bookmark' title='《Software Testing》第十七章 &#8211; 计划你的测试'>《Software Testing》第十七章 &#8211; 计划你的测试</a></li>
</ol></p>]]></content:encoded>
			<wfw:commentRss>http://magustest.com/blog/readingdaily/software-testing-note-part-one/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

