測試員的角色

經驗一：作用

什麼時候測試人員都要了解專案的進度和問題，找到資訊，知道專案進行的大概方向，正確的引導專案組一步步到達目的地（類似前燈一樣的作用）

經驗二：使命

快速找出重要軟體問題

對產品質量提出總體評估

確認產品達到某種具體標準

幫助客戶改進產品質量和可測試性

保證測試過程能夠達到可分清責任的標準

就測試和與測試員協作方式培訓客戶

採用特定的方法集或遵循特定的規則集

幫助預測和控制成本

幫助客戶改進其過程

以最小成本、時間或儘可能減少副作用的方式，完成自己的工作

為滿足特定客戶要求，完成所有必要的工作

測試員必須明確原因：

測試員不知道自己該做什麼的時候，可以憑此找出自己的核心問題。

測試員知道自己該做什麼的時候，重新考慮使命可以使自己不會過於偏重某一個測試問題而忽略其他問題。

明確自己下一步要做什麼。

可為自己工作辯護，簡單描述，向他人解釋自己的角色。

而且在緊急時刻，因為某些原因不能完成自己的使命，則需立即彙報給管理層。

經驗三：服務角色

1.專案經理

迅速報告重要問題，不要成為專案瓶頸

測試員的責任就是告訴專案經理自己能做什麼，不能做什麼，有關專案的決策和條件會對測試產生什麼影響

2.程式設計師

迅速的提供有質量的錯誤報告，提供自己技能瞭解產品更好的定位錯誤。這樣能更好的協助程式設計師，同時贏得信任，獲取支援和影響。

3.技術文件編寫員

可幫助技術文件編寫理解產品怎樣發揮效能，指出文件中的錯誤。當技術文件編寫研究產品是也會了解到一些測試員不知道的資訊，這樣測試員如果和技術關係好也能瞭解到一些產品新特徵，新用法，計劃中的漏洞和他們所發現的軟體問題。

4．技術支援員

遺留在產品中的任何問題都會為技術支援員帶來擔憂。

測試員通過告訴技術支援遠可能會給使用者帶來的麻煩的產品問題，向其提供服務。

技術人員在測試過程中幫助測試員找出應該更正的問題，測試員通過現場測試發現的難題，為技術支援員提供幫助。

5．市場開發員

市場開發員需要了解產品中任何與產品應該提供給客戶的關鍵利益不一致的地方。

程式中的小問題，可能是使用者較難完成的某種重要任務，所以對市場開發員來說就至關重要了。通過評審市場開發計劃文件或描述，測試員可以幫助市場開發員對產品能力有更精確的認識。

6.管理層和專案相關人員

測試員服務公司業務。測試員必須小心，不要像個質量狂，而不是通情達理的人。特別是到了專案要結束的時候，測試員要以兼顧公司短期和長期利益的方式完成自己的職責。要以明確，簡潔的詞彙編寫測試狀態和報告，以便執行經理能夠感到有做抉擇的依據。

7．使用者

在測試員的心中，要想著將要使用該產品的人。使用者的滿意是專案的最高利益。但是要考慮主要使用者對專案團隊的特殊要求。

經驗四：測試發現的資訊會“打擾”客戶

測試團隊的使命包括根據客戶對價值的定義，通知客戶有關威脅產品價值的任何資訊。如果發現產品能按照意圖執行，但是達不到所要求價值，則測試員有責任報告，如果忽視報告，那是他們的權力。

經驗五：迅速找出重要問題

先測試變更部分，在測試沒有變化部分。

先測試核心部分，再測試輔助功能，測試關鍵常用功能，再測試基本任務的功能。

先測試能力，再測試可靠性。先測試每個功能是否完全能用，然後在深入檢查每個功能在很多不同條件下表現如何。

首先測試常見情況，然後測試少見情況，使用常用的資料和使用場景。

首先測試常見威脅，然後測試罕見威脅。用最有可能出現的壓力和錯誤情況進行測試。

首先測試影響大的問題，然後測試影響小的問題。測試在出現失效的情況下會產生大量破壞的產品部件。

首先測試最需要的部分，然後測試沒有要求的部分。測試對團隊其他人有重要意義的任何部分的任何問題。

經驗六：跟著程式設計師走

迅速回歸問題，迅速找出問題。最理想情況是，程式設計師為了修改測試員找出的程式問題忙得團團轉，是程式設計師，而不是測試員，成為專案的瓶頸。

經驗七：詢問一切，但不一定外露

不問問題當然可以測試，但是不可能測試得好。不過很直白的問題會刺激別人，常常使人產生顧慮。

問題是一劑猛藥，最好是採用低劑量，或者與飯一起吃（結合其他溝通形式）

經驗十：當心“完備的”測試

完備測試可能的定義

完全發現了產品中每個問題

完全檢查了產品的每個部分

完成了自認為是有用、經濟的測試

儘自己所能，完全達到了專案團隊制定的目標

完成了約定的測試

完成了在一定條件下人所能夠測試的所有內容

完成了自己知道如何測試的所有內容

完成了自己所承擔的測試部分，不考慮其他人的工作

完成了對產品很廣，但是不深的測試

完成了對產品的一種測試

用完了分配給測試的時間

解決完備測試普通溝通問題，可讓客戶詳細瞭解測試過程。

總結自己實施的測試，以及為什麼值得實施這些測試，並告訴客戶自己沒有做的其他值得做的測試，以及為什麼沒有做這些測試。

經驗十一：通過測試不能保證質量

質量來源於構建產品的人，有時這對他們來說是要揹負的沉重負擔。測試員使命中的一大部分，就是幫助他們更有效地對付真正的負擔。

測試員不應該是唯一關心交付好產品的人

經驗十二：永遠別做看門人

產品釋出否決權如果有測試人員來行使，那麼團隊其他成員會為此放鬆一點，甚至是大大的放鬆。如果問題逃過測試和專案團隊，他們團隊其他成員也會責備測試員。另外延誤釋出，會被嚴厲追究責任的。

如果一定要一個人來承擔，最好要由控制專案，條件最好的人承擔釋出產品的責任。大多數非常有效的團隊，都採取某種方式的集體決定是否釋出產品。要堅持與專案團隊的其他角色一起分擔這種權力。

經驗十三：當心測試中不關我事理論

產品規格說明太模糊；程式設計師交付程式碼太慢；測試問題不被重視，被認為是測試人員主觀臆想等外在原因，可能會使測試員不得不放狠話說出了問題不關我事，當然情況嚴重或許這樣做不錯。但是首先應該考慮下自己的期望是否符合實際情況，是否有其他方式能夠得到自己所需的條件。

如果測試員擺正心態，認為自己的工作就是付出合理的努力去適應和靈活應對各種情況。則程式設計師或更願意與測試人員打交道，不會心理上排斥測試人員，反過來促使他們把幫助測試人員當做是自己的事。

經驗十四：當心成為過程改進小組

希望能通過不需要測試的方式達到質量過關，因而去要求其他團隊該如何如何做。只會適得其反，讓其他團隊繞過測試，讓測試變的無能。

經驗二十三：測試員不只是遊客

測試員把精力放在評估產品上，而不是見證產品

姿態：如果問題存在就會有相應的行為。由此來說服改進問題。

經驗二十四：所有測試都試圖回答某些問題

執行的測試都是要回答有關現實的產品和應該得到的產品之間關係的某個問題。

在任何測試活動中，都要問自己什麼樣的問題應該推動自己評估測試策略，否則就會更像遊客，而不是測試員。

經驗二十六：直覺是不錯的開始，但又是槽糕的結束

當有問題時，測試員以此處有問題，我直覺認為這是問題。可考慮換中方式，用事實依據說明問題與某需求衝突，直接關係到客戶很看重的需求。

如果只是用直覺來說話，大家都有直覺，很可能測試員的工作建議不會被採納。

經驗三十二：通過會議、推導和參照發現需求

需求文件或多或少是不完整、不準確、沒有提供資訊或沒有幫助的。

測試員把專案文件，看作是唯一需求來源會影響測試過程。

需求資訊達到測試員主要有三種途徑：

》會議。

》推導。通過已知專案和產品其他資訊，確定什麼需求最重要。

》參照。既發現顯式，也發現隱式規格說明。

很多優秀的測試員所使用的大多需求來自推導或隱式規格說明。 

顯示說明來自客戶權威確認，隱式說明來自其內容的說服力和可信性，而不是客戶的批准。

隱式規格說明形式：

>競爭對手的產品

>相關產品

>同一產品老版本

>專案團隊之間的電子郵件討論

>顧客意見

>雜誌文章（例如，老版本的綜述）

>相關主題的教科書（會計書籍適應於會計應用程式）

>圖形使用者介面風格指南

>作業系統相容性需求

>測試員自己的豐富經驗

經驗三十五：不要將實驗與測試混淆起來

測試至少包括的四種活動：

>配置。準備要測試的產品，都要將其置於正確的起始狀態，否則測試結果會受到不良變數的影響

>執行。向產品輸入資料，向產品發命令，以某種方式與產品互動。否則，產品只是放在那裡，測試員能夠做的只是評審，而不是測試。

>觀察。最終知道問題所在

>評估。得到問題存在的機制（構造和原理），否則要麼不提交問題，要麼值提供資料，由客戶自己進行評估。

經驗三十七：當測試複雜產品時：陷入與退出

遇到複雜問題時，先試著冷靜研究產品一段時間，如果過了1個小時還是沒有任何結果，則停下來乾點別的，等其他問題都解決了再來研究。

經驗三十八：運用試探法快速產生測試思路

常用試探法：

測試邊界

測試所有錯誤資訊

測試與程式設計師的配置不同的配置

執行比較難設定的測試

避免冗餘測試

試探法沒有智慧，智慧來自測試員。試探法只是為測試員的思考提出建議

經驗三十九：測試員不能避免偏向，但是可以管理偏向

測試員是有偏向的，有時編輯一個很長的欄位，測試員會輸入11111111，而不是23875019460，因為輸入字元重複的字串，要比0-9的隨機數字容易。這是種很小的偏向，但仍是一種偏向。

更糟糕的偏向是，大多數測試員傾向於測試最可視的功能，而不是最重要的功能。

傾向於考慮認為與自己類似的客戶。

傾向於十餘非常簡單、非常荒謬的輸入，而不是具有中等複雜度的現實輸入。

常見偏向：

同化偏向。把測試結果解釋為自己對產品的看法。

證實偏向。更關注會證明自己對產品看法的測試結果。

可用性偏向。更容易認為自己想到的操作方式常出現。

最初印象偏見。更信任所做的第一次觀察。

更新印象偏見。更信任所做的最近一次觀察。

框架效應。一個問題相似表達卻導致了不同的決策判斷。程式設計師對錯誤報告的反應與錯誤本身的表達和措辭有很大的關係。不管錯誤真正的含義如何。

知名偏向。把碰巧認識的使用者意見放在更重要的位置

表達偏向。期望較小的問題也許有較小的原因，而嚴重問題會有大原因。

測試員不能避免這些偏向，因為這些偏向已經很大程度固話在頭腦中。

解決方案：

通過研究偏向在實踐中注意，則可以更好的補償。

多樣化也可以抵禦過強的測試偏向。如測試員集體討論問題，可以將一個測試員的偏向降到最低限度。

經驗四十：如果自己知道自己不聰明，就更難被愚弄

測試是需要時刻謹慎的，不能疏忽大意。要常記教訓。

經驗四十一：如果遺漏一個問題，檢查這種遺漏是意外還是策略的必然結果

出現遺漏問題先不要過分自責，最需要的是帶著解決問題的思路，檢查問題是如何出現的。

自己是否忠實的執行了策略？是特定情況意外發生？如果是第二種則趁此計劃改善策略。

經驗四十二：困惑是一種測試工具

當測試員感到困惑時，這可能是某種重要提示。

規格不清楚嗎？掩蓋了重要分歧

產品不清楚嗎？產品有嚴重問題      

策略不清楚嗎？策略不夠詳細或者邏輯有問題

流程複雜嗎？導致部門間配合溝通困難

經驗四十三：清新的眼光會發現失效

初次接觸產品時，需特別注意困惑的地方，這也許就是使用者使用時感到困惑之處。

工作時，可觀察同事對產品的反應，從中瞭解自己的不足和盲點

警惕陷入測試慣性。測試完畢後，迴歸和多輪測試最好是交替測試，警防以越來越窄的方式測試。

經驗四十四：測試員要避免遵循過程，除非過程遵循自己

？不懂，後期參閱相關書籍

測試員按照具體的測試過程小心的輸入1287個字元

過於詳細沒有什麼好處。

在編寫測試過程中，要避免與測試概念無關的細化。包含所有必要的資訊和設計與解釋測試所需的細節，但是要讓未來的測試員有創造行和判斷力的執行，讓未來測試員引入變化以使現在所編寫的測試過程新鮮、高效

經驗四十六：測試過程是一個重要成果：是更好、更聰明的測試員

評估測試過程，首要要看專案測試員的素質，要看他們是怎麼思考的，以及這種思考怎麼對其行為產生影響。只有掌握的這些資訊，才能更好的評估他們的工作產品。

經驗四十八：關注測試員、覆蓋率、潛在問題、活動（如何測試。如探索式測試）和評估的組合測試手段

測試員：進行測試的人。不同的測試階段需要不同的人來進行測試。如，內部測試則需要專業的測試人員，α測試是內部其他成員進行測試，β測試則需要真正的使用者進行測試，市場運營代表。

覆蓋率：測試的範圍，測試的功能點。

潛在問題：測試的原因，不測試會有什麼風險。

活動：是否通過測試，怎樣判斷是否通過測試。

經驗五十：關注測試內容的基於覆蓋率的測試手段

功能測試

特性或功能整合測試

選單瀏覽

域測試

等價類分析

邊界測試

最佳代表測試

輸入欄位測試大綱或矩陣

用各種方式對映和測試編輯欄位

邏輯測試

基於狀態測試：讓程式完成能做的事，嘗試不能做的事，每做一件事程式都會有其對應的狀態。

路徑測試：主要路徑和子路徑測試

語句與分支覆蓋

配置覆蓋率

基於規格說明的測試

基於需求的測試

組合測試

經驗五十一：關注測試原因原因基於問題的測試手段

輸入約束

輸出約束

計算約束

資料（儲存）約束：輸入、輸出、計算均沒有問題，產生資料檔案太大，程式不能處理

經驗五十二：關注測試方法基於活動的測試手段

迴歸測試：其目標是為了證明變更使得原來沒有問題的程式現在變得有問題了。

共有三種迴歸測試

1.      程式錯誤得到更正後，再針對性的測試

2.      老程式錯誤迴歸：迴歸的bug還是沒有更正好

3.      副作用迴歸又叫穩定性迴歸：看程式沒有的問題的地方是不是現在變得有問題了

指令碼測試：低階程式設計師執行已經錄製好的指令碼測試

冒煙測試：新版本釋出前，確認基本功能是否實現。或者是更新版本確認修改後的問題是否修復。或者是進行效能測試前，進行基本功能確認的測試。

探索式測試：測試員在不斷了解產品和增長知識的前提下，不斷創新測試。

遊擊式測試：有經驗的測試員在有限的時間內，對軟體進行重點、有目的、有攻擊性行的測試。

場景測試：

場景包含四個屬性：

1.      反應真實情況的場景；

2.      一般是多種複雜情況的組合，包含多個功能，但是不需要窮盡測試；

3.      能比較快速的得出結；

4.      沒有通過測試則需要求立即修改，否則不能通過上線。

安裝測試：不同系統上安裝，或者磁碟上修改某個檔案測試。

負載測試：通過不斷載入的方式，檢視系統在超負載的情況下是否能正常執行。

壓力測試：在高負載的前提下，檢視應用系統在峰值使用情況下操作行為，從而有效地發現系統的某項功能隱患、系統是否具有良好的容錯能力和可恢復能力。壓力測試是為了發現在什麼條件下您的應用程式的效能會變得不可接受。

壓力測試可以說是負載測試的一種，即高負載的負載測試。

長序列測試（或叫持久測試、可靠測試、耐力測試）

效能測試

經驗五十三：關注測試是否通過的基於評估的測試手段

比較權威的資料範圍，校驗資料

與規格說明或者其他權威文件比較

與已經儲存的結果進行比較

基於理論的測試

經驗五十七：使自己的錯誤報告成為一種有效的推銷工具

陳述種種好處，說明潛在的使用者需要

說明預期問題，並反駁他們的不願意修改的理由

經驗六十：引用別人的報告要小心

不要修改別人的報告，補充時需註明時間和姓名

經驗七十二：小缺陷也值得報告和修改

四小時不包括測試時間內能修改好的bug,稱之為低成本修改。這樣的修改能杜絕使用者後續抱怨，低成本修改可避免產品一半以上的技術支援電話。

任何程式都會有些小缺陷，但是隨著小缺陷的增加會使客戶信心下降。

使用者的滿意度，會直接增加產品的市場份額。

經驗七十三：失效是錯誤徵兆，不是錯誤本身

小問題可能是程式結構或者內部指標失效等嚴重錯誤導致。需要重視，並且有相應的後續測試。

不可重現的錯誤

1.任何時候盡力重現，沒有重現的錯誤都需要報告，這樣的錯誤可能是時間炸彈。

測試員不能重新的錯誤，程式設計師可以通過對程式的瞭解程度，定位到問題，或者後期再出現時測試人員也可以根據報告和現有資訊重新問題。

2.不可重現的錯誤是可重現的。

可能是操作順序