人是測試工作中最有價值也是最重要的資源，沒有一個合格的、積極的測試小組，測試就不可能實現。然而，在軟件開發產業中有一種非常普遍習慣，那就是讓那些經驗最少的新手、沒有效率的開發者或不適合干其他工作的人去做測試工作。這絕對是一種目光短淺的行為，對一個系統進行有效的測試所需要的技能絕對不比進行軟件開發需要的少，事實上，測試者將獲得極其廣泛的經驗，他們將遇到許多開發者不可能遇到的問題。

①、溝通能力

一名理想的測試者必須能夠同測試涉及到的所有人進行溝通，具有與技術（開發者）和非技術人員（客戶，管理人員）的交流能力。既要可以和用戶談得來，又能同開發人員說得上話，不幸的是這兩類人沒有共同語言。和用戶談話的重點必須放在系統可以正確地處理什么和不可以處理什么上。而和開發者談相同的信息時，就必須將這些活重新組織以另一種方式表達出來，測試小組的成員必須能夠同等地同用戶和開發者溝通。

②、移情能力

和系統開發有關的所有人員都處在一種既關心又擔心的狀態之中。用戶擔心將來使用一個不符合自己要求的系統，開發者則擔心由于系統要求不正確而使他不得不重新開發整個系統，管理部門則擔心這個系統突然崩潰而使它的聲譽受損。測試者必須和每一類人打交道，因此需要測試小組的成員對他們每個人都具有足夠的理解和同情，具備了這種能力可以將測試人員與相關人員之間的沖突和對抗減少到最低程度。

③、技術能力

就總體言，開發人員對那些不懂技術的人持一種輕視的態度。一旦測試小組的某個成員作出了一個錯誤的斷定，那么他們的可信度就會立刻被傳揚了出去。一個測試者必須既明白被測軟件系統的概念又要會使用工程中的那些工具。要做到這一點需要有幾年以上的編程經驗，前期的開發經驗可以幫助對軟件開發過程有較深入的理解，從開發人員的角度正確的評價測試者，簡化自動測試工具編程的學習曲線。

④、自信心

開發者指責測試者出了錯是常有的事，測試者必須對自己的觀點有足夠的自信心。如果容許別人對自己指東指西，就不能完成什么更多的事情了。

⑤、外交能力

當你告訴某人他出了錯時，就必須使用一些外交方法。機智老練和外交手法有助于維護與開發人員的協作關系，測試者在告訴開發者他的軟件有錯誤時，也同樣需要一定的外交手腕。如果采取的方法過于強硬，對測試者來說，在以后和開發部門的合作方面就相當于“贏了戰爭卻輸了戰役”。

⑥、幽默感

在遇到狡辯的情況下，一個幽默的批評將是很有幫助的。

⑦、很強的記憶力

一個理想的測試者應該有能力將以前曾經遇到過的類似的錯誤從記憶深處挖掘出來，這一能力在測試過程中的價值是無法衡量的。因為許多新出現的問題和我們已經發現的問題相差無幾。

⑧、耐心

一些質量保證工作需要難以置信的耐心。有時你需要花費驚人的時間去分離、識別和分派一個錯誤。這個工作是那些坐不住的人無法完成的。

⑨、懷疑精神

可以預料，開發者會盡他們最大的努力將所有的錯誤解釋過去。測式者必須聽每個人的說明，但他必須保持懷疑直到他自己看過以后。

⑩、自我督促

干測試工作很容易使你變得懶散。只有那些具有自我督促能力的人才能夠使自己每天正常地工作。

11、洞察力

一個好的測試工程師具有“測試是為了破壞”的觀點，捕獲用戶觀點的能力，強烈的質量追求，對細節的關注能力。應用的高風險區的判斷能力以便將有限的測試針對重點環節。

UML軟件工程組織

--------------------------------------------------------------------------------

軟件測試之我見

mume（轉載自CSDN）2002年09月16日

我做軟件測試有一段不短的時間了，可大量的盲目測試幾乎沒有增長我的測試經驗，每次測試前總有些茫然，不知道自己怎樣才能有效的發現軟件中存在的缺陷；測試后也不能肯定是否可以放心的發布被測軟件。我想可能很多初涉測試的工作者都同我有相似的感覺，我們需要有關測試的理論知識的引導，以下是我讀了一些講解測試技術的書籍后的收獲，以及我對我國當前軟件業中測試這一領域的認識，希望也能給測試同行點滴的收益。

一、軟件測試員的目標是盡可能早一些找出軟件缺陷，并確保其得以關閉。

或許大家會認為軟件測試員的工作目標是不言而喻的：就是找軟件缺陷，然而《軟件測試》這本書為軟件測試人員提出了更確切的目標：盡可能早一些找出軟件缺陷，并確保其得以修復。在閱讀全書并仔細思考后，我覺得此目標包含三大點含義：

1． 軟件測試員的基本目標是發現軟件缺陷。

我覺得在這里有必要把這不言而喻的事實再次強調一下，因為有時產品的開發小組要測試員只是為了證實軟件可以運行，而不是找缺陷。在這種情況下，測試人員也就缺乏不懈努力發現缺陷的探索精神和熱情。所以我覺得在心里堅信不移的認為：軟件測試員的基本目標是發現軟件缺陷，是做好測試的首要條件。

2． 軟件測試員追求的是盡可能早的找出軟件缺陷。

因為軟件的修復費用，隨著時間的推移，將數十倍的增長，所以軟件測試員應盡可能早的找出軟件缺陷。對大型的軟件，在軟件開發的同時，就應該有緊隨其后的測試，如果等到產品已經開發完畢才開始測試，非常有可能引起大量耗時費力的返工。而如何盡可能早的找出缺陷？《軟件測試》這本書向我們介紹了一些理論上的測試方法：靜態黑盒測試、動態黑盒測試、靜態白盒測試、動態白盒測試；配置測試、兼容性測試、易用性測試……，怎樣才能有效的用這些方法盡早的發現軟件缺陷，需要大家在工作實踐中不斷的摸索、總結，進而不斷的提高自己的測試能力。

3． 軟件測試人員必需確保找出的軟件缺陷得以關閉。

請注意，我們這里提的是軟件測試人員必需確保找出的軟件缺陷得以關閉，而不是要軟件缺陷得以修復。我們軟件測試員需要對自己找出的軟件缺陷保持一種平常心：并不是我們辛苦找出的每個軟件缺陷都是必要修復的。可能是由于沒有足夠的時間、不算真正的軟件缺陷、修復的風險太大等原因，產品開發小組決定對一些軟件缺陷不作修復。

另外，測試員對軟件缺陷描述不清楚，也會使軟件測試員發現的缺陷被忽略。所以我們測試員必須在描述軟件缺陷方面狠下功夫：用簡單明了的語句描述軟件缺陷；每一件報告盡量針對一個軟件缺陷，避免多個缺陷混雜在一起，以致其中一些被忽略或忘卻；記錄引出軟件缺陷的操作步驟，使缺陷得以再現。

雖然我們軟件測試員需要對自己找出的軟件缺陷保持一種平常心，但同時又必須堅持有始有終的原則，跟蹤每一個軟件缺陷的處理結果，確保軟件缺陷得以關閉。關閉軟件缺陷的前提可以是缺陷得以修復或決定不作修復。而缺陷是否需要修復的最終決定權在軟件的最終負責人，檢查缺陷得以關閉的責任在測試人員。

二、測試一個軟件最首要也是最重要的是測試其產品功能說明書。

1 概念

產品功能說明書：對產品最終需要實現的功能的描述。這些功能是最終確定的需要滿足的客戶需求，也包括是一些軟件必須具備的能力。

在規范的軟件生成的流程中，產品功能說明書應在用戶需求評審會議召開后，進行系統的概要設計前確定。

2 原因

（１）很多軟件的缺陷都是因為產品功能說明書不夠全面，經常更改造成的；

（２）只有詳細的閱讀了產品功能說明書，確認產品需要實現的功能，才能擬定切實可行的測試方案；

3 方法

（１）參照需求說明書，檢查產品功能說明書描述的產品將要實現的功能是否已經完整、準確、一致、合理的描述了產品的功能，并確保這些功能是可測試的

（２）研究產品說明書是否符合現有的軟件設計開發的標準或規范；

（３）研究同類軟件，預測產品的最終結果；

如果測試人員發現產品說明書不符合以上幾點，該怎么做？

測試人員需要明白，我們的責任是反映產品的缺陷，我們不需要也不能修正產品，所以同發現軟件的其它缺陷一樣，在發現產品說明書的缺陷后，應該把它們如實并詳細的記錄下來，呈報給此軟件的最終負責人，對并此缺陷的處理情況進行跟蹤。

注意同發現的軟件其它缺陷一樣，缺陷列表應該呈報給軟件的最終負責人，而不是給相關技術人員或技術主管，因為技術人員可能會以在技術的實現上有難度為推托，拒絕對缺陷的修改。

4 目前的可執行度

（１）很多軟件在開發前并沒有書面形式的產品說明書

目前我國的許多軟件公司都是小型的手工作坊式的公司，在程序開發前都沒有一個正式的、完整的、確定的產品說明書，即便是這種情況，產品說明書也是存在的，它存在在軟件設計人員、項目負責人的腦海里，在他們心中都有一個軟件的輪廓，假定了軟件將要實現的功能。我們的測試人員可以在同他們的交流和不斷的詢問中獲得這個非正式的產品說明書，值得注意的是在我們得到這些信息后還需要以書面的形式把它們一一列舉出來，再向相關人員請教，最后做到能完整、準確、一致、合理的描述了產品的功能。

（２）測試人員一般不會在項目初期就參與項目

當前還存在著這樣一種問題，公司一般不會讓軟件測試人員在項目的初期就參與項目，一般要等到軟件的雛形出來后才會讓軟件測試人員著手進行測試。對這種情況，測試人員可以通過已經建立的軟件的雛形，揣摩產品說明書，然后也是同上段所說一樣，向相關人員請教，擬定一份書面的完整的、準確的、一致的、合理的產品說說明書。值得注意的是，測試人員在運行軟件的雛形時，往往會發現一些軟件缺陷，這時千萬不要局限在這些缺陷上耗費經歷，以致忘了擬定產品說明書的主要任務，一定要記住：測試一個軟件最首要也是最重要的是測試其產品說明書，在產品說明書明確后，再制定具體的測試案例。

以上兩點是指在公司體系不太正規的情況下給測試員的建議，但我認為要能更好的保證軟件的質量，或許規范生成軟件的整個運作流程更為有效：產品說明書由項目負責人來主持定版比較好，因為他把握著產品發展的方向；在產品說明書定版時的會議應請負責測試的人參加，使他們對產品有一個宏觀的認識，我也不贊成測試人員過早的局限于某一項目，如果那樣他們會覺得無所事事。

三、完全測試軟件是絕不可能的，必須對測試的各項進行等價劃分。

1 概念

等價分配：軟件有無限的測試案例，我們要想辦法把軟件的相似輸入、輸出、操作分成一組，來使無限的測試案例減小到同樣有效的小范圍，這個過程稱為等價分配。

邊界條件：軟件計劃的操作界限所在的邊緣條件，即如果超出這個邊界條件，就可能會引出錯誤。

2 原因

輸入量太大

輸出結果太多

軟件實現途徑太多

軟件說明書沒有客觀標準。從不同的角度看，軟件缺陷的標準不同。

3 方法

（１）數據測試：

1） 確定輸入的邊界條件，對邊界線上的及邊界線兩邊的數據進行測試；

2） 邊界線可能是2的乘方，默認值、空白值、零值等；每一個軟件測試問題各不相同，可能包含格式各樣邊界的不同數據。

（２）狀態測試（軟件的狀態是指軟件當前所處的情況或者模式）

1） 每種狀態至少訪問一次；

2） 測試看起來最常見最普遍的狀態轉換；

3） 測試狀態之間最不常用的分支；

4） 測試所有錯誤狀態及其返回值；

5） 測試隨機狀態轉換。

4 目前的可執行度

如果為了減少測試案例的數量過度進行等價分配，測試漏掉軟件缺陷的風險就會增加。對初涉軟件測試者，一定要請經驗豐富的測試員審查預定的等價類別。