﻿<?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>C++博客-君子性非异也，善假于物也。-文章分类-软件测试初探</title><link>http://www.cppblog.com/xushaohua/category/2318.html</link><description>如有恒，何须三更起，半夜眠；最怕莫，三天打鱼两天晒网，竹篮打水一场空！</description><language>zh-cn</language><lastBuildDate>Sun, 25 May 2008 16:23:58 GMT</lastBuildDate><pubDate>Sun, 25 May 2008 16:23:58 GMT</pubDate><ttl>60</ttl><item><title>How To Write Better Bug Reports</title><link>http://www.cppblog.com/xushaohua/articles/14587.html</link><dc:creator>shaohua</dc:creator><author>shaohua</author><pubDate>Thu, 02 Nov 2006 15:00:00 GMT</pubDate><guid>http://www.cppblog.com/xushaohua/articles/14587.html</guid><wfw:comment>http://www.cppblog.com/xushaohua/comments/14587.html</wfw:comment><comments>http://www.cppblog.com/xushaohua/articles/14587.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cppblog.com/xushaohua/comments/commentRss/14587.html</wfw:commentRss><trackback:ping>http://www.cppblog.com/xushaohua/services/trackbacks/14587.html</trackback:ping><description><![CDATA[我们是否经常看到开发人员针对我们归档的bug report要求提供更多的信息？我们是否经常需要在bug report归档后花更多的时间去研究那个问题？我们是否经常从开发人员那里听到在他们那边难以重现bug并且需要即刻提供“可重现的步骤”？广义上来说，我们与其花更多的时间在这些问题上还不如投资更多的时间来测试系统。问题出在bug report的质量上。这里介绍一些如何改进并达到完美bug report的建议。<br /><br /> <br /><br />Bug report的目的<br /><br />当我们发现一个缺陷时，我们需要把它告诉给开发人员。Bug report就是这种沟通的媒介物。Bug report的主要目的是让开发人员亲眼看到这个错误。如果你不能和他一起以在他面前制造出那个失败，那么就需要给他们足够多的指引以便他们能够自己制造出那个失败。Bug report就是解释在期望结果和实际结果之间的差距并且详细的说明如何重现那个场景。<br /><br /> <br /><br />在发现缺陷之后<br /><br />·         只有当你确信你已经发现一个bug的时候开始起草bug report，不要在测试结束或每天结束之后。那样，你可能会遗忘掉一些东西。更糟的情况是，我们可能会忘掉那个bug。<br /><br />·         花一些时间去诊断你正在报告的缺陷。想想可能存在的原因。可能到最后你会发现更多的缺陷。在你的bug report中说说你的发现。开发人员将不仅仅对你使他们的工作变得轻松而感到高兴。<br /><br />·         在开始读你的bug report之前抽出一些时间来。你可能会感觉到象重新编写报告一样。<br /><br /> <br /><br />摘要<br /><br />Bug report的摘要是你bug report给读者的第一印象。你提交的bug的命运很大程度依赖于你的bug report能否吸引读者。原则就是每个bug应该有一个简单有趣的摘要。它可能会听上去象编写一个优秀的勾起注意的广告活动。但是随后，没有什么意外。一个好的摘要应该不超过50到60个字符。而且一个好的摘要不应该承载任何对bug主观的表达。<br /><br /> <br /><br />语言<br /><br />·         不要在bug report中夸大缺陷。同样，也不要太轻描淡写了。<br /><br />·         不管bug是多么的令人讨厌，别忘了是bug令人讨厌，而不是开发人员。永远不要冒犯开发人员的努力。使用委婉些的说法。“混乱的UI”可以被温和些改为“不正确的UI”。这样开发人员的努力将会得到尊重。<br /><br />·         保持简单诚实。你不是在写散文或文章，因此使用简单的语言<br /><br />·         在编写bug report的时候记住你的目标读者。他们可能是开发人员，其他的测试人员，经理，或者在一些情况下，甚至是客户。Bug report应该可以被所有的人理解。<br /><br /> <br /><br />可重现的步骤<br /><br />·         “可重现的步骤”的流程应该是合乎逻辑的。<br /><br />·         清楚的列出前提条件<br /><br />·         写下平常的步骤。例如，如果一个步骤要求用户创建文件并且为它命名，不要要求用户命名为“Mihir’s file”。最好命名为好像“Test File”一样的文件名。<br /><br />·         “可重现的步骤”应该详尽。例如，如果你想用户在Microsoft Word里保存一个文件，你可以要求用户到File菜单并且点击Save子菜单项。你也可以只说“保存文件”。但是记住，并不是所有的人都知道如何在Microsoft Word中保存文件。因此最后遵守第一种方法。<br /><br />·         在一个干净的系统里测试你的“可重现的步骤”。你可能会发现有些步骤被遗漏或是毫无关系的。<br /><br /> <br /><br />测试数据<br /><br />尽力编写普通的bug report，开发人员可能没有权限访问你的测试数据。如果bug是和一组特定的测试数据相关，在你的bug report上附带上它。<br /><br /> <br /><br />截屏<br /><br />截屏是bug report中一个十分必要的部分。一个图片胜过一千句话。但是不要把在每个bug report里附带没有必要的截屏变成一个习惯。理想的来说，你的bug report应该是足够有效的使开发人员重现问题。截屏应该只是验证的一种方法。<br /><br />·         如果你要在bug report里附带截屏，要确保那些图片不是太大的，使用jpg或gif的格式，而不是bmp格式<br /><br />·         在截屏上写上注释以指出问题所在。这将帮助开发人员一眼就可以马上定位问题。<br /><br /> <br /><br />严重程序/优先级别<br /><br />·         在设置bug report的严重程序之前应该全面的分析缺陷的影响程序。如果你认为你的bug具有很高的优先级应该被修复，在bug report中证明这点。应该在bug report的描述部分指出这个理由。<br /><br />·         如果bug是来自上个内部小版本或版本回归的结果，那么发出警报。象这种bug的严重程序可能是低的，但是优先级别应该是高。<br /><br /> <br /><br />日志<br /><br />在bug report里附上日志或日志的摘录片断。这将帮助开发人员轻松地分析且调试系统。多数情况下，如果不附上日志而且在开发人员那边又很难重现问题的话，他们将会把bug report打回给你并要求附带日志文件。<br /><br />如果日志文件不太大的话，举个例子，大约20到25行，你就可以把它贴在bug report里。但是如果它比较大的话，把它做为附件贴在bug report里，否则你的bug report会看上去象个日志。 <br /><br /> <br /><br />其他信息<br /><br />·         如果你的bug是随机出现的，只需在你的bug report中说一下就可以了。但是不要忘记归档它。你总是能够在你发现它们之后的任何时间里增加准确的步骤。这也将在其他人提交这个问题时解救你，特别是当那个问题比较严重时。<br /><br />·         在bug report中写下错误信息，特别是当错误信息有编号的时候。例如，来自数据库中的错误信息。 <br /><br />·         在bug report中写下版本编号和内部小版本编号 <br /><br />·         写下问题可以被重现的平台。准确的说明问题不可重现的平台。同样也要理解问题在特定平台上不可重现和没有在某个平台上测试之间的分别。这个可能会造成混淆。 <br /><br />·         如果你遇到几个问题却有一样的结果，只需写一个bug report。问题的修复可能只是一个。同样，如果你在不同的地方遇到相似的问题，且要求同一种修复方法,但是在不同的地方，那么就要为每一个问题书写单独的bug report。每个bug report对应一个修复。 <br /><br />·         如果可以重现bug的测试环境是开发人员可以访问的，写下访问这种设置的详情。这将帮助他们节约安装环境的时间以重现你提交的bug。 <br /><br />·         你决不能坚持关于bug的任何信息。在bug被修复之前由于低效的提交bug而引起的开发人员和测试人员之间不必要的交互只是浪费时间。<br /><img src ="http://www.cppblog.com/xushaohua/aggbug/14587.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cppblog.com/xushaohua/" target="_blank">shaohua</a> 2006-11-02 23:00 <a href="http://www.cppblog.com/xushaohua/articles/14587.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>编写有效的bug report</title><link>http://www.cppblog.com/xushaohua/articles/14586.html</link><dc:creator>shaohua</dc:creator><author>shaohua</author><pubDate>Thu, 02 Nov 2006 14:59:00 GMT</pubDate><guid>http://www.cppblog.com/xushaohua/articles/14586.html</guid><wfw:comment>http://www.cppblog.com/xushaohua/comments/14586.html</wfw:comment><comments>http://www.cppblog.com/xushaohua/articles/14586.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cppblog.com/xushaohua/comments/commentRss/14586.html</wfw:commentRss><trackback:ping>http://www.cppblog.com/xushaohua/services/trackbacks/14586.html</trackback:ping><description><![CDATA[你有没有为了要更多的信息而被返回bug report的经历呢？有没有碰到过你发现的一个非常严重的错误被推迟到下一个版本才去修复的情况呢？<br /> <br />      你提交的每一个bug report都是和项目组就正在测试中的软件质量问题的一种书面沟通方式。通常，你用于沟通程序错误的能力－不是体现在错误本身的内在严重程度－而是体现在确定这个错误是否需要修复。<br />       如果这是一个可怕的想法，你可能会想，“等等！我讨厌写作，我并不擅长写作。怎么样才能够通过编写bug report来决定错误的命运呢？”它要吸引大家相信错误是为他们说话的－任何一个头脑正常的人都应该主动地查看一个特定的错误是足够可怕的以致要被修复。不幸的是，事实并不是这样。<br />       但是好消息是：有效的和软件开发人员、项目组沟通的能力不是由你在高校英语课程中的表现所决定的。<br />       这不是关于用有趣的词语编写流畅散文，也不是关于优秀语法和拼写的方法。它是有关仅用能够表达你观点的词语明白地表述错误的方法。太多地话将会使你的观点陷入茫然无措中。太少地话又会使他人用自己的假设去填补隔阂－通常是对软件有害的部分。如果你不是很确信是什么样的错误，那么不管你的bug report写得怎么好，也没有人知道那是什么样的错误。<br />       这篇文章主要讨论你现在能够开始着手提高人们倾听你发现的错误的机会的4个方法。<br />了解你的听众<br />       毋庸置疑，任何写作课都会告诉你必须了解你是为谁编写bug report。<br />       每份bug report至少有两个听众：必须要修复错误的人和决定错误命运的人或团体。有时一个人会同时负责这两份工作，但是仍然是两个不同的听众，只是一起发生在同一个人身上罢了。<br />       你的第一个听众－那个必须修复错误的人需要清楚，明确的步骤以重现错误。信息越多越好。针对这个目的，我们称这个人为“开发人员”。开发人员需要关于我们操作了什么和我们看见了什么的准确信息。<br />       你的第二个听众－决定错误命运的人或团体需要知道如果不修复此错误的后果。这个听众需要精练的语句以抓住他们的注意力并且引发对错误的相关连问题的讨论。基于这个目的，我们称他为“错误审核委员会”。在使错误得以修复的过程中你的角色是帮助错误审核委员会了解不修复错误的风险远远超过修复错误可能发生的风险。<br />       你越了解你的开发人员和错误审核委员会如何工作，你就越可以根据他们的需要裁减你的bug report。尽力在私底下设法了解你的听众。如果你能够出席错误审核委员会会议，尝试这样做。你将学习到许多关于你的听众是如何思考的知识。<br />选择一个好的标题<br />      一般把用于描述错误的短句称为错误的标题或描述。这是bug report中最重要的部分。错误审核委员会成员经常通过它来决定错误是否可以推迟修复。如果标题没有力度，委员会成员可能认为它是不值得花费太多的时间。（毕竟，在接下来的2个小时里还有145个以上的错误要审核。）<br />       以下是一些示例：<br />好的：超时后在退出时崩溃了<br />太长的：在数据库不可用后你又保存记录的更改,然后从文件菜单中选择退出时程序崩溃了<br />不足够的信息：程序崩溃了<br />太模糊：当数据库离线时出现问题<br />标题变成了一种给项目组提供检查和调查错误的方法。和数据相比，人们更容易记词语。人们更愿意记得“在windows2000下不能够安装”的错误，而不是类似“＃23423”错误，而且在以后人们还会利用这些关键词搜索错误。<br />      编写一个好的，简明的错误标题是不容易的。和编写bug report的其他部分相比，应该多花些时间构造理想的错误标题。要确信标题是足够短以便能够在显示错误的屏幕上和由缺陷跟踪系统生成的报表中显示完全（不会折行）。标题不必是完美的语法，而应简短并一针见血。<br />书写清楚，明确的步骤<br />       你提交给开发人员的步骤应该提供如何产生错误的信息，这样错误就能够被发现并且修复。它也需要给错误审核委员会提供错误发生的环境。<br />唯一正确：<br />1．  运行客户端<br />2．  找出一个记录<br />3．  更改记录但不存盘<br />4．  使数据库服务器脱机<br />5．  尝试保存记录<br />6．  收到一个超时的错误<br />7．  退出客户端<br />结果：崩溃<br />马虎的（有很大空间让人产生误解的）：<br />使数据库服务器脱机，保存，然后退出，崩溃了。<br />太多冗余的信息（不能够指出什么是引发错误的最关键原因）<br />1．  运行客户端<br />2．  为输入新的条目查询数据库<br />3．  打开一个浏览器<br />4．  在yahoo.com上浏览新闻<br />5．  关闭浏览器<br />6．  选择一个条目<br />7．  把种类从“蔬菜” 更改到“水果”<br />8．  使数据库服务器脱机<br />9．  尝试保存记录<br />10．                       收到一个超时的错误<br />11．                       退出客户端<br />结果：崩溃<br />在这个例子中，测试人员记录在发现错误之前他所作的一切，但是他没有检查是不是每个步骤都是必要的，例如从yahoo.com阅读新闻。<br />如果你只写下那些产生错误必不可少的步骤，开发人员将很少告诉你他们不能够重现错误，同样错误什么委员会也会很少决定“没有人将会做到那个程度！”<br />但是如果每个步骤都是必须的，怎么办呢？如果错误只在你执行了一些看上去没有关系的步骤后出现了，那么在bug report中记录下这些步骤。你可以在那些看上去没有逻辑关系的步骤后写上“必须的步骤”，或者你可以在bug report的开始部分加上注释：“注意－这里的每一个步骤都是重现错误的必要步骤。<br />编写清晰的步骤同样可以在验证修复过程中提供帮助，特别是在另一个测试人员做验证的时候。<br />解释错误的影响，不只是症状<br />一些bug report是令人误解的。从错误的表层看是无伤大雅的，但是如果在你检查错误的牵连时，你发现它是一个非常严重的问题。如果你在错误审核委员会，你会拥护先修改哪一个错误呢？<br />1．  关于“一个令人讨厌的对话框阻止关闭应用程序”的报告<br />2．  关于“在退出时应用程序中止了” 的报告<br />这两个是同一个错误。差异完全在于测试人员如何编写bug report。<br />在此提到的“令人讨厌的对话框”是指Windows操作系统中显示不能退出进程的窗口（“这个Windows应用程序不能响应结束任务的请求。。。”）。测试人员在试图关闭机器而不是退出应用程序时发现这个问题。应用程序没有等待来自用户的输入，因此退出失败是没有原因的。实际上，这个症状指出了更深的问题－在第一个关于“令人讨厌的对话框”的bug report被推迟修复时几乎要遗漏的问题。<br />这个 “令人讨厌的对话框”的bug report存在着两个问题。首先，它不精确。如果测试人员在步骤中包括了“令人讨厌的对话框”中的文字，决策者可以认识到对话框是一个严重的问题而不是一个微小的干扰。第二，这份报告没有指出错误的其他隐藏的问题：应用程序被中止了。<br />结论<br />我们都想把自己的工作变得与众不同。我们想知道是因为我们努力的工作而使得软件的最终版本更好。我们用来沟通错误的能力在我们是否有尽我们希望多地影响软件的最终版本中是决定因素。<br />因此当你编写bug report时，记住你的听众，选择一个好的标题，清楚的记录步骤并解释错误的影响。你的bug report将会因为你花在它上面的格外努力而更好，并且有更多的错误被修复。最终将达到我们期望的结果－使错误在伤害用户之前得到修复。<img src ="http://www.cppblog.com/xushaohua/aggbug/14586.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cppblog.com/xushaohua/" target="_blank">shaohua</a> 2006-11-02 22:59 <a href="http://www.cppblog.com/xushaohua/articles/14586.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>软件产品测试标准</title><link>http://www.cppblog.com/xushaohua/articles/14585.html</link><dc:creator>shaohua</dc:creator><author>shaohua</author><pubDate>Thu, 02 Nov 2006 14:58:00 GMT</pubDate><guid>http://www.cppblog.com/xushaohua/articles/14585.html</guid><wfw:comment>http://www.cppblog.com/xushaohua/comments/14585.html</wfw:comment><comments>http://www.cppblog.com/xushaohua/articles/14585.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cppblog.com/xushaohua/comments/commentRss/14585.html</wfw:commentRss><trackback:ping>http://www.cppblog.com/xushaohua/services/trackbacks/14585.html</trackback:ping><description><![CDATA[国际标准<br />?  ISO/IEC 17025 General requirements for the competency of testing and calibration laboratories <br />?  ISO/IEC 14598 Software Engineering-Product Evaluation <br />?  ISO/IEC 9126 Information technology-Software product evaluation- Quality characteristics and guidelines for their use <br />?  ISO/IEC 12119 Information technology - Software packages - Quality requirements and testing <br />?  Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software <br />?  Software engineering - Product evaluation - Part 6: Documentation of evaluation modules <br />?  Software engineering - Product evaluation - Part 3: Process for developers <br />?  Information technology; guidelines for the management of software documentation <br />?  Software engineering - Product evaluation - Part 2: Planning and management <br />?  Dependability management - Part 3: Application guide - Section 6: Software aspects of dependability <br />?  Software dependability through the software life-cycle processes - Application guide <br />?  ANSI/NAPM IT 7.228-1997 Electronic Projection-Fixed Resolution Projectors <br /> <br />国家标准 <br />?  GB/T 17544 软件包质量要求和测试 <br />?  GB/T 16260 信息技术软件产品评价质量特 性及其使用指南 <br />?  GB/T 18031-2000 信息技术数字键盘汉字输入通用要求 <br />?  制造业企业资源计划 (ERP) 系统功能结构技术规范 <br />?  质量管理和质量保证标准 第三部分 :GB/T 19001-ISO 9001 在软件开发、供应和维护中的使用指南 <br />?  信息技术 系统及软件完整性级别 <br />?  软件工程 产品评价 第 1 部分：概述 <br />?  软件工程 产品评价 第 2 部分：策划和管理 <br />?  软件工程 产品评价 第 3 部分：开发者用的过程 <br />?  软件工程 产品评价 第 4 部分：需方用的过程 <br />?  软件工程 产品评价 第 5 部分：评价者用的过程 <br />?  软件工程 产品评价 第 6 部分：评价模块的文档编制 <br />?  工业控制用软件评定准则 <br />?  计算机软件测试文件编制规范 <br />?  计算机软件质量保证计划规范 <br />?  计算机软件配置管理计划规范 <br />?  计算机软件单元测试 <br />?  信息技术 软件产品评价 质量特性及其使用指南 <br />?  计算机软件可靠性和可维护性 <br />?  GB 9813-2000 微型计算机通用规范 <br />?  GB 17859-1999 计算机信息系统安全保护等级划分准则 <br />?  GB/T 18231-2000 信息技术 低层安全模型 <br />?  GB/T 18336.1-2001 信息技术安全性评估准则第 1 部分：简介和一般模型 <br />?  GB/T 18336.2-2001 信息技术安全性评估准则第 2 部分：安全功能要求 <br />?  GB/T 18336.3-2001 信息技术安全性评估准则第 1 部分：安全保证要求 <br />?  GB/T 4943-2001 信息技术设备的安全 <br />?  GB/T 15278-94 数据加密物理层互操作性要求 <br />?  GB/T 18020-1999 信息技术应用级防火墙安全技术要求 <br />?  GB/T 17900-1999 网络代理服务器的安全技术要求 <br />?  GB/T 18019-1999 包过滤防火墙安全技术要求 <br />?  GB/T 18020-1999 应用级防火墙安全技术要求 <br /> <br />行业标准 <br />?  制造业信息化工程 应用软件产品 测评规范 第一部分 : 基本原则 <br />?  制造业信息化工程 应用软件产品测评规范 第二部分：三维 CAD 软件评测指标 <br />?  制造业信息化工程 应用软件产品测评规范 第三部分： ERP 软件测评指标 <br />?  计算机信息系统安全等级保护数据库管理系统技术要求 <br />?  计算机信息系统安全等级保护操作系统技术要求 <br />?  计算机信息系统安全等级保护管理要求 <br />?  GA/T 387-2002 计算机信息系统安全等级保护网络技术要求 <br />?  GA/T 390-2002 计算机信息系统安全等级保护通用技术要求 <br />?  GA 163-1997 计算机信息系统安全专用产品分类原则 <br />?  GA 174-1998 基于 DOS 的信息安全产品评级准则 <br />?  GA 216.1-1999 计算机信息系统安全产品部件第 1 部分：安全功能检测 <br /> <br />企业标准 <br />?  BZ01CSTC 软件产品测试与评估通用规范 <br />?  BZ02CSTC 应用软件产品测试规范 <br />?  BZ03CSTC 软件产品测试评分标准 <br />?  BZ04CSTC 办公自动化软件产品测试规范 <br />?  BZ05CSTC 商务处理软件产品测试规范 <br />?  BZ06CSTC 软件产品 2000 年符合性测试规范 <br />?  BZ07CSTC 软件产品登记测试评分标准 <br />?  BZ08CSTC 软件产品登记测试规范 <br />?  国产数据库管理系统评测大纲 <br />?  打印机测试规范 <br />?  扫描仪测试规范 <br />?  显示器测试规范 <br />?  硬盘测试规范 <br />?  投影机测试规范 <br />?  台式 PC 测试规范 <br />?  笔记本测试规范 <br />?  显示卡测试规范 <br />?  服务器测试规范 <br />?  交换机测试规范 <br />?  防火墙测试规范 <br /><img src ="http://www.cppblog.com/xushaohua/aggbug/14585.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cppblog.com/xushaohua/" target="_blank">shaohua</a> 2006-11-02 22:58 <a href="http://www.cppblog.com/xushaohua/articles/14585.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>[转]如何成为优秀的软件测试工程师</title><link>http://www.cppblog.com/xushaohua/articles/14571.html</link><dc:creator>shaohua</dc:creator><author>shaohua</author><pubDate>Thu, 02 Nov 2006 04:40:00 GMT</pubDate><guid>http://www.cppblog.com/xushaohua/articles/14571.html</guid><wfw:comment>http://www.cppblog.com/xushaohua/comments/14571.html</wfw:comment><comments>http://www.cppblog.com/xushaohua/articles/14571.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cppblog.com/xushaohua/comments/commentRss/14571.html</wfw:commentRss><trackback:ping>http://www.cppblog.com/xushaohua/services/trackbacks/14571.html</trackback:ping><description><![CDATA[ 现在软件测试工作越来越收到企业的重视，许多人员也投入到软件测试的行列中来，软件<a class="bluekey" href="http://www.yesky.com/key/202/525202.html" target="_blank">测试工程师</a>的队伍越来越壮大。但是如何成为一名优秀的软件测试工程师呢？这是大家比较关注的一个问题，尤其是初入这个行当的莱鸟更想了解这个问题的答案。本文根据自己多年来在IT公司从事软件测试的经验总结了一些东西给大家共享，同时也希望大家提出宝贵的意见和建议。 <br /><br /><strong><strong>　</strong>  起码有三年以上的软件开发经验 </strong><p class="main"><strong>　</strong>  现在许多软件企业招收一些刚刚毕业的大学生或者非计算机专业的人员作为自己公司软件测试工程师，这是非常错误的，也是对软件测试不负责任的表现。虽然他们可以发现软件中的一些错误，但是对于软件中的一些关键，致命，危险的错误他们是很难发现的。大家都知道，软件工程中有个模型叫瀑布模型，这是最基本的软件模型，这个模型又叫碗状模型，因为开发位于碗的最底部，左上方依次为建模，需求分析，设计；右上方依次为测试，部署，维护。这就是说明软件开发是一切软件活动的基础，同时也是软件测试的基础。一个人只有经历过一定年限的软件开发工作，才可以积累丰富的经验，知道在软件中哪些地方容易出错而那些地方不容易，这给以后的软件测试工作带来非常宝贵的经验。 <br /><br /><strong><strong>　</strong>  有逆向思维的能力 </strong></p><p class="main"><strong>　</strong>  我曾经接触过一些软件测试工程师，他们干了一段时间软件测试工作后返回去又开始去做开发工作了，问他们为啥？答案是软件测试工作太难了，开发是顺向思维，而测试是逆向思维，老要找一些稀奇古怪的思路去操作软件。软件的使用者千差万别，软件在使用过程中遇到的各种现象也是千差万别的，所以要求软件测试工程师需要具有一些逆向思维的能力，想别人所不想，测别人所不测，这样才可以找到更多的软件中的错误。这是作为一名优秀的软件测试工程师最基本的素质。 <br /><br /><strong><strong>　</strong>  善于同<a class="bluekey" href="http://www.yesky.com/key/1598/286598.html" target="_blank">软件开发人员</a>沟通 </strong></p><p class="main">沟<strong>　</strong>  通是当今软件项目中需要掌握的最关键技术之一。软件测试人员要善于同软件开发人员沟通，软件测试人员与开发人员搞好关系，使测试人员不成为开发人员的眼中钉，这对于提高整个软件项目质量是十分重要的。沟通主要包括： <br /><br /><strong>　</strong>  讨论软件的需求，设计：<br /><strong>　</strong>  通过这样的沟通，你可以更好的了解所测试的软件系统，以至于尽可能少的测试出软件中不是错误的“错误”，从而降低给软件开发人员带来的压力。 <br /><strong>　</strong>  报告好的测试结果：<br /><strong>　</strong>  作为一个测试人员，发现错误往往是测试人员最愿意而且引以自豪的结果，但是一味地给开发人员报告软件错误，会给他们造成厌恶感，降低整个软件的质量和开发进度。所以作为一名软件测试工程师，当你测试的模块没有严重的错误或者错误很少的时候，你不妨跑到开发人员那里告诉他们这个好消息，这会给你带来意想不到的结果。 <br /><strong>　</strong>  讨论一些与工作无关的事情：<br /><strong>　</strong>  作为一个测试人员经常和开发人员讨论一些与工作无关的事情，比如大家可以谈谈新闻，趣事，家庭…这样可以加强相互间的默契程度，许多<a class="bluekey" href="http://www.yesky.com/key/4791/409791.html" target="_blank">统计表</a>明，这样可以更好的提高软件工作质量。 <br /><br /><strong><strong>　</strong>  善于同领导沟通 </strong></p><p class="main"><strong>　</strong>  测试人员往往是领导的眼和耳，领导根据测试人员的测试结果可以了解公司的产品质量，从而调整其他的工作。领导工作一般比较繁忙，所以作为一名优秀的测试人员要学会把测试结果进行总结，最好以图表的形势给领导看。<br /><br /><strong><strong>　</strong>  掌握一些自动化测试工具 </strong></p><p class="main"><strong>　</strong>  测试工作往往是比较繁琐，枯燥无味的工作，测试人员长期处于重复的手工工作，会降低测试效率，并且对于测试质量也往往是不利的；况且许多测试不使用测试工具是不可以进行的，比如性能测试，<a class="bluekey" href="http://www.yesky.com/key/1485/461485.html" target="_blank">压力测试</a>等等。目前市场上有许多测试工具供你使用，你可以根据自己的需要选择一些测试工具来辅助你的测试。但是要记住一点，不是说有了测试工具就不要人工测试了，测试工具不是万能的。 <br /><br /><strong><strong>　</strong>  善于学习的能力 </strong></p><p class="main"><strong>　</strong>  <a class="bluekey" href="http://www.yesky.com/key/2469/297469.html" target="_blank">软件测试技术</a>随着时间的变化也在做一些提高和改进，作为一名优秀的测试人员要善于利用书籍，网站，论坛，交流等各种途径不断提高自己的软件测试水平。 <br /><strong><strong>　</strong>  提高自己的表达能力 </strong></p><p class="main"><strong>　</strong>  软件测试人员当发现软件中存在缺陷的时候，往往要书写缺陷报告，缺陷报告要写得详尽清楚，使开发人员能够尽快定位错误，修改错误，所以作为一名优秀的测试人员提高自己的写作能力是非常必要的。<br /><br /><strong><strong>　</strong>  了解业务知识 </strong></p><p><span class="main"><strong>　</strong>  更好的了解你说测试软件的业务知识是非常重要的，对业务知识了解得越深入，越能够找出更深入，更关键，更隐蔽的软件错误。所以作为一名优秀的软件测试工程师，要多向该领域专家，同行学习，提高自己的业务知识水平。 <br /><strong>　</strong>  以上仅为个人的一些经验所谈，希望大家都能够成为一名优秀的软件测试工程师。</span></p><img src ="http://www.cppblog.com/xushaohua/aggbug/14571.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cppblog.com/xushaohua/" target="_blank">shaohua</a> 2006-11-02 12:40 <a href="http://www.cppblog.com/xushaohua/articles/14571.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>黑白盒的测试原理以及内容</title><link>http://www.cppblog.com/xushaohua/articles/10664.html</link><dc:creator>shaohua</dc:creator><author>shaohua</author><pubDate>Fri, 28 Jul 2006 14:16:00 GMT</pubDate><guid>http://www.cppblog.com/xushaohua/articles/10664.html</guid><wfw:comment>http://www.cppblog.com/xushaohua/comments/10664.html</wfw:comment><comments>http://www.cppblog.com/xushaohua/articles/10664.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cppblog.com/xushaohua/comments/commentRss/10664.html</wfw:commentRss><trackback:ping>http://www.cppblog.com/xushaohua/services/trackbacks/10664.html</trackback:ping><description><![CDATA[
		<p>黑白盒测试原理 <br /> <br />黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试地，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。 <br />黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身有问题或规格说明的规定有误，用墨盒测试方法是发现不了的。</p>
		<p>黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。</p>
		<p>功能不正确或遗漏； <br />界面错误； <br />数据库访问错误； <br />性能错误； <br />初始化和终止错误等。 <br />从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有佥的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。</p>
		<p>等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。</p>
		<p>边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。</p>
		<p>错误推测设计方法就是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。</p>
		<p>因果图方法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为判定表。</p>
		<p>正交试验设计法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。 </p>
		<p>白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。</p>
		<p>这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。</p>
		<p>采用什么方法对软件进行测试呢？常用的软件测试方法有两大类：静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试；而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。</p>
<img src ="http://www.cppblog.com/xushaohua/aggbug/10664.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cppblog.com/xushaohua/" target="_blank">shaohua</a> 2006-07-28 22:16 <a href="http://www.cppblog.com/xushaohua/articles/10664.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>