Web（前端）测试工程师 2人
岗位职责：

1. 负责淘宝网前端测试；
2. 设计前端测试方案及流程，并推广实施；
3. 提供自动化测试工具和自动化测试框架，帮助测试工程师提供测试效率和质量；

岗位技能：

1. 熟悉WEB开发技术，如java, DOM, HTML, Css, JavaScript
2. 熟悉软件测试，有丰富的自动化测试实施经验
3. 有良好的沟通能力和快速学习能力
4. 熟悉前端测试，包括性能测试，熟悉前端测试技术或框架者优先；

工作之前，更多的是在思索如何成为一名优秀的测试工程师。时儿清晰，时儿模糊，并循环在自己身上出现，折磨着，很痛苦。佛说：人来到这个世上就是受折磨的。好吧，神都这样说了，安慰下自己。

工作之后，从平时学习和日常测试的实践中，以及我们产品线情况，在想，我们测试人员应该站在哪些角度上去保证软件质量？现在想到是三个方面。

1，从业务逻辑上着手。

这点很容易明白，业务是系统功能的一种体现形式如果，如果对业务逻辑了解清楚，不管系统有多复杂，也不管系统有多大，对那些熟悉业务的人来说，可以设计出质量高的测试用例，进行一次成功的测试。很喜欢的一句话，就是专业知识是测试人员的左脚，业务知识是测试人员的右脚，也就是这个道理。在测试道路上能走多远，就看左右脚有没有力了。

2，从用户体验上思考

在软件工程上，并不认为开发人员去自己测试他们的代码是一种好的方法。人很多时候很固执，总认为自己写的代码没有问题，特别是作技术的人。很多测试人员，很多时候或许仅仅是从测试角度去测试一个系统，根据特定的流程，特定的方法等等，去完成一个系统的测试工作，如果测试结果通过测试，测试达标就ok了。但我们很多时候忘记了从用户体验上去思考某个功能的使用，某个页面的样式。。。特别是我们淘宝的应用，系统体验好不好，很大程度是关系到我们的PV和用户数量，我们是否在测试时，考虑下这方面，虽然这些不是功能或性能上的缺陷。

3，从系统架构上把握

这点是在工作之后给我的灵感。以前只是想到1，2两点，但仅仅是从上面这两点去做，能保证软件的质量么？

这是谁也不敢保证的。如果要解剖一头牛，你得要非常了解牛的架构是怎样的。同样，如果我们要保证软件系统的质量，我们也要非常了解软件系统的架构，这样，我们才胸有成竹，有的放矢。可以从一个更高的视角，保证软件的质量。有一句诗词叫作：会当凌绝顶，一览众山小。当站在一个更高的角度看事物时，我们的视角才宽广，才更全面。软件测试也是如此，当你对一个软件系统的实现结构了如指掌后，你就可以清楚地知道这个系统哪里是最弱的，哪里是最强的，哪些地方是最需要关注的，哪些地方需要做性能测试，哪些地方可以使用自动化介入，从而采用最好最适合的测试策略。

ok，就这样先，好好学习，天天向上。。。

献给对软件测试有着很傻不拉机感情的人们。更多blog，请移步至：http://cuckoo2010.blog.163.com/

2009，从学校走了进来。。。

或许在同学们眼里，似乎一切都很美好，在校期间就已经在中国普天实习，考完大学里最后一次考试不到一个月就来到现在的公司上班。。。

可他们并不知道，期间我与一些机会错过，现在回想起来，常常痛恨自己。其实他们个个都很优秀，都很聪明。在摸着石头过河的日子里，很多人在一场轰轰烈烈的爱情里，在一次次游戏的撕杀中，或许在河里迷了方向。很感谢同寝的其他舍友，因为有他们在，自己没有迷失，我们在一起努力过。

刚来公司，仅仅是对测试的固执而选择了测试，如果当初听从经理的安排，去做公司的网站，也许就不会错过1月份那次机会。不过有失必有得，经过这段时间的测试工作，让我明白很多。这些是无法从学校学到的。

佛说，有因有果。如果我现在的得是因为昨日的努力，那我想，自己现在的失也是因为昨日没有努力深入。2010了，恰遇虎年，对我来说是最为关键的一年，一定要虎虎的，每天都要进步。如果在三到四年内没能在测试领域有所作为，四年后也就别再想了，回家种红薯去！

虎年，一定要虎虎的，也祝我的同学们心想事成！

前段时间，junit annotation让我无言了一回，白疼了他两年，郁闷

junit 现在已经开发到了4.8.1版本，在这个版本中，共有19个annotation。最常用到的也有十来个。下面是无言之后写的一个junit 程序。没做什么功能，细心看，或是自己写一遍，或许那天，你就会用得上。

package com.junit.annotation;

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Assert;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Ignore;
import org.junit.Rule;
import org.junit.Test;
import org.junit.experimental.theories.DataPoint;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.rules.TestName;
import org.junit.runner.RunWith;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assume.assumeThat;;

@RunWith(Theories.class)
public class AnnotationTest {

 @Rule
 public TestName testname = new TestName();
 
 @DataPoint
 public static String dPoint = "I love JUnit!";
 
 //测试@BeforeClass批注，在整个测试类中只运行一次，有别于@Before。
 //test the @BeforeClass annotation
 @BeforeClass
 public static void testBeforeClass() {
  System.out.println("BeforeClass");
 }
 
 //测试@Before批注，在每个测试方法运行前执行该方法。
 //test the @Before annotation
 @Before
 public void testBefore() {
  System.out.println("Before");
 }
 
 //测试@Test批注。
 //test the @Test annotation
 @Test
 public void testMethod() {
  Assert.assertEquals("testMethod",testname.getMethodName());
  System.out.println("testMethod");
 }
 
 //测试@Theory批注。
 //test the @Theory annotation
 @Theory
 public void testDataPoint(String interests) {
  //interests必须是I lvoe JUnit!，否则跳过该测试函数。
  //interests must be I lvoe JUnit!, or skip the test function.
  assumeThat(interests, is("I love JUnit!"));
  Assert.assertEquals("testDataPoint",testname.getMethodName());
  System.out.println("testDataPoint"+"\n"+dPoint);
 }
 
 //测试@Ignore批注
 //test the @Ignore annotation
 @Ignore
 @Test
 public void testIgnore() {
  Assert.assertEquals("testIgnore",testname.getMethodName());
  System.out.println("testIgnore");
 }
 
 //测试@After批注，每个test方法执行完成后运行此方法
 //test the @After annotation
 @After
 public void testAfter() {
  System.out.println("After");
 }
 
 //测试@AfterClass批注，在整个测试类中只运行一次，有别于@After
 //test the @AfterClass annotation
 @AfterClass
 public static void testAfterClass() {
  System.out.println("AfterClass");
 }
}
执行完，测试通过，从下图可以知道@Ignore的作用吧

  

再看下控制台中输出的信息

从上图可以得知，标的@BeforeClass和@AfterClass的测试方法只执行了一次，而@Before和@After在每个标有@Test方法执行前后都会执行一次。这也是这几个annotation的区别。

而@Rule这个annotation这里只说了一种用法，还有其它七种用法。

附上项目结构图

这段时间在看一本测试驱动开发的书，是极限编程创始人Kent Beck写的，非常不错。让测试程序运行起来，之后再消除那些重复设计，最终使代码整洁可用（clean code that works）。呵呵，还没看完，没悟到什么。纯属瞎扯蛋！

OK，洗洗睡了，明天上班。

java开源大全，里面有非常全面的java方向内容介绍，不管你是开发还是测试，检验下自己会多少东东。网站为：http://www.open-open.com/

网站有直接的链接，别忘记从链接进入官网，那有权威的Documentation！

       记得年少时，第一次看神雕侠侣，每到动情悲伤处，总会被感落泪，从此便喜欢上了倜傥不羁，重情理义，敢爱敢恨的杨过，也从那时起，迷上了金庸先生的武侠世界，更加向往那如画的江南。在金庸的“射雕三部曲”中，郭靖重礼，杨过重情，张无忌重义；但是相比之下，杨过是最有强势独立主见的一个角色，也是金庸笔下人生经历最为坎坷，多磨的大侠之一。

      在金庸先生笔下，每个主角都有这样那样的奇遇，从而学到至高无上的武功，千里传音，摘花夺命。可谁又能像杨过一样，在学到众家的武功后，自创出一套手法与寻常武功大异，武学通理相反，古怪之极，令敌琢磨不定的黯然销魂掌，终成一代武学大家，位列西狂！

     学百家之所长，以成己之专。如果你爱测试，何时列位。荒废，无稽之谈，哈哈，笑痴。。。

      

在深圳已经上班两周了，做的是自己喜欢的工作——软件测试

但不知道为什么，仍然离不开写java，struts，hibernate，spring，junit，maven，cactus，jetty，qtp，loadrunner，bugfree，qc，perl，python，ruby。。。。一连串熟悉喜欢的字符

我现在终于明白，自己要的是什么了。。。

加油吧，为那梦想能尽快实现

发现个人空间中有些地方存在bug

一，bug重现

第一个bug，是在日志模块中的“上一篇/下一篇”。空间主人发表多篇日志后，在空间首页按时间的先后倒序显示，即最后发布的日志显示在最上面。按照页面的显示排序，此时最后发布的日志为第一篇，最先发布的日志为最后一篇。如果阅读者从第一篇日志开始阅读，阅读后第一篇在想进入下一篇时，如果点击“下一篇”，这里就有问题了，页面转向是的最后发布的日志，也就是第一篇，而不是下一篇。如果你想阅读下一篇日志，得点击“上一篇”。这不符合人们的使用习惯，按照软件的易用性测试中的定义，是算一个bug的。

第二个bug，也是出自在日志模块中的“上一篇/下一篇”中。现在我们可以忽视第一个bug的存在，通过不停地点击“上一篇/下一篇”，不管是到达第一篇还是最后一篇，都没有相关提示信息。如果到达第一篇时，阅读者想再继续阅读最新的日志，是否应该弹出相应提示信息，如“当前已经是第一篇”，最后一篇也一样。这样处理更加人性化。

第三个bug，第三个bug是出现在日志模块和文件模块之间的切换中。点击导航菜单中的“日志”进入显示日志页面，这里即便是忽视第一个bug，如果日志A，文件B，日志C发布的时间由后自前时，在阅读后日志A后想阅读日志C，点击“上一篇/下一篇”时，页面跳转到文件B中，在文件模块中也一样。这是一个较明显较严重的bug。

名词解释：

1，上一篇：某一篇文章的前一篇，以当前一篇的方位为参照物。（嘿嘿，自己瞎编的）

2，下一篇：某一篇文章的后一篇，以当前一篇的方位为参照物。（嘿嘿，自己瞎编的）

3，bug：英文意思为臭虫，是指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。

二，bug分析

在个人空间的日志和文件模块中，所有日志和文件都是以发布的时间先后进行倒序显示，先来看看“上一篇”和“下一篇”的链接，如图：

“上一篇”截图：

“下一篇”截图：

itemid是指当前日志或文件的编号，uid是指个人空间用户的编号，它们都是唯一的。以这两个条件为前提，再通过up或next查看相应的日志或文件。但所有日志和文件都是以发布时间的先后进行搜索。或许，设计者的设计思路是同一个用户不可能在同一个时刻内发布大于两篇的日志或文件。但如果真的出现用户在同一个时刻发布了大于两篇的日志或文件，在此时点击“上一篇”或“下一篇”时会出现什么情况了。

当一个软件和数据库连接搭上关系，数据库的设计就尤为重要了。如果数据库没有设计好，势必影响整个软件功能的实现。

嗯，就到这先啦，呵呵，本想给个测试用例的，但必竟不是自己的网站，说太多可能不太好，明白人一看也大概清楚了。我只是对bug太过于敏感。哎。。。学软件测试的，就这缺点，想改却改不了。

仅仅是出于对测试的喜爱，以及对空间的发展，写了这篇东东，并无他意，如有冒犯，请和本人联系，我自会删除本日志。

今天，学院校庆。。。

今天，天空下雨。。。

今天，我拒签了。。。

第一次拒签，公司是深圳一家光电方面的外资公司。同学说我，你怎么那么傻，这样你不是可以回家那边工作么？老师说我，你要想清楚，大专生找一份好工作是很难的。

离家近是什么概念？离家近就意味着可以天天回家么？

如果你有时间，再远也可以回家；如果你没时间，再近也回不了家。大禹为了治水，三过家门而未进。。。

我深知自己只是区区一个大专生，这段时间在华科武大参加校招的经历已经让我意识到这点。但并不畏惧，因为我已经知道我与他们的差距在哪，我自信可以赶上，我更自信自己在专业上的优势。

在签约办公室里，我也是很矛盾。到底要不要签，但我始终下不了笔。我告诉自己，你的最爱是软件测试么，你的强项不在光电。软件测试是你从一开始就确立好的目标，你不是规划好了将来么。

决定不签的那一刻，我感觉很轻松，因为我知道自己的将来想要的是什么。我更加期待下周能实现，那个曾在高中时就想实现的梦想，还有那老子，曾经找了几年的《道德经》。。。

我不停地告诉自己，你要的不仅仅是一份工作，而是一种事业。不要轻易放弃自己的梦想，不管以后的路有多辛苦，有多难。。。

十年铸剑，只为冲天一啸。我相信自己，不管以后的路有多么艰难。

我的测试，我的梦想，期待着下周，能实现高中时的梦。。。

今天新装上LoadRunner 9.5版本的，破解成功，支持web 10000 的Vuser。好爽，把上次测试的博客网整崩溃了，大家一起来玩下啦。

网上的方法大多一样。用两个dll文件覆盖bin中的同名dll文件，再删除注册表中的相关地方，最后加上License。但我跳过了注册表这步，也可以成功加上golba-100的License，但web 10000的加不上。在注册表里玩了下，先前我装过8.1版本的，删掉一些后，就可以加上web 10000的了。之后又删掉，再试了几次，搞定。这里提供破解所用到的两个dll文件，大家可以试试啦，很好玩的。

装好后，我模拟1000个Vuser，每隔10秒初始200个Vuser
和运行100个Vuser，事务失败达到6000个，成功仅仅3447个。登录事务响应时间达到18.75秒，数据没有完全插入数据库中，在tomcat后台抛了内存不足，500等错误，运行时基本打不开博客网，连tomcat的主页也打不开。CUP使用率达到60%以上，PF使用率达到1.15GB，笔记本电脑嗡嗡作响，这下可有得搞头了，继续，得把测试方案再修改下。

第一步：用LR8.0中的mlr5lprg.dll、lm70.dll覆盖LR9.1（9.5）安装目录下“bin”文件夹中的对应文件;

第二步：手动修改注册表，删除下面内容

[HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\LoadRunner\License2]

[HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\LoadRunner\License2\History]

"AIBGEBFW-JVED-ZKEKEKEKEKEBDNQAF-KBRDN"=""

[HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\LoadRunner\License2\PermanentLicense]

@="AIBGEBFW-JVED-ZKEKEKEKEKEBDNQAF-KBRDN"

"last"="AIBGEBFW-JVED-ZKEKEKEKEKEBDNQAF-KBRDN"

[HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\LoadRunner\License2\TemporaryLicense]@="AEBGEBFS-AKEKEKEKE-KAUCA"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{87B3ADD4-21EB-11d5-93EF-00105AA0FD2D}]

@="IControl"

第三步：添加下面的licence，即可使用。

golba-100: AEAMAUIK-YAFEKEKJJKEEA-BCJGI

web-10000: AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB

声明：仅用于学习，商用请使用正版软件。感谢HP公司！

MILY: 宋体; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: 宋体; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-ascii-font-family: Calibri; mso-hansi-font-family: Calibri">导读

经过前面的测试，我们通过了测试并得到了测试数据。此时，可以通过LR的Analysis模块进行操作。Analysis是一个独立的模块，它可以将测试结果和监控数据转化为数据库数据，以利于分析处理。测试人员可以在分析器中选择感兴趣的图表，通过合并图，交叉图和自动关联等手段，对测试结果和监控数据进行分析处理。以确定性能瓶颈及其产生的原因。最后，可以选择有价值的部分图，自动生成HTML和Word格式报告， 这些报告可以作为附件和测试测试报告一起提交，提供性能参考。

详细分析

场景运行 结束后，必须手动打开Analysis，Analysis启动时，会自动收集本地计算机上的结果数据，如果压力产生器在远端机器上，又没有选择自动收集数据，则会先收集测试结果数据。打开后如下图所示:

在上图中，带红点的是打开自动生成的图表，没有红点的则是通过合并图，筛选等手段添加上的。Analysis上图形主要分为四大类，分别是Vusers，事务，Web资源，网页分析。通过不同的需要选择不同的图来分析。下面主要讲几个重要的图及相关操作。

一，相关图的解说

1， Vuser图，如下图所示：

此图是经过筛选操作后得到的Vuser图，显示了所有Vuser在测试期间的每一秒内，执行Vuser脚本的Vuser的数量及它们的状态。如果想了解单独一个Vuser的状态，也可以将筛选条件设置您想了解的VuserID。具体操作步骤是：在Vuser图内单击鼠标右键，选择菜单中的“设置筛选器/分组方式”，在弹出的设置框中进行设置即可。如下图所示：

用筛选方式可以搜索到特定的Vuser在不同时刻的数据，方便性能分析，初学者要好好掌握。此方法可以运用到对其它图的操作上，以后对筛选的操作就不再具体描述了。

2， 事务图。事务图主要包括平均事务响应时间图，每秒事务数图，每秒事务总数，事务概要图，事务性能概要图，事务响应时间（负载下）图，事务响应时间（百分比）图，事务响应时间（分布）图。

这里就拿事务响应时间（百分比）图来分析。它可以帮助测试人员分析在给定时间范围内执行的事务的百分比和确定合适的事务百分比，以判断是否满足系统的性能标准，通常情况下，您需要在可接受的响应时间范围内，确定事务百分比，最大响应时间可能非常长，但如果大多数事务具有可以接受的响应时间，则整个系统还是适用的。来看看具体的图：

 

上图是所有用户的全部事务的响应时间百分比，可以通过筛选功能，筛选出具体的用户和事务进行分析；用向下搜索功能提炼出更加精确的数据，以便好地进行性能分析，定位系统的性能瓶颈，此操作在相应的图中单击鼠标右键，选择“向下搜索”，在弹出的设置框中设置相应选项就可以了。我这里就用Vuser9分析

 

经过LR的筛选功能可以得到更多精确的图，就可以很清晰很方便地分析出系统是否存在性能问题了。用性能下降曲线分析法，从上图可以看到，发布博文事务曲线非常平滑，最大响应时间为0.999秒，是属于非常好的现象，其它事务随着负载用户数量的增大，出现相应的波动，从而可以分析性能问题所在。从图中可以看到，一条曲线可以分为以下几个部分：

（1）性能平坦区——在不进行更多性能调优情况下所能期望达到的最佳性能。这个区域可被用作基线或是benchmark。

（2）压力区域——应用“轻微下降”的地方。典型的、最大的建议用户负载是压力区域的开始。

（3）性能拐点——性能开始“急剧下降”的点。

这几个区域实际上明确标识了系统性能最优秀的区间，系统性能开始变坏的区间，以及系统性能出现急剧下降的点。对性能测试来说，找到这些区间和拐点，也就可以找到性能瓶颈产生的地方。因此，对性能下降曲线分析法来说，主要关注的是性能下降曲线上的各个区间和相应的拐点，通过识别不同的区间和拐点，从而为性能瓶颈识别和性能调优提供依据。

 

在其它图中，还可以使用LoadRunner中的自动关联确定造成服务器或网络瓶颈的原因。自动关联功能应用高级统计信息算法来确定哪些度量对事务的响应时间影响最大。操作步骤是：单击“关联选项”选项卡，选择要将哪些图的数据与相应事务关联，如下图所示：

 

除了上述操作外，还可以进行其它操作，如比较不同场景的结果，如果你执行了多个场景的话。最后根据用户选择感兴趣的图表，生成HTML或Word格式及其它格式的报告。此次测试的报告我已经上传到博客上了，感兴趣的朋友可以下载看看，谢谢大家的支持。根据测试结果分析数据与事先设计好的测试用例或需求说明书对比，验证测试是否通过，不通过则分析系统性能瓶颈出在哪里。OK，图表就分析到这了。 

二，相应服务器性能分析

1， tomcat分析

我这里用的是Lambda Probe来实现的，来看看在运行场景时，tomcat的性能，如下图：

从图中两个表中可以看出，要相同的时间内。每30秒的用户数和执行的事务数整体上是一致的，并没有影响系统整体性能，数据库中也成功在插入了相应数据，如下图：

在脚本运行设置中，我设置了6个迭代，这里也成功插入了6条数据，再结合事务响应时间（最大为0.999秒），说明这块的性能是通过测试的。这里想加一句，一个没有发现bug的测试，算不上是一个成功的测试。因为软件测试的目的就是要找到bug，如果有条件，尽量把并发的Vuser设多，能把系统搞崩溃最好，这样就可以提取更有价值的数据，从而分析出系统的瓶颈，解决性能问题。

2， MySQL数据库服务器分析

MySQL数据库服务器性能主要参考tomcat中的status可以获得相应数据，只要tomcat用户管理文件配置成功，就可以走入了，地址为：http://localhost:8080/manager/status  如下图:

在运行场景中，这里会记录所有数据插入的信息，通过这些信息，分析其性能。

如果出现性能问题或现在的性能不符合需求规格说明书上所需求的，则超需要进行性能调优了。针对不同性能问题，实施不同的策略，如存储空间不足，则可以增加大容量硬盘；内存不足就补内存；服务器问题则可以采用集群等等，但每种都不是单独考虑，要考虑到成本，风险等问题。不能说存储空间不足，就恶补大容量硬盘，这种方法不完全正确的。

 

此次测试的感想

         做性能测试比做功能测试是难很多的。

第一，  如果系统应用复杂，功能众多的话，就需要进行大量的测试工作，工作量庞大，试想我这里只是测试了登录和发博文两个功能，还有其它功能都还没有测试呢。

第二，  Web脚本如何开发。不想认为仅仅通过录制就可以解决脚本问题，在一些特定的环境下，要测试人员开发大量的脚本，涉及高级算法，语言等知识。

第三，  场景数据出来后，如何分析。分析测试数据是一个很头痛的问题，其它涉及到的东西且不说，光是那庞大的数据量就可能让你窒息了。像阿里巴巴，淘宝这样的网站，数据都是海量级别的。

第四，  性能问题不仅仅关系到软件本身，还与服务器，网络，存储空间，I/O等等有关。

…………

性能测试工程师职位是具体有挑战性的，如果你想成为一个优秀的性能测试工程师，必须有牢固的开发测试基础，广阔的知识面，良好的分析问题和解决问题的能力，等等。上下不断求索吧。

OK，关于LoadRunner自动化测试就到这了。LoadRunner中自带有一个测试web项目，地址是http://127.0.0.1:1080/mercuryWebTours  开启服务器后，用注册用户名和密码进入。大家可以自己动手试试，尽量整出点性能问题来，学IT，很多时候BUG和异常可能成为你技术提高的源泉。谢谢大家的支持，不足之处，请大家谅解和提示。

 

MILY: 宋体; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: 宋体; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-ascii-font-family: Calibri; mso-hansi-font-family: Calibri">导读

经过上篇的准备，现在我们来具体用LR来测试一个博客后台页面的登录及发布博文的测试，我这使用的LoadRunner时8.1版本的，所支持的虚拟用户数最大是24个，所以我在测试时用了20个。OK不多说，现在开始吧，来看看自己写的博客性能到底如何。

一些说明

         系统信息：个人博客系统1.0版，所用到的技术jsp+javabean+servlet，数据库是  MySQL 5.1，服务器是tomcat 6.0.20，开发工具是MyEclipse 8.0M1

         测试工具：LoadRunner 8.1

         操作系统：XP professional sp3

录制脚本

         打开LR后，进入负载测试界面选择“创建/编辑”，在这个界面中选择“新建Vuser脚本”后会弹出让你选择协议的确认框，如图所示

        

         因为我们所测试的是web项目，所以在这里我们要选择“Web（HTTP/HTML）”协议，确定后进行入Virtual User Generator功能模块。此时会弹出“Start Recording”录制设置窗口，

         这里除了要选择Applcation type（我们要选择 Internet Applcation），正确填写被测网站地址，选择相应 Record into Action 外，还需特别注意 “选项”Options这个按钮。这是录制选项

         设置的地方。这里本人建议最好点开，在弹出的录制设置窗口中在Internet Protocol中的Advanced上选择支持UTF-8选项，这样做的好处是可以避免出现录制脚本中出现中文乱码。

         如下图所示

        

         录制设置做好后，就可以开始录制了。

         在录制登录脚本和发布博文操作时，需要特别注意的一个地方的，在进入博客后台管理页面后，在正式登录前可以增加一个事务，事务名要取个有意义的名称，增加脚本的可读性。

         这里加一个事务是有特别的用处的，可以在此操作添加集合点，在后面的场景中设置循环，实现用户并发操作。设置开始事务登录成功后，一定要设置结束事务操作，这点请大家一

         定记住，下图是我的事务设置（login）

 

登录成功后，再新建一个发布博文的事务（putout_blog），在退出博客管理后台时也与前两种方法一样，新建一个退出的事务（out_blog）。退出到博客首页后关闭浏览器，停止脚          本的录制，返回到Virtual User Generator脚本编辑界面。

脚本编辑

         OK，录制完成啦，现在可以对脚本进行编辑了，对于这个，我不得不说LR的强大，这也是我爱上LR的原因之一，就像当年爱上MyEclipse一样。脚本和程序一样，要有良好的风格，

         必要的注释。对每个事务进行注释，以便以后修改。这方面不做过多的文字描述。

         首先，你可以点击“编译”按钮编译下，检查录制的脚本有没有错误。接下来，我们来看看脚本，在事务中我们可以看到一个这样的函数lr_think_time(1234)，这就是在上篇中提到的

         思考时间，对这个函数，在事务中尽量注掉或者把时间改小，以免影响后面的响应时间，我们也可以在打开平均事务响应时间表等相关表设置中去掉思考时间。但在实际工作中的性能测试，思考时间是一个值得测试人员思考的问题。

         其次，使用参数化对登录username和password设置不同的值，实现以不同的用户身份进行登录。在LR中，参数设置方式有多种，都可达到一样的效果，我这里就拿一种来说下。

         点击工具栏上的“打开参数列表”点击“新建”按钮，设置相应名称，我的是loginusername，loginpassword，选择适当的参数类型，选择文件路径时把dat类型改为txt，不改也行这个是个人的爱好，点击“添加行”或“添加列”，输入相应的值，在更新值的时间处选择适当的方式。设置好后，可以通过右击鼠标，选择“参数属性”，验证是否已经设置成功。我的设置如下图所示：

     

         请注意上图中的红色字体部分，很重要。设置好参数后，在要定义的value后面选择对应的参数，单击鼠标右键，在“使用现有参数”中选择刚刚设好的参数就OK了。以上的我是对登录事务的参数设置，也可以在发布博文中用同样的设置，这里不再重复。

    还可以在登录事务中设置集合点，设置方法不难，只需在事务前加上lr_rendezvous("login_gather");函数就行了，login_gather是集合点名称,在以后的场景设置中可以再详细设置。还有可以在录制时先做好相应关联等等。

对脚本编辑好后，点击工具栏上的“编译”按钮，对脚本进行编译，以验证刚刚对脚本的修改有无错误，确保下一步运行的成功。此次测试脚本及分析报告我将会上传到博客中，感兴趣的朋友可以下载来看看，谢谢。

运行脚本

编译后如果没错，我们就可以运行脚本了，但在运行前可以对运行进行相应设置，可以增加迭代次数，忽略思考时间，如果你是机器配置不够好，可以突然忽略掉日志记录，对网络

         进行设置等等。点击菜单中的“Vuser”或直接按F4，就可以弹出运行时设置框了，我的设置如下图所示：

设置好后，点击“运行”按钮就OK了。运行成功后，可以视图中查看运行结果，如下图所示：请注意，在运行前请确保所用到的服务器都是启动的

        

创建场景及运行

         LR脚本生成和场景配置在不同的模块进行，脚本在VuGen中录制，增强和调试；场景则是在Controller中进行配置，通过Controller来控制执行的规则和虚拟用户数目。进入场景模块

         可以通过LoadRunner Launcher，点击“Run Load Tests”启动，也可是在Virtual User Generator模块中的菜单栏中的“工具”选择“创建控制器场景”，此时将会弹出一个设置窗口，

         设置好Vuser数和场景类型确定后进入Controller模块。如下图所示：

        

         进入到场景计划界面后，可以通过配置多台计算机作为压力产生器向被系统加载压力等等，还可以编辑计划，在编辑计划中可以新建计划，选择不同的计划定义，设置初始加压Vuser

         数量及用时，持续时间和减压方式。我的设置如下图所示：

         在前面脚本的编辑中我们加入了集合点，集合点让多个Vuser在同一个时刻执行任务，从而在服务器上创建密集的用户负载，脚本中的集合点只是一个标记而已，至于并发情况的属

         性配置则在Controller中进行。操作为在菜单中“场景”中选择“集合点”命令，打开集合信息对话框，进行设置，我的设置如下图所示：

         接着可以在Controller菜单的“工具”中选择“选项”命令，对所有脚本设置一些全局的配置，比如超时设置，运行时刻设置和运行文件设置等，大家可以试下。

服务器监控

  在运行负载测试时，还应该参所用到的服务器进行实时监控，我这个项目用到的服务器是tomcat和mysql。LR对tomcat的性能监控是可以通过写脚本实现的，我这里用Lambda Probe来实现的，Lambda Probe以前是tomcat的探针，官方原话是Tomcat Probe， the ultimate tool for monitoring and management of Apache Tomcat instance in real time,官网地址是：http://www.lambdaprobe.org/d/index.htm。Mysql可以用tomcat中的status模块收集相关数据来判断其性能问题。

设置搞定后，我们就可以开始运行场景了，你可在“RUN”视图中看到相关图的动态变化,场景运行完成后，相应的视图数据也就出来了，如下图所示：

此时可以通过结果分析器（Analysis）模块进行性能分析，找出并定位性能问题所在,这部分内容放到下一篇博文中再讲。谢谢大家的支持，不足之处，真诚希望能得到大家的谅解和帮助，谢谢大家啦。

 在下一篇中，将会讲到怎样在初步得到的笼统数据中逐步筛选出重要且有价值的数据，从而达到确定软件系统到底有没有符合需求规格说明书所定义的性能要求。谢谢大家的关注与支持！

 

MILY: 宋体; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: 宋体; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-ascii-font-family: Calibri; mso-hansi-font-family: Calibri">导读

  如果你是正在学LoadRunner，或者已经精通LoadRunner，你也许会有这样的感觉：做性能测试我离不开LoadRunner了。是的，LR太棒了，不爱都不行。从现在开始，我们来走入LoadRunner的世界。

LoadRunner介绍

LoadRunner是原Mercury公司是产品，2006年Mercury公司被HP收购。LoadRunner（以下简称LR）是一种高规模适应性的自动负载测试工具，它能预测系统行为，优化性能。LR强调强调是的对整个企业应用架构进行测试，它通过模拟实际用户的操作行为和实行实时性能监控，来帮助客户更快的确认和查找问题。LR能支持广泛的协议的技术，为客户的特殊环境，提供特殊的解决方案。

LR的特点：

1， 能很轻松地创建虚拟用户

2， 能创建真实的负载

3， 定位性能问题

4， 分析结果精确定位问题所在

5， 完整的企业应用环境支持

 

LR的结构：

1， Virtual User Generator：虚拟用户生成器，简称VuGen，用来录制操作者的操作，建立虚拟用户脚本。

2， Controller：压力控制器，整个压力测试的控制中心，用来管理，设计，驱动及监控压力测试场景。

3， Load Generator：压力生成器，执行虚拟使用者脚本以产生虚拟用户，对被测系统发出请求和接收响应，模拟实际的负载。

4， Analysis：结果分析器，通过测试结果的数据，用来分析压力测试结果。

5， Launcher：提供一个集中的界面，启动LR所有模块。

 

LoadRunner的工作原理:

LR的工作原理是通过用户执行被测程序的客户端，在VuGen中录制被测系统的客户端和服务器的协议交互，生成脚本，然后在Controller中控制Load Generator，按照一定的配置（又称为场景），模拟一定数量的用户，对服务器产生压力，同时对被测系统涉及的操作系统，数据库，中间件笔资源进行监控，收集压力情况下的资源信息，测试结束后形成测试结果和监控数据，在结果分析器中进行分析，最后生成测试结果报告。在下一篇中我会以一个具体的测试案例来具体说明，敬请留意。

OK，按照上面的原理，我们来画一个图来说明，这样更容易理解了，如下图所示：

OK，这就是LR了，当然在实际的操作中可不象那么简单，RL的功能非常强大，在下一篇中会讲到，插入事务，参数化技术，精确搜索数据和筛选特定数据等等。

 

做软件性能测试前的准备

做测试的都知道，做性能测试比做功能测试难许多，主要是因为性能涉及的范围太广，所考虑的不仅仅是软件本身，还要考虑到硬件，操作系统，网络和各种用到的服务器等等。在做性能测试是都要对这些进行监控，收集数据，光是工作量就比做功能大很多。功能主要关注的是软件系统能做什么，而性能测试关注更多的则是在一定条件下软件系统能做得多好。

想要做软件性能测试，首先你得搞懂几个概念性的术语。

一，什么是软件性能

         软件性能是软件的一种非功能特性，它关注的不是软件是否完成特定的功能，而是在完成该功能时展示出来的及时性。

         二，软件性能的指标

1， 响应时间：是指系统对请求作出响应的时间。这里的响应时间只是一个很笼统的概念，其实响应时间是可以被进一步分解为系统响应时间和呈现时间。响应时间是衡量一个系统性能的重要指标，但需要说明的是，软件性能的高底实际上取决于用户对该响应时间的接受程度。

2， 吞吐量：是指系统在单位时间内处理请求的数量。对无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，此时吞吐量就是响应时间的倒数。

3， 并发用户数：是指系统可以同时承载的正常使用系统功能的用户数量。与吞吐量相比，并发数量是一个更直观但也是更笼统的性能指标。

4， 资源利用率：资源利用率反映的是在一段时间只资源平均占用的情况，

5， 性能计数器：是描述服务器或操作系统性能的一些数据指标。例如，对Windows系统来说，使用内存数（Memory In Usage），进程时间（Total Process Time）等都是常见的计数器。

6， 思考时间（think time）：也被称为“休眠时间”，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个lr_think_time()的函数，使得脚本在执行两个操作之间等待一段时间。但在实际测试中，设置多长的think time才算最合理，不影响迭代次数、并发用户数和吞吐量，是值得我们思考的问题。

三，软件性能测试的分类

根据测试目的不同，可以把软件性能测试以及性能有关的其它一些测试分为以下几类。

1， 性能测试   这里的性能测试是一个狭义的概念，是指测试软件的性能是否符合需求中规定的性能。

2， 并发测试  

3， 压力测试

4， 可靠性测试

5， 负载测试

6， 配置测试

7， 失效恢复测试

其他方面的准备

OK，到这里，我们就可以做测试前的准备了。了解项目背景，制定测试计划，参于人员有人数用各自的任务，测试范围和目标，测试模型，测试数据，系统信息，搭建测试环境等等，所有这些都准备好了，在下一篇，我以一个自己写的博客网为例用LR来现实其性能测试。

今天到这里，谢谢大家，有不足之处，真诚希望各位多多指点。

MILY: 宋体; mso-ascii-font-family: Calibri; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: 宋体; mso-fareast-theme-font: minor-fareast; mso-hansi-font-family: Calibri; mso-hansi-theme-font: minor-latin">导读

其实并不想写关于理论的东西，理论性的东西网上有很多，更喜欢说一些实际操作性的话题。前几篇大多是说的关于单元测试方面，现在就对单元测试做个总结。纯属于个人理解,不足和巧合之处敬请大家指正。

什么是单元测试

                在你要去做一件事情时，总得知道是什么事吧。做单元测试也是如此，得先知道什么是单元测试。OK，传统软件对“单元”一词有各种定义，对“单元测试”也是一如此。这里我取其一种，即单元是可以编译和执行的最小软件构件，是决不会指派给多个程序员开发的软件构件。对于结构化程序而言，程序单元是指程序中定义的函数和子程序，单元测试就是对函数或子程序进行的测试。但有些也可以把紧密相关的一组函数或过程看做一个单元，如函数A调用函数B，那么在执行测试时，可以将A和B合并为一个单元进行测试。对于面向对象设计程序而言，程序单元是指特定的一个具体的类或相关的多个类，单元测试就是对类的测试；有时候，在一个类特别复杂的时候，可以把类中的方法作为一个单元进行测试。

单元测试要测试程序中的哪些方面

              现在你已经知道什么是单元测试了，但单元测试到底要测试程序中的哪些方面呢？有些人，包括本人一开始学习单元测试也犯过这样的错误，就是只写一个测试用例，让所有代码从头到尾跑一次，只测试一条能够正确执行的路径，如果测试通过了，就认为测试工作已经完成。实际上并非如此。单元测试的目的是根据可能是各种情况，确定测试内容，确定这段代码是否在任何情况下都和期望的一致。因此，在单元测试时，测试人员在依据详细设计规格说明书和源程序清单，理解程序的输入输出和模块的逻辑结构，从以下五个方面考虑：

1， 模块接口，主要测试数据在模块接口处是否出错，能否正确地输入输出。

2， 局部数据结构，主要检查临时存储在模块内部的数据在程序执行过程中是否完整，正确。

3， 独立路径，主要是为了发现因计算错误，比较不正确和控制流不适当而造成的错误而设计相应测试用例。

4， 出错处理，主要检查程序是否能预见各种出错条件，并进行相应的出错处理。

5， 边界条件，边界测试是单元测试中最后也是最重要的一项任务，主要检查软件在边界上是否失效。

怎样进行单元测试

         到此处，或许你已经想跃跃欲试了。OK，现在就开始，对程序进行单元测试，方法大体上有两种，一是静态测试，另一种就是动态测试。涉及了白盒测试技术知识。

一，静态测试

在静态测试中，一般会用词法分析与语法分析和静态错误分析。

用词法分析与语法分析可以获得软件组成的重要因数，如变量标识符，常量等，组合这些基本因数可以得到软件的基本信息。

静态错误分析用于确定在源程序中是否有某类错误或不安全的结构，主要有四种类型：类型和单位分析，引用分析，表达式分析和接口分析。

 

在实际工作中，如果测试需求严格，可能还会对代码进行检查，如桌面检查，代码审查，走查，等等。不同的公司有不同的做法。

 

二，动态测试

动态测试，是一种需要执行原程序或测试类程序的一种测试方法。在软件动态测试中，程序插桩是一种基本的测试手段。借助在被测试程序中插入操作，来实现测试的目的。在单元测试中，最重要的莫过于逻辑覆盖率的测试。逻辑覆盖是通过对程序逻辑结构的遍历实现程序的覆盖，主要有语句覆盖（SC），判定覆盖（DC），条件覆盖（CC），条件判定组合覆盖（CDC），多条件覆盖（MCC）和修正判定条件覆盖（MCDC）。还有路径覆盖和基本路径测试法等等。关于这些覆盖的定义和用法这里就不做过多的述说了，因为很多测试资料及网上都可以很容易找到，也很容易看懂。关键的是在工作中，怎样设计一个成功的测试用例来提高被测程序的覆盖率，这才是作为一个测试工作者要思考的问题。与该文章一起，我会上传一个相关的文档，感兴趣的朋友可以下载看看。

 

怎样做好单元测试

             在你知道为什么，怎样做时，你是否这样想过，怎样才能做得最好呢？当有很多方法可以同是实现时，你是否想过，用哪种方法可以以最快的速度达到最好的效果？先搞懂为什么，再思考怎么做，最后深入研究怎样才能做得最好。这是我一直以来的学习习惯，感觉很好，你们也可是试试。

            怎样做好单元测试，除了你要懂得软件开发流程，测试基本知识，你还需要熟悉代码，懂得编程，具备良好的逻辑思维能力和洞查能力加上有良好的职业敏感度。除此之外，你还得有很强的学习能力，因为单元测试中对不同开发语言，不同技术，相对应的测试方法和技术都会不同，所用到的测试工具也不同，所以你要有很强的学习能力。

          要做好一个单元测试，当然少不了应用工具，在这里举例一些

1， JUnit ：一种测试java类的测试框架，可以ant结合，达到自动化测试，官网地址是：http://www.junit.org/   ant 下载地址是：http://ant.apache.org/

2， Jtest：和JUnit类似，只是JUnit是开源软件。官网地址是：http://www.parasoft.com/jsp/home.jsp

3， Cactus：一种测试servlet，jsp，taglibs，filter的框架，是apache开发的一个开源软件，官网地址是：http://www.apache.org

4， Strutstest：一种测试struts的框架，结合junit可以测试struts中的action。下载地址是：http://strutstestcase.sourceforge.net/  

5， Jsunit：一种类似junit的测试框架，主要用来测试javascript。下载地址是：http://sourceforge.net/projects/jsunit/

6， httpUnit：httpUnit本身不是测试工具，而是协助进行功能单元测试的工具，与JUnit一起，可以整合cactus。官网地址为：http://httpunit.sourceforge.net/

7， C++test：一种C和C++的单元测试工具，官网地址是：http://www.parasoft.com/jsp/home.jsp

 

除了以上所要求具备的，会用的东西外，更少不了一个

好的测试计划。当这些都准备好了后，就开始Run吧。

 

         OK，就说这些我所常用的了，还有很多，大家在网上都很容易找到，就不一一例举了。

这篇结束后，这类话题就不再说了，将转入功能测试，性能测试及自动化测试（LoadRunner，WAS，JMeter，WinRunner）相关话题，谢谢大家的支持，欢迎大家指正错误的地方，我的QQ是117293968，加时请注明“软件测试”，大家一起相互学习，相互帮助啦。

       MILY: 宋体; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: 宋体; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-ascii-font-family: Calibri; mso-hansi-font-family: Calibri">软件质量是软件的灵魂所在。及时，尽早，不断地对软件系统进行测试，从而找出软件中的BUG，软件测试的目的就是寻找错误，并且尽最大的可能寻找最多的错误，所以说软件测试是可以在一定的程度上提高软件的质量。

软件测试分类很多，对不同的公司而言，又有不同的测试分类。按照开发阶段划分，有单元测试，集成测试，系统测试，确认测试和验收测试；按照测试实施组织划分，有开发方测试，也就是开发方自己的测试团队的测试，用户测试及第三方测试；还的一种是按照测试技术划分，有白盒测试，黑盒测试和灰盒测试，灰盒测试就是在测试活动中所用测试技术介于白盒和黑盒之间的一个测试技术。

再者就是软件测试的模型了。开发有开发的模型，软件测试也开展出来一些很重要的模型供测试人员参考。这里就简要分析几个。

第一个是V模型，V模型是最具代表意义的测试模型，如下图所示：

           

V模型是是软件开发瀑布模型的变种，它反映测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述这些个测试阶段和开发过程期间各个阶段的对应关系。但V模型也存在一定的局限性，就是把测试作为需求分析，概要设计，详细设计和编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。

第二个是W模型，如下图所示：

W模型在V模型的基础上，增加一与开发阶段的同步测试，形成W模型；测试与开发同步进行，有利用尽早的发现问题。相对于V模型而言，W模型更加科学。W模型可以说是V模型自然而然的发展。它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求,功能和设计同样要测试。但W模型也是有局限性的，它的局限性是仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整。W模型把软件开发和测试看成是一种线性的前后关系。

在V模型和W模型中，都没有很好地体现测试流程的完整性，为了解决这个问题，有专业就提出了H模型，这就是现在要讲的第三个测试模型，H模型，如下图所示：

H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。上示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”，图中其它流程可以是任意开发流程。H模型是一个独立的流程，贯穿于整个产品周期，与其它流程并发地起先，当某个测试时间点就绪时，软件测试即将从测试准备阶段进入测试执行阶段。

除了以上三种常见的测试模型外，还有X模型，前置测试模型等等。应该说这些测试模型对指导测试工作的进行具有重要的意义，但任何模型都不是完美的。我们应该尽可能地去应用模型中对项目有实用价值的方面，不强行地为使用模型而使用模型，否则也就没有实际意义了。

MILY: 宋体; mso-ascii-theme-font: minor-latin; mso-fareast-font-family: 宋体; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin; mso-ascii-font-family: Calibri; mso-hansi-font-family: Calibri; mso-bidi-font-size: 10.5pt">接 用cactus,jetty实现对servlet类进行单元测试二

 

OK，可以开始写测试类了，代码为：

package com.test.servlet.jetty;

import junit.framework.Test;

import junit.framework.TestSuite;

import org.apache.cactus.ServletTestCase;

import org.apache.cactus.WebRequest;

import org.apache.cactus.extension.jetty.Jetty6xTestSetup;

import com.test.servlet.LoginServlet;

import com.test.servlet.LoginServletJettyTest;

public class LoginServletJettyTest extends ServletTestCase {

    public static Test suite() {

    System.setProperty("cactus.contextURL",

       "http://localhost:8080/cactustest");

    TestSuite suite = new TestSuite();

    suite.addTestSuite(LoginServletJettyTest.class);

    return new Jetty6xTestSetup(suite);

    }

    public void beginLoginUser(WebRequest webRequest) {

    webRequest.addParameter("username", "cuckoo");

    webRequest.addParameter("password", "123");

    }

    public void testLoginUser() {

    LoginServlet loginServlet = new LoginServlet();

    assertTrue(loginServlet.loginUser(request));

    }

    public void beginInLoginUser(WebRequest webRequest) {

    webRequest.addParameter("username", "guest");

    webRequest.addParameter("password", "123456");

    }

    public void testInLoginUser() {

    LoginServlet loginServlet = new LoginServlet();

    assertFalse(loginServlet.loginUser(request));

    }

}

 

直接运行，不必启动tomcat，结果如图：

看到了最喜欢的绿带，说明你的测试通过了，可以进行下一步开发啦。

  

最后，解释下一两个名词及说明下我的开发环境：

 

组件：组件是在容器内部执行的一段代码。

容器：容器则是为存放在其内的组件提供有用服务（比如生命周期，安全，事务，分布等等）的器皿。

 

我的开发环境是：

软件环境：xp sp3，MyEclipse 8.0M1，tomcat 6.0.20

 

谢谢大家的支持，由于此网站所支持博文字数有限，故分了三篇来完成本话题，给大家带来的不便之处，敬请原谅。再者本人水平有限，欢迎大家指正错误和不足之处，谢谢大家。

按照官网的定义，我们就可以用MILY: 'Arial','sans-serif'; FONT-SIZE: 10.5pt" lang=EN-US>cactus和JUnit一起来完成对上述servlet的测试了。

首先，我们来建一个web项目，我定义的名称为cactustest；再把下载下来的cactus解压，把cactus-1.7.2\lib中的jar包复制到WebRoot\WEB-INF\lib下，也可以建立自己的用户库，方便以后的项目使用。搭建好环境后，接下来就可以写上面程序的测试类啦，让我们来用cactus为上面的程序写一个测试类，测试类代码为：

package com.test.servlet;

 

import org.apache.cactus.ServletTestCase;

import org.apache.cactus.WebRequest;

 

public class LoginServletCactusTest extends ServletTestCase {

    //先来个正确的测试用例

    //分别为username和password赋值

    public void beginLoginUser(WebRequest webRequest) {

       webRequest.addParameter("username", "cuckoo");

       webRequest.addParameter("password", "123");

    }

   //使用assertTrue方法断言，如果正确返回true

    public void testLoginUser() {

       LoginServlet loginServlet = new LoginServlet();

       assertTrue(loginServlet.loginUser(request));

    }

   //再来个错误的测试用例

   //分别为username和password赋值

    public void beginInLoginUser(WebRequest webRequest) {

       webRequest.addParameter("username", "guest");

       webRequest.addParameter("password", "123456");

    }

  //使用assertFalse方法断言，如果错误返回true

    public void testInLoginUser() {

       LoginServlet loginServlet = new LoginServlet();

       assertFalse(loginServlet.loginUser(request));

    }

}

这样，测试类就搞定了，

 下图是我的项目结构如下图：

 

OK，现在就可以启动tomcat了，部署成功后在地址栏上输入http://localhost:8080/cactustest/ServletTestRunner?suite=com.test.servlet.LoginServletCactusTest  回车，你将会看到让自己感到高兴的结果，此种方式是以XML形式输出测试结果，如下图：

还可以用cactus自定义的的样式表的方式输出测试结果，只需要把cactus自带的cactus-report.xsl文件加入到webroot目录下就可以了，在地址栏上输入http://localhost:8080/cactustest/ServletTestRunner?suite=com.test.servlet.LoginServletCactusTest&xsl=cactus-report.xsl  回车，这种形式的输出比较美观，如下图所示：

到这里，一个单独用JUnit不能完成的测试用上cactus就搞定了，或许我们会感觉高兴下，从技术上我们是实现了用JUnit加cactus对servlet的测试，但细心的你是否已经发现了其中的不便之处，就是每次对一个servlet测试前都要启动tomcat，这样大大增加了测试时间，也可能影响项目进度。有没有什么方法可以解决这个问题呢？细心的你可能已经发现，在我的项目结构图上，已经有一个LoginServletJettyTest.java类。是的，这个就是为了解决上面问题而用的另一种框架，它就是Jetty。它运行测试servlet就像用JUnit测试普通java类一样那么简单，不需要启动tomcat。

在这里我们可以使用Jetty 它的下载地址为 http://jetty.mortbay.org/jetty/index.html ，它是个Java编写的HTTP服务器，本身也是个Container，Cactus集成了Jetty，并提供与测试相关的简便类别。

使用Cactus+Jetty执行测试，在更大的程度上隐藏了测试运行过程的细节，您不必关心Redirector Proxy，更不一定要关心TestCase在客户端与服务器端的行为，运行起来就如同在运作一个JUnit测试。

   在WebRoot\WEB-INF\lib原来的基础上加入cactus.core.framework.uberjar.javaEE.14-1.8.1.jar就行了.

 

未完，下篇 用cactus,jetty实现对servlet类进行单元测试三 继续……

JUnit是名声大燥了，想必只要学过JAVA的人都知道世上有个东东叫JUnit。记得有个想学JUnit的兄弟在群上大喊：我要学JUnit，因为JUnit应用最广，最好的单元测试工具。无法否认，JUnit是一个非常让JAVA程度员或白盒测试人员喜爱的一个框架。但有时候应用最广的未必就是万能的，最好的未必就是最合适的。

JUnit也是有缺点的。想象一下，你有一个web程序，非常简单的那种，是用servlet实现的，你希望对其中的loginUser（）方法进行单元测试，代码如下：

 

package com.test.servlet;

 

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

 

public class LoginServlet extends HttpServlet {

 

    private static final long serialVersionUID = -5174161414983884806L;

 

    public boolean loginUser(HttpServletRequest request) {

        String username = request.getParameter("username");

        String password = request.getParameter("password");

    if (username == null || password == null || !username.equals("cuckoo")

                || !password.equals("123")) {

            return false;

        } else {

            return true;

        }

    }

}

 

为了能够测试这个方法，你需要得到一个合法的HttpServletRequest对象。但不幸的是，你不可能调用 new HttpServletRequest 来创建一个可用的请求。因为HttpServletRequest的生命周期是由容器管理的，因此你无法单独使用JUnit为loginUser方法编写测试类。

    此时我们今天的主角就要出来了，它就是cactus，cactus是什么？仙人掌吗？呵呵，当然不是了。仙人掌只是它翻译过来的中文名。它如commons-dbutils，commons-beanutils等等一样，是apache上的一个开源框架。下载地址为http://jakarta.apache.org/cactus/index.html 或是http://archive.apache.org/dist/jakarta/cactus/  用官网是话说，cactus就是

Cactus is a simple test framework for unit testing server-side java code (Servlets, EJBs, Tag Libs, Filters, ...).

The intent of Cactus is to lower the cost of writing tests for server-side code. It uses JUnit and extends it.

即Cactus是一个基于JUnit框架的简单测试框架，用来单元测试服务端Java代码。Cactus框架的主要目标是能够单元测试服务端的使用Servlet对象的Java方法httpServletRequest,HttpServletResponse,HttpSession等。Cactus的工作原理在官网上也可以找到，那有详细的说明，以下是其中的一种:图来自于cactus官网

Cactus provides several TestCase classes that extends the JUnit Testcase and it also provides several kind of redirectors (Servlet Redirector, JSP Redirector, ...). The diagram above is a generic diagram which serves to explain the principles. You'll find details for a specific redirector proxy in the next section. YYYTestCase = ( ServletTestCase | FilterTestCase | JspTestCase ) XXX is the name of the test case. Each YYYTestCase class contains several test cases

这是官网的简单说明，意思是：cactus提供了几个TestCase的类扩展了JUnit的TestCase的，同时也提供了若干种转向器（重定向程序组件，JSP的重定向，...).上图是一个普通的图，这足以解释的原则。你会发现，在未来一段特定的重定向代理细节。 YYYTestCase =（ServletTestCase | FilterTestCase | JspTestCase）XXX是测试案例的名称。每个YYYTestCase类包含几个测试案例。

我们将使用Cactus的ServletTestRedirector作为上图介绍的Redirector Proxy，并使用Cactus的ServletTestRunner作为执行测试时的TestRunner，这两个被撰写为Servlet，所以要在web.xml中加以定义，代码为：

<?xml version="1.0" encoding="UTF-8"?>

<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

    http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

 

    <!--

    <description>cactus test</description>

    <display-name>cactusTest</display-name>

     -->

    <servlet>

        <servlet-name>ServletRedirector</servlet-name>

        <servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class>

    </servlet>

    <servlet>

        <servlet-name>ServletTestRunner</servlet-name>

        <servlet-class>org.apache.cactus.server.runner.ServletTestRunner</servlet-class>

    </servlet>

  <servlet>

    <servlet-name>LoginServlet</servlet-name>

    <servlet-class>com.test.servlet.LoginServlet</servlet-class>

  </servlet>

 

    <servlet-mapping>

        <servlet-name>ServletRedirector</servlet-name>

        <url-pattern>/ServletRedirector</url-pattern>

    </servlet-mapping>

    <servlet-mapping>

        <servlet-name>ServletTestRunner</servlet-name>

        <url-pattern>/ServletTestRunner</url-pattern>

    </servlet-mapping>

  <servlet-mapping>

    <servlet-name>LoginServlet</servlet-name>

    <url-pattern>/servlet/LoginServlet</url-pattern>

  </servlet-mapping>

  </web-app>

1 .单元测试概述

  

单元测试——是最小粒度的测试，以测试某个功能或代码块。一般由程序员来做，因为它需要知道内部程序设计和编码的细节。

1.1. 单元测试的好处

    A、提高开发速度——测试是以自动化方式执行的，提升了测试代码的执行效率。

    B、提高软件代码质量——它使用小版本发布至集成，便于实现人员除错。同时引入重   构概念，让代码更干净和富有弹性。

    C、提升系统的可信赖度——它是回归测试的一种。支持修复或更正后的“再测试”，可确保代码的正确性。

1.2 单元测试的针对对象

   A、面向过程的软件开发针对过程。

   B、面向对象的软件开发针对对象。

   C、可以做类测试，功能测试，接口测试（最常用于测试类中的方法）。

1.3 单元测试工具和框架

    目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），     CppUnit（C ），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma （《设计模式》的作者）和Kent Beck（XP（Extreme Programming）的创始人 ）提供的开放源代码的JUnit。

2. 什么是JUnit及其特性

如果您要对编写的程序进行测试，应该如何进行呢？传统的测试方式是通过信赖人工对输出结果的判断，缺少效率且通常难以组织，且针对单一程序通常要设计专门的测试程序，如果您是在编写Java，您可以使用JUnit来为你提供有效的测试。 

2.1. 什么是JUnit？

在这里引述一下JUnit FAQ中的解释。 
JUnit是一个开放原始码的Java测试框架（testing framwork），它用来编写与执行重复性的测试，它是用在单元测试框架的xUnit架构的贯例。 

2.2. JUnit的好处

A、可以使测试代码与产品代码分开。

B、针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试。

C、易于集成到测试人员的构建过程中，JUnit和Ant的结合可以实施增量开发。

D、JUnit是公开源代码的，可以进行二次开发。

C、可以方便地对JUnit进行扩展。

2.3 JUnit单元测试编写原则：

A、是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写。

B、是使测试单元保持持久性。

C、是可以利用既有的测试来编写相关的测试。

2.4  JUnit包括以下的特性： 

  A. 对预期结果的断言

  B. 对相同共享资料的测试组装
  C. 易于组织与执行测试的测试套件

  D 图形与文字界面的测试器

3. JUnit 的使用入门

现在很多Java开发工具都集成了JUnit，如MyEclipse,Netbean,JBuilder等等，你可以直接使用。当然你也可以在JUnit的官方网站上下载，网址是http://junit.org

我自己用的是MyEclipse6.6版本的java开发工具，JUnit是4.5版本。现在我们来写一个java类，也就是被测试的类，然后用JUnit来进行单元测试。

首先，在MyEclipse中建一个java工程，我这里的工程名为javaproject2，引入JUnit4.5相关的jar文件，把环境搭建好。然后建立相应的包。这里应当注意，为了方便管理，我们的源代码和测试代码最好不要放在同一个代码文件夹中的同一个包中。我们可以再建一个代码文件夹test，并在其中建一个与源代码文件夹（src）中的包名一致的包。这样做的好处是源代码和测试代码虽然不在同一个文件夹，但它们的.class文件都在同一个文件夹中，实现了源代码和测试代码的分离，方便管理。

如图1.0所示：

 

               （图1.0）

搭建好测试环境后，就可以进行相关类的编写了。这里我设计了一个税收类Revenue.java，放在src中的com.cuckoo2010包中。该类包含一个税费计算的方法revenuemethod(double mymoney)，方法具体的实现逻辑为：当个人收小于或等于800则不征税，当个人收入大于800底于2000元时，征收百分之七的税，当个人收入大于2000且底于5000元时，征收百分之十五的税，当个人收入超过5000时，征收百分之二十五的税。设定一个异常状态，当输入值等于或小于零时抛出一个异常。代码如下：

package com.cuckoo2010;

/**

 * 被测试的类 Revenue.java

 * @author 松子煮茶

 */

public class Revenue {

private double money;

public double revenuemethod(double mymoney) throws Exception {

//个人收小于或等于800则不征税

if (mymoney <= 800) {

return this.money = mymoney;

} 

//个人收入大于800底于2000元时，征收百分之七的税

else if (mymoney <= 2000) {

return this.money = mymoney - mymoney * 0.07;

} 

//个人收入大于2000且底于5000元时，征收百分之十五的税

else if (mymoney > 2000 && mymoney <= 5000) {

return this.money = mymoney - mymoney * 0.15;

} 

//个人收入超过5000时，征收百分之二十五的税

else if (mymoney > 5000) {

return this.money = mymoney - mymoney * 0.25;

} 

else if (mymoney <= 0) {

/**

 * 自定义异常

 * 当金额小于或等于0时，系统抛出异常

 */

throw new Exception("金额不符合要求，必须大于零！");

}

return this.money;

}

}

写完这个类后，我们可以根据这个类设计一个测试用例，也就是各种输入值，预期值及实际值。

如表1.1所示：

表1.1

<TD style="BORDER-BOTTOM: rgb(0,0,0) 0.5pt solid; BORDER-LEFT: medium none; PADDING-BOTTOM: 0pt; PADDING-LEFT: 5.4pt; WIDTH: 125.25pt; PADDING-RIGHT: 5.4pt; BORDER-TOP: <

查看(313) 评论(0) 收藏 分享 圈子 管理

不是第一篇日志

2009-02-09 10:34:06

学测试已经快两年了，要说说啦...

查看(60) 评论(1) 收藏 分享 圈子 管理

	输入值	预期值	实际值
正常测试数据	1.0	1.0	1.0
	500.0	500.0	500.0
	799.0	799.0	799.0
	1999.0	1859.07	1859.07
	2999.0	2549.15	2549.15
	4999.0	4249.15	4249.15
	5999.0	4499.25	4499.25
边界测试数据	800.0	800.0	800.0
	2000.0	1860.0	1860.0