qileilove

　　（1）系統(tǒng)架構(gòu)、開發(fā)方法、人員安排、實現(xiàn)過程、開發(fā)周期

　　（2）產(chǎn)品應(yīng)用范圍、面向的用戶及用戶人數(shù)、產(chǎn)品要實現(xiàn)的功能、使用的數(shù)據(jù)類型

　　（3）開發(fā)環(huán)境：開發(fā)工具版本、數(shù)據(jù)庫版本、操作系統(tǒng)版本

　　（4）運行環(huán)境：硬件平臺、操作系統(tǒng)、支撐環(huán)境（數(shù)據(jù)庫版本、IE版本）、相關(guān)組件、服務(wù)

　　（5）安全要求：產(chǎn)品權(quán)限、數(shù)據(jù)庫權(quán)限、部署的服務(wù)器信息、防火墻信息、要放開的端口號

　　（6）性能需求：系統(tǒng)支持的并發(fā)數(shù)量、響應(yīng)時間、數(shù)據(jù)庫中數(shù)據(jù)容量、占用的系統(tǒng)CPU、磁盤空間、傳輸速度、網(wǎng)絡(luò)帶寬等。

　　2、需求分析

　　（1）畫出整體系統(tǒng)的（網(wǎng)絡(luò)）拓撲圖

　　（2）根據(jù)不同角色身份進行分析，畫出系統(tǒng)流程圖：用戶角度、安裝人員角度、維護人員角度

　　（3）從數(shù)據(jù)庫角度進行深入分析：數(shù)據(jù)層、業(yè)務(wù)層、表現(xiàn)層

　　（4）系統(tǒng)包含的功能模塊/子系統(tǒng)列表，畫出各模塊的流程圖，各模塊間的關(guān)系及銜接接口

　　（5）安全級別是否達標(biāo)、對性能需求進行分析

　　3、測試準(zhǔn)備工作

　　（1）環(huán)境準(zhǔn)備：開發(fā)環(huán)境、測試環(huán)境、用戶機干凈環(huán)境虛擬機、復(fù)雜環(huán)境虛擬機（IE不同版本、操作系統(tǒng)不同版本、防火墻不同、數(shù)據(jù)庫版本不同）

　　（2）數(shù)據(jù)準(zhǔn)備：正式數(shù)據(jù)、不自洽數(shù)據(jù)

　　（3）書寫測試功能點

　　（4）根據(jù)需求分析結(jié)果和測試功能點，制定測試策略、測試方法、測試周期、人員安排。

　　4、測試開始

　　（1）測試用例書寫：根據(jù)八大測試用例方法書寫：等價類劃分方法、邊界值分析方法、錯誤推測方法、因果圖方法、判定表驅(qū)動分析方法、正交實驗設(shè)計方法、功能圖分析方法、場景設(shè)計方法

　　（2）編寫測試使用的sql語句、編寫自動化測試腳本

　　（3）功能測試：可借助測試工具，例如：Xenu、Cookie Editor、QTP

　　（4）白盒測試：代碼走讀、靜態(tài)結(jié)構(gòu)分析法、邏輯覆蓋法、基本路徑測試法，工具：NUnit。詳讀web.config等配置文件，輔助理解程序整體結(jié)構(gòu)，檢查之前的測試點是否完善。

　　（5）數(shù)據(jù)庫測試：數(shù)據(jù)備份與恢復(fù)測試、故障轉(zhuǎn)移和恢復(fù)測試、數(shù)據(jù)遷移數(shù)據(jù)操作測試（包括不同版本數(shù)據(jù)庫間的遷移、跨數(shù)據(jù)庫類型遷移，例如SQL遷移到Oracle）。

　　（6）數(shù)據(jù)庫壓力測試：

　　● 通過數(shù)據(jù)庫連接數(shù)的變化，測試是否有連接泄露的現(xiàn)象

　　● 是否有數(shù)據(jù)表鎖死等現(xiàn)象

　　（7）性能測試：連接速度測試、負載測試、壓力測試，工具loadrunner

　　（8）安全性測試：建立整體的威脅模型，測試溢出漏洞、信息泄漏、錯誤處理、SQL 注入、身份驗證和授權(quán)錯誤、XSS攻擊。可用工具：

　　● Paros proxy （http://www.parosproxy.org），用于截獲HTTP 通信數(shù)據(jù)

　　● Fiddler （http://www.fiddlertool.com/fiddler），用于截獲HTTP 通信數(shù)據(jù)

　　● TamperIE （http://www.bayden.com/dl/TamperIESetup.exe），用于修改GET 和POST

　　（9）兼容性測試：利用之前準(zhǔn)備的不同環(huán)境，測試產(chǎn)品兼容性及支持環(huán)境

　　（10）安裝測試：不同環(huán)境、安裝過程不同選項、不同路徑

　　（11）參數(shù)測試：書寫可配置參數(shù)的意義及語法說明文檔，并進行測試

　　5、測試結(jié)束：

　　（1）測試總結(jié)：bug情況、系統(tǒng)穩(wěn)定性、使用方便度、遺留待解決改進的問題

　　（2）功能點測試報告

　　（3）性能測試報告

　　（4）環(huán)境要求文檔：操作系統(tǒng)的版本（包括企業(yè)版、標(biāo)準(zhǔn)版等）、位數(shù)；數(shù)據(jù)庫的版本（包括企業(yè)版、標(biāo)準(zhǔn)版等）、位數(shù)；.Framework版本；不支持的環(huán)境

　　（5）使用手冊：系統(tǒng)常見故障分析及排除說明、錯誤信息編碼說明

　　（6）部署文檔：包含F(xiàn)AQ的內(nèi)容以及截圖

　　（7）維護文檔：系統(tǒng)目錄結(jié)構(gòu)說明、系統(tǒng)啟動進程說明、數(shù)據(jù)備份說明

　　（8）外出安裝前的檢查文檔

　　6、外出安裝注意事項：

　　（1）設(shè)計若安裝出現(xiàn)問題的緊急預(yù)案

　　（2）安裝前檢查環(huán)境（待寫一個環(huán)境檢查的小工具）

　　（3）根據(jù)事先寫的檢查文檔一項項打勾、安裝后對每一模塊進行測試驗證

　　（4）安裝結(jié)束后，將IIS、WEB.CONFING、注冊表信息、日志信息、防火墻信息、安裝路徑、安裝程序等拷貝回來，撰寫文檔。

　　每個人都會犯錯誤，但作為數(shù)據(jù)庫管理員，我們應(yīng)該盡量避免失誤，從而為公司降低成本，并確保數(shù)據(jù)質(zhì)量。下面的五個數(shù)據(jù)庫設(shè)計失誤必須引起我們的警惕。

　　1、選擇恰當(dāng)?shù)臄?shù)據(jù)類型，避免數(shù)據(jù)庫的過度膨脹

　　請留意數(shù)據(jù)類型的選擇。例如，如果你很清楚某列的數(shù)值范圍在0-100，000之間，那么就不必使用BIGINT數(shù)據(jù)類型，因為INT類型就已經(jīng)足夠了。

　　選擇前者意味著，你每插入一條數(shù)據(jù)就比后者浪費了4個字節(jié)。這聽起來也許微不足道，但隨著數(shù)據(jù)量的增長，問題將會凸顯出來。

　　2、遵循ISO標(biāo)準(zhǔn)，保證異構(gòu)數(shù)據(jù)庫系統(tǒng)之間的互通性

　 　大型企業(yè)的IT基礎(chǔ)架構(gòu)非常復(fù)雜，可能需要不同數(shù)據(jù)庫系統(tǒng)之間的數(shù)據(jù)交換。我們以TIMESTAMP數(shù)據(jù)類型為例，在Transact-SQL中定義的 TIMESTAMP數(shù)據(jù)類型與ISO標(biāo)準(zhǔn)有所不同。其它的數(shù)據(jù)庫系統(tǒng)與ISO標(biāo)準(zhǔn)也有所差別。所以，我們要盡可能地遵循ISO標(biāo)準(zhǔn)，以保證異構(gòu)數(shù)據(jù)庫系統(tǒng) 之間的互通性。

　　3、以恰當(dāng)?shù)臋C制實現(xiàn)序列化

　　保證在數(shù)據(jù)庫中插入記錄的序列化非常 有必要，許多數(shù)據(jù)庫設(shè)計者通過各種機制來確保序列化的應(yīng)用。一些數(shù)據(jù)庫設(shè)計者喜歡在數(shù)據(jù)庫設(shè)計中引入GUID，但引入GUID并不是一個好的選擇，這是因 為GUID默認并非序列化的，使用GUID列作為主鍵和/或索引甚至?xí)斐尚阅軉栴}。

　　4、創(chuàng)建索引時要將外鍵考慮在內(nèi)

　　如果你的數(shù)據(jù)庫中已定義外鍵，那么在建立索引的時候就要多加留神了，要把這種情況納入數(shù)據(jù)庫設(shè)計的整體之中去。

　　5、不要忽略與業(yè)務(wù)需求相關(guān)的候選鍵

　　數(shù)據(jù)庫設(shè)計者不應(yīng)只將注意力放在代理鍵上，而忘卻業(yè)務(wù)需求。顯然，這對數(shù)據(jù)質(zhì)量非常不利。如果你沒有在與業(yè)務(wù)相關(guān)的候選鍵上建立任何約束或索引，可能會出現(xiàn)重復(fù)值。

　　請遠離上面的5個數(shù)據(jù)庫設(shè)計失誤吧，這會幫助你為公司節(jié)省成本，并提高數(shù)據(jù)質(zhì)量。

　　這8組關(guān)系為如下所示。

　　1）質(zhì)量與人員的關(guān)系。

　　2）質(zhì)量與流程的關(guān)系。

　　3）質(zhì)量與技術(shù)的關(guān)系。

　　4）質(zhì)量與資源的關(guān)系。

　　5）人員與技術(shù)的關(guān)系。

　　6）人員與流程的關(guān)系。

　　7）技術(shù)與資源的關(guān)系。

　　8）流程與資源的關(guān)系。

　　下面就簡單說明一下這些關(guān)系的內(nèi)涵，以及如何處理它們之間的關(guān)系（參見圖1-1）。

圖1-1

　　1、質(zhì)量與人員的關(guān)系

　　質(zhì)量需要組織中的全員負責(zé)，每個人的行為都能對軟件產(chǎn)品質(zhì)量有直接的影響，每個人都應(yīng)樹立積極的態(tài)度，做正確的事，對軟件產(chǎn)品質(zhì)量的提高貢獻自己的力量。

　　2、質(zhì)量與流程的關(guān)系

　　借助流程避免或減少人為的錯誤，借助流程可以督促人們在正確的時間做正確的事，甚至基于已有的良好流程迫使流程自身的優(yōu)化，持續(xù)改進。所以，基于流程的質(zhì)量改進是相對可靠、穩(wěn)定的，基于流程的質(zhì)量改進是可持續(xù)發(fā)展的。

　　序言：我想主要從實際原理和應(yīng)用上來說說測試框架，這些框架包括：關(guān)鍵字測試框架robot，基于各種語言的分布式STAF框架，集成測試框架Fit（husdon），以及elipse TPTPd性能測試框架等。這不是一套工具教程，而是一套應(yīng)用的簡單思想，個人難免有局限性，見諒。

　　一、STAF介紹

　　STAF全名叫Software Testing Automation Framework，即軟件自動化測試框架，我覺得，STAF可以完全稱得為一個測試框架，其基于軟件開發(fā)中 “系統(tǒng)+組件”的思想，系統(tǒng)是一個架子，各個組件都可以插入到架子中成為其功能一部分。即，STAF是一個這么一個架子，提供了組件插入的規(guī)則，不管你的 組件是用什么語言寫的，只要符合STAF的組件規(guī)范，就都能做為STAF的組件服務(wù)與其他的組件服務(wù)進行通信，即其提供了輕量級分發(fā)機制，負責(zé)將請求轉(zhuǎn)發(fā) 給服務(wù)，從而調(diào)用這些服務(wù)的功能。

　　二、staf原理

　　staf的基本運作原理如下：

　 　1、啟動STAF時，STAF做為系統(tǒng)的一個守護進程開啟，然后同時加載其架構(gòu)中的服務(wù)，這些服務(wù)可以是DLL文件、JAR文件。當(dāng)你設(shè)計一個STAF 的外部服務(wù)的時候，即繼承STAF提供你的接口，你只需要撰寫一個類實現(xiàn)接口的方法即可。也可以這么理解，STAF就像一個操作系統(tǒng)，而這些服務(wù)就像這些操作系統(tǒng)上的應(yīng)用功能軟件，每個軟件之間可以通過內(nèi)存或者管道或者網(wǎng)絡(luò)通道進行互相通信。所以，你若是設(shè)計一個測試框架時，可以參考STAF或者操作系統(tǒng)的這種理念，定義一套規(guī)范接口，以便于框架的靈活拓展和實現(xiàn)，而不是將一套框架寫的死死的。

　　2、STAF在加載服務(wù)的時候，為每個服務(wù)分配了一個句柄，即STAFHandle，這個句柄即作為服務(wù)的唯一標(biāo)識。類比于操作系統(tǒng)會給每一個進程一個進程ID，你打開系統(tǒng)的任務(wù)管理器，能看到很多進程在運作，而你可以通過每個進程的ID對這些進程進行操作。

　　3、STAF之間服務(wù)的交互則可以通過命令行的形式或者向服務(wù)的隊列讀寫的形式進行。命令行可以看做為每個服務(wù)向外公開的消息接口。

　　三、staf的應(yīng)用

　　staf的缺陷在于掌握困難，你需要很清楚它的機制以及其提供的一些服務(wù)的作用后，你才能真正的把他用好

　　1、分布式多執(zhí)行端應(yīng)用：STAF采用P2P架構(gòu)，即沒有服務(wù)器和客戶端之分，任何安裝了STAF的機器之間可以互相通信，可以利用STAF的這種特性實現(xiàn)分布式執(zhí)行的功能，例如：你有10個測試用例， 一般都會將10個測試儀用例在一臺執(zhí)行機器上串行運行，腳本少的話當(dāng)然不會有什么問題，但是當(dāng)腳本數(shù)量龐大到一定程度時，那么你需要一個分配機制，能夠?qū)?這些腳本分配到不同的空閑執(zhí)行端運行，那么STAF可以幫助你實現(xiàn)這些機制，可以指定一臺STAF機器為腳本任務(wù)分配端，然后指定一些STAF機器為執(zhí)行 端，那么任務(wù)分配端收到任務(wù)，即一系列測試腳本后，它可以尋找到空閑執(zhí)行端，應(yīng)用STAF之間的通信，將這些測試腳本分配下去，在每一臺機器上執(zhí)行，然后 返回結(jié)果。這樣，就可以大大節(jié)約一些測試時間了。當(dāng)然，你也可以自己開發(fā)屬于自己的網(wǎng)絡(luò)分配系統(tǒng)，可以采用socket機制實現(xiàn)。

　　2、STAF幾個比較常用的的內(nèi)外服務(wù)：

　　文件系統(tǒng)服務(wù)：即FS服務(wù)，你可以采用FS服務(wù)進行不同機器之間或者一臺機器上的文件之間的傳遞。例如：一些測試腳本和測試結(jié)果、日志等都可以采用這種方式傳遞。

　　時間驅(qū)動服務(wù)：即調(diào)用此服務(wù)來按特定的時間間隔發(fā)送STAF命令，從而調(diào)用別的STAF功能服務(wù)，這其實相當(dāng)于在自動化測試中，每隔多少時間，進行一次測試，這種概念跟持續(xù)集成的按時間間隔進行build有些相似。

　　事件驅(qū)動服務(wù)：即由發(fā)生的事件來驅(qū)動進行通信，從而執(zhí)行STAF命令，事件是通過隊列形式發(fā)送，每個服務(wù)都有自己的一個隊列，服務(wù)通過接收隊列中的請求從而進行功能操作；這種概念跟持續(xù)集成的按事件驅(qū)動進行build有些相似。

　　郵件服務(wù)：即發(fā)送郵件的服務(wù)，當(dāng)測試完成或者失敗時可以觸發(fā)這個服務(wù)發(fā)送郵件。

　　日志服務(wù)：即可以將一些測試結(jié)果或者日志信息按照表格序列的形式存在指定的STAF機器上，然后可以隨時進行讀取。這樣可以當(dāng)一臺STAF機器的測試執(zhí)行完畢后，將測試結(jié)果存在本機或者專門存放日志的STAF機器上，然后隨時可以讀取顯示。

　　壓縮服務(wù)：調(diào)用STAF命令對文件進行壓縮。

　　名字空間服務(wù)：這個服務(wù)挺重要的，就是可以將一些數(shù)據(jù)存在STAF的指定內(nèi)存中，然后獨特的名字對應(yīng)著獨特的數(shù)據(jù)，這個與哈希表有些類似，你可以隨時取得這些數(shù)據(jù)，這些數(shù)據(jù)在后臺都是保存在本地XML文件中的。

　　當(dāng)然，這些服務(wù)只是一些基本服務(wù)，為了拓展你自己定制性的測試框架或者平臺，你可以很好的利用這些基本功能。

　　3、STAX，很多人都不清楚STAX和STAF的關(guān)系，其實從本質(zhì)上而言，STAX和STAF本身沒有太大關(guān)系，即STAX只是調(diào)用了STAF的內(nèi)外部服務(wù)來構(gòu)造了一個測試執(zhí)行引擎。STAX整體機制是：你通過在按照STAX的XML格式定義測試工作流， 可在其中嵌套要執(zhí)行的測試用例，然后由STAX導(dǎo)入，然后執(zhí)行STAF命令，調(diào)用相關(guān)的執(zhí)行服務(wù)執(zhí)行測試，STAX能夠監(jiān)測服務(wù)的狀態(tài)，并且讀取指定機器 的日志服務(wù)并顯示。不過我認為：STAX在執(zhí)行操作上太過于繁瑣，不用也罷。你可以自己設(shè)計控制界面，來下發(fā)腳本，并且可以讀取日志服務(wù)或者可以獲得 STAF的一個句柄，從而可以接收STAF發(fā)送過來的回應(yīng)，將結(jié)果和執(zhí)行狀態(tài)顯示在界面上。

　　4、總而言之，STAF只是一個請求消息的分發(fā)機制，而那些基于STAF規(guī)則的服務(wù)才是實現(xiàn)整個測試的重點。你需要拓建多大的測試框架，那么你就得找到更多的需求，將其轉(zhuǎn)化為服務(wù)，并且定義好他們之間的請求消息，讓它們很好的協(xié)同合作。

　　總結(jié)：

　　1、一個好的測試工具或者框架，簡單的使用并不難，如果真想在自動化測試領(lǐng)域得到進一步的發(fā)展，那么學(xué)習(xí)這些框架的思想，因為這些框架都是前人在實踐基礎(chǔ)上構(gòu)建出來的，學(xué)習(xí)其思想，不僅能掌握自動化測試的理念，更能在軟件思想上更進一步。

　　2、想當(dāng)時學(xué)習(xí)STAF框架時，實踐很少，對于自動化測試框架一些認識都限于理論，所以學(xué)習(xí)了很長時間，但是在一段時間后，再去學(xué)習(xí)robot框架以及別的框架，都很快的從里到外認識，所以，學(xué)習(xí)很多工具不如先把一個學(xué)通。

版權(quán)聲明：本文出自 散步的SUN 的51Testing軟件測試博客：http://www.51testing.com/?382641

原創(chuàng)作品，轉(zhuǎn)載時請務(wù)必以超鏈接形式標(biāo)明本文原始出處、作者信息和本聲明，否則將追究法律責(zé)任。

　　誰修改了我的密碼？

　　于是開始在網(wǎng)上找：為什么sql server 密碼突然失效？ 查了半天沒找到原因......

　　于是在網(wǎng)上找：如何修改sql server 密碼？發(fā)現(xiàn)大多是在已知舊密碼基礎(chǔ)上再去修改密碼，可是我不知道。

　　繼續(xù)，終于找到解決方法：

　　用windows驗證方式登錄，然后執(zhí)行sql語句：alter login [sa]with password=N'NewPassword' 即可！這里是不需要知道舊密碼的哦！

　　問題是解決啦，可是不能不把元兇找到啊。原來是他......

　　踏破鐵鞋啊！原來是自己造成的！在sqlserver安裝時這些選項沒有注意，才造成今天的后果。

　　在這里，雖然我勾選了強制實施密碼策略，但是我設(shè)置的密碼很簡單依然可以，這是為什么？原來，這個功能要用到NetValidatePasswordPolicy() API這個函數(shù)。（該功能只有在安全要求較高的時候才用，我們是自己做練習(xí)，無需使用啦！）

　　解決方法：在運行里輸入 gpedit.msc 打開 本地策略編輯器依次 展開 計算機配置-Windows設(shè)置-安全設(shè)置-帳戶策略-密碼策略“密碼必須符合復(fù)雜性要求”應(yīng)該是禁用狀態(tài)，改為已啟用，之后再創(chuàng)建SQL Server用戶即可。

　　元兇已經(jīng)找到，希望大家不要被“他”把密碼“修改”掉啊！！！

　　① 子類使用無參構(gòu)造器創(chuàng)建對象：

　　在SonDemo 的main方法中加入創(chuàng)建對象的代碼：

　　我是父類的無參構(gòu)造器

　　我是--子類--的無參構(gòu)造器

　　② 子類使用有參構(gòu)造器創(chuàng)建對象：

　　SonDemo的main方法中加入

　　那么控制臺打印的結(jié)果是：

　　我是父類的無參構(gòu)造器

　　我是子類的有參構(gòu)造器，參數(shù)是than you ma

　　也就是說在子類調(diào)用無參構(gòu)造器創(chuàng)建對象的時候，在執(zhí)行它自己的有參構(gòu)造器之前首先執(zhí)行父類的無參構(gòu)造器。

　　③ 在子類中創(chuàng)建父類的對象，使用無參

　　SonDemo的main方法中加入

　　我是父類的無參構(gòu)造器

　　我是--子類--的無參構(gòu)造器

　　我是父類的無參構(gòu)造器

　　調(diào)用了父類的無參構(gòu)造器，有參的創(chuàng)建對象調(diào)用的是有參構(gòu)造器。

　　總結(jié)：在創(chuàng)建子類對象的時候，首先會調(diào)用父類的構(gòu)造器，讓后在調(diào)用子類相應(yīng)的構(gòu)造器創(chuàng)建對象，在子類創(chuàng)建父類對象時，就是直接調(diào)用父類自己相應(yīng)的構(gòu)造器。

　　答，靜態(tài)塊會在構(gòu)造器之前運行。不管是子類還是父類。創(chuàng)建一個對象的時候，會首先加載它的靜態(tài)塊。

　　① 程序的結(jié)果：

　　因為在創(chuàng)建子類對象之前：會創(chuàng)建父類的一個對象，而靜態(tài)塊會在main之前被加載，所以兩個類的靜態(tài)塊首先執(zhí)行。

　　然后執(zhí)行構(gòu)造器。

　　② 如果在子類中的main中只創(chuàng)建父類的對象結(jié)果是怎么樣的呢？

　　打印結(jié)果：

　　為什么子類的靜態(tài)塊會被加載了？是因為我們是在SonDemo中測試，如果在其他類中測試就不會打印。

　　總結(jié)：我們說了這么多就是重要的一點。靜態(tài)塊會在構(gòu)造器器之前執(zhí)行。

　　當(dāng)啟動一個Java程序時，一個虛擬機實例也就誕生了。當(dāng)該程序關(guān)閉退出，這個虛擬機實例也就隨之消亡。如果在同一臺計算機上同時運行三個Java程序，將得到三個Java虛擬機實例。每個Java程序都運行于它自己的Java虛擬機實例中。

　　Java虛擬機在執(zhí)行Java程序的過程中會把它所管理的內(nèi)存劃分為若干個不同的數(shù)據(jù)區(qū)域。根據(jù)《Java虛擬機規(guī)范（第2版）》的規(guī)定，Java虛擬機所管理的內(nèi)存將會包括以下幾個運行時數(shù)據(jù)區(qū)域，如下圖1所示。

圖1 Java虛擬機的內(nèi)部體系結(jié)構(gòu)

　　下面先對圖中各部分做個簡單的說明：

　 　1、class文件：虛擬機并不關(guān)心Class的來源是什么語言，只要它符合Java class文件格式就可以在Java虛擬機中運行。使用Java編譯器可以把Java代碼編譯為存儲字節(jié)碼的Class文件，使用JRuby等其他語言的 編譯器一樣可以把程序代碼編譯成Class文件。

　　2、類裝載器子系統(tǒng)：負責(zé)查找并裝載Class 文件到內(nèi)存，最終形成可以被虛擬機直接使用的Java類型。

　 　3、方法區(qū)：在類裝載器加載class文件到內(nèi)存的過程中，虛擬機會提取其中的類型信息，并將這些信息存儲到方法區(qū)。方法區(qū)用于存儲已被虛擬機加載的類 信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼等數(shù)據(jù)。由于所有線程都共享方法區(qū)，因此它們對方法區(qū)數(shù)據(jù)的訪問必須被設(shè)計為是線程安全的。

　　4、堆：存儲Java程序創(chuàng)建的類實例。所有線程共享，因此設(shè)計程序時也要考慮到多線程訪問對象（堆數(shù)據(jù)）的同步問題。

　 　5、Java棧：Java棧是線程私有的。每當(dāng)啟動一個新線程時，Java虛擬機都會為它分配一個Java棧。Java棧以幀為單位保存線程的運行狀 態(tài)。虛擬機只會直接對Java棧執(zhí)行兩種操作：以幀為單位的壓棧或出棧。當(dāng)線程調(diào)用java方法時，虛擬機壓入一個新的棧幀到該線程的java棧中。當(dāng)方 法返回時，這個棧幀被從java棧中彈出并拋棄。一個棧幀包含一個java方法的調(diào)用狀態(tài)，它存儲有局部變量表、操作棧、動態(tài)鏈接、方法出口等信息。

　　6、程序計數(shù)器：一個運行中的Java程序，每當(dāng)啟動一個新線程時，都會為這個新線程創(chuàng)建一個自己的PC（程序計數(shù)器）寄存器。程序計數(shù)器的作用可以看做是當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器。字節(jié)碼解釋器工作時 就是通過改變這個計數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令，分支、循環(huán)、跳轉(zhuǎn)、異常處理、線程恢復(fù)等基礎(chǔ)功能都需要依賴這個計數(shù)器來完成。如果線程正 在執(zhí)行的是一個Java方法，這個計數(shù)器記錄的是正在執(zhí)行的虛擬機字節(jié)碼指令的地址；如果正在執(zhí)行的是Natvie方法，這個計數(shù)器值則為空 （Undefined）。

　　7、本地方法棧：本地方法棧與虛擬機棧所發(fā)揮的作用是非常相似的，其區(qū)別不過是虛 擬機棧為虛擬機執(zhí)行Java方法（也就是字節(jié)碼）服務(wù)，而本地方法棧則是為虛擬機使用到的Native方法服務(wù)。任何本地方法接口都會使用某種本地方法 棧。當(dāng)線程調(diào)用Java方法時，虛擬機會創(chuàng)建一個新的棧幀并壓入Java棧。然而當(dāng)它調(diào)用的是本地方法時，虛擬機會保持Java棧不變，不再在線程的 Java棧中壓入新的幀，虛擬機只是簡單地動態(tài)鏈接并直接調(diào)用指定的本地方法。如果某個虛擬機實現(xiàn)的本地方法接口是使用C連接模型的話，那么它的本地方法 棧就是C棧。

　　8、執(zhí)行引擎：負責(zé)執(zhí)行字節(jié)碼。方法的字節(jié)碼是由Java虛擬機的指令序列構(gòu)成的。每一條指令 包含一個單字節(jié)的操作碼，后面跟隨0個或多個操作數(shù)。執(zhí)行引擎執(zhí)行字節(jié)碼時，首先取得一個操作碼，如果操作碼有操作數(shù)，取得它的操作數(shù)。它執(zhí)行操作碼和跟 隨的操作數(shù)規(guī)定的動作，然后再取得下一個操作碼。這個執(zhí)行字節(jié)碼的過程在線程完成前將一直持續(xù)。

　　圖片，文件，二進制數(shù)據(jù)

　　既然數(shù)據(jù)庫支持BLOB類型的數(shù)據(jù)，把文件塞進BLOB字段里一定沒有錯了！？錯，不是這樣的！別的先不提，在很多數(shù)據(jù)庫語言里，處理大字段都不是很容易。

　　把文件存放在數(shù)據(jù)庫里有很多問題：

　　● 對數(shù)據(jù)庫的讀/寫的速度永遠都趕不上文件系統(tǒng)處理的速度

　　● 數(shù)據(jù)庫備份變的巨大，越來越耗時間

　　● 對文件的訪問需要穿越你的應(yīng)用層和數(shù)據(jù)庫層

　　這后兩個是真正的殺手。把圖片縮略圖存到數(shù)據(jù)庫里？很好，那你就不能使用nginx或其它類型的輕量級服務(wù)器來處理它們了。

　　給自己行個方便吧，在數(shù)據(jù)庫里只簡單的存放一個磁盤上你的文件的相對路徑，或者使用S3或CDN之類的服務(wù)。

　　短生命期數(shù)據(jù)

　 　使用情況統(tǒng)計數(shù)據(jù)，測量數(shù)據(jù)，GPS定位數(shù)據(jù)，session數(shù)據(jù)，任何只是短時間內(nèi)對你有用，或經(jīng)常變化的數(shù)據(jù)。如果你發(fā)現(xiàn)自己正在使用定時任務(wù)從某 個表里刪除有效期只有一小時，一天或數(shù)周的數(shù)據(jù)，那說明你沒有找對正確的做事情的方法。使用redis， statsd/graphite， Riak，它們都是干這種事情更合適的工具。這建議也適用于對于收集那些短生命期的數(shù)據(jù)。

　　當(dāng)然，用挖土機在后花園里種土豆也是可行的，但相比起從儲物間里拿出一把鏟子，你預(yù)約一臺挖土機、等它趕到你的園子里挖坑，這顯然更慢。你要選擇合適的工具來處理手頭上的事。

　　日志文件

　　把日志數(shù)據(jù)存放到數(shù)據(jù)庫里，表面上看起來似乎不錯，而且“將來也許我需要對這些數(shù)據(jù)進行復(fù)雜的查詢”，這樣的話很得人心。這樣做并不是一個特別差的做法，但如果你把日志數(shù)據(jù)和你的產(chǎn)品數(shù)據(jù)存放到一個數(shù)據(jù)庫里就非常不好了。

　　也許你的日志記錄做的很保守，每次web請求只產(chǎn)生一條日志。對于整個網(wǎng)站的每個事件來說，這仍然會產(chǎn)生大量的數(shù)據(jù)庫插入操作，爭奪你用戶需要的數(shù)據(jù)庫資源。如果你的日志級別設(shè)置為verbose或debug，那等著看你的數(shù)據(jù)庫著火吧。

　　你應(yīng)該使用一些比如Splunk Loggly或純文本文件來存放你的日志數(shù)據(jù)。這樣去查看它們也許會不方便，但這樣的時候不多，甚至有時候你需要寫出一些代碼來分析出你想要的答案，但總的來說是值得的。

　　可是稍等一下，你是那片不一樣的雪花，你遇到的問題會如此的不同，所以，如果你把上面提到的三種東西中的某一種放到了數(shù)據(jù)庫里也不會有問題。不，你錯了，不，你不特殊。相信我。

　　在理想情況下，我們會測試程序的所有可能執(zhí)行情況，而在大多數(shù)情況下，這幾乎是不可能的。即使一個看起來非常簡單的程序，其可能的輸入與輸出組合可達到數(shù)百種甚至數(shù)千種，對所有的可能情況都設(shè)計測試用例是不切合實際的。對一個復(fù)雜的應(yīng)用程序進行完全的測試，將耗費大量的時間和人力資源，這樣在經(jīng)濟上是不可行的。

　 　另外，要成功地測試一個軟件應(yīng)用程序，測試人員也需要有正確的態(tài)度（也許用“愿景”（vision）這個詞會更好一些）。在某些情況下，測試人員的態(tài)度 可能比實際的測試過程本身還要重要。因此，在深入探討軟件測試的本質(zhì)之前（指技術(shù)層面），我們先探討一下軟件測試的心理學(xué)問題。

　　測試執(zhí)行得差，其中一個主要原因在于大多數(shù)的程序員一開始就把“測試”這個術(shù)語的定義搞錯了。

　　他們可能會認為：

　　“軟件測試就是證明軟件不存在錯誤的過程。”

　　“軟件測試的目的在于證明軟件能夠正確完成其預(yù)定的功能。”

　　“軟件測試就是建立一個‘軟件做了其應(yīng)該做的’信心的過程。”

　　這些定義都是本末倒置的。

　　每當(dāng)測試一個程序時，應(yīng)當(dāng)想到要為程序增加一些價值。通過測試來增加程序的價值，是指測試提高了程序的可靠性或質(zhì)量。提高了程序的可靠性，是指找出并最終修改了程序的錯誤。

　　因此，不要只是為了證明程序能夠正確運行而去測試程序；相反，應(yīng)該一開始就假設(shè)程序中隱藏著錯誤（這種假設(shè)對于幾乎所有的程序都成立），然后測試程序，發(fā)現(xiàn)盡可能多的錯誤。

　　那么，對于測試，更為合適的定義應(yīng)該是：“測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”。

　　雖然這看起來像是個微妙的文字游戲，但確實有重要的區(qū)別。理解軟件測試的真正定義，會對成功地進行軟件測試有很大的影響。

　 　人類行為總是傾向于具有高度目標(biāo)性，確立一個正確的目標(biāo)有著重要的心理學(xué)影響。如果我們的目的是證明程序中不存在錯誤，那就會在潛意識中傾向于實現(xiàn)這個 目標(biāo)；也就是說，我們會傾向于選擇可能較少導(dǎo)致程序失效的測試數(shù)據(jù)。另一方面，如果我們的目標(biāo)在于證明程序中存在錯誤，我們設(shè)計的測試數(shù)據(jù)就有可能更多地 發(fā)現(xiàn)問題。與前一種方法相比，后一種方法會更多地增加程序的價值。

　　這種對軟件測試的定義，包含著無窮的內(nèi)蘊，其中的很多都蘊涵在本書各處。舉例來說，它暗示了軟件測試是一個破壞性的過程，甚至是一個“施虐”的過程，這就說明為什么大多數(shù)人都覺得它困難。這種定義可能是違反我們愿望的；所幸的是，我們大多數(shù)人總是對生活充滿建設(shè)性而不是破壞性的愿景。大多數(shù)人都本能地傾向于創(chuàng)造事物，而不是將事物破壞。這個定義還暗示了對于一個特定的程序，應(yīng)該如何設(shè)計測試用例（測試數(shù)據(jù)）、哪些人應(yīng)該而哪些人又不應(yīng)該執(zhí)行測試。

　 　為增進對軟件測試正確定義的理解，另一條途徑是分析一下對“成功的”和“不成功的”這兩個詞的使用。當(dāng)項目經(jīng)理在歸納測試用例的結(jié)果時，尤其會用到這兩 個詞。大多數(shù)的項目經(jīng)理將沒發(fā)現(xiàn)錯誤的測試用例稱為一次“成功的測試”，而將發(fā)現(xiàn)了某個新錯誤的測試稱為“不成功的測試”。

　　這又是一次 本末倒置。“不成功的”表示事情不遂人意或令人失望。我們認為，如果在測試某段程序時發(fā)現(xiàn)了錯誤，而且這些錯誤是可以修復(fù)的，就將這次合理設(shè)計并得到有效 執(zhí)行的測試稱做是“成功的”。如果本次測試可以最終確定再無其他可查出的錯誤，同樣也被稱做是“成功的”。所謂“不成功的”測試，僅指未能適當(dāng)?shù)貙Τ绦蜻M 行檢查，在大多數(shù)情況下，未能找出錯誤的測試被認為是“不成功的”，這是因為認為軟件中不包含錯誤的觀點基本上是不切實際的。

　　能發(fā)現(xiàn)新錯誤的測試用例不太可能被認為是“不成功的”，也就是說，能發(fā)現(xiàn)錯誤就證明它是值得設(shè)計的。“不成功的”測試用例，會看到程序輸出正確的結(jié)果而沒發(fā)現(xiàn)任何錯誤。

　 　我們可以類比一下病人看醫(yī)生的情況，病人因為身體不舒服而去看醫(yī)生。如果醫(yī)生對病人進行了一些檢查和化驗，卻沒有診斷出任何病因，我們就不會認為這些檢 查和化驗是“成功的”，因為病人支付了昂貴的檢查和化驗費用，而病狀卻依然如故。病人會因此而質(zhì)疑醫(yī)生的診斷能力。但是，如果醫(yī)生診斷出病人是胃潰瘍，那 么這次檢測就是“成功的”，醫(yī)生可以開始進行相應(yīng)的治療。因此，醫(yī)療行業(yè)會使用“成功的”或“不成功的”來表達診斷結(jié)果。我們當(dāng)然可以類推到軟件測試中 來，當(dāng)我們開始測試某個程序時，它就好似我們的病人。

　　“軟件測試就是證明軟件不存在錯誤的過程”，這個定義會帶來第二個問題。對于幾乎所有的程序而言，甚至是非常小的程序，這個目標(biāo)實際上也是無法達到的。

　 　另外，心理學(xué)研究表明，當(dāng)人們開始一項工作時，如果已經(jīng)知道它是不可行的或無法實現(xiàn)時，人的表現(xiàn)就會相當(dāng)糟糕。舉例來說，如果要求人們在15分鐘之內(nèi)完 成星期日《紐約時報》里的縱橫填字游戲，那么我們會觀察到10分鐘之后的進展非常小，因為大多數(shù)人都會卻步于這個現(xiàn)實，即這個任務(wù)似乎是不可能完成的。但 是如果要求在四個小時之內(nèi)完成填字游戲，我們很可能有理由期望在最初10分鐘之內(nèi)的進展會比前一種情況下的大。將軟件測試定義為發(fā)現(xiàn)程序錯誤的過程，使得 測試是個可以完成的任務(wù)，從而克服了這個心理障礙。

　　諸如“軟件測試就是證明‘軟件做了其應(yīng)該做的’的過程”此類的定義所帶來的第三個問 題是，程序即使能夠完成預(yù)定的功能，也仍然可能隱藏錯誤。也就是說，當(dāng)程序沒有實現(xiàn)預(yù)期功能時，錯誤是清晰地顯現(xiàn)出來的；如果程序做了其不應(yīng)該做的，這同 樣是一個錯誤。如果我們將軟件測試視作發(fā)現(xiàn)錯誤的過程，而不是將其視為證明“軟件做了其應(yīng)該做的”的過程，我們發(fā)現(xiàn)后一類錯誤的可能性會大很多。

　 　總結(jié)一下，軟件測試更適宜被視為試圖發(fā)現(xiàn)程序中錯誤（假設(shè)其存在）的破壞性的過程。一個成功的測試用例，通過誘發(fā)程序發(fā)生錯誤，可以在這個方向上促進軟 件質(zhì)量的改進。當(dāng)然，最終我們還是要通過軟件測試來建立某種程度的信心：軟件做了其應(yīng)該做的，未做其不應(yīng)該做的。但是通過對錯誤的不斷研究是實現(xiàn)這個目的 的最佳途徑。

　　有人可能會聲稱“本人的程序完美無缺”（不存在錯誤），針對這種情況建立起信心的最好辦法就是盡量反駁他，即努力發(fā)現(xiàn)不完美之處，而不只是確認程序在某些輸入情況下能夠正確地工作。

　　1）軟件需求變更：軟件需求變更可能導(dǎo)致軟件功能的增加、刪除、修改等變化，應(yīng)遵循需求變更控制管理方法，同樣變更的測試用例也需要執(zhí)行變更管理流程。

　　2）測試需求的遺漏和誤解：由于測試需求分析不到位，可能導(dǎo)致測試需求遺漏或者誤解，相應(yīng)的測試用力也要進行變更。特別是對于軟件隱性需求，在測試需求分析階段容易遺漏，而在測試執(zhí)行過程中被發(fā)現(xiàn)，這時需要補充測試用例。

　　3）測試用例遺漏：在測試過程中，發(fā)現(xiàn)測試用例未覆蓋全部需求，需要補充相應(yīng)的測試用例。

　　4）軟件發(fā)布后，用戶反饋的缺陷：表明測試不全面，存在尚未發(fā)現(xiàn)的缺陷，需要補充或者修改測試用例。

　　對于提供軟件服務(wù)的產(chǎn)品，其多個版本常常共存，而對應(yīng)的測試用例也是共存的，而且測試用例需要專人定期維護，并遵循以下原則：

　　1）及時刪除過時的測試用例

　　需求變更可能導(dǎo)致原有部分測試用例不再適合新的需求要求。例如，刪除了某個功能，那么針對該功能的測試用例也不再需要。所以隨著需求的每一次變更，都要刪除那些不再使用的測試用例。

　　2）及時刪除冗余的測試用例

　　在設(shè)計測試用例時，可能存在兩個或者多個用例測試相同內(nèi)容，降低回歸測試效率，所以要定期整理測試用例集，及時刪除冗余的測試用例。

　　3）增加新的測試用例

　　由于需求變更、用例遺漏或者版本發(fā)布后發(fā)現(xiàn)缺陷等原因，原有的測試用例集沒有完全覆蓋軟件需求，需要增加新的測試用例。

　　4）改進測試用例

　　隨著開發(fā)工作進行，測試用例不斷增加，某些用例隨著系統(tǒng)輸入和當(dāng)前狀態(tài)的變化而變得不再適用，這些用例難以重用，影響回歸測試的效率，需要進行改進，使之可重用可控制。

　　總之，測試用例的維護是一個長期的過程，也是一個不斷改進和完善的過程。