測試指導(dǎo)手冊.doc

精品文檔 軟件測試指導(dǎo)手冊 張寶良為了提高測試效率，保證產(chǎn)品測試質(zhì)量，從而保證產(chǎn)品開發(fā)工期與質(zhì)量，統(tǒng)一測試思想是十分必要的。本文就用友軟件測試相關(guān)內(nèi)容進行闡述，力求給大家啟示與參考。第一章 測試概念第一節(jié) 測試要點 測試要點是依據(jù)等價類方法（或其他方法），經(jīng)過對被測試內(nèi)容進行分析后，以清單方式進行描述要測試的內(nèi)容。注意事項：1. 針對任何一個被測試內(nèi)容，均要考慮是否涉及系統(tǒng)提供的公用功能。2. 測試要點盡可能窮舉，避免遺漏。3. 測試要點給出代碼實現(xiàn)正確實現(xiàn)是什么，什么樣實現(xiàn)是錯誤的。4. 測試要點是針對最小功能單元，可以是一個功能結(jié)點，也可以是一個操作按鈕，但不允許多個內(nèi)容一起描述舉例：U8產(chǎn)品 XXX產(chǎn)品測試要點測試內(nèi)容涉及要素基礎(chǔ)數(shù)據(jù)要求、算法、界面布局、多語、升級、接口、年結(jié)、打印、輸出、預(yù)覽、審批流、預(yù)警、EAI、并發(fā)、互斥、功能權(quán)限、數(shù)據(jù)權(quán)限、效率、極限序號測試要點預(yù)計結(jié)果第二節(jié) 測試用例 測試用例是指數(shù)據(jù)測試用例，針對測試要點，必須以數(shù)據(jù)形式才可描述清楚，作為測試要點的補充。測試要點不一定必須有測試數(shù)據(jù)用例，但測試數(shù)據(jù)用例必須對應(yīng)有測試要點。注意事項：1. 測試用例一般會涉及多個功能配合。2. 描述中要體現(xiàn)操作次序3. 數(shù)據(jù)準備考慮以下情況l 小數(shù)l 外幣l 表體一條記錄l 表體滿記錄l 表體滿記錄多一條4. 數(shù)據(jù)準備不要太復(fù)雜，要便于操作。如果復(fù)雜可拆開描述。第二章 測試策略 測試策略：針對某項具體任務(wù)，安排最合適的人選，采用最佳的測試方法，在規(guī)定的時間內(nèi)，保質(zhì)保量完成。策略要點（1） 在測試策略中，人員能力的培養(yǎng)是最重要的，是完成任務(wù)的關(guān)鍵。（2） 針對被測試對象的不同，測試策略應(yīng)有差異。（3） 測試計劃是保證被測試對象完全測試的關(guān)鍵，同時也是提高測試人員工作效率的關(guān)鍵。（4） 被測試對象在分解任務(wù)時要有主次之分（5） 測試資源安排時要有主次之分（6） 測試進度安排要有主次之分（7） 合理設(shè)計各測試階段測試內(nèi)容，充分體現(xiàn)早期測試思想，及早穩(wěn)定產(chǎn)品。（8） 最大限度地提高測試經(jīng)理的作用（任務(wù)安排、測試設(shè)計、問題分析、產(chǎn)品把握）（9） 建立監(jiān)督、檢查機制。每個階段都要有報告產(chǎn)生，對報告要進行詳細分析，以便掌握進度和質(zhì)量。（10） 向過程要效益，過程不同效益不同。任務(wù)計劃任務(wù)計劃分兩類：測試經(jīng)理使用的“階段任務(wù)計劃”，測試人員使用的“每日任務(wù)計劃” XXX測試組階段任務(wù)計劃測試任務(wù)開始時間結(jié)束時間完成情況871SP（測試驗證及Bug修改）2008-11-202008-12-19872上市后補丁（任務(wù)含開發(fā)和測試時間）2008-11-202008-12-31發(fā)版時未同步的補丁同步2008-12-12008-12-18該計劃根據(jù)開發(fā)計劃由測試經(jīng)理編寫。它有以下類型：大版、專版、特殊補丁、臨時任務(wù)。定期向部門經(jīng)理反饋 XXX測試員每日任務(wù)計劃測試任務(wù)日期完成情況2008-12-32008-12-42008-12-5該計劃根據(jù)階段測試任務(wù)制定，由測試經(jīng)理編寫，測試人員執(zhí)行。切不可以由測試人員編寫，理由是缺乏全面考慮，尤其是測試覆蓋度方面。測試人員每日向測試經(jīng)理反饋。工作內(nèi)容分類以是否改動可以分為改動部分和非改動部分。以是否是重點可以分為重點內(nèi)容和非重點內(nèi)容。次序（1）改動部分（30%資源）（2）重點部分（40%資源）（3）非改動部分（10%資源）（4）全面測試（20%資源）內(nèi)容（1） 測試人員與各開發(fā)角色充分溝通（2） 編寫、評審、執(zhí)行測試要點及測試用例（3） 每日測試問題分析（原因、影響、補充測試要點）測試資源目前測試資源主要有三種：正式員工、外包測試人員、實習(xí)生；針對每個版本重點的不同在資源配備上要合理安排。1資源分析（1） 正式人員正式員工是公司測試的核心力量。他們是經(jīng)過嚴格篩選的，大部分都具有實際工作經(jīng)驗，工作心態(tài)比較穩(wěn)定，為此在分配任務(wù)時，核心產(chǎn)品、核心內(nèi)容要由他們來負責(zé)。（2） 外包測試人員外包測試人員是公司測試的輔助力量，他們也是經(jīng)過嚴格篩選的，大部分也都具有實際工作經(jīng)驗，但在專業(yè)知識方面沒有正式員工那樣嚴格。他們的工作心態(tài)相對穩(wěn)定，歸屬感差一些。但是合理使用，同樣會達到正式員工的效果，甚至?xí)葌€別正式員還好。為此在分配工作任務(wù)時，擇優(yōu)考慮。（3） 實習(xí)生實習(xí)生是公司測試的邊緣力量，他們來公司的主要目的是學(xué)習(xí)軟件產(chǎn)品測試知識，相關(guān)業(yè)務(wù)知識，為自己擇業(yè)增加籌碼。錄用他們時主要考察他們的專業(yè)知識與綜合素質(zhì)，在分配工作任務(wù)時，產(chǎn)品的邊緣測試任務(wù)一般由他們來完成，表現(xiàn)優(yōu)異者可以考慮接觸一些核心內(nèi)容。2資源培養(yǎng)培養(yǎng)測試人員的手段有很多，比如：產(chǎn)品知識培訓(xùn)、測試方法培訓(xùn)、測試技巧培訓(xùn)等。這些都是傳統(tǒng)的方法。一個測試人員由不合到合格需要很長的時間。建立業(yè)務(wù)員能力提升系統(tǒng)，可以縮短培養(yǎng)時間，這一系統(tǒng)即包括業(yè)務(wù)知識，又包括測試理論。3指導(dǎo)思想在軟件產(chǎn)品測試過程中，所有測試人員都要樹立正確的工作觀念，任何消極的工作態(tài)度都會影響自己的未來發(fā)展，所以，必須明白當前的工作是在為自己工作，為自己的未來工作。為此，測試經(jīng)理除了安排測試任務(wù)外，溝通工作是重點。溝通包括各環(huán)節(jié)、各角色的工作內(nèi)容溝通；下屬員工思想溝通，隨時關(guān)注每個人的思想動態(tài)，及時調(diào)整，確保每個員工全身心的進行測試工作。測試誤區(qū)1 測試人員只要了解業(yè)務(wù)知識就可以了，開發(fā)知識不需要了解。2 測試工作很簡單，任何人都可以做，沒什么技術(shù)可言3 我只為找產(chǎn)品錯誤，其他不管4 測試是給程序員打下手的5 測試人員與程序員的關(guān)系是對立的6 我是程序員，測試不是我的事7 測試很苦，很枯燥8 測試很難有成就感，開發(fā)還可以說哪個功能是我開發(fā)的。9 測試工作不受重視第三章 測試方法 最常規(guī)測試分黑盒測試與白盒測試，針對管理軟件而言，目前主要集中應(yīng)用的是黑盒測試。黑盒測試顧名思義就是將被測系統(tǒng)看成一個黑盒，從外界取得輸入，然后再輸出。整個測試基于需求文檔、測試文檔、產(chǎn)品幫助、支持問題，看是否能滿足文檔中的所有要求。黑盒測試要求測試者在測試時不能使用與被測系統(tǒng)內(nèi)部結(jié)構(gòu)相關(guān)的知識或經(jīng)驗，它適用于對系統(tǒng)的功能進行測試。 黑盒測試的優(yōu)點有： 1） 比較簡單，不需要了解程序內(nèi)部的代碼及實現(xiàn)2） 與軟件的內(nèi)部實現(xiàn)無關(guān)3） 從用戶角度出發(fā)，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；4） 基于軟件開發(fā)文檔，所以也能知道軟件實現(xiàn)了文檔中的哪些功能； 5） 在做軟件自動化測試時較為方便。 黑盒測試的缺點有： 1) 不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；2) 自動化測試的復(fù)用性較低。此處暫不討論白盒測試第一節(jié) 功能驗證法（點測試法）l 依據(jù)產(chǎn)品功能清單，詳細分析理解具體的功能描述，檢查產(chǎn)品實現(xiàn)是否正確。1） 參考產(chǎn)品隨機幫助2） 參考需求文檔3） 參考測試要點4） 參考測試用例注意事項1） 考慮逆向操作2） 考慮極限情況3） 考慮界面規(guī)范4） 考慮提示語規(guī)范5） 利用等價類方法設(shè)計數(shù)據(jù)測試范圍6） 如果沒有以上測試依據(jù)，必須編寫測試要點，也就是所有測試必須提前編寫或想好測試點再測試舉例：測試憑證審核1. 單張審核2. 成批審核3. 按憑證類別過濾審核憑證4. 按月份和憑證號范圍過濾審核憑證5. 按日期范圍過濾審核憑證6. 選擇全部憑證審核7. 查看所有作廢憑證8. 查看所有有錯憑證9. 按外部系統(tǒng)過濾憑證審核10. 按制單人、審核人、主管簽字過濾憑證審核11. 聯(lián)查明細賬 不能聯(lián)查現(xiàn)金、銀行科目 只有有此科目查詢權(quán)限的操作員才可查詢12. 審核人和制單人不能是同一個人13. 若想對已審核的憑證取消審核，單擊取消取消審核。取消審核簽字只能由審核人自己進行。14. 憑證一經(jīng)審核，就不能被修改、刪除，只有被取消審核簽字后才可以進行修改或刪除。15. 審核人除了要具有審核權(quán)外，還需要有對待審核憑證制單人所制憑證的審核權(quán)，這個權(quán)限在基礎(chǔ)設(shè)置的數(shù)據(jù)權(quán)限中設(shè)置。16. 采用手工制單的用戶，在憑單上審核完后還須對錄入機器中的憑證進行審核。17. 作廢憑證不能被審核，也不能被標錯。18. 已標錯的憑證不能被審核，若想審核，需先按取消取消標錯后才能審核。已審核的憑證不能標錯。19. 預(yù)算審批通過的憑證，只能進行審核，不能進行憑證其它操作。20. 取消審核時，無論預(yù)算管理系統(tǒng)返回何值全部認為成功，系統(tǒng)只提示不進行控制。21. 企業(yè)可以依據(jù)實際需要加入審核后方可執(zhí)行領(lǐng)導(dǎo)簽字的控制，同時取消審核時控制領(lǐng)導(dǎo)尚未簽字?？稍谶x項中選中主管簽字以后不可以取消審核和出納簽字第二節(jié) 流程測試法（線測試法） 依據(jù)產(chǎn)品功能相互之間的依存關(guān)系，以列表形式描述出功能的操作次序，主要檢查功能節(jié)點之間的耦合情況。注意事項：1） 測試逆向操作2） 測試傳輸字段之間的數(shù)據(jù)類型、字段寬度的一致性3） 在測試之前要將所測試內(nèi)容以清單形式進行列示，以便檢查。舉例：銀行對賬流程流程1 1 銀行會計科目指定2 結(jié)算方式設(shè)定3 部門、職員準備4 支票登記5 錄入銀行會計科目憑證6 銀行科目憑證簽字7 查詢銀行日記賬（包含未記賬憑證）流程21 銀行會計科目指定2 結(jié)算方式設(shè)定3 部門、職員準備4 支票登記5 錄入銀行會計科目憑證6 銀行科目憑證簽字7 銀行科目憑證審核8 銀行科目憑證記賬9 查詢銀行日記賬（不包含未記賬憑證）10 期初對賬情況錄入l 單位日記賬情況l 銀行對賬單情況11 本期銀行對賬單處理a) 導(dǎo)入本期銀行對賬單b) 錄入本期銀行對賬單12 銀行對賬13 查詢以下內(nèi)容l 長期未達賬項l 對賬勾對情況l 銀行存款余額調(diào)節(jié)表14 核銷已達賬項第三節(jié) 項目測試法（面測試法） 對被測試項目，檢查系統(tǒng)提供的公用功能進行測試。比如功能權(quán)限、數(shù)據(jù)權(quán)限、并發(fā)測試、互斥測試、預(yù)警、審批流、單據(jù)格式、單據(jù)編號、自定義項、UFO函數(shù)等注意事項：1. 對任何一個產(chǎn)品而言，凡是涉及到得測試項目必須全面測試。2. 注意平臺公共部分改動對本產(chǎn)品的影響3. 針對每一個測試項目都要有對應(yīng)的測試方案舉例：單據(jù)編號測試方案l 完全手工編號測試：測試特殊字符、極限、重號、單據(jù)查詢中錄入手工編號l 手工改動，重號時自動重?。簻y試前綴（測試要窮舉）、規(guī)則、重號、單據(jù)查詢中錄入l 所有單據(jù)均要測到l 編號設(shè)置測試方案l 對照表測試方案l 流水號測試方案在以上三個測試方案中要體現(xiàn)以下內(nèi)容：1. 特殊字符2. 編號極限長度3. 重號4. 前綴各種組合5. 前綴與規(guī)則各種組合6. 日期情況下考慮特殊日期、閏年、閏月7. 單據(jù)修改保存后編號不能改變應(yīng)收款管理單據(jù)名稱完全手工編號手工改動,重號時自動重取按收發(fā)標志流水使用前綴其他應(yīng)收單付款單收款單第四節(jié) 參考測試法參考測試就是依據(jù)已經(jīng)發(fā)生的測試活動結(jié)果，作為當前測試的依據(jù)。以此發(fā)現(xiàn)新的產(chǎn)品問題，一方面能過拓展測試思路，另外也可以檢查當前產(chǎn)品問題是否還存在。有三種情況可以作為測試依據(jù)，它們是：（1）支持問題支持問題反映的是當前產(chǎn)品在不同版本中遺留的問題，檢查當前版本是否還存在。因為同一產(chǎn)品進過多人開發(fā)和測試，每個人的開發(fā)思路與測試思路存在很大差異，同時對不同客戶的使用也存在很大差異，完全測試全面，幾乎是不可能的事情。作為測試工作，只能最大限度地降低產(chǎn)品問題。所以認真分析支持問題，并積累分類問題是完全必要的。在支持問題分析上，重點分析用戶的應(yīng)用場景，能夠分析出客戶的使用規(guī)律。（2）他人測試記錄分析他人測試記錄，主要分析他人的測試思路，尤其是數(shù)據(jù)錯誤和控制錯誤。因為每個人的測試結(jié)果都是該人對產(chǎn)品的理解深度的體現(xiàn)，產(chǎn)品理解越深。（3）自己以前測試記錄分析自己測試的問題，檢查測試的不足，看一下還有哪些沒有測試到?？匆幌伦约旱氖菃栴}的種類，是否還只停留在表面問題上。第五節(jié) 高危模塊測試法任何一個軟件產(chǎn)品，影響它的質(zhì)量因素有很多，其中最重要的是程序員能力。程序員的能力體現(xiàn)在兩個方面，其一是編程能力；其二是業(yè)務(wù)知識能力。人無完人，為此必然在產(chǎn)品的某些方面存在更多的問題。所以在分析產(chǎn)品高危模塊時，除去分析問題的集中區(qū)以外，還要分析人的因素，便于測試策略的決定。通過分析一個產(chǎn)品的所有問題，從數(shù)量方面統(tǒng)計出該產(chǎn)品問題發(fā)生的位置。檢查測試方案是否有遺漏，重點關(guān)注，加強測試。在整個測試周期中，始終圍繞高威模塊進行測試，確保整體產(chǎn)品的穩(wěn)定。分析產(chǎn)品問題性質(zhì)，檢查控制問題有多少，可以看出程序員對產(chǎn)品內(nèi)容邏輯關(guān)系的掌握程度；檢查數(shù)據(jù)問題多少，可以看出程序員對產(chǎn)品算法的掌握程度；檢查其他問題多少，可以看出程序員的心細程度。 高危模塊的分析就是要由針對性地進行測試，彌補程序員的能力不足，使產(chǎn)品達到穩(wěn)定狀態(tài)，使客戶用著放心。第六節(jié) 業(yè)務(wù)模型測試法對于一個重要的軟件項目，尤其是版本不斷更新時，建立業(yè)務(wù)模型進行測試是十分必要的，這也是大多數(shù)應(yīng)用軟件非常關(guān)注的問題。由于建立業(yè)務(wù)模型非常困難，造成許多企業(yè)望而卻步。首先明確一點，這是一件一勞永逸的事情。下面就建立業(yè)務(wù)模型進行分析。概念業(yè)務(wù)規(guī)則：業(yè)務(wù)結(jié)構(gòu)和業(yè)務(wù)行為的約束。業(yè)務(wù)場景：從不同維度對業(yè)務(wù)的描述業(yè)務(wù)流程：業(yè)務(wù)規(guī)則與業(yè)務(wù)場景的結(jié)合點。這些點串聯(lián)起來，形成業(yè)務(wù)流程。應(yīng)用首先要建立業(yè)務(wù)模型，該業(yè)務(wù)模型與軟件產(chǎn)品相匹配?？梢赃@樣理解，業(yè)務(wù)模型是大樓圖紙，軟件產(chǎn)品是大樓實體。圖紙設(shè)計的質(zhì)量好壞直接影響大樓的質(zhì)量。軟件測試就好比工程監(jiān)理人員，在建筑施工過程中，依據(jù)設(shè)計圖紙，對施工質(zhì)量進行監(jiān)控。有了上面的比喻，在分析業(yè)務(wù)模型測試法時就容易多了。步驟第四章 測試階段設(shè)計理論上講測試階段的劃分應(yīng)該是如下次序：準備、單元、聯(lián)調(diào)、集成、驗收、用戶測試、發(fā)版測試，但實際工作中由于多種因素的影響，這個標準次序隨時會被打破，并且已被歷版產(chǎn)品發(fā)版所證明。鑒于此種情況，測試階段和各測試階段所測試的內(nèi)容就有必要認真設(shè)計。單元、聯(lián)調(diào)兩階段目前在各測試組內(nèi)完成，其余各階段由測試部組織各測試組完成。優(yōu)化各測試階段的內(nèi)容會提高測試效率，使產(chǎn)品及早穩(wěn)定。準備階段目的為某軟件項目啟動做準備，主要包括資源準備、相關(guān)文檔準備階段特征（1） 準備越充分，項目實施過程越順利。（2） 培訓(xùn)、文檔編寫、審核、評審、考試等活動較多（3） 招聘新人較多人員活動測試人員步驟（1） 閱讀、溝通、掌握產(chǎn)品定義與需求（2） 按照標準格式編寫測試要點與測試用例（3） 評審測試要點與測試用例要點（1） 測試要點與測試用例分為：單元和聯(lián)調(diào)兩類（2） 單元類：以本版新增和變化為主。（3） 聯(lián)調(diào)類：以產(chǎn)品核心功能、接口、流程為主。（4） 尤其注意相關(guān)接口產(chǎn)品變化和平臺變化，必須體現(xiàn)在要點和用例中。測試經(jīng)理步驟（1） 安排測試人員閱讀、溝通、掌握產(chǎn)品定義需求（2） 組織編寫、評審單元與聯(lián)調(diào)測試用例（3） 制定單元與聯(lián)調(diào)測試計劃（依據(jù)測試設(shè)計與新增用例）要點（1） 用例能夠確保被測試能容的全面性與正確性（2） 測試資源能力能夠保證項目的順利實施（3） 所有活動的過程控制符合公司研發(fā)規(guī)范工作內(nèi)容當某個項目開始啟動以后，做為測試部分要進行以下準備工作（1）確定測試內(nèi)容（2）確定測試資源（3）編寫、評審測試計劃（4）編寫、評審測試方案（5）編寫、評審測試用例（6）測試、開發(fā)人員培訓(xùn)：業(yè)務(wù)知識與測試知識注意事項（1） 準備不充分（2） 測試資源考慮不周（3） 人員變動頻繁（4） 資源分配不合理（5） 所有活動控制不嚴，應(yīng)付了事。測試設(shè)計步驟（1） 依據(jù)本版新增內(nèi)容，為單元、聯(lián)調(diào)、集成三階段提供詳細測試要點及用例（2） 主要設(shè)計：選項、功能、算法、流程、接口、年結(jié)、測試項目、應(yīng)用場景等要點（1） 設(shè)計要保證全面性，不能有遺漏。（2） 便于測試人員執(zhí)行操作（3） 測試設(shè)計最小化：無論是要點還是用例，在設(shè)計時要堅持小、精、準的原則，盡可能避免大而全。（4） 測試設(shè)計文檔與產(chǎn)品開發(fā)同步變更，雖然目前我們也有需求變更，測試用例變更等開發(fā)制度要求，但是在此強調(diào)，是因為我們的工作由許多不盡人意的地方。如果測試要點與測試用例不能與產(chǎn)品開發(fā)同步，就不能保證產(chǎn)品完整測試。舉例：A功能對應(yīng)A1測試用例，產(chǎn)品開發(fā)一段時間以后，A功能變成了A+功能，這時A1測試用例應(yīng)該變成A1+測試用例才對。場景測試設(shè)計目的（1）減少測試盲目性，有重點進行測試。（2）整理、分析用戶數(shù)據(jù)情況，總結(jié)用戶使用規(guī)律。（3）模擬用戶測試設(shè)計要點（1） 操作系統(tǒng)、數(shù)據(jù)庫、IE版本（2） IT部署、產(chǎn)品啟用（3） 功能權(quán)限分布（4） 數(shù)據(jù)權(quán)限分布（5） 對用戶數(shù)據(jù)進行分類（按業(yè)務(wù)范圍、按數(shù)據(jù)量大?。?，按業(yè)務(wù)測試功能、按數(shù)據(jù)量測效率。單元階段目的最小功能單元實現(xiàn)正確，滿足產(chǎn)品定義、需求、開發(fā)設(shè)計、測試設(shè)計要求。本階段主要以單產(chǎn)品測試為主，重點測試本版變化內(nèi)容。階段特征（1）因各開發(fā)進度不一致，開發(fā)次序會有不合理現(xiàn)象。尤其是平臺進度有時會滯后業(yè)務(wù)組情況，造成結(jié)果是其他開發(fā)組無法進行開發(fā)，測試就跟談不上了。（2）安裝盤此時一般沒有出來，或比較晚。可此時業(yè)務(wù)組已經(jīng)完成部分代碼。（3）此階段時間相對聯(lián)調(diào)階段要長。（3）建議：A.開發(fā)及時調(diào)整開發(fā)次序B.安裝盤及早完成C.不涉及接口與相關(guān)影響的先測試。D.隨時了解相關(guān)變化與進度人員活動測試人員（1） 建立測試環(huán)境。在安裝盤沒有出來前以新建賬套為主。（2） 替換文件測試新增內(nèi)容（3） 執(zhí)行任務(wù)計劃安排（4） 分析當天結(jié)果測試經(jīng)理（1） 隨時掌握各產(chǎn)品進度、與問題狀況，監(jiān)督代碼質(zhì)量。（2） 編制、調(diào)整測試人員的任務(wù)計劃（3） 隨時關(guān)注其他業(yè)務(wù)組產(chǎn)品（包括平臺）對本業(yè)務(wù)組的影響。（4） 隨時向部門經(jīng)理反饋開發(fā)次序狀態(tài)與代碼質(zhì)量情況測試內(nèi)容（1） 本版新增內(nèi)容（2） 測試設(shè)計提供的內(nèi)容注意事項（1） 在確認平臺、相關(guān)產(chǎn)品無影響下，測試設(shè)計提供的內(nèi)容提前測試。（2） 產(chǎn)品本事改動影響相關(guān)內(nèi)容測試人員必須向開發(fā)了解清楚（3） 產(chǎn)品安裝盤出來后，檢查升級腳本是否體現(xiàn)在安裝盤中。如果有，就開始使用用戶數(shù)據(jù)升級測試。聯(lián)調(diào)階段目的（1） 產(chǎn)品內(nèi)部最小功能單元之間數(shù)據(jù)傳輸或控制正確（2） 產(chǎn)品間最小功能單元之間數(shù)據(jù)傳輸或控制正確本階段主要以小集成測試為主，啟用關(guān)聯(lián)產(chǎn)品，重點在接口、流程測試、應(yīng)用場景測試。在場景測試中完成接口、流程測試。在這個階段不在是以本版變化為主，而是強調(diào)產(chǎn)品的整體功能穩(wěn)定性、效率提升性。（3）本階段是集成階段的重要保證，聯(lián)調(diào)做的好與壞直接影響集成測試的效果。階段特征（1） 各產(chǎn)品因改動范圍不同，進度快慢不同，不會同時進入聯(lián)調(diào)狀態(tài)，而且不能人為控制。（2） 此時安裝盤已經(jīng)進入穩(wěn)定期，注意相關(guān)影響產(chǎn)品進入聯(lián)調(diào)情況。（3） 相關(guān)產(chǎn)品接口、平臺影響測試進入重點區(qū)域（4） 該階段測試以小集成測試為主。（5） 在功能穩(wěn)定、接口穩(wěn)定情況下進行全面測試，以備提交集成測試人員活動測試人員（1） 將具有相關(guān)接口的產(chǎn)品組織在一起，進行小集成測試。以前是單兵作戰(zhàn)，相關(guān)產(chǎn)品接口數(shù)據(jù)考慮簡單。這樣做風(fēng)險相當大，相當于復(fù)雜接口變化全部轉(zhuǎn)移到集成階段測試去了。（2） 使用安裝盤進行測試（3） 執(zhí)行任務(wù)計劃安排（4） 分析當天結(jié)果測試經(jīng)理（1） 關(guān)注進入聯(lián)調(diào)狀態(tài)產(chǎn)品的先后次序（2） 測試資源要全力保障（3） 任務(wù)安排以全面新、穩(wěn)定性為主（4） 將風(fēng)險盡最大可能控制在聯(lián)調(diào)階段測試內(nèi)容（1） 測試新功能（2） 測試產(chǎn)品內(nèi)部接口（3） 測試產(chǎn)品間接口（4） 測試平臺影響（5） 測試測試項目注意事項（1） 測試的全面性、性能的穩(wěn)定性是重點（2） 文檔齊全，尤其是各類報告。（3） 效率單獨測試，越早越好集成階段目的（1） 檢查產(chǎn)品各組成部分，在不同IT部署情況下，整體運行情況。（2） 在新建和用戶數(shù)據(jù)基礎(chǔ)上，核心功能、流程、接口、年結(jié)、效率在此階段進行全面驗證。（3） 所有測試項目得到驗證（4） 所有主要舊版本升級到當前版本，升級數(shù)據(jù)得到驗證。（5） 并發(fā)使用系統(tǒng)每一部分功能，檢查系統(tǒng)功能互容性。（6） 依據(jù)效率測試設(shè)計內(nèi)容進行效率測試階段特征（1） 此階段工作是以測試部任務(wù)安排為中心，具體何時開始集成測試完全由測試部決定。一般是大部分產(chǎn)品達到集成狀態(tài)以后，就開始進行集成了。（2） 測試方案由測試部統(tǒng)一編寫（3） 測試計劃由測試部統(tǒng)一制定（4） 測試組人員此時完全受控于測試部（5） 根據(jù)需要可以將測試資源進行合理分配（集成內(nèi)人員、集成外人員）（6） 此階段工作的好壞，完全取決于此階段的任務(wù)計劃安排和執(zhí)行力度人員活動測試人員（1） 按照測試部下發(fā)的測試任務(wù)在規(guī)定的時間內(nèi)進行測試。任務(wù)設(shè)計的好壞直接影響測試效果。（2） 目前狀態(tài)：任務(wù)設(shè)計太粗線條了，測試人員很難深入測試，月結(jié)和年結(jié)基本上是每套集成賬檢查重點。在這過程中測試痕跡無法分析。人員座位分散，測試經(jīng)理監(jiān)控自己人員，但參與控制的不多。（3） 建議：任務(wù)由專人進行設(shè)計和分配。每套賬的任務(wù)執(zhí)行要執(zhí)行監(jiān)督和分析。目的是了解測試任務(wù)執(zhí)行情況（覆蓋范圍、執(zhí)行深度）測試經(jīng)理（1） 參與集成測試方案編寫與評審（2） 集成問題分析（3） 進行測試進度控制（4） 負責(zé)本領(lǐng)域產(chǎn)品流程和接口測試（5） 監(jiān)督測試人員任務(wù)執(zhí)行測試內(nèi)容（1） 老版升級測試，檢查當前版本升級腳本是否正確。特點是升級樣本要足夠多，以避免本版新增功能對數(shù)據(jù)庫結(jié)構(gòu)的影響，從而造成用戶無法進行產(chǎn)品部分功能。升級樣本數(shù)量要根據(jù)客戶群多少來確定，目前沒有合理的進行設(shè)計。（2） 每套集成賬具體測試內(nèi)容在集成測試之前就已經(jīng)編寫、評審?fù)瓿?。測試執(zhí)行階段，由賬套測試負責(zé)人編寫測試計劃、由各測試經(jīng)理進行測試任務(wù)分配。（3） 測試人員依據(jù)測試任務(wù)進行測試。目前存在的問題：（1） 用戶場景測試深度不夠，原因是分配任務(wù)較多，準備數(shù)據(jù)時間長，每一套集成賬測試時間較短，新人多，有經(jīng)驗的人少。反應(yīng)在測試問題上是：表面問題較多，深層的接口問題，數(shù)據(jù)問題較少。（2） 產(chǎn)品間測試配合不充分，測試人員對相關(guān)產(chǎn)品了解只是基本功能，產(chǎn)品應(yīng)用場景了解很少，致使深層次應(yīng)用問題很難挖掘。（3） 測試項目驗證比較分散，沒有集中驗證，完全可以指定某一個人完成的項目就不要動員全部人員參加。1.1.1 業(yè)務(wù)規(guī)則依據(jù)業(yè)務(wù)規(guī)則組織(BRG，BusinessRulesGroup)定義：“業(yè)務(wù)規(guī)則是支持企業(yè)決策，影響或控制企業(yè)業(yè)務(wù)行為的指示”。業(yè)務(wù)規(guī)則是對業(yè)務(wù)結(jié)構(gòu)和影響業(yè)務(wù)行為的一種約束，它說明在指定情況下必須做什么和不做什么。業(yè)務(wù)規(guī)則具有完整性與一致性等特性。完整性是指單個規(guī)則作為一個整體發(fā)揮作用，而一致性是指在業(yè)務(wù)活動中規(guī)則自身不發(fā)生變化時，相同輸入條件導(dǎo)致相同輸出結(jié)果。業(yè)務(wù)規(guī)則的這些特性為基于業(yè)務(wù)模型生成測試用例提供必要條件。1.1.2 場景場景是由一系列相關(guān)狀態(tài)組成。它描述軟件系統(tǒng)的運行狀態(tài)，反映軟件功能的任務(wù)剖面。場景最小單位是原子場景。這些原子場景的輸入與輸出能從系統(tǒng)外部環(huán)境直接施加和截取。原子場景是不可再分且獨立可測的。多個具有緊密關(guān)系的原子場景能組合成子場景。子場景又可以組合成為代表了被測系統(tǒng)功能包的復(fù)合場景，它反映了系統(tǒng)更高層面功能集合。場景可以抽象表示為一個五元組：S=(IV，OV，PC，P，F(xiàn))，其中，IV、OV、PC、P、F分別代表了場景的輸入集、輸出集、前提條件、優(yōu)先級與場景功能描述。1.1.3 業(yè)務(wù)流程業(yè)務(wù)流程是業(yè)務(wù)模型中業(yè)務(wù)規(guī)則與場景的結(jié)合點。業(yè)務(wù)流程是一組將輸入依據(jù)業(yè)務(wù)規(guī)則轉(zhuǎn)化為輸出的相互關(guān)聯(lián)或相互作用的活動。業(yè)務(wù)模型使用場景描述業(yè)務(wù)流程，說明軟件系統(tǒng)如何解決用戶業(yè)務(wù)問題。業(yè)務(wù)流程是從用戶角度對系統(tǒng)的動態(tài)描述。場景是從開發(fā)人員角度對系統(tǒng)靜態(tài)分析，使用靜態(tài)場景描述動態(tài)業(yè)務(wù)流程，必須補充場景轉(zhuǎn)移關(guān)系。場景轉(zhuǎn)移關(guān)系包括“順序”、“循環(huán)”、“判斷”與“并發(fā)”。1.2 基于業(yè)務(wù)模型的軟件測試過程軟件測試過程一般有計劃、設(shè)計與開發(fā)、實施、評估4個階段，業(yè)務(wù)模型可以完全融合到軟件測試過程中，并貫穿整個軟件測試過程。1.3 測試用例的生成在業(yè)務(wù)模型的業(yè)務(wù)流程與測試用例集的測試用例之間建立聯(lián)系，根據(jù)業(yè)務(wù)流程要素確定測試用例要素：根據(jù)業(yè)務(wù)流程標識確定測試用例標識符。根據(jù)業(yè)務(wù)流程步驟確定測試用例步驟。根據(jù)業(yè)務(wù)流程關(guān)系場景的前提條件確定測試用例前提條件。根據(jù)業(yè)務(wù)流程關(guān)系場景的輸入集合確定測試用例輸入集合。根據(jù)業(yè)務(wù)流程關(guān)系場景的輸出集合確定測試用例輸出集合。業(yè)務(wù)流程一般包含多個場景，場景之間轉(zhuǎn)移關(guān)系也較復(fù)雜，這些復(fù)雜性不利于測試用例生成。因此，在生成測試用例前，需要根據(jù)簡化原則簡化業(yè)務(wù)流程的描述與場景轉(zhuǎn)移關(guān)系。業(yè)務(wù)流程簡化原則包括：原則1：子圖分解原則。將一個業(yè)務(wù)流程分解為若干個子流程，分解前后的流程是等價的。原則2：循環(huán)活動簡化原則。對于可多次重復(fù)的活動，規(guī)定活動重復(fù)的最大次數(shù)，以避免發(fā)生死循環(huán)。原則3