第一章軟件測試與項目分析1.1軟件測試概念1.2軟件測試內(nèi)容1.3軟件測試分類1.4軟件測試流程1.5OA系統(tǒng)分析第一章軟件測試與項目分析1.1軟件測試概念1.2軟件測試內(nèi)1.1軟件測試概念50年代，軟件伴隨著第一臺電子計算機的問世誕生了，以寫軟件為職業(yè)的人也開始出現(xiàn)，他們多是經(jīng)過訓練的數(shù)學家和電子工程師。1960年代美國大學開始出現(xiàn)授予計算機專業(yè)的學位，教人們寫軟件。早期人們在編寫代碼的時候，基本都是自己寫，自己調(diào)試，直到50年代末，測試才與調(diào)試區(qū)分來，但由于受調(diào)試思想的影響，測試一直處于被壓制狀態(tài)，“為了讓我們看到產(chǎn)品在工作，就得將測試工作往后推一點”。直到產(chǎn)品代碼，甚至是項目后期，才開始軟件測試工作。1972年，在美國北卡羅來納大學舉行了首屆軟件測試正式會議。1979年，GlenfordMyers的《軟件測試藝術》（TheArtofSoftwareTesting）中作出了當時最好的軟件測試定義：“測試是為發(fā)現(xiàn)錯誤而執(zhí)行的一個程序或者系統(tǒng)的過程?！敝链?，軟件測試在正式登上歷史的舞臺，軟件測試是軟件生產(chǎn)流程中質(zhì)量保證的重要手段。測試，檢測、試驗，利用一定的手段，檢測被測對象特性表現(xiàn)是否與預期需求一致。對于軟件而言，測試是通過人工或者自動的檢測方式，檢測被測對象是否滿足用戶要求或弄清楚預期結果與實際結果之間的差異，是為了發(fā)現(xiàn)錯誤而審查軟件文檔、檢查軟件數(shù)據(jù)和執(zhí)行程序代碼的過程。軟件測試是質(zhì)量檢測過程，包含了若干個測試活動。（引自《軟件測試技術基礎教程》）1.1軟件測試概念50年代，軟件伴隨著第一臺電子計算機的問世1.1軟件測試概念早些時候，很多人對軟件測試的認識僅限于運行軟件執(zhí)行測試，實際上軟件測試還包括靜態(tài)測試和驗證活動。軟件包括實現(xiàn)用戶需求的源代碼、描述軟件功能及性能表現(xiàn)的說明書，支撐軟件運行的配置數(shù)據(jù)，軟件測試對象同樣包括了文檔及配置數(shù)據(jù)的測試，不僅僅是執(zhí)行軟件。軟件測試工程師職責定義的軟件測試是指軟件產(chǎn)品生存周期內(nèi)所有的檢查、評審和確認活動。如設計評審、文檔審查、需求測試、單元測試、集成測試、系統(tǒng)測試、驗收測試等等檢查活動。軟件測試活動是對軟件產(chǎn)品質(zhì)量的檢驗和評價的過程。一方面檢查、揭露軟件產(chǎn)品質(zhì)量中存在的質(zhì)量問題，另一方面又需對產(chǎn)品質(zhì)量進行客觀的評價并提出改進意見。軟件測試使用人工或自動化手段對被測對象進行確認驗證活動，從而找出被測對象與最終用戶需求之間的差別。在通常的軟件生產(chǎn)活動中，軟件測試貫穿于整個軟件的生命周期，從初期的項目需求調(diào)研到后期的產(chǎn)品維護，每個階段都離不開檢查、評審與確認活動?；诓煌慕嵌?，軟件測試的目的是不一樣的。從用戶角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產(chǎn)品。而從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證被測軟件已正確地實現(xiàn)了用戶的需求，確立人們對軟件質(zhì)量的信心。1.1軟件測試概念早些時候，很多人對軟件測試的認識僅限于運行1.2軟件測試內(nèi)容軟件測試定義是為了發(fā)現(xiàn)錯誤而審查軟件文檔、檢查軟件數(shù)據(jù)和執(zhí)行程序代碼的過程。從該定義可以看出，軟件測試對象并不僅僅是程序源代碼，還包括與之相對應的文檔及配置數(shù)據(jù)，在軟件生產(chǎn)活動中，一般都有哪些文檔呢？配置數(shù)據(jù)又都有哪些？通常情況下，軟件項目開展過程中，會有可行性報告、項目立項申請報告、項目進度安排計劃、需求規(guī)格說明書、開發(fā)進度計劃、測試計劃、概要設計文檔、詳細設計文檔、數(shù)據(jù)庫設計文檔、數(shù)據(jù)字典、源碼清單、測試用例等等，配置數(shù)據(jù)主要包括系統(tǒng)運行所必須的基礎數(shù)據(jù)，比如建庫sql語句、建表sql語句、存儲過程、數(shù)據(jù)庫連接配置文件、系統(tǒng)初始驅(qū)動程序等等。在上面眾多的文檔與配置數(shù)據(jù)中，測試工程師需要對這些資料進行檢查、評審與確認。1.2軟件測試內(nèi)容軟件測試定義是為了發(fā)現(xiàn)錯誤而審查軟件文檔、1.2軟件測試內(nèi)容軟件測試核心工作是實施軟件系統(tǒng)功能、性能、文檔、配置數(shù)據(jù)等方面的測試活動，除此之外，還有可能有需求調(diào)研、用戶手冊編寫等等工作。日常測試工作中，測試工程師經(jīng)常利用測試用例執(zhí)行被測軟件，利用預期結果與軟件的實際結果進行比較，從而找出被測系統(tǒng)中與最終用戶需求不一致的地方，也就是通常意義上的Bug。經(jīng)過一輪又一輪的版本迭代測試，使被測軟件達到預期質(zhì)量要求。以成都沖和科技有限公司OA項目（以下簡稱OA系統(tǒng)）為例，測試工程師以OA系統(tǒng)的需求規(guī)格說明書，從功能、性能、GUI等質(zhì)量特性提取測試項及子項，設計測試用例。當測試版本提交后，則可進行測試用例的執(zhí)行，發(fā)現(xiàn)并管理缺陷，并根據(jù)缺陷編寫系統(tǒng)測試報告，當測試工作完成后可根據(jù)項目經(jīng)理要求，編寫系統(tǒng)的用戶手冊等。1.2軟件測試內(nèi)容軟件測試核心工作是實施軟件系統(tǒng)功能、性能、1.3軟件測試分類從測試方法來看，軟件測試可分為黑盒測試、白盒測試、灰盒測試、靜態(tài)測試、動態(tài)測試、手工測試、自動化測試等幾個方面，從測試階段來分，可分為需求測試、單元測試、集成測試、系統(tǒng)測試、驗收測試等幾個階段。1.3軟件測試分類從測試方法來看，軟件測試可分為黑盒測試、白1.3軟件測試分類1.3.1按測試方法劃分與軟件開發(fā)有若干框架一樣，軟件測試同樣可以采用多種方法，利用不同的方法可以得到不同的效果，并且最終保證被測對象符合預期的用戶需求。按照測試方法分，主要有以下幾種：1.3軟件測試分類1.3.1按測試方法劃分1.3軟件測試分類黑盒測試黑盒測試又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于需求規(guī)格的功能測試，通過測試活動來檢查被測對象每個功能能否正常使用，是否滿足用戶需求。黑盒測試方法能更好更真實的從用戶角度來檢查被測對象界面、功能等方面需求實現(xiàn)情況，但黑盒測試基于用戶需求進行，會帶來隱患。黑盒測試方法難以發(fā)現(xiàn)一些隱藏在程序內(nèi)部的缺陷，如內(nèi)存泄漏等。以OA系統(tǒng)為例，如果從用戶需求角度考慮，對圖書管理、資產(chǎn)管理或車輛管理等模塊，實施功能或性能測試，此處的方法即為黑盒測試。黑盒測試工作目前是軟件測試方法核心方法，在企業(yè)測試過程中，大多數(shù)采用黑盒測試方法，讀者在學習過程中需重點學習此測試方法，再輔以后續(xù)的測試方法，方能把握工作核心，關鍵點。1.3軟件測試分類黑盒測試1.3軟件測試分類白盒測試白盒測試又稱結構測試、邏輯驅(qū)動測試或基于程序代碼內(nèi)部構成的測試。此時，測試工程師需深入考查程序代碼的內(nèi)部結構、邏輯設計等。白盒測試需要測試工程師具備很深的軟件開發(fā)功底，精通相應的開發(fā)語言，初級測試工程師難以勝任該工作。白盒測試方法主要包括代碼檢查法、靜態(tài)結構分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測試法，其中最為常用的方法是代碼檢查法。代碼檢查包括桌面檢查、代碼審查和走查等，主要檢查代碼和設計一致性，代碼對標準的遵循、可讀性，代碼邏輯表達的正確性，代碼結構合理性等方面；發(fā)現(xiàn)違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內(nèi)容。一般公司都有比較成熟的編程規(guī)范，代碼檢查時，可以根據(jù)編程規(guī)范進行檢查。1.3軟件測試分類白盒測試1.3軟件測試分類以OA系統(tǒng)車輛管理添加車輛功能為例，如果對以下代碼

functionfindObj(theObj,theDoc)

{

varp,i,foundObj;

if(!theDoc)theDoc=document;

if((p=theObj.indexOf("?"))>0&&parent.frames.length)

{

theDoc=parent.frames[theObj.substring(p+1)].document;

theObj=theObj.substring(0,p);

}1.3軟件測試分類以OA系統(tǒng)車輛管理添加車輛功能為例，如果對1.3軟件測試分類

if(!(foundObj=theDoc[theObj])&&theDoc.all)foundObj=theDoc.all[theObj];for(i=0;!foundObj&&i<theDoc.forms.length;i++)foundObj=theDoc.forms[i][theObj];for(i=0;!foundObj&&theDoc.layers&&i<theDoc.layers.length;i++)foundObj=findObj(theObj,theDoc.layers[i].document);if(!foundObj&&document.getElementById)foundObj=document.getElementById(theObj);returnfoundObj;}1.3軟件測試分類if(!(foundObj=thvarGetDate="";functionSelectDate(ObjName,FormatDate){ varPostAtt=newArray; PostAtt[0]=FormatDate; PostAtt[1]=findObj(ObjName); GetDate=showModalDialog("../util/calendar/calendar.htm",PostAtt,"dialogWidth:286px;dialogHeight:221px;status:no;help:no;");}functionSetDate(){ findObj(ObjName).value=GetDate;}進行測試，驗證findObj、SetDate等函數(shù)的功能，此類方法即為白盒測試方法。varGetDate="";1.3軟件測試分類灰盒測試與前面的黑盒測試、白盒測試相比，灰盒測試介于兩者之間。黑盒測試僅關注程序代碼的功能性表現(xiàn)，不關注其內(nèi)部邏輯設計、構成情況，白盒測試則僅從程序代碼的內(nèi)部構成考慮，檢查其內(nèi)部代碼設計結構，方法調(diào)用等，灰盒測試則綜合了黑盒測試與白盒測試，一方面考慮程序代碼的功能性表現(xiàn)，另一方面，又需要考慮程序代碼的內(nèi)部結構。同樣，以OA系統(tǒng)為例，如果在測試過程中，既考慮車輛管理用戶需求方面的特性，如能否添加車輛，編輯車輛信息等，又從該功能的實現(xiàn)邏輯代碼考慮，則此方法即為灰盒測試。1.3軟件測試分類灰盒測試1.3軟件測試分類靜態(tài)測試靜態(tài)測試，顧名思義，靜態(tài)的、不執(zhí)行被測對象程序代碼尋找缺陷的過程。通過閱讀程序代碼、文檔資料等，與需求規(guī)格說明書進行比較，找出程序代碼中設計不合理以及文檔資料有錯誤的地方。在實際研發(fā)活動中可開展同行評審活動，通過評審方式，找出文檔資料、程序代碼中存在的缺陷并加以修改。以OA系統(tǒng)為例，如果針對該系統(tǒng)的設計文檔，如概要設計文檔，或系統(tǒng)源代碼進行走讀查閱，則使用的是靜態(tài)測試方法。1.3軟件測試分類靜態(tài)測試1.3軟件測試分類動態(tài)測試動態(tài)測試即為執(zhí)行被測對象程序代碼，執(zhí)行測試用例，檢查程序運行實際結果與測試用例預期結果之間是否存在差異，判定實際結果與預期結果是否一致，從而檢驗程序的正確性、可靠性和有效性，并分析系統(tǒng)運行效率和健壯性等性能狀況。動態(tài)測試由四部分組成：設計測試用例、執(zhí)行測試用例、分析比較輸出結果、輸出測試報告。動態(tài)測試有三種主要的方法：黑盒測試、白盒測試以及灰盒測試。以OA系統(tǒng)為例，搭建測試環(huán)境運行系統(tǒng)對其進行功能的驗證測試，即為使用動態(tài)測試方法。1.3軟件測試分類動態(tài)測試1.3軟件測試分類手工測試未真正接觸軟件測試之前，很多人都認為，軟件測試工作就是執(zhí)行一些鼠標點擊的動作來查找缺陷。的確，在手動測試階段，大部分的測試工作就是模擬用戶的業(yè)務流程，使用軟件產(chǎn)品，與用戶需求規(guī)格進行比較，從而發(fā)現(xiàn)軟件系統(tǒng)中的缺陷。手動測試是最傳統(tǒng)的測試方法，也是目前大多數(shù)公司都在使用的測試形式。測試工程師設計測試用例并執(zhí)行測試用例，根據(jù)實際結果與預期結果相比，記錄測試結果，最終輸出測試報告。手工測試，可以充分發(fā)揮測試工程師的主觀能動性，將其智力活動體現(xiàn)于測試工作中，能發(fā)現(xiàn)很多的缺陷，但手工測試方法又有一定的局限性，并且長期下去會令人覺得枯燥單調(diào)。1.3軟件測試分類手工測試1.3軟件測試分類自動化測試

軟件行業(yè)不斷發(fā)展，軟件測試技術也在不斷地更新，出現(xiàn)了眾多的自動化測試工具，如HP的QucikTestProfessional、LoadRunner，IBMRPT、RFT等等。自動化測試是利用一些測試工具，錄制業(yè)務使用流程，讓工具自動運行測試過程查找缺陷，也可以編寫腳本代碼，設定特定的測試場景，自動尋找缺陷。自動化測試的引入，大大提高了測試的效率和測試的準確性，而且寫出結構性較好的測試腳本，還可以在軟件生命周期的各個階段重復使用。1.3軟件測試分類自動化測試1.3軟件測試分類前面概要闡述了按測試方法劃分的軟件測試類型，下面以測試階段對測試類型進行劃分，主要有需求測試、單元測試、集成測試、系統(tǒng)測試、用戶測試、回歸測試等。需求測試需求調(diào)研完成后，測試部門或者需求小組進行需求測試，從需求文檔規(guī)范性、正確性等方面檢查需求調(diào)研階段生成的需求文檔，測試工程師最好是有經(jīng)驗的需求分析人員，并且得到了需求調(diào)研期間形成的DEMO。在許多失敗的項目中，70%～85%的返工是由于需求方面的錯誤所導致的，并且因為需求的緣故而導致大量的返工，造成進度延遲、缺陷的發(fā)散，甚至項目的失敗，這是一件極其痛苦的事情，所以，在有條件開展需求測試的時候，一定要實施需求測試。單元測試單元測試又稱為模塊測試，顧名思義，就是對程序代碼中最小的設計模塊單元進行測試。單元測試是在軟件開發(fā)過程中進行的最低級別的測試活動。在單元測試活動中，我們主要采用靜態(tài)測試與動態(tài)測試相結合的辦法。首先采用靜態(tài)的代碼走查，檢查程序代碼中不符合編程規(guī)范，存在錯誤或者遺漏的地方，同時使用代碼審查的方法，項目小組檢查項目代碼，以期發(fā)現(xiàn)更多的問題，然后再使用單元測試工具，比如JUnit等工具進行程序代碼內(nèi)邏輯結構、函數(shù)調(diào)用等方面進行測試。據(jù)業(yè)界統(tǒng)計，單元測試一般可以發(fā)現(xiàn)大約80%的軟件缺陷。1.3.2按測試階段劃分1.3軟件測試分類前面概要闡述了按測試方法劃分的軟件測試類型1.3軟件測試分類集成測試集成測試，又稱為組裝測試，就是將軟件產(chǎn)品中各個模塊集成組裝起來，檢查其接口是否存在問題，以及組裝后的整體功能、性能表現(xiàn)。在開展集成測試之前，我們需進行深入的單元測試（當然，實際工作中大多公司不會做單元測試，僅有程序員各自檢查自己的代碼）。從個體來講，可能解決了很多的缺陷，但所有的個體組合起來，就可能出現(xiàn)各種各樣的問題。1+1<2的問題，此刻尤為突出。集成測試一般可采用非增式集成方法、增式集成方法（自底向上集成、自頂向下集成、組合方式集成）等策略進行測試，利用以黑盒測試為主、白盒測試為輔的測試方法進行測試。集成測試工程師一般由測試工程師擔當，開發(fā)工程師將經(jīng)過單元測試的代碼集成后合成一個新的軟件測試版本，交由配置管理員，然后測試組長從配置管理員處提取集成好的測試版本進行測試。集成測試階段主要解決的是各個軟件組成單元代碼是否符合開發(fā)規(guī)范、接口是否存在問題、整體功能有無錯誤、界面是否符合設計規(guī)范、性能是否滿足用戶需求等問題。1.3軟件測試分類集成測試1.3軟件測試分類系統(tǒng)測試系統(tǒng)測試，是將通過集成測試的軟件，部署到某種較為復雜的計算機用戶環(huán)境進行測試，這里所說的復雜的計算機用戶環(huán)境，其實就是我們一般用戶的計算機環(huán)境。系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。這個階段主要進行的是安裝與卸載測試、兼容性測試、功能確認測試、安全性測試等等。系統(tǒng)測試階段采用黑盒測試方法，主要考查被測軟件的功能與性能表現(xiàn)。如果軟件可以按照用戶合理地期望的方式來工作的時候，即可認為通過系統(tǒng)測試。系統(tǒng)測試過程其實也是一種配置檢查過程，檢查在軟件生產(chǎn)過程中是否有遺漏的地方，在系統(tǒng)測試過程中做到查漏補缺，以確保交付的產(chǎn)品符合用戶質(zhì)量要求。1.3軟件測試分類系統(tǒng)測試1.3軟件測試分類用戶測試在系統(tǒng)測試完成后，將會進行用戶測試。這里的用戶測試，其實可以稱為用戶確認測試。在正式驗收前，需要用戶對本系統(tǒng)做出一個評價，用戶可對交付的系統(tǒng)做測試，并將測試結果反饋回來，進行修改、分析。面向應用的項目，在交付用戶正是使用之前要經(jīng)過一定時間的用戶測試?；貧w測試回歸測試一般發(fā)生的情況在發(fā)現(xiàn)缺陷后，重新執(zhí)行測試用例的過程。回歸測試階段主要的目的是檢查以前的測試用例能否再次通過，是否還有需要補充的用例等等。有些公司會采用自動化測試工具來進行回歸測試，比如利用QTP，對于產(chǎn)品級，變動量小的軟件而言，我們可以利用這樣的工具去執(zhí)行測試。但一般情況下，都由測試工程師手動的執(zhí)行以前的測試用例，來檢查用例通過情況?；貧w測試可以發(fā)現(xiàn)在產(chǎn)品發(fā)布前未能發(fā)現(xiàn)的問題，比如時鐘的延遲、軟件的性能問題等等。1.3軟件測試分類用戶測試1.4軟件測試流程在學習了軟件測試的基本概念后，我們接著聊聊一般公司里軟件測試的流程。以OA系統(tǒng)為例，一般公司的軟件測試工作流程如圖1-1所示。圖1-1軟件測試工作流程圖1.4軟件測試流程在學習了軟件測試的基本概念后，我們接著聊聊1.4軟件測試流程1.4.1成立測試組當需測試的項目分配下來后，該項目的負責人向測試部門提出測試申請，通過測試經(jīng)理的審批后，由測試經(jīng)理指派測試組長與測試工程師，成立項目測試組，負責該項目的測試工作。根據(jù)項目團隊的組織流程，OA系統(tǒng)的負責人張三向測試部門經(jīng)理李四申請實施測試活動，此時，李四接受測試任務后，制定王五、趙六、田七為測試工程師，負責OA系統(tǒng)的實際測試活動。1.4軟件測試流程1.4.1成立測試組1.4軟件測試流程1.4.2分析測試需求測試經(jīng)理任命測試組長，測試組長需提前熟悉被測對象的需求，從總體上掌握項目的進展情況。通過仔細的閱讀項目的相關文檔（比如項目的進度計劃、測試要求等）后，測試組長需安排下一步工作。1.4軟件測試流程1.4.2分析測試需求1.4軟件測試流程1.4.3制定測試計劃測試組長在詳細了解項目信息后，根據(jù)項目需求、項目進度計劃表制定當前項目的測試計劃，并以此測試計劃來指導測試組開展對應的測試工作。測試計劃中需說明每個測試工件輸出的時間點、測試資源、測試方法、測試風險規(guī)避、測試停測標準等。1.4軟件測試流程1.4.3制定測試計劃1.4軟件測試流程1.4.4提取測試需求測試組長制定好了測試計劃后，項目組進行評審。評審通過后，項目測試組即可按照此測試計劃開展工作。測試組員根據(jù)測試組長的任務分配，進行項目用戶需求規(guī)格說明書的閱讀，甚至開展需求測試工作。需求閱讀理解完成后，進行測試需求的提取，也就是列出被測對象需測試的點，這項工作可以利用TestDiector等測試管理工具開展。1.4軟件測試流程1.4.4提取測試需求1.4軟件測試流程1.4.5編寫測試用例測試需求提取完畢，經(jīng)過測試組的評審通過后，測試組員可以進行測試用例的設計，這些工作都是在測試計劃中規(guī)定的時間內(nèi)完成。比如測試計劃中規(guī)定“2008-12-20至2008-12-30完成系統(tǒng)測試用例設計及評審”，那么就必須在這個時間段內(nèi)完成被測對象的測試用例設計。測試用例的設計一般使用Word、Excel等樣式，也可使用TestDirector、TestLink等工具進行管理。測試用例設計工作在某些企業(yè)中因項目周期及要求不同，可能不開展，直接進行測試活動。1.4軟件測試流程1.4.5編寫測試用例1.4軟件測試流程1.4.6搭建測試環(huán)境測試用例設計工作完成后，如果項目開發(fā)組告知測試組長可以開展測試的時候，測試組長可從配置管理員處提取測試版本，根據(jù)開發(fā)組提供的被測對象測試環(huán)境搭建單進行測試環(huán)境的搭建。測試環(huán)境搭建需要測試工程師掌握基本的硬件、軟件知識。隨著用戶需求的不斷加大，復雜化，項目運行環(huán)境往往非常復雜，并且搭建成本極高，以大型網(wǎng)站系統(tǒng)架構為例，如圖1-2所示。1.4軟件測試流程1.4.6搭建測試環(huán)境1.4軟件測試流程圖1-2大型web系統(tǒng)架構1.4軟件測試流程1.4軟件測試流程從用戶角度來看，該服務器的架構非常復雜，從測試人員角度來看，同樣站在用戶角度，亦不需要掌握其等復雜架構，測試環(huán)境一般都由開發(fā)人員搭建，所以該環(huán)節(jié)的工作測試人員不一定實施。1.4軟件測試流程從用戶角度來看，該服務器的架構非常復雜，從1.4軟件測試流程1.4.7執(zhí)行測試用例測試環(huán)境搭建完成后，測試組員將進行測試用例的執(zhí)行。根據(jù)前期設計并評審通過的測試用例，測試組員進行各個功能模塊的測試。在執(zhí)行測試用例的過程中，如果發(fā)現(xiàn)有遺漏或者不完善的測試用例，需及時做更新，并用文檔記錄變更歷史。用例執(zhí)行過程中如果發(fā)現(xiàn)了Bug，則需按照部門或者項目組的Bug提交規(guī)范，利用一些Bug管理工具提交Bug。常用的Bug管理工具有Bugzilla、TestTrack、Mantis、TestDirector等。1.4軟件測試流程1.4.7執(zhí)行測試用例1.4軟件測試流程1.4.8跟蹤處理缺陷大多數(shù)公司都有自己的Bug管理流程規(guī)范，項目組成員需根據(jù)這個流程規(guī)范開展日常的Bug處理工作。在缺陷處理階段，大多要經(jīng)過4次、甚至更多的迭代過程，多次進行回歸測試，直到在規(guī)定的時間內(nèi)達到測試計劃中所定義的停測標準為止。在這個階段，主要使用黑盒測試方法開展工作，以被測對象的需求規(guī)格說明為依據(jù)，重點關注被測對象的界面與功能表現(xiàn)。1.4軟件測試流程1.4.8跟蹤處理缺陷1.4軟件測試流程1.4.9執(zhí)行性能測試一般在功能測試完成后，我們還需開展相應的性能測試工作。與功能測試一樣，在測試之前，需要進行測試需求的分析，性能指標提取、用例設計、腳本錄制、優(yōu)化、執(zhí)行、分析等等一系列過程。通過使用一些自動化工具進行性能測試是目前性能測試的主要手段，常用的性能測試工具有WAS、QALoad、WebLoad、LoadRunner、Robot等。性能測試階段主要解決被測對象的性能問題。目前大部分項目軟件在執(zhí)行功能測試后，可能不進行性能測試，所以本過程在實際項目測試時不一定實施，但面向大眾或涉及多用戶多并發(fā)的業(yè)務系統(tǒng)，一定會開展性能測試活動。1.4軟件測試流程1.4.9執(zhí)行性能測試1.4軟件測試流程1.4.10輸出測試報告功能測試、性能測試都完成后，測試組長需要對被測對象做一個全面的總結，以數(shù)據(jù)為依據(jù)，衡量被測對象的質(zhì)量狀況，并提交測試結果報告給項目組，從而幫助項目經(jīng)理、開發(fā)組及其他部門了解被測對象的質(zhì)量情況，以決定下一步的工作計劃。功能測試報告主要包含被測對象的缺陷修復率、Bug狀態(tài)統(tǒng)計、Bug分布等，性能測試報告主要包含測試指標的達標情況及測試部的質(zhì)量評價等。當然，也可以出一份整體的測試報告，包含功能、性能的測試結果。綜上所述，測試需求分析、測試計劃制定、執(zhí)行測試、跟蹤處理缺陷、編寫測試報告等測試活動，在任何項目中都會實施，而測試用例設計、測試環(huán)境搭建、性能測試等活動則可能根據(jù)項目需求不一樣不一定實施。1.4軟件測試流程1.4.10輸出測試報告1.5OA系統(tǒng)分析通過上面幾部分的介紹，我們已經(jīng)了解了軟件測試的基本概念，軟件測試工作的常用流程等。從本節(jié)起，我們正式進入本書的實戰(zhàn)部分，以實際的項目實例介紹軟件測試工作?，F(xiàn)在軟件行業(yè)中有很多業(yè)務類型，大多數(shù)公司招聘時都需要測試工程師具備豐富的項目經(jīng)驗，那么這些項目經(jīng)驗怎么來呢？這里介紹一個常用的方法。對于軟件測試初學者，一個比較好的方法是利用網(wǎng)絡下載一些程序源代碼，根據(jù)這些資料中配備的環(huán)境配置說明，自己練習部署、源代碼閱讀、業(yè)務理解等，如果在環(huán)境配置、程序應用過程中出現(xiàn)問題的話，我們可以通過網(wǎng)絡查找相關的解決辦法。一方面，自己動手練習環(huán)境的部署，提高代碼閱讀能力及動手能力；另一方面，可以接觸各種各樣的業(yè)務系統(tǒng)，因為一般的源代碼網(wǎng)站都會將代碼進行分類，業(yè)務類型還是比較豐富的，這些源代碼都是工作中各種業(yè)務的縮影?，F(xiàn)在常用的軟件大概分為七大類：系統(tǒng)軟件、應用軟件、工程科學計算軟件、嵌入式軟件、產(chǎn)品軟件、Web應用軟件和人工智能軟件。這些分類實際上按照業(yè)務類型來分，在實際的工作中都有可能接觸到，所以，我們應該通過多種方法，多個途徑來豐富自己的業(yè)務知識。1.5OA系統(tǒng)分析通過上面幾部分的介紹，我們已經(jīng)了解了軟件1.5OA系統(tǒng)分析OA是什么意思呢？OA（OfficeAutomation）辦公自動化是將現(xiàn)代化辦公和計算機網(wǎng)絡功能結合起來的一種新型的辦公方式，是當前新技術革命中一個非?；钴S和具有很強生命力的技術應用領域，是信息化社會的產(chǎn)物。辦公自動化的原動力是人類文明進步和發(fā)展的同時人類求得自身解放的需要，OA系統(tǒng)的出現(xiàn)和發(fā)展也正是來源于這種需要的牽引。傳統(tǒng)的辦公方式極大地束縛了人的創(chuàng)造力和想象力，埋沒了人的智慧和潛能，使人們耗費了大量的時間和精力去手工處理那些繁雜、重復的工作。手工處理的延時和差錯，正是現(xiàn)代化管理中應該去除的弊端。用先進的、現(xiàn)代化的工具代替手工作業(yè)，無疑是生產(chǎn)力發(fā)展的方向。OA系統(tǒng)對傳統(tǒng)辦公方式的變革，正是適應了人們的普遍需求，也順應了技術發(fā)展的潮流，自然成為業(yè)界追求的目標。1.5OA系統(tǒng)分析OA是什么意思呢？1.5OA系統(tǒng)分析OA系統(tǒng)建設的本質(zhì)是提高決策效能為目的的。通過實現(xiàn)辦公自動化，或者說實現(xiàn)數(shù)字化辦公，可以優(yōu)化現(xiàn)有的管理組織結構，調(diào)整管理體制，在提高效率的基礎上，增加協(xié)同辦公能力，強化決策的一致性，最后實現(xiàn)提高決策效能的目的。OA系統(tǒng)的基礎是對管理的理解和對信息的積累。技術只是辦公自動化的技術實現(xiàn)手段。只有將辦公過程中生成的信息進行有序化積累，沉淀，才能真正發(fā)揮辦公自動化的作用。OA系統(tǒng)的靈魂是軟件，硬件只是實現(xiàn)辦公自動化的環(huán)境保障。數(shù)字化辦公的兩個明顯特征是授權和開放，通過授權確保信息的安全和分層使用，使得數(shù)字化辦公系統(tǒng)有可以啟用的前提，通過開放，使得信息共享成為現(xiàn)實。（引自網(wǎng)絡）1.5OA系統(tǒng)分析OA系統(tǒng)建設的本質(zhì)是提高決策效能為目的的1.5OA系統(tǒng)分析OA系統(tǒng)現(xiàn)在非常流行。前些年，比如2002年左右，很多公司開始提倡無紙化辦公，使得OA系統(tǒng)得到了蓬勃發(fā)展。記得當時我所在的公司使用DominoLotus開發(fā)了一套OA系統(tǒng)，功能非常齊全，但價格也比較貴?，F(xiàn)在的OA系統(tǒng)所使用的開發(fā)語言已經(jīng)很廣泛了，有php、jsp、asp等等。萬變不離其宗，僅管采用了眾多的實現(xiàn)方式，但其核心思想不變，我們只要理解這種業(yè)務類型，通過這種業(yè)務類型，掌握通用的功能測試與性能測試方法即可。書中引用的OA系統(tǒng)是一種典型的OA業(yè)務系統(tǒng)，采用JSP開發(fā)，基于B/S結構，整個系統(tǒng)共有通知、工作流、文件柜、任務督辦、工作計劃、工作記事、考勤、網(wǎng)絡硬盤、通訊錄、設置代理、短消息、郵箱、社區(qū)、博客、聊天室、圖書管理、辦公用品管理、資產(chǎn)管理、車輛管理、會議管理、郵編區(qū)號萬年歷、檔案管理、客戶管理、銷售管理、供應商管理、系統(tǒng)管理等模塊。1.5OA系統(tǒng)分析OA系統(tǒng)現(xiàn)在非常流行。前些年，比如2001.5OA系統(tǒng)分析各個功能簡介如表1-1中所列：表1-1OA系統(tǒng)功能模塊說明模塊名稱 功能簡介行政管理公共通知 發(fā)布公共通知，利用電子文件柜中的插件，可以很方便地發(fā)送通過，相關人員將會收到短消息提醒，并且還可以發(fā)布部門通知，部門通知僅相關部門人員可見。工作流 通過可視化流程設計器，定義各種各樣的流程。流轉(zhuǎn)時可以指定角色也可以指定相關人員，支持串簽、會簽、異或發(fā)散、異或聚合、條件節(jié)點、節(jié)點上多個人員同時處理、人員安排策略等，能夠自動按組織機構、角色、職位根據(jù)行文的方向自動匹配人員，并且具備強大的流程查詢功能。智能表單設計 通過表單智能設計器，能夠在原來WORD文檔基礎上創(chuàng)建表單，支持常用的輸入框、下拉菜單、日期控件，支持嵌套表格，還支持宏控件，如：用戶選擇、部門選擇、意見框、簽名框、圖像控件、手寫板等。在設計流程的時候，能夠指定相關人員對表單控件的修改權限，沒有權限的人員將不可以修改輸入框的內(nèi)容。電子文件柜 文檔管理系統(tǒng)是用戶對各種文檔進行管理的工具，并在此基礎上可以建立個人文檔庫,針對個人文檔庫和公用文檔庫，提供對文檔的建立、修改、刪除及歸類存儲等管理功能，可以使用多種文件格式，并可設置讀者權限來共享。電子文件柜中采用了功能強大的WebEdit控件，可以很方便地采集遠程圖片、Flash等，實現(xiàn)所見即所得編輯。1.5OA系統(tǒng)分析各個功能簡介如表1-1中所列：1.5OA系統(tǒng)分析工作計劃 工作計劃是為了加強工作的計劃性，提高工作效率，日常工作必須做到有計劃的合理安排。工作計劃中可以指定參與部門、人員、負責人等，并且可以實現(xiàn)計劃的調(diào)度，如周計劃、月計劃等，可以定時提醒參與人員，工作計劃帶有進度，用戶可以添加工作計劃的回復，回復可以帶附件。任務督辦 以樹形的方式對任務進行組織、發(fā)起者可以把任務交辦給某幾個人員、承辦者可回復任務或者繼續(xù)交辦、任務的發(fā)起者可以催辦、改變?nèi)蝿盏臓顟B(tài)、任務層層布置下去，最終形成一棵任務樹，樹上各個節(jié)點的人員只能看到有權看到的節(jié)點。考勤管理 實現(xiàn)網(wǎng)上簽到，可進行考勤信息的記錄，可定義每天的上下班時間。工作記事 記錄每天的工作，記錄只能在當天修改。便于工作的回顧和總結，上級領導可以調(diào)閱查看相關人員工作情況。組織機構 單位名錄將以樹狀的機構宏觀上將組織的機構管理起來，使用戶能夠輕松查詢組織的機構圖以及機構內(nèi)部的基本人員信息，將組織信息一目了然地顯示在用戶的面前。1.5OA系統(tǒng)分析工作計劃 工作計劃是為了加強工作的計劃性1.5OA系統(tǒng)分析個人助理我的文檔

提供個人文件柜功能，短消息可以轉(zhuǎn)存至我的文檔通訊錄

對通訊名單進行分組管理、查詢、可以導入、導出Outlook格式的通訊錄。消息中心

可以收發(fā)短消息，短消息可以加附件，有權限的用戶可以進行短消息的群發(fā)。工作代理

員工外出時可以設置工作的代理人，所有事務可以自動轉(zhuǎn)發(fā)給工作代理人，員工回來后可以查看所有授權的事務處理過程。日程管理

日程管理可以用于個人時間管理?？梢赃M行約會、會議安排?？梢酝ㄟ^臺歷式的圖形界面，輕松地查看安排好的各種約會?？刂泼姘?/p>

修改個人信息、設置消息提示的參數(shù)、管理論壇中的個人用戶信息、定制桌面，可將文件柜中的目錄和文件、待辦流程、任務督辦、日程安排、論壇新貼、博客新貼等根據(jù)個人的需要定制至桌面。電子郵件

電子郵件是辦公自動化系統(tǒng)中最基本的功能，通過電子郵件系統(tǒng)可以方便地起草、發(fā)送郵件、瀏覽接收到的郵件并歸類存檔，可以實現(xiàn)各類信息（如信件、文檔、報表、多媒體等多種格式文件）在系統(tǒng)中各分支機構、部門及個人之間快速、高效地傳遞。1.5OA系統(tǒng)分析個人助理1.5OA系統(tǒng)分析公共信息管理圖書管理 圖書資料的基本信息管理和借閱管理。辦公用品管理 物品管理主要是實現(xiàn)辦公用品這類易耗品、公用設備的請領管理。如：辦公設備、辦公用品等的基本信息管理和借用、占有及調(diào)度管理，用戶通過系統(tǒng)全面了解機構物品各種情況，并可以進行申領。資產(chǎn)管理 實現(xiàn)對單位固定資產(chǎn)的基本信息、登記、領用、折舊管理，同時系統(tǒng)提供查詢和統(tǒng)計功能。會議管理 會議管理系統(tǒng)實現(xiàn)了會議室、會務信息的申請、安排和管理，提供了會議人員、時間、場地的管理。車輛管理 對車輛資源的使用、調(diào)度進行管理的?？蓪崿F(xiàn)駕駛員、車輛占用及調(diào)度的統(tǒng)一安排。問卷調(diào)查 在線問卷，調(diào)查意見、想法，并可匯總，以便于管理人員參考掌握相關情況。檔案管理檔案管理 檔案管理實現(xiàn)對人員的基本信息、學習、履歷、家庭、任職、專業(yè)技能、考核、獎勵信息的管理、查詢。1.5OA系統(tǒng)分析公共信息管理1.5OA系統(tǒng)分析銷售管理客戶信息管理 客戶信息、客戶單位信息管理，個人用戶可對自己的客戶信息進行管理，并可共享給其它人員，客戶經(jīng)理可對所有的客戶信息進行管理。管理人員可以自行定義需要管理的客戶信息，并支持對新加信息的管理。合同管理 合同管理可以登記合同的詳細信息，管理人員可以自行定義合同中的有關內(nèi)容，并支持對新加內(nèi)容的查詢。產(chǎn)品銷售管理 添加產(chǎn)品銷售的記錄，并可進行查詢。管理人員可以自行定義管理信息中的有關內(nèi)容，并支持對新加內(nèi)容的查詢。供應商信息管理 對供應商及聯(lián)系人進行管理。管理人員可以自行定義管理信息中的有關內(nèi)容，并支持對新加內(nèi)容的查詢。1.5OA系統(tǒng)分析銷售管理1.5OA系統(tǒng)分析超級管理工號管理 對員工工號進行管理，用戶也可以通過工號登錄調(diào)度中心 可對流程和工作計劃進行調(diào)度，定時發(fā)起流程，或者進行工作計劃的提醒，有效保障工作按時有條不紊地進行。系統(tǒng)管理 對用戶、角色、用戶組、權限分配、部門、公共共享、流程定義、流程中文檔的序列號、論壇、博客、討論、系統(tǒng)環(huán)境、配置等進行管理。自定義模塊 通過智能表單設計，定義模塊的顯示列表、權限等。系統(tǒng)日志 對系統(tǒng)用戶的登錄使用情況進行監(jiān)控記錄。生日管理 對員工生日進行管理，可以設置生日提醒。菜單管理 對左側(cè)菜單、頂部及底部導航菜單進行管理。1.5OA系統(tǒng)分析超級管理第一章軟件測試與項目分析1.1軟件測試概念1.2軟件測試內(nèi)容1.3軟件測試分類1.4軟件測試流程1.5OA系統(tǒng)分析第一章軟件測試與項目分析1.1軟件測試概念1.2軟件測試內(nèi)1.1軟件測試概念50年代，軟件伴隨著第一臺電子計算機的問世誕生了，以寫軟件為職業(yè)的人也開始出現(xiàn)，他們多是經(jīng)過訓練的數(shù)學家和電子工程師。1960年代美國大學開始出現(xiàn)授予計算機專業(yè)的學位，教人們寫軟件。早期人們在編寫代碼的時候，基本都是自己寫，自己調(diào)試，直到50年代末，測試才與調(diào)試區(qū)分來，但由于受調(diào)試思想的影響，測試一直處于被壓制狀態(tài)，“為了讓我們看到產(chǎn)品在工作，就得將測試工作往后推一點”。直到產(chǎn)品代碼，甚至是項目后期，才開始軟件測試工作。1972年，在美國北卡羅來納大學舉行了首屆軟件測試正式會議。1979年，GlenfordMyers的《軟件測試藝術》（TheArtofSoftwareTesting）中作出了當時最好的軟件測試定義：“測試是為發(fā)現(xiàn)錯誤而執(zhí)行的一個程序或者系統(tǒng)的過程?！敝链耍浖y試在正式登上歷史的舞臺，軟件測試是軟件生產(chǎn)流程中質(zhì)量保證的重要手段。測試，檢測、試驗，利用一定的手段，檢測被測對象特性表現(xiàn)是否與預期需求一致。對于軟件而言，測試是通過人工或者自動的檢測方式，檢測被測對象是否滿足用戶要求或弄清楚預期結果與實際結果之間的差異，是為了發(fā)現(xiàn)錯誤而審查軟件文檔、檢查軟件數(shù)據(jù)和執(zhí)行程序代碼的過程。軟件測試是質(zhì)量檢測過程，包含了若干個測試活動。（引自《軟件測試技術基礎教程》）1.1軟件測試概念50年代，軟件伴隨著第一臺電子計算機的問世1.1軟件測試概念早些時候，很多人對軟件測試的認識僅限于運行軟件執(zhí)行測試，實際上軟件測試還包括靜態(tài)測試和驗證活動。軟件包括實現(xiàn)用戶需求的源代碼、描述軟件功能及性能表現(xiàn)的說明書，支撐軟件運行的配置數(shù)據(jù)，軟件測試對象同樣包括了文檔及配置數(shù)據(jù)的測試，不僅僅是執(zhí)行軟件。軟件測試工程師職責定義的軟件測試是指軟件產(chǎn)品生存周期內(nèi)所有的檢查、評審和確認活動。如設計評審、文檔審查、需求測試、單元測試、集成測試、系統(tǒng)測試、驗收測試等等檢查活動。軟件測試活動是對軟件產(chǎn)品質(zhì)量的檢驗和評價的過程。一方面檢查、揭露軟件產(chǎn)品質(zhì)量中存在的質(zhì)量問題，另一方面又需對產(chǎn)品質(zhì)量進行客觀的評價并提出改進意見。軟件測試使用人工或自動化手段對被測對象進行確認驗證活動，從而找出被測對象與最終用戶需求之間的差別。在通常的軟件生產(chǎn)活動中，軟件測試貫穿于整個軟件的生命周期，從初期的項目需求調(diào)研到后期的產(chǎn)品維護，每個階段都離不開檢查、評審與確認活動。基于不同的角度，軟件測試的目的是不一樣的。從用戶角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產(chǎn)品。而從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證被測軟件已正確地實現(xiàn)了用戶的需求，確立人們對軟件質(zhì)量的信心。1.1軟件測試概念早些時候，很多人對軟件測試的認識僅限于運行1.2軟件測試內(nèi)容軟件測試定義是為了發(fā)現(xiàn)錯誤而審查軟件文檔、檢查軟件數(shù)據(jù)和執(zhí)行程序代碼的過程。從該定義可以看出，軟件測試對象并不僅僅是程序源代碼，還包括與之相對應的文檔及配置數(shù)據(jù)，在軟件生產(chǎn)活動中，一般都有哪些文檔呢？配置數(shù)據(jù)又都有哪些？通常情況下，軟件項目開展過程中，會有可行性報告、項目立項申請報告、項目進度安排計劃、需求規(guī)格說明書、開發(fā)進度計劃、測試計劃、概要設計文檔、詳細設計文檔、數(shù)據(jù)庫設計文檔、數(shù)據(jù)字典、源碼清單、測試用例等等，配置數(shù)據(jù)主要包括系統(tǒng)運行所必須的基礎數(shù)據(jù)，比如建庫sql語句、建表sql語句、存儲過程、數(shù)據(jù)庫連接配置文件、系統(tǒng)初始驅(qū)動程序等等。在上面眾多的文檔與配置數(shù)據(jù)中，測試工程師需要對這些資料進行檢查、評審與確認。1.2軟件測試內(nèi)容軟件測試定義是為了發(fā)現(xiàn)錯誤而審查軟件文檔、1.2軟件測試內(nèi)容軟件測試核心工作是實施軟件系統(tǒng)功能、性能、文檔、配置數(shù)據(jù)等方面的測試活動，除此之外，還有可能有需求調(diào)研、用戶手冊編寫等等工作。日常測試工作中，測試工程師經(jīng)常利用測試用例執(zhí)行被測軟件，利用預期結果與軟件的實際結果進行比較，從而找出被測系統(tǒng)中與最終用戶需求不一致的地方，也就是通常意義上的Bug。經(jīng)過一輪又一輪的版本迭代測試，使被測軟件達到預期質(zhì)量要求。以成都沖和科技有限公司OA項目（以下簡稱OA系統(tǒng)）為例，測試工程師以OA系統(tǒng)的需求規(guī)格說明書，從功能、性能、GUI等質(zhì)量特性提取測試項及子項，設計測試用例。當測試版本提交后，則可進行測試用例的執(zhí)行，發(fā)現(xiàn)并管理缺陷，并根據(jù)缺陷編寫系統(tǒng)測試報告，當測試工作完成后可根據(jù)項目經(jīng)理要求，編寫系統(tǒng)的用戶手冊等。1.2軟件測試內(nèi)容軟件測試核心工作是實施軟件系統(tǒng)功能、性能、1.3軟件測試分類從測試方法來看，軟件測試可分為黑盒測試、白盒測試、灰盒測試、靜態(tài)測試、動態(tài)測試、手工測試、自動化測試等幾個方面，從測試階段來分，可分為需求測試、單元測試、集成測試、系統(tǒng)測試、驗收測試等幾個階段。1.3軟件測試分類從測試方法來看，軟件測試可分為黑盒測試、白1.3軟件測試分類1.3.1按測試方法劃分與軟件開發(fā)有若干框架一樣，軟件測試同樣可以采用多種方法，利用不同的方法可以得到不同的效果，并且最終保證被測對象符合預期的用戶需求。按照測試方法分，主要有以下幾種：1.3軟件測試分類1.3.1按測試方法劃分1.3軟件測試分類黑盒測試黑盒測試又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于需求規(guī)格的功能測試，通過測試活動來檢查被測對象每個功能能否正常使用，是否滿足用戶需求。黑盒測試方法能更好更真實的從用戶角度來檢查被測對象界面、功能等方面需求實現(xiàn)情況，但黑盒測試基于用戶需求進行，會帶來隱患。黑盒測試方法難以發(fā)現(xiàn)一些隱藏在程序內(nèi)部的缺陷，如內(nèi)存泄漏等。以OA系統(tǒng)為例，如果從用戶需求角度考慮，對圖書管理、資產(chǎn)管理或車輛管理等模塊，實施功能或性能測試，此處的方法即為黑盒測試。黑盒測試工作目前是軟件測試方法核心方法，在企業(yè)測試過程中，大多數(shù)采用黑盒測試方法，讀者在學習過程中需重點學習此測試方法，再輔以后續(xù)的測試方法，方能把握工作核心，關鍵點。1.3軟件測試分類黑盒測試1.3軟件測試分類白盒測試白盒測試又稱結構測試、邏輯驅(qū)動測試或基于程序代碼內(nèi)部構成的測試。此時，測試工程師需深入考查程序代碼的內(nèi)部結構、邏輯設計等。白盒測試需要測試工程師具備很深的軟件開發(fā)功底，精通相應的開發(fā)語言，初級測試工程師難以勝任該工作。白盒測試方法主要包括代碼檢查法、靜態(tài)結構分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測試法，其中最為常用的方法是代碼檢查法。代碼檢查包括桌面檢查、代碼審查和走查等，主要檢查代碼和設計一致性，代碼對標準的遵循、可讀性，代碼邏輯表達的正確性，代碼結構合理性等方面；發(fā)現(xiàn)違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內(nèi)容。一般公司都有比較成熟的編程規(guī)范，代碼檢查時，可以根據(jù)編程規(guī)范進行檢查。1.3軟件測試分類白盒測試1.3軟件測試分類以OA系統(tǒng)車輛管理添加車輛功能為例，如果對以下代碼

functionfindObj(theObj,theDoc)

{

varp,i,foundObj;

if(!theDoc)theDoc=document;

if((p=theObj.indexOf("?"))>0&&parent.frames.length)

{

theDoc=parent.frames[theObj.substring(p+1)].document;

theObj=theObj.substring(0,p);

}1.3軟件測試分類以OA系統(tǒng)車輛管理添加車輛功能為例，如果對1.3軟件測試分類

if(!(foundObj=theDoc[theObj])&&theDoc.all)foundObj=theDoc.all[theObj];for(i=0;!foundObj&&i<theDoc.forms.length;i++)foundObj=theDoc.forms[i][theObj];for(i=0;!foundObj&&theDoc.layers&&i<theDoc.layers.length;i++)foundObj=findObj(theObj,theDoc.layers[i].document);if(!foundObj&&document.getElementById)foundObj=document.getElementById(theObj);returnfoundObj;}1.3軟件測試分類if(!(foundObj=thvarGetDate="";functionSelectDate(ObjName,FormatDate){ varPostAtt=newArray; PostAtt[0]=FormatDate; PostAtt[1]=findObj(ObjName); GetDate=showModalDialog("../util/calendar/calendar.htm",PostAtt,"dialogWidth:286px;dialogHeight:221px;status:no;help:no;");}functionSetDate(){ findObj(ObjName).value=GetDate;}進行測試，驗證findObj、SetDate等函數(shù)的功能，此類方法即為白盒測試方法。varGetDate="";1.3軟件測試分類灰盒測試與前面的黑盒測試、白盒測試相比，灰盒測試介于兩者之間。黑盒測試僅關注程序代碼的功能性表現(xiàn)，不關注其內(nèi)部邏輯設計、構成情況，白盒測試則僅從程序代碼的內(nèi)部構成考慮，檢查其內(nèi)部代碼設計結構，方法調(diào)用等，灰盒測試則綜合了黑盒測試與白盒測試，一方面考慮程序代碼的功能性表現(xiàn)，另一方面，又需要考慮程序代碼的內(nèi)部結構。同樣，以OA系統(tǒng)為例，如果在測試過程中，既考慮車輛管理用戶需求方面的特性，如能否添加車輛，編輯車輛信息等，又從該功能的實現(xiàn)邏輯代碼考慮，則此方法即為灰盒測試。1.3軟件測試分類灰盒測試1.3軟件測試分類靜態(tài)測試靜態(tài)測試，顧名思義，靜態(tài)的、不執(zhí)行被測對象程序代碼尋找缺陷的過程。通過閱讀程序代碼、文檔資料等，與需求規(guī)格說明書進行比較，找出程序代碼中設計不合理以及文檔資料有錯誤的地方。在實際研發(fā)活動中可開展同行評審活動，通過評審方式，找出文檔資料、程序代碼中存在的缺陷并加以修改。以OA系統(tǒng)為例，如果針對該系統(tǒng)的設計文檔，如概要設計文檔，或系統(tǒng)源代碼進行走讀查閱，則使用的是靜態(tài)測試方法。1.3軟件測試分類靜態(tài)測試1.3軟件測試分類動態(tài)測試動態(tài)測試即為執(zhí)行被測對象程序代碼，執(zhí)行測試用例，檢查程序運行實際結果與測試用例預期結果之間是否存在差異，判定實際結果與預期結果是否一致，從而檢驗程序的正確性、可靠性和有效性，并分析系統(tǒng)運行效率和健壯性等性能狀況。動態(tài)測試由四部分組成：設計測試用例、執(zhí)行測試用例、分析比較輸出結果、輸出測試報告。動態(tài)測試有三種主要的方法：黑盒測試、白盒測試以及灰盒測試。以OA系統(tǒng)為例，搭建測試環(huán)境運行系統(tǒng)對其進行功能的驗證測試，即為使用動態(tài)測試方法。1.3軟件測試分類動態(tài)測試1.3軟件測試分類手工測試未真正接觸軟件測試之前，很多人都認為，軟件測試工作就是執(zhí)行一些鼠標點擊的動作來查找缺陷。的確，在手動測試階段，大部分的測試工作就是模擬用戶的業(yè)務流程，使用軟件產(chǎn)品，與用戶需求規(guī)格進行比較，從而發(fā)現(xiàn)軟件系統(tǒng)中的缺陷。手動測試是最傳統(tǒng)的測試方法，也是目前大多數(shù)公司都在使用的測試形式。測試工程師設計測試用例并執(zhí)行測試用例，根據(jù)實際結果與預期結果相比，記錄測試結果，最終輸出測試報告。手工測試，可以充分發(fā)揮測試工程師的主觀能動性，將其智力活動體現(xiàn)于測試工作中，能發(fā)現(xiàn)很多的缺陷，但手工測試方法又有一定的局限性，并且長期下去會令人覺得枯燥單調(diào)。1.3軟件測試分類手工測試1.3軟件測試分類自動化測試

軟件行業(yè)不斷發(fā)展，軟件測試技術也在不斷地更新，出現(xiàn)了眾多的自動化測試工具，如HP的QucikTestProfessional、LoadRunner，IBMRPT、RFT等等。自動化測試是利用一些測試工具，錄制業(yè)務使用流程，讓工具自動運行測試過程查找缺陷，也可以編寫腳本代碼，設定特定的測試場景，自動尋找缺陷。自動化測試的引入，大大提高了測試的效率和測試的準確性，而且寫出結構性較好的測試腳本，還可以在軟件生命周期的各個階段重復使用。1.3軟件測試分類自動化測試1.3軟件測試分類前面概要闡述了按測試方法劃分的軟件測試類型，下面以測試階段對測試類型進行劃分，主要有需求測試、單元測試、集成測試、系統(tǒng)測試、用戶測試、回歸測試等。需求測試需求調(diào)研完成后，測試部門或者需求小組進行需求測試，從需求文檔規(guī)范性、正確性等方面檢查需求調(diào)研階段生成的需求文檔，測試工程師最好是有經(jīng)驗的需求分析人員，并且得到了需求調(diào)研期間形成的DEMO。在許多失敗的項目中，70%～85%的返工是由于需求方面的錯誤所導致的，并且因為需求的緣故而導致大量的返工，造成進度延遲、缺陷的發(fā)散，甚至項目的失敗，這是一件極其痛苦的事情，所以，在有條件開展需求測試的時候，一定要實施需求測試。單元測試單元測試又稱為模塊測試，顧名思義，就是對程序代碼中最小的設計模塊單元進行測試。單元測試是在軟件開發(fā)過程中進行的最低級別的測試活動。在單元測試活動中，我們主要采用靜態(tài)測試與動態(tài)測試相結合的辦法。首先采用靜態(tài)的代碼走查，檢查程序代碼中不符合編程規(guī)范，存在錯誤或者遺漏的地方，同時使用代碼審查的方法，項目小組檢查項目代碼，以期發(fā)現(xiàn)更多的問題，然后再使用單元測試工具，比如JUnit等工具進行程序代碼內(nèi)邏輯結構、函數(shù)調(diào)用等方面進行測試。據(jù)業(yè)界統(tǒng)計，單元測試一般可以發(fā)現(xiàn)大約80%的軟件缺陷。1.3.2按測試階段劃分1.3軟件測試分類前面概要闡述了按測試方法劃分的軟件測試類型1.3軟件測試分類集成測試集成測試，又稱為組裝測試，就是將軟件產(chǎn)品中各個模塊集成組裝起來，檢查其接口是否存在問題，以及組裝后的整體功能、性能表現(xiàn)。在開展集成測試之前，我們需進行深入的單元測試（當然，實際工作中大多公司不會做單元測試，僅有程序員各自檢查自己的代碼）。從個體來講，可能解決了很多的缺陷，但所有的個體組合起來，就可能出現(xiàn)各種各樣的問題。1+1<2的問題，此刻尤為突出。集成測試一般可采用非增式集成方法、增式集成方法（自底向上集成、自頂向下集成、組合方式集成）等策略進行測試，利用以黑盒測試為主、白盒測試為輔的測試方法進行測試。集成測試工程師一般由測試工程師擔當，開發(fā)工程師將經(jīng)過單元測試的代碼集成后合成一個新的軟件測試版本，交由配置管理員，然后測試組長從配置管理員處提取集成好的測試版本進行測試。集成測試階段主要解決的是各個軟件組成單元代碼是否符合開發(fā)規(guī)范、接口是否存在問題、整體功能有無錯誤、界面是否符合設計規(guī)范、性能是否滿足用戶需求等問題。1.3軟件測試分類集成測試1.3軟件測試分類系統(tǒng)測試系統(tǒng)測試，是將通過集成測試的軟件，部署到某種較為復雜的計算機用戶環(huán)境進行測試，這里所說的復雜的計算機用戶環(huán)境，其實就是我們一般用戶的計算機環(huán)境。系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。這個階段主要進行的是安裝與卸載測試、兼容性測試、功能確認測試、安全性測試等等。系統(tǒng)測試階段采用黑盒測試方法，主要考查被測軟件的功能與性能表現(xiàn)。如果軟件可以按照用戶合理地期望的方式來工作的時候，即可認為通過系統(tǒng)測試。系統(tǒng)測試過程其實也是一種配置檢查過程，檢查在軟件生產(chǎn)過程中是否有遺漏的地方，在系統(tǒng)測試過程中做到查漏補缺，以確保交付的產(chǎn)品符合用戶質(zhì)量要求。1.3軟件測試分類系統(tǒng)測試1.3軟件測試分類用戶測試在系統(tǒng)測試完成后，將會進行用戶測試。這里的用戶測試，其實可以稱為用戶確認測試。在正式驗收前，需要用戶對本系統(tǒng)做出一個評價，用戶可對交付的系統(tǒng)做測試，并將測試結果反饋回來，進行修改、分析。面向應用的項目，在交付用戶正是使用之前要經(jīng)過一定時間的用戶測試?；貧w測試回歸測試一般發(fā)生的情況在發(fā)現(xiàn)缺陷后，重新執(zhí)行測試用例的過程?；貧w測試階段主要的目的是檢查以前的測試用例能否再次通過，是否還有需要補充的用例等等。有些公司會采用自動化測試工具來進行回歸測試，比如利用QTP，對于產(chǎn)品級，變動量小的軟件而言，我們可以利用這樣的工具去執(zhí)行測試。但一般情況下，都由測試工程師手動的執(zhí)行以前的測試用例，來檢查用例通過情況?；貧w測試可以發(fā)現(xiàn)在產(chǎn)品發(fā)布前未能發(fā)現(xiàn)的問題，比如時鐘的延遲、軟件的性能問題等等。1.3軟件測試分類用戶測試1.4軟件測試流程在學習了軟件測試的基本概念后，我們接著聊聊一般公司里軟件測試的流程。以OA系統(tǒng)為例，一般公司的軟件測試工作流程如圖1-1所示。圖1-1軟件測試工作流程圖1.4軟件測試流程在學習了軟件測試的基本概念后，我們接著聊聊1.4軟件測試流程1.4.1成立測試組當需測試的項目分配下來后，該項目的負責人向測試部門提出測試申請，通過測試經(jīng)理的審批后，由測試經(jīng)理指派測試組長與測試工程師，成立項目測試組，負責該項目的測試工作。根據(jù)項目團隊的組織流程，OA系統(tǒng)的負責人張三向測試部門經(jīng)理李四申請實施測試活動，此時，李四接受測試任務后，制定王五、趙六、田七為測試工程師，負責OA系統(tǒng)的實際測試活動。1.4軟件測試流程1.4.1成立測試組1.4軟件測試流程1.4.2分析測試需求測試經(jīng)理任命測試組長，測試組長需提前熟悉被測對象的需求，從總體上掌握項目的進展情況。通過仔細的閱讀項目的相關文檔（比如項目的進度計劃、測試要求等）后，測試組長需安排下一步工作。1.4軟件測試流程1.4.2分析測試需求1.4軟件測試流程1.4.3制定測試計劃測試組長在詳細了解項目信息后，根據(jù)項目需求、項目進度計劃表制定當前項目的測試計劃，并以此測試計劃來指導測試組開展對應的測試工作。測試計劃中需說明每個測試工件輸出的時間點、測試資源、測試方法、測試風險規(guī)避、測試停測標準等。1.4軟件測試流程1.4.3制定測試計劃1.4軟件測試流程1.4.4提取測試需求測試組長制定好了測試計劃后，項目組進行評審。評審通過后，項目測試組即可按照此測試計劃開展工作。測試組員根據(jù)測試組長的任務分配，進行項目用戶需求規(guī)格說明書的閱讀，甚至開展需求測試工作。需求閱讀理解完成后，進行測試需求的提取，也就是列出被測對象需測試的點，這項工作可以利用TestDiector等測試管理工具開展。1.4軟件測試流程1.4.4提取測試需求1.4軟件測試流程1.4.5編寫測試用例測試需求提取完畢，經(jīng)過測試組的評審通過后，測試組員可以進行測試用例的設計，這些工作都是在測試計劃中規(guī)定的時間內(nèi)完成。比如測試計劃中規(guī)定“2008-12-20至2008-12-30完成系統(tǒng)測試用例設計及評審”，那么就必須在這個時間段內(nèi)完成被測對象的測試用例設計。測試用例的設計一般使用Word、Excel等樣式，也可使用TestDirector、TestLink等工具進行管理。測試用例設計工作在某些企業(yè)中因項目周期及要求不同，可能不開展，直接進行測試活動。1.4軟件測試流程1.4.5編寫測試用例1.4軟件測試流程1.4.6搭建測試環(huán)境測試用例設計工作完成后，如果項目開發(fā)組告知測試組長可以開展測試的時候，測試組長可從配置管理員處提取測試版本，根據(jù)開發(fā)組提供的被測對象測試環(huán)境搭建單進行測試環(huán)境的搭建。測試環(huán)境搭建需要測試工程師掌握基本的硬件、軟件知識。隨著用戶需求的不斷加大，復雜化，項目運行環(huán)境往往非常復雜，并且搭建成本極高，以大型網(wǎng)站系統(tǒng)架構為例，如圖1-2所示。1.4軟件測試流程1.4.6搭建測試環(huán)境1.4軟件測試流程圖1-2大型web系統(tǒng)架構1.4軟件測試流程1.4軟件測試流程從用戶角度來看，該服務器的架構非常復雜，從測試人員角度來看，同樣站在用戶角度，亦不需要掌握其等復雜架構，測試環(huán)境一般都由開發(fā)人員搭建，所以該環(huán)節(jié)的工作測試人員不一定實施。1.4軟件測試流程從用戶角度來看，該服務器的架構非常復雜，從1.4軟件測試流程1.4.7執(zhí)行測試用例測試環(huán)境搭建完成后，測試組員將進行測試用例的執(zhí)行。根據(jù)前期設計并評審通過的測試用例，測試組員進行各個功能模塊的測試。在執(zhí)行測試用例的過程中，如果發(fā)現(xiàn)有遺漏或者不完善的測試用例，需及時做更新，并用文檔記錄變更歷史。用例執(zhí)行過程中如果發(fā)現(xiàn)了Bug，則需按照部門或者項目組的Bug提交規(guī)范，利用一些Bug管理工具提交Bug。常用的Bug管理工具有Bugzilla、TestTrack、Mantis、TestDirector等。1.4軟件測試流程1.4.7執(zhí)行測試用例1.4軟件測試流程1.4.8跟蹤處理缺陷大多數(shù)公司都有自己的Bug管理流程規(guī)范，項目組成員需根據(jù)這個流程規(guī)范開展日常的Bug處理工作。在缺陷處理階段，大多要經(jīng)過4次、甚至更多的迭代過程，多次進行回歸測試，直到在規(guī)定的時間內(nèi)達到測試計劃中所定義的停測標準為止。在這個階段，主要使用黑盒測試方法開展工作，以被測對象的需求規(guī)格說明為依據(jù)，重點關注被測對象的界面與功能表現(xiàn)。1.4軟件測試流程1.4.8跟蹤處理缺陷1.4軟件測試流程1.4.9執(zhí)行性能測試一般在功能測試完成后，我們還需開展相應的性能測試工作。與功能測試一樣，在測試之前，需要進行測試需求的分析，性能指標提取、用例設計、腳本錄制、優(yōu)化、執(zhí)行、分析等等一系列過程。通過使用一些自動化工具進行性能測試是目前性能測試的主要手段，常用的性能測試工具有WAS、QALoad、WebLoad、LoadRunner、Robot等。性能測試階段主要解決被測對象的性能問題。目前大部分項目軟件在執(zhí)行功能測試后，可能不進行性能測試，所以本過程在實際項目測試時不一定實施，但面向大眾或涉及多用戶多并發(fā)的業(yè)務系統(tǒng)，一定會開展性能測試活動。1.4軟件測試流程1.4.9執(zhí)行性能測試1.4軟件測試流程1.4.10輸出測試報告功能測試、性能測試都完成后，測試組長需要對被測對象做一個全面的總結，以數(shù)據(jù)為依據(jù)，衡量被測對象的質(zhì)量狀況，并提交測試結果報告給項目組，從而幫助項目經(jīng)理、開發(fā)組及其他部門了解被測對象的質(zhì)量情況，以決定下一步的工作計劃。功能測試報告主要包含被測對象的缺陷修復率、Bug狀態(tài)統(tǒng)計、Bug分布等，性能測試報告主要包含測試指標的達標情況及測試部的質(zhì)量評價等。當然，也可以出一份整體的測試報告，包含功能、性能的測試結果。綜上所述，測試需求分析、測試計劃制定、執(zhí)行測試、跟蹤處理缺陷、編寫測試報告等測試活動，在任何項目中都會實施，而測試用例設計、測試環(huán)境搭建、性能測試等活動則可能根據(jù)項目需求不一樣不一定實施。1.4軟件測試流程1.4.10輸出測試報告1.5OA系統(tǒng)分析通過上面幾部分的介紹，我們已經(jīng)了解了軟件測試的基本概念，軟件測試工作的常用流程等。從本節(jié)起，我們正式進入本書的實戰(zhàn)部分，以實際的項目實例介紹軟件測試工作?，F(xiàn)在軟件行業(yè)中有很多業(yè)務類型，大多數(shù)公司招聘時都需要測試工程師具備豐富的項目經(jīng)驗，那么這些項目經(jīng)驗怎么來呢？這里介紹一個常用的方法。對于軟件測試初學者，一個比較好的方法是利用網(wǎng)絡下載一些程序源代碼，根據(jù)這些資料中配備的環(huán)境配置說明，自己練習部署、源代碼閱讀、業(yè)務理解等，如果在環(huán)境配置、程序應用過程中出現(xiàn)問題的話，我們可以通過網(wǎng)絡查找相關的解決辦法。一方面，自己動手練習環(huán)境的部署，提高代碼閱讀能力及動手能力；另一方面，可以接觸各種各樣的業(yè)務系統(tǒng)，因為一般的源代碼網(wǎng)站都會將代碼進行分類，業(yè)務類型還是比較豐富的，這些源代碼都是工作中各種業(yè)務的縮影。現(xiàn)在常用的軟件大概分為七大類：系統(tǒng)軟件、應用軟件、工程科學計算軟件、嵌入式軟件、產(chǎn)品軟件、Web應用軟件和人工智能軟件。這些分類實際上按照業(yè)務類型來分，在實際的工作中都有可能接觸到，所以，我們應該通過多種方法，多個途徑來豐富自己的業(yè)務知識。1.5OA系統(tǒng)分析通過上面幾部分的介紹，我們已經(jīng)了解了軟件1.5OA系統(tǒng)分析OA是什么意思呢？OA（OfficeAutomation）辦公自動化是將現(xiàn)代化辦公和計算機網(wǎng)絡功能結合起來的一種新型的辦公方式，是當前新技術革命中一個非?；钴S和具有很強生命力的技術應用領域，是信息化社會的產(chǎn)物。辦公自動化的原動力是人類文明進步和發(fā)展的同時人類求得自身解放的需要，OA系統(tǒng)的出現(xiàn)和發(fā)展也正是來源于這種需要的牽引。傳統(tǒng)的辦公方式極大地束縛了人的創(chuàng)造力和想象力，埋沒了人的智慧和潛能，使人們耗費了大量的時間和精力去手工處理那些繁雜、重復的工作。手工處理的延時和差錯，正是現(xiàn)代化管理中應該去除的弊端。用先進的、現(xiàn)代化的工具代替手工作業(yè)，無疑是生產(chǎn)力發(fā)展的方向。OA系統(tǒng)對傳統(tǒng)辦公方式的變革，正是適應了人們的普遍需求，也順應了技術發(fā)展的潮流，自然成為業(yè)界追求的目標。1.5OA系統(tǒng)分析OA是什么意思呢？1.5OA系統(tǒng)分析OA系統(tǒng)建設的本質(zhì)是提高決策效能為目的的。通過實現(xiàn)辦公自動化，或者說實現(xiàn)數(shù)字化辦公，可以優(yōu)化現(xiàn)有的管理組織結構，調(diào)整管理體制，在提高效率的基礎上，增加協(xié)同辦公能力，強化決策的一致性，最后實現(xiàn)提高決策效能的目的。OA系統(tǒng)的基礎是對管理的理解和對信息的積累。技術只是辦公自動化的技術實現(xiàn)手段。只有將辦公過程中生成的信息進行有序化積累，沉淀，才能真正發(fā)揮辦公自動化的作用。OA系統(tǒng)的靈魂是軟件，硬件只是實現(xiàn)辦公自動化的環(huán)境保障。數(shù)字化辦公的兩個明顯特征是授權和開放，通過授權確保信息的安全和分層使用，使得數(shù)字化辦公系統(tǒng)有可以啟用的前提，通過開放，使得信息共享成為現(xiàn)實。（引自網(wǎng)絡）1.5OA系統(tǒng)分析OA系統(tǒng)建設的本質(zhì)是提高決策效能為目的的1.5OA系統(tǒng)分析OA系統(tǒng)現(xiàn)在非常流行。前些年，比如2002年左右，很多公司開始提倡無紙化辦公，使得OA系統(tǒng)得到了蓬勃發(fā)展。記得當時我所在的公司使用DominoLotus開發(fā)了一套OA系統(tǒng)，功能非常齊全，但價格也比較貴?，F(xiàn)在的OA系統(tǒng)所使用的開發(fā)語言已經(jīng)很廣泛了，有php、jsp、asp等等。萬