Engine.js与util.js不同之处在于，util.js是静态js文件，可以直接从jar文件中拿出来，页面可以直接引用；而engine.js则有部分动态内容，这决定了它必须经过servelt资源请求，在servelt为动态内容赋值之后，才可以返回给客户端；

/** The original page id sent from the server */

dwr.engine._origScriptSessionId = “${scriptSessionId}”;

/** The session cookie name */

dwr.engine._sessionCookieName = “${sessionCookieName}”; // JSESSIONID

/** Is GET enabled for the benefit of Safari? */

dwr.engine._allowGetForSafariButMakeForgeryEasier = “${allowGetForSafariButMakeForgeryEasier}”;

/** The script prefix to strip in the case of scriptTagProtection. */

dwr.engine._scriptTagProtection = “${scriptTagProtection}”;

/** The default path to the DWR servlet */

dwr.engine._defaultPath = “${defaultPath}”;

/** Do we use XHR for reverse ajax because we are not streaming? */

dwr.engine._pollWithXhr = “${pollWithXhr}”;

这些变量值，会在页面每次刷新时，服务器会重新赋值；

一、下面是engine.js中一些变量和方法的解释:

1、 origScriptSessionId：

原始脚本sessionid,随每次刷新而改变；它与我们所说的httpsessionid是有区别的，httpsessionid是保存在服务器端，origScriptSessionId是保存在客户端的；

2、 dwr.engine._getJSessionId

得到我们所说的httpsessionid，这个id在整个会话生命周期内不变；

3、 dwr.engine._sessionCookieName

由_getJSessionId方法引用，用来获取httpsessionid的；

4、 scriptSessionId

页面sessionid，由origScriptSessionId加上一个随机数生成；它是客户端发给server的；每次发送值都不相同；

5、 preHooks

前钩方法 在dwr进行远程方法调用的之前调用

6、 postHooks

后钩方法 在dwr进行远程方法调用的之后调用；

7、 DWREngine.beginBatch()

开始批处理; 包装请求头

8、 DWREngine.endBatch()

提交批处理;

9、 rpcType

dwr的请求类型；

DWREngine.defaultMessageHandler(abc);默认的消息句柄;

DWREngine.setTextHtmlHandler;当接收到html时发生的事件;

DWREngine.setErrorHandler(abc); 默认错误句柄;

DWREngine.setWarningHandler(abc);默认警告句柄;

DWREngine.setTimeout(0); 超时时间设置,默认是0;

//三种调用方法;

DWREngine.XMLHttpRequest = 1;

DWREngine.IFrame = 2;

DWREngine.ScriptTag = 3;

DWREngine.setMethod(<1 or 2 or 3>);设置调用远程的方法;

DWREngine.setVerb = function(<’GET’ or ‘POST’>);设置发送数据的方法;

DWREngine.setOrdered(<true or false>);设置xhr的请求按顺序执行.<官方强烈建议不要用这个,会变的很慢而且无法预测.>

DWREngine.setAsync (<true or false>);设置xhr的请求方法是否异步?默认是true（异步）;

二、url对应的处理handler

1、 createUrlMapping(container, “/engine.js”, “engineHandlerUrl”, EngineHandler.class);

2、 org.directwebremoting.servlet.EngineHandler.java

继承了FileHandler，并且setDynamic(true);

首先根据/engine.js 从scriptCache 里取，如果没有的话根据/org/directwebremoting/engine.js,从classpath路径加载；从输入流每行过滤${}的字符，由LocalUtil类替换成真正的内容；

scriptCompressed ：是否保留javascrpt文件中的空行和注释;

Acegi通过AbstractSecurityInterceptor（Interceptor：拦截器）为安全对象访问提供一致的工作模型，它按照以下流程进行工作：

1． 从SecurityContext中取出已经认证过的Authentication（包括权限信息）；

2． 通过反射机制，根据目标安全对象和“配置属性”得到访问目标安全对象所需的权限；

3． AccessDecisionManager根据Authentication的授权信息和目标安全对象所需权限做出是否有权访问的判断。如果无权访问，Acegi将抛出AccessDeniedException异常，否则到下一步；

4． 访问安全对象并获取结果（返回值或HTTP响应）；

5． AbstractSecurityInterceptor可以在结果返回前进行处理：更改结果或抛出异常。

Acegi称受保护的应用资源为“安全对象”，这包括URL资源和业务类方法。我们知道在Spring AOP中有前置增强、后置增强、异常增强和环绕增强，其中环绕增强的功能最为强大——它不但可以在目标方法被访问前拦截调用，还可以在调用返回前改变返回的结果，甚至抛出异常。Acegi使用环绕增强对安全对象进行保护。

Acegi通过AbstractSecurityInterceptor为安全对象访问提供一致的工作模型，它按照以下流程进行工作：

1． 从SecurityContext中取出已经认证过的Authentication（包括权限信息）；

2． 通过反射机制，根据目标安全对象和“配置属性”得到访问目标安全对象所需的权限；

3． AccessDecisionManager根据Authentication的授权信息和目标安全对象所需权限做出是否有权访问的判断。如果无权访问，Acegi将抛出AccessDeniedException异常，否则到下一步；

4． 访问安全对象并获取结果（返回值或HTTP响应）； 5． AbstractSecurityInterceptor可以在结果返回前进行处理：更改结果或抛出异常。

安全对象和一般对象的区别在于前者通过Acegi的“配置属性”进行了描述，如“/view.jsp=PRIV_COMMON”配置属性就将“/view.jsp”这个URL资源标识为安全对象，它表示用户在访问/view.jsp时，必须拥有PRIV_COMMON这个权限。配置属性通过XML配置文件，注解、数据库等方式提供。安全对象通过配置属性表示为一个权限，这样，Acegi就可以根据Authentication的权限信息获知用户可以访问的哪些安全对象。

根据安全对象的性质以及具体实现技术，AbstractSecurityInterceptor拥有以下三个实现类：

l FilterSecurityInterceptor：对URL资源的安全对象进行调用时，通过该拦截器实施环绕切面。该拦截器使用Servlet过滤器实现AOP切面，它本身就是一个Servlet过滤器；

l MethodSecurityInterceptor：当调用业务类方法的安全对象时，可通过该拦截器类实施环绕切面；

AspectJSecurityInterceptor：和MethodSecurityInterceptor类似，它是针对业务类方法的拦截器，只不过它通过AspectJ实施AOP切面。

1．你点击一个链接访问一个网页；

2．浏览器发送一个请求到服务器，服务器判断出你正在访问一个受保护的资源；

3．如果此时你并未通过身份认证，服务器发回一个响应提示你进行认证——这个响应可能是一个HTTP响应代码，抑或重定向到一个指定页面；

4．根据系统使用认证机制的不同，浏览器或者重定向到一个登录页面中，或者由浏览器通过一些其它的方式获取你的身份信息（如通过BASIC认证对话框、一个Cookie或一个X509证书）；

5．浏览器再次将用户身份信息发送到服务器上（可能是一个用户登录表单的HTTP POST信息、也可能是包含认证信息的HTTP报文头）；

6．服务器判断用户认证信息是否有效，如果无效，一般情况下，浏览器会要求你继续尝试，这意味着返回第3步。如果有效，则到达下一步；

7．服务器重新响应第2步所提交的原始请求，并判断该请求所访问的程序资源是否在你的权限范围内，如果你有权访问，请求将得到正确的执行并返回结果。否则，你将收到一个HTTP 403错误，这意味着你被禁止访问。

在Acegi框架里，你可以找到对应以上大多数步骤的类，其中ExceptionTranslationFilter、AuthenticationEntryPoint、AuthenticationProvider以及Acegi的认证机制是其中的代表者。

ExceptionTranslationFilter是一个Acegi的Servlet过滤器，它负责探测抛出的安全异常。当一个未认证用户访问服务器时，Acegi将引发一个Java异常。Java异常本身对HTTP请求以及如何认证用户是一无所知的，ExceptionTranslationFilter适时登场，对这个异常进行处理，启动用户认证的步骤（第3步）。如果已认证用户越权访问一个资源，Acegi也将引发一个Java异常，ExceptionTranslationFilter则将这个异常转换为HTTP 403响应码（第7步）。可见，Acegi通过异常进行通讯，ExceptionTranslationFilter接收这些异常并作出相应的动作。

当ExceptionTranslationFilter通过Java异常发现用户还未认证时，它到底会将请求重定向哪个页面以要求用户提供认证信息呢？这通过咨询AuthenticationEntryPoint来达到目的——Acegi通过AuthenticationEntryPoint描述登录页面。

当你的浏览器通过HTTP表单或HTTP报文头向服务器提供用户认证信息时，Acegi需要将这些信息收集到Authentication中，Acegi用“认证机制”描述这一过程。此时，这个新生成Authentication只包含用户提供的认证信息，但并未通过认证。

AuthenticationProvider负责对Authentication进行认证。AuthenticationProvider究竟如何完成这一过程呢？请回忆一下上节我们所介绍的UserDetails和UserDetailsService，大多数AuthenticationProvider通过UserDetailsService获取和未认证的Authentication对应的UserDetails并进行匹配比较来完成这一任务。当用户认证信息匹配时，Authentication被认为是有效的，AuthenticationProvider进一步将UserDetails中权限、ACL等信息拷贝到Authentication。

当Acegi通过认证机制收集到用户认证信息并填充好Authentication后，Authentication将被保存到SecurityContextHolder中并处理用户的原始请求（第7步）。

你完全可以抛开Acegi的安全机制，编写自己的Servlet过滤器，使用自己的方案构建Authentication对象并将其放置到SecurityContextHolder中。也许你使用了CMA（Container Managed Authentication：容器管理认证），CMA允许你从ThreadLocal或JNDI中获取用户认证信息，这时你只要获取这些信息并将其转换为Authentication就可以了。

首先，我们要接触是UserDetails接口，它代表一个应用系统的用户，该接口定义了用户安全相关的信息，如用户名/密码，用户是否有效等信息，你可以根据以下接口方法进行相关信息的获取：

String getUsername()：获取用户名；

String getPassword()：获取密码；

boolean isAccountNonExpired()：用户帐号是否过期；

boolean isAccountNonLocked()：用户帐号是否锁定；

boolean isCredentialsNonExpired()：用户的凭证是否过期；

boolean isEnabled()：用户是否处于激活状态。

当以上任何一个判断用户状态的方法都返回false时，用户凭证就被视为无效。

UserDetails还定义了获取用户权限信息的方法：GrantedAuthority[] getAuthorities()，GrantedAuthority代表用户权限信息，它定义了一个获取权限描述信息（以字符串表示，如PRIV_COMMON）的方法：String getAuthority()。

在未使用Acegi之前，我们可能通过类似User、Customer等领域对象表示用户的概念，并在程序中编写相应的用户认证的逻辑。现在，你要做的一个调整是让原先这些代表用户概念的领域类实现UserDetails接口，这样，Acegi就可以通过UserDetails接口访问到用户的信息了。

UserDetails可能从数据库、LDAP等用户信息资源中返回，这要求有一种机制来完成这项工作，UserDetailsService正是充当这一角色的接口。UserDetailsService接口很简单，仅有一个方法：UserDetails loadUserByUsername(String username) ，这个方法通过用户名获取整个UserDetails对象。

Authentication代表一个和应用程序交互的待认证用户，Acegi从类似于登录页面、Cookie等处获取待认证的用户信息（一般是用户名密码）自动构造Authentication实例。

Authentication可以通过Object getPrincipal()获取一个代表用户的对象，这个对象一般可以转换为UserDetails，从中可以取得用户名/密码等信息。在Authentication被AuthenticationManager认证之前，没有任何权限的信息。在通过认证之后，Acegi通过UserDetails将用户对应的权限信息加载到Authentication中。Authentication拥有一个GrantedAuthority[] getAuthorities()方法，通过该方法可以得到用户对应的权限信息。

Authentication和UserDetails很容易被混淆，因为两者都有用户名/密码及权限的信息，接口方法也很类似。其实Authentication是Acegi进行安全访问控制真正使用的用户安全信息的对象，它拥有两个状态：未认证和已认证。UserDetails是代表一个从用户安全信息源（数据库、LDAP服务器、CA中心）返回的真正用户，Acegi需要将未认证的Authentication和代表真实用户的UserDetails进行匹配比较，通过匹配比较（简单的情况下是用户名/密码是否一致）后，Acegi将UserDetails中的其它安全信息（如权限、ACL等）拷贝到Authentication中。这样，Acegi安全控制组件在后续的安全访问控制中只和Authentication进行交互。

由于Acegi对程序资源进行访问安全控制时，一定要事先获取和请求用户对应的Authentication，Acegi框架必须为Authentication提供一个“寓所”，以便在需要时直接从“寓所”把它请出来，作为各种安全管理器决策的依据。

SecurityContextHolder就是Authentication容身的“寓所”，你可以通过SecurityContextHolder.getContext().getAuthenication()代码获取Authentication。细心观察一下这句代码，你会发现在SecurityContextHolder和Authentication之间存在一个getContext()中介，这个方法返回SecurityContext对象。SecurityContext这个半路杀出来的程咬金有什么特殊的用途呢？我们知道Authentication是用户安全相关的信息，请求线程其它信息（如登录验证码等）则放置在SecurityContext中，构成了一个完整的安全信息上下文。SecurityContext接口提供了获取和设置Authentication的方法：

u Authentication getAuthentication()

u void setAuthentication(Authentication authentication)

SecurityContextHolder是Acegi框架级的对象，它在内部通过ThreadLocal为请求线程提供线程绑定的SecurityContext对象。这样，任何参与当前请求线程的Acegi安全管理组件、业务服务对象等都可以直接通过SecurityContextHolder.getContext()获取线程绑定的SecurityContext，避免通过方法入参的方式获取用户相关的SecurityContext。

线程绑定模式对于大多数应用来说是适合的，但是应用本身会创建其它的线程，那么只有主线程可以获得线程绑定SecurityContext，而主线程衍生出的新线程则无法得到线程绑定的SecurityContext。Acegi考虑到了这些不同应用情况，提供了三种绑定SecurityContext的模式：

n SecurityContextHolder.MODE_THREADLOCAL：SecurityContext绑定到主线程，这是默认的模式；

n SecurityContextHolder.MODE_GLOBAL：SecurityContext绑定到JVM中，所有线程都使用同一个SecurityContext；

n SecurityContextHolder.MODE_INHERITABLETHREADLOCAL：：SecurityContext绑定到主线程及由主线程衍生的线程中。

你可以通过SecurityContextHolder.setStrategyName(String strategyName)方法指定SecurityContext的绑定模式。

乘飞机的过程最能体现安全控制的流程，我们可以从中找到身份认证、资源访问控制、领域对象安全控制的对应物：安检对应身份认证，登机对应资源访问控制，而按号就座则对应领域对象安全控制。

Acegi通过两个组件对象完成以上安全问题的处理：AuthenticationManager（认证管理器）、AccessDecisionManager（访问控制管理器）。

SecurityContextHolder是框架级的容器，它保存着和所有用户关联SecurityContext实例，SecurityContext承载着用户（也称认证主体）的身份信息的权限信息， AuthenticationManager、AccessDecisionManager将据此进行安全访问控制。

SecurityContext的认证主体安全信息在一个HTTP请求线程的多个调用之间是共享的（通过ThreadLocal），但它不能在多个请求之间保持共享。为了解决这个问题，Acegi将认证主体安全信息缓存于HttpSession中，当用户请求一个受限的资源时，Acegi通过HttpSessionContextIntegrationFilter（Integration：集成、整合）将认证主体信息从HttpSession中加载到SecurityContext实例中，认证主体关联的SecurityContext实例保存在Acegi容器级的SecurityContextHolder里。当请求结束之后，HttpSessionContextIntegrationFilter执行相反的操作，将SecurityContext中的认证主体安全信息重新转存到HttpSession中，然后从SecurityContextHolder中清除对应的SecurityContext实例。通过HttpSession转存机制，用户的安全信息就可以在多个HTTP请求间共享，同时保证SecurityContextHolder中仅保存当前有用的用户安全信息。

当用户请求一个受限的资源时，AuthenticationManager首先开始工作，它象一个安检入口，对用户身份进行核查，用户必须提供身份认证的凭证（一般是用户名/密码）。在进行身份认证时，AuthenticationManager将身份认证的工作委托给多个AuthenticationProvider。因为在具体的系统中，用户身份可能存储在不同的用户信息安全系统中（如数据库、CA中心、LDAP服务器），不同用户信息安全系统需要不同的AuthenticationProvider执行；诸如用户信息查询、用户身份判断、用户授权信息获取等工作。只要有一个AuthenticationProvider可以识别用户的身份，AuthenticationManager就通过用户身份认证，并将用户的授权信息放入到SecurityContext中。

当用户通过身份认证后，试图访问某个受限的程序资源时，AccessDecisionManager开始工作。AccessDecisionManager采用民主决策机制判断用户是否有权访问目标程序资源，它包含了多个AccessDecisionVoter。在访问决策时每个AccessDecisionVoter都拥有投票权，AccessDecisionManager统计投票结果，并按照某种决策方式根据这些投票结果决定最终是否向用户开放受限资源的访问。

一、 概述

对于任何一个完整的应用系统，完善的认证和授权机制是必不可少的。Acegi Security（以下简称Acegi）是一个能为基于Spring的企业应用提供强大而灵活安全访问控制解决方案的框架，Acegi已经成为Spring官方的一个子项目，所以也称为Spring Security。它通过在Spring容器中配置一组Bean，充分利用Spring的IoC和AOP功能，提供声明式安全访问控制的功能。虽然，现在Acegi也可以应用到非Spring的应用程序中，但在Spring中使用Acegi是最自然的方式。 Acegi可以实现业务对象方法级的安全访问控制粒度，它提供了以下三方面的应用程序的安全：

URL资源的访问控制

如所有用户（包括其名用户）可以访问index.jsp登录页面，而只有授权的用户可以访问/user/addUser.jsp页面。Acegi允许通过正则表达式或Ant风格的路径表达式定义URL模式，让授权用户访问某一URL匹配模式下的对应URL资源。

业务类方法的访问控制

Spring容器中所有Bean的方法都可以被Acegi管理，如所有用户可以调用BbtForum#getRefinedTopicCount()方法，而只有授权用户可以调用BbtForum#addTopic()方法。

领域对象的访问控制

业务类方法代表一个具体的业务操作，比如更改、删除、审批等，业务类方法访问控制解决了用户是否有调用某种操作的权限，但并未对操作的客体（领域对象）进行控制。对于我们的论坛应用来说，用户可以调用BbtForum#updateUser(User user)方法更改用户注册信息，但应该仅限于更改自己的用户信息，也即调用BbtForum#updateUser()所操作的User这个领域对象必须是受限的。

Acegi通过多个不同用途的Servlet过滤器对URL资源进行保护，在请求受保护的URL资源前，Acegi的Servlet过滤器判断用户是否有权访问目标资源，授权者被开放访问，而未未被授权者将被阻挡在大门之外。

Acegi通过Spring AOP对容器中Bean的受控方法进行拦截，当用户的请求引发调用Bean的受控方法时，Acegi的方法拦截器开始工作，阻止未授权者的调用。

对领域对象的访问控制建立在对Bean方法保护的基础上，在最终开放目标Bean方法的执行前，Acegi将检查用户的ACL（Aeccess Control List：访问控制列表）是否包含正要进行操作的领域对象，只有领域对象被授权时，用户才可以使用Bean方法对领域对象进行处理。此外，Acegi还可以对Bean方法返回的结果进行过滤，将一些不在当前用户访问权限范围内的领域对象剔除掉——即传统的数据可视域范围的控制。一般来说，使用Acegi控制数据可视域未非理想的选择，相反通过传统的动态SQL的解决方案往往更加简单易行。

从本质特性上来说，Servlet过滤器就是最原始的原生态AOP，所以我们可以说Acegi不但对业务类方法、领域对象访问控制采用了AOP技术方案，对URL资源的访问控制也使用了AOP的技术方案。使用AOP技术方案的框架是令人振奋的，这意味着，开发者可以在应用程序业务功能开发完毕后，轻松地通过Acegi给应用程序穿上安全保护的“铁布衫”。

1、  首先，我们在某个页面需要使用dwr功能时，需要引入
<script type=”text/javascript” src=”dwr/util.js”></script>
这样对”dwr/util.js”的请求，统一由org.directwebremoting.servlet.DwrServlet的doget（）、doPost（）方法来处理；

2、  dopost方法调用UrlProcessor的handle（）方法处理；
UrlProcessor的handle方法在执行时，先取得请求路径，然后根据请求路径，从urlMapping里取得相应的页面处理handler类，由这个handler类来处理请求和响应，也就是说”dwr/util.js”请求对应一个handler类来处理，”dwr/engine.js”由另外一个handler来处理，关于对engine.js的请求处理，我们在下一章里来讲解；
UrlProcessor的urlMapping类里的key 、value数据，是dwrservlet在container初始化时填入的；DefaultContainer――》setupFinished（）――》callInitializingBeans（）（这个方法是把container里的实现了InitializingBean接口的bean都执行了afterContainerSetup方法；UrlProcessor是实现了InitializingBean接口，它的afterContainerSetup方法，就是将DefaultContainer初始化时，初始的urlmapping值注入到自己的urlmap里）；

3、  dwr/util.js对应的处理handler
处理util.js的handler是：org.directwebremoting.servlet.UtilHandler
在org.directwebremoting.impl.ContainerUtill类里你可以看到，它们之间的对应关系
createUrlMapping(container, “/util.js”, “utilHandlerUrl”, UtilHandler.class);
UtilHandler继承了FileHandler，它寻找到jar下的util.js,然后以文件流的形式读入，最后作为响应输出到页面；通常只读取一次，因为在第一次读取时，它会把文件内容保存到一个map类型的scriptCache里，缓存起来；以后访问的时候就直接从scriptCache里取；
具体详细细节请参见FileHandler的public void handle(HttpServletRequest request, HttpServletResponse response) throws IOException方法；
Util.js作为静态js文件，适合于缓存起来，没必要每次都去从文件里读取，提高效率；

import java.lang.reflect.Field;

public class ReflectionTest{

public static void main(String[] args) throws Exception{

PrivateTest pt = new PrivateTest();

Class<?> clazz = PrivateTest.class;

Field field = clazz.getDeclaredField(”name”);

field.setAccessible(true);

field.set(pt,”world”);

System.out.println(pt.getName());

}

}

class PrivateTest{

private String name=”hello”;

public String getName(){

return name;

}

}

function suite()
{
 var testSuite = new top.jsUnitTestSuite();
 testSuite.addTestPage(”../test1.html”);
 testSuite.addTestPage(”../test2.html”);
 testSuite.addTestSuite(secondSuite ());

 return testSuite;
}
function secondSuite(){
 var testSuite = new top.jsUnitTestSuite();
   //取得浏览器访问参数的值，根据此值改变测试逻辑
//1) top.jsUnitParmHash.parameterName;
   //2) top.jsUnitParmHash[‘parameterName’];
   Var suiteToRun = top. jsUnitParmHash.suite;
   If(suiteToRun==’test1’){
   testSuite.addTestPage(”../test1.html”);
 }else{
   testSuite.addTestPage(”../test2.html”);
 }

 return testSuite;
}
十三、  Ant自动化测试
1、 修改jsunit下的build.xml文件
配置property属性
（1） browserFileNames：浏览器地址；多个可以用逗号隔开；
（2） closeBrowsersAfterTestRuns：执行测试后，是否关闭浏览器；默认true
（3） logsDirectory：日志存放目录
（4） url：测试文件地址；如：
   file:///c:/jsunit/testRunner.html?testPage=c:/jsunit/tests/jsUnitTestSuite.html
 
2、 运行ant standalone_test ，在单机上行运行测试；distributed_test：是分布式远程测试；

//向JsUnit框架显式暴露测试函数名
function exposeTestFunctionNames(){
 var tests = new Array();

 tests[0] = “testAdd”;
 tests[1] = “testMinus”;
 tests[2] = “testMultiply”;
 tests[3] = “testDivide”;

 return tests;
}
七、  setUpPage函数
此函数会在页面加载后首先执行，并且只执行一次，类似于JUnit4中的@BeforeClass注解
function setUpPage(){
 arg1 = 3;
 arg2 = 6;

//此行代码必须放置在setUpPage的最后，在完成资源加载后告诉JsUnit该函数已执行完毕
 setUpPageStatus = “complete”;
}
八、  测试实例
<script type=”text/javascript”>
function addNumbers(){
 var v1 = document.getElementById(”value1″).value;
 var v2 = document.getElementById(”value2″).value;
 var result = addTwoNumbers(v1, v2); 
 
 return result;
}

function addTwoNumbers(value1, value2){
 return parseInt(value1) + parseInt(value2);
}
function setUp() //类比于JUnit中的setUp
{
 document.getElementById(”value1″).value = 6;
 document.getElementById(”value2″).value = 7;

}

function tearDown() //类比于JUnit中的tearDown
{
 document.getElementById(”value1″).value = “”;
 document.getElementById(”value2″).value = “”;
}

function testAddNumbers(){
 var result = addNumbers();
 assertEquals(13, result);
}
</script>
<BODY>

<form>
<input type=”text” id=”value1″><br>
<input type=”text” id=”value2″><br>
<input type=”text” id=”result”><br>
<input type=”button” value=”Add” onclick=”addNumbers()”>

</BODY>
九、  日志跟踪
? 分3个级别：warn、info和debug
? 测试函数应用
function testAdd()
{
 var result = add(4, 2);
 assertEquals(6, result);
 warn(”result ” , result);
}
? 在testRunner.htmll里有显示日志级别跟踪的选择；
十、 Jsunit的测试套件
测试套件的函数名一定为suite；
function suite()
{
 var testSuite = new top.jsUnitTestSuite();
//增加的测试页面的路径是相对于测试运行器的路径的（testRunner.html），而不是相对于当前的页面
 testSuite.addTestPage(”../test1.html”);
 testSuite.addTestPage(”../test2.html”);
   //套件里还可以在包含套件
 testSuite.addTestSuite(secondSuite ());

 return testSuite;
}
function secondSuite() //需要与suite定义在同一个页面中
{
 var testSuite = new top.jsUnitTestSuite();

 testSuite.addTestPage(”../test1.html”);
 testSuite.addTestPage(”../test2.html”);

 return testSuite;
}