Bug report的目?br />
当我们发C个缺hQ我们需要把它告诉给开发h员。Bug report是q种沟通的媒介物。Bug report的主要目的是让开发h员亲眼看到这个错误。如果你不能和他一起以在他面前刉出那个p|Q那么就需要给他们_多的指引以便他们能够自己刉出那个p|。Bug report是解释在期望结果和实际l果之间的差距ƈ且详l的说明如何重现那个场景?br />
在发现缺陷之?br />
· 只有当你信你已l发C个bug的时候开始v草bug reportQ不要在试l束或每天结束之后。那P你可能会遗忘掉一些东ѝ更p的情况是，我们可能会忘掉那个bug?br />
· ׃些时间去诊断你正在报告的~陷。想惛_能存在的原因。可能到最后你会发现更多的~陷。在你的bug report中说说你的发现。开发h员将不仅仅对你他们的工作变得轻松而感到高兴?br />
· 在开始读你的bug report之前抽出一些时间来。你可能会感觉到象重新编写报告一栗?br />
摘要
Bug report的摘要是你bug reportl读者的W一印象。你提交的bug的命q很大程度依赖于你的bug report能否吸引读者。原则就是每个bug应该有一个简单有的摘要。它可能会听上去象编写一个优U的勾h意的q告zd。但是随后，没有什么意外。一个好的摘要应该不过50?0个字W。而且一个好的摘要不应该承蝲M对bug主观的表达?br />
语言
· 不要在bug report中夸大缺陗同P也不要太L淡写了?br />
· 不管bug是多么的令h讨厌Q别忘了是bug令h讨厌Q而不是开发h员。永q不要冒犯开发h员的努力。用委婉些的说法。“qUI”可以被温和些改为“不正确的UI”。这样开发h员的努力会得到重?br />
· 保持单诚实。你不是在写散文或文章，因此使用单的语言
· 在编写bug report的时候记住你的目标读者。他们可能是开发h员，其他的测试h员，l理Q或者在一些情况下Q甚x客户。Bug report应该可以被所有的人理解?br />
可重现的步骤
· “可重现的步骤”的程应该是合乎逻辑的?br />
· 清楚的列出前提条?br />
· 写下q_的步骤。例如，如果一个步骤要求用户创建文件ƈ且ؓ它命名，不要要求用户命名为“Mihir’s file”。最好命名ؓ好像“Test File”一L文g名?br />
· “可重现的步骤”应该详。例如，如果你想用户在Microsoft Word里保存一个文Ӟ你可以要求用户到File菜单q且点击Save子菜单项。你也可以只说“保存文件”。但是记住，q不是所有的人都知道如何在Microsoft Word中保存文件。因此最后遵守第一U方法?br />
· 在一个干净的系l里试你的“可重现的步骤”。你可能会发现有些步骤被遗漏或是毫无关系的?br />
试数据
力~写普通的bug reportQ开发h员可能没有权限访问你的测试数据。如果bug是和一l特定的试数据相关Q在你的bug report上附带上它?br />
截屏
截屏是bug report中一个十分必要的部分。一个图片胜q一千句话。但是不要把在每个bug report里附带没有必要的截屏变成一个习惯。理想的来说Q你的bug report应该是够有效的使开发h员重现问题。截屏应该只是验证的一U方法?br />
· 如果你要在bug report里附带截屏，要确保那些图片不是太大的Q用jpg或gif的格式，而不是bmp格式
· 在截屏上写上注释以指出问题所在。这帮助开发h员一眼就可以马上定位问题?br />
严重E序/优先U别
· 在设|bug report的严重程序之前应该全面的分析~陷的媄响程序。如果你认ؓ你的bugh很高的优先应该被修复，在bug report中证明这炏V应该在bug report的描q部分指个理由?br />
· 如果bug是来自上个内部小版本或版本回归的l果Q那么发报。象q种bug的严重程序可能是低的Q但是优先别应该是高?br />
日志
在bug report里附上日志或日志的摘录片断。这帮助开发h员轻村֜分析且调试系l。多数情况下Q如果不附上日志而且在开发h员那边又很难重现问题的话Q他们将会把bug report打回l你q要求附带日志文件?br />
如果日志文g不太大的话，举个例子Q大U?0?5行，你就可以把它贴在bug report里。但是如果它比较大的话，把它做ؓ附g贴在bug report里，否则你的bug report会看上去象个日志?
其他信息
· 如果你的bug是随机出现的Q只需在你的bug report中说一下就可以了。但是不要忘记归档它。你L能够在你发现它们之后的Q何时间里增加准确的步骤。这也将在其他h提交q个问题时解救你Q特别是当那个问题比较严重时?br />
· 在bug report中写下错误信息，特别是当错误信息有编L时候。例如，来自数据库中的错误信息?
· 在bug report中写下版本编号和内部版本编?
· 写下问题可以被重现的q_。准的说明问题不可重现的^台。同样也要理解问题在特定q_上不可重现和没有在某个^C试之间的分别。这个可能会造成h?
· 如果你遇到几个问题却有一Ll果Q只需写一个bug report。问题的修复可能只是一个。同P如果你在不同的地斚w到相似的问题Q且要求同一U修复方?但是在不同的地方Q那么就要ؓ每一个问题书写单独的bug report。每个bug report对应一个修复?
· 如果可以重现bug的测试环境是开发h员可以访问的Q写下访问这U设|的详情。这帮助他们节U安装环境的旉以重C提交的bug?
· 你决不能坚持关于bug的Q何信息。在bug被修复之前由于低效的提交bug而引L开发h员和试人员之间不必要的交互只是费旉?br />
]]>
你提交的每一个bug report都是和项目组正在测试中的Y件质量问题的一U书面沟通方式。通常Q你用于沟通程序错误的能力Q不是体现在错误本n的内在严重程度－而是体现在确定这个错误是否需要修复?br /> 如果q是一个可怕的xQ你可能会想Q“等{！我讨厌写作，我ƈ不擅长写作。怎么h能够通过~写bug report来决定错误的命运呢？”它要吸引大家相信错误是Z们说话的QQ何一个头脑正常的人都应该d地查看一个特定的错误是够可怕的以致要被修复。不q的是，事实q不是这栗?br /> 但是好消息是Q有效的和Y件开发h员、项目组沟通的能力不是׃在高校英语课E中的表现所军_的?br /> q不是关于用有趣的词语编写流畅散文，也不是关于优U语法和拼写的Ҏ。它是有关仅用能够表达你观点的词语明白地表述错误的方法。太多地话将会你的观点陷入茫然无措中。太地话又会他h用自q假设d补隔阂－通常是对软g有害的部分。如果你不是很确信是什么样的错误，那么不管你的bug report写得怎么好，也没有h知道那是什么样的错误?br /> q篇文章主要讨论你现在能够开始着手提高h们們你发现的错误的机会的4个方法?br />了解你的听众
毋庸|疑QQ何写作课都会告诉你必M解你是ؓ谁编写bug report?br /> 每䆾bug report臛_有两个听众：必须要修复错误的人和军_错误命运的h或团体。有时一个h会同时负责这两䆾工作Q但是仍然是两个不同的听众，只是一起发生在同一个hw上|了?br /> 你的W一个听众－那个必须修复错误的h需要清楚，明确的步骤以重现错误。信息越多越好。针对这个目的，我们U这个h为“开发h员”。开发h员需要关于我们操作了什么和我们看见了什么的准确信息?br /> 你的W二个听众－军_错误命运的h或团体需要知道如果不修复此错误的后果。这个听众需要精l的语句以抓住他们的注意力ƈ且引发对错误的相兌问题的讨论。基于这个目的，我们UC为“错误审核委员会”。在佉K误得以修复的q程中你的角色是帮助错误审核委员会了解不修复错误的风险远q超q修复错误可能发生的风险?br /> 你越了解你的开发h员和错误审核委员会如何工作，你就可以根据他们的需要裁减你的bug report。尽力在U底下设法了解你的听众。如果你能够出席错误审核委员会会议，试q样做。你学习到许多关于你的听众是如何思考的知识?br />选择一个好的标?br /> 一般把用于描述错误的短句称为错误的标题或描q。这是bug report中最重要的部分。错误审核委员会成员l常通过它来军_错误是否可以推迟修复。如果标题没有力度，委员会成员可能认为它是不值得p太多的时间。（毕竟Q在接下来的2个小旉q有145个以上的错误要审核。）
以下是一些示例：
好的Q超时后在退出时崩溃?br />太长的：在数据库不可用后你又保存记录的更?然后从文件菜单中选择退出时E序崩溃?br />不够的信息Q程序崩溃了
太模p：当数据库ȝ时出现问?br />标题变成了一U给目l提供检查和调查错误的方法。和数据相比Qh们更Ҏ记词语。h们更愿意记得“在windows2000下不能够安装”的错误Q而不是类似“＃23423”错误，而且在以后h们还会利用这些关键词搜烦错误?br /> ~写一个好的，明的错误标题是不Ҏ的。和~写bug report的其他部分相比，应该多花些时间构造理想的错误标题。要信标题是够短以便能够在显C错误的屏幕上和q陯t系l生成的报表中显C完全（不会折行Q。标题不必是完美的语法，而应短ƈ一针见血?br />书写清楚Q明的步骤
你提交给开发h员的步骤应该提供如何产生错误的信息，q样错误p够被发现q且修复。它也需要给错误审核委员会提供错误发生的环境?br />唯一正确Q?br />1Q?q行客户?br />2Q?扑և一个记?br />3Q?更改记录但不存盘
4Q?使数据库服务器脱?br />5Q?试保存记录
6Q?收到一个超时的错误
7Q?退出客L
l果Q崩?br />马虎的（有很大空间让Z生误解的Q：
使数据库服务器脱机，保存Q然后退出，崩溃了?br />太多冗余的信息（不能够指Z么是引发错误的最关键原因Q?br />1Q?q行客户?br />2Q?入新的条目查询数据库
3Q?打开一个浏览器
4Q?在yahoo.com上浏览新?br />5Q?关闭览?br />6Q?选择一个条?br />7Q?把种cM“蔬菜?更改到“水果?br />8Q?使数据库服务器脱?br />9Q?试保存记录
10Q ?收到一个超时的错误
11Q ?退出客L
l果Q崩?br />在这个例子中Q测试h员记录在发现错误之前他所作的一切，但是他没有检查是不是每个步骤都是必要的，例如从yahoo.com阅读新闻?br />如果你只写下那些产生错误必不可少的步骤，开发h员将很少告诉你他们不能够重现错误Q同样错误什么委员会也会很少军_“没有h会做到那个E度Q?br />但是如果每个步骤都是必须的，怎么办呢Q如果错误只在你执行了一些看上去没有关系的步骤后出现了，那么在bug report中记录下q些步骤。你可以在那些看上去没有逻辑关系的步骤后写上“必ȝ步骤”，或者你可以在bug report的开始部分加上注释：“注意－q里的每一个步骤都是重现错误的必要步骤?br />~写清晰的步骤同样可以在验证修复q程中提供帮助，特别是在另一个测试h员做验证的时候?br />解释错误的媄响，不只是症?br />一些bug report是o解的。从错误的表层看是无伤大雅的Q但是如果在你检查错误的牵连Ӟ你发现它是一个非怸重的问题。如果你在错误审核委员会Q你会拥护先修改哪一个错误呢Q?br />1Q?关于“一个o厌的对话框阻止关闭应用程序”的报告
2Q?关于“在退出时应用E序中止了?的报?br />q两个是同一个错误。差异完全在于测试h员如何编写bug report?br />在此提到的“o厌的对话框”是指Windows操作pȝ中显CZ能退E的H口Q“这个Windows应用E序不能响应l束d的请求。。。”）。测试h员在试图关闭机器而不是退出应用程序时发现q个问题。应用程序没有等待来自用L输入Q因此退出失败是没有原因的。实际上Q这个症状指Z更深的问题－在第一个关于“o厌的对话框”的bug report被推q修复时几乎要遗漏的问题?br />q个 “o厌的对话框”的bug report存在着两个问题。首先，它不_。如果测试h员在步骤中包括了“o厌的对话框”中的文字，决策者可以认识到对话框是一个严重的问题而不是一个微的q扰。第二，q䆾报告没有指出错误的其他隐藏的问题Q应用程序被中止了?br />l论
我们都想把自q工作变得与众不同。我们想知道是因为我们努力的工作而得Y件的最l版本更好。我们用来沟通错误的能力在我们是否有我们希望多地媄响Y件的最l版本中是决定因素?br />因此当你~写bug reportӞC你的听众Q选择一个好的标题，清楚的记录步骤ƈ解释错误的媄响。你的bug report会因ؓ你花在它上面的格外努力而更好，q且有更多的错误被修复。最l将辑ֈ我们期望的结果－佉K误在伤害用户之前得到修复?img src ="http://www.shnenglu.com/xushaohua/aggbug/14586.html" width = "1" height = "1" />
]]>
? ISO/IEC 14598 Software Engineering-Product Evaluation
? ISO/IEC 9126 Information technology-Software product evaluation- Quality characteristics and guidelines for their use
? ISO/IEC 12119 Information technology - Software packages - Quality requirements and testing
? 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
? Software engineering - Product evaluation - Part 6: Documentation of evaluation modules
? Software engineering - Product evaluation - Part 3: Process for developers
? Information technology; guidelines for the management of software documentation
? Software engineering - Product evaluation - Part 2: Planning and management
? Dependability management - Part 3: Application guide - Section 6: Software aspects of dependability
? Software dependability through the software life-cycle processes - Application guide
? ANSI/NAPM IT 7.228-1997 Electronic Projection-Fixed Resolution Projectors
国家标准
? GB/T 17544 软g包质量要求和试
? GB/T 16260 信息技术Y件品评仯量特 性及其用指?
? GB/T 18031-2000 信息技术数字键盘汉字输入通用要求
? 刉业企业资源计划 (ERP) pȝ功能l构技术规?
? 质量理和质量保证标?W三部分 :GB/T 19001-ISO 9001 在Y件开发、供应和l护中的使用指南
? 信息技?pȝ及Y件完整性?
? 软g工程 产品评h W?1 部分Q概q?
? 软g工程 产品评h W?2 部分Q策划和理
? 软g工程 产品评h W?3 部分Q开发者用的过E?
? 软g工程 产品评h W?4 部分Q需方用的过E?
? 软g工程 产品评h W?5 部分Q评仯用的过E?
? 软g工程 产品评h W?6 部分Q评h块的文档~制
? 工业控制用Y件评定准?
? 计算Y件测试文件编制规?
? 计算Y件质量保证计划规?
? 计算Y仉|管理计划规?
? 计算Y件单元测?
? 信息技?软g产品评h 质量Ҏ及其用指?
? 计算Y件可靠性和可维护?
? GB 9813-2000 微型计算机通用规范
? GB 17859-1999 计算Z息系l安全保护等U划分准?
? GB/T 18231-2000 信息技?低层安全模型
? GB/T 18336.1-2001 信息技术安全性评估准则第 1 部分Q简介和一般模?
? GB/T 18336.2-2001 信息技术安全性评估准则第 2 部分Q安全功能要?
? GB/T 18336.3-2001 信息技术安全性评估准则第 1 部分Q安全保证要?
? GB/T 4943-2001 信息技术设备的安全
? GB/T 15278-94 数据加密物理层互操作性要?
? GB/T 18020-1999 信息技术应用防火墙安全技术要?
? GB/T 17900-1999 |络代理服务器的安全技术要?
? GB/T 18019-1999 包过滤防火墙安全技术要?
? GB/T 18020-1999 应用U防火墙安全技术要?
行业标准
? 刉业信息化工E?应用软g产品 评规范 W一部分 : 基本原则
? 刉业信息化工E?应用软g产品评规范 W二部分Q三l?CAD 软g评测指标
? 刉业信息化工E?应用软g产品评规范 W三部分Q?ERP 软g评指标
? 计算Z息系l安全等U保护数据库理pȝ技术要?
? 计算Z息系l安全等U保护操作系l技术要?
? 计算Z息系l安全等U保护管理要?
? GA/T 387-2002 计算Z息系l安全等U保护网l技术要?
? GA/T 390-2002 计算Z息系l安全等U保护通用技术要?
? GA 163-1997 计算Z息系l安全专用品分cd?
? GA 174-1998 Z DOS 的信息安全品评U准?
? GA 216.1-1999 计算Z息系l安全品部件第 1 部分Q安全功能检?
企业标准
? BZ01CSTC 软g产品试与评估通用规范
? BZ02CSTC 应用软g产品试规范
? BZ03CSTC 软g产品试评分标准
? BZ04CSTC 办公自动化Y件品测试规?
? BZ05CSTC 商务处理软g产品试规范
? BZ06CSTC 软g产品 2000 q符合性测试规?
? BZ07CSTC 软g产品登记试评分标准
? BZ08CSTC 软g产品登记试规范
? 国数据库管理系l评大U?
? 打印机测试规?
? 扫描仪测试规?
? 昄器测试规?
? 盘试规范
? 投媄机测试规?
? 台式 PC 试规范
? W记本测试规?
? 昄卡测试规?
? 服务器测试规?
? 交换机测试规?
? 防火墙测试规?
]]>
L有三q以上的软g开发经?
现在许多软g企业招收一些刚刚毕业的大学生或者非计算Z业的人员作ؓ自己公司软g试工程师，q是非常错误的，也是对Y件测试不负责ȝ表现。虽然他们可以发现Y件中的一些错误，但是对于软g中的一些关键，致命Q危险的错误他们是很隑֏现的。大安知道QY件工E中有个模型叫瀑布模型Q这是最基本的Y件模型，q个模型又叫状模型Q因为开发位于碗的最底部Q左上方依次为徏模，需求分析，设计Q右上方依次为测试，部vQ维护。这是说明软g开发是一切Y件活动的基础Q同时也是Y件测试的基础。一个h只有l历q一定年限的软g开发工作，才可以积累丰富的l验Q知道在软g中哪些地方容易出错而那些地方不ҎQ这l以后的软g试工作带来非常宝贵的经验?
有逆向思维的能?
我曾l接触过一些Y件测试工E师Q他们干了一D|间Y件测试工作后q回d开始去做开发工作了Q问他们为啥Q答案是软g试工作太难了，开发是向思维Q而测试是逆向思维Q老要找一些稀奇古怪的思\L作Y件。Y件的使用者千差万别，软g在用过E中遇到的各U现象也是千差万别的Q所以要求Y件测试工E师需要具有一些逆向思维的能力，惛_人所不想Q测别h所不测Q这h可以扑ֈ更多的Y件中的错误。这是作Z名优U的Y件测试工E师最基本的素质?
善于?a class="bluekey" target="_blank">软g开发h?/a>沟?
?strong> 通是当今软g目中需要掌握的最关键技术之一。Y件测试h员要善于同Y件开发h员沟通，软g试人员与开发h员搞好关p，使测试h员不成ؓ开发h员的g钉，q对于提高整个Y仉目质量是十分重要的。沟通主要包括：
讨论软g的需求，设计Q?br /> 通过q样的沟通，你可以更好的了解所试的Y件系l，以至于尽可能的试Y件中不是错误的“错误”，从而降低给软g开发h员带来的压力?
报告好的试l果Q?br /> 作ؓ一个测试h员，发现错误往往是测试h员最愿意而且引以自豪的结果，但是一呛_l开发h员报告Y仉误，会给他们造成厌恶感，降低整个软g的质量和开发进度。所以作Z名Y件测试工E师Q当你测试的模块没有严重的错误或者错误很的时候，你不妨跑到开发h员那里告诉他们这个好消息Q这会给你带来意想不到的l果?
讨论一些与工作无关的事情：
作ؓ一个测试h员经常和开发h员讨Z些与工作无关的事情，比如大家可以谈谈新闻Q趣事，家庭…这样可以加强相互间的默契程度，许多l计?/a>明，q样可以更好的提高Y件工作质量?
善于同领导沟?
试人员往往是领导的眼和耻I领导Ҏ试人员的测试结果可以了解公司的产品质量Q从而调整其他的工作。领导工作一般比较繁忙，所以作Z名优U的测试h员要学会把测试结果进行ȝQ最好以图表的Ş势给领导看?br />
掌握一些自动化试工具
试工作往往是比较繁琐，枯燥无味的工作，试人员长期处于重复的手工工作，会降低测试效率，q且对于试质量也往往是不利的Q况且许多测试不使用试工具是不可以q行的，比如性能试Q?a class="bluekey" target="_blank">压力试{等。目前市Z有许多测试工具供你用，你可以根据自q需要选择一些测试工h辅助你的试。但是要C一点，不是说有了测试工具就不要人工试了，试工具不是万能的?
善于学习的能?
软g试技?/a>随着旉的变化也在做一些提高和改进Q作Z名优U的测试h员要善于利用书籍Q网站，论坛Q交等各种途径不断提高自己的Y件测试水q?
提高自己的表达能?
软g试人员当发现Y件中存在~陷的时候，往往要书写缺h告，~陷报告要写得详清楚，使开发h员能够尽快定位错误，修改错误Q所以作Z名优U的测试h员提高自q写作能力是非常必要的?br />
了解业务知识
更好的了解你说测试Y件的业务知识是非帔R要的Q对业务知识了解得越深入Q越能够扑և更深入，更关键，更隐蔽的软g错误。所以作Z名优U的Y件测试工E师Q要多向该领域专Ӟ同行学习Q提高自q业务知识水^?
以上仅ؓ个h的一些经验所谈，希望大家都能够成Z名优U的Y件测试工E师?/span>
]]>
黑盒试也称功能试Q它是通过试来检每个功能是否都能正怋用。在试圎ͼ把程序看作一个不能打开的黑盒子Q在完全不考虑E序内部l构和内部特性的情况下，在程序接口进行测试，它只查程序功能是否按照需求规D明书的规定正怋用，E序是否能适当地接收输入数据而生正的输出信息。黑盒测试着gE序外部l构Q不考虑内部逻辑l构Q主要针对Y件界面和软g功能q行试?
黑盒试是以用户的角度，从输入数据与输出数据的对应关pd发进行测试的。很明显Q如果外部特性本w有问题或规D明的规定有误Q用墨盒试Ҏ是发C了的?/p>
黑盒试法注重于试软g的功能需求，主要试图发现下列几类错误?/p>
功能不正或遗漏Q?
界面错误Q?
数据库访问错误；
性能错误Q?
初始化和l止错误{?
从理ZԌ黑盒试只有采用ID输入试Q把所有可能的输入都作为测试情况考虑Q才能查出程序中所有的错误。实际上试情况有无I多个，Z不仅要测试所有u的输入，而且q要寚w些不合法但可能的输入q行试。这L来，完全试是不可能的，所以我们要q行有针Ҏ的试Q通过制定试案例指导试的实施，保证软g试有组l、按步骤Q以及有计划地进行。黑盒测试行为必能够加以量化，才能真正保证软g质量Q而测试用例就是将试行ؓ具体量化的方法之一。具体的黑盒试用例设计Ҏ包括{hcd分法、边界值分析法、错误推法、因果图法、判定表驱动法、正交试验设计法、功能图法等?/p>
{hcd分的办法是把E序的输入域划分成若q部分，然后从每个部分中选取数代表性数据作为测试用例。每一cȝ代表性数据在试中的作用{h于这一cM的其他倹{?/p>
边界值分析是通过选择{hc边界的试用例。边界值分析法不仅重视输入条g边界Q而且也必考虑输出域边界?/p>
错误推测设计Ҏ是Zl验和直觉推程序中所有可能存在的各种错误Q从而有针对性地设计试用例的方法?/p>
因果图方法是从用自然语言书写的程序规D明的描述中找出因Q输入条Ӟ和果Q输出或E序状态的改变Q，可以通过因果图{换ؓ判定表?/p>
正交试验设计法，是使用已经造好了的正交表格来安排试验ƈq行数据分析的一U方法，目的是用最的试用例辑ֈ最高的试覆盖率?
白盒试也称l构试或逻辑驱动试Q它是按照程序内部的l构试E序Q通过试来检品内部动作是否按照设计规D明书的规定正常进行，验程序中的每条通\是否都能按预定要求正工作?/p>
q一Ҏ是把试对象看作一个打开的盒子，试人员依据E序内部逻辑l构相关信息Q设计或选择试用例Q对E序所有逻辑路径q行试Q通过在不同点查程序的状态，定实际的状态是否与预期的状态一致?/p>
采用什么方法对软gq行试呢？常用的Y件测试方法有两大c：静态测试方法和动态测试方法。其中Y件的静态测试不要求在计机上实际执行所程序，主要以一些h工的模拟技术对软gq行分析和测试；而Y件的动态测试是通过输入一l预先按照一定的试准则构造的实例数据来动态运行程序，而达到发现程序错误的q程?/p>