我相信大家对测试不陌生，但是对安全测试可能有一些疑问。安全测试关心的问题是不一样的。这种测试也被人叫做工具测试、渗透测试、攻击测试、测试产品安全性。

    这种测试需要首先知道各种各样的攻击的方式和原理，在攻击产生之前尽量多的找到产品的漏洞，尽量多的发现产品里面的问题，再努力把它解决掉。

What is the difference between security testing and traditional function based testing ?

    这两个之间的差别我们可以用一个简单的东西来说明，Targeted towards making sure that the app does what it is supposed to do。

    For Functionality testing：我设计这个产品是1、2、3、4、5，我得让它能干到1、2、3、4、5才行，不是说是1、2、3、4，少1份干不了。这是一般的出来的结果也是一二三四五。

    For Security testing：是说我设计了1、2、3、4、5，我得确定你干出来的不是1、2、3、4、5、6、7，还多出来2个。大家都知道你用word去解析一个文件，看一个文档的时候，是一个代码，具体怎么发生大家可能比较清楚的。

    一般来说，重点是通用的漏洞、Memory问题、堆溢出、栈溢出，还有各种各样的溢出，SQL、XSS和各种各样的validation。被黑客熟悉的除了我们耳熟能详的漏洞之外，还要关注其他的一些东西，比如说Access Control、information、加密方面的问题、认证方面的问题。一些软件安全工程师经常用加密技术，但是用错或者是设计上有一些东西出现错误。

Security Testing一般的方法就是以下这几种：

（1）White BOX：我们一般会用静态的源码扫描工具。通过对源代码的扫描，我们可以把源代码的某一个函数，某一个文件，某一行用了哪些不安全的东西，有哪些漏洞，有哪些缓存区域的漏洞等等，这些东西都能扫描出来。通过扫描把这些漏洞全部做出来以后，从源代码方面能够保证基本上保证常见的漏洞不会出现。 
（2）Black BOX：首先要灵活，会有很多的方法，比较好的有Injection Fuzzer和Dumb Fuzzer，后面会介绍它们之间的区别。
（3）Gray BOX

Part 2  Smart Fuzz Test

    Fuzz这个名词来自于Professor Barton Miller。在1989年一个风雨交加的夜晚，他登陆一台自己的主机，不知道怎么回事，信号通过猫传到主机上，雷电一闪，把里面的高位变低位，低位至高位了，结果到了主机以后改变了。他突发奇想，把这种方式作为一种测试的方式来做。

1、到底什么是Fuzz Test？

    Generally speaking fuzz is a brute force method which used to break software，就是用大量的测试用例一个一个试，尽可能多的找出有可能出问题的地方。

2、Fuzz怎么工作？
    现在有无数有名的Fuzz工具，有很多人很多还在写，一般包括四个部分。
（1）Generate lots of malformed data as test cases，要生成大量的测试用例。这个测试用力是malformed的，一个软件首先要找到输入点，然后把数据丢进去，这个数据有可能是一个文件，有可能是一个数据包，有可能是测试表里面的一个项，有可能是临时文件里面的一个东西，总之是一种数据，要定义malformed这种非正常的数据。
（2）Drop the test cases into product，把它丢进去，看这个产品怎么反应。
（3）Monitor and log any crash/exception triggered by malicious input.
（4）Review the test log, investigated deeply.

3、Injection Fuzzer和Dumb Fuzzer的区别

    下面我们说一下Dumb Fuzzer和Intelligent Fuzzer之间的区别。

    Dumb就是哑的，就是笨的意思。刚开始Fuzz的时候用的都是这种东西，直接把非法数据丢到软件里边去，这种东西很难真正测试出问题，因为很难把问题放到缓冲区去。比如丢一个Word，不能随便写一个文件，这就很难测试到真正问题，必须基本符合Word本身的文件格式，才有可能测试到结果。要考虑到软件本身执行的流程，你的case放进去，能够放到多深，逻辑放到多深，你要考虑这个问题。你要写这种程序的话，就要非常了解要测试的文档结构。

    什么东西可以被Fuzzed？文件格式可能出问题，数据包也可能出问题。因为数据包在解析数据包的时候也是一个状态机，放进去以后再看下一步到哪里去。抗组件这些东西也是相当容易出问题的。这么多东西，都是可以被Fuzz的。当然有一些东西也是可以被Fuzz的，我们现在说的集中是软件产品，硬件也可能有。

4、几个Fuzz工具

    简单介绍几个Fuzz工具，因为Fuzz的工具特别多，下面结合我在工作中的用到的一些东西，用最简单的方式介绍一下。

（1）Com Raidor

    对于ActiveX，一般来说，我们用的都是Com Raidor，它是非常简单，而且是免费的，它是Idenfense的产品。你只要选中，它里面有很多的项目。因为很多问题是针对IE的，它就会生成测试用例，会把脚本拿出来，一个一个的丢到IE里跑，接下来一直是这个状态。很简单，相信点几下鼠标就可以做。大家如果在测试的时候，其实跑一下也不费什么力。

（2）Fuzz网络协议——SPIKE

    SPIKE第一个提出格式化Fuzz的概念，而且提供了免费的、开源的工具，它发现了很多著名的漏洞。如果我要用SPIKE Fuzz一个文件的话就不是很简单了。Fuzz的时候，你要保证数据结构基本是正确的，不用完全对，完全对的话就不用Fuzz了。改一些小的地方，一次改一点点，一次改一点点，一次改一个地方或者几个地方，不要改太多，这样一丢，才能测试到东西。如果改的太多，最基本的条件没有满足，进去以后它就会走到其他分值区。这是一个结构化的最基本的原理。是要注重数据之间的结构，在这种情况下才能比较准确的找到问题。

    协议一般都有状态，第二个包过来，第一个包回去，第三个包过来，第四个包回去，可能是第三次组合的东西某一项才会触发漏洞。但是如果你从第一个包就开始胡乱的发，也许根本进行不到第三个包去了。所以说，协议Fuzz的文件要更麻烦一点。你要想把它送的深，送的远，送的逻辑远，覆盖的逻辑深，把东西丢到程序里面深一点，你得思考程序到底是怎么样执行的，你得想它控制的东西不是一个重复的。我想它已经不是一个纯黑盒测试了，要考虑程序里面是怎么运行的，还要考虑到程序的具体逻辑。

    本文主要内容整理自著名软件安全专家王清先生在2008中国软件安全峰会上的演讲，欢迎下载本文资料。

前后对比一下,阅读了一些书籍和材料总结到以下几点：

1. Junit写出来测试代码的基本骨架的样式大概就是下面的：(// 和/**开头那些都是为了方便理解而加的注释)

基本顺序就是

(1) import junit.framework.* 下面所有的类

(2) extends 用自己的测试类继承TestCase

(3) 初始化和释放资源的方法　setUp()和tearDown()

(4) 写一个构造函数用super 调用 父类构造函数

(5) test开头的测试方法。

(6) 定义testsuite，指定testsuite要执行的测试方法

(7)如果要在命令行下执行测试，需要用main函数指定待运行testsuite和一系列定义，以及运行方法和运行对象等等。

本文出自jaunty的软件测试博客，转载请保留出处及链接：http://jaunty.me/blog

下面就是按照这个骨架的基本代码模版:

package Skeleton;
import junit.framework.*;
 //change all occurrences of “skeleton” below
 // appropriate
public class TestSkeleton extends TestCase {
 /**
  * Pre-method test setup()
  */
 public void setUp(){
 }
 /**
  * Pre-Method tear down()
  */
 public void tearDown(){
  
 }
 /**
  * Add test here,
  * public void testxxx(){
  * }
  */
 public TestSkeleton(String name){
  super(name);
  
 }
 /**
  * Default suite method
  */
 
 public static Test suite(){
  return new TestSuite(TestSkeleton.class);
  
 }
 /**
  * main method only be invoked from command line.
  *
  */
 
 public static void main (String[] args){
  TestSuite suite = new TestSuite();
  if (args.length!=0){
   //Run specified test
   for (int i=0;i<args.length;i++){
    suite.addTest(new TestSkeleton(args[i]));    
   }
  }
  else {
   //discover all of them or use user defined suite
   suite.addTest(TestSkeleton.suite());
  }
  junit.textui.TestRunner.run(suite);
 }

}

上面这个模版用起来固然好，不过有个问题，就是复用性。假设我们都需要在setUp()下面作数据库联接。然后我们100个测试类都用这个模版。然后如果我们数据库的联接某天变了，那你就的在100个测试类里逐个的改去吧。

2. 可以写一个类专门来集合要测试的方法或者suite，然后可以指定来运行。

看下面一个小的范例：

import Example.ExampleHelloTest; //因为ExampleHelloTest在另外一个包里所以需要import进来
import junit.framework.*;
import pragmaticUnitTest.TestLargest;//因为TestLargest在另外一个包里所以需要import进来

public class TestSuiteComposite extends TestCase{
 public TestSuiteComposite (String  method){
 super(method);
 }

/**

*define composited testsuite

*/ 

static public Test suite(){
  TestSuite suite = new TestSuite();

// add all the test methods from ExampleHelloTest class.

  suite.addTestSuite(ExampleHelloTest.class);
//  add test suite from TestLargest class. 

suite.addTest(TestLargest.suite());
  return suite;
  
 }
}

基本结构就是ExampleHelloTest class定义了一系列的测试方法但是没有定义test suite.这里就把这个class里的所有的测试方法加进来。然后又把TestLargest class 里定义的suite加进来。实际上在TestLargest class里定义了10个测试方法。但是TestLargest class的suite只是指定了其中的2个来运行。因此在这个composite的class里我们运行顺序是先把ExampleHelloTest定义的所有测试方法执行然后再执行TestLargest class 里suite里限定的2个测试方法。

我个人感觉，这样把测试的执行操控放到一个class里来作是很方便也很容易修改的，毕竟只有一个接口。

因此对于第一大点提到的那个复用性的缺点。我个人感觉 其实我们可以把那些实际的一些需要复用又容易引起修改的，例如第一大点里数据库连接修改的例子，我们可以放在这个唯一入口的测试类的suite setUp()和tearDown()方法里。这样只需要改一次。这点是我自己设想的，还没有实践过。

本文出自jaunty的软件测试博客，转载请保留出处及链接：http://jaunty.me/blog

3. 这点是针对第2点提出来的。就是可以考虑不要直接用实际的测试类直接继承TestCase.可以一开始自己制定一个空的class继承TestCase。然后所有的测试都去继承这个自定义的基类。这样的好处也是一些公用的方法和处理的时候很容易就控制和修改了。

4. 运行单元测试的时候可以选择每次都运行所有的测试，一旦某个地方改了就把所有的测试都运行一遍以保证不会造成已经走了很远了发现出错，难究根源。但是对于一些非常耗时的test，可以选择隔断时间运行一次。

最后发发牢骚，以前也不知道谁说的java跟C#一样,可能是我coding太菜了，体会不到真谛，我感觉他们仅仅是一些所谓的特性或者原理一样而已，那些需要增加coding功底的细节，那些一句话就能考量出你深入这个语言多深的细节都还是很不一样的。至少我感觉跟我以前做过的C#的程序的一些编写的基本的细节还是不一样的。只不过说语言来来回回就那些事。主旨和思想来回就是那些但是精通的人却很少，毕竟想professional还是需要日月积累的。