Web（前端）測試工程師 2人
崗位職責：

1. 負責淘寶網(wǎng)前端測試；
2. 設計前端測試方案及流程，并推廣實(shí)施；
3. 提供自動(dòng)化測試工具和自動(dòng)化測試框架，幫助測試工程師提供測試效率和質(zhì)量；

崗位技能：

1. 熟悉WEB開(kāi)發(fā)技術(shù)，如java, DOM, HTML, Css, JavaScript
2. 熟悉軟件測試，有豐富的自動(dòng)化測試實(shí)施經(jīng)驗
3. 有良好的溝通能力和快速學(xué)習能力
4. 熟悉前端測試，包括性能測試，熟悉前端測試技術(shù)或框架者優(yōu)先；

工作之前，更多的是在思索如何成為一名優(yōu)秀的測試工程師。時(shí)兒清晰，時(shí)兒模糊，并循環(huán)在自己身上出現，折磨著(zhù)，很痛苦。佛說(shuō)：人來(lái)到這個(gè)世上就是受折磨的。好吧，神都這樣說(shuō)了，安慰下自己。

工作之后，從平時(shí)學(xué)習和日常測試的實(shí)踐中，以及我們產(chǎn)品線(xiàn)情況，在想，我們測試人員應該站在哪些角度上去保證軟件質(zhì)量？現在想到是三個(gè)方面。

1，從業(yè)務(wù)邏輯上著(zhù)手。

這點(diǎn)很容易明白，業(yè)務(wù)是系統功能的一種體現形式如果，如果對業(yè)務(wù)邏輯了解清楚，不管系統有多復雜，也不管系統有多大，對那些熟悉業(yè)務(wù)的人來(lái)說(shuō)，可以設計出質(zhì)量高的測試用例，進(jìn)行一次成功的測試。很喜歡的一句話(huà)，就是專(zhuān)業(yè)知識是測試人員的左腳，業(yè)務(wù)知識是測試人員的右腳，也就是這個(gè)道理。在測試道路上能走多遠，就看左右腳有沒(méi)有力了。

2，從用戶(hù)體驗上思考

在軟件工程上，并不認為開(kāi)發(fā)人員去自己測試他們的代碼是一種好的方法。人很多時(shí)候很固執，總認為自己寫(xiě)的代碼沒(méi)有問(wèn)題，特別是作技術(shù)的人。很多測試人員，很多時(shí)候或許僅僅是從測試角度去測試一個(gè)系統，根據特定的流程，特定的方法等等，去完成一個(gè)系統的測試工作，如果測試結果通過(guò)測試，測試達標就ok了。但我們很多時(shí)候忘記了從用戶(hù)體驗上去思考某個(gè)功能的使用，某個(gè)頁(yè)面的樣式。。。特別是我們淘寶的應用，系統體驗好不好，很大程度是關(guān)系到我們的PV和用戶(hù)數量，我們是否在測試時(shí)，考慮下這方面，雖然這些不是功能或性能上的缺陷。

3，從系統架構上把握

這點(diǎn)是在工作之后給我的靈感。以前只是想到1，2兩點(diǎn)，但僅僅是從上面這兩點(diǎn)去做，能保證軟件的質(zhì)量么？

這是誰(shuí)也不敢保證的。如果要解剖一頭牛，你得要非常了解牛的架構是怎樣的。同樣，如果我們要保證軟件系統的質(zhì)量，我們也要非常了解軟件系統的架構，這樣，我們才胸有成竹，有的放矢�？梢詮囊粋�(gè)更高的視角，保證軟件的質(zhì)量。有一句詩(shī)詞叫作：會(huì )當凌絕頂，一覽眾山小。當站在一個(gè)更高的角度看事物時(shí)，我們的視角才寬廣，才更全面。軟件測試也是如此，當你對一個(gè)軟件系統的實(shí)現結構了如指掌后，你就可以清楚地知道這個(gè)系統哪里是最弱的，哪里是最強的，哪些地方是最需要關(guān)注的，哪些地方需要做性能測試，哪些地方可以使用自動(dòng)化介入，從而采用最好最適合的測試策略。

ok，就這樣先，好好學(xué)習，天天向上。。。

獻給對軟件測試有著(zhù)很傻不拉機感情的人們。更多blog，請移步至：http://cuckoo2010.blog.163.com/

2009，從學(xué)校走了進(jìn)來(lái)。。。

或許在同學(xué)們眼里，似乎一切都很美好，在校期間就已經(jīng)在中國普天實(shí)習，考完大學(xué)里最后一次考試不到一個(gè)月就來(lái)到現在的公司上班。。。

可他們并不知道，期間我與一些機會(huì )錯過(guò)，現在回想起來(lái)，常常痛恨自己。其實(shí)他們個(gè)個(gè)都很優(yōu)秀，都很聰明。在摸著(zhù)石頭過(guò)河的日子里，很多人在一場(chǎng)轟轟烈烈的愛(ài)情里，在一次次游戲的撕殺中，或許在河里迷了方向。很感謝同寢的其他舍友，因為有他們在，自己沒(méi)有迷失，我們在一起努力過(guò)。

剛來(lái)公司，僅僅是對測試的固執而選擇了測試，如果當初聽(tīng)從經(jīng)理的安排，去做公司的網(wǎng)站，也許就不會(huì )錯過(guò)1月份那次機會(huì )。不過(guò)有失必有得，經(jīng)過(guò)這段時(shí)間的測試工作，讓我明白很多。這些是無(wú)法從學(xué)校學(xué)到的。

佛說(shuō)，有因有果。如果我現在的得是因為昨日的努力，那我想，自己現在的失也是因為昨日沒(méi)有努力深入。2010了，恰遇虎年，對我來(lái)說(shuō)是最為關(guān)鍵的一年，一定要虎虎的，每天都要進(jìn)步。如果在三到四年內沒(méi)能在測試領(lǐng)域有所作為，四年后也就別再想了，回家種紅薯去！

虎年，一定要虎虎的，也祝我的同學(xué)們心想事成！

前段時(shí)間，junit annotation讓我無(wú)言了一回，白疼了他兩年，郁悶

junit 現在已經(jīng)開(kāi)發(fā)到了4.8.1版本，在這個(gè)版本中，共有19個(gè)annotation。最常用到的也有十來(lái)個(gè)。下面是無(wú)言之后寫(xiě)的一個(gè)junit 程序。沒(méi)做什么功能，細心看，或是自己寫(xiě)一遍，或許那天，你就會(huì )用得上。

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批注，在整個(gè)測試類(lèi)中只運行一次，有別于@Before。
 //test the @BeforeClass annotation
 @BeforeClass
 public static void testBeforeClass() {
  System.out.println("BeforeClass");
 }
 
 //測試@Before批注，在每個(gè)測試方法運行前執行該方法。
 //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!，否則跳過(guò)該測試函數。
  //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批注，每個(gè)test方法執行完成后運行此方法
 //test the @After annotation
 @After
 public void testAfter() {
  System.out.println("After");
 }
 
 //測試@AfterClass批注，在整個(gè)測試類(lèi)中只運行一次，有別于@After
 //test the @AfterClass annotation
 @AfterClass
 public static void testAfterClass() {
  System.out.println("AfterClass");
 }
}
執行完，測試通過(guò)，從下圖可以知道@Ignore的作用吧

  

再看下控制臺中輸出的信息

從上圖可以得知，標的@BeforeClass和@AfterClass的測試方法只執行了一次，而@Before和@After在每個(gè)標有@Test方法執行前后都會(huì )執行一次。這也是這幾個(gè)annotation的區別。

而@Rule這個(gè)annotation這里只說(shuō)了一種用法，還有其它七種用法。

附上項目結構圖

這段時(shí)間在看一本測試驅動(dòng)開(kāi)發(fā)的書(shū)，是極限編程創(chuàng )始人Kent Beck寫(xiě)的，非常不錯。讓測試程序運行起來(lái)，之后再消除那些重復設計，最終使代碼整潔可用（clean code that works）。呵呵，還沒(méi)看完，沒(méi)悟到什么。純屬瞎扯蛋！

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

java開(kāi)源大全，里面有非常全面的java方向內容介紹，不管你是開(kāi)發(fā)還是測試，檢驗下自己會(huì )多少東東。網(wǎng)站為：http://www.open-open.com/

網(wǎng)站有直接的鏈接，別忘記從鏈接進(jìn)入官網(wǎng)，那有權威的Documentation！

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

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

     學(xué)百家之所長(cháng)，以成己之專(zhuān)。如果你愛(ài)測試，何時(shí)列位�；膹U，無(wú)稽之談，哈哈，笑癡。。。

      

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

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

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

加油吧，為那夢(mèng)想能盡快實(shí)現

發(fā)現個(gè)人空間中有些地方存在bug

一，bug重現

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

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

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

名詞解釋?zhuān)?/P>

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

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

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

二，bug分析

在個(gè)人空間的日志和文件模塊中，所有日志和文件都是以發(fā)布的時(shí)間先后進(jìn)行倒序顯示，先來(lái)看看“上一篇”和“下一篇”的鏈接，如圖：

“上一篇”截圖：

“下一篇”截圖：

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

當一個(gè)軟件和數據庫連接搭上關(guān)系，數據庫的設計就尤為重要了。如果數據庫沒(méi)有設計好，勢必影響整個(gè)軟件功能的實(shí)現。

嗯，就到這先啦，呵呵，本想給個(gè)測試用例的，但必竟不是自己的網(wǎng)站，說(shuō)太多可能不太好，明白人一看也大概清楚了。我只是對bug太過(guò)于敏感。哎。。。學(xué)軟件測試的，就這缺點(diǎn)，想改卻改不了。

僅僅是出于對測試的喜愛(ài)，以及對空間的發(fā)展，寫(xiě)了這篇東東，并無(wú)他意，如有冒犯，請和本人聯(lián)系，我自會(huì )刪除本日志。

今天，學(xué)院校慶。。。

今天，天空下雨。。。

今天，我拒簽了。。。

第一次拒簽，公司是深圳一家光電方面的外資公司。同學(xué)說(shuō)我，你怎么那么傻，這樣你不是可以回家那邊工作么？老師說(shuō)我，你要想清楚，大專(zhuān)生找一份好工作是很難的。

離家近是什么概念？離家近就意味著(zhù)可以天天回家么？

如果你有時(shí)間，再遠也可以回家；如果你沒(méi)時(shí)間，再近也回不了家。大禹為了治水，三過(guò)家門(mén)而未進(jìn)。。。

我深知自己只是區區一個(gè)大專(zhuān)生，這段時(shí)間在華科武大參加校招的經(jīng)歷已經(jīng)讓我意識到這點(diǎn)。但并不畏懼，因為我已經(jīng)知道我與他們的差距在哪，我自信可以趕上，我更自信自己在專(zhuān)業(yè)上的優(yōu)勢。

在簽約辦公室里，我也是很矛盾。到底要不要簽，但我始終下不了筆。我告訴自己，你的最?lèi)?ài)是軟件測試么，你的強項不在光電。軟件測試是你從一開(kāi)始就確立好的目標，你不是規劃好了將來(lái)么。

決定不簽的那一刻，我感覺(jué)很輕松，因為我知道自己的將來(lái)想要的是什么。我更加期待下周能實(shí)現，那個(gè)曾在高中時(shí)就想實(shí)現的夢(mèng)想，還有那老子，曾經(jīng)找了幾年的《道德經(jīng)》。。。

我不停地告訴自己，你要的不僅僅是一份工作，而是一種事業(yè)。不要輕易放棄自己的夢(mèng)想，不管以后的路有多辛苦，有多難。。。

十年鑄劍，只為沖天一嘯。我相信自己，不管以后的路有多么艱難。

我的測試，我的夢(mèng)想，期待著(zhù)下周，能實(shí)現高中時(shí)的夢(mèng)。。。

今天新裝上LoadRunner 9.5版本的，破解成功，支持web 10000 的Vuser。好爽，把上次測試的博客網(wǎng)整崩潰了，大家一起來(lái)玩下啦。

網(wǎng)上的方法大多一樣。用兩個(gè)dll文件覆蓋bin中的同名dll文件，再刪除注冊表中的相關(guān)地方，最后加上License。但我跳過(guò)了注冊表這步，也可以成功加上golba-100的License，但web 10000的加不上。在注冊表里玩了下，先前我裝過(guò)8.1版本的，刪掉一些后，就可以加上web 10000的了。之后又刪掉，再試了幾次，搞定。這里提供破解所用到的兩個(gè)dll文件，大家可以試試啦，很好玩的。

裝好后，我模擬1000個(gè)Vuser，每隔10秒初始200個(gè)Vuser
和運行100個(gè)Vuser，事務(wù)失敗達到6000個(gè)，成功僅僅3447個(gè)。登錄事務(wù)響應時(shí)間達到18.75秒，數據沒(méi)有完全插入數據庫中，在tomcat后臺拋了內存不足，500等錯誤，運行時(shí)基本打不開(kāi)博客網(wǎng)，連tomcat的主頁(yè)也打不開(kāi)。CUP使用率達到60%以上，PF使用率達到1.15GB，筆記本電腦嗡嗡作響，這下可有得搞頭了，繼續，得把測試方案再修改下。

第一步：用LR8.0中的mlr5lprg.dll、lm70.dll覆蓋LR9.1（9.5）安裝目錄下“bin”文件夾中的對應文件;

第二步：手動(dòng)修改注冊表，刪除下面內容

[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

聲明：僅用于學(xué)習，商用請使用正版軟件。感謝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">導讀

經(jīng)過(guò)前面的測試，我們通過(guò)了測試并得到了測試數據。此時(shí)，可以通過(guò)LR的Analysis模塊進(jìn)行操作。Analysis是一個(gè)獨立的模塊，它可以將測試結果和監控數據轉化為數據庫數據，以利于分析處理。測試人員可以在分析器中選擇感興趣的圖表，通過(guò)合并圖，交叉圖和自動(dòng)關(guān)聯(lián)等手段，對測試結果和監控數據進(jìn)行分析處理。以確定性能瓶頸及其產(chǎn)生的原因。最后，可以選擇有價(jià)值的部分圖，自動(dòng)生成HTML和Word格式報告， 這些報告可以作為附件和測試測試報告一起提交，提供性能參考。

詳細分析

場(chǎng)景運行 結束后，必須手動(dòng)打開(kāi)Analysis，Analysis啟動(dòng)時(shí)，會(huì )自動(dòng)收集本地計算機上的結果數據，如果壓力產(chǎn)生器在遠端機器上，又沒(méi)有選擇自動(dòng)收集數據，則會(huì )先收集測試結果數據。打開(kāi)后如下圖所示:

在上圖中，帶紅點(diǎn)的是打開(kāi)自動(dòng)生成的圖表，沒(méi)有紅點(diǎn)的則是通過(guò)合并圖，篩選等手段添加上的。Analysis上圖形主要分為四大類(lèi)，分別是Vusers，事務(wù)，Web資源，網(wǎng)頁(yè)分析。通過(guò)不同的需要選擇不同的圖來(lái)分析。下面主要講幾個(gè)重要的圖及相關(guān)操作。

一，相關(guān)圖的解說(shuō)

1， Vuser圖，如下圖所示：

此圖是經(jīng)過(guò)篩選操作后得到的Vuser圖，顯示了所有Vuser在測試期間的每一秒內，執行Vuser腳本的Vuser的數量及它們的狀態(tài)。如果想了解單獨一個(gè)Vuser的狀態(tài)，也可以將篩選條件設置您想了解的VuserID。具體操作步驟是：在Vuser圖內單擊鼠標右鍵，選擇菜單中的“設置篩選器/分組方式”，在彈出的設置框中進(jìn)行設置即可。如下圖所示：

用篩選方式可以搜索到特定的Vuser在不同時(shí)刻的數據，方便性能分析，初學(xué)者要好好掌握。此方法可以運用到對其它圖的操作上，以后對篩選的操作就不再具體描述了。

2， 事務(wù)圖。事務(wù)圖主要包括平均事務(wù)響應時(shí)間圖，每秒事務(wù)數圖，每秒事務(wù)總數，事務(wù)概要圖，事務(wù)性能概要圖，事務(wù)響應時(shí)間（負載下）圖，事務(wù)響應時(shí)間（百分比）圖，事務(wù)響應時(shí)間（分布）圖。

這里就拿事務(wù)響應時(shí)間（百分比）圖來(lái)分析。它可以幫助測試人員分析在給定時(shí)間范圍內執行的事務(wù)的百分比和確定合適的事務(wù)百分比，以判斷是否滿(mǎn)足系統的性能標準，通常情況下，您需要在可接受的響應時(shí)間范圍內，確定事務(wù)百分比，最大響應時(shí)間可能非常長(cháng)，但如果大多數事務(wù)具有可以接受的響應時(shí)間，則整個(gè)系統還是適用的。來(lái)看看具體的圖：

 

上圖是所有用戶(hù)的全部事務(wù)的響應時(shí)間百分比，可以通過(guò)篩選功能，篩選出具體的用戶(hù)和事務(wù)進(jìn)行分析；用向下搜索功能提煉出更加精確的數據，以便好地進(jìn)行性能分析，定位系統的性能瓶頸，此操作在相應的圖中單擊鼠標右鍵，選擇“向下搜索”，在彈出的設置框中設置相應選項就可以了。我這里就用Vuser9分析

 

經(jīng)過(guò)LR的篩選功能可以得到更多精確的圖，就可以很清晰很方便地分析出系統是否存在性能問(wèn)題了。用性能下降曲線(xiàn)分析法，從上圖可以看到，發(fā)布博文事務(wù)曲線(xiàn)非常平滑，最大響應時(shí)間為0.999秒，是屬于非常好的現象，其它事務(wù)隨著(zhù)負載用戶(hù)數量的增大，出現相應的波動(dòng)，從而可以分析性能問(wèn)題所在。從圖中可以看到，一條曲線(xiàn)可以分為以下幾個(gè)部分：

（1）性能平坦區——在不進(jìn)行更多性能調優(yōu)情況下所能期望達到的最佳性能。這個(gè)區域可被用作基線(xiàn)或是benchmark。

（2）壓力區域——應用“輕微下降”的地方。典型的、最大的建議用戶(hù)負載是壓力區域的開(kāi)始。

（3）性能拐點(diǎn)——性能開(kāi)始“急劇下降”的點(diǎn)。

這幾個(gè)區域實(shí)際上明確標識了系統性能最優(yōu)秀的區間，系統性能開(kāi)始變壞的區間，以及系統性能出現急劇下降的點(diǎn)。對性能測試來(lái)說(shuō)，找到這些區間和拐點(diǎn)，也就可以找到性能瓶頸產(chǎn)生的地方。因此，對性能下降曲線(xiàn)分析法來(lái)說(shuō)，主要關(guān)注的是性能下降曲線(xiàn)上的各個(gè)區間和相應的拐點(diǎn)，通過(guò)識別不同的區間和拐點(diǎn)，從而為性能瓶頸識別和性能調優(yōu)提供依據。

 

在其它圖中，還可以使用LoadRunner中的自動(dòng)關(guān)聯(lián)確定造成服務(wù)器或網(wǎng)絡(luò )瓶頸的原因。自動(dòng)關(guān)聯(lián)功能應用高級統計信息算法來(lái)確定哪些度量對事務(wù)的響應時(shí)間影響最大。操作步驟是：?jiǎn)螕簟瓣P(guān)聯(lián)選項”選項卡，選擇要將哪些圖的數據與相應事務(wù)關(guān)聯(lián)，如下圖所示：

 

除了上述操作外，還可以進(jìn)行其它操作，如比較不同場(chǎng)景的結果，如果你執行了多個(gè)場(chǎng)景的話(huà)。最后根據用戶(hù)選擇感興趣的圖表，生成HTML或Word格式及其它格式的報告。此次測試的報告我已經(jīng)上傳到博客上了，感興趣的朋友可以下載看看，謝謝大家的支持。根據測試結果分析數據與事先設計好的測試用例或需求說(shuō)明書(shū)對比，驗證測試是否通過(guò)，不通過(guò)則分析系統性能瓶頸出在哪里。OK，圖表就分析到這了。 

二，相應服務(wù)器性能分析

1， tomcat分析

我這里用的是Lambda Probe來(lái)實(shí)現的，來(lái)看看在運行場(chǎng)景時(shí)，tomcat的性能，如下圖：

從圖中兩個(gè)表中可以看出，要相同的時(shí)間內。每30秒的用戶(hù)數和執行的事務(wù)數整體上是一致的，并沒(méi)有影響系統整體性能，數據庫中也成功在插入了相應數據，如下圖：

在腳本運行設置中，我設置了6個(gè)迭代，這里也成功插入了6條數據，再結合事務(wù)響應時(shí)間（最大為0.999秒），說(shuō)明這塊的性能是通過(guò)測試的。這里想加一句，一個(gè)沒(méi)有發(fā)現bug的測試，算不上是一個(gè)成功的測試。因為軟件測試的目的就是要找到bug，如果有條件，盡量把并發(fā)的Vuser設多，能把系統搞崩潰最好，這樣就可以提取更有價(jià)值的數據，從而分析出系統的瓶頸，解決性能問(wèn)題。

2， MySQL數據庫服務(wù)器分析

MySQL數據庫服務(wù)器性能主要參考tomcat中的status可以獲得相應數據，只要tomcat用戶(hù)管理文件配置成功，就可以走入了，地址為：http://localhost:8080/manager/status  如下圖:

在運行場(chǎng)景中，這里會(huì )記錄所有數據插入的信息，通過(guò)這些信息，分析其性能。

如果出現性能問(wèn)題或現在的性能不符合需求規格說(shuō)明書(shū)上所需求的，則超需要進(jìn)行性能調優(yōu)了。針對不同性能問(wèn)題，實(shí)施不同的策略，如存儲空間不足，則可以增加大容量硬盤(pán)；內存不足就補內存；服務(wù)器問(wèn)題則可以采用集群等等，但每種都不是單獨考慮，要考慮到成本，風(fēng)險等問(wèn)題。不能說(shuō)存儲空間不足，就惡補大容量硬盤(pán)，這種方法不完全正確的。

 

此次測試的感想

         做性能測試比做功能測試是難很多的。

第一，  如果系統應用復雜，功能眾多的話(huà)，就需要進(jìn)行大量的測試工作，工作量龐大，試想我這里只是測試了登錄和發(fā)博文兩個(gè)功能，還有其它功能都還沒(méi)有測試呢。

第二，  Web腳本如何開(kāi)發(fā)。不想認為僅僅通過(guò)錄制就可以解決腳本問(wèn)題，在一些特定的環(huán)境下，要測試人員開(kāi)發(fā)大量的腳本，涉及高級算法，語(yǔ)言等知識。

第三，  場(chǎng)景數據出來(lái)后，如何分析。分析測試數據是一個(gè)很頭痛的問(wèn)題，其它涉及到的東西且不說(shuō)，光是那龐大的數據量就可能讓你窒息了。像阿里巴巴，淘寶這樣的網(wǎng)站，數據都是海量級別的。

第四，  性能問(wèn)題不僅僅關(guān)系到軟件本身，還與服務(wù)器，網(wǎng)絡(luò )，存儲空間，I/O等等有關(guān)。

…………

性能測試工程師職位是具體有挑戰性的，如果你想成為一個(gè)優(yōu)秀的性能測試工程師，必須有牢固的開(kāi)發(fā)測試基礎，廣闊的知識面，良好的分析問(wèn)題和解決問(wèn)題的能力，等等。上下不斷求索吧。

OK，關(guān)于LoadRunner自動(dòng)化測試就到這了。LoadRunner中自帶有一個(gè)測試web項目，地址是http://127.0.0.1:1080/mercuryWebTours  開(kāi)啟服務(wù)器后，用注冊用戶(hù)名和密碼進(jìn)入。大家可以自己動(dòng)手試試，盡量整出點(diǎn)性能問(wèn)題來(lái)，學(xué)IT，很多時(shí)候BUG和異�？赡艹蔀槟慵夹g(shù)提高的源泉。謝謝大家的支持，不足之處，請大家諒解和提示。

 

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">導讀

經(jīng)過(guò)上篇的準備，現在我們來(lái)具體用LR來(lái)測試一個(gè)博客后臺頁(yè)面的登錄及發(fā)布博文的測試，我這使用的LoadRunner時(shí)8.1版本的，所支持的虛擬用戶(hù)數最大是24個(gè)，所以我在測試時(shí)用了20個(gè)。OK不多說(shuō)，現在開(kāi)始吧，來(lái)看看自己寫(xiě)的博客性能到底如何。

一些說(shuō)明

         系統信息：個(gè)人博客系統1.0版，所用到的技術(shù)jsp+javabean+servlet，數據庫是  MySQL 5.1，服務(wù)器是tomcat 6.0.20，開(kāi)發(fā)工具是MyEclipse 8.0M1

         測試工具：LoadRunner 8.1

         操作系統：XP professional sp3

錄制腳本

         打開(kāi)LR后，進(jìn)入負載測試界面選擇“創(chuàng )建/編輯”，在這個(gè)界面中選擇“新建Vuser腳本”后會(huì )彈出讓你選擇協(xié)議的確認框，如圖所示

        

         因為我們所測試的是web項目，所以在這里我們要選擇“Web（HTTP/HTML）”協(xié)議，確定后進(jìn)行入Virtual User Generator功能模塊。此時(shí)會(huì )彈出“Start Recording”錄制設置窗口，

         這里除了要選擇Applcation type（我們要選擇 Internet Applcation），正確填寫(xiě)被測網(wǎng)站地址，選擇相應 Record into Action 外，還需特別注意 “選項”Options這個(gè)按鈕。這是錄制選項

         設置的地方。這里本人建議最好點(diǎn)開(kāi)，在彈出的錄制設置窗口中在Internet Protocol中的Advanced上選擇支持UTF-8選項，這樣做的好處是可以避免出現錄制腳本中出現中文亂碼。

         如下圖所示

        

         錄制設置做好后，就可以開(kāi)始錄制了。

         在錄制登錄腳本和發(fā)布博文操作時(shí)，需要特別注意的一個(gè)地方的，在進(jìn)入博客后臺管理頁(yè)面后，在正式登錄前可以增加一個(gè)事務(wù)，事務(wù)名要取個(gè)有意義的名稱(chēng)，增加腳本的可讀性。

         這里加一個(gè)事務(wù)是有特別的用處的，可以在此操作添加集合點(diǎn)，在后面的場(chǎng)景中設置循環(huán)，實(shí)現用戶(hù)并發(fā)操作。設置開(kāi)始事務(wù)登錄成功后，一定要設置結束事務(wù)操作，這點(diǎn)請大家一

         定記住，下圖是我的事務(wù)設置（login）

 

登錄成功后，再新建一個(gè)發(fā)布博文的事務(wù)（putout_blog），在退出博客管理后臺時(shí)也與前兩種方法一樣，新建一個(gè)退出的事務(wù)（out_blog）。退出到博客首頁(yè)后關(guān)閉瀏覽器，停止腳          本的錄制，返回到Virtual User Generator腳本編輯界面。

腳本編輯

         OK，錄制完成啦，現在可以對腳本進(jìn)行編輯了，對于這個(gè)，我不得不說(shuō)LR的強大，這也是我愛(ài)上LR的原因之一，就像當年愛(ài)上MyEclipse一樣。腳本和程序一樣，要有良好的風(fēng)格，

         必要的注釋。對每個(gè)事務(wù)進(jìn)行注釋?zhuān)�以便以后修改。這方面不做過(guò)多的文字描述。

         首先，你可以點(diǎn)擊“編譯”按鈕編譯下，檢查錄制的腳本有沒(méi)有錯誤。接下來(lái)，我們來(lái)看看腳本，在事務(wù)中我們可以看到一個(gè)這樣的函數lr_think_time(1234)，這就是在上篇中提到的

         思考時(shí)間，對這個(gè)函數，在事務(wù)中盡量注掉或者把時(shí)間改小，以免影響后面的響應時(shí)間，我們也可以在打開(kāi)平均事務(wù)響應時(shí)間表等相關(guān)表設置中去掉思考時(shí)間。但在實(shí)際工作中的性能測試，思考時(shí)間是一個(gè)值得測試人員思考的問(wèn)題。

         其次，使用參數化對登錄username和password設置不同的值，實(shí)現以不同的用戶(hù)身份進(jìn)行登錄。在LR中，參數設置方式有多種，都可達到一樣的效果，我這里就拿一種來(lái)說(shuō)下。

         點(diǎn)擊工具欄上的“打開(kāi)參數列表”點(diǎn)擊“新建”按鈕，設置相應名稱(chēng)，我的是loginusername，loginpassword，選擇適當的參數類(lèi)型，選擇文件路徑時(shí)把dat類(lèi)型改為txt，不改也行這個(gè)是個(gè)人的愛(ài)好，點(diǎn)擊“添加行”或“添加列”，輸入相應的值，在更新值的時(shí)間處選擇適當的方式。設置好后，可以通過(guò)右擊鼠標，選擇“參數屬性”，驗證是否已經(jīng)設置成功。我的設置如下圖所示：

     

         請注意上圖中的紅色字體部分，很重要。設置好參數后，在要定義的value后面選擇對應的參數，單擊鼠標右鍵，在“使用現有參數”中選擇剛剛設好的參數就OK了。以上的我是對登錄事務(wù)的參數設置，也可以在發(fā)布博文中用同樣的設置，這里不再重復。

    還可以在登錄事務(wù)中設置集合點(diǎn)，設置方法不難，只需在事務(wù)前加上lr_rendezvous("login_gather");函數就行了，login_gather是集合點(diǎn)名稱(chēng),在以后的場(chǎng)景設置中可以再詳細設置。還有可以在錄制時(shí)先做好相應關(guān)聯(lián)等等。

對腳本編輯好后，點(diǎn)擊工具欄上的“編譯”按鈕，對腳本進(jìn)行編譯，以驗證剛剛對腳本的修改有無(wú)錯誤，確保下一步運行的成功。此次測試腳本及分析報告我將會(huì )上傳到博客中，感興趣的朋友可以下載來(lái)看看，謝謝。

運行腳本

編譯后如果沒(méi)錯，我們就可以運行腳本了，但在運行前可以對運行進(jìn)行相應設置，可以增加迭代次數，忽略思考時(shí)間，如果你是機器配置不夠好，可以突然忽略掉日志記錄，對網(wǎng)絡(luò )

         進(jìn)行設置等等。點(diǎn)擊菜單中的“Vuser”或直接按F4，就可以彈出運行時(shí)設置框了，我的設置如下圖所示：

設置好后，點(diǎn)擊“運行”按鈕就OK了。運行成功后，可以視圖中查看運行結果，如下圖所示：請注意，在運行前請確保所用到的服務(wù)器都是啟動(dòng)的

        

創(chuàng )建場(chǎng)景及運行

         LR腳本生成和場(chǎng)景配置在不同的模塊進(jìn)行，腳本在VuGen中錄制，增強和調試；場(chǎng)景則是在Controller中進(jìn)行配置，通過(guò)Controller來(lái)控制執行的規則和虛擬用戶(hù)數目。進(jìn)入場(chǎng)景模塊

         可以通過(guò)LoadRunner Launcher，點(diǎn)擊“Run Load Tests”啟動(dòng)，也可是在Virtual User Generator模塊中的菜單欄中的“工具”選擇“創(chuàng )建控制器場(chǎng)景”，此時(shí)將會(huì )彈出一個(gè)設置窗口，

         設置好Vuser數和場(chǎng)景類(lèi)型確定后進(jìn)入Controller模塊。如下圖所示：

        

         進(jìn)入到場(chǎng)景計劃界面后，可以通過(guò)配置多臺計算機作為壓力產(chǎn)生器向被系統加載壓力等等，還可以編輯計劃，在編輯計劃中可以新建計劃，選擇不同的計劃定義，設置初始加壓Vuser

         數量及用時(shí)，持續時(shí)間和減壓方式。我的設置如下圖所示：

         在前面腳本的編輯中我們加入了集合點(diǎn)，集合點(diǎn)讓多個(gè)Vuser在同一個(gè)時(shí)刻執行任務(wù)，從而在服務(wù)器上創(chuàng )建密集的用戶(hù)負載，腳本中的集合點(diǎn)只是一個(gè)標記而已，至于并發(fā)情況的屬

         性配置則在Controller中進(jìn)行。操作為在菜單中“場(chǎng)景”中選擇“集合點(diǎn)”命令，打開(kāi)集合信息對話(huà)框，進(jìn)行設置，我的設置如下圖所示：

         接著(zhù)可以在Controller菜單的“工具”中選擇“選項”命令，對所有腳本設置一些全局的配置，比如超時(shí)設置，運行時(shí)刻設置和運行文件設置等，大家可以試下。

服務(wù)器監控

  在運行負載測試時(shí)，還應該參所用到的服務(wù)器進(jìn)行實(shí)時(shí)監控，我這個(gè)項目用到的服務(wù)器是tomcat和mysql。LR對tomcat的性能監控是可以通過(guò)寫(xiě)腳本實(shí)現的，我這里用Lambda Probe來(lái)實(shí)現的，Lambda Probe以前是tomcat的探針，官方原話(huà)是Tomcat Probe， the ultimate tool for monitoring and management of Apache Tomcat instance in real time,官網(wǎng)地址是：http://www.lambdaprobe.org/d/index.htm。Mysql可以用tomcat中的status模塊收集相關(guān)數據來(lái)判斷其性能問(wèn)題。

設置搞定后，我們就可以開(kāi)始運行場(chǎng)景了，你可在“RUN”視圖中看到相關(guān)圖的動(dòng)態(tài)變化,場(chǎng)景運行完成后，相應的視圖數據也就出來(lái)了，如下圖所示：

此時(shí)可以通過(guò)結果分析器（Analysis）模塊進(jìn)行性能分析，找出并定位性能問(wèn)題所在,這部分內容放到下一篇博文中再講。謝謝大家的支持，不足之處，真誠希望能得到大家的諒解和幫助，謝謝大家啦。

 在下一篇中，將會(huì )講到怎樣在初步得到的籠統數據中逐步篩選出重要且有價(jià)值的數據，從而達到確定軟件系統到底有沒(méi)有符合需求規格說(shuō)明書(shū)所定義的性能要求。謝謝大家的關(guān)注與支持！

 

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">導讀

  如果你是正在學(xué)LoadRunner，或者已經(jīng)精通LoadRunner，你也許會(huì )有這樣的感覺(jué)：做性能測試我離不開(kāi)LoadRunner了。是的，LR太棒了，不愛(ài)都不行。從現在開(kāi)始，我們來(lái)走入LoadRunner的世界。

LoadRunner介紹

LoadRunner是原Mercury公司是產(chǎn)品，2006年Mercury公司被HP收購。LoadRunner（以下簡(jiǎn)稱(chēng)LR）是一種高規模適應性的自動(dòng)負載測試工具，它能預測系統行為，優(yōu)化性能。LR強調強調是的對整個(gè)企業(yè)應用架構進(jìn)行測試，它通過(guò)模擬實(shí)際用戶(hù)的操作行為和實(shí)行實(shí)時(shí)性能監控，來(lái)幫助客戶(hù)更快的確認和查找問(wèn)題。LR能支持廣泛的協(xié)議的技術(shù)，為客戶(hù)的特殊環(huán)境，提供特殊的解決方案。

LR的特點(diǎn)：

1， 能很輕松地創(chuàng )建虛擬用戶(hù)

2， 能創(chuàng )建真實(shí)的負載

3， 定位性能問(wèn)題

4， 分析結果精確定位問(wèn)題所在

5， 完整的企業(yè)應用環(huán)境支持

 

LR的結構：

1， Virtual User Generator：虛擬用戶(hù)生成器，簡(jiǎn)稱(chēng)VuGen，用來(lái)錄制操作者的操作，建立虛擬用戶(hù)腳本。

2， Controller：壓力控制器，整個(gè)壓力測試的控制中心，用來(lái)管理，設計，驅動(dòng)及監控壓力測試場(chǎng)景。

3， Load Generator：壓力生成器，執行虛擬使用者腳本以產(chǎn)生虛擬用戶(hù)，對被測系統發(fā)出請求和接收響應，模擬實(shí)際的負載。

4， Analysis：結果分析器，通過(guò)測試結果的數據，用來(lái)分析壓力測試結果。

5， Launcher：提供一個(gè)集中的界面，啟動(dòng)LR所有模塊。

 

LoadRunner的工作原理:

LR的工作原理是通過(guò)用戶(hù)執行被測程序的客戶(hù)端，在VuGen中錄制被測系統的客戶(hù)端和服務(wù)器的協(xié)議交互，生成腳本，然后在Controller中控制Load Generator，按照一定的配置（又稱(chēng)為場(chǎng)景），模擬一定數量的用戶(hù)，對服務(wù)器產(chǎn)生壓力，同時(shí)對被測系統涉及的操作系統，數據庫，中間件筆資源進(jìn)行監控，收集壓力情況下的資源信息，測試結束后形成測試結果和監控數據，在結果分析器中進(jìn)行分析，最后生成測試結果報告。在下一篇中我會(huì )以一個(gè)具體的測試案例來(lái)具體說(shuō)明，敬請留意。

OK，按照上面的原理，我們來(lái)畫(huà)一個(gè)圖來(lái)說(shuō)明，這樣更容易理解了，如下圖所示：

OK，這就是LR了，當然在實(shí)際的操作中可不象那么簡(jiǎn)單，RL的功能非常強大，在下一篇中會(huì )講到，插入事務(wù)，參數化技術(shù)，精確搜索數據和篩選特定數據等等。

 

做軟件性能測試前的準備

做測試的都知道，做性能測試比做功能測試難許多，主要是因為性能涉及的范圍太廣，所考慮的不僅僅是軟件本身，還要考慮到硬件，操作系統，網(wǎng)絡(luò )和各種用到的服務(wù)器等等。在做性能測試是都要對這些進(jìn)行監控，收集數據，光是工作量就比做功能大很多。功能主要關(guān)注的是軟件系統能做什么，而性能測試關(guān)注更多的則是在一定條件下軟件系統能做得多好。

想要做軟件性能測試，首先你得搞懂幾個(gè)概念性的術(shù)語(yǔ)。

一，什么是軟件性能

         軟件性能是軟件的一種非功能特性，它關(guān)注的不是軟件是否完成特定的功能，而是在完成該功能時(shí)展示出來(lái)的及時(shí)性。

         二，軟件性能的指標

1， 響應時(shí)間：是指系統對請求作出響應的時(shí)間。這里的響應時(shí)間只是一個(gè)很籠統的概念，其實(shí)響應時(shí)間是可以被進(jìn)一步分解為系統響應時(shí)間和呈現時(shí)間。響應時(shí)間是衡量一個(gè)系統性能的重要指標，但需要說(shuō)明的是，軟件性能的高底實(shí)際上取決于用戶(hù)對該響應時(shí)間的接受程度。

2， 吞吐量：是指系統在單位時(shí)間內處理請求的數量。對無(wú)并發(fā)的應用系統而言，吞吐量與響應時(shí)間成嚴格的反比關(guān)系，此時(shí)吞吐量就是響應時(shí)間的倒數。

3， 并發(fā)用戶(hù)數：是指系統可以同時(shí)承載的正常使用系統功能的用戶(hù)數量。與吞吐量相比，并發(fā)數量是一個(gè)更直觀(guān)但也是更籠統的性能指標。

4， 資源利用率：資源利用率反映的是在一段時(shí)間只資源平均占用的情況，

5， 性能計數器：是描述服務(wù)器或操作系統性能的一些數據指標。例如，對Windows系統來(lái)說(shuō)，使用內存數（Memory In Usage），進(jìn)程時(shí)間（Total Process Time）等都是常見(jiàn)的計數器。

6， 思考時(shí)間（think time）：也被稱(chēng)為“休眠時(shí)間”，從業(yè)務(wù)的角度來(lái)說(shuō)，這個(gè)時(shí)間指的是用戶(hù)在進(jìn)行操作時(shí)，每個(gè)請求之間的間隔時(shí)間。從自動(dòng)化測試實(shí)現的角度來(lái)說(shuō)，要真實(shí)地模擬用戶(hù)操作，就必須在測試腳本中讓各個(gè)操作之間等待一段時(shí)間，體現在腳本中，具體而言，就是在操作之間放置一個(gè)lr_think_time()的函數，使得腳本在執行兩個(gè)操作之間等待一段時(shí)間。但在實(shí)際測試中，設置多長(cháng)的think time才算最合理，不影響迭代次數、并發(fā)用戶(hù)數和吞吐量，是值得我們思考的問(wèn)題。

三，軟件性能測試的分類(lèi)

根據測試目的不同，可以把軟件性能測試以及性能有關(guān)的其它一些測試分為以下幾類(lèi)。

1， 性能測試   這里的性能測試是一個(gè)狹義的概念，是指測試軟件的性能是否符合需求中規定的性能。

2， 并發(fā)測試  

3， 壓力測試

4， 可靠性測試

5， 負載測試

6， 配置測試

7， 失效恢復測試

其他方面的準備

OK，到這里，我們就可以做測試前的準備了。了解項目背景，制定測試計劃，參于人員有人數用各自的任務(wù)，測試范圍和目標，測試模型，測試數據，系統信息，搭建測試環(huán)境等等，所有這些都準備好了，在下一篇，我以一個(gè)自己寫(xiě)的博客網(wǎng)為例用LR來(lái)現實(shí)其性能測試。

今天到這里，謝謝大家，有不足之處，真誠希望各位多多指點(diǎn)。

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">導讀

其實(shí)并不想寫(xiě)關(guān)于理論的東西，理論性的東西網(wǎng)上有很多，更喜歡說(shuō)一些實(shí)際操作性的話(huà)題。前幾篇大多是說(shuō)的關(guān)于單元測試方面，現在就對單元測試做個(gè)總結。純屬于個(gè)人理解,不足和巧合之處敬請大家指正。

什么是單元測試

                在你要去做一件事情時(shí)，總得知道是什么事吧。做單元測試也是如此，得先知道什么是單元測試。OK，傳統軟件對“單元”一詞有各種定義，對“單元測試”也是一如此。這里我取其一種，即單元是可以編譯和執行的最小軟件構件，是決不會(huì )指派給多個(gè)程序員開(kāi)發(fā)的軟件構件。對于結構化程序而言，程序單元是指程序中定義的函數和子程序，單元測試就是對函數或子程序進(jìn)行的測試。但有些也可以把緊密相關(guān)的一組函數或過(guò)程看做一個(gè)單元，如函數A調用函數B，那么在執行測試時(shí)，可以將A和B合并為一個(gè)單元進(jìn)行測試。對于面向對象設計程序而言，程序單元是指特定的一個(gè)具體的類(lèi)或相關(guān)的多個(gè)類(lèi)，單元測試就是對類(lèi)的測試；有時(shí)候，在一個(gè)類(lèi)特別復雜的時(shí)候，可以把類(lèi)中的方法作為一個(gè)單元進(jìn)行測試。

單元測試要測試程序中的哪些方面

              現在你已經(jīng)知道什么是單元測試了，但單元測試到底要測試程序中的哪些方面呢？有些人，包括本人一開(kāi)始學(xué)習單元測試也犯過(guò)這樣的錯誤，就是只寫(xiě)一個(gè)測試用例，讓所有代碼從頭到尾跑一次，只測試一條能夠正確執行的路徑，如果測試通過(guò)了，就認為測試工作已經(jīng)完成。實(shí)際上并非如此。單元測試的目的是根據可能是各種情況，確定測試內容，確定這段代碼是否在任何情況下都和期望的一致。因此，在單元測試時(shí)，測試人員在依據詳細設計規格說(shuō)明書(shū)和源程序清單，理解程序的輸入輸出和模塊的邏輯結構，從以下五個(gè)方面考慮：

1， 模塊接口，主要測試數據在模塊接口處是否出錯，能否正確地輸入輸出。

2， 局部數據結構，主要檢查臨時(shí)存儲在模塊內部的數據在程序執行過(guò)程中是否完整，正確。

3， 獨立路徑，主要是為了發(fā)現因計算錯誤，比較不正確和控制流不適當而造成的錯誤而設計相應測試用例。

4， 出錯處理，主要檢查程序是否能預見(jiàn)各種出錯條件，并進(jìn)行相應的出錯處理。

5， 邊界條件，邊界測試是單元測試中最后也是最重要的一項任務(wù)，主要檢查軟件在邊界上是否失效。

怎樣進(jìn)行單元測試

         到此處，或許你已經(jīng)想躍躍欲試了。OK，現在就開(kāi)始，對程序進(jìn)行單元測試，方法大體上有兩種，一是靜態(tài)測試，另一種就是動(dòng)態(tài)測試。涉及了白盒測試技術(shù)知識。

一，靜態(tài)測試

在靜態(tài)測試中，一般會(huì )用詞法分析與語(yǔ)法分析和靜態(tài)錯誤分析。

用詞法分析與語(yǔ)法分析可以獲得軟件組成的重要因數，如變量標識符，常量等，組合這些基本因數可以得到軟件的基本信息。

靜態(tài)錯誤分析用于確定在源程序中是否有某類(lèi)錯誤或不安全的結構，主要有四種類(lèi)型：類(lèi)型和單位分析，引用分析，表達式分析和接口分析。

 

在實(shí)際工作中，如果測試需求嚴格，可能還會(huì )對代碼進(jìn)行檢查，如桌面檢查，代碼審查，走查，等等。不同的公司有不同的做法。

 

二，動(dòng)態(tài)測試

動(dòng)態(tài)測試，是一種需要執行原程序或測試類(lèi)程序的一種測試方法。在軟件動(dòng)態(tài)測試中，程序插樁是一種基本的測試手段。借助在被測試程序中插入操作，來(lái)實(shí)現測試的目的。在單元測試中，最重要的莫過(guò)于邏輯覆蓋率的測試。邏輯覆蓋是通過(guò)對程序邏輯結構的遍歷實(shí)現程序的覆蓋，主要有語(yǔ)句覆蓋（SC），判定覆蓋（DC），條件覆蓋（CC），條件判定組合覆蓋（CDC），多條件覆蓋（MCC）和修正判定條件覆蓋（MCDC）。還有路徑覆蓋和基本路徑測試法等等。關(guān)于這些覆蓋的定義和用法這里就不做過(guò)多的述說(shuō)了，因為很多測試資料及網(wǎng)上都可以很容易找到，也很容易看懂。關(guān)鍵的是在工作中，怎樣設計一個(gè)成功的測試用例來(lái)提高被測程序的覆蓋率，這才是作為一個(gè)測試工作者要思考的問(wèn)題。與該文章一起，我會(huì )上傳一個(gè)相關(guān)的文檔，感興趣的朋友可以下載看看。

 

怎樣做好單元測試

             在你知道為什么，怎樣做時(shí)，你是否這樣想過(guò)，怎樣才能做得最好呢？當有很多方法可以同是實(shí)現時(shí)，你是否想過(guò)，用哪種方法可以以最快的速度達到最好的效果？先搞懂為什么，再思考怎么做，最后深入研究怎樣才能做得最好。這是我一直以來(lái)的學(xué)習習慣，感覺(jué)很好，你們也可是試試。

            怎樣做好單元測試，除了你要懂得軟件開(kāi)發(fā)流程，測試基本知識，你還需要熟悉代碼，懂得編程，具備良好的邏輯思維能力和洞查能力加上有良好的職業(yè)敏感度。除此之外，你還得有很強的學(xué)習能力，因為單元測試中對不同開(kāi)發(fā)語(yǔ)言，不同技術(shù)，相對應的測試方法和技術(shù)都會(huì )不同，所用到的測試工具也不同，所以你要有很強的學(xué)習能力。

          要做好一個(gè)單元測試，當然少不了應用工具，在這里舉例一些

1， JUnit ：一種測試java類(lèi)的測試框架，可以ant結合，達到自動(dòng)化測試，官網(wǎng)地址是：http://www.junit.org/   ant 下載地址是：http://ant.apache.org/

2， Jtest：和JUnit類(lèi)似，只是JUnit是開(kāi)源軟件。官網(wǎng)地址是：http://www.parasoft.com/jsp/home.jsp

3， Cactus：一種測試servlet，jsp，taglibs，filter的框架，是apache開(kāi)發(fā)的一個(gè)開(kāi)源軟件，官網(wǎng)地址是：http://www.apache.org

4， Strutstest：一種測試struts的框架，結合junit可以測試struts中的action。下載地址是：http://strutstestcase.sourceforge.net/  

5， Jsunit：一種類(lèi)似junit的測試框架，主要用來(lái)測試javascript。下載地址是：http://sourceforge.net/projects/jsunit/

6， httpUnit：httpUnit本身不是測試工具，而是協(xié)助進(jìn)行功能單元測試的工具，與JUnit一起，可以整合cactus。官網(wǎng)地址為：http://httpunit.sourceforge.net/

7， C++test：一種C和C++的單元測試工具，官網(wǎng)地址是：http://www.parasoft.com/jsp/home.jsp

 

除了以上所要求具備的，會(huì )用的東西外，更少不了一個(gè)

好的測試計劃。當這些都準備好了后，就開(kāi)始Run吧。

 

         OK，就說(shuō)這些我所常用的了，還有很多，大家在網(wǎng)上都很容易找到，就不一一例舉了。

這篇結束后，這類(lèi)話(huà)題就不再說(shuō)了，將轉入功能測試，性能測試及自動(dòng)化測試（LoadRunner，WAS，JMeter，WinRunner）相關(guān)話(huà)題，謝謝大家的支持，歡迎大家指正錯誤的地方，我的QQ是117293968，加時(shí)請注明“軟件測試”，大家一起相互學(xué)習，相互幫助啦。

       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">軟件質(zhì)量是軟件的靈魂所在。及時(shí)，盡早，不斷地對軟件系統進(jìn)行測試，從而找出軟件中的BUG，軟件測試的目的就是尋找錯誤，并且盡最大的可能尋找最多的錯誤，所以說(shuō)軟件測試是可以在一定的程度上提高軟件的質(zhì)量。

軟件測試分類(lèi)很多，對不同的公司而言，又有不同的測試分類(lèi)。按照開(kāi)發(fā)階段劃分，有單元測試，集成測試，系統測試，確認測試和驗收測試；按照測試實(shí)施組織劃分，有開(kāi)發(fā)方測試，也就是開(kāi)發(fā)方自己的測試團隊的測試，用戶(hù)測試及第三方測試；還的一種是按照測試技術(shù)劃分，有白盒測試，黑盒測試和灰盒測試，灰盒測試就是在測試活動(dòng)中所用測試技術(shù)介于白盒和黑盒之間的一個(gè)測試技術(shù)。

再者就是軟件測試的模型了。開(kāi)發(fā)有開(kāi)發(fā)的模型，軟件測試也開(kāi)展出來(lái)一些很重要的模型供測試人員參考。這里就簡(jiǎn)要分析幾個(gè)。

第一個(gè)是V模型，V模型是最具代表意義的測試模型，如下圖所示：

           

V模型是是軟件開(kāi)發(fā)瀑布模型的變種，它反映測試活動(dòng)與分析和設計的關(guān)系，從左到右，描述了基本的開(kāi)發(fā)過(guò)程和測試行為，非常明確地標明了測試過(guò)程中存在的不同級別，并且清楚地描述這些個(gè)測試階段和開(kāi)發(fā)過(guò)程期間各個(gè)階段的對應關(guān)系。但V模型也存在一定的局限性，就是把測試作為需求分析，概要設計，詳細設計和編碼之后的最后一個(gè)活動(dòng)，需求分析等前期產(chǎn)生的錯誤直到后期的驗收測試才能發(fā)現。

第二個(gè)是W模型，如下圖所示：

W模型在V模型的基礎上，增加一與開(kāi)發(fā)階段的同步測試，形成W模型；測試與開(kāi)發(fā)同步進(jìn)行，有利用盡早的發(fā)現問(wèn)題。相對于V模型而言，W模型更加科學(xué)。W模型可以說(shuō)是V模型自然而然的發(fā)展。它強調：測試伴隨著(zhù)整個(gè)軟件開(kāi)發(fā)周期，而且測試的對象不僅僅是程序，需求,功能和設計同樣要測試。但W模型也是有局限性的，它的局限性是仍把開(kāi)發(fā)活動(dòng)看成是從需求開(kāi)始到編碼結束的串行活動(dòng)，只有上一階段完成后，才可以開(kāi)始下一階段的活動(dòng)，不能支持迭代，自發(fā)性以及變更調整。W模型把軟件開(kāi)發(fā)和測試看成是一種線(xiàn)性的前后關(guān)系。

在V模型和W模型中，都沒(méi)有很好地體現測試流程的完整性，為了解決這個(gè)問(wèn)題，有專(zhuān)業(yè)就提出了H模型，這就是現在要講的第三個(gè)測試模型，H模型，如下圖所示：

H模型將測試活動(dòng)完全獨立出來(lái)，形成一個(gè)完全獨立的流程，將測試準備活動(dòng)和測試執行活動(dòng)清晰地體現出來(lái)。上示意圖僅僅演示了在整個(gè)生產(chǎn)周期中某個(gè)層次上的一次測試“微循環(huán)”，圖中其它流程可以是任意開(kāi)發(fā)流程。H模型是一個(gè)獨立的流程，貫穿于整個(gè)產(chǎn)品周期，與其它流程并發(fā)地起先，當某個(gè)測試時(shí)間點(diǎn)就緒時(shí)，軟件測試即將從測試準備階段進(jìn)入測試執行階段。

除了以上三種常見(jiàn)的測試模型外，還有X模型，前置測試模型等等。應該說(shuō)這些測試模型對指導測試工作的進(jìn)行具有重要的意義，但任何模型都不是完美的。我們應該盡可能地去應用模型中對項目有實(shí)用價(jià)值的方面，不強行地為使用模型而使用模型，否則也就沒(méi)有實(shí)際意義了。

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實(shí)現對servlet類(lèi)進(jìn)行單元測試二

 

OK，可以開(kāi)始寫(xiě)測試類(lèi)了，代碼為：

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));

    }

}

 

直接運行，不必啟動(dòng)tomcat，結果如圖：

看到了最喜歡的綠帶，說(shuō)明你的測試通過(guò)了，可以進(jìn)行下一步開(kāi)發(fā)啦。

  

最后，解釋下一兩個(gè)名詞及說(shuō)明下我的開(kāi)發(fā)環(huán)境：

 

組件：組件是在容器內部執行的一段代碼。

容器：容器則是為存放在其內的組件提供有用服務(wù)（比如生命周期，安全，事務(wù)，分布等等）的器皿。

 

我的開(kāi)發(fā)環(huán)境是：

軟件環(huán)境：xp sp3，MyEclipse 8.0M1，tomcat 6.0.20

 

謝謝大家的支持，由于此網(wǎng)站所支持博文字數有限，故分了三篇來(lái)完成本話(huà)題，給大家帶來(lái)的不便之處，敬請原諒。再者本人水平有限，歡迎大家指正錯誤和不足之處，謝謝大家。

按照官網(wǎng)的定義，我們就可以用MILY: 'Arial','sans-serif'; FONT-SIZE: 10.5pt" lang=EN-US>cactus和JUnit一起來(lái)完成對上述servlet的測試了。

首先，我們來(lái)建一個(gè)web項目，我定義的名稱(chēng)為cactustest；再把下載下來(lái)的cactus解壓，把cactus-1.7.2\lib中的jar包復制到WebRoot\WEB-INF\lib下，也可以建立自己的用戶(hù)庫，方便以后的項目使用。搭建好環(huán)境后，接下來(lái)就可以寫(xiě)上面程序的測試類(lèi)啦，讓我們來(lái)用cactus為上面的程序寫(xiě)一個(gè)測試類(lèi)，測試類(lèi)代碼為：

package com.test.servlet;

 

import org.apache.cactus.ServletTestCase;

import org.apache.cactus.WebRequest;

 

public class LoginServletCactusTest extends ServletTestCase {

    //先來(lái)個(gè)正確的測試用例

    //分別為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));

    }

   //再來(lái)個(gè)錯誤的測試用例

   //分別為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));

    }

}

這樣，測試類(lèi)就搞定了，

 下圖是我的項目結構如下圖：

 

OK，現在就可以啟動(dòng)tomcat了，部署成功后在地址欄上輸入http://localhost:8080/cactustest/ServletTestRunner?suite=com.test.servlet.LoginServletCactusTest  回車(chē)，你將會(huì )看到讓自己感到高興的結果，此種方式是以XML形式輸出測試結果，如下圖：

還可以用cactus自定義的的樣式表的方式輸出測試結果，只需要把cactus自帶的cactus-report.xsl文件加入到webroot目錄下就可以了，在地址欄上輸入http://localhost:8080/cactustest/ServletTestRunner?suite=com.test.servlet.LoginServletCactusTest&xsl=cactus-report.xsl  回車(chē)，這種形式的輸出比較美觀(guān)，如下圖所示：

到這里，一個(gè)單獨用JUnit不能完成的測試用上cactus就搞定了，或許我們會(huì )感覺(jué)高興下，從技術(shù)上我們是實(shí)現了用JUnit加cactus對servlet的測試，但細心的你是否已經(jīng)發(fā)現了其中的不便之處，就是每次對一個(gè)servlet測試前都要啟動(dòng)tomcat，這樣大大增加了測試時(shí)間，也可能影響項目進(jìn)度。有沒(méi)有什么方法可以解決這個(gè)問(wèn)題呢？細心的你可能已經(jīng)發(fā)現，在我的項目結構圖上，已經(jīng)有一個(gè)LoginServletJettyTest.java類(lèi)。是的，這個(gè)就是為了解決上面問(wèn)題而用的另一種框架，它就是Jetty。它運行測試servlet就像用JUnit測試普通java類(lèi)一樣那么簡(jiǎn)單，不需要啟動(dòng)tomcat。

在這里我們可以使用Jetty 它的下載地址為 http://jetty.mortbay.org/jetty/index.html ，它是個(gè)Java編寫(xiě)的HTTP服務(wù)器，本身也是個(gè)Container，Cactus集成了Jetty，并提供與測試相關(guān)的簡(jiǎn)便類(lèi)別。

使用Cactus+Jetty執行測試，在更大的程度上隱藏了測試運行過(guò)程的細節，您不必關(guān)心Redirector Proxy，更不一定要關(guān)心TestCase在客戶(hù)端與服務(wù)器端的行為，運行起來(lái)就如同在運作一個(gè)JUnit測試。

   在WebRoot\WEB-INF\lib原來(lái)的基礎上加入cactus.core.framework.uberjar.javaEE.14-1.8.1.jar就行了.

 

未完，下篇 用cactus,jetty實(shí)現對servlet類(lèi)進(jìn)行單元測試三 繼續……

JUnit是名聲大燥了，想必只要學(xué)過(guò)JAVA的人都知道世上有個(gè)東東叫JUnit。記得有個(gè)想學(xué)JUnit的兄弟在群上大喊：我要學(xué)JUnit，因為JUnit應用最廣，最好的單元測試工具。無(wú)法否認，JUnit是一個(gè)非常讓JAVA程度員或白盒測試人員喜愛(ài)的一個(gè)框架。但有時(shí)候應用最廣的未必就是萬(wàn)能的，最好的未必就是最合適的。

JUnit也是有缺點(diǎn)的。想象一下，你有一個(gè)web程序，非常簡(jiǎn)單的那種，是用servlet實(shí)現的，你希望對其中的loginUser（）方法進(jìn)行單元測試，代碼如下：

 

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;

        }

    }

}

 

為了能夠測試這個(gè)方法，你需要得到一個(gè)合法的HttpServletRequest對象。但不幸的是，你不可能調用 new HttpServletRequest 來(lái)創(chuàng )建一個(gè)可用的請求。因為HttpServletRequest的生命周期是由容器管理的，因此你無(wú)法單獨使用JUnit為loginUser方法編寫(xiě)測試類(lèi)。

    此時(shí)我們今天的主角就要出來(lái)了，它就是cactus，cactus是什么？仙人掌嗎？呵呵，當然不是了。仙人掌只是它翻譯過(guò)來(lái)的中文名。它如commons-dbutils，commons-beanutils等等一樣，是apache上的一個(gè)開(kāi)源框架。下載地址為http://jakarta.apache.org/cactus/index.html 或是http://archive.apache.org/dist/jakarta/cactus/  用官網(wǎng)是話(huà)說(shuō)，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是一個(gè)基于JUnit框架的簡(jiǎn)單測試框架，用來(lái)單元測試服務(wù)端Java代碼。Cactus框架的主要目標是能夠單元測試服務(wù)端的使用Servlet對象的Java方法httpServletRequest,HttpServletResponse,HttpSession等。Cactus的工作原理在官網(wǎng)上也可以找到，那有詳細的說(shuō)明，以下是其中的一種:圖來(lái)自于cactus官網(wǎng)

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

這是官網(wǎng)的簡(jiǎn)單說(shuō)明，意思是：cactus提供了幾個(gè)TestCase的類(lèi)擴展了JUnit的TestCase的，同時(shí)也提供了若干種轉向器（重定向程序組件，JSP的重定向，...).上圖是一個(gè)普通的圖，這足以解釋的原則。你會(huì )發(fā)現，在未來(lái)一段特定的重定向代理細節。 YYYTestCase =（ServletTestCase | FilterTestCase | JspTestCase）XXX是測試案例的名稱(chēng)。每個(gè)YYYTestCase類(lèi)包含幾個(gè)測試案例。

我們將使用Cactus的ServletTestRedirector作為上圖介紹的Redirector Proxy，并使用Cactus的ServletTestRunner作為執行測試時(shí)的TestRunner，這兩個(gè)被撰寫(xiě)為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 .單元測試概述

  

單元測試——是最小粒度的測試，以測試某個(gè)功能或代碼塊。一般由程序員來(lái)做，因為它需要知道內部程序設計和編碼的細節。

1.1. 單元測試的好處

    A、提高開(kāi)發(fā)速度——測試是以自動(dòng)化方式執行的，提升了測試代碼的執行效率。

    B、提高軟件代碼質(zhì)量——它使用小版本發(fā)布至集成，便于實(shí)現人員除錯。同時(shí)引入重   構概念，讓代碼更干凈和富有彈性。

    C、提升系統的可信賴(lài)度——它是回歸測試的一種。支持修復或更正后的“再測試”，可確保代碼的正確性。

1.2 單元測試的針對對象

   A、面向過(guò)程的軟件開(kāi)發(fā)針對過(guò)程。

   B、面向對象的軟件開(kāi)發(fā)針對對象。

   C、可以做類(lèi)測試，功能測試，接口測試（最常用于測試類(lèi)中的方法）。

1.3 單元測試工具和框架

    目前的最流行的單元測試工具是xUnit系列框架，常用的根據語(yǔ)言不同分為JUnit（java），     CppUnit（C ），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。該測試框架的第一個(gè)和最杰出的應用就是由Erich Gamma （《設計模式》的作者）和Kent Beck（XP（Extreme Programming）的創(chuàng )始人 ）提供的開(kāi)放源代碼的JUnit。

2. 什么是JUnit及其特性

如果您要對編寫(xiě)的程序進(jìn)行測試，應該如何進(jìn)行呢？傳統的測試方式是通過(guò)信賴(lài)人工對輸出結果的判斷，缺少效率且通常難以組織，且針對單一程序通常要設計專(zhuān)門(mén)的測試程序，如果您是在編寫(xiě)Java，您可以使用JUnit來(lái)為你提供有效的測試。 

2.1. 什么是JUnit？

在這里引述一下JUnit FAQ中的解釋。 
JUnit是一個(gè)開(kāi)放原始碼的Java測試框架（testing framwork），它用來(lái)編寫(xiě)與執行重復性的測試，它是用在單元測試框架的xUnit架構的貫例。 

2.2. JUnit的好處

A、可以使測試代碼與產(chǎn)品代碼分開(kāi)。

B、針對某一個(gè)類(lèi)的測試代碼通過(guò)較少的改動(dòng)便可以應用于另一個(gè)類(lèi)的測試。

C、易于集成到測試人員的構建過(guò)程中，JUnit和Ant的結合可以實(shí)施增量開(kāi)發(fā)。

D、JUnit是公開(kāi)源代碼的，可以進(jìn)行二次開(kāi)發(fā)。

C、可以方便地對JUnit進(jìn)行擴展。

2.3 JUnit單元測試編寫(xiě)原則：

A、是簡(jiǎn)化測試的編寫(xiě)，這種簡(jiǎn)化包括測試框架的學(xué)習和實(shí)際測試單元的編寫(xiě)。

B、是使測試單元保持持久性。

C、是可以利用既有的測試來(lái)編寫(xiě)相關(guān)的測試。

2.4  JUnit包括以下的特性： 

  A. 對預期結果的斷言

  B. 對相同共享資料的測試組裝
  C. 易于組織與執行測試的測試套件

  D 圖形與文字界面的測試器

3. JUnit 的使用入門(mén)

現在很多Java開(kāi)發(fā)工具都集成了JUnit，如MyEclipse,Netbean,JBuilder等等，你可以直接使用。當然你也可以在JUnit的官方網(wǎng)站上下載，網(wǎng)址是http://junit.org

我自己用的是MyEclipse6.6版本的java開(kāi)發(fā)工具，JUnit是4.5版本�，F在我們來(lái)寫(xiě)一個(gè)java類(lèi)，也就是被測試的類(lèi)，然后用JUnit來(lái)進(jìn)行單元測試。

首先，在MyEclipse中建一個(gè)java工程，我這里的工程名為javaproject2，引入JUnit4.5相關(guān)的jar文件，把環(huán)境搭建好。然后建立相應的包。這里應當注意，為了方便管理，我們的源代碼和測試代碼最好不要放在同一個(gè)代碼文件夾中的同一個(gè)包中。我們可以再建一個(gè)代碼文件夾test，并在其中建一個(gè)與源代碼文件夾（src）中的包名一致的包。這樣做的好處是源代碼和測試代碼雖然不在同一個(gè)文件夾，但它們的.class文件都在同一個(gè)文件夾中，實(shí)現了源代碼和測試代碼的分離，方便管理。

如圖1.0所示：

 

               （圖1.0）

搭建好測試環(huán)境后，就可以進(jìn)行相關(guān)類(lèi)的編寫(xiě)了。這里我設計了一個(gè)稅收類(lèi)Revenue.java，放在src中的com.cuckoo2010包中。該類(lèi)包含一個(gè)稅費計算的方法revenuemethod(double mymoney)，方法具體的實(shí)現邏輯為：當個(gè)人收小于或等于800則不征稅，當個(gè)人收入大于800底于2000元時(shí)，征收百分之七的稅，當個(gè)人收入大于2000且底于5000元時(shí)，征收百分之十五的稅，當個(gè)人收入超過(guò)5000時(shí)，征收百分之二十五的稅。設定一個(gè)異常狀態(tài)，當輸入值等于或小于零時(shí)拋出一個(gè)異常。代碼如下：

package com.cuckoo2010;

/**

 * 被測試的類(lèi) Revenue.java

 * @author 松子煮茶

 */

public class Revenue {

private double money;

public double revenuemethod(double mymoney) throws Exception {

//個(gè)人收小于或等于800則不征稅

if (mymoney <= 800) {

return this.money = mymoney;

} 

//個(gè)人收入大于800底于2000元時(shí)，征收百分之七的稅

else if (mymoney <= 2000) {

return this.money = mymoney - mymoney * 0.07;

} 

//個(gè)人收入大于2000且底于5000元時(shí)，征收百分之十五的稅

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

return this.money = mymoney - mymoney * 0.15;

} 

//個(gè)人收入超過(guò)5000時(shí)，征收百分之二十五的稅

else if (mymoney > 5000) {

return this.money = mymoney - mymoney * 0.25;

} 

else if (mymoney <= 0) {

/**

 * 自定義異常

 * 當金額小于或等于0時(shí)，系統拋出異常

 */

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

}

return this.money;

}

}

寫(xiě)完這個(gè)類(lèi)后，我們可以根據這個(gè)類(lèi)設計一個(gè)測試用例，也就是各種輸入值，預期值及實(shí)際值。

如表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

學(xué)測試已經(jīng)快兩年了，要說(shuō)說(shuō)啦...

查看(60) 評論(1) 收藏 分享 圈子 管理

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

<ruby id="h6500"><table id="h6500"></table></ruby>

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