軟件測試流程收集(2)

　　為了測試一款軟件，我們可能根據不同的需求點(diǎn)要使用很多不同的測試環(huán)境。有些測試環(huán)境我們是可以搭建的，有些環(huán)境我們無(wú)法搭建或者搭建成本很高。不管如何，我們的目標是測試軟件問(wèn)題，保證軟件質(zhì)量。測試環(huán)境問(wèn)題，還是根據具體產(chǎn)品以及開(kāi)發(fā)者的實(shí)際情況而采取最經(jīng)濟的方式吧。

　　測試執行

　　測試執行過(guò)程又可以分為以下階段：

　　單元測試→集成測試→系統測試→出廠(chǎng)測試，其中每個(gè)階段還有回歸測試等。

　　從測試的角度而言，測試執行包括一個(gè)量和度的問(wèn)題。也就是測試范圍和測試程度的問(wèn)題。 比如一個(gè)版本需要測試哪些方面?每個(gè)方面要測試到什么程度?

　　從管理的角度而言，在有限的時(shí)間內，在人員有限甚至短缺的情況下，要考慮如何分工，如何合理地利用資源來(lái)開(kāi)展測試。當然還要考慮以下問(wèn)題：

　　1. 當測試人員測試的執行不到位、敷衍了事時(shí)該如何解決?

　　2. 測試效率問(wèn)題，怎樣提高測試效率?

　　3. 根據版本的不同特點(diǎn)是只做驗證測試還是采取冒煙測試亦或是系統全面測試?

　　4. 當測試過(guò)程中遇到一些偶然性隨機問(wèn)題該怎樣處理?

　　5. 當版本中出現很多新問(wèn)題時(shí)該怎樣對待?測試停止標準?

　　6. ……

　　總之，測試執行過(guò)程中會(huì )遇到很多復雜的問(wèn)題，還是那句話(huà)，具體問(wèn)題具體解決!本文不做過(guò)多闡述。

　　測試記錄

　　缺陷記錄總的說(shuō)來(lái)包括兩方面：由誰(shuí)提交和缺陷描述。

　　一般而言，缺陷都是誰(shuí)測試誰(shuí)提交，當然有些公司可能為了保證所提交缺陷的質(zhì)量，還會(huì )在提交前進(jìn)行缺陷評估，以確保所提交的缺陷的準確性。

　　在缺陷的描述上，至少要包括以下一些方面內容：

　　序號

　　標題

　　預置條件

　　操作步驟

　　預期結果

　　實(shí)際結果

　　注釋

　　嚴重程度

　　概率

　　版本

　　測試者

　　測試日期

　　以上是描述一個(gè)bug時(shí)通常所要描述的內容，當然在實(shí)際提交bug時(shí)可以根據實(shí)際情況進(jìn)行補充，如附上圖片、log文件等。

　　另外，一個(gè)版本軟件測試完畢，還要根據測試情況出份測試報告，這也是所要經(jīng)過(guò)的一個(gè)環(huán)節。

　　缺陷管理

　　缺陷管理方面，很多公司都采取缺陷管理工具來(lái)進(jìn)行管理，常見(jiàn)缺陷管理工具有Test Director、Bugfree等。

　　下圖是一個(gè)bug從提出到close所經(jīng)過(guò)的一些流程，其他比如keep No action\keep spec等一些狀態(tài)流程都未包含在內，在此僅做示范說(shuō)明。

　　注：軟件缺陷和bug兩者在含義上有著(zhù)細微差別，本文統稱(chēng)缺陷。

　　軟件評估

　　這里評估指軟件經(jīng)過(guò)一輪又一輪測試后，確認軟件無(wú)重大問(wèn)題或者問(wèn)題很少的情況下，對準備發(fā)給客戶(hù)的軟件進(jìn)行評估，以確定是否能夠發(fā)行給客戶(hù)或投放市場(chǎng)。

　　軟件評估小組一般由項目負責人、營(yíng)銷(xiāo)人員、部門(mén)經(jīng)理等組成，也可能是由客戶(hù)指定的第三方人員組成。

　　測試總結

　　每個(gè)版本有每個(gè)版本的測試總結，每個(gè)階段有每個(gè)階段的測試總結，當項目完成RTM后，一般要對整個(gè)項目做個(gè)回顧總結，看有哪些做的不足的地方，有哪些經(jīng)驗可以對今后的測試工作做借鑒使用，等等。測試總結無(wú)嚴格格式、字數限制。應該說(shuō)，測試總結還是很總要的。

　　測試維護

　　由于測試的不完全性，當軟件正式release后，客戶(hù)在使用過(guò)程中，難免遇到一些問(wèn)題，有的甚至是嚴重性的問(wèn)題，這就需要修改有關(guān)問(wèn)題，修改后需要再次對軟件進(jìn)行測試、評估、發(fā)行。

　　三、編制測試用例

　　著(zhù)重介紹一些編制測試用例的具體做法。

　　1、測試用例文檔

　　編寫(xiě)測試用例文檔應有文檔模板，須符合內部的規范要求。測試用例文檔將受制于測試用例管理軟件的約束。

　　軟件產(chǎn)品或軟件開(kāi)發(fā)項目的測試用例一般以該產(chǎn)品的軟件模塊或子系統為單位，形成一個(gè)測試用例文檔，但并不是絕對的。

　　測試用例文檔由簡(jiǎn)介和測試用例兩部分組成。簡(jiǎn)介部分編制了測試目的、測試范圍、定義術(shù)語(yǔ)、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個(gè)具體測試用例都將包括下列詳細信息：用例編號、用例名稱(chēng)、測試等級、入口準則、驗證步驟、期望結果(含判斷標準)、出口準則、注釋等。以上內容涵蓋了測試用例的基本元素：測試索引，測試環(huán)境，測試輸入，測試操作，預期結果，評價(jià)標準。

　　2、測試用例的設置

　　我們早期的測試用例是按功能設置用例。后來(lái)引進(jìn)了路徑分析法，按路徑設置用例。目前演變?yōu)榘垂δ?、路徑混合模式設置用例。

　　按功能測試是最簡(jiǎn)捷的，按用例規約遍歷測試每一功能。

　　對于復雜操作的程序模塊，其各功能的實(shí)施是相互影響、緊密相關(guān)、環(huán)環(huán)相扣的，可以演變出數量繁多的變化。沒(méi)有嚴密的邏輯分析，產(chǎn)生遺漏是在所難免。路徑分析是一個(gè)很好的方法，其最大的優(yōu)點(diǎn)是在于可以避免漏測試。

　　但路徑分析法也有局限性。在一個(gè)非常簡(jiǎn)單字典維護模塊就存在十余條路徑。一個(gè)復雜的模塊會(huì )有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合適的使用規模。若一個(gè)子系統有十余個(gè)或更多的模塊，這些模塊相互有關(guān)聯(lián)。再采用路徑分析法，其路徑數量成幾何級增長(cháng)，達5位數或更多，就無(wú)法使用了。那么子系統模塊間的測試路徑或測試用例還是要靠傳統方法來(lái)解決。這是按功能、路徑混合模式設置用例的由來(lái)。

　　3、設計測試用例

　　測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約(或設計規格說(shuō)明書(shū))，根據關(guān)聯(lián)的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例?；臼录臏y試用例應包含所有需要實(shí)現的需求功能，覆蓋率達100%。

　　設計備選事件和異常事件的用例，則要復雜和困難得多。例如，字典的代碼是唯一的，不允許重復。測試需要驗證：字典新增程序中已存在有關(guān)字典代碼的約束，若出現代碼重復必須報錯，并且報錯文字正確。往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，并同時(shí)盡量發(fā)現其中的軟件缺陷。

　　可以采用軟件測試常用的基本方法：等價(jià)類(lèi)劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟件的不同性質(zhì)采用不同的方法。如何靈活運用各種基本方法來(lái)設計完整的測試用例，并最終實(shí)現暴露隱藏的缺陷，全憑測試設計人員的豐富經(jīng)驗和精心設計。

　　四、測試用例在軟件測試中的作用

　　1、指導測試的實(shí)施

　　測試用例主要適用于集成測試、系統測試和回歸測試。在實(shí)施測試時(shí)測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實(shí)施測試。并對測試情況記錄在測試用例管理軟件中，以便自動(dòng)生成測試結果文檔。

　　根據測試用例的測試等級，集成測試應測試那些用例，系統測試和回歸測試又該測試那些用例，在設計測試用例時(shí)都已作明確規定，實(shí)施測試時(shí)測試人員不能隨意作變動(dòng)。

　　2、規劃測試數據的準備

　　在我們的實(shí)踐中測試數據是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。尤其象測試報表之類(lèi)數據集的正確性，按照測試用例規劃準備測試數據是十分必須的。

　　除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據。

　　3、編寫(xiě)測試腳本的"設計規格說(shuō)明書(shū)"

　　為提高測試效率，軟件測試已大力發(fā)展自動(dòng)測試。自動(dòng)測試的中心任務(wù)是編寫(xiě)測試腳本。如果說(shuō)軟件工程中軟件編程必須有設計規格說(shuō)明書(shū)，那么測試腳本的設計規格說(shuō)明書(shū)就是測試用例。

　　4、評估測試結果的度量基準

　　完成測試實(shí)施后需要對測試結果進(jìn)行評估，并且編制測試報告。判斷軟件測試是否完成、衡量測試質(zhì)量需要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統計基準是軟件模塊或功能點(diǎn)，顯得過(guò)于粗糙。采用測試用例作度量基準更加準確、有效。

　　5、分析缺陷的標準

　　通過(guò)收集缺陷，對比測試用例和缺陷數據庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟件質(zhì)量。而已有相應測試用例，則反映實(shí)施測試或變更處理存在問(wèn)題。

　　五、相關(guān)問(wèn)題

　　1、測試用例的評審

　　測試用例是軟件測試的準則，但它并不是一經(jīng)編制完成就成為準則。測試用例在設計編制過(guò)程中要組織同級互查。完成編制后應組織專(zhuān)家評審，需獲得通過(guò)才可以使用。評審委員會(huì )可由項目負責人、測試、編程、分析設計等有關(guān)人員組成，也可邀請客戶(hù)代表參加。

　　2、測試用例的修改更新

　　測試用例在形成文檔后也還需要不斷完善。主要來(lái)自三方面的緣故：第一、在測試過(guò)程中發(fā)現設計測試用例時(shí)考慮不周，需要完善;第二、在軟件交付使用后反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成;第三、軟件自身的新增功能以及軟件版本的更新，測試用例也必須配套修改更新。

　　一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。

　　3、測試用例的管理軟件

　　運用測試用例還需配備測試用例管理軟件。它的主要功能有三個(gè)：第一、能將測試用例文檔的關(guān)鍵內容，如編號、名稱(chēng)等等自動(dòng)導入管理數據庫，形成與測試用例文檔完全對應的記錄;第二、可供測試實(shí)施時(shí)及時(shí)輸入測試情況;第三、最終實(shí)現自動(dòng)生成測試結果文檔，包含各測試度量值，測試覆蓋表和測試通過(guò)或不通過(guò)的測試用例清單列表。

　　有了管理軟件，測試人員無(wú)論是編寫(xiě)每日的測試工作日志、還是出軟件測試報告，都會(huì )變得輕而易舉。 

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