编写优秀Bug报告的艺术

第一篇：编写优秀Bug报告的艺术

编写优秀Bug报告的艺术

前言

在Quality week上的一次演讲中，微软的一个测试经理，Roger Sherman指出了由于“不可重现”导致bug关闭的主要原因。这是一个非常可惜的情况，因为这样的bug report浪费了紧张的开发计划中的宝贵时间，增加了对产品质量完全是无关紧要的事情，同时导致了在开发人员和测试之间的挫败感和差的感觉。有时，bug report是由于短暂的或随机的事件，测试和开发之间不一致的工具和配置，或者在测试的环境下对正确的行为的模糊定义而产生的，但是许多的由于不可重现而被关闭的测试报告是因为描述不清晰，被误解，或者只是文字的错误。

幸运的是，我学习到一些能够引起管理层注意，更清楚的和开发人员沟通并得到修复的编写优秀bug report的诀窍。这些技巧不仅仅提供了是在被修复的问题的比例方面得到了可靠的回报，而且在同开发人员和管理层的通过中也得到了回报。在我管理的项目中使用这种方法编写bug report，8份bug report中大约只有一个没有被修复。

这篇文章的思想只有当你的报告针对的测试执行过程是专业的质量工作才可以发挥作用。聪明地执行完整的测试包是产生可靠的测试状况信息的基础的其中一个因素。在许多的测试文献中广泛地介绍了多种多样的关于如何构建这样的测试包的方法。选择和你质量风险管理需求相一致的技术并且使之适应你的具体情况，敏捷地监督已计划的测试的执行过程，这样你就可以拥有可靠的测试执行过程。

另外一个关键的因素－bug report，却没有得到太多的关注。这是非常令人遗憾的，因为优秀的bug report对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。试想一下：如果你不能用开发人员能够理解的术语和能够用于调试的方法给开发人员解释一个错误，他怎么能够修复问题呢？如果你不能够在bug report中提出象“保险杆标签”（bumper sticker）一样的错误总结来引起管理层的注意，你又如何让他们关心你们发现的问题呢？

Bug report的核心是对错误的描述。表格1中是一个关于好和差的错误描述的例子。编写好的bug report是一种好的艺术形式。采用以下的10条技巧可以帮助你的小组提高编写bug report的质量：

1.组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问獾牡胤健?

2.重现Reproduce：测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次。

3.隔离Isolate：在尝试编写bug report之前，必须试着隔离错误。可以采用改变一些

变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。

4.归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题

进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？

5.对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该

检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。

6.总结Summarize：在bug report的第一行写上错误的总结是非常关键的。测试人

员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。

7.精简Condense：在bug report的初稿完成后，测试人员应该反复阅读它，集中剔

除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。

8.消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检

查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。

9.中立Neutralize：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。

如同所有的错误总结一样，独立的bug report在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述事实。

10.检查Review：一旦测试人员感觉bug report是他能够编写的最好版本，他应该将

报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的bug report。

以上10条技巧可以帮助你和你的小组提交准确简洁的，彻底校订的，精心构思的，高质量的技术文档。测试小组应该集中编写bug report的任务，测试组长和经理应该让测试组成员清楚地认识到编写优秀的bug report是一项首要的工作任务。衡量优秀的bug report的质量指标应该包括如下：

对管理层来说，是清晰明了的，特别是在概要这一级；

对于开发部门是有用的，主要是给出能够让开发人员高效地调试问题的相关信息

可以很快的将bug从“Opened”状态转变成“Closed”状态，减少为得到更多的信息从开发人员打回的差的bug report并导致测试人员返工的时间。

改进bug报告的流程是需要花费一些时间的，但是也给予了效果显著的回报。首先，简单的流程改进了测试小组和高层、平行管理层之间的沟通，增强小组的信任度，名望和鼓励管理层给测试投资更多的资源。第二，平稳地递交报告给开发人员促进了测试和开发人员之间积极的关系。第三，更短的bug生命周期是更加有效的，在时间上之前花费在编写优秀bug report上的时间和后期由于返工差的bug report花费的时间相抵消。这些回报帮助开发流程通过有效的沟通和高效率的流程获得更好的产品质量。

第二篇：有效地报告BUG

如何有效地报告Bug------------------引言

为公众写过软件的人，大概都收到过很拙劣的bug（计算机程序代码中的错误或程序运行时的瑕疵??译者注）报告，例如： 在报告中说“不好用”； 所报告内容毫无意义；

在报告中用户没有提供足够的信息； 在报告中提供了虚假信息；

所报告的问题是由于用户的过失而产生的； 所报告的问题是由于其他程序的错误而产生的； 所报告的问题是由于网络错误而产生的；

这便是为什么“技术支持”被认为是一件可怕的工作，因为有拙劣的bug报告需要处理。然而并不是所有的bug报告都令人生厌：我在业余时间维护自由软件，有时我会收到非常清晰、有帮助并且内容丰富的bug报告。

在这里我会尽力阐明如何写一个好的bug报告。我非常希望每一个人在报告bug之前都读一下这篇短文，当然我也希望用户在给我报告bug之前已经读过这篇文章。

简单地说，报告bug的目的是为了让程序员看到程序的错误。您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。

在bug报告里，要设法搞清什么是事实（例如：“我在电脑旁”和“XX出现了”）什么是推测（例如：“我想问题可能是出在„„”）。如果愿意的话，您可以省去推测，但是千万别省略事实。

当您报告bug的时候（既然您已经这么做了），一定是希望bug得到及时修正。所以此时针对程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的??因为这可能是程序员的错误，也有可能是您的错误，也许您有权对他们发火，但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。除此以外，请记住：如果是免费软件，作者提供给我们已经是出于好心，所以要是太多的人对他们无礼，他们可能就要“收起”这份好心了。“程序不好用”

程序员不是弱智：如果程序一点都不好用，他们不可能不知道。他们不知道一定是因为程序在他们看来工作得很正常。所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。他们需要信息，报告bug也是为了提供信息。信息总是越多越好。

许多程序，特别是自由软件，会公布一个“已知bug列表”。如果您找到的bug在列表里已经有了，那就不必再报告了，但是如果您认为自己掌握的信息比列表中的丰富，那无论如何也要与程序员联系。您提供的信息可能会使他们更简单地修复bug。

本文中提到的都是一些指导方针，没有哪一条是必须恪守的准则。不同的程序员会喜欢不同形式的bug报告。如果程序附带了一套报告bug的准则，一定要读。如果它与本文中提到的规则相抵触，那么请以它为准。

如果您不是报告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。）这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档做得更容易使用。“演示给我看”

报告bug的最好的方法之一是“演示”给程序员看。让程序员站在电脑前，运行他们的程序，指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操作以及程序对您的输入有何反应。

他们对自己写的软件了如指掌，他们知道哪些地方不会出问题，而哪些地方最可能出问题。他们本能地知道应该注意什么。在程序真的出错之前，他们可能已经注意到某些地方不对劲，这些都会给他们一些线索。他们会观察程序测试中的每一个细节，并且选出他们认为有用的信息。

这些可能还不够。也许他们觉得还需要更多的信息，会请您重复刚才的操作。他们可能在这期间需要与您交流一下，以便在他们需要的时候让bug重新出现。他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。如果您不走运，他们可能需要坐下来，拿出一堆开发工具，花上几个小时研究。但是最重要的是在程序出错的时候让程序员在电脑旁。一旦他们看到了问题，他们通常会找到原因并开始试着修改。“告诉我该怎么做”

如今是网络时代，是信息交流的时代。我可以点一下鼠标把自己的程序送到俄罗斯的某个朋友那里，当然他也可以用同样简单的方法给我一些建议。但是如果我的程序出了什么问题，我不可能在他旁边。“演示”是很好的办法，但是常常做不到。

如果您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。当他们亲眼看到错误时，就能够进行处理了。

确切地告诉程序员您做了些什么。如果是一个图形界面程序，告诉他们您按了哪个按钮，依照什么顺序按的。如果是一个命令行程序，精确的告诉他们您键入了什么命令。您应该尽可能详细地提供您所键入的命令和程序的反应。

把您能想到的所有的输入方式都告诉程序员，如果程序要读取一个文件，您可能需要发一个文件的拷贝给他们。如果程序需要通过网络与另一台电脑通讯，您或许不能把那台电脑复制过去，但至少可以说一下电脑的类型和安装了哪些软件（如果可以的话）。

“哪儿出错了？在我看来一切正常哦！”

如果您给了程序员一长串输入和指令，他们执行以后没有出现错误，那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不一样。有时候程序的行为可能和您预想的不一样，这也许是误会，但是您会认为程序出错了，程序员却认为这是对的。

同样也要描述发生了什么。精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的，最好再告诉他们，您认为自己应该看到什么。如果您只是说：“程序出错了”，那您很可能漏掉了非常重要的信息。

如果您看到了错误消息，一定要仔细、准确的告诉程序员，它们很重要。在这种情况下，程序员只要修正错误，而不用去找错误。他们需要知道是什么出问题了，系统所报的错误消息正好帮助了他们。如果您没有更好的方法记住这些消息，就把它们写下来。只报告“程序出了一个错”是毫无意义的，除非您把错误消息一块报上来。

特殊情况下，如果有错误消息号，一定要把这些号码告诉程序员。不要以为您看不出任何意义，它就没有意义。错误消息号包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。给错误消息编号是因为用语言描述计算机错误常常令人费解。用这种方式告诉您错误的所在是一个最好的办法。

在这种情形下，程序员的排错工作会十分高效。他们不知道发生了什么，也不可能到现场去观察，所以他们一直在搜寻有价值的线索。错误消息、错误消息号以及一些莫名其妙的延迟，都是很重要的线索，就像办案时的指纹一样重要，保存好。

如果您使用UNIX系统，程序可能会产生一个内核输出（core dump）。内核输出是特别有用的线索来源，别扔了它们。另一方面，大多数程序员不喜欢收到含有大量内核输出文件的EMAIL，所以在发邮件之前最好先问一下。还有一点要注意：内核输出文件记录了完整的程序状态，也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可能包含在内核输出文件里。“出了问题之后，我做了„„”

当一个错误或bug发生的时候，您可能会做许多事情。但是大多数人会使事情变的更糟。我的一个朋友在学校里误删了她所有的Word文件，在找人帮忙之前她重装了Word，又运行了一遍碎片整理程序，这些操作对于恢复文件是毫无益处的，因为这些操作搞乱了磁盘的文件区块。恐怕在这个世界上没有一种反删除软件能恢复她的文件了。如果她不做任何操作，或许还有一线希望。

这种人仿佛一只被逼到墙角的鼬（黄鼠狼、紫貂一类的动物??译者注）：背靠墙壁，面对死亡的降临奋起反扑，疯狂攻击。他们认为做点什么总比什么都不做强。然而这些在处理计算机软件问题时并不适用。不要做鼬，做一只羚羊。当一只羚羊面对料想不到的情况或受到惊吓时，它会一动不动，是为了不吸引任何注意，与此同时也在思考解决问题的最好办法（如果羚羊有一条技术支持热线，此时占线。）。然后，一旦它找到了最安全的行动方案，它便去做。

当程序出毛病的时候，立刻停止正在做的任何操作。不要按任何按钮。仔细地看一下屏幕，注意那些不正常的地方，记住它或者写下来。然后慎重地点击 “确定” 或“取消”，选择一个最安全的。学着养成一种条件反射??一旦电脑出了问题，先不要动。要想摆脱这个问题，关掉受影响的程序或者重新启动计算机都不好，一个解决问题的好办法是让问题再次产生。程序员们喜欢可以被重现的问题，快乐的程序员可以更快而且更有效率的修复bug。“我想粒子的跃迁与错误的极化有关”

并不只是非专业的用户才会写出拙劣的bug报告，我见过一些非常差的bug报告出自程序员之手，有些还是非常优秀的程序员。

有一次我与另一个程序员一起工作，他一直在找代码中的bug，他常常遇到一个bug，但是不会解决，于是就叫我帮忙。“出什么毛病了？”我问。而他的回答却总是一些关于bug的意见。如果他的观点正确，那的确是一件好事。这意味着他已经完成了工作的一半，并且我们可以一起完成另一半工作。这是有效率并有用的。

但事实上他常常是错的。这就会使我们花上半个小时在原本正确的代码里来回寻找错误，而实际上问题出在别的地方。我敢肯定他不会对医生这么做。“大夫，我得了Hydroyoyodyne（真是怪病??译者），给我开个方子”，人们知道不该对一位医生说这些。您描述一下症状，哪个地方不舒服，哪里疼、起皮疹、发烧„„让医生诊断您得了什么病，应该怎样治疗。否则医生会把您当做疑心病或精神病患者打发了，这似乎没什么不对。

做程序员也是一样。即便您自己的“诊断”有时真的有帮助，也要只说“症状”。“诊断”是可说可不说的，但是“症状”一定要说。同样，在bug报告里面附上一份针对bug而做出修改的源代码是有用处的，但它并不能替代bug报告本身。

如果程序员向您询问额外的信息，千万别应付。曾经有一个人向我报告bug，我让他试一个命令，我知道这个命令不好用，但我是要看看程序会返回一个什么错误（这是很重要的线索）。但是这位老兄根本就没试，他在回复中说“那肯定不好用”，于是我又花了好些时间才说服他试了一下那个命令。

多动动脑筋对程序员是有帮助的。即使您的推断是错误的，程序员也应该感谢您，您的尝试使他们的工作变的更简单。不过千万别忘了报告“症状”，否则只会使事情变得更糟。“真是奇怪，刚才还不好用，怎么现在又好了？”

“间歇性错误”着实让程序员发愁。相比之下，进行一系列简单的操作便能导致错误发生的问题是简单的。程序员可以在一个便于观察的条件下重复那些操作，观察每一个细节。太多的问题在这种情况下不能解决，例如：程序每星期出一次错，或者偶然出一次错，或者在程序员面前从不出错（程序员一离开就出错。??译者）。当然还有就是程序的截止日期到了，那肯定要出错。

大多数“间歇性错误”并不是真正的“间歇”。其中的大多数错误与某些地方是有联系的。有一些错误可能是内存泄漏产生的，有一些可能是别的程序在不恰当的时候修改某个重要文件造成的，还有一些可能发生在每一个小时的前半个小时中（我确实遇到过这种事情）。

同样，如果您能使bug重现，而程序员不能，那很有可能是他们的计算机和您的计算机在某些地方是不同的，这种不同引起了问题。我曾写过一个程序，它的窗口可以蜷缩成一个小球停在屏幕的左上角，它在别的计算机上只能在 800x600 解析度工作，但是在我的机器上却可以在 1024x768 工作。

程序员想要了解任何与您发现的问题相关的事情。有可能的话您到另一台机器上试试，多试几次，两次，三次，看看问题是不是经常发生。如果问题出现在您进行了一系列操作之后，不是您想让它出现它就会出现，这就有可能是长时间的运行或处理大文件所导致的错误。程序崩溃的时候，您要尽可能的记住您都做了些什么，并且如果您看到任何图形, 也别忘了提一下。您提供的任何事情都是有帮助的。即使只是概括性的描述（例如：当后台有EMACS运行时，程序常常出错），这虽然不能提供导致问题的直接线索，但是可能帮助程序员重现问题。

最重要的是：程序员想要确定他们正在处理的是一个真正的“间歇性错误”呢，还是一个在另一类特定的计算机上才出现的错误。他们想知道有关您计算机的许多细节，以便了解您的机器与他们的有什么不同。有许多细节都依仗特定的程序，但是有一件东西您一定要提供??版本号。程序的版本、操作系统的版本以及与问题有关的程序的版本。“我把磁盘装进了我的Windows„„”

表意清楚在一份bug报告里是最基本的要求。如果程序员不知道您说的是什么意思，那您就跟没说一样。我收到的bug报告来自世界各地，有许多是来自非英语国家，他们通常为自己的英文不好而表示歉意。总的来说，这些用户发来的bug报告通常是清晰而且有用的。几乎所有不清晰的bug报告都是来自母语是英语的人，他们总是以为只要自己随便说说，程序员就能明白。

精确。

如果做相同的事情有两种方法，请说明您用的是哪一种。例如：“我选择了‘载入’”，可能意味着“我用鼠标点击‘载入’”或“我按下了‘ALT+L’”，说清楚您用了哪种方法，有时候这也有关系。详细。

信息宁多毋少！如果您说了很多，程序员可以略去一部分，可是如果您说的太少，他们就不得不回过头再去问您一些问题。有一次我收到了一份bug报告只有一句话，每一次我问他更多事情时，他每次的回复都是一句话，于是我花了几个星期的时间才得到了有用的信息。

谨慎使用代词。

诸如“它”，“窗体”这些词，当它们指代不清晰的时候不要用。来看看这句话：“我运行了FooApp，它弹出一个警告窗口，我试着关掉它，它就崩溃了。”这种表述并不清晰，用户究竟关掉了哪个窗口？是警告窗口还是整个FooApp程序？您可以这样说，“我运行FooApp程序时弹出一个警告窗口，我试着关闭警告窗口，FooApp崩溃了。”这样虽然罗嗦点，但是很清晰不容易产生误解。检查。

重新读一遍您写的bug报告，您觉得它是否清晰？如果您列出了一系列能导致程序出错的操作，那么照着做一遍，看看您是不是漏写了一步。

小结：

bug报告的首要目的是让程序员亲眼看到错误。如果您不能亲自做给他们看，给他们能使程序出错的详细的操作步骤。

如果首要目的不能达成，程序员不能看到程序出错。这就需要bug报告的第二个目的来描述程序的什么地方出毛病了。详细的描述每一件事情：您看到了什么，您想看到什么，把错误消息记下来，尤其是“错误消息号”。

当您的计算机做了什么您料想不到的事，不要动！在您平静下来之前什么都别做。不要做您认为不安全的事。

尽量试着自己“诊断”程序出错的原因（如果您认为自己可以的话）。即使做出了“诊断”，您仍然应该报告“症状”。

如果程序员需要，请准备好额外的信息。如果他们不需要，就不会问您要。他们不会故意为难自己。您手头上一定要有程序的版本号，它很可能是必需品。

表述清楚，确保您的意思不能被曲解。

总的来说，最重要的是要做到精确。程序员喜欢精确。

第三篇：bug分析报告

一、整体bug分布

1、模块分布图

2、严重程度分布图

3、Bug时间分布-模块-严重程度分布图等

二、功能模块bug分布

1、严重程度分布

2、Bug时间分布

三、测试阶段bug分布

1、模块分布图

2、严重程度分布图

3、Bug时间分布-模块-严重程度分布图等

四、bug出现原因总结

分析bug出现的原因，对bug原因进行归类整理等

第四篇：Bug 报告的流程以及要素分析

Bug 报告的流程以及要素分析

前提：标准的对日项目中使用

Bug发行和处理流程

1． 测试中发现问题

2． 寻找参照文档即发行依据。3． 进行对比信息采集

4． 进行不重复bug的自我确认 5． 进行bug发行确认（pl确认）6． 书写bug report-〉submit 7． 项目组长check, 测试员再现操作-〉bug report 状态便更为open 8． 开发方-〉确认-〉1.待确认（缺少信息）-> bug report 打回6，进行信息添加。

2．分析修改

9． bug report待测试状态-〉测试员进行测试—〉测试OK->closed —〉 测试NG-〉等待继续修改。

Bug 报告的要素

1． 概要

用最精简的话语，最好是一句来描述你发现的问题。一般逻辑为，哪里，进行了什么操作，本该出现什么，结果出现了什么。（比较严重的缺陷不需要说明期望结果）2． 步骤

从第一步开始书写你的操作手顺。一般原则为：让一个不熟悉此操作的人，按照你的步骤能够再现这个bug.**需要注意的是。需要书写的步骤不能含有冗余。也就是说，需要测试员在发现问题后对自己已经确定的再现操作步骤进行排除和分析。只保留缺一不可的步骤。3． 再现率

一般为 X/Y的格式。即再现次数/操作次数。

4． 发行依据，就是参考文件，你是依据什么文件（权威，一般为需求文档或者开发方的说明文档等）而发行的这个bug.5． 对比信息。包括类比和对比信息。6． 测试环境

7． 使用的测试数据

8． 测试附件 图片，录影（图片无法说明的），log文件。9． 其他

以上是书写bug的重要要素。当然，一个bug报告的组成还有以下：

bug的概要分析。分析这个bug属于什么范围的问题，什么模块的问题。是进行了什么操作而造成的。

Bug的优先级。有三级与五级这两种不同的区分。依据项目而定。这种级别一般是测试员没有权限决定但是有权利进行建议的。Bug的分析过程。一般由开发和分析人员填写。

Bug的再测试纪录，一般由测试人员填写测试经过，测试时间，步骤，结果然后会由PL进行确认和提交。

Bug的结束时间以及结束原因。

分四种情况，一种是因为测试员测试OK的，原因一般为修改完成等

一种是开发人员觉得有风险不修改，觉得没有必要修改，或者其他的原因不与修改的。这时候的原因就比较多，例如，延迟修改，不修改等。

第三种情况一般是因为测试人员自己的原因发行的误bug.比如说式样，需求，设计已经修改但是测试员没有及时参照。此时的结束原因就会是：操作错误，需求理解错误，涉及理解错误，数据错误等等。

最后一种其实也不算是bug.但是不能将结束原因归咎于测试员的误操作。比如需求变更，环境原因等。

以上这些都是在系统中进行，如果大家在实际的测试中没有测试工具来进行分析，就只好采用手工了。但是有了这些要素。估计会对工作有很大的帮助。

对日项目相对欧美比较复杂，但是对于后期的bug的分析以及测试的分析有很大帮助。

第五篇：中学教师教案编写的艺术

中学教师教案编写的艺术

一、教案编写的基本要求

教案是教师为实现教学目的、完成教学任务而制定的施教方案，是教学目的、重点难点、课时安排、教学内容、教学动作等有序地组合在一起而形成的建构体系。教师在完成教材分析与处理、了解学生、教学资料收集、教法选用与设计之后，就可以着手编写教案了。可以说，教案是教师备课的书面成果是各项课前准备工作成绩的集大成者，也是教师创造性劳动的标志。教师编写教案必须遵循以下要求：

1、高度重视，扎实准备

编写教案是课堂教学质量的保证，课堂教学要受时间限制，教学内容具有系统性、条理性、逻辑性，教学实施具有程序性，这些要求仅凭大脑记忆是不够的，需要见诸文字，才能落到实处。有了教案，教师就可以有目的按计划地从容熟练地进行课堂教学。有教案与没教案，认真编写的教案与马虎从事的教案，其教学效果是大不相同的。精心编写的优秀教案，不仅是教师实施教学的蓝本，还是教师总结教学经验、开展教学研究、提高教学水平的珍贵资料。教师必须从思想上高度重视教案的作用，扎实准备（包括钻研教材、了解学生、收集资料），认真撰写，才能编写出有水平有创意的教案。

2、遵循“三个统一”的原则

第一个统一指传授知识、进行思想教育和培养能力的统一。

教师在编写教案时，应就每一课时知识的深度和广度，着重进行哪一方面的思想教育，对学生行为提出什么具体要求，培养学生什么能力等，都要作出明确的规定。同时，还要认真考虑这三者是否协调一致，及如何实现三者的协调一致。

第二个统一指教和学的统一。教师在编写教案时，不仅要考虑教师如何教，而且要考虑学生如何学，使教和学配合默契，融为一体。教师必须紧密结合教学内容和学生的实际，确定恰当的教学方法，提出如何引起学生兴趣的具体设想。

第三个统一指科学性、思想性和趣味性的统一。教案的科学性主要指观点表述务求准确，说理要充分，论证要严密，例证要典型。教案的思想性主要指能体现课程标准要求，有针对性地对学生进行思想教育。教案的趣味性主要体现在语言生动、幽默、形象，引进事例和材料丰富并感人。编写教案要做到科学性、思想性、趣味性的统一，必须以教材为着眼点，突出科学性和思想性，而趣味性应是服务于这两者的。

3、必须处理好三对关系

第一，观点与例证的关系。例证要为观点服务，观点要通过例证来映证，要求例证与观点协调统一，防止例证与观点的脱节。

第二，深度与广度的关系。要依据课程标准和学生接受能力来确定讲授的广度和深度。有的内容必须讲清讲透，有的内容点到即可，不必在理论上多费笔墨。

第三，时间与内容的关系。教师必须合理组织教学内容，恰当安排教学时间，避免内容过多时间不够或内容贫乏半节课就讲完的情形。

二、教案编写的基本形式和内容结构

教案种类繁多，其中课时教案为基本型。课时教案有详细和简略之分。简略教案只写教学内容的要点。详细教案不仅要写出教学内容，还要写明教学环节、讲授层次的衔接、教学方法的设计、师生双边活动的安排、教具演示的程序、板书设计等，也就是要把整堂课的教学过程详细反映出来。新教师应该写出详细教案。编写教案没有固定的格式，一般有概况和正文两部分。

概况包括授课班级、授课课题名称、课的类型、课的安排。正文包括教学目的、教学重点、难点、拟用教具、拟用教法、教学进程

（含复习旧课导入新课（3－5分钟）、讲授新课（25－30分钟）、巩固新课（5分钟）、结束新课、布置课后思考题（5分钟）等环节）、板书设计、教学后记等。下面简要介绍教案各项目的书写内容及方法。

（1）课题名称

要写明本课时课题全称及教材版本

第几课第几框。如：“心理健康，有利成长”。

——国家教委统编，人民教育出版社1997年12月第1版《思想政治》初中一年级上册第二课第二框。

（2）课型、课时安排

课型主要包括授新课、复习课、讨论课、讲评课。课时安排主要指需几个课时才能完成本教案的教学内容，一般每框题安排1个课时。

（3）教学目的

教学目的包括：传授给学生哪些知识、培养学生何种能力、对学生进行哪方面思想教育。这三方面内容可用并列复句的形式表述，也可用条文的形式表述。可以三方面俱全，也可以是其中两方面，主要视具体教学内容而定。

（4）重点难点

每一课题包含的知识及所蕴含的思想政治教育因素是多方面的，在有限的时间内不可能也没必要等量齐观地传授给学生，必须区别轻重缓急、深浅难易。找准了重点难点，就抓住了教学的关键环节，并能增加教学活动的节奏感。重点难点的确定以教材分析成果为依据，一般以并列短语进行表述。

（5）拟用教法

指明本堂课教法组合，如“以讲述法、讲授法为主，以谈话法、演示法为辅”或“以谈话法为主，以讲授法、讨论法为辅。”有的同学习惯写“讲授法为主”显得笼统，因讲授法分讲述、讲授、讲读、讲演，彼此差别甚大。故应具体指明这四种方法中的某一种或某二种。至于每个子目，每个问题的具体教法，可在“讲授新课”中予以指明。

（6）拟用教具

写明打算在课堂上演示的教具名称。教具名称要写具体，不能写“打算张贴有关挂图”、“打算自制一张图表在适当时候展示”。某校学生关于“依法治惩犯罪”框题的实习教案的“拟用教具”栏是这样写的： “教具A挂图：云南省近年查获毒品一览表

教具B投影：禁赌刻不允缓”

这样表述具体明确，且有条理，是符合要求的。

（7）教学进程

教学进程是教案的主体，是对课时内教学内容展开和教学活动的具体计划安排。教学进程与课型密切联系，不同课型有不同的教学进程。下面着重介绍授新课教学进程诸环节的写作要领。

复习旧课——用简明的语言扼要写出提问的问题。所提问题应与新课内容有较大关联。答案不必写出，亦可简要写出。

导入新课——以简练的语言，紧扣新旧知识的内在联系，自然地把学生的思路从对旧知识的回顾或其他场景，引导到对新知识的探索上来。讲授新课——是教学进程的核心，也是整个教案的重头戏。首先，要明确写出讲授哪些内容，依次讲授；

其次，遵循从具体到抽象，从感性到理性的认识规律设计具体的教学步骤和方法，何时讲述，何时讲授，何时提问，何时展示直观教具以及对教具的解说词，都要一一写明；

再次，讲授新课的文字应准确生动，通俗易懂，符合逻辑。用什么语言表述概念原理，用什么语言连接各个问题，使之转换自然；用什么语言启发学生思维，都要反复揣摩，精心撰写。

巩固新课——是教师在讲完新课后对新授知识进行复习、检查巩固的环节，只需写上提问的问题或书面练习题（包括板演）的内容即可。可充分利用教材有关“想一想”、“议一议”等小栏目来设计巩固新课的方法。

结束新课——教师在巩固新课后，用归纳和启发性语言结束全课的环节，要求语言简练，高度概括本课内容，并引起学生回味和思索。

布置课后思考题——主要布置课后课后思考题，注意题型多样，题量应比巩固新课时出的题更多些，难度更大些。

（8）板书设计

板书是教学的重要辅助手段之一，应在课前备课时就设计好，并在教案上写明。板书设计要依据教材内容，做到提纲领提纲挈领，条理分明，详略得当，工整规范。

（9）教学后记

这是在上完课才写的项目，是对本课教学的小结，成败得失，经验教训，改进设想等均可写上。

如何撰写教学反思

对于教师来说，＂反思教学＂ 就是教师自觉地把自己的课堂教学实践, 作为认识对象而进行全面而深入的冷静思考和总结，它是一种用来提高自身的业务，改进教学实践的学习方式，不断对自己的教育实践深入反思，积极探索与解决教育实践中的一系列问题。进一步充实自己，优化教学，并使自己逐渐成长为一名称职的人类灵魂工程师。简单地说，教学反思就是研究自己如何教，自己如何学。教中学，学中教。因此，如何写好教学反思呢？笔者从以下几个方面与大家探讨：

（1）写成功之处

将教学过程中达到预先设计的教学目的、引起教学共振效应的做法；课堂教学中临时应变得当的措施；层次清楚、条理分明的板书；某些教学思想方法的渗透与应用的过程；教育学、心理学中一些基本原理使用的感触；教学方法上的改革与创新等等，详细得当地记录下来，供以后教学时参考使用，并可在此基础上不断地改进、完善、推陈出新，达到光辉顶点。

（2）写不足之处

即使是成功的课堂教学也难免有疏漏失误之处，对它们进行系统的回顾、梳理，并对其作深刻的反思、探究和剖析，使之成为今后再教学上吸取教训，更上一层楼。

（3）写教学机智

课堂教学中，随着教学内容的展开，师生的思维发展及情感交流的融洽，往往会因为一些偶发事件而产生瞬间灵感，这些＂智慧的火花＂常常是不由自主、突然而至，若不及时利用课后反思去捕捉，便会因时过境迁而烟消云散，令人遗憾不已。

（4）写学生创新 在课堂教学过程中，学生是学习的主体，学生总会有＂创新的火花＂在闪烁，教师应当充分肯定学生在课堂上提出的一些独特的见解，这样不仅使学生的好方法、好思路得以推广，而且对学生也是一种赞赏和激励。同时，这些难能可贵的见解也是对课堂教学的补充与完善，可以拓宽教师的教学思路，提高教学水平。因此，将其记录下来，可以补充今后教学的丰富材料养分。

（5）写＂再教设计＂

一节课下来，静心沉思，摸索出了哪些教学规律；教法上有哪些创新；知识点上有什么发现；组织教学方面有何新招；解题的诸多误区有无突破；启迪是否得当；训练是否到位等等。及时记下这些得失，并进行必要的归类与取舍，考虑一下再教这部分内容时应该如何做，写出＂再教设计＂，这样可以做到扬长避短、精益求精，把自己的教学水平提高到一个新的境界和高度。

总而言之，写课后教学反思，贵在及时，贵在坚持，贵在执着地追求。一有所得，及时写下，有话则长，无话则短，以写促思，以思促教，长期积累，必有＂集腋成裘、聚沙成塔＂的收获。以上是笔者对教学反思的撰写一些看法，可能还有很多错误，希望老师们在教学实践中批评指正。笔者也将根据自己的教学反思认知和研究深入进行修正。

三、编制教案过程中要注意的问题

教案编制的基本方法有文字表达法、列一览表法和卡片提示法。相应地,教案主要有文字表达式教案、表格式教案和卡片式教案等基本格式。在编制中，一般要注意以下问题：

1、教案内容

教案编写应内容全面、环节完整、具体明确、层次清楚，各部分的过渡衔接应自然顺畅，以确保教案在教学中的指导作用。否则，若书写杂乱，不分层次，就不能充分发挥教案作用，这将造成教学准备的充分程度下降，将直接影响教学质量的提高。

2、教案的重点

编写教案的重点应是教学过程和教学方法的设计。因此在实际教学中应避免两种倾向，一种是教案写得过于简单，只写成提纲形式，这样不利于教师的课前准备和具体教学过程的实施；另一种是将教案写成繁琐的讲稿，造成上课时照本宣科，不利于灵活地把握教学进程。

3、教案的修改和调整

编写的教案是组织教学的依据，但在具体教学实施中，教案也不是绝对不可改变的，可根据课堂上的实际情况，随时做些必要的修改和调整，以适应情况的变化，更好地完成教学任务。

4、教学后记

教后记是教案的一个组成部分。教学后要认真反思，填写教学计划的执行情况、效果如何、有什么经验教训、原因是什么、应如何改进等。以便不断积累和总结教学经验，提高教学水平。

四、教案编制的基本方法

教案编制的基本方法有文字表达法、列一览表法和卡片提示法。相应地，教案主要有文字表达式教案、表格式教案和卡片式教案等基本格式。

1、文字表达法

文字表达法就是教师编制教案时主要用文字形式将备课的结果表达出来。它可以编写成详细教案和简略教案两种。详细教案是把教学过程中的教学内容、教学步骤和教学方法都详细地写出来，类似讲稿；简略教案是只写教学内容的要点、主要教学步骤和主要教学方法，类似讲课提纲，它的优点是节约编写时间，可以用更多的时间去研究教法、熟悉教材等。教案是详写还是略写，应根据教师的个人经验和教学经验来决定，一般提倡编写详案。

2、列一览表法

列一览表法就是教师根据教学要求，按照课时教学内容而设计的一张“教案一览表”。它具有言简意赅、一目了然的特点，有利于教师熟记教学内容，避免产生教学失误。如果将“教案一览表”事先印发给学生，作为学习提纲，则可以减少教师课堂讲授时间，从而留出较多的时间让学生自学、讨论。这种方法既能使课堂教学生动活泼，又能提高教学质量。“教案一览表”的设计要简明扼要，力戒拖泥带水；要纵横联系，避免顾此失彼。

3、卡片提示法

卡片提示法就是教师将教案纲要、重点、难点和易忘记的内容以及需要补充的内容写在卡片上，以便在课堂教学中提示自己。卡片提示有两种形式:一种是教案纲要提示；另一种是教学内容提示和资料补充。卡片提示形式灵活、方便，便于教案的修改和补充，也是一种较好的方法。