软件质量度量评价准则有多少条??分别是什么??谢谢!!
你好! 有N多种指标:缺陷统计数据的度量(I)所有缺陷数量的时间走势或趋势统计 (Bug Trends By Time)未被处理的缺陷按照严重程度的统计 (Active Bugs By Severity) 未被处理的缺陷按照优先程度的统计 (Active Bugs By Priority)未被处理的缺陷数量的时间走势或趋势统计 (Active Bugs Over Time)已发现缺陷的数量和已修复的缺陷的数量的比率 (Fixed/Found)。
也被称为修改率或纠错率(Fix Rate) 未处理的缺陷数量和已处理的的缺陷数量的比率 (active/resolved)已处理的被修复的缺陷数量和已处理的缺陷数量的比率(Resolved as Fixed/resolved)重新被激活的已修复的缺陷数量(Bug re-activation rate)通过测试找到的缺陷的统计(Bugs opened by testing activity)所有的缺陷按照严重程度的统计(All Bugs By Severity)新被发现的缺陷按严重程度的统计 (Opened Bugs By Severity) 已处理的缺陷按照严重程度的统计 (Resolved Bugs By Severity) 被修复的缺陷按照严重程度的统计 (Fixed By Severity)不同语言版本缺陷数量的统计(Bugs opened by Language version)被报告存在缺陷的各功能统计(Where your bugs were found)处理缺陷的平均时间的统计(Average Time to Resolve)关闭缺陷的平均时间的统计(Average Time to Close)被处理缺陷的不同结论统计(Resolved Bugs By Resolution)详细的信息你可以留下邮箱,我发给你文件!
软件复杂度的复杂度的种类
有模块、类和程序三类复杂度。
模块复杂度包含了关于模块的复杂度信息;类复杂度是针对那些使用McCabe面向对象特性的程序,它包含了关于类的复杂度信息;程序复杂度包含了关于程序的复杂度信息。
集成复杂度报告对应于三种复杂度的是三种复杂度报告。
如果一个报告的复杂度信息不只一种,那么就把这些复杂度信息组合成新的报告。
集成复杂度信息只收集一个部件及其下级的信息。
例如:如果一个程序级报告包含一个类复杂度,那么只报告组成程序的类的信息,而不包含类组成的信息。
McCabe复杂度是对软件结构进行严格的算术分析得来的,实质上是对程序拓扑结构复杂性的度量,明确指出了任务复杂部分。
McCabe复杂度包括:圈复杂度、基本复杂度、模块设计复杂度、设计复杂度、集成复杂度、行数、规范化复杂度、全局数据复杂度、局部数据复杂度、病态数据复杂度。
McCabe复杂度的用途在软件工程中,有三种使用McCabe复杂性度量的方式。
作为测试的辅助工具。
McCabe复杂性度量的结果等于通过一个子程序的路径数,因而需要设计同样多的测试案例以覆盖所有的路径。
如果测试案例数小于复杂性数,则有三种情况一是需要更多的测试;二是某些判断点可以去掉;三是某些判断点可用插入式代码替换。
作为程序设计和管理指南。
在软件开发中,需要一种简单的方式指出可能出问题的子程序。
保持子程序简单的通用方法是设置一个长度限制,例如50行或2页,但这实际上是在缺乏测试简明性的有效方法时无可奈何的替代方法。
不少人认为McCabe度量就是这样一种简明性度量。
但是要注意,McCabe度量数大的程序,不见得结构化就不好。
例如,Case语句是良结构的,但可能有很大的McCabe度量数(依赖于语句中的分支数),这可能是由于问题和解决方案所固有的复杂性所决定的。
使用者应当自己决定如何使用McCabe度量所提供的信息。
作为网络复杂性度量的一种方法。
Hall和Preiser提出了一种组合网络复杂性度量,用于度量可能由多个程序员组按模块化原理建立的大型软件系统的复杂性。
他们提出的组合度量公式为式中 C1,...,Ck是各个模块的复杂性;CN是网络复杂性;W1和W2为权值。
McCabe复杂度即可用于度量各个模块的复杂性,也可用于度量网络复杂性。
圈复杂度是用来衡量一个模块判定结构的复杂程度,数量上表现为独立路径的条数,即合理的预防错误所需测试的最少路径条数,圈复杂度大说明程序代码可能质量低且难于测试和维护,经验表明,程序的可能错误和高的圈复杂度有着很大关系。
独立路径组成的集合称为基本路径集合,独立路径数就是指基本路径集合中路径的数量。
基本路径集合不是唯一的,独立路径数也就不唯一。
因此,圈复杂度是最大独立路径数。
计算方法节点是程序中代码的最小单元,边代表节点间的程序流。
如果一个模块流程图有e条边n个节点,它的圈复杂度V(G)=e-n+2,典型的V(G)max=10。
图1中示例的圈复杂度是2。
优点避免软件中的错误倾向;指出极复杂模块,这样的模块也许可以进一步细化;度量测试计划,确定测试重点;在开发过程中通过限制程序逻辑,指导测试过程;指出将要测试的区域;帮助测试人员确定测试和维护对象;与所用的高级程序设计语言类型无关。
应用圈复杂度指出为了确保软件质量应该检测的最少基本路径的数目。
在实际中,测试每一条路经是不现实的,测试难度随着路径的增加而增加。
但测试基本路径对衡量代码复杂度的合理性是很必要的。
McCabe & Associates建议圈复杂度到10,因为高的圈复杂度使测试变得更加复杂而且增大了软件错误产生的概率。
提示:圈复杂度度量是测量在一个软件模块中的分支数目,在所有的开发周期中都要使用。
圈复杂度度量以软件的结构流程图为基础。
控制流程图描述了软件模块的逻辑结构。
一个模块在典型的语言中是一个函数或子程序,有一个入口和一个出口,也可以通过调用/返回机制设计模块。
软件模块的每个执行路径,都有与从模块的控制流程图中的入口到出口的节点相符合的路径。
“Cyclomatic”来源于非直接连接基本测试周期的数目,更重要的是,也通过直接相连的图表给出独立路径的数目。
通过图表的相关性,一个节点可到达另一个节点。
圈复杂度度量也可作为模块基本流程图路径的数目,其重点在于模块线形组合后,所产生的路径数目是最小的。
对圈复杂度的限制现在有许多好方法可以用来限制圈复杂度。
过于复杂的模块容易出错,难于理解、测试、更正,所以应当在软件开发的各个阶段有意识地限制复杂度,许多开发者已经成功地实现把对软件复杂度的限制作为软件项目的一部分,尽管在确切的数目上略微有些争议。
最初支持的数目是10,现在支持数目可达15。
但是,只应当在条件较好的情况下使数目大于10,例如开发者非常有经验,设计合乎正式标准,使用现代化的程序语言、结构程序、代码预排和先进的测试计划。
换句话说,开发团队可以选择超过10的限制数目,但是必须根据经验进行一些取舍,把精力花在比较复杂的模块上。
基本复杂度是用来衡量程序非结构化程度的,非结构成分降低了程序的质...
软件测试中什么是白盒测试 黑盒测试
白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构测试程序,通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子,测试人员依据程序内部逻辑结构相关信息,设计或选择测试用例,对程序所有逻辑路径进行测试,通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
采用什么方法对软件进行测试呢?常用的软件测试方法有两大类:静态测试方法和动态测试方法。
其中软件的静态测试不要求在计算机上实际执行所测程序,主要以一些人工的模拟技术对软件进行分析和测试;而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序,而达到发现程序错误的过程。
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。
其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
六种覆盖标准:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。
语句覆盖每条语句至少执行一次。
判定覆盖每个判定的每个分支至少执行一次。
条件覆盖每个判定的每个条件应取到各种可能的值。
判定/条件覆盖同时满足判定覆盖条件覆盖。
条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
路径覆盖使程序中每一条可能的路径至少执行一次。
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
"白盒"法是穷举路径测试。
在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。
贯穿程序的独立路径数是天文数字。
但即使每条路径都测试了仍然可能有错误。
第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。
第二,穷举路径测试不可能查出程序中因遗漏路径而出错。
第三,穷举路径测试可能发现不了一些与数据相关的错误。
如何挑选白盒测试工具 白盒测试目前主要用在具有高可靠性要求的软件领域,例如:军工软件、航天航空软件、工业控制软件等等。
白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件的测试、测试的可视化等。
对开发语言的支持:白盒测试工具是对源代码进行的测试,测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。
但是对于不同的开发语言,测试工具实现的方式和内容差别是较大的。
目前测试工具主要支持的开发语言包括:标准C、C++、Visual C++、Java、Visual J++等。
代码的覆盖深度:从覆盖源程序语句的详尽程度分析,逻辑覆盖标准包括以下不同的覆盖标准:语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖。
·语句覆盖 为了暴露程序中的错误,程序中的每条语句至少应该执行一次。
因此语句覆盖(Statement Coverage)的含义是:选择足够多的测试数据,使被测程序中每条语句至少执行一次。
语句覆盖是很弱的逻辑覆盖。
·判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖(Decision Coverage)。
判定覆盖的含义是:设计足够的测试用例,使得程序中的每个判定至少都获得一次“真值”或“假值”,或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次,因此判定覆盖又称为分支覆盖。
·条件覆盖 在设计程序中,一个判定语句是由多个条件组合而成的复合判定。
为了更彻底地实现逻辑覆盖,可以采用条件覆盖(Condition Coverage)的标准。
条件覆盖的含义是:构造一组测试用例,使得每一判定语句中每个逻辑条件的可能值至少满足一次。
·多条件覆盖 多条件覆盖也称条件组合覆盖,它的含义是:设计足够的测试用例,使得每个判定中条件的各种可能组合都至少出现一次。
显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
·修正条件判定覆盖 修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”,目前在国外的国防、航空航天领域应用广泛。
这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。
它要求满足两个条件:首先,每一个程序模块的入口和出口点都要考虑至少要被调用一次,每个程序的判定到所有可能的结果值要至少转换一次;其次,程序的判定被分解为通过逻辑操作符(and、or)连接的布尔条件,每个条件对于判定的结果值是独立的。
不同的测试工具对于代码的覆盖能力也是不同的,通常能够支持修正条件判定覆盖的测试工具价格是极其昂贵的。
嵌入式软件的测试:对于嵌入式软件的测试,我们还需要一方面进一步考虑测试工具对于嵌入式操作系统的支持能力,例如DOS、Vxworks、Neculeus、Linux和Windows CE等;另一方面还需要考虑测试工具对于硬件平台的支持能力,包括是...
软件项目管理的基本信息
书 名: 软件项目管理 作 者:覃征 出版社: 清华大学出版社 出版时间: 2009-10-1 ISBN: 9787302209485 开本: 16开 定价: 39.00元 软件项目管理是软件工程和项目管理的交叉学科,是项目管理的原理和方法在软件工程领域的应用。
本书分为基础篇、管理篇和实践篇。
基础篇介绍了软件产业和软件项目管理导论,使读者从整体上了解软件项目管理的产生背景和概貌。
管理篇以项目管理知识体系(PMBOK)为核心,围绕着软件项目的开发全过程,从软件项目需求管理、软件项目成本管理、软件项目进度管理、软件项目风险管理、软件项目配置管理、软件项目资源管理、软件项目质量管理等方面对软件项目中的管理问题进行探讨。
实践篇将需求管理、成本管理、进度管理、风险管理、配置管理、资源管理和质量管理等相对独立的领域融合在软件过程框架中,介绍了在软件项目实践中如何集中使用相关理论和技术。
其中包括Rational统一过程、敏捷软件开发和6σ软件开发。
本书可作为高等学校信息、软件、计算机科学与技术等专业的学生的教材,也可供从事软件项目管理工作的人员参考。
信息之二 书 名: 软件项目管理 开本: 16开 定价: 32.00元 《软件项目管理》系统介绍了软件项目管理的理论、方法与案例,全书共分15章,内容包括软件项目管理、组织平台、软件项目立项、软件开发过程、软件估算、软件项目计划、软件配置管理、软件质量管理、软件度量、风险管理、软件外包管理、人力资源管理与团队建设、软件知识产权管理、项目经理面临的政治、项目管理技巧。
《软件项目管理》适合软件工程及计算机相关专业的研究生使用,也可作为软件领域开发人员的参考书。
第1章 软件项目管理导论1.1 软件项目管理概述1.1.1 项目管理的发展1.1.2 什么是项目1.1.3 什么是项目管理1.1.4 项目管理环境1.1.5 软件工程与项目管理1.2 软件项目分类1.3 企业愿景1.4 项目成功需要的关键投入1.5 软件项目开发过程1.6 软件项目管理的重要性1.6.1 失控项目定义1.6.2 失控项目特征1.6.3 技术问题1.7 CMM模型1.7.1 CMM概述1.7.2 CMM的内部结构1.7.3 CMM的5个等级1.7.4 CMM中5级的发展关系 第2章 组织平台2.1 组织机构与决策机制2.1.1 组织的定义2.1.2 组织平台与项目决策2.2 常见软件组织形式2.2.1 简单的软件开发组织2.2.2 普通的软件开发组织2.2.3 较成熟的软件开发组织2.2.4 开发组织的选择与设定2.3 CMM中的组织2.3.1 CMM中的关键工作组2.3.2 物理组与逻辑组2.3.3 组织的完善与独立性2.3.4 关键角色 第3章 软件项目立项3.1 识别潜在项目3.2 产品立项3.2.1 商业目标3.2.2 产品战略3.2.3 产品的5个层次3.2.4 产品定位战略3.2.5 产品开发立项3.2.6 产品立项报告3.3 定制项目立项3.3.1 项目选择3.3.2 合同签定要注意的问题3.3.3 定制项目立项报告3.4 立项评审3.5 技术人员在立项中的责任 第4章 软件开发过程4.1 需求确定4.1.1 把握系统需求4.1.2 需求管理的实施过程4.1.3 需求变更管理4.1.4 需求分析提交的结果4.1.5 角色划分4.2 软件设计4.2.1 概要设计4.2.2 详细设计4.3 编码4.3.1 编码标准4.3.2 编码风格4.3.3 命名规则4.4 测试4.4.1 测试目标4.4.2 测试原则4.4.3 软件测试过程管理4.5 发布、部署和维护4.5.1 发布4.5.2 部署4.5.3 维护 第5章 软件估算5.1 软件估算概述5.2 估算步骤5.2.1 确定软件范围5.2.2 确定工作所需资源5.2.3 确定估算内容5.2.4 估算改进5.3 估算方法5.3.1 FP功能点估算法5.3.2 LOC估算法5.3.3 COCOMO估算法5.3.4 软件方程式估算法5.3.5 类比估算法5.3.6 wBS估算法5.3.7 Delphi估算法5.3.8 PERT方法5.3.9 估算方法的综合应用5.4 估算的表达5.5 估算的原则与技巧 第6章 软件项目计划6.1 软件项目计划的层次6.2 软件项目计划编制的方针6.3 软件项目计划的内容6.3.1 项目介绍6.3.2 技术方案概述6.3.3 过程计划6.3.4 测试计划6.3.5 组织计划6.3.6 资源计划6.3.7 软件估算与预算6.3.8 进度表6.3.9 质量计划6.3.10 风险计划6.3.11 变更管理计划6.3.12 文档计划6.3.13 培训计划6.3.14 发布与实施计划6.4 软件项目计划成功的关键要素6.5 软件项目计划模板 第7章 软件配置管理7.1 软件配置管理概述7.1.1 术语与概念7.1.2 软件配置管理定义7.1.3 软件配置管理的基础7.2 软件配置管理的活动7.2.1 制定SCM计划7.2.2 软件配置标识与维护7.2.3 软件配置控制与变更管理7.2.4 版本管理7.2.5 软件配置状态发布7.2.6 软件配置审计7.2.7 软件发布管理7.3 配置管理工具7.3.1 几种配置管理工具介绍7.3.2 配置管理工具选择7.3.3 配置管理工具实施7.4 成功的关键7.5 职责分配与角色 第8章 软件质量管理8.1 软件质量管理基础8.1 一软件质量8.1.2 软件质量需求与质量特征8.1.3 软件质量管理8.2 软件质量保证 …… 第9章 软件度量 第10章 风险管理 第11章 软件外包管理 第12章 人力资源管理与团队建设 第13章 软件知识产权管理 第14章 项目经理面临的政治 第15章 项目管理技巧 参考文献
什么是软件项目管理?
软件是程序,是控制硬件功能并指挥其运行的程序、代码和符号语言。
项目是具有明确的起止时间,明确的目标、范围和成本的一次性的工作。
它具有如下特点:(1)明确的开始、结束时间;(2)明确的目标,它规定了具有质量保证的一个或多个目标;(3)限制条件,必须是在给定的进度(时间)、成本下完成的;(4)是一次性的,一个项目不能以同样的方式重复。
管理是将一些理论知识、技能、工具和技巧应用到项目活动中去的行为或艺术。
所以,软件项目管理主要专注于软件项目活动的一些行为分析与管理。
一个项目管理需要考虑的远不止我们想象的那么多,往往需要在众多的、甚至是相互冲突的要求中寻求一种平衡,以达到满足每个团体各方面的利益:范围、时间、成本和质量有不同需求和期望的项目涉及人员明确表示出来的要求(需求)和未明确表达的要求(期望)比如,部门主管可能希望新的项目在成本方面,而系统工程师却更注重技术的完善,而市场人员却希望在尽可能短的时间内完成项目以便尽快满足市场、占有市场份额。
而项目管理者所要做的,就是夹在这不同的需求和利益中,寻求一种解决这些冲突,满足不同需要的适当的方法。
项目管理知识体系主体和项目管理过程图
软件开发难以管理的原因是什么?
你说的是软件管理吧?软件项目管理的对象是软件工程项目。
它所涉及的范围覆盖了整个软件工程过程。
为使软件项目开发获得成功,关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件/软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等做到心中有数。
这种管理在技术工作开始之前就应开始,在软件从概念到实现的过程中继续进行,当软件工程过程最后结束时才终止软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。
软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、编码到测试、维护全过程)都能在管理者的控制之下,以预定成本按期,按质的完成软件交付用户使用。
而研究软件项目管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则,方法,同时避免前人的失误。
软件项目管理的提出是在20世纪70年代中期的美国,当时美国国防部专门研究了软件开发不能按时提交,预算超支和质量达不到用户要求的原因,结果发现70%的项目是因为管理不善引起的,而非技术原因。
于是软件开发者开始逐渐重视起软件开发中的各项管理。
到了20世纪90年代中期,软件研发项目管理不善的问题仍然存在。
据美国软件工程实施现状的调查,软件研发的情况仍然很难预测,大约只有10%的项目能够在预定的费用和进度下交付。
1995年,据统计,美国共取消了810亿美元的商业软件项目,其中31%的项目未做完就被取消,53%的软件项目进度通常要延长50%的时间,只有9%的软件项目能够及时交付并且费用也控制在预算之内。
软件项目管理和其他的项目管理相比有相当的特殊性。
首先,软件是纯知识产品,其开发进度和质量很难估计和度量,生产效率也难以预测和保证。
其次,软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。
Windows这样的操作系统有1500万行以上的代码,同时有数千个程序员在进行开发,项目经理都有上百个。
这样庞大的系统如果没有很好的管理,其软件质量是难以想象的。
软件项目管理的内容主要包括如下几个方面:人员的组织与管理,软件度量,软件项目计划,风险管理,软件质量保证,软件过程能力评估,软件配置管理等。
软件测试的生命周期?
软件测试生命周期包括6个阶段(大体上): 1)计划 2)分析,3)设计,4)构建,5)测试周期,6)最后测试和实施,7)实施后。
1. 计划(产品定义阶段) ?? 高层次的测试计划(包含多重测试周期) ?? 质量保证计划(质量目标,测试标准等 ) ?? 确定计划评审的时间 ?? 报告问题过程 ?? 确定问题的分类 ?? 确定验收标准-给质量保证员和用户。
?? 建立应用程序测试数据库 ?? 确定衡量标准,例如缺陷数量/严重程度和缺陷起源(仅举几个例子) 。
?? 确定项目质量度量 ?? 开始制定项目整体测试时间表(时间,资源等) ?? 必需阶段:评审产品定义文档 ?? 文档中加入质量保证标准,作为工程改善进程的一部分 ?? 根据该产品的特点帮助确定问题的范围 ?? 大约每月要花5 -1 0小时在这一方面 ?? 计划在数据库管理所有测试用例,包括手工方面或者自动化方面。
2. 分析(外部文档阶段) ?? 根据业务需求开发功能验证矩阵。
?? 制定测试用例格式-估计时间和分配优先级。
?? 制定测试周期矩阵与时间线 ?? 根据功能验证矩阵开始编写测试用例 ?? 根据业务需求计划测试用例基准数据 ?? 确定用于自动化测试的测试用例。
?? 自动化团队开始在测试工具中创建变量文件和高层次的测试脚本。
?? 为自动化系统中的跟踪组件设置路径和自动化引导。
?? 界定压力和性能测试的范畴。
?? 按照每个测试用例的数据要求开始建立基准数据库。
?? 定义维护基准数据库的过程,即备份,恢复,验证。
?? 开始规划项目所需的测试周期数,和回归测试次数。
?? 开始文档复查,如:功能设计文档,业务需求文档,产品规格说明书,产品外部文档等。
?? 审查测试环境和实验室,前端与后端系统都要。
?? 准备使用McCabe工具,以支持白盒测试中代码的研发和复杂性分析 ?? 建立反馈机制并开始录入文档。
?? 必需阶段:审查外部文件 ?? 文档中加入质量保证标准,作为工程改善进程的一部分。
?? 根据群体执行反馈编写测试用例 ?? 开始研制测试用例估计数目,每个用例的执行时间,和用例是否自动化这些方面的度量 ?? 为每个测试用例确定基准数据, ?? 大约每月要花25小时在这一方面 3. 设计(文档架构阶段) ?? 根据变更修改测试计划 ?? 修改测试周期矩阵和时间线 ?? 核实测试计划和用例用到的数据都输入到数据库,或是否必需的。
?? 修改功能验证矩阵 ?? 继续编写测试用例,根据变化添加新的用例 ?? 制定风险评估标准 ?? 规范自动化测试和多用户测试的细节。
?? 挑选出一套用于自动化测试的测试用例,并且把这些用例脚本化 ?? 规范压力测试和性能测试的细节。
?? 最终确定的测试周期。
(根据用例的估计时间和优先权确定每个周期所用的测试用例数) ?? 最终确定的测试计划 ?? 估计单元测试所需资源 ?? 必需阶段:审查架构文件 ?? 文档中加入质量保证标准,作为工程改善进程的一部分。
?? 确定要进行编码的的实际组件或模块 ?? 在这定义单元测试标准,通过/失败准则等。
?? 单元测试报告,报告进行单元测试后的模块质量如何,白盒测试和黑盒测试都要包括输入/输出数据和所有决定点。
?? 列出所有要进行单元测试的模块 4. 构建(单元测试阶段) ?? 完成所有计划 ?? 完成测试周期矩阵和时间线 ?? 完成所有测试用例。
(手动) ?? 完成第一套自动化测试用例的测试脚本。
?? 完成压力和性能测试的计划 ?? 开始压力和性能测试 ?? McCabe工具支持-提供度量 ?? 测试自动化测试系统,并修复错误。
?? 发展单元测试 ?? 运行质量保证验收测试套件,以确保软件已经可以交给QA测试。
5. 测试周期/ 错误修正( 重复/系统测试阶段) ?? 测试周期1,执行第一套的测试用例(前端和后端) ?? 报告错误 ?? 错误审核-不断开展的活动。
?? 根据需求修改测试用例 ?? 根据需求增加测试用例 ?? 测试周期二 ?? 测试周期三 6. 最后的测试和实施(代码冻结阶段) ?? 执行所有前端测试用例-人工和自动化。
?? 执行所有后端测试案例-人工和自动化。
?? 执行所有压力和性能测试。
?? 提供对正在进行的缺陷跟踪度量。
?? 提供对正在进行的复杂性和设计的度量。
?? 更新测试用例和测试计划的估计时间。
?? 文件测试周期,回归测试,并更新相应文档。
7. 实施后 ?? 开展实施后评估会议以回顾整项工程。
(经验所得) ?? 准备最终的缺陷报告和相关度量。
?? 制定战略以防止类似的问题在今后的项目中重复出现。
?? 创建如何改进流程的计划目标和里程碑, ?? McCabe工具-制作最后的报道和分析。
?? 自动化测试组-1 )审查测试用例以评估其他可用于自动化回归测试的用例2 )清理自动化测试用例和变量,和3 )审查自动化测试和手工测试结果的整合过程 ?? 测试实验室和测试环境-清理测试环境,标记和存档用过测试用例和数据,恢复测试仪器到原始状态等。