項目測試工作說明

1、項目測試工作說明項目測試流程項目立項項目立項制訂測試計劃制訂測試計劃 軟件開發(fā)設(shè)計文檔軟件需求文檔測試用例設(shè)計測試用例設(shè)計單元測試單元測試集成測試集成測試系統(tǒng)測試系統(tǒng)測試測試執(zhí)行測試執(zhí)行撰寫測試報告撰寫測試報告測試結(jié)果整理分析研發(fā)經(jīng)理審查研發(fā)經(jīng)理審查遞交報告系統(tǒng)達不到上線要求測試退出測試退出符合上線要求項目現(xiàn)狀需求不清晰：由于客戶對信息化系統(tǒng)接觸較少，無法提供詳細明確的業(yè)務(wù)需求，致使我們的需求人員對用戶的需求無法進行鑒別、綜合和建模，清除用戶需求的模糊性、歧義性和不一致性，分析系統(tǒng)的數(shù)據(jù)要求，為原始問題及目標軟件建立邏輯模型。軟件設(shè)計不充分：依據(jù)需求文檔，開發(fā)要將實際業(yè)務(wù)需求轉(zhuǎn)化為軟件功能需求

2、，并出具詳細的軟件規(guī)格說明書。目前開發(fā)只提供差異化文檔并未出具詳細的軟件功能設(shè)計說明文檔，對功能實現(xiàn)沒有一個完整開發(fā)業(yè)務(wù)邏輯說明功能實現(xiàn)不到位：可能由于開發(fā)周短或者公司缺乏技術(shù)底蘊或者使用某種框架技術(shù)的限制無法將功能做到完全滿足功能需求（包括隱含的）或者易操作和人性化方面做的不足系統(tǒng)代碼較脆弱：由于代碼設(shè)計沒有考慮周全以及缺乏異常處理機制，經(jīng)常遇到報黃頁，或者頁面緩存太過嚴重等問題經(jīng)常出現(xiàn)系統(tǒng)優(yōu)化不徹底：隨著項目的越來越多，一些老問題一直沒有修改，一些功能需要重構(gòu)一直沒有重構(gòu)。用戶業(yè)務(wù)差異化太大：同一個業(yè)務(wù)不同的客戶不同的功能需求，我們的系統(tǒng)配置項越來越多。如何做好我們的測試工作我是一個業(yè)務(wù)專

3、家：對目前的系統(tǒng)業(yè)務(wù)要熟練掌握，這個功能是干什么的？該功能有什么樣的業(yè)務(wù)關(guān)聯(lián)？這個操作會引發(fā)系統(tǒng)怎樣的影響？這個功能有幾種配置？每個配置都是基于什么樣的功能場景？為什么有這樣的功能操作邏輯？它的優(yōu)勢是什么？等等我是一個客戶：我的角色就是一個客戶，我要體驗系統(tǒng)是不是很人性化，功能實現(xiàn)是不是符合我的要求，界面是不是一看就知道我得到了什么信息，如何去操作？一些重要操作是不是有提醒功能避免誤操作或者提下一步操作提示？我是一個邏輯縝密的人：這個功能實現(xiàn)關(guān)聯(lián)多個功能，他們是否能夠協(xié)調(diào)正常工作？這個業(yè)務(wù)流程有多少個環(huán)節(jié)每個環(huán)節(jié)是否能夠讀取正確的數(shù)據(jù)？業(yè)務(wù)功能變更對前后關(guān)聯(lián)的業(yè)務(wù)影響有多大？我是一個優(yōu)化專家：

4、功能實現(xiàn)是不是存在可以優(yōu)化的地方，功能實現(xiàn)是否有漏洞存在影響用戶的正常使用?功能實現(xiàn)是否存在不足可以，那些功能是冗余無用的？哪些功能尚未使用？我是一個追究思源的人：為什么功能這樣實現(xiàn)，它的業(yè)務(wù)需求是什么？它的功能目標是什么？在一個什么樣的業(yè)務(wù)場景下進行使用？它的使用對象是那些人，業(yè)務(wù)關(guān)聯(lián)都那些人？測試計劃俗話說：凡事預(yù)則立，不預(yù)則廢！不論做什么事，事先有準備，就能得到成功，不然就會失敗。項目測試在實施前就要制訂測試計劃。測試計劃Testing plan，描述了要進行的測試活動的范圍、方法、資源和進度的文檔。它確定測試項、被測特性、測試任務(wù)、誰執(zhí)行任務(wù)、各種可能的風(fēng)險。測試計劃可以有效預(yù)防計劃的

5、風(fēng)險，保障計劃的順利實施。測試計劃編寫6要素1）Why：為什么要進行這些測試：【編寫目的】2) What：測試哪些方面，不同階段的工作內(nèi)容：【測試范圍】、【測試目標】、【質(zhì)量目標】3) When：測試不同階段的起止時間：【測試進度】4) Where：相應(yīng)文檔，缺陷的存放位置，測試環(huán)境等；【參考文檔】、【測試交付文檔】、【軟件資源】、【硬件資源 】5) Who：項目有關(guān)人員組成，安排哪些測試人員進行測試 【人力資源】6) How：如何去做，使用哪些測試工具以及測試方法進行測試。【測試技術(shù)】、【測試策略】、【風(fēng)險和約束】、【測試退出標準 】測試執(zhí)行測試執(zhí)行的內(nèi)容包括功能測試、集成測試、系統(tǒng)測試（回

6、歸測試）。功能測試：即某一單個功能的測試。功能測試的要點如下： 功能實現(xiàn)滿足用戶需求（功能實現(xiàn)與需求及設(shè)計相一致） 功能最優(yōu)化（操作便捷不復(fù)雜、界面友好好理解、信息提示溫馨易懂） 功能健壯性（如格式校驗、異常處理機制、緩存機制、必填項校驗） 功能權(quán)限（數(shù)據(jù)權(quán)限、操作權(quán)限） 功能關(guān)聯(lián)（輸入數(shù)據(jù)來源、輸入數(shù)據(jù)去向） 功能操作邏輯（增刪改查的操作順序和操作條件）集成測試：多個功能融合在一起進行的測試.一般用于業(yè)務(wù)流程測試和業(yè)務(wù)關(guān)聯(lián)測試: 上一個功能的輸出結(jié)果是否可以作為本次功能的輸入 上一個功能的輸入結(jié)果是否可以作為本次功能操作可操作數(shù)據(jù)項之一 最后一個功能的輸出結(jié)果是否影響了上一個或上上一個功能的

7、操作系統(tǒng)測試：系統(tǒng)的全部功能整合在一起進行的測試，其目的： 校驗功能的正確性、業(yè)務(wù)流程操作的正確性、數(shù)據(jù)流轉(zhuǎn)的正確性 功能測試交付文檔功能測試交付單是測試人員對某一個功能測試完畢之后需要交付的一個文檔。該文檔描述了測試人員測試一個功能的全部過程，如業(yè)務(wù)了解度、測試點、業(yè)務(wù)邏輯、業(yè)務(wù)關(guān)聯(lián)性、業(yè)務(wù)的待優(yōu)化建議等內(nèi)容。功能描述：對被測試功能進行概括介紹。功能操作邏輯：通過操作邏輯圖反映該功能的增刪改查及其他操作功能的順序及操作條件功能關(guān)聯(lián)業(yè)務(wù)：說明被測試功能相關(guān)聯(lián)的業(yè)務(wù)功能測試結(jié)果：詳細描述被測試功能的測試功能點及測試結(jié)果關(guān)聯(lián)業(yè)務(wù)測試結(jié)果：詳細描述被測試功能關(guān)聯(lián)業(yè)務(wù)關(guān)聯(lián)的正確性功能優(yōu)化建議：對功能實

8、現(xiàn)提出優(yōu)化建議編寫該文檔的優(yōu)勢：編寫該文檔的優(yōu)勢：規(guī)范測試人員的測試工作從文檔中檢測測試人員的測試是否完整將測試人員忽略的測試點找出來保證測試覆蓋度的最大化檢測測試人員對該功能的認知度功能測試過程中我們應(yīng)該做的在功能測試過程中我們會遇到很多問題。如需求不明確、開發(fā)實現(xiàn)功能與需求或設(shè)計不相符等等，那么我們該如何解決呢？需求不明確需求不明確：首先我們要找到需求人員了解該業(yè)務(wù)需求，其次要求需求人員在需求文檔中補充該需求的詳細內(nèi)容或者要求需求人員通過郵件的形式告知測試以及開發(fā)人員該需求的詳細內(nèi)容功能實現(xiàn)與需求設(shè)計不一致功能實現(xiàn)與需求設(shè)計不一致：首先找到功能實現(xiàn)的開發(fā)人員確認不一致的原因，如果是經(jīng)上面領(lǐng)

9、導(dǎo)確認過的則需要找到項目負責(zé)人進行證實，并發(fā)送郵件進行告知變更原因及變更結(jié)果；如果是開發(fā)人員私自變更，可拒絕測試并通過發(fā)郵件告知項目負責(zé)人。隱含功能開發(fā)測試理解有誤差隱含功能開發(fā)測試理解有誤差：有些隱含功能開發(fā)實現(xiàn)與測試理解不一致，則可通過與開發(fā)人員溝通，若雙方堅持已見且無認可的妥協(xié)方案，同需求及項目負責(zé)人進行協(xié)商，將最終的方案通過郵件進行告知功能優(yōu)化功能優(yōu)化：由于設(shè)計方案欠缺考慮導(dǎo)致實現(xiàn)的功能有許多的隱患問題，如操作不簡便，頁面不美觀、沒有達到引導(dǎo)客戶操作的功效，提示信息不友好或者看不懂等，測試人員要給予優(yōu)化的建議。特殊操作缺乏提示特殊操作缺乏提示：如刪除前的確認框提示、不可回退操作的確認提

10、示、或者隱含生成其他記錄的提示等更能體現(xiàn)我們系統(tǒng)的人性化功能交換測試功能交換測試：我們每個人都有自己的優(yōu)勢，是別人無法比擬的，有的人注重邏輯，有的人注重細節(jié)，有的人傾向于界面，一個功能的完整的測試不是一個人能完成的，功能交換測試能夠最大程度的提高測試質(zhì)量和測試覆蓋度功能測試過程中我們必須要注意的一個系統(tǒng)有很多業(yè)務(wù)功能要進行測試，一個系統(tǒng)的功能也不是由一個人來完成測試工作的，因此，一個系統(tǒng)功能的測試由多個人進行分工完成的，在這樣的情況下，有些測試人員可能只會測試自己負責(zé)的功能，不會關(guān)注別人測試的功能，這種測試態(tài)度是不正確的，測試人員和開發(fā)人員不一樣，只知道自己負責(zé)開發(fā)的業(yè)務(wù)即可，熟悉系統(tǒng)業(yè)務(wù)是測

11、試人員的基本技能，不是局部而是全部。一個測試人員具備了掌握全系統(tǒng)的業(yè)務(wù)你才可以做到:1)新功能設(shè)計上可以評估設(shè)計是否考慮周全2)清晰的知道哪些關(guān)聯(lián)業(yè)務(wù)需要測試3)在新功能設(shè)計上給予指導(dǎo)性的建議4)你有資格成為一個業(yè)務(wù)專家5) 提高測試覆蓋度確保測試質(zhì)量6)在整體業(yè)務(wù)把握的基礎(chǔ)上提升測試思維的高度和測試意識7)分析定位系統(tǒng)Bug是什么原因造成的8）系統(tǒng)變更帶來的影響和風(fēng)險評估9）培養(yǎng)縝密的邏輯思維，做到舉一反三，化整為零，聚零為整10）從軟件業(yè)務(wù)領(lǐng)悟?qū)嶋H業(yè)務(wù)，實際業(yè)務(wù)轉(zhuǎn)化軟件業(yè)務(wù)缺陷跟蹤管理流程發(fā)現(xiàn)缺陷發(fā)現(xiàn)缺陷確認缺陷確認缺陷提交缺陷分析缺陷分析缺陷測試主管測試人員提交缺陷后續(xù)修改修改缺陷修改缺

12、陷缺陷存檔缺陷存檔項目經(jīng)理分配缺陷開發(fā)人員驗證缺陷驗證缺陷測試人員關(guān)閉缺陷關(guān)閉缺陷驗證通過驗證不通過后續(xù)缺陷修改缺陷跟蹤我們應(yīng)該做的缺陷跟蹤是缺陷發(fā)現(xiàn)、提交、分配、修正、校驗這樣的一個過程。缺陷跟蹤可以衡量一個測試人員的測試力度，也是保證軟件質(zhì)量一個重要環(huán)節(jié)。通過缺陷管理可以反應(yīng)開發(fā)的質(zhì)量，為軟件上線提供依據(jù)。缺陷跟蹤過程中我們應(yīng)該做的如下：發(fā)現(xiàn)缺陷，能夠定位缺陷的級別，缺陷修改的緩重輕急發(fā)現(xiàn)缺陷，能夠分析缺陷產(chǎn)生的原因，方便開發(fā)修改缺陷定位問題所在發(fā)現(xiàn)缺陷，缺陷描述要簡潔易懂，盡量不要給開發(fā)或他人造成誤解或者不解提交缺陷，要分類匯總生成缺陷反饋文檔提交缺陷，將缺陷反饋文檔放置指定位置并通過郵

13、件告知測試主管或測試負責(zé)人缺陷確認，通過缺陷描述確認該缺陷是否為真正的缺陷缺陷確認，要通過缺陷描述操作系統(tǒng)重現(xiàn)缺陷進行確認缺陷確認，確認該缺陷的級別，輕重緩解是否得當(dāng)缺陷驗證，確認開發(fā)修復(fù)缺陷是否正確缺陷驗證，確認開發(fā)修復(fù)缺陷的同時是否產(chǎn)生了新的缺陷缺陷驗證，驗證通過的缺陷要及時修改缺陷的狀態(tài)，必要時添加驗證備注說明缺陷驗證，將驗證不通過的缺陷進行缺陷狀態(tài)的修改，并通過郵件方式告知開發(fā)人員進行修改，并監(jiān)督直至驗證通過將未修復(fù)延期修復(fù)的缺陷進行整理一個單獨的文檔進行存放并通過郵件告知相關(guān)人員缺陷跟蹤我們必須要注意的發(fā)現(xiàn)了缺陷，開發(fā)不認可，或者開發(fā)通過非正常手段來解決問題等等情況我們?nèi)绾蝸響?yīng)對來減

14、緩測試和開發(fā)的這種敵對狀態(tài)和通過什么樣的方式來解決問題。開發(fā)不認可這是個缺陷開發(fā)不認可這是個缺陷：我們可以給開發(fā)講為什么是缺陷，有什么樣的嚴重后患來證明就是個缺陷，如果開發(fā)還是不認可，我們可上訴至測試主管和項目經(jīng)理進行最后的確認，如果是缺陷開發(fā)必須進行修改，如果認為不是缺陷或者可延期修改，必須在缺陷反饋文檔增加備注說明，并通過郵件的方式告知相關(guān)人員開發(fā)通過非正常手段修復(fù)缺陷開發(fā)通過非正常手段修復(fù)缺陷:開發(fā)不是修改代碼修復(fù)缺陷，而是隱藏代碼掩蓋了缺陷的重現(xiàn)操作等非正常手段間接修復(fù)缺陷，我們將此情況上訴至測試主管和項目經(jīng)理，通過協(xié)調(diào)給予最終的解決方案，通過郵件方式將解決方案告知相關(guān)人按照方案開發(fā)進

15、行修改，測試進行校驗，并在缺陷修復(fù)備注給予說明開發(fā)遲遲不修改缺陷：開發(fā)遲遲不修改缺陷：對于已經(jīng)確認并要修改的缺陷，開發(fā)遲遲不予修改，則測試人員需要時時詢問缺陷修復(fù)的時間，如果時間拖的過久需要項目經(jīng)理以郵件的方式進行告知缺陷修復(fù)的具體時間或近期不能修復(fù)的原因。開發(fā)修復(fù)缺陷出現(xiàn)后遺癥開發(fā)修復(fù)缺陷出現(xiàn)后遺癥：開發(fā)修復(fù)缺陷可能會引發(fā)新的缺陷的產(chǎn)生，因此要求我們在校驗缺陷的同時，必須校驗相關(guān)功能的其他操作是否正常。延期缺陷的追蹤延期缺陷的追蹤：有些缺陷被延期，可能由于相關(guān)方面的原因無暇顧及這些遺留缺陷而將缺陷一而再再而三的擱置最終不了了之。因此要定期的追蹤項目經(jīng)理遺留缺陷的修復(fù)工作缺陷反饋文檔缺陷追蹤管

16、理有兩種方式，通過缺陷管理工具進行管理，另外是通過缺陷文檔進行管理。無論是缺陷管理工具還是缺陷文檔，缺陷基本信息包括如下：缺陷位置缺陷位置：描述缺陷所在的功能模塊菜單頁面項目名稱項目名稱：缺陷出現(xiàn)的項目名稱項目版本項目版本：缺陷出現(xiàn)在的項目的哪個版本當(dāng)中缺陷標題缺陷標題：概括描述功能缺陷缺陷描述缺陷描述：描述缺陷產(chǎn)生的操作步驟導(dǎo)致的實際系統(tǒng)反應(yīng)與期望結(jié)果不一致缺陷級別缺陷級別：缺陷的嚴重程度（改善性、一般、嚴重、致命）缺陷優(yōu)先級缺陷優(yōu)先級：缺陷處理輕慢緩急度（有空改改、正常處理、高度重視、立即解決）提交時間提交時間：缺陷提交時間缺陷狀態(tài)缺陷狀態(tài)：已提交、已分配、待驗證、已關(guān)閉、無效提交人提交人

17、：發(fā)現(xiàn)并條件缺陷的測試人員修改人修改人：修復(fù)缺陷的開發(fā)人員修改時間修改時間：缺陷修復(fù)時間驗證人驗證人：驗證缺陷的人驗證時間驗證時間：驗證缺陷的時間備注備注：填寫缺陷從提交到驗證過程中的重要說明缺陷級別定義改善性缺陷改善性缺陷：由問題提出人對測試對象的改進意見或測試人員提出的建議、質(zhì)疑。一般缺陷一般缺陷：次要功能沒有完全實現(xiàn)但不影響使用。如提示信息不太準確，或用戶界面差，操作時間長，模塊功能部分失效等，打印內(nèi)容、格式錯誤，刪除操作未給出提示，數(shù)據(jù)庫表中有過多的空字段等嚴重缺陷嚴重缺陷：系統(tǒng)的主要功能部分喪失、數(shù)據(jù)不能保存，系統(tǒng)的次要功能完全喪失。問題局限在本模塊，導(dǎo)致模塊功能失效或異常退出。如致

18、命的錯誤聲明，程序接口錯誤，數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件致命缺陷致命缺陷：造成系統(tǒng)或應(yīng)用程序崩潰、死機、系統(tǒng)掛起，或造成數(shù)據(jù)丟失，主要功能完全喪失，導(dǎo)致本模塊以及相關(guān)模塊異常等問題。如代碼錯誤，死循環(huán)，數(shù)據(jù)庫發(fā)生死鎖、與數(shù)據(jù)庫連接錯誤或數(shù)據(jù)通訊錯誤，未考慮異常操作，功能錯誤等項目需求變更流程客戶變更需求客戶變更需求內(nèi)部變更需求內(nèi)部變更需求需求變更分析需求變更分析變更影響分析變更影響分析不變更說明書不變更說明書需求變更會議討論需求變更會議討論變更解決方案變更解決方案 變更執(zhí)行變更執(zhí)行變更存檔變更存檔需求變更說明書影響較大影響較小不變更需求變更設(shè)計說明書編碼、測試項目需求變更我

19、們應(yīng)該做的項目變更是項目開發(fā)過程中經(jīng)常遇到的不可控制的一種項目變動，項目變更管理的目的是以一種對于項目影響最小的方式改變現(xiàn)狀。作為測試人員在需求變更階段如何去做呢？了解需求變更的功能差異了解需求變更的功能差異：被變更功能的現(xiàn)有功能是什么樣子，和變更要求的差異化有多大，做到心中有數(shù)，為變更后的測試做好鋪墊分析差異化對系統(tǒng)的影響范圍分析差異化對系統(tǒng)的影響范圍：被變更功能按照變更需求變更后，相關(guān)聯(lián)的業(yè)務(wù)是否能正常使用？需要修改多少關(guān)聯(lián)業(yè)務(wù)？數(shù)據(jù)庫的老數(shù)據(jù)如何去處理？給予變更建議方案給予變更建議方案：對于系統(tǒng)測試是最熟悉的，系統(tǒng)變更的風(fēng)險和影響范圍是最清楚的，所以測試有資格有義務(wù)去提供變更的解決方案，以最小的代價來滿足變更需求。評估開發(fā)給予的解決方案是否可行評估開發(fā)給予的解決方案是否可行：測試代表用戶，客戶的需求實現(xiàn)首先要得到測試人員的認可。如果解決方案不可行要給予不可行可通過郵件將不可行的理由告知測試主管和項目經(jīng)理。準備測試方案應(yīng)對變更測試準備測試方案應(yīng)對變更測試：設(shè)計測試方案，確定測試的范圍和測試功能點，將測試范圍最大化，測試覆蓋率最大化變更測試需缺陷追蹤：同項目功能測試缺陷追蹤項目需求變更我們應(yīng)該注意的一般來說，項目需求變更大