軟件項目測試經(jīng)驗(2)

　　測試計劃主要是進(jìn)行描述測試需求、分析制定測試計劃工作。在制定測試計劃時(shí)，經(jīng)常有人認為測試計劃是在整個(gè)項目計劃制定之后才開(kāi)始進(jìn)行測試計劃的，事實(shí)上并不是這樣的。測試計劃和項目計劃是互相影響的。舉個(gè)例子。假設項目有進(jìn)行性能測試的需求，但是測試工具又需要學(xué)習，那么我們在測試計劃中就需要預留這部分的時(shí)間，還有，測試用例的評審，也需要預留時(shí)間?；蛘?，如果某部分比較復雜，可能測試需要的時(shí)間會(huì )較多，或者需要測試的次數會(huì )比較多，那么可能要求開(kāi)發(fā)組先安排這個(gè)核心模塊的開(kāi)發(fā)，這樣需要調整開(kāi)發(fā)計劃的順序。所以，測試計劃和項目計劃是互相影響的。在測試計劃環(huán)節還包括測試需求的描述，主要是確認需求是可測試的，并將需求細化為具體的可測試點(diǎn)，保證測試設計時(shí)可以根據測試需求編寫(xiě)測試用例，而避免遺漏測試點(diǎn)。我們的測試需求需要得到業(yè)務(wù)分析人員的評審，測試計劃要得到pm的審批認可。

　　對于測試計劃，還需要說(shuō)明的是，在具體的每個(gè)測試階段工作計劃中，我們需要定義本階段測試需要進(jìn)行的次數。每一輪測試是一個(gè)完整的測試周期，按照這里介紹的測試過(guò)程進(jìn)行。通常我們是一天一輪測試，最多是兩天一輪測試。通過(guò)這種方式，減少了測試和開(kāi)發(fā)之間的空擋時(shí)間，即測試等開(kāi)發(fā)，開(kāi)發(fā)等測試。

　　肯定會(huì )有人疑問(wèn)，一個(gè)系統龐大的時(shí)候，怎么能在一兩天內完成測試呢?是的，如果系統比較大的話(huà)，確實(shí)沒(méi)法在一兩天內完成一次所有測試點(diǎn)的全面測試，有可能需要一周或更長(cháng)的時(shí)間，但是這樣的話(huà)，就出現了測試、開(kāi)發(fā)互相等待的情況了。所以，在我們制定的測試階段計劃時(shí)，需要指明本次測試的測試重點(diǎn)，測試范圍。我可以這一輪測試進(jìn)行A、B模塊基本功能測試，第二輪測試進(jìn)行C、D模塊基本功能測試，第三輪測試，進(jìn)行主要業(yè)務(wù)流程測試，第四輪測試，關(guān)注負面測試。在我之前的實(shí)踐中，發(fā)現這種方法還是比較有效的?？赡艽蠹乙沧⒁獾搅?，這個(gè)例子是另一個(gè)項目的。沒(méi)錯，在今天提到的移動(dòng)的這個(gè)項目中我們就沒(méi)有對測試階段進(jìn)行迭代，弄得當時(shí)我們測試小組工作很累，很被動(dòng)，經(jīng)常是開(kāi)發(fā)說(shuō)測試我們就要馬上開(kāi)始測試，而缺乏計劃。實(shí)施這種方法后，測試的計劃性就比較強，測試不用總是被打擾。

　　測試設計，主要是根據需求、設計文檔進(jìn)行的測試用例設計工作。(如何從需求導出測試用例)設計測試用例，是整個(gè)測試過(guò)程中很重要的一部分工作，關(guān)系到測試執行效果。但是在剛開(kāi)始時(shí)，系統沒(méi)有界面，所以我們只能根據系統用例搭建測試用例的初步框架，能寫(xiě)多少寫(xiě)多少。隨著(zhù)對系統的理解深入，加上后面也開(kāi)發(fā)了系統原型，我們就可以不斷完善測試用例。即使是在測試階段，我們仍不斷修改測試用例。測試用例我們分為兩種，一種是內部測試用例，項目組內部使用;一種是驗收測試用例，偏重于業(yè)務(wù)，供客戶(hù)使用。

　　從圖中大家也可以感覺(jué)到項目組內部使用的測試用例在維護上比較不方便。因為我們的需求并沒(méi)有做到很細，加上需求本身就是變化的，所以我們的測試需求經(jīng)常修改，一旦測試需求新增、修改、刪除時(shí)，測試用例要相應進(jìn)行調整。這就造成了1)定位測試用例比較不方便，2)測試用例編號修改不方便，3)閱讀、執行測試用例不方便。所以，2004年底開(kāi)始準備團隊自己開(kāi)發(fā)一個(gè)測試用例管理系統。

　　在測試執行階段，主要進(jìn)行測試的執行工作。如果項目有需要編寫(xiě)或錄制測試腳本的話(huà)，那么也在這個(gè)階段進(jìn)行。測試執行結果是在原有測試用例的副本上編寫(xiě)實(shí)際執行結果而形成。

　　在測試執行結束后，我們開(kāi)始對測試執行結果進(jìn)行測試分析并編寫(xiě)測試報告。測試報告的編寫(xiě)上，主要的內容在于對投入的資源、測試結果、缺陷進(jìn)行分析，并對整體測試情況進(jìn)行總結分析。對于資源的分析，包括各個(gè)測試任務(wù)投入的人力情況、實(shí)際工作量與計劃工作量的對比，并進(jìn)行分析。測試結果分析，可以通過(guò)對測試需求的覆蓋情況、測試用例的覆蓋情況及測試用例執行結果情況進(jìn)行統計，并進(jìn)行分析。缺陷分析，可以通過(guò)對嚴重性、優(yōu)先級、模塊缺陷數、缺陷修復情況等方面進(jìn)行統計，并分析。例如，本次系統缺陷存在可用性問(wèn)題，如修改操作員所屬的組后，無(wú)法登錄系統等。整體情況的總結可以從測試充分性、軟件質(zhì)量情況、測試活動(dòng)情況、經(jīng)驗教訓等方面進(jìn)行總結。

　　注：本測試過(guò)程對于每個(gè)階段的測試活動(dòng)、每一輪測試活動(dòng)、測試團隊承接的各種測試類(lèi)型均適用。

　　也就是說(shuō)，每一輪測試之前，測試組leader需要準備測試計劃，確定測試執行重點(diǎn)、目標、測試內容等，選取測試用例，并按照預先選取的測試用例執行測試，測試執行結束，需要進(jìn)行測試匯報。

　　因為測試經(jīng)驗教訓是很重要的，所以我們團隊有專(zhuān)人負責對每個(gè)項目測試報告中的經(jīng)驗教訓進(jìn)行匯總，目的讓后面項目測試工作可以吸取前面項目測試的經(jīng)驗，避免犯前面項目測試工作同樣的錯誤。

　　在測試過(guò)程中有個(gè)很重要的內容是：測試準則。

　　在實(shí)際執行中，我們不難碰到以下類(lèi)似情況：提交測試的系統經(jīng)常在測試執行初期，就出現頁(yè)面訪(fǎng)問(wèn)失敗或者正常功能失效的情況;測試人員不知道提交測試的版本改了什么東西或者新增了什么功能，改了哪些缺陷，導致經(jīng)常碰到開(kāi)發(fā)人員說(shuō)測試人員提交的某些缺陷所對應的功能不屬于本版本測試內容等等。存在這些情況的很大一部分的原因是因為在項目策劃階段時(shí)，測試組未就測試準則和項目組達成一致意見(jiàn)，或者已經(jīng)達成一致，但是并沒(méi)有嚴格執行。我們今天要講的測試準則，主要是針對前者，后者屬于管理層面問(wèn)題，不在我們的考慮范圍內。

　　測試準則，包括測試進(jìn)入、暫停、恢復、退出準則。這些測試準則的例子如幻燈片所示。只要是導致暫停測試的的問(wèn)題不存在后，就可以恢復測試?；謴蜏y試時(shí)，一般是需要把前面測試內容重新進(jìn)行測試。

　　上面的測試準則的例子，也不是很恰當及規范，至少缺少了數據度量部分，這里只是拿出來(lái)和大家一起交流。這部分內容我一直認為是很重要的，如果做的不好，測試組的負擔會(huì )很重。

　　需要注意的一點(diǎn)是：測試準則，是在制定測試計劃時(shí)溝通確定的，它需要和相關(guān)人溝通，且得到pm審批通過(guò)的。

　　在實(shí)際測試過(guò)程中碰到同樣的問(wèn)題，是否繼續測試，或者需要暫停測試，處理方式不是一成不變的，這是需要根據項目所處階段來(lái)具體情況具體分析的。

原文轉自：http://kjueaiud.com