今日小组成员任务完成情况：
| 成员 | 今日工作 | 备注 |
| 郭义 | 未完成白盒测试文档（延期） | 未完成任务(12-12日任务已完成） |
| 杜杰 | 完成了代码复审方法 | 完成任务 |
| 侯俊 | 完成了findbugs测试文档 | 完成任务 |
| 李嘉蕊、姜黎黎 | 完成缺陷报告模板 | 完成任务 |
| 唐伟 | 编写今日博客 | 完成任务（后期添加未完成组员的部分） |
小组完成文档总览
白盒测试用例如下图
代码评审会议纪要
1、主持人（杜杰）对项目及此次会议做整体介绍。
2、小组其余成员（姜黎黎、唐伟、李嘉蕊、侯俊、郭义）根据代码评审标准，以及对代码的阅读，填写评审表。
3、主持人结合代码讲解发现的问题，每讲完一个问题，针对其展开讨论，每个问题控制在10分钟以内。
4、 主持人组织全体与会人员召开会议并记录会议过程。
评审结果报告
一、概要部分
全组人员开的代码复审会议中，首先，对项目的源码从头到尾进行复审，看代码是否符合需求和规格说明，然后检查代码是否有周全的考虑，以及代码的可读性和可维护性，经过小组成员的审核和讨论，确认该项目的代码全部符合以上要求。
二、设计规范部分
对代码进行了初步的复审后，然后小组成员开始分块对项目代码进行设计规范部分的复审。经过大家的复审，确认项目代码遵从了已知的设计模式或项目中常用的模式，没有硬编码或字符串/数字等存在，没有依赖于某一平台，不会影响将来的移植（如Win32到Win64），开发者新写的代码能用已有的Library/SDK/Framework中的功能实现，在本项目中存在类似的功能可以调用而不用全部重新实现，另外，很多人想保留尽可能多的代码，因为以后可能会用上，这样导致程序文件中有很多注释掉的代码，这些代码都可以删除，因为源代码控制已经保存了原来的老代码，而这些代码就是无用代码，在本次工作中，也对此进行了检查，发现没有无用的代码可以清除。所以复审的设计规范部分完全合格。
三、代码规范部分
进行了设计规范部分的代码复审后，我们小组对全部的项目代码又进行了仔细地检查，看代码是否符合代码标准及规格。经过复查，结果如下：
1、代码遵循PSR-1中的编码规范。
2、代码使用4个空格符而不是tab键进行缩进。
3、每行的字符数软性保持在80个之内
4、每个 namespace命名空间声明语句和use声明语句块后面，插入一个空白行。
5、类的开始花括号写在其声明后自成一行，结束花括号也写在其主体后自成一行。
6、方法的开始花括号写在函数声明后自成一行，结束花括号也写在函数主体后自成一行。
7、类的属性和方法添加访问修饰符private、protected以及public，abstract以及final声明在访问修饰符之前，而static必须声明在访问修饰符之后。
8、控制结构的关键字后要有一个空格符，而调用方法或函数时则没有。
9、控制结构的开始花括号写在声明的同一行，而结束花括号写在主体后自成一行。
10、控制结构的开始左括号后和结束右括号前，都没有空格符。
四、具体代码部分
对代码规范进行复查后，我们对项目的具体代码部分又进行了复审。经过我们小组自己复查，该项目的代码有对错误进行处理，对于调用的外部函数，检查了返回值或处理了异常，参数传递没有错误，字符串的长度是字符的长度，是以0开始计数，对于边界条件给出了其相应处理，Switch语句的Default也进行了处理，循环没有可能出现死循环。所以，具体代码部分的复审合格。
五、可读性
接下来，我们对项目代码又进行了可读性复审，发现代码可读性好，有足够的注释，每一个函数和模块都有相应的注释，并且，函数和模块内的关键语句也有注释，通过注释，可以很好地理解项目的代码思路。
六、可测试性
最后，我们又对项目进行了可测试性的相关复审，复审结果表示，该项目代码没有需要更新或创建新的单元测试，各个模块及函数的可测试性良好。
静态代码检查工具选择
一、工具选择
经过对比findbugs，checkstyle，pmd，jtest四款工具的优点与缺点以及个人的偏好，最终我选择findbugs，其在eclipse和IDEA都有插件支持，当然，findbugs是开源免费的。
Findbugs开发的目的是基于Bug Patterns概念，注重检测真正的bug及潜在的性能问题 ，尤其注意了尽可能抑制误检测(false positives)的发生。
FindBugs检查内容主要包括： 检查bytecode中的bug patterns 也允许用户自定义特定的bug patterns检测equals() 实现时的一般规约违反 Null pointer的参照 Method的返回值的check遗漏 初始化前field的访问 Multi-thread的正确性检测Code的脆弱性，可以变更的静态object ，内部数列参照的return等。
它有以下特点：FindBugs主要着眼于寻找代码中的缺陷，以bytecode（*.class、*.jar）为对象进行检查，不检查java源代码FindBugs可以通过命令行、各种构建工具（如Ant、Maven等）、独立的Swing GUI或是以IDE插件的方式来运行 FindBugs输出结果既可以是XML的，也可以是文本形式的不注重style及format，注重检测真正的bug及潜在的性能问题，尤其注意了尽可能抑制误检测(false positives)的发生findBugs有过滤器可以帮你过滤掉一些没必要的检测器findBugs可以编写自定义的检测器。
二、IDEA安装FindBugs插件
我的环境是IDEA，因此以下是IDEA的安装方法。
首先到https://plugins.jetbrains.com/plugin/?id=3847 , 下载最新版本的findbugs压缩包。
然后打开IDEA的Plugins ， 选择Install plugin from disk 。 然后选择下载的findbugs压缩包，选择apply，重启即可。。
就是这么简单。
Findbugs的进一步认识
1. Findbugs是一个静态分析工具，它检查类或者JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。Findbugs可以在ANT/GUI/ECLIPSE三个环境中运行，同时也可以编写自己的检测器，功能比较完善。
2. 它主要用到的技术是缺陷模式匹配和数据流分析：
1）缺陷模式匹配：事先从代码分析经验中收集足够多的共性缺陷模式，将待分析代码与已有的共性缺陷模式进行模式匹配，从而完成软件的安全分析。这种方式的优点是简单方便，但是要求内置足够多缺陷模式，且容易产生误报。
2）数据流分析：数据流分析也是一种软件验证技术，这种技术通过收集代码中引用到的变量信息，从而分析变量在程序中的赋值、引用以及传递等情况。对数据流进行 分析可以确定变量的定义以及在代码中被引用的情况，同时还能够检查代码数据流异常，如引用在前赋值在后、只赋值无引用等。数据流分析主要适合检验程序中的 数据域特性。
3. FindBugs检查.class文件，基于Bug Patterns概念，查找javabytecode(.class文件)中的潜在bug。主要检查bytecode中的bug patterns，如NullPoint空指针检查、没有合理关闭资源、字符串相同判断错（==，而不是equals）等。
4. Findbugs自带检测器，其中有60余种Bad practice，80余种Correctness，1种 Internationalization，12种Malicious code vulnerability，27种Multithreaded correctness，23种Performance，43种Dodgy。
5. FindBugs有两种使用形式，一是作为插件，放在Eclipse中使用，二是提供软件运行。而作为插件的形式比较方便简单，个人觉得使用起来比较合适。
6.FindBugs内置的编程规范包括：
1) Bad practice 坏的实践：常见代码错误，用于静态代码检查时进行缺陷模式匹配
2) Correctness 可能导致错误的代码，如空指针引用等
3) 国际化相关问题：如错误的字符串转换
4) 可能受到的恶意攻击，如访问权限修饰符的定义等
5) 多线程的正确性：如多线程编程时常见的同步，线程调度问题。
6) 运行时性能问题：如由变量定义，方法调用导致的代码低效问题。
来源：https://www.cnblogs.com/hust1703SE/p/8018838.html