软件质量管理实战.doc

目录第1章 缺陷综述21.1 软件缺陷的定义21.2 软件缺陷的生命周期21.3 缺陷信息31.4 软件缺陷分类31.4.1 缺陷类型31.4.2 缺陷严重程度41.4.3 缺陷优先级41.4.4 缺陷状态41.5 缺陷产生的原因51.5.1 缺陷的产生51.5.2 缺陷的来源51.5.3 缺陷的根源51.6 缺陷预防61.6.1 缺陷预防61.6.2 缺陷预防的目标61.6.3 缺陷预防的策略61.6.4 缺陷预防活动61.6.5 缺陷预防的验证61.6.6 软件质量特性的提高71.7 缺陷发现手段71.7.1 同行评审71.7.2 测试71.7.3 管理评审71.7.4 QA发现71.8 缺陷修复和沟通策略8第2章 软件测试82.1 软件测试的基本问题82.1.1 软件测试的对象82.1.2 软件测试目的82.1.3 软件测试的原则82.1.4 测试的两个重要里程碑92.1.5 测试可以发现的缺陷92.1.6 软件测试的基本方法92.2 软件测试过程92.2.1 单元测试92.2.2 集成测试102.2.3 验收测试102.3 软件测试的方法112.3.1 功能测试11第1章 缺陷综述软件产品和传统软件产品的几个不同的特性不可见性、灵活性、复杂性对于软件质量的进行评价的时候应该遵循如下原则：1） 应强调软件总体质量而不应片面强调软件的正确性，忽略可维护性、可靠性、可用性和效率等2） 应在软件的整个开发周期的各个阶段都注意软件的质量，而不能只在软件的验收阶段注重软件的质量3） 应制定软件质量的标准，不能局限于定性地评价软件的质量，应采用同行评审和度量等各种方法来定量的评价软件的质量，使软件评价走上评测结合与预防为主的科学道路。1.1 软件缺陷的定义1） 软件为达到产品说明书表明的功能2） 软件出现了产品说明书指明不会出现的错误3） 软件实现了产品说明书中为提及的功能，即超出了说明书指定的范围4） 软件未达到产品说明书虽指出但为达到的目标5） 软件测试员认为软件难于理解、不易使用、运行缓慢，或者最终用户认为不好IOS 9000对缺陷的定义为“未满足与预期或者规定用途相关的要求”1） 软件错误软件在生命周期内不希望或不可接受的人为错误，其结果导致软件缺陷的产生2） 软件缺陷存在于软件中的那些不希望或不可接受的偏差，其结果是软件运行于某一特定特定条件时将出现软件故障，称软件缺陷的激活3） 软件故障软件在运行过程中出现的一种不希望或不可接受的内部状态4） 软件失效软件在运行过程中出现的一种不希望或不可接受的外部行为结果1.2 软件缺陷的生命周期1、 简单的软件缺陷生命周期1） 发现打开2） 打开修复3） 修复关闭2、 复杂的软件缺陷生命周期详情见后页1.3 缺陷信息简要缺陷信息主要缺陷信息1.4 软件缺陷分类按动态缺陷的属性信息描述来进行1.4.1 缺陷类型表1缺陷类型缺陷类型内容说明备注系统缺陷1、 程序的死循环；2、 由于程序引起的死机，非法退出3、 程序错误，不能执行正常工作或重要的功能，使系统崩溃或资源严重不足不能执行正常工作或重要功能，使系统崩溃或资源严重不足数据缺陷1、 数据计算错误；2、 数据约束错误；3、 数据输入、输出错误严重影响系统要求或基本功能的实现， 且没有办法更正（重新安装或重启软件不属于更正办法）数据库缺陷1、 数据库发生死锁；2、 数据库的表、缺省值未加完整性等约束条件3、 数据库连接错误4、 数据库中的表有过多的错误接口缺陷1、 数据通信错误；2、 程序接口错误3、 硬件接口、通信错误功能缺陷1、 程序功能无法实现；2、 程序功能实现错误严重影响系统要求或基本功能的实现但寻在合理的更正办法（重启安装或重新启动软件不属于更正办法）安全性缺陷1、 用户权限无法实现2、 超时限制错误3、 访问控制错误4、 加密错误兼容性缺陷1、与需求配置兼容性不符合可以是情况而定性能缺陷1、 未达到预期需求目标2、 性能测试中途出现错误，导致无法继续性能界面缺陷1、 操作界面错误2、 打印内容、格式错误3、 删除操作为给出提示4、 长时间操作为给出提示5、 界面不规范使操作者不方便或遇到麻烦，但不影响执行工作功能的实现建议类缺陷1、 功能建议2、 操作建议3、 校验建议4、 说明建议建议型的改进要求1.4.2 缺陷严重程度表2缺陷严重程度的分类编号缺陷严重等级描述1致命不能执行正常工作或重要功能，或者危机他人人身安全2严重严重地影响系统要求或基本功能的实现吗，不能执行正常工作或重要功能，使系统崩溃或资源严重不足，且没有办法更正（重新安装或重启该软件不属于更正办法）3较重1、 严重影响系统的要求或基本功能的实现，不存在合理的更正办法（重新安装或重启该软件不属于更正办法）2、 操作界面缺陷3、 打印内容、格式缺陷4、 错误操作没有给出提示5、 删除确认4一般1、 操作界面不规范2、 辅助说明描述不清楚3、 长时间操作单不给用户提示、类似死机4、 提示窗口文字为采用行业术语5、 可输入区域和制度区域没有明显的区分标志6、 操作者感到不方便或者麻烦，单不影响执行工作功能或重要功能5较轻却他缺陷或建议类缺陷1.4.3 缺陷优先级1.4.4 缺陷状态编号缺陷状态描述1提交（Submitted）已提交的缺陷2打开（Open）确认“已提交的缺陷”，等待处理3拒绝（Rejected）拒绝“提交的缺陷”，不需要修复或不是缺陷4修复（Resolved）缺陷被修复5关闭（Closed）确认被修复的缺陷，将其关闭6推迟（Later）可在以后解决，但要确定修复的日期1.5 缺陷产生的原因1.5.1 缺陷的产生1、 没有正确理解客户的需求2、 开发人员按照设计要求进行开发或者编写的代码存在错误而引起的缺陷1.5.2 缺陷的来源1 需求2 设计3 编码4 测试5 集成1.5.3 缺陷的根源1 测试策略：错误的测试范围、误解测试目标、超越测试能力2 过程、工具和方法：无效的需求收集过程、过时的风险管理过程、不适用的项目管理方法、没有估算规程、无效的变更控制过程3 技术团队与个人能力：项目团队职责交叉、缺乏培训4 组织和通信：缺乏用户参与、职责不明确、管理失败5 硬件：硬件配置不对、缺乏或处理器缺陷导致算术精度丢失、内存溢出6 软件：软件设置不对、缺乏或操作系统错误导致无法释放资源、工具软件的错误、编译器的错误等7 工作环境：组织机构调整、预算改变、工作环境恶劣1.6 缺陷预防1.6.1 缺陷预防缺陷预防的目的是识别产生缺陷的原因，从而避免他们的再次发生1.6.2 缺陷预防的目标1） 软件预防活动要有计划2） 找出并标明引起缺陷的原因3） 对引起缺陷的原因划分优先级并且进行系统地优化1.6.3 缺陷预防的策略1） 根据缺陷预防目标，制定预防计划，检查与测试相结合2） 建立统一的缺陷数据库，对开发过程实时监测3） 重复发现缺陷的原因分析4） 进行Pareto分析，从缺陷检查列表中确认最基本的缺陷5） 利用趋势分析根据，选择缺陷估算模型6） 评估缺陷预防活动的有效性7） 计算进行缺陷预防的投资回报率8） 使用工具及模板1.6.4 缺陷预防活动模式软件复用重构1.6.5 缺陷预防的验证缺陷验证的具体步骤1、 收集信息2、 识别最大的问题领域3、 制定缺陷预防计划4、 制定试运行计划5、 实施试运行计划并推广6、 继续其他问题域的缺陷预防活动1.6.6 软件质量特性的提高1） 功用性：软件是否满足了客户功能要求2） 可靠性：软件是否能够在一个稳定的状态下满足功用性3） 可用性：衡量用户使用软件需要多大的努力4） 效率：衡量软件正常运行需要耗费多少物理资源5） 可维护性：衡量对已完成的软件继续调整需要多大的努力6） 可移植性：衡量软件是否能够方便地部署到不同的运行环境中1.7 缺陷发现手段1） 进过对需求规格说明书、设计说明书等工作产品的走查、评审发现2） 由编写代码的开发人员发现3） 在代码变异的过程中发现4） 由尝试运行代码的开发人员发现5） 有专职的质量保证人员发现6） 由组中的其他开发人员或测试人员发现7） 由产品大规模测试发现8） 由最早用户发现1.7.1 同行评审在工作产品开发过程中为了识别缺陷由同行开展对工作产品的评审1.7.2 测试软件测试不仅仅是为了找出错误，通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程缺陷，以便改进。1.7.3 管理评审目的：解决管理问题，为管理行动提供信息1.7.4 QA发现PPQA产品过程质量保证，既保证产品过程又需要保证产品质量1） 客观的评价执行的过程、工作产品以及服务2） 标识记录不符合性问题3） 将质量保证活动结果向开发人员和管理人员汇报4） 跟着不符合性问题直至解决1.8 缺陷修复和沟通策略并非所有的缺陷都被修复或者都要被修复的：1） 产品最终发行或者项目交付由明确的时间期限限制2） 缺陷报告中提出的问题难以重现3） 修复缺陷将影响较多的模块，带来的风险比较大，可能会加剧产品的不稳定性4） 修复缺陷的性价比过低第2章 软件测试2.1 软件测试的基本问题2.1.1 软件测试的对象1） 源代码或目标程序2） 各开发阶段的文档（需求规格说明、概要设计说明、详细设计说明及其他相关文档）2.1.2 软件测试目的1） 用户角度看目的：通过软件测试发现隐藏的错误或缺陷，考虑是否接受该产品2） 开发者角度：表明软件产品不存在错误，验证软件实现了产品的所有功能3） 测试人员角度：发现错误、预测错误，提供软件可靠性数据4） 软件测试根本目的：一是发现错误，而是通过测试发现的错误不断改进软件开发过程中存在的缺陷2.1.3 软件测试的原则1） 开发和测试分立，由独立的专门的测试小组来进行整体测试工作2） 对程序修改之后要回归测试3） 尽早和不断进行软件测试，特别是由小到大的增量测试4） 测试用例应包含测试输入和预期输出结果，要兼顾有效输入和无效输入。无效输入的是指异常的、临界的、可能引起问题变异的输入条件5） 充分注意测试的集群现象，测试后程序残余的错误数目和该程序中已经发现的错误数目或者检出率称正比6） 所有的软件测试都应追溯的用户需求7） 写测试用例和执行测试用例的人应尽量分开8） 完全的测试时不可能的，测试无法找出软件潜在的所有缺陷，测试需要终止9） 应当对每一个测试结果做出错误统计和分析10） 妥善保存测试计划、测试用例、出错统计和最终分析报告为维护提供方便2.1.4 测试的两个重要里程碑功能冻结：本版本只提供产品需求规格说明书中提到的确定要做的功能，其他功能放到后续的版本中考虑代码冻结：软件通过测试周期，逐渐稳定，修复工作逐渐减少，可实现代码冻结2.1.5 测试可以发现的缺陷1） 通过调试过程开发人员可以进行缺陷自测2） 通过单元测试可以发现代码中的缺陷3） 通过黑盒测试发现功能设计上的缺陷4） 在理想状态下，测试用例如果设计的足够完善，可以发现全部缺陷2.1.6 软件测试的基本方法1 白盒测试通过检查内部操作是否符合设计说明书的要求，所有内部成分是否已经通过检查，白盒测试也成结构测试或逻辑驱动测试白盒测试时穷举路径测试，主要方法有逻辑驱动、基路测试2 黑盒测试已知产品的功能设计规格，通过测试证明每个功能是否符合要求，着眼于外部程序，针对软件界面和软件功能进行测试，主要有等价类划分、边界值分析、因果图、错误推测2.2 软件测试过程软件测试分为单元测试、集成测试、系统测试、验收测试2.2.1 单元测试单元测试主要采用白盒测试用例，辅助以黑盒测试用例，对模块内所有重要的控制路径设计测试用例测试用例是为达到最佳测试效果或高效地揭露隐藏的错误，而精心设计具有代表性或特殊性的少量测试数据，好的测试用例在于发现了至今为止未发现的错误1 单元测试的内容1） 模块借口测试模块借口测试使单元测试的基础，只有数据能正确输入输出后，其他测试才有意义，需考虑一下因素：Ø 调用所测模块是输入的实际参数和形式参数在个数、属性和顺序上是否匹配Ø 所测模块调用子模块时，输入给子模块的实际参数与子模块的形式参数在个数、属性和顺序上是否匹配Ø 是否修改了只做输入用的形式参数Ø 输出给标准函数的参数在个数、属性和顺序上是否匹配Ø 对全局变量的定义各模块是否一致Ø 是否把某些约束作为形式参数传递2） 局部数据测试检查局部数据使为了保证临时存储在模块内的数据在程序执行过程中是否完整、正确Ø 不正确或不一致的数据说明；Ø 使用没有赋值或没有初始化的变量Ø 不争取的初始值或缺省值Ø 变量名拼错或写错Ø 不一致的数据类型Ø 出现上溢、下溢和地址异常3） 边界条件测试4） 独立路径测试5） 错误处理测试2 单元测试的环境3 单元测试的工具2.2.2 集成测试1 集成测试考虑的问题1） 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失2） 组装模块的时候是否会对另一模块的功能产生不利的影响3） 各个子模块组装起来，能达到预期要求的父功能4） 全局数据结构是否有问题2 集成的方式“一次性集成”“增量式集成”2.2.3 验收测试也成确认测试，目的在于确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务，验收系统是否确实能提供系统方案说明书中的功能和性能包括系统测试“Alpha测试”和“Beta测试”“Alpha测试”由用户在开发者的场所进行，开发者负责记录发现的问题“Beta测试机”由用户在使用者的多个场所进行，用户记录发现的问题，报告给开发者。“Alpha测试”是可控的，“Beta测试”使不可控的2.3 软件测试的方法2.3.1 功能测试1 基于图形用户界面程序的功能测试GUI界面下软件的功能：文本内容、窗口属性、控件状态；检查用户和软件的交互能力；检查GUI对象操作是否与用户要求相符2 非GUI应用程序的功能测试第3章 经验教训库3.1 同行评审经验库项目名称项目编号检查人检查日期检查项： 项；有效检查项：_项；通过项：_项；通过率：_序号检查项通过情况情况说明标准化101有规定的文档标识是 否 免 102引用的文档现行有效是 否 免 103文档编写的内容、格式符合相关标准是 否 免 104是 否 免 105是 否 免 是 否 免 是 否 免 是 否 免 是 否 免 是 否 免 是 否 免 是 否 免 是 否 免 是 否 免