-
UltraEdit 配置 python 环境(语法高亮)
2011-07-26 14:34:11
-
cmd窗口中运行ipconfig显示不是内部或外部命令
2011-07-19 14:51:27
-
我从编程中悟出八个字
2008-05-26 12:32:39
-
如何有效地报告Bug
2008-04-19 13:07:48
为公众写过软件的人，大概都收到过很拙劣的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系统，程序可能会产生一个内核输出（coredump）。内核输出是特别有用的线索来源，别扔了它们。另一方面，大多数程序员不喜欢收到含有大量内核输出文件的EMAIL，所以在发邮件之前最好先问一下。还有一点要注意：内核输出文件记录了完整的程序状态，也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可能包含在内核输出文件里。
“出了问题之后，我做了……”
当一个错误或bug发生的时候，您可能会做许多事情。但是大多数人会使事情变的更糟。我的一个朋友在学校里误删了她所有的Word文件，在找人帮忙之前她重装了Word，又运行了一遍碎片整理程序，这些操作对于恢复文件是毫无益处的，因为这些操作搞乱了磁盘的文件区块。恐怕在这个世界上没有一种反删除软件能恢复她的文件了。如果她不做任何操作，或许还有一线希望。
这种用户仿佛一只被逼到墙角的鼬（黄鼠狼、紫貂一类的动物——译者注）：背靠墙壁，面对死亡的降临奋起反扑，疯狂攻击。他们认为做点什么总比什么都不做强。然而这些在处理计算机软件问题时并不适用。不要做鼬，做一只羚羊。当一只羚羊面对料想不到的情况或受到惊吓时，它会一动不动，是为了不吸引任何注意，与此同时也在思考解决问题的最好办法（如果羚羊有一条技术支持热线，此时占线。）。然后，一旦它找到了最安全的行动方案，它便去做。
当程序出毛病的时候，立刻停止正在做的任何操作。不要按任何健。仔细地看一下屏幕，注意那些不正常的地方，记住它或者写下来。然后慎重地点击“确定” 或“取消”，选择一个最安全的。学着养成一种条件反射——一旦电脑出了问题，先不要动。要想摆脱这个问题，关掉受影响的程序或者重新启动计算机都不好，一个解决问题的好办法是让问题再次产生。程序员们喜欢可以被重现的问题，快乐的程序员可以更快而且更有效率的修复bug。
“我想粒子的跃迁与错误的极化有关”
并不只是非专业的用户才会写出拙劣的bug报告，我见过一些非常差的bug报告出自程序员之手，有些还是非常优秀的程序员。
有一次我与另一个程序员一起工作，他一直在找代码中的bug，他常常遇到一个bug，但是不会解决，于是就叫我帮忙。“出什么毛病了？”我问。而他的回答却总是一些关于bug的意见。如果他的观点正确，那的确是一件好事。这意味着他已经完成了工作的一半，并且我们可以一起完成另一半工作。这是有效率并有用的。但事实上他常常是错的。这就会使我们花上半个小时在原本正确的代码里来回寻找错误，而实际上问题出在别的地方。我敢肯定他不会对医生这么做。“大夫，我得了Hydroyoyodyne（真是怪病——译者），给我开个方子”，人们知道不该对一位医生说这些。您描述一下症状，哪个地方不舒服，哪里疼、起皮疹、发烧……让医生诊断您得了什么病，应该怎样治疗。否则医生会把您当做疑心病或精神病患者打发了，这似乎没什么不对。
做程序员也是一样。即便您自己的“诊断”有时真的有帮助，也要只说“症状”。“诊断” 查看(403) 评论(0) 收藏 分享 管理
如何成为一名优秀的软件质量保证工程师
2008-03-22 15:03:52
CMM与软件评价及测试
2008-03-20 21:58:15
CMM与软件评价及测试
在CMM的发展进程中，曾经提议将软件评价与测试（Evaluation and Test）作为CMM的一个KPA加入到CMM中，虽然这一提议最终未获通过，但通过对这一提议的讨论，我们可以得到很多与软件测试相关的一些有益的东西。
一、软件评价与测试在整个软件生命周期中的作用
评价是对软件开发过程中产生的各种系统规格和模型进行的验证活动。测试则是一种基于机器的对代码执行、确认的活动。大部分组织对评价和测试的定义都相对狭义，一般是指对代码执行物理测试用例的活动。事实上，很多公司甚至直到编码已经开始时才指定或安排测试人员。更有甚者，他们将这一活动的范围仅仅限于功能测试，也许有时做一下性能测试。这种观点在目前的CMM有关评价与测试的描述中被进一步强调，这就是SPE，软件产品工程KPA。在SPE KPA活动中，活动5、6、7，仅仅用了基于代码的测试作为例子，只明确地提到了功能测试。其他类型的测试只是用一句非常含糊的话来指代：“保证软件满足软件需求 ”。
另一方面，建造摩天大厦的人们，则远在砌第一块砖之前就将评价和测试集成到了开发过程之中。通过建模来验证稳定性、防水性、照明布置以及电源的需求等等，从而实施评价。而目前，组织所使用软件评价和测试方法就像是设计师一直等到大楼已经建成才进行测试，而此时的测试只是能保证给水和照明可以工作而已。
CMM只是进一步将评价和测试的部分思想进行融合，用一个特殊的评价技术来代替，这个技术就是CMM中的一个KPA，同行评审。这也意味着，在提交代码之前，唯一可干的评价就是同行评审，且已经足够了。事实上，对于一件事情的评价和测试的步骤包括：(1)定义成功准则；(2)涉及覆盖这些准则的用例；(3)执行用例；(4)验证结果，验证所有的内容都已覆盖。同行评审只是提供了一个基于纸面的测试机制。它既不能从根本上提供成功准则，也不能提供任何正式的机制以支持用例定义以用于同行评审中。同行评审本质是主观的，因此，基于误解使程序员将缺陷引入产品，而到同行评审时，基于同样的误解，也使得人们无法发现这些缺陷。
评价和测试的一个相对坚固的内涵范围必须包括项目在开发周期每一个阶段的每一个交付产品。它也必须考虑每个交付产品的每一个预期特性。而且必须包括每一个评价/测试步骤。下面我们看两个例子：评价需求和对一个设计的评价。
一个需求文档必须是完备的、一致的、正确的和清晰的。那么第一步就是基于项目/产品目标（即为什么要做这个项目的说明）对需求进行确认。这能够保证我们定义了正确的功能集。下一步评价就是遍历use-case脚本走查各功能规则，如果可能的话，最好用一些原型工具（screen prototype）作为辅助工具。第三步评价是有领域专家进行的对文档的同行评审。第四步是由非领域专家进行的正式的含糊性评审（他们无法读懂文档里的功能知识，这将帮助确保各种规则是明确定义的，而不是隐含定义）。第五步评价是将需求转换为布尔逻辑图。这可以鉴别规则之间的顺序问题，同时也能发现漏掉的用例(cases)。第五步评价是在CASE工具的辅助下进行的逻辑一致性检查。第七步评价是由领域专家进行的对测试脚本的评审，这些脚本是从需求导出来的。
对设计的评价一样可以进行一系列补救。一个是对照需求对设计文档进行走查。另一评价是构建一个模型来验证设计的完整性（例如构造一个操作系统的资源分配模式来保证不会发生死锁）。第三种评价是建立模型来验证性能特征。第四种是将形成的设计与其他公司的现成系统进行对比，以确保所设计的配置能够处理预期的处理规模和数据规模。
上面的评价只有一部分可以用同行评审来完成，没有一个是基于代码的。而且上边的例子中没有一个评价是穷尽的，必要时我们可以进行的其他评价。关键是我们输出一个交付产品（如需求文档），在我们能够正式称它是完备的并可被下一开发步骤使用之前，我们必须基于预期的特征对之进行评价。而进行这些评价需要比进行同行评审更加复杂的技术。
这就是评价和测试的关键所在。一个特征的预定义集合，尽可能被明确定义，用来对一个交付产品来进行确认。例如，当你在学校，进行了数学测验，老师会拿你的回答与预期答案相对比。老师不会仅仅说他们看上去也是合理的，或者他们更加准确。答案是 查看(604) 评论(0) 收藏 分享 管理
软件测试基本功之----WinRunner篇
2008-03-08 20:29:36
配置管理规范模板
2008-02-18 20:30:08
浅析项目管理之配置管理
2008-02-18 20:27:29
浅析项目管理之配置管理
简介：在软件项目实施过程中正确、有效地进行配置管理，需要进行科学合理的规划工作，并确定相应的执行策略。本文针对软件项目工作的特点，介绍了配置管理工作的一般步骤和注意事项。
在软件项目实施过程中正确、有效地进行配置管理，需要进行科学合理的规划工作，并确定相应的执行策略。本文针对软件项目工作的特点，介绍了配置管理工作的一般步骤和注意事项。
当软件开发团队发展到一定规模时，会越来越强调开发过程规范化和成熟度。软件项目的成败在很大程度上取决于对其开发过程的控制，这包括对质量、源代码、进度、资金、人员等的控制。软件配置管理可以帮助开发团队对软件开发过程进行有效地变更控制，高效地开发高质量的软件。在质量体系的诸多支持活动中，配置管理处在支持活动的中心位置，它有机地把其他支持活动结合起来，形成一个整体，相互促进，相互影响，有力地保证了质量体系的实施。
配置项的分类
在开展配置管理工作之前，首先应根据项目特点，对项目实施过程中涉及到的配置项进行分类工作。一般来说，一个完整的软件项目会包括项目管理文档、软件开发文档、程序代码、集成文档、维护文档等五类配置项，配置项分类结构如图所示。
对于每一类配置项，又可以划分为若干细类，具体的分类方法如下：在项目实施过程中制订的工程总体计划、阶段计划、周计划，定期召开的项目例会或技术专题会议的纪要，质量评审记录、配置管理报告等与质量相关的工作记录等文档，都属于项目管理方面的范畴，因此均可以划分到项目管理类文档进行管理。
作为一个软件项目，必然会产生贯穿软件工程标准定义的需求调研、需求分析、概要设计、详细设计、单元测试、系统测试、用户测试等各个阶段的软件文档，均可以归入到软件开发类文档之中。
在软件开发过程中产生的各模块程序代码，软件系统运行所需的各类参数以及配置文件等内容，由于其技术和管理特征与文档有很大的不同，而且相互之间的关联性比较强，为了对其版本进行有效地控制，建议单独划为一个类别进行管理。
软件系统的设计、开发和运行离不开硬件环境的支持，因此在软件项目的实施过程中，通常都会涉及到机房设计、主机安装、网络规划等方面的工作内容，因此系统集成类的文档应作为单独的一个类别，纳入到软件项目的配置管理之中。
在软件系统投入运行之后，需要进行相应的日常维护工作，在维护过程中产生阶段性运行总结报告、定期产生的维护日志、系统运行中出现的故障现象及问题解决情况等维护记录，都需要纳入维护类文档进行管理。
在软件项目实施过程中产生的各类文档、程序代码纷繁复杂、数量众多，通过对各类配置项的归类工作，形成逻辑清晰的配置管理结构，便于对文档和程序代码进行日常管理，使项目实施中产生的各类配置记录始终处于可控状态。
建立配置库
在软件项目的启动阶段，应指定一名专职或兼职的配置管理员，建立一台专用的配置服务器，安装相应的配置工具软件，并根据配置项分类方法，对程序代码和文档的目录结构进行规划工作，在配置工具软件中，建立起相应的配置目录结构，同时根据使用者角色的不同，设定相应的目录访问和存取权限。配置项及工作角色的对应关系如表所示。
对于每一个具体的配置项，都需要标识出其作者、时间、版本号、当前状态等基本信息，以便对配置项的版本进行实时监控，方便项目成员对配置项的检索和更新工作。
配置管理员负责整个配置库的安全管理工作，应妥善保管好系统管理员的口令，并进行定期的变更工作，以保证配置库的安全性。
建立执行机制
在配置库建立起来以后，配置管理员应将配置目录结构和权限分配表在项目组内部进行公布，并根据应用行业特点，对CMM/ISO9001的配置管理过程进行合理裁减，制订适用于本项目的配置工作流程，明确项目组中的每位成员在配置管理方面的分工职责，并对项目组成员进行相应的职责和流程培训工作。
配置管理员除了负责对各类配置项进行管理之外，还应对项目配置状况进行分析，定期提供配置报告，发布最新的配置项状态，提出改进建议并跟踪执行情况，避免出现因为文档或程序代码版本更新的不一致，而导致系统故障的情况发生。
在配置管理工作中，为了保证配置项的可靠性，应制订相应的备份策略，对配置库中的不同类型的配置项进行定期备份。在软件系统的设计开发阶段，程序代码类的配置项由于变更频繁，建议每天备份一次，在正式发布之后，可以改为每周备份一次。文档类的配置项变更机率相对较小，建议每周备份一次。具体的备份方法，可以采用手工方式执行备份操作，也可以在工具软件或操作系统中设定备份策略，定期自动执行备份操作，同时配置管理员应做好相应的备份记录工作。
由于配置工具软件本身一般都提供对每一个配置项历史版本的追溯机制，因此对配置库的备份操作，一般只需对当前配置库的内容进行备份即可。这里需要注意的一点是，在执行配置库的备份操作之前，应对配置库目录中的数据是否正常进行检查，以避免因库文件损坏而使错误数据覆盖正常备份库，从而导致配置项丢失的情况出现。
经验总结
如果配置工作流程制订得过于复杂，不具备可操作性，反而起不到应有的管理作用，因此在开展配置管理工作时，应以简单、有效、适合应用行业特点为基本准则，推进软件项目实施过程中的配置管理工作。
配置管理对象不仅仅限于CMM/ISO9001体系规定的内容，凡是与项目实施有关的文档、代码或数据均应纳入配置管理，这样可以实现对项目实施中的每一项工作进行追溯，及时处理项目实施过程中出现的各类问题。
在软件系统投入运行之时，应对配置库进行整理和提炼，形成从项目启动到系统运行阶段，涵盖项目管理、软件开发、系统集成等领域的一套完整的项目档案，随同软件系统正式交付给用户，并给予适当的培训和辅导，使用户能够快速有效地开展系统维护工作，为生产系统的稳定与可靠运行提供了保证。
标题搜索
我的存档
数据统计
- 访问量: 49834
- 日志数: 60
- 书签数: 1
- 建立时间: 2008-01-04
- 更新时间: 2012-02-18
