Ribbon

摘要： 模式是用来解决常见的、反复出现的问题。反模式是一种另类的模式，指我们反复犯的一些常见错误，了解反模式是避免发生错误的第一步。如果你发现自己面临着夸大优先级的问题时，那么可以采用如下方法：1. 定期清除你的缺陷，控制缺陷数据库2. 控制缺陷的优先级，允许用户指定严重性而不是优先级3. 不要用数字来表示优先级，按照优先顺序把缺陷列出来巨星效应会破坏团队。确保开发过程包含足够的检验机制和平衡机制：1. 确保“完成就是完成”，当前工作完成之前不允许任何人进入下一个任务。2. 将大任务分解成具体的小任务。3. 采用“自负自责”的原则，谁造成了缺陷谁就负责修复它。从最初的构思到最终部署，整个过程用同一个团 阅读全文

摘要： 有很多书或文章都在探讨如何编写好软件，但很少有讨论如何编写容易调试的软件，幸好，如果遵从创建良好软件的一般原则，即分离问题、避免复制、隐藏信息，并创建结构良好、易于理解和修改的软件，那么就能编写出容易调试的软件。良好的设计与调试并无冲突。代码的每一块都建立在一个无数假设的平台上——某些条件必须是正确的才能让运行结果符合预期，往往缺陷的出现是因为某些假设是不成立的或者是错误的。避免做出这些假设是不可能的也是没意义的，我们不仅可以验证它们，也可以通过断言来自动验证。断言长什么样？在Java里有两种格式，一种简单的格式：assert <condition>; 还有一种格式包含一条信息，若 阅读全文

摘要： 调试过程是不会发生在真空中的，因此提前了解基本知识，未雨绸缪，等你真的遇到一个缺陷时，会为你节省大量时间、精力并减少挫折感。有效的自动化测试不仅仅意味着简单地使你的测试自动化，为了达到效益最大化，你的测试必须满足：明确说明测试的结果是通过还是失败，每个测试输出一个结果——通过或者失败。独立，运行一个测试程序之前不需要安装，测试运行前，能够自动安装任何它需要的环境，测试后能撤销对环境的修改。单击运行所有测试，所有测试都可以一步运行，不会互相影响。全面覆盖，做到接近完全覆盖是有可能的。调试的时候是什么让自动化测试更有价值呢？首先，经过良好测试的代码往往只有少量缺陷，最容易修复的缺陷就是根本不存在的 阅读全文

摘要： 所谓“缺陷（bug）”是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。软件缺陷的主要类型：1. 软件没有实现产品规格说明要求的功能2. 软件出现了不该出现的错误3. 软件实现了说明没提到的功能4. 软件没实现虽然规格说明中未明确提及但应实现的目标5. 软件难理解，不易使用软件缺陷有四种级别，分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小的(Minor)。软件缺陷的三种基本状态：1. Active(Open)2. Fixed(Resolved)3. Close(Inactive)软件缺陷产生的原因主要有三方面：技术问题，团队合 阅读全文

摘要： 调试对于软件开发至关重要，然而调试并非是件容易事，Paul Butcher的这本《软件调试修炼之道》是一部非常优秀的软件调试实战指南，很多人光看标题，以为这本书只是在讲blackbox/whitebox testing, unit testing, regression testing, etc. 其实，作者根本没专门把这些Testing 101的内容拿出来讲。书的内容除了debug，还涵盖了很多『好』的软件开发方法。所谓的『好』的开发方法，就是要保证软件质量，保证开发进度，保证写出来的代码可维护。说真心话，这本书真的是软件工程方面的好书。而且这本书写的通俗易懂。它不需要读者拥有5年、10年以 阅读全文

摘要： 特殊案例之一就是修补已经发布的软件，诊断这种缺陷与其他缺陷并没有什么不同，但修复的目标通常是要修复错误的根源，而对已经发布的软件要进行修补时，他只是在最大程度降低风险。如果缺陷出现在用户已经使用的软件中，那么需要考虑向后兼容的问题。首先需要确定正在进行的修复是否可能引起兼容问题，此时，我们能做的就是对整体了解的基础上思考，将确定兼容性问题加入到缺陷修复的检查列表中，一旦确定有兼容性问题，该如何解决呢？1. 提供迁移的方法：给用户提供一些方法来修改其现有数据，代码等东西，以适应新的规则。2. 实现一个兼容模式：比如office word 2010打开word 2003版本显示如下：这不是一个能被 阅读全文

摘要： 本章主要内容有：什么时候修复缺陷？调试的思维模式自己如何解决质量问题早期修复缺陷基于两个原则：1. 那些可能发现缺陷的过程（测试、代码审查、用户使用）要连续贯穿于整个开发过程中2. 缺陷修复优先于其他任何事情目的：保证软件中存在的缺陷数量尽可能少。早期的缺陷检测和修复能帮助你估算在缺陷修复上大约需要多少时间并以此来修改测试计划。调试时一种心理活动。爱丽丝：再试也没用，人们不可能去相信不可能发生的事。怀特女王：我敢说你练的还很不够，我在你这么大的时候，每天做它半小时，有时在早餐前，我就相信有不可能的事情要发生。缺陷是不可避免的，无论多么努力，总会遗漏一些问题，因此不必去担心缺陷的发生，接受总会有 阅读全文

摘要： 之前的部分我们都假定已经知道软件存在缺陷，那么在这一章中，我们要看看在此之前，需要做什么呢？本章重点讲述三方面内容：缺陷追踪：使用缺陷追踪系统获取它所提供的信息，当发现缺陷时，记录下具体的，明确的，最小化的，唯一的缺陷报告，通过软件增加选项来自动收集环境和配置信息。与用户合作：用户很少会花时间来报告缺陷，即使报告了也不能保证缺陷的高质量，但我们可以简化整个流程来让用户帮助我们获得关于缺陷的更多信息。1. 在About对话框中，或者在线帮助网站等地方向用户解释如何报告缺陷2. 安装顶层的异常处理程序，给用户发送缺陷报告选项，记录下相关细节，比如office发送报告对话框3. 提供多种选择让用户发 阅读全文

摘要： 缺陷修复的目标极其明确，但有时候修复的过程涉及的只是一个孤立的代码区，因此，修复完缺陷后有必要花时间反思以下几个问题。这到底是怎么搞的？当你对缺陷怀抱这样的疑问时，尤其在修复完后依然怀抱这样的疑问时，很大程度上表明你还没有真正完全了解缺陷所揭示的东西，请继续思考下去，弄明白它究竟是怎么搞的，极可能会从中学到很多东西。哪里出了问题？这是从缺陷中吸取教训的第一步，有时候甚至需要思考，软件最开始是如何产生这个错误的呢？如果起初开发的代码中隐藏着缺陷，那么究竟发生在需求的模糊不清造成的误解上，还是架构设计的疏漏里，又或者是测试本身的缺陷还是构造造成的呢？它不会再发生了！一旦确定了错误来源，就可以采取措 阅读全文

摘要： 当问题诊断告一段落，很可能你已经完成了任务中最困难的部分了，但是，依然要小心，你必须知道，对于一个好的修复来说，不仅仅是让软件能够正常运行，你还需要为将来奠定良好的基础。缺陷修复的三个目标：修复问题，避免引入回归，维持或提高代码的整体质量（可读性、架构、测试覆盖率等）假设你的开发过程包括测试驱动（测试优先）开发，你拥有一个自动化测试框架和大量的单元测试工具，当你要对源代码进行修改的时候，这种方法确实能收到良好的效果，不仅可以用它来确保你的修复程序会解决此问题，还为它避免卷入回归提供了很好的保障。测试优先开发规则之一：直到有一个失败的测试时，才应该更改源代码。因此，你需要证明你已经拥有了通过所有 阅读全文