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！

       記得年少時，第一次看神雕俠侶，每到動情悲傷處，總會被感落淚，從此便喜歡上了倜儻不羈，重情理義，敢愛敢恨的楊過，也從那時起，迷上了金庸先生的武俠世界，更加向往那如畫的江南。在金庸的“射雕三部曲”中，郭靖重禮，楊過重情，張無忌重義；但是相比之下，楊過是最有強勢獨立主見的一個角色，也是金庸筆下人生經歷最為坎坷，多磨的大俠之一。

      在金庸先生筆下，每個主角都有這樣那樣的奇遇，從而學到至高無上的武功，千里傳音，摘花奪命�？烧l又能像楊過一樣，在學到眾家的武功后，自創出一套手法與尋常武功大異，武學通理相反，古怪之極，令敵琢磨不定的黯然銷魂掌，終成一代武學大家，位列西狂！

     學百家之所長，以成己之專。如果你愛測試，何時列位�；膹U，無稽之談，哈哈，笑癡。。。

      

在深圳已經上班兩周了，做的是自己喜歡的工作——軟件測試

但不知道為什么，仍然離不開寫java，struts，hibernate，spring，junit，maven，cactus，jetty，qtp，loadrunner，bugfree，qc，perl，python，ruby。。。。一連串熟悉喜歡的字符

我現在終于明白，自己要的是什么了。。。

加油吧，為那夢想能盡快實現

發現個人空間中有些地方存在bug

一，bug重現

第一個bug，是在日志模塊中的“上一篇/下一篇”�？臻g主人發表多篇日志后，在空間首頁按時間的先后倒序顯示，即最后發布的日志顯示在最上面。按照頁面的顯示排序，此時最后發布的日志為第一篇，最先發布的日志為最后一篇。如果閱讀者從第一篇日志開始閱讀，閱讀后第一篇在想進入下一篇時，如果點擊“下一篇”，這里就有問題了，頁面轉向是的最后發布的日志，也就是第一篇，而不是下一篇。如果你想閱讀下一篇日志，得點擊“上一篇”。這不符合人們的使用習慣，按照軟件的易用性測試中的定義，是算一個bug的。

第二個bug，也是出自在日志模塊中的“上一篇/下一篇”中�，F在我們可以忽視第一個bug的存在，通過不停地點擊“上一篇/下一篇”，不管是到達第一篇還是最后一篇，都沒有相關提示信息。如果到達第一篇時，閱讀者想再繼續閱讀最新的日志，是否應該彈出相應提示信息，如“當前已經是第一篇”，最后一篇也一樣。這樣處理更加人性化。

第三個bug，第三個bug是出現在日志模塊和文件模塊之間的切換中。點擊導航菜單中的“日志”進入顯示日志頁面，這里即便是忽視第一個bug，如果日志A，文件B，日志C發布的時間由后自前時，在閱讀后日志A后想閱讀日志C，點擊“上一篇/下一篇”時，頁面跳轉到文件B中，在文件模塊中也一樣。這是一個較明顯較嚴重的bug。

名詞解釋：

1，上一篇：某一篇文章的前一篇，以當前一篇的方位為參照物。（嘿嘿，自己瞎編的）

2，下一篇：某一篇文章的后一篇，以當前一篇的方位為參照物。（嘿嘿，自己瞎編的）

3，bug：英文意思為臭蟲，是指電腦系統的硬件、系統軟件（如操作系統）或應用軟件（如文字處理軟件）出錯。

二，bug分析

在個人空間的日志和文件模塊中，所有日志和文件都是以發布的時間先后進行倒序顯示，先來看看“上一篇”和“下一篇”的鏈接，如圖：

“上一篇”截圖：

“下一篇”截圖：

itemid是指當前日志或文件的編號，uid是指個人空間用戶的編號，它們都是唯一的。以這兩個條件為前提，再通過up或next查看相應的日志或文件。但所有日志和文件都是以發布時間的先后進行搜索�；蛟S，設計者的設計思路是同一個用戶不可能在同一個時刻內發布大于兩篇的日志或文件。但如果真的出現用戶在同一個時刻發布了大于兩篇的日志或文件，在此時點擊“上一篇”或“下一篇”時會出現什么情況了。

當一個軟件和數據庫連接搭上關系，數據庫的設計就尤為重要了。如果數據庫沒有設計好，勢必影響整個軟件功能的實現。

嗯，就到這先啦，呵呵，本想給個測試用例的，但必竟不是自己的網站，說太多可能不太好，明白人一看也大概清楚了。我只是對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和異�？赡艹蔀槟慵夹g提高的源泉。謝謝大家的支持，不足之處，請大家諒解和提示。

 

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版本�，F在我們來寫一個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) 收藏 分享 圈子 管理

老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

	輸入值	預期值	實際值
正常測試數據	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