摘要: 本章主要内容有:什么时候修复缺陷?调试的思维模式自己如何解决质量问题早期修复缺陷基于两个原则:1. 那些可能发现缺陷的过程(测试、代码审查、用户使用)要连续贯穿于整个开发过程中2. 缺陷修复优先于其他任何事情目的:保证软件中存在的缺陷数量尽可能少。早期的缺陷检测和修复能帮助你估算在缺陷修复上大约需要多少时间并以此来修改测试计划。调试时一种心理活动。爱丽丝:再试也没用,人们不可能去相信不可能发生的事。怀特女王:我敢说你练的还很不够,我在你这么大的时候,每天做它半小时,有时在早餐前,我就相信有不可能的事情要发生。缺陷是不可避免的,无论多么努力,总会遗漏一些问题,因此不必去担心缺陷的发生,接受总会有 阅读全文
posted @ 2013-02-22 17:00 Ribbon 阅读(327) 评论(0) 推荐(0) 编辑
摘要: 之前的部分我们都假定已经知道软件存在缺陷,那么在这一章中,我们要看看在此之前,需要做什么呢?本章重点讲述三方面内容:缺陷追踪:使用缺陷追踪系统获取它所提供的信息,当发现缺陷时,记录下具体的,明确的,最小化的,唯一的缺陷报告,通过软件增加选项来自动收集环境和配置信息。与用户合作:用户很少会花时间来报告缺陷,即使报告了也不能保证缺陷的高质量,但我们可以简化整个流程来让用户帮助我们获得关于缺陷的更多信息。1. 在About对话框中,或者在线帮助网站等地方向用户解释如何报告缺陷2. 安装顶层的异常处理程序,给用户发送缺陷报告选项,记录下相关细节,比如office发送报告对话框3. 提供多种选择让用户发 阅读全文
posted @ 2013-02-22 16:10 Ribbon 阅读(368) 评论(0) 推荐(0) 编辑
摘要: 缺陷修复的目标极其明确,但有时候修复的过程涉及的只是一个孤立的代码区,因此,修复完缺陷后有必要花时间反思以下几个问题。这到底是怎么搞的?当你对缺陷怀抱这样的疑问时,尤其在修复完后依然怀抱这样的疑问时,很大程度上表明你还没有真正完全了解缺陷所揭示的东西,请继续思考下去,弄明白它究竟是怎么搞的,极可能会从中学到很多东西。哪里出了问题?这是从缺陷中吸取教训的第一步,有时候甚至需要思考,软件最开始是如何产生这个错误的呢?如果起初开发的代码中隐藏着缺陷,那么究竟发生在需求的模糊不清造成的误解上,还是架构设计的疏漏里,又或者是测试本身的缺陷还是构造造成的呢?它不会再发生了!一旦确定了错误来源,就可以采取措 阅读全文
posted @ 2013-02-22 13:44 Ribbon 阅读(222) 评论(0) 推荐(0) 编辑