实践作业3：白盒测试实践
针对本组选定的Web应用系统（同黑盒测试实践所使用的系统），运用白盒测试方法设计测试用例，编写单元测试脚本，执行测试，记录缺陷。并综合运用多种静态检查方法，对源代码展开分析，并对测试工作和被测代码的质量给出分析，得出结论。
本次用于静态代码检测的工具是FindBugs,把它用作为一个eclipse的插件来完成这次的静态代码检测。
一、编写目的
本文档记录图书管理系统V1.0的系统测试执行过程。预期的读者范围包括：项目经理、测试经理、用户。对于新开发的web应用图书管理系统（v1.0版）进行部分模块的代码审查工作，以验证需求文档的要求和开发要求，检验是否满足要求。
二、测试策略
召开代码审查会议
进行静态代码审查
记录缺陷报告和填写审查表
三、执行步骤
1.组织审查人员约定地点时间进行代码审查会议并填写审查表
2.依据代码规范进行代码的静态审查
3.制作单元测试脚本进行测试并记录结果
4.填写缺陷报告并提交修改
四、工作小态
我们小组集体完成相关作业，其中遇到了一些困难，比如测试工具最开始不会用，有时候bug不再现，还有猜测不出一部分用户的行为。但由于我们是集体作战，有问题一起解决，实在解决不了的问题我们就扬长避短。所以我们在几个工作日就完成了作业。
五、静态代码检测
FindBugs通过检查类文件或 JAR文件，将字节码与一组缺陷模式进行对比从而发现代码缺陷，完成静态代码分析。FindBugs既提供可视化 UI 界面，同时也可以作为 Eclipse插件使用。文本将主要使用将 FindBugs作为 Eclipse插件。在安装成功后会在 eclipse中增加 FindBugs perspective，用户可以对指定 Java类或 JAR文件运行 FindBugs，此 FindBugs会遍历指定文件，进行静态代码分析。Findbugs可以在多个环境中运行，同时也可以编写自己的检测器，功能比较完善。我们平时可以收集自己的或者是别人的开发经验，把它做成检测器来完善Findbugs的检测体系。
FindBugs 是一个静态分析工具，它检查类或者 JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具，就可以在不实际运行程序的情况对软件进行分析。不是通过分析类文件的形式或结构来确定程序的意图，而是通常使用 Visitor 模式。：在FindBugs的GUI中，需要先选择待扫描的.class文件(FindBugs其实就是对编译后的class进行扫描，藉以发现一些隐藏的bug。)。如果你拥有这些.class档对应的源文件，可把这些.java文件再选上，这样便可以从稍后得出的报告中快捷的定位到出问题的代码上面。此外，还可以选上工程所使用的library，这样似乎可以帮助FindBugs做一些高阶的检查，藉以发现一些更深层的bug。选定了以上各项后，便可以开始检测了。检测的过程可能会花好几分钟，具体视工程的规模而定。检测完毕可生成一份详细的报告，藉由这份报告，可以发现许多代码中间潜在的bug。比较典型的，如引用了空指针(null pointer dereference), 特定的资源(db connection)未关闭，等等。如果用人工检查的方式，这些bug可能很难才会被发现，或许永远也无法发现，直到运行时发作…当除掉了这些典型的(classic) bug后，可以确信的是，我们的系统稳定度将会上一个新的台阶。在网上的评价中，FindBugs工具虽然是机器扫描，效率高，但是还不够灵活。
首先把下载到的FindBugs对Eclipse插件解压到Eclipse安装目录下的Plugin目录，启动Eclipse，在之前加载好的工程上右键找到Find Bugs菜单，点击Find Bugs，开始执行静态代码审查。
这时候findbugs会自动检测所选的工程或包内的代码，检测完成后会显示出代码中的bug信息。在Window菜单上选择Show View中的Other，搜索FindBugs，选择Bug Explorer，点击OK，如下图所示。
在下方的Bug Explore中就可以找到工具找到的bug。
静态代码检查工具的优缺点：
代码检查工具的优点：自动化，使用机器扫描，效率高，速度快，本次使用过程在1分钟之内完成，可以快捷地代替人力寻找bugs。
代码检查工具的缺点：不够灵活，只能在检查工具有的bug库里面找到简单的错误。对于逻辑性较强的bug和结果与期望不符的问题检测率较低。
六、代码复查审核：
1．概要部分
（1）代码基本符合需求和规格说明。
（2）代码设计具有十分周全的考虑。
（3）代码可读性良好。
（4）代码易于维护。
（5）代码的每一行都执行并检查过了。
2．设计规范部分
（1）遵从常用的Web框架模式进行设计。
（2）没有硬编码的数字和字符存在。
（3）代码没有依赖于某一操作系统或平台，具有良好的可移植性。
（4）开发者新写的代码不能用已有的Library/SDK/Framework中的功能实现，并没有重复的接口。
（5）有部分无用的代码，但是不多，不造成具体的影响，可删除或者不用删除。
3．代码规范部分
（1）边写的代码基本符合良好的代码标准和风格。
4．具体代码部分
（1）对于错误，有正确的提示和终止一系列应对的操作，对于调用的外部函数，检查了返回值或者处理了异常。
（2）参数传递无错误。
（3）数据结构中没有无用的元素，并无多余的数据。
5．效能
（1）代码的效能十分流畅，可能是因为本体代码和功能比较简单。
（2）代码中，没有特别需要优化的循环部分。
6．可读性
代码可读性不算特别好，有少量的中文注释，但是不算特别清晰。
7．可测试性
代码缺少单元测试所以需要创建新的单元测试。
七、代码测试结论
被测的子模块系统质量符合需求文档的要求，可以继续审查其他模块和系统。
