静态测试情况总结报告

静态测试情况分析报告

在2007年2月版本前期阶段，测试二部就提出静态测试的做法，并在部门内部全面开展静态测试，目前静态测试工作已在全中心展开。经过一年多努力，我们不仅在静态测试方面取得了一定的成果，而且在静态测试方法的研究方面也取得了突破性的进展，将静态测试从单纯的文档审核上升到了静态分析的理论高度、并在实践中总结出一套切实可行的实施做法。

一、静态测试的实施方法

根据项目不同阶段的工作重点，结合测试人员的介入情况，我们将测试人员参与项目的工作分为五个阶段，即“项目定义阶段”、“功能设计阶段”、“详细设计阶段”、“编码集成阶段”、“系统测试阶段”。在项目定义和功能设计阶段，测试人员主要参与需求分析和设计方案讨论，在过程中了解业务需求和设计方案，为后期的静态和动态测试奠定基础。从详细设计阶段开始，测试人员将通过静态方法全面展开对项目设计方案的分析，静态测试工作将一直延续到系统测试结束。因为同样的静态测试问题，在不同的项目阶段发现，解决问题的难易程度和成本都存在很大的差别，因此，对于不同项目阶段的静态测试，需要采取不同的测试方法，才能更有效地发现问题。下面将对不同项目阶段静态测试的工作重点及分析方法进行论述：

1、项目定义阶段

项目定义阶段，开发中心的主要工作是对业务需求进行分析，确认项目能够实现的需求内容，并制定总体设计方案。测试部门会根据

情况派出相关骨干人员参与。测试人员在参与需求分析过程中，一是充分了解业务需求的背景及实现的目标，同时还会根据自身能力，提出一些问题来细化和完善需求；二是充实自己业务知识，从需求中了解新业务，以及相关的业务规范，为后续的项目测试工作打下坚实的业务基础。例如：在财智卡一期的业务需求讨论中，测试人员针对业务部门提出的财智卡定位不清问题，要求业务部门进一步明确对于卡BIN的具体要求，以及财智卡在未来业务中的使用范围和控制要求，当问题一一得到落实以后，就发现原业务需求的目标与现有的银联规范和卡的业务规范存在一定的矛盾。如果这个问题没有在需求分析阶段得到明确，而是按照业务需求结合我们现有系统进行设计开发，测试也按照设计方案进行，很有可能导致问题到投产以后才会暴露。

2、功能设计阶段

功能设计阶段，项目组的主要工作是根据已确定的业务需求和总体设计方案完成项目的功能设计。测试经理和主要的测试骨干都会参与设计方案的讨论。在讨论的过程中，测试人员会站在用户的角度，对照业务需求的描述，采用一种“虚拟测试”的思考方法，对设计方案进行分析，找出设计方案中可能存在的问题，协助设计人员不断完善设计方案。另一方面，测试人员通过参与设计方案的讨论，可全面了解项目的技术方案和设计思路，为后续展开的静态测试和动态测试打下良好的基础。

例如：测试人员在参与“境内外币统一清算”项目功能设计的讨论中，针对原设计方案中使用现有的往来户透支功能，来处理该项目

结算账户透支问题时，对设计方案提出疑义：（1）使用往来户的透支功能，就必须遵循现有系统往来户透支计息方式计算利息，并需要纳入法人透支管理流程，这些极可能会与人行的最终要求不一致，也会影响行内对贷款规模的控制；（2）如果人行确定了结算户的透支计息方式，或以后人行再提出新的对结算户透支控制和计息方式的变更，都将会涉及系统大范围地修改。并对这部分的功能设计提出建议性意见：结算帐户仍按业务部门提出的使用往来户，但对其透支的功能，通过参数设置引入对应的内部户进行管理，将内部户设置为不计息帐户，在人行没有确定利息计算方式之前，如果需要可通过人工对不计息的内部户计算透支利息，在人行确定了计息方式，可以开发一个独立的计息程序对这部分帐户进行计息处理，这样即便人行的规则有变化，我们也不需要进行大范围地修改程序，通过反复讨论，最终设计人员采纳了测试人员的建议。对于这个问题解决对后续项目的影响，在08年4月版本“境内外币统一清算优化”项目已经得以验证。

3、详细设计阶段

详细设计阶段，开发人员的主要工作是按照功能设计方案《软需》进行详细设计，并编写《系统规格书》和《程序规格书》。测试人员的主要工作就是按照《软需》完成测试设计，并编写《测试计划》和《测试方案》。测试部门在完成上述工作的过程中，还会从几个方面对功能设计方案进行静态测试：

（1）对照《总体设计方案》，分析《软需》描述的功能设计方案，尽量找出功能设计方案中可能存在的“设计遗漏”问

题，以及功能设计方案与总体设计方案不一致的“设计错误”问题；

（2）依据《业务需求》，对照《软需》描述的功能设计方案进行分析，从中发现功能设计描述的条件和结果与业务需求提出的前提和目标不一致的“需求问题”；业务需求有，但功能设计方案中缺少的“设计遗漏”问题；业务需求没有要求，功能设计多余的“设计错误”问题。

（3）针对《软需》中不同模块之间或不同应用之间相关功能的设计方案进行对比分析，尽量找出一些相关联的功能，在设计上的冲突和矛盾，从而发现一些“设计错误”问题；

（4）针对《软需》描述的某一具体功能模块设计方案，测试人员根据业务需求、前后关联关系、系统的控制参数等，先分析出可能存在的输入条件，与功能设计方案描述的各种输入条件进行对比分析，找出设计方案中对输入条件遗漏和错误的内容，提出“设计遗漏”和“设计错误”的静态问题；另外，按照所有可能的输入条件，和设计的功能处理描述进行分析推断，得到可能的程序运行结果，与设计方案中描述的输出结果进行对比分析，对不一致和遗漏结果，提出“设计错误”和“设计不完善”的静态问题。

通过上述做法，测试人员可以在该阶段发现一些影响较大的需求理解、设计遗漏、设计错误和设计不完善的问题。针对这些问题，设计人员只需要花费很少的修改和完善文档的工作量，就能够在详细设计阶段一一明确和解决这些问题，有效避免了上述问题对编码质量的影响。因为提交的程序中减少了需求设计问题，在同等编码水平的条

件下，动态测试可能发现的问题会相对减少。发现的问题少了，开发人员修改程序，测试人员反复验证和回归测试的工作量就会大大减少。测试进度快了，相对测试的时间就充分了，测试的深度也可以得到加强，在一定程度上能够起到提高测试质量的目的。

举例1：“内部资金收付管理系统(二) ”项目，在详细设计阶段，测试人员提出：业务要求系统具有查询当日到期外币上存、拆借资金明细表的功能。按照目前的设计方案在T日日终，处理T+1日到期的登记簿记录，这样在T+1日日间将不可能查询到当天到期的记录，功能设计实现的结果与业务需求不符。类是这样“设计错误”问题，可以通过对照业务需求与设计处理结果进行对比分析发现。

举例2：“核算与产品剥离”项目，在详细设计阶段提出，生成月终损益表记录设计功能描述中，读取银行财务核算帐户（KTHFIACT）时，要判断帐户属性为1或3情况，但在SEAS上对KTHFIACT表结构的设置，根本没有帐户属性字段。类是这样的设计方案中不一致错误问题，可以通过设计文档功能描述的相关内容对比分析发现。

举例3:“核算与产品剥离”项目，在详细设计阶段提出：财务管理综合系统账户的账号管理参数表分页查询接口CI20019 查询的内容已经移到新的表中，在设计方案中没有描述对CI20019接口的修改功能。类是这样的设计遗漏的问题，可以通过对被修改内容的相关模块的分析发现。

举例4:“核心银行系统历史明细改造”项目，在详细设计阶段