測試經驗交流

  本文主要目的是加強項目組和測試中心之間的相互了解，分享一些測試人員在工作中的經驗和成果，

  從而使項目組和測試中心的配合更加默契，共同把握住產品的質量要素。

  一、 測試的目的和原則

  1、測試概念的范疇

  廣義上講，測試是指軟件產品生存周期內所有的檢查、評審和確認活動。如：設計評審、系統測試。

  狹義上講，測試是對軟件產品質量的檢驗和評價。它一方面檢查軟件產品質量中存在的質量問題，同

  時對產品質量進行客觀的評價。

  2、測試的目的

  簡單地說，就是替用戶受過，測試的最終目的是確保最終交給用戶的產品的功能符合用戶的需求，把

  盡可能多的問題在產品交給用戶之前發現并改正。

  具體地講，測試一般要達到下列目標：

  1、確保產品完成了它所承諾或公布的功能，并且所有用戶可以訪問到的功能都有明確的書面說

  明------在某種意義上與ISO9001是同一種思想。

  產品缺少明確的書面文檔，是廠商一種短期行為的表現，也是一種不負責任的表現。所謂短期行為，是指缺少明確的書面文檔既不利于產品最后的順利交付，容易與用戶發生矛盾，影響廠商的聲譽和將來與用戶的合作關系；同時也不利于產品的后期維護，也使廠商支出超額的用戶培訓和技術支持費用。從長期

  利益看，這是很不劃算的。我有個感覺，接觸過的軟件產品，很少有向方正這樣大大的產品、薄薄的文檔。

  當然，書面文檔的編寫和維護工作對于使用快速原型法(RAD)開發的項目是最為重要的、最為困難，也是最容易被忽略的。

  最后，書面文檔的不健全甚至不正確，也是測試工作中遇到的最大和最頭痛的問題，它的直接后果是測試效率低下、測試目標不明確、測試范圍不充分，從而導致最終測試的作用不能充分發揮、測試效果不理想。

  2、 確保產品滿足性能和效率的要求

  使用起來系統運行效率低(性能低)、或用戶界面不友好、用戶操作不方便(效率低)的產品不能說是一

  個有競爭力的產品。

  用戶最關心的不是你的技術有多先進、功能有多強大，而是他能從這些技術、這些功能中得到多少好

  處。也就是說，用戶關心的是他能從中取出多少，而不是你已經放進去多少。

  3、 確保產品是健壯的和適應用戶環境的

  健壯性即穩定性，是產品質量的基本要求，尤其對于一個用于事務關鍵或時間關鍵的工作環境中。

  另外就是不能假設用戶的環境(某些項目可能除外)，如：報業用戶許多配置是比較低的，而且是和某

  些第三方產品同時使用的。

  3、測試的原則---Good Enough

  對于相對復雜的產品或系統來說，zero-bug是一種理想，good-enough是我們的原則。

  Good-enough原則就是一種權衡投入/產出比的原則：不充分的測試是不負責任的；過分的測試是一種

  資源的浪費，同樣也是一種不負責任的表現。我們的操作困難在于：如何界定什么樣的測試是不充分的，

  什么樣的測試是過分的。目前狀況唯一可用的答案是：制定最低測試通過標準和測試內容，然后具體問題

  具體分析。最明顯的例子就是FIT3.0中文報版的產品測試。

  4、測試的規律----木桶原理和80-20原則

  1、木桶原理。

  在軟件產品生產方面就是全面質量管理(TQM)的概念。產品質量的關鍵因素是分析、設計和實現，測

  試應該是融于其中的補充檢查手段，其他管理、支持、甚至文化因素也會影響最終產品的質量。應該說，

  測試是提高產品質量的必要條件，也是提高產品質量最直接、最快捷的手段，但決不是一種根本手段。反

  過來說，如果將提高產品質量的砝碼全部押在測試上，那將是一個恐怖而漫長的災難。

  2、 Bug的80-20原則。

  一般情況下，在分析、設計、實現階段的復審和測試工作能夠發現和避免80%的Bug，而系統測試又能

  找出其余Bug中的80%，最后的5%的Bug可能只有在用戶的大范圍、長時間使用后才會曝露出來。因為測試

  只能夠保證盡可能多地發現錯誤，無法保證能夠發現所有的錯誤。

  二、 測試中心測試組織、測試實施的現狀和改進

  1、測試中心的任務和發展目標----質量

  參與到監控產品生命周期中一切影響到質量的因素的工作中去。

  目前測試中心的主要任務是負責產品的系統測試。

  但實際上，因為單獨的系統測試不能保證產品最終的質量，所以測試中心在部分項目中也參與到集成

  測試和用戶測試中。

  另外，測試中心也承擔了部分系統評測的任務和用戶技術支持的任務。

  測試中心將來的發展目標是研究院開發的產品的質量保證中心，我們的中心任務只有兩個字："質

  量"，測試中心也只對這兩個字負責，并且將參與到監控產品生命周期中一切影響到質量的因素的工作中去。

  2、測試中心的組織方式----小組

  測試中心內部的個體分為測試人員和支持人員(管理人員屬于支持人員)。

  測試中心的工作實體(最小組織單位)是測試小組和支持小組，分別由小組長全權負責。小組長向測試

  中心主任負責。

  測試小組根據測試項目或評測項目的需要臨時組建，小組長也是臨時指定。與項目組的最大區別是生

  命周期短，一般是2周到4個月。在系統測試期間或系統評測期間，測試組長是測試中心對外(主要是項目

  組)的唯一接口，對內完全負責組員的工作安排、工作檢查和進度管理。

  支持小組按照內部相關條例負責測試中心的后勤保障和日常管理工作，機構設置一般相對比較穩定。

  主要負責網絡管理、數據備份、文檔管理、設備管理和維護、員工內部培訓、測試理論和技術應用、日常

  事務管理和檢查等。

  另外，測試中心對于每一個重要的產品方向，如：報社系統(包括采編、FIT、RIP、字模等)、電視臺

  系統(包括點睛、新聞等)…，均設置1-3個人長期研究和跟蹤方正及競爭對手的產品特征、性能、優缺點

  等。在有產品測試時，指導或參加測試(但不一定作為測試組長)，在沒有產品測試時，進行產品研究，并

  負責維護和完善測試設計。目前希望在需求分析階段多多參與(如：Chirashi2.1)。

  3、測試中心的運作方式----制度化并形成應用

  主要介紹一下項目組關心的系統測試流程：

  1、項目組提交系統測試申請給測試中心指定帳號。由專人檢查文檔格式和完備性。

  2、檢查合格后交給該產品對應方向的研究人員，評價其內容的有效性和真實性。

  3、檢查合格后由測試中心主任審查并通過，成立測試組，指定測試組長(但暫時沒有組員)。

  4、測試組長根據該產品的申請報告、測試設計和以往測試數據，制定測試方案。

  5、測試中心主任審核通過測試方案后，根據測試方案指定測試組成員，并由支持組完成其他支持任

  務(如：設備的配備、測試數據庫的建立、網絡權限的修改…)。

  6、測試期間測試組根據測試方案進行實際測試，記錄并跟蹤測試缺陷報告，填寫測試記錄。測試期

  間測試組長與項目組(測試經理)經常溝通，并獲取產品的更新版本。同時，測試組長審查、修改并提交所

  有缺陷報告，保證隨時掌握產品的質量情況，并監督測試進度。

  7、產品進行到一定階段后(標志是測試缺陷報告庫中所有的報告處于歸檔狀態)，由項目組和測試組

  長共同決定產品進入穩定期測試。穩定期測試版本之前的版本必須在顯著位置標明為測試版字樣。

  8、穩定期測試期間所發現的缺陷報告也需要記錄在測試缺陷報告庫中，并在穩定期結束后由雙方(有

  時可能也有市場方面的意見)共同決定對這些缺陷的處理方式。如果需要改動產品，則重新開始穩定期，

  否則通過穩定期測試。

  9、測試組長對于通過穩定期測試的產品填寫綜合測試報告，測試中心依此發布產品發行通知。

  10、測試組對整個測試過程和產品質量進行總結和評價，形成文檔并備案。同時，將測試過程中對測

  試設計的改動納入基線。最后，組長整理并在指定地點保存相關測試數據和測試樣張。

  11、測試中心解散測試小組。

  另外，在系統測試階段，我們要求測試小組要進行一些常規內容測試(如：Y2K測試，病毒檢查、裸機

  測試、加密檢查、說明書檢查…)，并要求寫入測試方案中。

  4、傳統測試流程遇到的挑戰和對策----問題發現得越早，解決的代價就越小

  1、 自動測試工具和測試理論

  由于我們的產品開發模式還不夠規范、相關文檔不夠完備，所以測試工具的應用效果不理想，只能部

  分應用。如：SQA。

  對于測試理論，測試思想/測試理念的灌輸工作還是有成效的，但是測試數學模型的研究和建立工作

  進展不順利，主要原因也是我們的產品生命周期內部操作不夠規范。

  目前主要依賴于：測試人員的經驗和素質；產品說明文檔和項目組的技術咨詢；測試設計。

  2、 測試分類

  根據目前的實際情況(已經由傳統的瀑布開發模式、使用結構化設計和實現手段，變為現在的RAD開發

  模式、使用OOD和OOP)，我們將把測試分為三種：產品測試、項目測試、系統評測。我們的依據是：問題

  發現得越早，解決的代價就越小。

  產品測試的流程基本和上面提到的一樣。

  項目測試的原則是盡早加入測試，并充分重視和支持用戶測試。

  系統評測是簡化工作流程。

  三、 測試中常見問題分析及對策

  我們一般把發現的錯誤bug(我們也稱為缺陷defect)按嚴重性分為4類：死機(系統崩潰或掛起)、致命

  (使系統不穩定、或破壞數據、或產生錯誤結果，而且是常規操作中經常發生或非常規操作中不可避免

  的)、嚴重(系統性能或響應時間變慢、產生錯誤的中間結果但不影響最終結果，如：顯示不正確但輸出正確)、一般(界面拼寫錯誤或用戶使用不方便)。

  我們也把發現的錯誤按優先級分為三種：高、中、低：一般是越影響用戶接受或使用該產品的錯誤優

  先級越高。

  但下面，將不對所有的問題進行列舉和分析，而只是列出一些顯而易見的、容易被項目組忽略的錯

  誤，這些錯誤可能是容易修改的、或是容易避免的，但是對于測試組或用戶來說可能卻是非常頭痛和不方

  便的。

  1、形象類問題：---不專業、用戶不信任

  1、不符合用戶操作習慣。如，快捷鍵定義不科學、不實用(鍵位分布不合理、按鍵太多，甚至沒有快

  捷鍵)。

  2、不夠專業，缺乏基本知識，而又沒有高手檢查：CMYK(0-255)

  3、界面中英文混雜，經常彈出莫名其妙的信息，而且還拼錯單詞

  4、SETUP界面：CopyRight 1994-1996；缺省認為用戶使用某種分辨率；

  5、說明書或幫助的排版格式不專業：中英文搭配不對、標點符號全角半角部分、沒有排版禁則…

  6、程序名/路徑名是程序員的名字、或沒有安裝程序、或安裝程序不完善(丟掉一些必要的模塊或文

  件)

  7、界面元素參差不齊，文字不能完全顯示，TAB時鼠標亂走。

  2、可用性問題：---用戶無法使用或不方便使用

  “用戶比開發或測試人員在接觸界面上要花費更多時間。表面上不重要的方面的影響會變得越來越

  大，最終甚至會掩蓋了產品得有用得方面?！?/P>

  下面是一些用戶界面錯誤的例子：

  1、輸入無合法性檢查和值域檢查，允許用戶輸入錯誤的數據類型，并導致不可逆料的后果

  2、界面中的信息不能及時更新，不能正確反映數據狀態，甚至對用戶產生錯誤的誤導。如：數據庫

  中剩余記錄個數；參數設置對話框中的預設值

  下面是一些低效的用戶界面的例子：

  1、表達不清或過于模糊的信息提示

  2、要求用戶輸入多余的、本來系統可以自己得到的數據。如：服務是否啟動，安裝后用戶要手動修

  改某些配置文件。

  3、為了達到某個設置或對話框，用戶必須做許多冗余操作。如，對話框嵌套層次太多。

  4、不能記憶用戶的設置或操作習慣，用戶每次進入都需要重新操作一次初始環境。

  5、使用不完善的功能且不給用戶以恰當的提示，如：對于TIF圖片的不完全支持；Undo功能的局限

  性。

  6、不經用戶確認就對系統或數據進行重大修改

  3、穩定性問題：---影響用戶正常工作

  1、不可重現的死機，或不斷申請但不完全釋放資源，系統性能越來越低

  2、主系統和子系統使用同樣的臨界資源而互相不知道。如：使用同樣的類名或臨時文件名、使用同

  樣的數據庫字段名或登錄帳號。

  3、不能重現的錯誤，許多與代碼中的未初始化變量(在Debug時一般是缺省初始化的)有關，有些與系

  統不檢查異常情況(如內存申請不成功、網絡突然中斷或長時間沒有響應)有關。

  4、其他問題

  1、文檔匱乏：無標準；無新功能使用方法；無版本改動說明。我們不僅要認為沒有說明文檔的產品

  不是是一個完整的產品，也要認為沒有說明或沒有正確說明的功能是一個沒有完全實現的功能，因為用戶

  無法用得起來。

  2、運行時不檢查內存、數據庫或硬盤空間等

  3、無根據地假設用戶環境：硬件/網絡環境；有些動態庫；安裝程序換臺機器不正確；假設網絡隨時

  都是連通的

  4、提供的版本帶病毒，或根本無法安裝，或沒有加密

  5、提供Debug版本給測試組或測試用戶，或項目組與測試組使用不同版本

  6、用戶現場開發和修改，又沒有記錄和保留

  7、錯誤反復出現，改動得不徹底、或版本管理出現混亂

  8、錯誤越改越多，改動得不徹底、或改動得不小心

  9、版本中部分內容和接口倒退

  10、有些選項永遠是灰的；有些選項、菜單項在該灰時還不灰，并且還能狀態顯示

  11、資源沒有和代碼分離，不同語言版本間不能平滑轉換

  12、缺少第三方產品的評估：廣告管理系統2000年問題

  13、產品配合不利，準備當作一套產品或方案推出，互相之間卻各不負責，(沒有整個項目負責人，

  是面向組織的而不是面向產品或方案的)，如：采編+FIT；Gallery+FIT。

  ……

  5、期望項目組關注的一些問題

  1、修改Bug的人考慮得不夠周全，也可能是沒有能力考慮周全---不懂全部程序

  2、問題留給測試組去發現的心態----不仔細測試、不小心修改、甚至不全面改(不徹底)

  3、自己不會用，不了解產品的用法。

  4、更多地從用戶使用的角度考慮設計、編碼與測試

  四、結語

  本文準備得匆忙，可能不夠全面和細致。這里只希望我們的產品以高質量和全面為用戶著想的態度來進入

  世界市場，并壟斷某些市場。切記：用戶和市場是我們的衣食父母…

原文轉自：http://www.anti-gravitydesign.com