缺陷预防实施方案.docx

缺陷预防实施方案1. 概述什么是缺陷预防，就是说能把缺陷消灭在萌芽状态，就是能在缺陷还没产生出来就已经被扼杀了。一般的软件测试属于后来弥补型，产生bug之后再来修改，但是bug发现越晚，修改掉花的代价就越大，所以软件缺陷预防技术就是项目生命周期的早期消灭bug。我们很多人对缺陷预防的理解存在着误区，我们仅把缺陷预防作为了编码之前的一个简单的活动。其实缺陷预防应该是贯穿整个软件生命周期的（后期的项目分析阶段其实是下一个项目最早期的缺陷预防）。缺陷预防并不仅仅是开发人员在编码之前从事的活动，而应该是项目组所有成员贯穿软件生命周期各个阶段的一项活动。1.1 缺陷与错误分布通过对缺陷分布情况的仔细分析，可以帮助我们确定实施缺陷预防的重点阶段。下图为项目各阶段缺陷分布情况。从上图中我们不难看出开发早期的错误是非常多的，83%的缺陷集中在需求和设计阶段。所以我们应该把缺陷预防的主要精力放在需求和设计阶段。2. 各阶段具体实施方案介绍2.1 需求阶段具体实施方案1. 需求人员加强与客户之间的沟通，需求说明书的编写应遵循以下8大原则：原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。 原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。原则4：规格说明必须包括系统运行的环境。原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。原则7：规格说明必须容许不完备性并允许扩充。原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落(理想情况)。同时，规格说明应被松散地构造(即耦合)，以便能够很容易地加入和删除一些段落。2. 各评审人员严格按照需求评测规范进行评审编 号评 测 项评测结果清晰性1系统的目标是否已定义2是否对关键术语和缩略语进行定义和描述3所使用的术语是否和用户/客户使用的一致4需求的描述是否清晰，不含糊5是否有对整套系统进行功能描述6是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置）7如果有会影响实施的假设情况，是否已经声明8是否已经对每个业务逻辑进行输入、输出以及过程的详细说明完整性9是否列出了系统所必须的依赖、假设以及约束10是否对每个提交物或阶段实施都进行了需求说明11需求说明书是否已包含了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测性（此范围比较广，包括性能指标、需求是否遗漏、重复或不一致的地方等）依从性12该文档是否遵守了公司规定的文档编写标准一致性13需求说明是否存在直接相互矛盾的条目14本需求说明书是否与相关需求素材一致可行性15所描述的所有功能是否必要并充分地满足客户/系统目标16需求规格说明书描述的详细程度是否足以满足进行详细设计17已知的限制（局限）是否已经详细说明18是否已确认每个需求的优先级别可管理性19是否将需求分别陈述，因此它们是独立的并且是可检查的20是否所有需求都可以回溯到相应的需求素材，反之亦然21是否已详细说明需求变更的过程3. 项目组成员协调客户完成对需求的评审确认2.2 设计阶段具体实施方案设计阶段，这个阶段主要通过技术评审测试逻辑设计。常用比较规范的作法是建立过程/数据矩阵，也就是CRUD矩阵，把过程影射到实体，把整个程序的数据的生命周期（建立，更新，读取，删除）反映出来。2.2.1 概要设计评审内容及规范概要设计文档的评审范围：1.可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成分是否可追溯到某一项需求。2.接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。3.风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。4.实用性：即确认该软件设计对于需求的解决方案是否实用。5.技术清晰性：即确认该软件设计是否以一种易于翻译成代码的形式表达。6.可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。7.质量：即确认该软件设计是否表现出良好的质量特征。8.各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。9.限制：评估对该软件的限制是否实现，是否与需求一致。10.其他具体问题：对于文档、可测试性、设计过程等进行评估。为评测设计是否达到目标，建立衡量设计的技术标准，如下：1.设计出来的结构应是分层结构，从而建立软件成分之间的控制。2.设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构建。3.设计应当既包含数据抽象，也包含过程抽象。4.设计应当建立具有独立功能特征的模块。5.设计应当建立能够降低模块与外部环境之间复杂连接的接口。6.设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。编号评测项评测结果清晰性1是否所设计的架构，包括数据流、控制流和接口，被清楚的表达了2是否所有的假设、约束、策略及依赖都被记录在本文档了3是否定义了总体设计目标完整性4是否所有的以前的TBD（待确定条目）都已经被解决了5是否设计已经可以支持本文档中遗留的TBD有可能带来的变更6是否所有的TBD的影响都已经被评估了7是否仍存在可能不可行的设计部分8是否已记录设计时的权衡考虑，该文件是否包括了权衡选择的标准和不选择其他方案的原因依从性9该文档是否遵守了公司规定的文档编写标准一致性10数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致11该设计是否反映了实际操作环境（硬件、软件和支持软件）可行性12从进度、预算和技术的角度上看该设计是否可行13是否存在错误的、缺少的或不完整的逻辑数据使用14所有复合数据元素、参数以及对象的概念是否都已文档化15是否还有任何需要的，但还没有定义的数据结构，反之亦然16是否已描述最低级别的数据元素，是否已详细说明取值范围功能性17是否对每一下级模块进行了概要算法说明18所选择的设计和算法能否满足所有需求接口19操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）20是否已描述界面的功能特性21界面将有利于问题的解决吗22是否所有界面都互相一致，与其他模块一致，以及和更高级别文档只中的需求一致23是否所有的界面都提供了所要求的信息24是否已说明内部各界面之间的关系25界面的数量和复杂程度是否已减少到最小可维护性26该设计是否是模块化的27这些模块具有高内聚度和低耦合度吗28是否已经对继承设计、代码或先前选择工具的使用进行了详细说明性能可靠性29该设计是否能够提供错误检测和恢复吗（例如：输入输出检查）30是否已考虑非正常的情况31是否所有的错误情况都被完整并准确地说明32该设计是否满足该系统进行集成时所遵守的约定易测性33是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的34该套系统是否能用增量型的方法来集成和测试可追溯性35是否各部分的设计都能追溯到需求说明书的要求36是否所有的设计决策都能追溯到原来确定的权衡因素37所继承设计的已知风险是否已确定和分析2.2.2 详细设计评审规范编号评测项评测结果清晰性1所有单元或过程的目的都已文档化2包括了数据流、控制流和接口的单元设计是否已清晰的说明完整性3是否已定义和初始化所有的变量、指针和常量4是否已描述单元的全部功能5是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）6是否已列出该单元的调用依从性7该文档是否遵守了公司规定的文档编写标准8是否采用了所要求的方法和工具来进行单元设计一致性9数据元素的命名和使用在整个单元和单元接口之间是否一致10所有接口的设计是否相互一致并且和更高级别文档一致正确性11是否处理所有条件（0、=0、0、switch/case），是否存在处理“case not found”的条件12是否正确的规定了分支（逻辑没有颠倒）数据使用13是否所有声明的数据都被实际使用到14是否所有该单元的数据结构都被详细说明15是否所有修改共享数据（或文件）的程序都考虑到了其他程序对该共享数据（或文件）的存取权限16是否所有逻辑单元、时间标志和同步标志都被定义和初始化接口17接口参数在数量、类型和顺序上是否匹配18是否所有的输入和输出都被正确定义和检查19是否传递参数序列都被清楚的描述20是否所有参数和控制标志由已描述的单元传递或返回21是否详细说明了参数的度量单位、取值范围、正确度和精度22共享数据区域及其存取规定的映射是否一致可维护性23单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其他单元的影响很小性能24是否该单元的所有约束（例如：过程时间和规模）都被详细说明可靠性25初始化是否使用到缺省值，缺省值是否正确26是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置27是否执行输入、输出、接口和结果的检查28是否对所有错误情况都发出有意义的信息29对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配30是否考虑到意外事件易测性31是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的32该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）33是否所有的逻辑都能被测试34是否已描述测试程序、测试数据集和测试结果可追溯性35是否设计的每一部分都能追溯到其他项目文档的要求，也能追溯到更高级别文档的要求36是否所有的设计决定都能追溯到权衡考虑37单元需求是否都能上溯到更好级别的文档，更改级别文档的需求是否已经在单元中体现2.3 编码阶段具体实施方案编码阶段，这个阶段预防措施主要有统一编码规范，代码评审，常见编码错误规避，单元测试。统一代码规范一般是开发经理统一要求，代码评审则是互相评审或者开发 leader进行评审，最后最重要的则是单元测试，就是一般说的白盒测试。3. 缺陷分析缺陷分析对于缺陷预防的实施有着非常大的影响，是实施缺陷预防的重中之重。所以我觉得在这里深入描述一下缺陷分析的方法很有必要。1.模块的缺陷分布，一般用柱状图或饼状图，就是每一个功能模块发现bug的比例，发现bug最多的模块证明在发布以后需要更多的维护。另外，历史数据可以参照，譬如上一个版本在哪个模块发现的bug比例对这个版本就是一个参考。如果，某个模块发现bug的比例比上个版本大幅下降，则很可能说明该模块还需要更多测试。2.缺陷的起因分布，一般用柱状图或饼状图，一般可分为架构缺陷、功能缺陷、易用性缺陷、性能缺陷、安全性缺陷、界面文字缺陷。一般如果架构缺陷占的比例较大，则说明设计有很大问题。3.按照不同发现人员的缺陷分布，一般用柱状图或饼状图，一般分为测试人员发现，开发人员发现，beta测试发现，外部客户发现。如果测试人员发现的 bug低于某个比例，证明质量保证测试不足。4.按照不同方式的缺陷分布 ，一般有需求审查，设计测试，代码走查，JAD，手工测试，自动化测试，白盒测试。一般来说，如果通过需求审查，设计测试，代码走查，JAD发现的bug 比重很低则说明测试前期重视不够，另外，在手工测试和自动化测试之间的比例也能说明自动化测试的贡献度。5.缺陷差额分析，就是已经发现的和已经解决的曲线关系，以时间为横轴，两者越接近说明产品质量越高。6.按照时间段的缺陷分布，一般用时间为横轴的曲线图表示，主要说明在哪个阶段发现的bug最多，对测试总结有指导意义。4. 总结综上所述，缺陷预防的核心思想是尽可能早地发现问题、解决问题，将问题消灭在萌芽状态，从而达到降低软件成本的目的（早期修复缺陷的成本远低于后期修复的成本）。关键在于加大客户需求、软件需求、概要设计、详细设计的评审力度，在于测试总结。结合本公司实际情况，总结出一下几条：1. 做好需求收集整理工作2. 提高文档质量，达到文中描述的标准3. 加大前期的评审力度，不要仅仅是停留在走流程表面4. 代码实现按照文档来，切忌随心所欲，否则还要前面的文档阶段干什么呢，那不是浪费工时吗？5. 采用专业的、正确的白