1． 目的
本方案主要实施NC产品程序代码的白盒测试。使界面符合设计规范，适用于用户；保证程序创建的类与接口的完整与正确，以及程序模块单独正常运行。保证局部模块功能完备性，运行正确性与稳定性。
2． 测试项
所要测试的类。如：
nc.ui.bd.*
nc.bs.bd.*
nc.vo.bd.*
3． 测试依据
1. NC产品需求报告；
需求规格说明书、用例描述清单
2. 设计文档；(OOA、OOD、CRC卡)
如：AOM（Analysis Object Model）表示类间的静态关系，是多个相关的用例共用的。
ASD（Analysis Sequence Diagram)是按业务工作的顺序表示每一工作步骤执行时类间的动态关系。一个用例对应一个ASD。
CRC （Collaborators & Responsibilities Card）卡是一个类的完整表述
3. 界面规范
4. 编码规范
5. 开发命名标准
4． 通过的准则
1.界面测试通过的标准：界面的样式、大小、颜色、整体布局的设置；各种标签控件的使用及主题描述以及事件源控件的使用、快捷键使用都应符合《NC系统应用框架需求报告》和《设计文档的相关规范》。
2.程序代码通过的标准：创建的类、接口、方法、属性应与《设计文档》保持一致；程序的各种命名、注释、代码行的格式等应符合《程序开发命名标准》和《编码规范》；程序模块能独立稳定运行。
5． 测试环境配置
1 测试工具：
2 软件环境：
Client端：
操作系统：中文WINNT/2000
开发环境：VA3.5 专业版
待测试的源码包
Server端：
操作系统：WIN NT4.0
开发环境：VA3.5 专业版
通讯环境： Servlet
3 DB Server端：DBMS：SQL SERVER
4 资源文件
6． 白盒测试总流程
测试流程依据，请参见《代码层次结构规范》。
NC系统中的对象主要分为如下几种：
· 界面对象(UIObject)
· 数值对象VO(ValueObject)
· 业务对象BO(BusinessObject)
· 数据管理对象DMO(DataManageObject)
测试流程可按二种方式，其优缺点对照：
BO
DB
DMO
UI
VO VO
DB
UI
BO
DMO
前者：优点是便于测试者从界面层直观地录入数据，缺点是做回归测试时，录入数据需重复
后者：
原则是从底层测试，底层测试通过了，再依次往上一层测试；否则不需往上层测试
缺点：需给中间层做一测试小程序：根据程序中类的对象构造输入数据及将结果输出到控制台上，（可通过自行设计测试工具来改善，测试工具需求另附）
优点：做回归测试时，不用再构造输入数据，只要再执行一遍小测试程序
7． 测试步骤：
需要列出所测试类的调用关系和关键方法的调用关系（依据为数据流）。
（1） 类关系图。
(2) 方法的功能调用关系图：只需要列出一些调用关系较复杂的方法。
1. 配置好测试环境；
2. 编写测试用例；
另附
3. 静态测试，走查代码；
代码走查使用测试用例启发检测错误，沿程序逻辑走一遍,检测程序结构和实现上是否有问题
4. 动态测试
· 界面初始化状态测试；
· 界面控件功能测试；（正反用例）；
· 业务功能测试（正反用例）；
· 数据流关联测试（涉及多表的增、删、改），并结合数据库表的字段、外键、字段类型、精度、小数位数、非空、默认值、备注、数据对象等。
· 数据传递和接收一致，数据计算或处理后状态正确；
· 组合模块整体运行稳定，不出现死机；
1. 确定问题属性:
分为四类：错误、缺陷、失效、故障
错误是指计算值、观测值、测量值之间，或条件与真值之间，不符合规定的或理论上的正确值或条件
缺陷是指与期望值或特征值的偏差
故障是指功能部件不能执行所要求的功能。故障可能由错误、缺陷或失效引起。
失效是指功能部件执行其功能的能力丧失，系统或系统部件丧失了在规定限度内执行所要求功能的能力
2. 确定问题类别:
问题类别分为以下几大类:
|
1.各层公用问题
|
|
2.JAVA语言规范
|
|
3.数据类型
|
|
4.SQL语句规范
|
|
5 界面UI
|
|
6.VO数值对象
|
|
7.BO业务对象
|
|
8.DMO数据管理对象
|
|
9.业务逻辑重点
|
|
10.事务处理与隔离级别测试（详见总体技术部相关文档）
|
|
11．效率测试（详见总体技术部相关文档）
|
1. 填写测试报告
测试记录需详细填写具体实施方法中的相关列表；
上交的测试报告只需填写未通过的项。(详见第10节)
8． 具体实施方法：
8.1). 各层公用问题：
|
序号
|
测试项
|
测试内容
|
质量保证标准
|
问题属性
|
出错频率
|
|
T1
|
代码与设计对照
|
按需求、UI,CRC设计文档与编码对照,看是否完全地实现了所有的UI设计文档和CRC卡中规定的内容？
|
完备性
|
错误
|
|
|
T2
|
代码与设计对照
|
按需求、UI,CRC设计文档与编码对照,看是否创建了所需的数据库或其他初始化数据文件？
|
完备性
|
错误
|
|
|
T3
|
参数
返回值
|
方法中被传递参数的类型、个数、顺序及返回值是否正确？以符合UI设计文档和CRC卡为准。
|
正确性
|
错误
|
|
|
T5
|
参数的传递
|
当方法需要调用其它方法时，调用的参数是否正确？（UI设计文档和CRC卡中有调用说明）
|
正确性
|
错误
|
|
|
T6
|
命名
|
是否按《命名规范》进行了类、方法、变量、属性的命名？
|
正确性
|
错误
|
|
|
T7
|
公式
|
代码中的公式是否使用了设计文档中的相应数学公式。
|
正确性
|
错误
|
|
|
T8
|
注释
|
注释是否使用简洁明了的语言对每一个方法都进行了充分必要的描述？是否对复杂的代码进行了注释？当程序的运行是受某些特殊因素限制时，是否做了限制注释？是否列出限制模块运行特性的全部特殊因素？
|
易理解性
|
缺陷
|
|
|
T9
|
冗余语句和变量
|
是否存在永远执行不到的语句和变量，而降低了程序的可理解性？
|
易理解性
|
缺陷
|
|
|
T10
|
程序是否冗余
|
对于程序中的大量重复内容，是否使用了专门的类来实现？
|
可验证性
|
缺陷
|
|
|
T11
|
代码整体规范
|
是否自始至终使用了《程序员开发手册》和《编码规范》中要求的格式、调用约定、结构等？
|
一致性
|
缺陷
|
|
|
T12
|
代码与书写注释
|
在一个函数内代码的长度不允许超过100行。建议如果一个函数的代码长度超过一个屏幕，那么或许这个函数太长了。
使用统一的格式化代码。将‘{’放在所有者的后面，并且在下一行代码前加入TAB键缩进；（TAB键比用若干个空格更容易控制使用统一的缩进距离）
类的注释；
接口的注释；
函数的注释；
类属性的注释；
局部变量的注释；
请详见：《代码与注释书写风格规范》
|
易理解性
|
缺陷
|
|
|
TT13
|
包
|
命名是否符合程序包命名规范
|
|
|
|
|
TT14
|
类
|
1.
|