掌握有效測試軟件的方法與技術(一)(2)

　　u 條件比較好的公司，可以設置一個獨立的測試小組，該測試小組輪流參加各個項目的系統測試。而單元測試、集成測試工作由項目的開發小組承擔。

　　u 條件一般的公司，養不起獨立的測試小組。單元測試、集成測試工作由項目開發小組承擔。當項目進展到系統測試階段，可以從項目外抽調一些人員，加上開發人員，臨時組織系統測試小組。

　　u 條件比較差的公司，也許只有一個項目和為數不多的一些開發人員。那么就讓開發人員一直兼任測試人員的角色，相互測試對方的程序。如果人員實在太少了，只好讓開發者測試自己的程序，有測試總比沒有測試好吧!

　　3.3 避免開發人員與測試人員產生矛盾

　　u 開發人員的注意事項：

　　不要敵視測試人員。要理解測試的目的就是發現缺陷，是測試人員的工作職責。不要以為測試人員吃飽了沒事干，存心找茬。

　　不要輕視測試人員，別說人家技術水平差，不配搞開發只好搞測試。

　　u 測試人員的注意事項：

　　發現缺陷時不要嘲笑開發人員，別說他的程序真臭、到處是Bug。

　　在開發人員壓力太大時或心情不好時不要火上澆油，發現缺陷時別大聲嚷嚷。

　　u 請留意另一種極端：如果測試人員與開發人員的關系非常好，可能會導致在測試的時候“手下留情”，這對項目也是一種傷害。

　　4. 企業的測試策略

　　4.1 理念：

　　u 企業的主要目的是獲取利潤，降低測試成本也是盈利的一種方式。

　　u 用較低的代價實現有效的測試，不應為了追求完美的測試而不失一切代價。

　　4.2 如何合理地減少測試工作量

　　u 減少冗余的測試

　　白盒測試與黑盒測試的方式雖然不同，但往往有“異曲同工”之妙。在很多地方，白盒測試與黑盒測試會產生一模一樣的效果(或者能推理出來)，這樣的測試是冗余的。

　　在集成測試、系統測試階段，可能要執行多次“回歸測試”。每一次“回歸測試”都會存在不少的冗余，應當設法剔除不必要的重復測試工作。

　　u 減少無價值的測試

　　無價值的測試通常是由于不懂得測試技術引起的。例如功能測試，在等價區間之中，本來只要測試一個典型的輸入就行了，如果有人在此區間測試了100次，那么其中99次就是無價值的。

　　u 如何“偷工減料”

　　有 一些“短、平、快”的項目，經費本來就少，用戶對質量要求也馬馬虎虎。為了能多掙一點錢，開發方不得不采用“偷工減料”的方式來降低測試代價。偷工減料的 途徑無非就是減少測試的內容和頻度。但不能砍得太狠，否則軟件拿不出手?；痉椒ㄊ钦页鲕浖行枰獌炏葴y試的部分(見下表)，其它次要部分可以忽略或將來 再測試。

　　u “偷工減料”方法的測試優先級：

　　哪些功能是軟件的特色?

　　哪些功能是用戶最常用的?

　　如果系統可以分塊賣的話，哪些功能塊在銷售時最昂貴?

　　哪些功能出錯將導致用戶不滿或索賠?

　　哪些程序是最復雜、最容易出錯的?

　　哪些程序是相對獨立，應當提前測試的?

　　哪些程序最容易擴散錯誤?

　　哪些程序是全系統的性能瓶頸所在?

　　哪些程序是開發者最沒有信心的?

　　4.3 測試何時結束

　　u 基于測試用例的規則

　　u 基于“測試期缺陷密度”的規則

　　u 基于“運行期缺陷密度”的規則

　　4.4 測試獎勵機制

　　u 根據缺陷的危害程度，把獎金分等級。每個新缺陷對應一份獎金，把獎金發給第一個發現該缺陷的人。獎金額要適當，太低了人們不感興趣，太高了會讓項目破產的。

　　5. 測試規范

　　5.1 測試流程

　　u 第一步：制定測試計劃。該計劃被批準后轉向第二步。

　　u 第二步：設計測試用例。該用例被批準后轉向第三步。

　　u 第三步：如果滿足“啟動準則” ，那么執行測試。

　　u 第四步：撰寫測試報告。

　　u 第五步：消除軟件缺陷。如果滿足“完成準則”，那么正常結束測試。

　　5.2 測試啟動準則

　　u 同時滿足以下條件，允許開始測試：

　　(1)測試計劃已經制定并且通過了審批;

　　(2)測試用例已經設計并且通過了審批;

　　(3)被測試對象已經開發完畢并等待測試。

　　5.3 測試完成準則

　　u 對于非嚴格系統可以采用“基于測試用例”的準則。同時滿足以下條件允許結束測試：

　　(1)功能性測試用例通過率達到100%;

　　(2)非功能性測試用例通過率達到90%時。

　　u 對于嚴格系統，應當補充“基于測試期缺陷密度”的規則：

　　(3)相鄰n個CPU小時內“測試期缺陷密度”全部低于某個值m。例如n大于10，m小于等于1。

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