随笔 - 26, 文章 - 0, 评论 - 12, 引用 - 0
数据加载中……

我的评论

re: java中获得系统路径 逃离开发 2006-03-07 13:03  
javax.servlet.FilterConfig
re: 开源测试工具——功能测试工具 逃离开发 2005-10-19 17:16  
1. 美国Segue公司的Silk系列产品
Segue公司一直专注于软件质量优化领域。在S
egue的产品套件中,拥有业内最强劲且最容易使用的、用于企业应用测试、调优和监测的自动化工具,能够帮助用户保障应用在其生命周期内的可靠性和性能。
(1) SilkPerformer——企业级性能测试工具
u 企业级自动化测试工具能够支持多种系统,如Java、.Net、Wireless、COM、CORBA、Oracle、Citrix、MetaFrame、客户机/服务器、以及各种ERP/CRM应用
u 多项专利技术精确模拟各种复杂的企业环境
u 可视化脚本记录功能及自定义工具简化了测试创建工作
u SilkPerformer的Java/.NET浏览器以及JUnit/NUnit测试输入功能简化了对并发访问情况下远程应用组件的早期负载测试工作
u 方便易用,工作流向导会逐步引导用户完成整个测试流程
(2) SilkTest International——业内唯一的Unicode功能测试工具
u SilkBean 充分利用 Java 语言的“编写一次,随处使用”的优点,让用户不必修改现有的脚本而能够在多种基于 Unix 的系统上运行
u 能够识别多种开发平台,如Java、JavaScript、HTML、ActiveX、Visual Basic 和C/C++等
u 一套脚本可供所有支持的语言使用
u 内置的错误恢复系统不仅具有自定义功能,可进行无人看守的自动测试
赛格瑞(Segue)公司是全球范围内专注于软件质量优化解决方案的领导者。2005年,赛格瑞(Segue)公司在中国设立了专门的销售服务公司,因此,赛格瑞(Segue)公司的软件测试产品在中国有了更好的技术支持。
参考网站:http://www.segue.com.cn/
推荐指数:★★★★★
2. MaxQ
MaxQ是一个免费的功能测试工具。它包括一个HTTP代理工具,可以录制测试脚本,并提供回放测试过程的命令行工具。测试结果的统计图表类似于一些较昂贵的商用测试工具。MaxQ希望能够提供一些关键的功能,比如HTTP测试录制回放功能,并支持脚本。
参考网站:http://maxq.tigris.org/
推荐指数:★★★☆☆
3. Httpunit
HttpUnit是一个开源的测试工具,是基于JUnit的一个测试框架,主要关注于测试Web应用,解决使用JUnit框架无法对远程Web内容进行测试的弊端。
HttpUnit提供的帮助类让测试者可以通过Java类和服务器进行交互,并且将服务器端的响应当作文本或者DOM对象进行处理。HttpUnit还提供了一个模拟Servlet容器,让测试者不需要发布Servlet,就可以对Servlet的内部代码进行测试。本文中作者将详细的介绍如何使用HttpUnit提供的类完成集成测试。
参考网站:http://www.httpunit.org/
推荐指数:★★★☆☆
4. Junit
是通用的测试 java 程序的测试框架JUnit可以对Java代码进行白盒测试。通过JUnitk可以用mock objects进行隔离测试;用Cactus进行容器内测试;用Ant和Maven进行自动构建;在Eclipse内进行测试;对Java应用程序、Filter、Servlet、EJB、JSP、数据库应用程序、Taglib等进行单元测试。
参考网站:http://www.junit.org/
推荐指数:★★★★★
5. Jtest
Jtest是Parasoft公司推出的一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个java类,然后自动生成junit测试用例并执行用例,从而实现代码的最大覆盖,并将代码运行时未处理的异常暴露出来;另外,它还可以检查以DbC(Design by Contract)规范开发的代码的正确性。用户还可以通过扩展测试用例的自动生成器来添加更多的junit用例。Jtest还能按照现有的超过350个编码标准来检查并自动纠正大多数常见的编码规则上的偏差,用户可自定义这些标准,通过简单的几个点击,就能预防类似于未处理异常、函数错误、内存泄漏、性能问题、安全隐患这样的代码问题。
JTest最大的优势在于静态代码分析,至于自动生成测试代码,当然生成测试代码框架也是不错的,但要做好单元测试用户还要做大量的工作。
参考网站:http://www.parasoft.com/jsp/aep/aep.jsp
推荐指数:★★★★☆
6. Hansel
Hansel 是一个测试覆盖率的工具——与用于单元测试的 JUnit framework 相集成,很容易检查单元测试套件的覆盖情况。
参考网站:http://hansel.sourceforge.net/
推荐指数:★★☆☆☆
7. Cactus
Cactus是一个基于JUnit框架的简单测试框架,用来单元测试服务端Java代码。Cactus框架的主要目标是能够单元测试服务端的使用Servlet对象的Java方法如HttpServletRequest,HttpServletResponse,HttpSession等
针对外部可测试组件运行时,需要把JUnit测试运行为发送HTTP请求给组件的客户端进程。为了在服务器容器内部运行JUnit测试,可以用Cactus框架,它是一个免费的开源框架,是Apache Jakarta项目的一部分。Cactus 包含了关于JUnit客户端如何连接到服务器,然后使测试运行的详细信息。
参考网站:http://jakarta.apache.org/cactus/
推荐指数:★★★★☆
8. JFCUnit
JFCUnit使得你能够为Java偏移应用程序编写测试例子。它为从用代码打开的窗口上获得句柄提供了支持;为在一个部件层次定位部件提供支持;为在部件中发起事件(例如按一个按钮)以及以线程安全方式处理部件测试提供支持。
参考网站:http://jfcunit.sourceforge.net/
推荐指数:★★★☆☆
9. StrutsTestCase
StrutsTestCase(STC)框架是一个开源框架,用来测试基于 Struts 的 Web 应用程序。这个框架允许您在以下方面进行测试:
u 在 ActionForm 类中的验证逻辑(validate() 方法)
u 在 Action 类中的业务逻辑(execute() 方法)
u 动作转发(Action Forwards)。
u 转发 JSP
STC 支持两种测试类型:
u Mock 方法 —— 在这种方法中,通过模拟容器提供的对象(HttpServletRequest、 HttpServletResponse 和 ServletContext),STC 不用把应用程序部署在应用服务器中,就可以对其进行测试。
u Cactus 方法 —— 这种方法用于集成测试阶段,在这种方法中,应用程序要部署在容器中,所以可以像运行其他 JUnit 测试用例那样运行测试用例。
参考网站:http:// strutstestcase.sourceforge.net/
推荐指数:★★★★☆
10. TestNG
TestNG是根据JUnit 和 NUnit思想而构建的一个测试框架,但是TestNG增加了许多新的功能使得它变得更加强大与容易使用比如:
u 支持JSR 175注释(JDK 1.4利用JavaDoc注释同样也支持)
u 灵活的Test配置
u 支持默认的runtime和logging JDK功能
u 强大的执行模型(不再TestSuite)
u 支持独立的测试方法
参考网站:http://testng.org/
推荐指数:★★★★☆
re: 把脉桌面 管理无忧 逃离开发 2005-09-14 14:43  

七种桌面管理产品:
Altiris公司的eXpress 5 -- 该产品提供了很好的集成磁盘映像管理特性;
Intel公司的LANDesk 6.4管理套件;
Microsoft公司的Systems Management Server 2.0 Service Pack 3;
Novell公司的ZENworks 3.0 -- Novell产品的机构的最佳解决方案;
Cognet公司的Cognet 3.5和myITware 4.0 -- 比较弱,但提供了一些特性:如软件应用描述文件,在测试的其他产品中没有发现该特性。
Tally Systems公司的TS.Census 1.2和 TS.Ready 4.0 -- 最好的库存管理产品,但它在软件计量(它不支持这种功能)等方面达不到要求
Vector Networks公司的LANUtil32和PC-Duo -- 是一款非常全面的产品,除了软件许可证计数功能外,它覆盖了所有的测试范围。
re: 关于OpenSessionInViewFilter 逃离开发 2004-11-18 15:16  
转自:Karl Baum's Weblog

Karl Baum's Weblog

All | General | Java


Thursday July 08, 2004
Lazy Initialization and the DAO pattern with Hibernate and Spring

Hibernate and Lazy Initialization

Hibernate object relational mapping offers both lazy and non-lazy modes of object initialization. Non-lazy initialization retrieves an object and all of its related objects at load time. This can result in hundreds if not thousands of select statements when retrieving one entity. The problem is compounded when bi-directional relationships are used, often causing entire databases to be loaded during the initial request. Of course one could tediously examine each object relationship and manually remove those most costly, but in the end, we may be losing the ease of use benefit sought in using the ORM tool.

The obvious solution is to employ the lazy loading mechanism provided by hibernate. This initialization strategy only loads an object's one-to-many and many-to-many relationships when these fields are accessed. The scenario is practically transparent to the developer and a minimum amount of database requests are made, resulting in major performance gains. One drawback to this technique is that lazy loading requires the Hibernate session to remain open while the data object is in use. This causes a major problem when trying to abstract the persistence layer via the Data Access Object pattern. In order to fully abstract the persistence mechanism, all database logic, including opening and closing sessions, must not be performed in the application layer. Most often, this logic is concealed behind the DAO implementation classes which implement interface stubs. The quick and dirty solution is to forget the DAO pattern and include database connection logic in the application layer. This works for small applications but in large systems this can prove to be a major design flaw, hindering application extensibility.

Being Lazy in the Web Layer

Fortunately for us, the Spring Framework has developed an out of box web solution for using the DAO pattern in combination with Hibernate lazy loading. For anyone not familiar with using the Spring Framework in combination with Hibernate, I will not go into the details here, but I encourage you to read Hibernate Data Access with the Spring Framework. In the case of a web application, Spring comes with both the OpenSessionInViewFilter and the OpenSessionInViewInterceptor. One can use either one interchangeably as both serve the same function. The only difference between the two is the interceptor runs within the Spring container and is configured within the web application context while the Filter runs in front of Spring and is configured within the web.xml. Regardless of which one is used, they both open the hibernate session during the request binding this session to the current thread. Once bound to the thread, the open hibernate session can transparently be used within the DAO implementation classes. The session will remain open for the view allowing lazy access the database value objects. Once the view logic is complete, the hibernate session is closed either in the Filter doFilter method or the Interceptor postHandle method. Below is an example of the configuration of each component:

Interceptor Configuration

<beans>
<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="interceptors">
<list>
<ref bean="openSessionInViewInterceptor"/>
</list>
</property>
<property name="mappings">
...
</bean>
...
<bean name="openSessionInViewInterceptor"
class="org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor">
<property name="sessionFactory"><ref bean="sessionFactory"/></property>
</bean>
</beans>
Filter Configuration

<web-app>
...
<filter>
<filter-name>hibernateFilter</filter-name>
<filter-class>
org.springframework.orm.hibernate.support.OpenSessionInViewFilter
</filter-class>
</filter>
...
<filter-mapping>
<filter-name>hibernateFilter</filter-name>
<url-pattern>*.spring</url-pattern>
</filter-mapping>
...
</web-app>
Implementing the Hibernate DAO's to use the open session is simple. In fact, if you are already using the Spring Framework to implement your Hibernate DAO's, most likely you will not have to change a thing. The DAO's must access Hibernate through the convenient HibernateTemplate utility, which makes database access a piece of cake. Below is an example DAO.

Example DAO

public class HibernateProductDAO extends HibernateDaoSupport implements ProductDAO {

public Product getProduct(Integer productId) {
return (Product)getHibernateTemplate().load(Product.class, productId);
}

public Integer saveProduct(Product product) {
return (Integer) getHibernateTemplate().save(product);
}

public void updateProduct(Product product) {
getHibernateTemplate().update(product);
}
}
Being Lazy in the Business Layer

Even outside the view, the Spring Framework makes it easy to use lazy load initialization, through the AOP interceptor HibernateInterceptor. The hibernate interceptor transparently intercepts calls to any business object configured in the Spring application context, opening a hibernate session before the call, and closing the session afterward. Let's run through a quick example. Suppose we have an interface BusinessObject:

public interface BusinessObject {
public void doSomethingThatInvolvesDaos();
}
The class BusinessObjectImpl implements BusinessObject:


public class BusinessObjectImpl implements BusinessObject {
public void doSomethingThatInvolvesDaos() {
// lots of logic that calls
// DAO classes Which access
// data objects lazily
}
}
Through some configurations in the Spring application context, we can instruct the HibernateInterceptor to intercept calls to the BusinessObjectImpl allowing it's methods to lazily access data objects. Take a look at the fragment below:

<beans>
<bean id="hibernateInterceptor" class="org.springframework.orm.hibernate.HibernateInterceptor">
<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>
<bean id="businessObjectTarget" class="com.acompany.BusinessObjectImpl">
<property name="someDAO"><ref bean="someDAO"/></property>
</bean>
<bean id="businessObject" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="target"><ref bean="businessObjectTarget"/></property>
<property name="proxyInterfaces">
<value>com.acompany.BusinessObject</value>
</property>
<property name="interceptorNames">
<list>
<value>hibernateInterceptor</value>
</list>
</property>
</bean>
</beans>

When the businessObject bean is referenced, the HibernateInterceptor opens a hibernate session and passes the call onto the BusinessObjectImpl. When the BusinessObjectImpl has finished executing, the HibernateInterceptor transparently closes the session. The application code has no knowledge of any persistence logic, yet it is still able to lazily access data objects.

Being Lazy in your Unit Tests

Last but not least, we'll need the ability to test our lazy application from J-Unit. This is easily done by overriding the setUp and tearDown methods of the TestCase class. I prefer to keep this code in a convenient abstract TestCase class for all of my tests to extend.

public abstract class MyLazyTestCase extends TestCase {

private SessionFactory sessionFactory;
private Session session;

public void setUp() throws Exception {
super.setUp();
SessionFactory sessionFactory = (SessionFactory) getBean("sessionFactory");
session = SessionFactoryUtils.getSession(sessionFactory, true);
Session s = sessionFactory.openSession();
TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(s));

}

protected Object getBean(String beanName) {
//Code to get objects from Spring application context
}

public void tearDown() throws Exception {
super.tearDown();
SessionHolder holder = (SessionHolder) TransactionSynchronizationManager.getResource(sessionFactory);
Session s = holder.getSession();
s.flush();
TransactionSynchronizationManager.unbindResource(sessionFactory);
SessionFactoryUtils.closeSessionIfNecessary(s, sessionFactory);
}
}

( Jul 08 2004, 09:39:55 AM EDT ) Permalink Comments [2]

Trackback URL: http://jroller.com/trackback/kbaum/Weblog/orm_lazy_initialization_with_dao
Comments:


A few things to keep in the back of your mind if you take this approach; 1. If any errors occur while attempting to lazy load relationships in the view (JSP) it would be hard to present a nice error to the user. 2. This would result in at least 2 hibernate sessions (db connections being open for any one request), so you might want to up the number of connections available. Cheers, Dan
Posted by Dan Washusen on July 08, 2004 at 09:02 PM EDT #

I am a little confused on why it would be difficult to show a nice error jsp. Couldn't we just use the provided servlet container error page mechanisms? In regards to the 2 hibernate sessions being opened. Are you saying that the OpenSessionInViewInterceptor would be run twice if an exception was thrown? Thanks for your feedback!
Posted by Karl Baum (63.170.158.133) on July 09, 2004 at 09:48 AM EDT #