开发静态测试规范
2 静态测试
2. 程序阅读
• 审查组人员仔细阅读代码和相关材料 • 对照代码审查单标出明显缺陷及错误
3. 审查会
• 审查会由组长主持 • 首先由程序员逐句阐明程序的逻辑，在此过程中可由 程序员或其他小组成员提出问题，追踪错误是否存在 • 经验证明在上述阐述过程中，有很多错误由讲述程序 者而不是其他小组成员发现 • 大声地朗读程序给听众，这样简单的工作是有效的错 误检测技术 • 然后利用代码审查单来分析讨论 • 组长负责讨论沿着建设性的方向前进，而其他人则集 中注意力发现错误，但不去纠正错误
G.J.Myers的代码审查单（部分）
• 数据引用错误
– 是否引用了未赋值或者未初始化的变量？ – 所有的数组引用，其下标值是否都在各自的相 应维数定义界内？ – 所有的数组引用，每一个下标是否是整数值？ – 所有引用的指针或变量当前是否已经分配储存 了？（即是否存在“悬挂引用”的问题） – 在检索操作或用下标引用数组时，是否存在“ 差1”的错误？
代码走查会的内容
• 与代码审查不同，不是读程序和使用代码审查单 • 而是由被指定的作为测试员的小组成员提供若干测 试用例（程序的输入数据和期望的输出结果），让 参加会的成员当计算机，在会议上对每个测试用例 用头脑来执行程序，也就是用测试用例沿程序逻辑 走一遍，并由测试人员讲述程序执行过程，在纸上 或黑板上监视程序状态（变量的值） • 每次开会时间以1－2小时为宜，但不允许中断 • 如果发现问题由秘书记下来，中间不讨论任何纠错 问题，主要是发现错误
内容
• 静态测试技术
– 代码审查 – 代码走查
• 静态测试的内容
– 需求定义的静态测试 – 设计文档的静态测试 – 源代码的静态测试
代码走查
• 代码走查与代码审查相似，它也是由一组 程序和错误检查技术组成，只是程序和错 误检查技术不完全相同
软件测试的静态与动态
软件测试的静态与动态软件测试是一项关键的质量保证活动，旨在检验软件系统是否满足预期的需求和功能。
为了有效地进行软件测试，测试人员需要掌握测试方法和技术。
其中，静态测试和动态测试是软件测试过程中常用的两种方法。
一、静态测试静态测试是在不运行程序的情况下检查软件系统的质量。
它主要通过对软件源代码、设计文档和其他相关文档进行检查，以发现软件中的错误、缺陷和问题。
静态测试方法包括代码审查、软件质量度量、需求分析和软件设计评审等。
1. 代码审查代码审查是一种通过系统地检查源代码来发现潜在错误和缺陷的方法。
它可以提前发现并纠正一些常见的编程错误，如语法错误、逻辑错误和性能问题。
代码审查可以通过手动检查、代码阅读、静态分析工具等方式进行。
2. 软件质量度量软件质量度量是一种通过定量分析软件各方面性能和特性的方法。
它可以帮助测试人员评估软件系统的可靠性、可维护性和可测试性等。
常见的软件质量度量指标包括代码覆盖率、错误密度、复杂性度量等。
3. 需求分析需求分析是在软件开发过程中非常重要的一环。
通过对需求文档的分析和评审，可以发现需求规范中的不一致、模糊或缺失等问题。
合理的需求分析可以减少软件开发中的返工和修复成本。
4. 软件设计评审软件设计评审是对软件系统设计文档进行检查和评估的过程。
在设计评审中，测试人员通常会检查设计是否满足软件需求，是否遵循设计规范和标准，以及是否存在潜在的设计缺陷。
二、动态测试动态测试是在运行程序的情况下检查软件系统的质量。
它通过输入一组测试数据并观察系统的输出行为，以验证软件是否按照预期的方式工作。
动态测试方法包括黑盒测试和白盒测试等。
1. 黑盒测试黑盒测试是一种基于软件规格说明的测试方法。
测试人员不需要了解软件的内部实现细节，而是关注系统的输入和输出，并通过比较实际输出和预期输出来判断系统的正确性。
常见的黑盒测试技术包括等价类划分、边界值分析和决策表等。
2. 白盒测试白盒测试是一种基于软件内部结构的测试方法。
静态测试实验报告
静态测试实验报告1. 简介静态测试是软件开发过程中的一种重要测试方法，主要通过检查源代码、设计文档和其他软件开发过程中产生的文档，以发现软件中存在的缺陷和错误。
本文将介绍静态测试的基本概念、常用的静态测试方法和实验结果分析。
2. 静态测试方法2.1 代码审查代码审查是一种常用的静态测试方法，通过对源代码的逐行检查，发现其中可能存在的错误和潜在的问题。
代码审查可以手动进行，也可以借助静态代码分析工具辅助完成。
在代码审查过程中，可以关注以下几个方面：•代码规范：检查代码是否符合编码规范，如命名规范、缩进规范等。
•逻辑错误：检查代码中是否存在逻辑错误，如条件判断是否正确、循环是否正确等。
•安全性问题：检查代码是否存在潜在的安全性问题，如输入校验不完善、SQL注入漏洞等。
2.2 文档审查除了代码审查外，文档审查也是一种常用的静态测试方法。
在软件开发过程中，会产生大量的设计文档、需求文档等，这些文档中可能存在错误和矛盾之处。
通过仔细审查这些文档，可以及早发现和解决问题。
在文档审查过程中，可以关注以下几个方面：•一致性检查：检查文档之间的一致性，如需求文档和设计文档之间的一致性。
•完整性检查：检查文档的完整性，是否存在关键信息的缺失。
•可读性检查：检查文档的可读性，是否易于理解和使用。
3. 实验设计本次实验旨在比较代码审查和文档审查对于发现软件错误的效果。
实验采用了以下步骤：1.随机选择了10个源代码文件和10个设计文档作为实验样本。
2.将这些样本分为两组，一组进行代码审查，另一组进行文档审查。
3.在代码审查组中，由一名经验丰富的开发人员对源代码进行逐行审查，记录发现的错误和问题。
4.在文档审查组中，由一名经验丰富的软件测试人员对设计文档进行仔细审查，记录发现的错误和问题。
5.对实验结果进行统计分析，比较代码审查和文档审查的效果。
4. 实验结果分析经过实验，我们得到了以下结果：•代码审查组共发现了20个错误和问题，平均每个样本发现2个问题。
软件测试流程规范最全
软件测试流程规范最全软件测试流程是指在软件开发过程中，通过对软件的功能、性能、质量等方面进行验证和检测，确保软件的稳定性和可靠性的一系列步骤和规范。
一个完善的软件测试流程可以帮助开发团队更好地发现和修复软件中的问题，提高软件的质量和用户体验。
下面是一个较为全面的软件测试流程规范，详细说明了每个阶段的任务和要求。
1.需求分析阶段在需求分析阶段，测试团队应该与业务分析人员一起参与需求讨论和分析工作，明确需求背景、功能要求和性能需求等。
测试团队应该对需求文档进行评审，确保需求的完整性和可测试性。
2.测试计划编制阶段在测试计划编制阶段，测试团队应该根据需求分析结果和软件开发进度制定测试计划。
测试计划应该包括测试目标、测试范围、测试策略、测试环境等内容。
测试计划还应该确定测试工具的选择和测试资源的分配。
3.测试用例设计阶段在测试用例设计阶段，测试团队根据需求文档和测试计划编制测试用例。
测试用例应该覆盖所有的功能点和场景，并包含预期结果。
测试用例设计应遵循等价类分析、边界值分析、场景分析等原则。
4.测试环境搭建阶段在测试环境搭建阶段，测试团队应该根据测试计划的要求搭建相应的测试环境。
测试环境应该与实际运行环境相同或相似，包括硬件设备、操作系统、数据库等。
测试环境应该保持稳定和可重复性。
在静态测试阶段，测试团队对设计文档、代码和其他文档进行静态测试。
静态测试可以帮助发现和修复设计和实现中的问题，提高软件的质量和可维护性。
静态测试方法包括代码审查、文档审查等。
6.单元测试阶段在单元测试阶段，开发人员对各个单位模块进行测试，以验证其功能的正确性和稳定性。
单元测试应该覆盖模块的各种路径和情况，使用合适的测试工具和框架进行测试。
单元测试应该在编码完成后立即进行。
7.集成测试阶段在集成测试阶段，各个模块进行集成和测试。
集成测试应该覆盖各个模块之间的接口和交互，以验证模块的正确集成。
集成测试应该从小规模的集成开始，逐渐扩大规模，确保各个模块的稳定性和一致性。
软件检测的静态动态测试
软件检测的静态动态测试在当今数字化的时代，软件已经成为我们生活和工作中不可或缺的一部分。
从手机上的各种应用程序，到企业使用的复杂业务系统，软件的质量和可靠性直接影响着用户的体验和业务的正常运转。
而确保软件质量的关键环节之一，就是软件检测。
其中，静态测试和动态测试是两种重要的检测方法。
静态测试，简单来说，就是在不运行软件代码的情况下对软件进行检查和评估。
这就好比在不发动汽车的情况下，对汽车的各个部件进行外观检查、尺寸测量和零部件质量评估。
在静态测试中，代码审查是一个常见的手段。
开发团队的成员或者专门的代码审查人员会仔细阅读软件的源代码，检查代码的结构、逻辑、语法错误等。
他们会关注代码是否符合编程规范，比如变量的命名是否清晰、函数的长度是否合理、代码的注释是否充分等。
通过这种方式，可以在早期发现潜在的问题，避免这些问题在软件运行时才暴露出来，从而节省大量的开发时间和成本。
另外，静态分析工具也是静态测试中的得力助手。
这些工具能够自动扫描代码，检测出一些常见的错误模式，如未初始化的变量、空指针引用、内存泄漏等。
它们还可以对代码的复杂度进行评估，帮助开发人员了解代码的可维护性和可读性。
除了代码本身，软件的需求文档、设计文档等也是静态测试的对象。
测试人员会检查这些文档的完整性、准确性和一致性。
比如，需求文档中描述的功能是否在设计文档中得到了充分的体现，设计文档中的架构和模块划分是否能够满足需求等。
与静态测试不同，动态测试是在软件运行的过程中对其进行检测。
这就像是让汽车在路上行驶，观察它的性能、操控和各种部件的实际工作情况。
动态测试中最常见的就是功能测试。
测试人员会按照预先制定的测试用例，对软件的各项功能进行逐一验证。
比如，对于一个登录功能，测试人员会输入不同的用户名和密码组合，检查软件是否能够正确地识别有效和无效的登录信息，并给出相应的反馈。
性能测试也是动态测试的重要组成部分。
它主要关注软件在不同负载条件下的响应时间、吞吐量、资源利用率等性能指标。
软件测试中的界面测试技术
软件测试中的界面测试技术在软件开发过程中，界面测试是非常重要的一部分。
界面测试主要用于验证软件的用户界面是否符合规范、是否可以正常使用，以及用户与软件之间的交互是否正确。
本文将介绍一些常用的界面测试技术，以帮助您在进行软件测试时能够更加准确、高效地进行界面测试。
一、静态界面测试技术静态界面测试技术主要用于验证软件界面的布局、样式、字体、颜色等静态属性是否符合设计要求。
以下是几种常用的静态界面测试技术：1. 图像比对法图像比对法主要用于验证软件界面的布局是否正确。
具体操作是，首先按照设计要求截取一张标准界面截图作为参照图像，然后通过自动化测试工具将标准图像与测试界面进行对比，如果存在像素级别的差异，则说明界面布局有问题。
2. 样式检查法样式检查法用于验证软件界面的样式属性是否符合设计要求。
具体操作是，通过CSS样式检查工具或浏览器开发者工具检查界面的样式属性，如字体、颜色、边框等是否与设计要求一致。
3. 层叠样式表（CSS）验证法CSS验证法用于验证软件界面中使用的CSS样式表是否符合规范。
具体操作是通过CSS验证工具对软件界面中引用的CSS样式表进行验证，检查是否存在语法错误、未闭合的标签等问题。
二、功能性界面测试技术功能性界面测试技术主要用于验证软件界面的各项功能是否正常工作。
以下是几种常用的功能性界面测试技术：1. 输入验证法输入验证法用于验证用户输入的数据是否能够正确地被软件接收和处理。
具体操作是输入各种合法和非法的数据，检查软件是否能够正确地进行数据验证、数据转换和错误处理等操作。
2. 按钮点击测试按钮点击测试用于验证用户在界面上点击按钮时，软件是否能够正确地执行相应的操作。
具体操作是点击各个按钮，检查软件是否能够正确响应并执行相应的操作。
3. 状态切换测试状态切换测试用于验证软件界面在不同状态下的表现是否正确。
具体操作是切换软件的不同状态，观察界面的变化和响应，并检查软件是否能够正常地进行状态切换并保持数据的一致性。
软件测试静态测试方法
软件测试静态测试方法软件测试静态测试是一种在软件开发过程中对软件文档进行检查和验证的方法。
它的目的是发现和纠正软件文档中潜在的错误和问题，以确保软件在实际运行时能够正常工作。
静态测试方法主要包括代码审查、需求分析和设计评审。
代码审查是一种常见的静态测试方法，它通过对程序代码进行检查和评估，发现可能存在的缺陷和错误，提高代码的质量。
代码审查有很多不同的技术和方法，例如代码检查、代码走查和代码评审等。
在代码审查过程中，审查者会仔细阅读代码，并通过对比已经确定正确的代码规范和最佳实践，来发现可能的问题和改进的空间。
通过代码审查，可以提前发现并修复代码中的潜在缺陷，减少后期的测试和维护工作。
需求分析和设计评审也是一种常用的静态测试方法。
在软件开发过程中，需求分析和设计是非常关键的环节，它们直接影响到最终的软件功能和性能。
通过对需求文档和设计文档进行评审，可以发现和纠正潜在的问题和错误。
在需求分析评审中，评审人员会仔细审查需求文档，并验证其准确性、完整性和一致性。
在设计评审中，评审人员会仔细审查设计文档，并评估其可行性、可维护性和可扩展性。
通过需求分析和设计评审，可以及早发现并修复潜在的问题，减少后期的开发和测试工作。
静态测试方法有很多优点。
首先，它可以在软件开发早期发现和纠正错误，提高软件的质量。
与动态测试方法相比，静态测试方法具有更高的效率和成本效益，因为它可以在代码编写和测试之前就发现问题。
其次，静态测试方法可以提高代码的可读性和可维护性。
通过对代码进行审查和评估，可以发现和修复冗余的代码、不良的编程习惯和不符合规范的代码等问题。
最后，静态测试方法可以提高开发团队的协作和沟通能力。
通过对文档进行评审，可以促使团队成员之间更加紧密地合作，提高软件开发的效率和质量。
然而，静态测试方法也存在一些不足之处。
首先，静态测试方法无法覆盖所有的代码路径和场景。
尽管可以通过对代码进行多次审查和评估，但仍然无法保证发现并修复所有的问题。
静态测试实验报告
一、实验目的本次实验旨在通过静态测试方法，对软件代码进行质量评估，以发现潜在的错误和缺陷，提高软件的可靠性和安全性。
静态测试是一种不执行程序代码的测试方法，通过分析代码结构、语法、逻辑和接口等，评估代码的质量。
二、实验环境1. 操作系统：Windows 102. 开发工具：Visual Studio 20193. 编程语言：C++4. 静态测试工具：Checkmarx、SonarQube三、实验内容1. 测试准备（1）选择待测试的代码：本次实验选择了一个简单的C++项目，包含主函数和几个辅助函数。
（2）安装静态测试工具：根据项目需求和工具特点，选择了Checkmarx和SonarQube作为静态测试工具。
（3）配置测试环境：设置静态测试工具的参数，包括代码路径、测试级别、报告格式等。
2. 静态测试执行（1）Checkmarx测试：- 运行Checkmarx工具，对代码进行静态扫描。
- 分析扫描结果，识别出潜在的缺陷和错误。
- 根据缺陷类型和严重程度，对代码进行修改和优化。
（2）SonarQube测试：- 将代码导入SonarQube平台，配置代码库和项目信息。
- 运行静态测试，生成测试报告。
- 分析报告，识别出代码中的缺陷和潜在风险。
3. 缺陷分析通过Checkmarx和SonarQube的测试结果，发现以下几类缺陷：（1）语法错误：例如，缺少分号、括号不匹配等。
（2）逻辑错误：例如，条件判断错误、循环条件错误等。
（3）编码规范问题：例如，命名不规范、代码格式不统一等。
（4）潜在安全风险：例如，SQL注入、XSS攻击等。
4. 缺陷修复根据测试结果，对代码进行修改和优化，修复以下缺陷：（1）修复语法错误：例如，添加缺失的分号、修正括号不匹配等。
（2）优化逻辑：例如，修正条件判断错误、调整循环条件等。
（3）改进编码规范：例如，统一命名规范、调整代码格式等。
（4）加强安全防护：例如，添加输入验证、使用安全编码规范等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
开发静态测试规范南京大汉网络有限公司2010年1月修订历史记录目录1目的 (3)2范围 (3)3术语 (3)4角色与职责 (3)5入口准则 (4)6输入 (4)7主要活动 (4)1 编码过程 (4)2 开发负责人（或部门经理）检查 (4)3 QA检查 (4)8开发支持流程 (5)1 运行环境规范 (5)2 F IND B UGS配置说明 (5)3 E CLIPSE设置 (8)4 代码检查规范 (9)5 F IND B UGS使用规范 (9)9输出 (10)10出口准则 (10)11引用文档 (10)1目的本文档的目的是为了规范开发人员在开发阶段对代码进行静态测试。
静态测试一方面可以提高开发人员编写代码的质量；另一方面，测试人员藉此可以把更多的精力放在业务逻辑的确认上面，而不是花大量精力去研究一些要在特殊状况下才可能出现的BUG(典型的如Null Pointer Dereference)。
使单元测试消耗工作量更少,也可以提高测试的效率。
2范围本文档所涉及的角色有：开发人员、开发负责人（或部门经理）、QA。
适用于公司所有软件编码过程。
3术语4角色与职责5入口准则编码阶段6输入公司编码规范7主要活动1编码过程当开发人员完成了部分功能模块开发的时候（指代码撰写完成，并已debug通过之后），在Eclipse的problems中没有Error和Warnings的情况下，可运用FindBugs对该模块涉及的JAVA文件进行扫描，通过FindBugs发现一些不易察觉的BUG或者是性能问题。
（具体操作步骤参考8.2FindBugs配置说明）。
2开发负责人（或部门经理）检查在编码进行中或者是编码结束后，由开发负责人（或部门经理）负责对代码质量进行走查，(除FindBugs运行检出的问题外)在检查的过程中出现的其他问题，都将记录在《问题跟踪表》中。
检查方式：可对整个工程或者是单独的代码块进行检查。
由开发负责人（或部门经理）对《问题跟踪表》中的问题进行跟踪。
开发人员对《问题跟踪表》中的问题进行修改。
并且要保证Eclipse—>Problems中没有Errors和Warnings存在，并且FindBugs没有检测出任何隐藏BUG的情况下才能通过。
3QA检查开发负责人（或部门经理）检查完代码后，由QA进行复查，QA将复查出的问题记录在《静态测试检查单》-问题跟踪表中。
QA复查通过后，才能进行产品预演。
测试人员在进行测试之前，需要查看《静态测试检查单》—QA复查单，在QA确认编码阶段已经结束的情况下，才能进行产品预演。
8开发支持流程1运行环境规范2FindBugs配置说明介绍如何使用FindBugs对工程进行检查，FindBugs主要有两种使用方式，一种Eclipse插件的方式；另外一种是单独运行的方式。
（注意：开发人员在编码的过程中可以使用Eclipse插件的方式对单个文件进行检查，但是最终必须要保证在GUI界面单独运行的方式中没有BUG出现，才算通过。
） FindBugs单独运行：1.找到$FindBugs_home\bin\findbugs.bat，双击它，会出现一个GUI界面，在GUI的界面中，操作菜单：文件/新建（如图）【project name】:填入工程名称。
【要分析的类包和目录】：通过“添加”按钮，选择要分析的class文件路径，（注意：只选择要分析的目录，不建议选择class根目录，选择根目录会对所有的class文件进行分析，在分析的过程中会很慢，甚至会有内存溢出的现象。
）【辅助类位置】：该工程所依赖的JAR包所在路径地址。
【源文件目录】：该工程JAVA源文件的路径地址。
（注意：此处为JAVA源文件的根目录，而不是具体到某个包的目录，否则分析结果会找不到源文件进行显示。
）2.以上操作完成后，点击“完成”按钮，FindBugs就开始进行检查了，检查结果如图所示：3.将执行的结果导出为XML文件，方便日后查看。
选择文件->Export filterEclipse插件：1)将edu.umd.cs.findbugs.plugin.eclipse_1.3.9.20090821.zip包解压，放到Eclipse\ plugins目录下。
2)启动Eclipse，点击project->properties，确认FindBugs插件是否已经正确安装，如果已经安装好，便可以看到FindBugs界面，如图：3)安装好以后，就可以使用FindBugs来检查我们的工程。
选择需要检查的工程，右击：工程名->FindBugs-> Fund Bugs，扫描完毕结果如图所示：4)对扫描完毕后的问题进行级别过滤，点击project->properties->FindBugs问题级别优先选择检查规则3Eclipse设置目前我们的产品都是在JDK1.4上面开发的，在从JDK1.4转换到JDK1.6时在Eclipse 中会出现泛型的问题，下面将介绍如何过滤这些问题的检查。
首先，Eclipse->Project->Properties->Java Compiler->Error/Warnings ,将“Generic type”下面的三个选项全部至为“Ignore”。
在看下一个菜单Validation->HTML Syntax,将“Attributes”下面的“Undefined attribute name”和“Undefined attribute value”这两项分别至为“Ignore”即可。
4代码检查规范FindBugs主要有九种检查规则，每一个规则中都有不同的检查条目，由于每个规则所拥有的条目很多，所以只针对每个规则常见的条目进行介绍：【Performance】：性能问题【Correctness】：代码的正确性【Internationalization】：国际化问题【Multithreaded currectness】：线程问题【Bad practice】：不好的习惯【Malicious code vulnerability】：恶意代码【Security】：安全性问题【Experrimental】：实验性问题5FindBugs使用规范介绍在使用的过程中，每个角色如何去分配代码中的BUG。
团队合作检查：对于团队合作的代码，开发人员首先要保证problems中没有Error和Warnings的情况下，使用FindBugs对自己开发的文件进行的检查，并把检查的问题全部修改完成后，提交CVS。
由开发负责人对代码进行复查，复查结果要填写在《静态测试检查单》如果复查有问题，将问题记录在《静态测试检查单》-问题跟踪表中，开发负责人要追踪问题，直到所有问题都被解决。
如果复查没有问题或问题已经修改完毕，开发负责人将检查单提交给QA，由QA对代码进行再次复审，QA检查通过后，才可进行产品预演。
如果预演未通过需要修改，则再次按照以上流程进行。
独立开发检查：定制开发项目（或者产品开发个人独立完成的模块），开发人员首先要保证problems中没有Error和Warnings的情况下，使用FindBugs对自己开发的文件进行的检查，并把检查的问题全部修改完成后，提交CVS。
如果开发负责人是开发人员本身，那么由部门经理对代码进行复查（以此类推），并将复查的结果填写在《静态测试检查单》，如果复查有问题，将问题记录在《静态测试检查单》-问题跟踪表中，部门经理要对问题进行追踪，直到所有问题都被解决。
如果复查没有问题开发静态测试规范南京大汉网络有限公司 第10页/共10页 或问题已经修改完毕，部门经理将检查单提交给QA ，由QA 对代码进行再次复审，QA 检查通过后，才可进行产品预演。
如果预演未通过需要修改，则再次按照以上流程进行。
更新包检查：1) 开发人员，在编码撰写完成之后，并且debug 之后。
problems 中没有Error和Warnings 的情况下，使用FindBugs 对所做的文件进行单独的检查。
将检查完毕的代码提交CVS 。
2) 开发负责人（或部门经理）：从CVS 开发库将代码checked 出，并根据开发人员所填写《xxx 版本修改记录》中提供的文件，对单个文件或者是工程进行复查。
开发负责人（或部门经理）将复查的结果填写在《静态测试检查单》，如果复查有问题，将问题记录在《静态测试检查单》-问题跟踪表中开发负责人（或部门经理）要对问题进行追踪，直到所有问题都被解决。
如果复查没有问题或问题已经修改完毕，开发负责人（或部门经理）将检查单提交给QA 。
3) QA 人员，在接到开发负责人（或部门经理）所提供的《静态测试检查单》后，从CVS 将更新包提取出来，覆盖到本地工程目录中，通过Eclipse 将更新包中的JAVA 文件进行编译，并根据《xxx 版本修改记录》中所提供的文件,对编译后的JAVA 文件进行复查。
QA 检查通过后，才可进行产品预演。
如果预演未通过需要修改，则再次按照以上流程进行。
9 输出《静态测试检查单》-问题跟踪表《静态测试检查单-》-开发负责人检查单《静态测试检查单》- QA 复查单10 出口准则由QA 检查确认，满足以下两个条件才可进行产品预演：1) Eclipse-> Problems 中没有Errors 和Warnings 存时。
2) FindBugs 没有检查出任何BUG 。
11 引用文档无。