1目的
为软件测试工作提供指导。
2范围
适用于软件单元测试、集成测试、确认测试和系统测试。
3术语定义
缺陷（Bug）：缺陷是对软件产品预期属性的偏离现象。
覆盖率（Coverage rate）：语句覆盖率、测试用例执行覆盖率，测试需求覆盖率等的总称。
4软件测试基础
4.1测试的定义
软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。
4.2测试的原则
a)尽早地和不断地进行软件测试；
b)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；
c)程序员应避免检查自己的程序；
d)在设计测试用例时，应当包括合理的输入条件和不合理的输入条件；
e)充分注意测试中的群集现象；
f)严格执行测试计划，排除测试的随意性；
g)应当对每一个测试结果做全面检查；
h)妥善保存测试计划，测试用例，Bug统计和最终分析报告，为维护提供方便。
4.3测试信息流
测试过程需要三类输入：
软件配置：包括软件需求规格说明、软件设计规格说明、源代码等；
测试配置：包括测试计划、测试用例、测试驱动程序等；
测试工具：测试工具为测试的实施提供某种服务。
测试之后，用实测结果与预期结果进行比较。如果发现出错的数据，就要进行调试。对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。
如果测试发现不了错误，那么可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用中发现，并在维护时由开发者去改正。
4.4测试与软件生命周期各阶段的关系
软件开发过程是一个自顶向下，逐步细化的过程，而测试过程则是依相反的顺序安排的自底向上，逐步集成的过程。低一级测试为上一级测试准备条件。参看图4.1，首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷；再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误；随后再对照需求，进行确认测试。最后从系统全体出发，运行系统，看是否满足要求。
图4.1
4.5测试的过程与策略
软件测试的主要工作是在项目或产品系统集成时进行测试，但是软件测试人员需要在项目及产品的需求调研阶段就应该进入，进入的目的主要是熟悉项目及产品的相关需求，流程，功能特点以及项目的整体进度，为后续的系统测试阶段做准备工作。主要工作内容是参加需求和开发人员的评审工作，有效的与需求和开发人员进行沟通，来获取测试所需要的各种文档和项目及产品知识。
倘若测试人员没有参与需求调研，那么必须仔细阅读系统需求相关文档，弄懂业务（或通过需求工程师的讲解，培训来获取）。时间允许最好能做统一的系统业务培训。
在这里我们将软件测试分为五大阶段：其中包括：单元测试、代码评审、代码集成测试、数据库完整性测试、系统集成测试。
(一)单元测试
单元测试是使用Junit测试框架，每次重构系统之后，必须保证所有单元测试通过，以避免因为重构导致的缺陷。单元测试对于功能性方法应达到100%的测试覆盖率。
Ø定义
单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。
Ø测试准入条件
✧《UML设计图》，其中包括：用例图、类图、时序图。
✧《单元测试范围》，其中包括：类、接口、方法、变量、输入参数、输出参数。
Ø测试环境：
✧单元测试的环境与开发环境一致。如图所示：代码开发是用MYEclipse（8.0.0）
✧MYEclipse（8.0.0）打开步骤（详细请参见：系统单元测试操作手册）：
Ø测试的职责划分
单元测试由开发组完成。
Ø质量控制
测试用例评审（类、方法的覆盖率）
Ø测试方案
✧测试依据：
测试的覆盖种类：
✓语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。
✓判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。
✓条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。
✓判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。
✓条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。
✓路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。
单元测试方案主要有条件测试，基本路径测试，循环测试。通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。
✧测试手段：
使用Junit单元测试工具。
✧测试内容及步骤：
在组件设计结束后，由设计人员定义单元测试的范围及具体内容。
统一测试框架（见环境搭建）。
建立测试程序，其中包括三个部分：数据准备区、测试准备区、测试区。其中数据准备区中确定被测函数的输入数据、成员变量、局部变量。测试准备区明确桩程序、预期值等。测试区中则调用被测函数。
执行单元测试，并修改测试中发现的问题，定期生成单元测试报告。
Ø测试完成标准
✧按照单元测试用例完成了单元测试；
✧源代码符合编程规范；
✧单元测试、代码评审应覆盖所有代码（可不包括复用的代码）。
✧缺陷清除率达到100%。
Ø测试的提交物
✧单元测试用例评审报告
✧单元测试范围定义
✧单元测试代码
(二)代码评审
代码评审通过走查、审查的方式，对产品组件的最小单位模块进行检查，发现各类缺陷。
Ø测试准入条件
《功能权限编码规范》
《命名规范》，其中包括：应用程序命名规范、变量命名规范、应用程序注释规范。
Ø测试环境：
✧代码评审的环境与开发环境一致。如图所示：代码开发是用MYEclipse（8.0.0）
Ø测试的职责划分
代码审查由开发组完成。
Ø质量控制
代码评审（程序覆盖率）
Ø测试方案
✧测试依据：
程序算法、编程思路是否清晰、无代码冗余，真正符合编码规范。
包名、类名、变量名、程序注释是否符合命名规范。
✧测试手段：
代码走查、代码审查。
严格按照：
✓《编码规范》，其中包括，程序算法、编程思路、代码冗余。
✓《命名规范》，其中包括：应用程序命名规范、变量命名规范、应用程序注释规范，进行代码走查、代码审查。
✧测试内容及步骤：
在组件设计结束后，由设计人员定义代码评审的范围及具体内容。
执行代码评审，并修改评审中发现的问题，定期生成代码评审报告。
Ø测试完成标准
按照代码评审范围完成代码评审；
源代码符合编程规范；
各基类和存储过程的正常值测试全部通过；
各基类和存储过程的异常值测试通过率达85%以上；
缺陷清除率达到100%。
Ø测试的提交物
代码评审范围定义
代码评审报告
代码检视表（开发人员交叉测试产生）
(三)组件集成测试
Ø集成测试必备文档
《接口详细描述文档》
Ø集成测试定义
代码集成测试集中在检查软件设计的几个单位模块上的组合，通过测试发现模块间的接口、业务功能与定义的功能、接口说明是否符合、以及其他的编码错误。
Ø测试环境：
开发组完成部分（或全部）编码与单元测试，形成了较稳定的可测试软件版本；
集成测试由开发人员完成；
集成测试代码和单元测试代码一样放在目标测试项目下的测试工程文件夹下；
根据需要还要添加集成测试所需要的jar包；
测试接口方法：
✓获得接口指针，逐个调用接口函数验证其正确性；
✓如果接口函数没有参数，测试返回值，纯虚函数要在继承的类中重载，不然不能生成类的实例，没有办法生成实例，不存在动态测试的问题， 只能检查代码做静态测试；
Ø测试的职责划分
代码集成测试由开发组完成。
Ø质量控制
测试用例评审（接口、类、方法的覆盖率）
Ø测试方案：
✧测试依据：
集成测试的实施方案有很多种，如自底向上集成测试、自顶向下集成测试、Big-Bang集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。在现代复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行，自底向上的集成测试方案在采用传统瀑布式开发模式的软件项目集成过程中较为常见，在此我们只介绍核心系统先行集成测试和高频集成测试相结合的方式
核心系统先行集成测试
核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。其步骤如下：
步骤一：对核心系统中的每个模块进行单独的、充分的测试，必要时使用驱动模块和桩模块;
步骤二：对于核心系统中的所有模块一次性集合到被测系统中，解决集成中出现的各类问题。在核心系统规模相对较大的情况下，也可以按照自底向上的步骤，集成核心系统的各组成模块。
步骤三：按照各外围软件部件的重要程度以及模块间的相互制约关系，拟定外围软件部件集成到核心系统中的顺序方案。方案经评审以后，即可进行外围软件部件的集成。
步骤四：在外围软件部件添加到核心系统以前，外围软件部件应先完成内部的模块级集成测试。
步骤五：按顺序不断加入外围软件部件，排除外围软件部件集成中出现的问题，形成最终的用户系统。
方案点评：该集成测试方法对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件，核心软件部件应具有较高的耦合度，外围软件部件内部也应具有较高的耦合度，但各外围软件部件之间应具有较低的耦合度。
高频集成测试
高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。使用高频集成测试需要具备一定的条件：可以持续获得一个稳定的增量，并且该增量内部已被验证没有问题;大部分有意义的功能增加可以在一个相对稳定的时间间隔（如每个工作日）内获得，测试包和代码的开发工作必须是并行进行的，并且需要版本控制工具来保证始终维护的是测试脚本和代码的最新版本，必须借助于使用自动化工具来完成。高频集成一个显著的特点就是集成次数频繁，高频集成测试一般采用如下步骤来完成：
步骤一：选择集成测试自动化工具。如很多Java项目采用Junit+Ant方案来实现集成测试的自动化，也有一些商业集成测试工具可供选择。
步骤二：设置版本控制工具，以确保集成测试自动化工具所获得的版本是最新版本。如使用SVN进行版本控制。
步骤三：测试人员和开发人员负责编写对应程序代码的测试脚本。
步骤四：设置自动化集成测试工具，每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试，并将测试报告汇报给开发人员和测试人员。
步骤五：测试人员监督代码开发人员及时关闭不合格项。
按照步骤三至步骤五不断循环，直至形成最终软件产品。
方案点评：该测试方案能在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。
✧测试手段：
使用Junit单元测试工具；
✧测试内容及步骤：
统一测试框架（见环境搭建）。
选择核心业务流程序列
;;建立的测试程序都包括三个部分：数据准备区、测试准备区、测试区。其中数据准备区中确定被测函数的输入数据、成员变量、局部变量。测试准备区明确桩程序、预期值等。测试区中则调用被测函数。
执行自动化的集成测试：运行测试脚本自动执行代码集成测试。并使用测试报告生成器生成每日集成测试报告。
回归测试：对修改后的集成序列执行回归测试。
评估测试：测试人员根据测试结果、评估集成测试。
Ø测试完成标准
按照集成测试方案完成了集成测试；
编写的测试代码要符合开发语言的编程规范；
各基类和存储过程的正常值测试全部通过；
联调测试各接口没有问题；
各基类和存储过程的异常值测试通过率达85%以上；
测试用例的覆盖率达到100％；
缺陷清除率达到100％；
Ø测试的提交物
代码集成测试计划
代码集成测试序列单
代码集成测试用例
代码集成测试用例评审报告
(四)数据和数据库完整性测试
Ø测试定义
针对数据库设计的测试。
Ø测试准入条件
《数据库建模》（建议使用：Sybase PowerDesigner）
《数据库创建规则》：其中包括：数据库命名规范、表，字段命名规范字段类型规范等。
Ø测试的职责划分
数据和数据库完整性测试由开发组负责；
Ø测试方案
✧测试手段：
测试人员通过写Sql语句来批量执行测试；
通过企业管理器（等工具）对表直接进行增删改查操作；
可根据《详细参见：ORACLE SQL性能优化》来优化程序中SQL语句。
✧测试内容及步骤：
测试数据库、表、字段的命名规范，不同的数据库对命名规范有要求。不规范的命名可能导致数据库无法创建；
针对不同的字段类型、字段大小正确性、合法性检测；
一些特殊的非空字段、自增长的数据类型进行测试；
主外键关系、约束关系测试；
对于触发器、索引的效率测试；
Ø测试完成标准
✧按照测试方案完成了测试；
✧测试用例对需求的覆盖率达到100％；
✧严重、一般缺陷清除率达到100％；
✧轻微、建议缺陷清除率达到90％；
Ø测试的提交物
✧测试计划
✧测试用例
✧测试SQL脚本
✧测试报告
(五)系统测试
1.功能模块测试
Ø测试定义
根据版本号进行集成构建测试，针对页面、表单、边界数据测试、单功能点、简单的业务流程的测试。
Ø测试准入条件
《需求规格说明书》
《数据库建模》
《详细设计说明书》
《界面规范》
Ø测试的职责划分
系统集成的功能测试由测试组负责；
Ø质量控制
用例评审（功能点的覆盖率）
Ø测试方案
✧测试手段
选择测试工具进行全自动、半自动回归测试；（注：引入自动化测试，须满足《QTP自动化测试方案》文档中3.5 引入自动化测试的标准）
手工测试
✧测试内容及步骤
页面布局、易用性、美观程度测试
✓页面布局合理、显示风格统一、色调协调、美观大方符合客户公司的企业文化。
链接测试
✓测试所有链接是否按指示的那样确实链接到了该链接的页面；
✓测试所链接的页面是否存在
✓保证Web应用系统上没有孤立的页面
表单测试
✓测试提交操作的完整性。
✓校验提交给服务器的信息的正确性、逻辑性。
✓服务器响应请求后传输信息、存取信息、显示信息、提示信息的正确性和准确性
✓表单中不同输入框的边界数据的测试：检查可编辑性、检查分界条件、检查有效分界符、检查无效字符的输入、检查多余空格的截取等。
单功能点测试
简单业务流程测试
Ø测试完成标准
✧按照测试用例完成了测试；
✧基本流程能够通畅的完成，核心功能可以体现；（不存在一、二级BUG）
✧对具备分支的流程，确保有一种分支可以持续使用，另外几种要求可以体现设置方法和直接效果，否则就应暂时屏蔽分支功能；
✧基本界面符合术语规范，不存在错误或明显歧义；所有可使用的流程中的界面设计工作必须完成；
按照标准流程没有出现各种非正常提示；
关键流程和流程中的基本数据备份恢复没有问题；
所有报表能够在基本数据的基础上正确生成；
非一，二级BUG的遗留数不能超过总用例数的5%
✧严重、较严重缺陷清除率达到100％；
✧一般、轻微缺陷清除率达到80％；
Ø测试提交物
✧测试用例
✧测试报告
✧用例评审报告
✧BUG跟踪列表（附错误抓图）
✧BUG汇总分析
2.业务流程功能测试
Ø测试定义
针对整个系统的业务流程的测试，集中功能测试。
Ø测试准入条件
《UML设计图》，其中包括：用例图、类图、时序图。
《需求规格说明书》
《数据库建模》
Ø测试的职责划分
系统测试由测试组负责；
Ø质量控制
测试用例评审（功能点的覆盖率）
Ø测试方案
✧测试手段
选择依据测试脚本执行手工测试
选择测试工具进行全自动、半自动回归测试；
✧测试内容及步骤
根据系统的业务情况，进行业务分类的同步测试。
一般业务测试
涉及的业务类型包括：
✓测试模块
✓测试业务流程
✓预计测试用例数量；
特殊业务测试
涉及的业务类型包括：
✓测试模块
✓测试业务流程
✓预计测试用例数量；
Ø测试完成标准
✧按照测试脚本、测试方案完成了测试；
✧测试用例对需求的覆盖率达到100%；
✧严重、一般缺陷清除率达到100％；
✧轻微、建议缺陷清除率达到90％；
Ø测试的提交物
✧测试用例
✧测试报告
✧用例评审报告
3.性能测试
Ø测试定义
用户的非功能需求的测试。
Ø测试准入条件
《性能指标定制》
Ø测试的职责划分
性能测试由测试组负责；
Ø测试方案
✧测试手段
选择性能测试工具实现性能测试；
开发测试脚本实现性能测试；
✧测试内容及步骤
确定性能测试指标：
✓用户容量（系统的最大注册用户数）；
✓系统负载（最大负载、最小负载、）；
✓网络带宽；
✓并发的用户数；
✓典型事务的响应时间；
✓稳定运行时间：在指定的事务数、指定的负载用户下、稳定运行时间；
根据性能测试指标，选择一个业务场景：
✓登录业务；
✓单表查询业务；
✓报表（多表）查询业务；
✓简单事务；
✓复杂事务；
搭建测试环境；
根据需要对数据库中的数据（注册用户、业务数据等）进行适当的模拟。
根据业务场景分组录制脚本，回放脚本并调试（使用loadrunner工具）。
✓在脚本中插入事务；
✓在脚本中插入集合点；
✓进行数据的参数化设置；
根据脚本，进行业务场景模拟（使用loadrunner工具）。
✓对录制的脚本组进行业务模拟组合；
✓对每一个脚本组设置虚拟用户数；
✓根据业务的特点设置每一个脚本组的开始运行时间、开始加载的用户数情况设置、运行的持续时间、运行结束时间、运行结束时释放用户情况。
✓设置集合点的策略、结果集等；
✓根据测试指标需要选择计数器
运行并监视场景
结合性能测试指标，分析实时监视图表，确定系统瓶颈；
✓事务的响应时间是否可以接受？
✓网络带宽是否足够？
✓内存是否够用？内存是否泄漏？
✓Cpu是否堵塞？
✓系统能否处理高负载？
根据性能缺陷，进行缺陷定位，调优工作；直到满足性能测试指标。
Ø测试完成标准
✧满足性能测试前制定的指标（用户的非功能需求）；
✧按照性能测试计划、方案完成性能测试；
Ø测试提交物
✧性能测试方案
✧性能测试计划
✧性能测试报告
4.兼容测试
Ø测试定义
系统在不同的软硬件条件下的业务流程的测试，
Ø测试的职责划分
兼容测试由测试组负责；
Ø测试方案
✧测试手段
手工测试
调试系统兼容性工具
✧测试内容和步骤
不同操作系统的测试；
不同分辨率下的测试；
不同浏览器和版本下的测试；
不同网络环境的测试
不同软硬件环境下的安装测试
Ø测试完成标准
✧根据指定的用户需求，使其满足不同的兼容性
✧按照测试计划、测试方案完成了兼容性测试；
5.验收测试
Ø测试定义
系统在客户现场安装并试运行。
Ø测试的职责划分
验收测试由实施人员或用户完成；
Ø测试方案
✧测试手段
手工测试
✧测试内容和步骤
需求功能与系统实现一致性
验收相关文档是否齐全
Ø测试完成标准
✧软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
✧所有测试项没有残余的一级二级三级的错误。
✧立项审批表、需求分析文档、设计文档和编码实现一致。
✧验收测试工件齐全（测试计划，测试用例，测试日志，测试通知单，测试分析报告）软件验收测试包括正式验收测试、alpha测试、beta测试三种测试。系统测试的策略：功能测试，性能测试，外部接口测试，界面测试，强度测试，冗余测试，可靠性测试，恢复测试等设计系统测试计划需要参考的项目文档有软件测试计划、软件需求工件、和迭代计划。
Ø紧急放行标准
✧标准适用范围
本标准细则适用于测试后期，由于特殊原因，必须提前交付使用，测试结果需保证用户指定使用的功能没有任何问题，允许有少量要解决而未解决的需求和测试中已发现的错误未完成。在软件发版后给用户替换正式版
✧标准内容
除用户指定的需求或以前版本中使用中的缺陷及错误必须完善外，按照测试中发现而未解决的问题的数量控制，控制指标如下：
一、二级BUG：低于2%
其它BUG：低于10%
6.回归测试
定义：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
理解：
1.回归测试是指重复以前的全部或部分的相同测试。
2.新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试。
3.回归测试的重心，以关键性模组为核心。
5内部规定
5.1Bug优先级标准
编号 | Bug优先级 | 对应的Bug严重等级 | 描述 |
1 | 高 | 灾难性，严重 | 缺陷必须被立即解决。 |
2 | 中 | 一般 | 缺陷需要正常排队等待修复或列入软件发布清单。 |
3 | 低 | 轻微 | 缺陷可以在方便时被纠正。 |
5.2Bug严重程度标准
此规范主要定义项目及产品在测试过程中缺陷的严重等级，软件测试接受的相关标准，通过不同严重等级的缺陷和缺陷修复后的正确率来判定项目及产品的质量。
Ø测试接收与退回标准
测试接受标准是开发集成测试完成后交由测试时需要达到的一个标准，首先确定系统软件无重大缺陷，达到的最低质量标准，整体流程能走通，应当达到“基本可用”的状态，如果送测系统通过接受标准则进行下一步的测试
Ø缺陷严重级别定义
说明：缺陷严重级别必须从最终用户感受的角度来定义。
缺陷严重级别 | 缺陷描述 | 划分参考 |
灾难性缺陷 （4级） | 造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。 | 系统缺陷 1.由程序所引起的死机，非法退出 2.不能执行正常工作或重要功能，资源严重不足，数据丢失，非正常死机等导致系统不能继续运行 |
严重缺陷 （3级） | 主要功能没有实现或产生错误结果；数据不能保存，系统的次要功能完全丧失；设计不合理造成性能低下，影响系统的运行、系统不稳定、或破坏数据，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，且没有办法更正（重新安装或重新启动软件不属更正办法） | 数据库缺陷 1.数据库发生死锁 2.数据库连接错误 3.数据通讯错误 接口缺陷 1.程序接口错误 2.硬件接口、通讯错误 功能错误 1.程序功能无法实现 2.程序功能实现错误 |
一般缺陷 （2级） | 次要功能没有完全实现但不影响使用。问题局限在本模块，导致模块功能失效或异常退出 | 操作错误 1.因错误操作迫使程序中断 功能错误 1.程序功能无法实现 2.程序功能实现错误 其他错误 1.脚本错误 |
轻微缺陷 （1级） | 使操作者不方便或遇到麻烦，但它不影响功能的操作和执行 | 界面错误 1.操作界面错误 2.界面、控件的摆布、图标、输入输出不规范 提示类操作 1.删除操作未给出提示 2.长时间操作未给出提示 3.出错没有提示 其他错误 1.快捷键无效，快捷键操作错误 |
5.3覆盖率标准
a)语句覆盖率最低不能小于80%
b)测试用例执行覆盖率应达到100%
c)测试需求覆盖率应达到100%
6测试通过条件
6.1.1单元测试停止标准
a)单元测试用例设计已经通过评审。
b)按照单元测试计划完成了所有规定单元的测试。
c)软件单元功能与设计一致。
6.1.2集成测试停止标准
a)集成测试用例全部通过
b)在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
6.1.3系统测试停止标准
a)系统测试用例全部通过。
b)满足通过准则，所有灾难性和严重bug均被修正；
c)系统测试的所有的BUG通过已经校验；
d)系统测试用例全部通过；
e)在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
6.1.4验收测试停止标准
a)验收测试方案已经通过评审。
b)按照验收测试计划完成了验收测试。
c)产品满足需求规格说明书的要求。
6.1.5Bug修复率标准
1）灾难，严重，bug全部解决
2）一般和轻微Bug修复比例大于80%
联系我们
Contact us
战略解码