測試指導(dǎo)手冊(cè)

文檔可能無法思考全面，請(qǐng)瀏覽后下載!文檔可能無法思考全面，請(qǐng)瀏覽后下載!17/18文檔可能無法思考全面，請(qǐng)瀏覽后下載!軟件測試指導(dǎo)手冊(cè)張寶良為了提高測試效率，保證產(chǎn)品測試質(zhì)量，從而保證產(chǎn)品開發(fā)工期與質(zhì)量，統(tǒng)一測試思想是十分必要的。本文就用友軟件測試相關(guān)內(nèi)容進(jìn)行闡述，力求給大家啟示與參考。第一章測試概念第一節(jié)測試要點(diǎn)測試要點(diǎn)是依據(jù)等價(jià)類方法（或其他方法），經(jīng)過對(duì)被測試內(nèi)容進(jìn)行分析后，以清單方式進(jìn)行描述要測試的內(nèi)容。注意事項(xiàng)：針對(duì)任何一個(gè)被測試內(nèi)容，均要考慮是否涉及系統(tǒng)提供的公用功能。測試要點(diǎn)盡可能窮舉，避免遺漏。測試要點(diǎn)給出代碼實(shí)現(xiàn)正確實(shí)現(xiàn)是什么，什么樣實(shí)現(xiàn)是錯(cuò)誤的。測試要點(diǎn)是針對(duì)最小功能單元，可以是一個(gè)功能結(jié)點(diǎn)，也可以是一個(gè)操作按鈕，但不允許多個(gè)內(nèi)容一起描述舉例：U8產(chǎn)品XXX產(chǎn)品測試要點(diǎn)測試內(nèi)容涉及要素基礎(chǔ)數(shù)據(jù)要求、算法、界面布局、多語、升級(jí)、接口、年結(jié)、打印、輸出、預(yù)覽、審批流、預(yù)警、EAI、并發(fā)、互斥、功能權(quán)限、數(shù)據(jù)權(quán)限、效率、極限序號(hào)測試要點(diǎn)預(yù)計(jì)結(jié)果第二節(jié)測試用例測試用例是指數(shù)據(jù)測試用例，針對(duì)測試要點(diǎn)，必須以數(shù)據(jù)形式才可描述清楚，作為測試要點(diǎn)的補(bǔ)充。測試要點(diǎn)不一定必須有測試數(shù)據(jù)用例，但測試數(shù)據(jù)用例必須對(duì)應(yīng)有測試要點(diǎn)。注意事項(xiàng)：測試用例一般會(huì)涉及多個(gè)功能配合。描述中要體現(xiàn)操作次序數(shù)據(jù)準(zhǔn)備考慮以下情況小數(shù)外幣表體一條記錄表體滿記錄表體滿記錄多一條數(shù)據(jù)準(zhǔn)備不要太復(fù)雜，要便于操作。如果復(fù)雜可拆開描述。第二章測試策略測試策略：針對(duì)某項(xiàng)具體任務(wù)，安排最合適的人選，采用最佳的測試方法，在規(guī)定的時(shí)間內(nèi)，保質(zhì)保量完成。策略要點(diǎn)在測試策略中，人員能力的培養(yǎng)是最重要的，是完成任務(wù)的關(guān)鍵。針對(duì)被測試對(duì)象的不同，測試策略應(yīng)有差異。測試計(jì)劃是保證被測試對(duì)象完全測試的關(guān)鍵，同時(shí)也是提高測試人員工作效率的關(guān)鍵。被測試對(duì)象在分解任務(wù)時(shí)要有主次之分測試資源安排時(shí)要有主次之分測試進(jìn)度安排要有主次之分合理設(shè)計(jì)各測試階段測試內(nèi)容，充分體現(xiàn)早期測試思想，及早穩(wěn)定產(chǎn)品。最大限度地提高測試經(jīng)理的作用（任務(wù)安排、測試設(shè)計(jì)、問題分析、產(chǎn)品把握）建立監(jiān)督、檢查機(jī)制。每個(gè)階段都要有報(bào)告產(chǎn)生，對(duì)報(bào)告要進(jìn)行詳細(xì)分析，以便掌握進(jìn)度和質(zhì)量。向過程要效益，過程不同效益不同。任務(wù)計(jì)劃任務(wù)計(jì)劃分兩類：測試經(jīng)理使用的“階段任務(wù)計(jì)劃”，測試人員使用的“每日任務(wù)計(jì)劃”XXX測試組階段任務(wù)計(jì)劃測試任務(wù)開始時(shí)間結(jié)束時(shí)間完成情況871SP（測試驗(yàn)證及Bug修改）2008-11-202008-12-19872上市后補(bǔ)?。ㄈ蝿?wù)含開發(fā)和測試時(shí)間）2008-11-202008-12-31發(fā)版時(shí)未同步的補(bǔ)丁同步2008-12-12008-12-18該計(jì)劃根據(jù)開發(fā)計(jì)劃由測試經(jīng)理編寫。它有以下類型：大版、專版、特殊補(bǔ)丁、臨時(shí)任務(wù)。定期向部門經(jīng)理反饋XXX測試員每日任務(wù)計(jì)劃測試任務(wù)日期完成情況2008-12-32008-12-42008-12-5該計(jì)劃根據(jù)階段測試任務(wù)制定，由測試經(jīng)理編寫，測試人員執(zhí)行。切不可以由測試人員編寫，理由是缺乏全面考慮，尤其是測試覆蓋度方面。測試人員每日向測試經(jīng)理反饋。工作內(nèi)容分類以是否改動(dòng)可以分為改動(dòng)部分和非改動(dòng)部分。以是否是重點(diǎn)可以分為重點(diǎn)內(nèi)容和非重點(diǎn)內(nèi)容。次序（1）改動(dòng)部分（30%資源）（2）重點(diǎn)部分（40%資源）（3）非改動(dòng)部分（10%資源）（4）全面測試（20%資源）內(nèi)容測試人員與各開發(fā)角色充分溝通編寫、評(píng)審、執(zhí)行測試要點(diǎn)及測試用例每日測試問題分析（原因、影響、補(bǔ)充測試要點(diǎn)）測試資源目前測試資源主要有三種：正式員工、外包測試人員、實(shí)習(xí)生；針對(duì)每個(gè)版本重點(diǎn)的不同在資源配備上要合理安排。1．資源分析正式人員正式員工是公司測試的核心力量。他們是經(jīng)過嚴(yán)格篩選的，大部分都具有實(shí)際工作經(jīng)驗(yàn)，工作心態(tài)比較穩(wěn)定，為此在分配任務(wù)時(shí)，核心產(chǎn)品、核心內(nèi)容要由他們來負(fù)責(zé)。外包測試人員外包測試人員是公司測試的輔助力量，他們也是經(jīng)過嚴(yán)格篩選的，大部分也都具有實(shí)際工作經(jīng)驗(yàn)，但在專業(yè)知識(shí)方面沒有正式員工那樣嚴(yán)格。他們的工作心態(tài)相對(duì)穩(wěn)定，歸屬感差一些。但是合理使用，同樣會(huì)達(dá)到正式員工的效果，甚至?xí)葌€(gè)別正式員還好。為此在分配工作任務(wù)時(shí)，擇優(yōu)考慮。實(shí)習(xí)生實(shí)習(xí)生是公司測試的邊緣力量，他們來公司的主要目的是學(xué)習(xí)軟件產(chǎn)品測試知識(shí)，相關(guān)業(yè)務(wù)知識(shí)，為自己擇業(yè)增加籌碼。錄用他們時(shí)主要考察他們的專業(yè)知識(shí)與綜合素質(zhì)，在分配工作任務(wù)時(shí)，產(chǎn)品的邊緣測試任務(wù)一般由他們來完成，表現(xiàn)優(yōu)異者可以考慮接觸一些核心內(nèi)容。2．資源培養(yǎng)培養(yǎng)測試人員的手段有很多，比如：產(chǎn)品知識(shí)培訓(xùn)、測試方法培訓(xùn)、測試技巧培訓(xùn)等。這些都是傳統(tǒng)的方法。一個(gè)測試人員由不合到合格需要很長的時(shí)間。建立業(yè)務(wù)員能力提升系統(tǒng)，可以縮短培養(yǎng)時(shí)間，這一系統(tǒng)即包括業(yè)務(wù)知識(shí)，又包括測試?yán)碚摗?．指導(dǎo)思想在軟件產(chǎn)品測試過程中，所有測試人員都要樹立正確的工作觀念，任何消極的工作態(tài)度都會(huì)影響自己的未來發(fā)展，所以，必須明白當(dāng)前的工作是在為自己工作，為自己的未來工作。為此，測試經(jīng)理除了安排測試任務(wù)外，溝通工作是重點(diǎn)。溝通包括各環(huán)節(jié)、各角色的工作內(nèi)容溝通；下屬員工思想溝通，隨時(shí)關(guān)注每個(gè)人的思想動(dòng)態(tài)，及時(shí)調(diào)整，確保每個(gè)員工全身心的進(jìn)行測試工作。測試誤區(qū)測試人員只要了解業(yè)務(wù)知識(shí)就可以了，開發(fā)知識(shí)不需要了解。測試工作很簡單，任何人都可以做，沒什么技術(shù)可言我只為找產(chǎn)品錯(cuò)誤，其他不管測試是給程序員打下手的測試人員與程序員的關(guān)系是對(duì)立的我是程序員，測試不是我的事測試很苦，很枯燥測試很難有成就感，開發(fā)還可以說哪個(gè)功能是我開發(fā)的。測試工作不受重視第三章測試方法最常規(guī)測試分黑盒測試與白盒測試，針對(duì)管理軟件而言，目前主要集中應(yīng)用的是黑盒測試。黑盒測試顧名思義就是將被測系統(tǒng)看成一個(gè)黑盒，從外界取得輸入，然后再輸出。整個(gè)測試基于需求文檔、測試文檔、產(chǎn)品幫助、支持問題，看是否能滿足文檔中的所有要求。黑盒測試要求測試者在測試時(shí)不能使用與被測系統(tǒng)內(nèi)部結(jié)構(gòu)相關(guān)的知識(shí)或經(jīng)驗(yàn)，它適用于對(duì)系統(tǒng)的功能進(jìn)行測試。

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