第一篇：軟件測試經驗小總結

需求分析階段：

1,增加的新功能,以及需求變動, 要考慮到測試范圍的變化,務必確保沒有因為變動引起測試遺漏.2,拿到需求以后,及時跟開發溝通各個功能點什么時候能夠開發完成;尤其在第一個初步的版本出來以后,要跟他們確認下缺失的功能點.因為有個時候開發會遺漏功能點, 盡量想辦法把問題提前發現.測試階段：

采取冒煙測試－〉回歸測試－〉系統測試，這樣的測試流程。

3, 冒煙測試的時候,所有的模塊都要冒煙,即便有些模塊最近都沒有改動過。因為模塊集成后，可能因為某些模塊的變動引起其他模塊的功能失效

Bug相關：

４, 不同瀏覽器的問題, 要在標題里加注

非IE瀏覽器的問題,發現以后在IE里驗證.５, UI的問題，一定要截圖，除了方便開發定位，另外還起到紀錄的作用。

6, Bug標題: 要描述清楚是什么錯誤.看一眼標題就可以知道標題描述的是期待結果還是實際結果。

7, Bug描述: 某某功能錯誤,或記錄錯誤的, 一定要在描述里寫明復現步驟，是什么錯誤,怎么錯了.8, 激活Bug：Re-active Bug的時候,要寫明是什么地方測試未通過,存在什么問題.9, 一個Bug只記錄跟蹤一個問題：驗證Bug的時候，如果發現該Bug引發了新問題，不要再激活原Bug, 應新建一個Bug,但要在原Bug上鏈接到新Bug.確保一個Bug只記錄跟蹤一個問題。

10, 出現的Bug都有記錄：Bug與開發直接溝通的,確認是一個Bug的,一定要在TFS里提交Bug，確保每個出現的Bug都有記錄,方便以后跟蹤.11, 每次給客戶部署的版本,要記錄下此版本上存在的Bug.測試階段：

1、遇到時間緊，人手不夠不能充分進行測試時，著重對新模塊和修改過的模塊進行測試，其他模塊進行簡單冒煙

2、必要的隨機測試很重要，往往能發現一些按照用例跑所發現不了的bug，最好是讓測試人員隨機跑其他人員的模塊（簡單的交叉測試）

用例設計階段：

正常流程的用例要有，最關鍵的是對于異常情況考慮要全面，用例覆蓋面很重要，必要的時候要多次評審測試用例

需求分析階段

盡量聽取第一手需求，盡量避免從開發人員那里獲得需求然后按照他們的思路來測試，這樣測試人員的思路會被開發人員帶著走，不便于發現隱藏問題（吃過虧的都知道

解Bug：

1、如果部署了正式環境上發現有頁面問題，聯系開發人員盡快解決，通過替換文件的方式而不用重新發版本，因此這種bug越早發現越好

2、項目時間緊張時候，如果遇到非常嚴重的bug，除了在工具里提交bug之外還要馬上聯系開發人員告知bug，因為有時候開發人員沒時間及時的去查看bug列表

3、每個人對自己分配的測試模塊要去盯開發人員，不能拖著，不然開發人員很容易遺忘）

第二篇：軟件測試總結

面向對象程序的軟件測試方法

在軟件生命周期過程中，軟件測試是保證軟件質量的關鍵環節之一。面向對象方法學在軟件工程中的引入極大地方便了軟件的設計、開發和維護，為創建高可靠性的軟件系統提供了重要保證。但面向對象程序的封裝、繼承、多態和異常處理機制等新特性卻給測試帶來新的挑戰。一方面需要調整、改進傳統的測試策略和方法；另一方面探索出適應面向對象程序特征的測試理論與技術也尤為必要。

面向對象(Object Oriented,OO)是當前計算機界關心的重點，它是90年代軟件開發方法的主流。面向對象的概念和應用已超越了程序設計和軟件開發，擴展到很寬的范圍。如數據庫系統、交互式界面、應用結構、應用平臺、分布式系統、網絡管理結構、CAD技術、人工智能等領域。

面向對象的定義或說明對象的定義的非常少。其初，“面向對象”是專指在程序設計中采用封裝、繼承、抽象等設計方法。可是，這個定義顯然不能再適合現在情況。面向對象的思想已經涉及到軟件開發的各個方面。如，面向對象的分析（OOA，Object Oriented Analysis），面向對象的設計（OOD，Object Oriented Design）、以及我們經常說的面向對象的編程實現（OOP，Object Oriented Programming）。許多有關面向對象的文章都只是講述在面向對象的開發中所需要注意的問題或所采用的比較好的設計方法。看這些文章只有真正懂得什么是對象，什么是面向對象，才能最大程度地對自己有所裨益。這一點，恐怕對初學者甚至是從事相關工作多年的人員也會對它們的概念模糊不清。

1、面向對象的基本概念

(1)對象。

對象是人們要進行研究的任何事物，從最簡單的整數到復雜的飛機等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規則、計劃或事件。

(2)對象的狀態和行為。

對象具有狀態，一個對象用數據值來描述它的狀態。

對象還有操作，用于改變對象的狀態，對象及其操作就是對象的行為。

對象實現了數據和操作的結合，使數據和操作封裝于對象的統一體中

(3)類。具有相同或相似性質的對象的抽象就是類。因此，對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。

類具有屬性，它是對象的狀態的抽象，用數據結構來描述類的屬性。

類具有操作，它是對象的行為的抽象，用操作名和實現該操作的方法來描述。

(4)類的結構。

在客觀世界中有若干類，這些類之間有一定的結構關系。通常有兩種主要的結構關系，即一般--具體結構關系，整體--部分結構關系。

①一般——具體結構稱為分類結構，也可以說是“或”關系，或者是“is a”關系。

②整體——部分結構稱為組裝結構，它們之間的關系是一種“與”關系，或者是“has a”關系。

(5)消息和方法。

對象之間進行通信的結構叫做消息。在對象的操作中，當一個消息發送給某個對象時，消息包含接收對象去執行某種操作的信息。發送一條消息至少要包括說明接受消息的對象名、發送給該對象的消息名（即對象名、方法名）。一般還要對參數加以說明，參數可以是認識該消息的對象所知道的變量名，或者是所有對象都知道的全局變量名。

類中操作的實現過程叫做方法，一個方法有方法名、參數、方法體。消

2、面向對象的特征

(1)對象唯一性。

每個對象都有自身唯一的標識，通過這種標識，可找到相應的對象。在對象的整個生命期中，它的標識都不改變，不同的對象不能有相同的標識。

(2)分類性。

分類性是指將具有一致的數據結構(屬性)和行為(操作)的對象抽象成類。一個類就是這樣一種抽象，它反映了與應用有關的重要性質，而忽略其他一些無關內容。任何類的劃分都是主觀的，但必須與具體的應用有關。

(3)繼承性。

繼承性是子類自動共享父類數據結構和方法的機制，這是類之間的一種關系。在定義和實現一個類的時候，可以在一個已經存在的類的基礎之上來進行，把這個已經存在的類所定義的內容作為自己的內容，并加入若干新的內容。繼承性是面向對象程序設計語言不同于其它語言的最重要的特點，是其他語言所沒有的。

在類層次中，子類只繼承一個父類的數據結構和方法，則稱為單重繼承。

在類層次中，子類繼承了多個父類的數據結構和方法，則稱為多重繼承。

在軟件開發中，類的繼承性使所建立的軟件具有開放性、可擴充性，這是信息組織與分類的行之有效的方法，它簡化了對象、類的創建工作量，增加了代碼的可重性。

采用繼承性，提供了類的規范的等級結構。通過類的繼承關系，使公共的特性能夠共享，提高了軟件的重用性。

(4)多態性(多形性)多態性使指相同的操作或函數、過程可作用于多種類型的對象上并獲得不同的結果。不同的對象，收到同一消息可以產生不同的結果，這種現象稱為多態性。

多態性允許每個對象以適合自身的方式去響應共同的消息。

多態性增強了軟件的靈活性和重用性。

面向對象方法的基本思想是一：面向對象方法是一種運用對象、類、封裝、繼承、多態和消息等概念來構造、測試、重構軟件的方法。

二： 面向對象方法是以認識論為基礎，用對象來理解和分析問題空間，并設計和開發出由對象構成的軟件系統（解空間）的方法。由于問題空間和解空間都是由對象組成的，這樣可以消除由于問題空間和求解空間結構上的不一致帶來的問題。簡言之，面向對象就是面向事情本身，面向對象的分析過程就是認識客觀世界的過程。

面向對象方法從對象出發，發展出對象，類，消息，繼承等概念。

面向對象方法的主要優點是：符合人們通常的思維方式；從分析到設計再到編碼采用一致的模型表示具有高度連續性；軟件重用性好。

面向對象軟件測試的特點是: 1.掌握代碼檢查、走查與評審的基本方法和技術； 2.掌握白盒測試和黑盒測試的測試用例的設計原則和方法； 3.掌握單元測試和集成測試的基本策略和方法；

4.了解系統測試、性能測試和可靠性測試的基本概念和方法； 5.了解面向對象軟件和WEB應用軟件測試的基本概念和方法； 6.掌握軟件測試過程管理的基本知識和管理方法； 7.熟悉軟件測試的標準和文檔；

8.掌握QESuite軟件測試過程管理平臺和QESat/C++軟件分析和工具的使用方法。

第三篇：軟件測試總結

1.軟件測試定義：由人工或自動方法來執行或評價系統或系統部分的過程，以驗證它是否滿足規定的需求，或識別出期望的結果和實際結果之間的差異。2.軟件測試的分類：

測試對象或范圍分類：需求評審、設計評審、單元測試、程序測試、系統

測試、文檔測試、Web應用測試、客戶端測試、數據庫測試等；

測試目的分類：集成測試、功能測試、壓力測試、性能測試等等； 靜態測試、動態測試； 白盒測試、黑盒測試。3.軟件測試的基本流程與原則

基本流程：

測試用例設計-輸入數據、預期結果； 測試執行-輸入數據執行被測對象； 檢查實際輸出與預期結果。基本原則：

開始測試時認定軟件有錯，測試要證明有錯； 測試應該由獨立的測試團隊來完成； 測試設計必須設計對應的預期輸出；

要對合理、不合理（有效、無效）輸入數據都進行測試； 檢查軟件的完備性、多余； 完整保留測試文檔；

一個被測對象中有錯誤的概率與已發現錯誤的個數成正比。4.Beizer測試成熟度級別：

0級：沒有區分測試與調試；

1級：測試的目的是證明軟件能用； 2級：測試的目的是證明軟件不能用；

3級：測試的目的不是為了證明什么，而是為了降低軟件使用風險； 4級：測試是一種智能訓練，能夠幫助專業人員開發出更高質量的軟件。5.軟件測試與軟件工程，軟件過程的關系：

軟件工程：在給定的條件下（成本、時間）開發出高質量的軟件產品。軟件生產過程的特性決定了軟件產品中不可避免包含有錯誤。軟件測試則是盡可能多地發現錯誤，從而保障軟件產品的質量。6.McCall的質量因素：

產品修改：

可維護性，靈活性，可測試性 產品轉移：

可移植性，可復用性，互操作性 產品運行：

正確性，易用性，可靠性，效率，完整性 7.軟件質量困境

軟件質量必須足夠好：存在價值

軟件產品無法完美：需要消耗過多的資源、時間、成本

軟件開發需要在兩個極端之間進行平衡：軟件足夠好的同時又不完美。8.質量控制、質量保證和質量管理

軟件質量控制其實是基本方法，通過一系列的技術來科學地測量過程的狀態。如缺陷率、測試覆蓋率等。

軟件質量保證則是過程的參考、指南的集合，如ISO9000、CMM/CMMI等，著重內部的檢查，確保已獲取認可的標準和步驟都已經遵循。

軟件質量管理則是實際操作的思想，質量管理控制和協調組織的質量活動，包括質量控制、質量保證和質量改進。9.WebApp應用的屬性：

網絡密集型應用；并發性；大負載量；性能；高可靠性、高可用性；安全性-內容敏感；

10.軟件評審的目的，評審度量及其應用

評審的目標在于：盡早發現軟件過程中的錯誤，防止錯誤傳遞、蔓延至后續活動，防止錯誤轉化為缺陷。

準備工作量Ep-實際評審會之前所需工作量； 評估工作量Ea-實際評審所花費的工作量 返工工作量Er-修改評審所發現錯誤的工作量 工作產品規模WPS-評審對象的規模

發現的主要錯誤數Errmajor-多于預期的改錯工作量的錯誤數目 發現的次要錯誤數Errminor-少于預期的改錯工作量的錯誤數目 總評審工作量Ereview = Ep+Ea+Er 錯誤總數Errtot = Errmajor+Errminor 錯誤密度：評審的每單位工作產品發現的錯誤數Ed = Errtot / WPS 錯誤密度數值的含義：較小（產品質量非常好或評審不夠徹底）；較大（產品質量存在缺陷）

11.軟件測試計劃：描述對計算機軟件配置項、子系統、系統進行測試的計劃安排，內容包括測試的環境、測試工作的標識及測試工作的時間安排。

軟件測試報告：是對計算機軟件配置項、軟件系統或子系統，或與軟件相關項目執行合格性測試的記錄 12.軟件測試活動

制訂測試計劃（測試分析員）

測試設計（測試設計人員）－方案設計 測試及測試用例設計 測試過程

樁模塊、驅動模塊設計

測試實施（測試設計員）－實現測試設計 單元測試（測試員）集成測試（測試員）系統測試（測試員）

評估測試（測試設計人員）

13.無向圖的相關定義：

連接性：節點ni、nj是連接的，當且僅當ni、nj在同一條路徑上。組件：圖的組件是相連節點的最大集合

圖G的圈復雜度V（G)＝e－n＋2p，其中e為G的邊數，n為節點數，p為組件數。14.圖覆蓋：給定一個關于圖G的準則C的測試需求集合TR，測試集合T在圖G上滿足準則C當且僅當對TR中每個測試需求tr，path(T)中至少存在一條測試路徑p滿足tr。

簡單路徑：如果從ni到nj的一條路徑中，除了始節點和終節點可以相同外，沒有任何節點出現次數多于一次，則該路徑為簡單路徑。

主路徑：如果從ni到nj是一條簡單路徑，并且它不作為任何其他簡單路徑的子路徑出現，則稱之為主路徑。

主路徑覆蓋（PPC）準則：TR包含圖中每一條主路徑。

指定路徑覆蓋（SPC)：TR包含一個測試路徑集S，S為指定參數。15.白盒測試方法

白盒測試：根據被測對象的內部結構和運行機制來設計測試用例的方法，又稱為結構測試、邏輯驅動測試、覆蓋測試

被測對象的獨立路徑至少覆蓋一次； 所有邏輯取值測試[真、假]； 循環邊界測試；

檢查內部數據結構、邊界條件。16.黑盒測試方法

黑盒測試方法又稱功能測試方法、數據驅動測試方法，測試設計時不考慮被測對象的內部結構，以檢查系統功能（功能的正確、完整、邏輯流程、人機界面、文檔內容、系統安裝/初始化）

以被測對象的外部特征為測試依據。17.模糊測試方法

模糊測試方法：構造大量的隨機數據作為系統的輸入，從而檢驗系統在各種數據情況下是否出現問題。

18.增量測試：單元測試、調用依賴的模塊集成測試，逐步擴展直到形成整個軟件系統。

19.突擊測試：所有模塊一次性集成為一個完整的系統，然后進行完全測試。20.等價類劃分：

等價類劃分基于對輸入或輸出數據情況的評估，劃分成兩個或多個子集（等價類），然后從每個子集中選取一定的代表進行測試的測試用例設計方法。21.極限測試

極限編程：利用輕量、敏捷的開發過程，使開發人員能夠更快地完成應用程序的開發。強調頻繁測試、測試驅動的方式保證軟件質量。

極限測試：為滿足極限編程思想和過程而設計的一套測試策略和流程，原來的測試技術、方法均可以使用 22.配置項測試的內容

功能: 適合性

準確性：功能的準確與精度要求 互操作性：與外部設備、系統的接口 安全保密性：數據訪問的可控制性 可靠性: 成熟性：容錯處理、平均無故障時間

容錯性：邊界條件、功能、性能的降級情況、誤操作模式、故障模式 易恢復性：自動修復能力/時間、平均宕機時間、平均恢復時間、恢復能力等 易用性

易理解性：功能描述清晰、準確；界面含義精確

易學性：在線幫助、幫助定位、各類手冊的易學、易用 易操作性：數據的有效檢查、解釋信息明確、界面切換 吸引性：人機界面定制 效率

時間特性：響應時間、平均響應時間、響應極限時間、吞吐量、平均吞吐量、極限吞吐量，多任務并行測試

資源利用：大量并發任務下I/O設備利用、極限負載下I/O設備的負載、大量并發任務下用戶等待時間、內存使用情況、數據傳輸能力等

維護性

易分析性：運行狀態數據易分析 易變更性：軟件的可配置、修改能力 易測試性：變更之后的易測試情況 可移植性

適應性：不同軟件、硬件環境的適應能力 易安裝性：安裝、配置的復雜程度、難以程度 共存性：與其他軟件協同的能力 易替換性：版本的替換難以程度 依從性

以上所有特性遵循標準、規范的情況測試

23系統測試：系統非功能性測試，以檢驗系統在超常數據規模或負載下，線程、CPU、內存資源的利用和響應時間、數據傳輸等性能指標是否滿足要求

24.測試計劃

確定測試充分性要求：覆蓋范圍、覆蓋程度 確定測試終止要求； 確定測試所需資源； 確定測試的軟件特性； 確定測試技術、方法； 確定測試準出條件； 確定測試進度計劃； 測試風險分析。

25.測試設計：測試設計人員、測試程序員

測試用例設計：依據測試特性； 獲取測試數據；

確定測試順序：資源、被測特性； 獲取測試資源：軟硬件、工具； 編寫測試程序； 建立測試環境； 撰寫測試設計說明。

26.測試總結：

測試分析員－測試報告

總結測試計劃、測試說明的變化情況； 異常終止時測試未覆蓋范圍； 未能解決的測試問題； 總結測試結果（發現問題）； 編寫測試報告；

根據問題報告、測試記錄，編寫測試問題報告。

27.軟件可靠性：在給定的運行時間內和給定的系統配置環境下，運行給定的軟件功能時所 表現出來的質量能力 28.系統性能指標

系統資源利用率：分析性能指標，改善性能系統行為指標 請求響應時間：一次請求完成時間

事務響應時間：一個事務所有請求完成的總時間

數據吞吐量：單位時間內服務器接收、發送的數據量。

29.驗收測試：用戶執行的、使用真實數據進行的測試，依據需求規格中的確認標準進行測試。回歸測試：驗證已測試過的內容不受變更影響，確認變更沒有引入新的錯誤。

30.α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操 作環境下進行的測試。

Beta測試由軟件的最終用戶在一個或多個客戶場所進行，開發者通常不在Beta測試的現場。

31.WebApp測試關注的主要內容 Web內容測試 界面 構件

導航測試 安全性 性能

32.測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。

33.軟件生存期定義：從軟件產品設計到軟件被淘汰的時間段。又稱軟件生命周期、生存周期。進一步劃分為兩個階段：開發階段和維護階段（40%+60%）。

34.軟件安全定義：一種軟件質量保證活動，他主要用來識別和評估可能對軟件產生負面影響并促使整個系統失效的潛在災難。

35.軟件評審的目標在于：盡早發現軟件過程中的錯誤，防止錯誤傳遞、蔓延至后續活動，防止錯誤轉化為缺陷。36.V模型

優點：既有底層測試又有高層測試。底層：單元測試。高層：系統測試。

將開發階段清楚的表現出來，便于控制開發的過程。當所有階段都結束時，軟件開發就結束了。

缺點：容易讓人誤解為測試是在開發完成之后的一個階段。

由于它的順序性，當編碼完成之后，正式進入測試時，這時發現的一些bug可能不容易找到其根源。

實際中，由于需求變更較大，導致要重復變更需求、設計、編碼、測試，返工量大。37.W模型：

優點：

將測試貫穿到整個軟件生命周期中，且除了代碼要測試，需求、設計等都要測試。更早介入軟件開發中，能盡早發現缺陷并修復。

測試與開發獨立起來，并與開發并行。缺點：

對有些項目，開發過程中根本沒有文檔產生，故W模型無法使用。

對于需求和設計的測試技術要求很高，實踐起來很困難。

從N0中某節點開始到Nf中某節點結束的一條路徑稱為一條測試路徑。

1.軟件缺陷：（符合下列規則的叫軟件缺陷)：

１）．軟件未達到產品說明書的功能

２）．軟件出現了產品說明書指明不會出現的錯誤

３）．軟件功能超出產品說明書指明范圍

４）．軟件未達到產品說明書雖未指出但應達到的目標

５）．軟件測試員認為難以理解、不易使用、運行速度緩慢、或者最終用戶認為不好

2.單元測試：單元測試是對軟件設計的最小單元——模塊進行正確性檢驗的測試工作，主要測試模塊在語法、格式和邏輯上的錯誤。3.回歸測試

指軟件系統被修改或擴充（如系統功能增強或升級）后重新進行的測試，是為了保證對軟件所做的修改沒有引入新的錯誤而重復進行的測試。

4.等價類：指某個輸入域的子集合，在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。

第四篇：《軟件測試經驗與教訓》讀后感

<<軟件測試經驗與教訓>>讀后感

看了<<軟件測試經驗與教訓>>第7、8、11章節后，對照以前的工作情況，感悟比較深的是以下幾點：

1、回想測試BA100項目時，和開發工程師的關系處得非常緊張，出現問題相互責備；開發工程師曾經提出不要打擊和嘲笑他們的要求。看完了與程序員交互這一章節后，明白程序員不是編碼機器，有感情，大多數人都非常在乎所在工作。我們作為程序員的正式批評者，要避免正面沖突情況，要有團體合作精神，相互幫助相互信任；這樣會讓他們愿意共享信息，使測試工作更有效。向領導只反映所發現的問題不是反應程序員的能力。

2、我們在測試過程中提出一些理解有誤或是路徑不明確的問題，也有一些描述不清楚的問題；今后嚴格要求自己，發現問題就要堅持自己的觀點，要提出令人信服的問題，并準確清楚描述問題，一步一步地將問題給出，沒有多余步驟。使問題描述易讀，容易理解。只談論所看到的現象，不要猜測內部問題的性質，避免開發查找問題時花大量時間。

3、在測試BA100項目時，開發工程師沒有做好準備就發布版本，測試員拿到版本直接升級或安裝，結果發現正常功能無法執行，但是還在繼續測試，或者大家需要退回舊版本重新等待開發再次發布；對于正常功能無法執行的版本我們應該拒絕這種測試版本。我希望以后項目使用冒煙測試，就是發布新版本時，安排一名測試員花上半天時間運行冒煙測試，其他人員等改版本通過冒煙測試才投入測試；這樣就不會浪費大家時間。

4、以前我一直認為：2個測試員測試同樣的內容是浪費時間，現在看完測試策略這一章節以后明白并不是一回事，2個測試員測試同樣的內容也許并不是重復勞動，可能發現不同的問題，可以注意到另外一個測試員忽視的問題，而這種問題都是比較嚴重的問題，不易發現。

第五篇：軟件測試經驗與教訓評論

<軟件測試經驗與教訓>評注

作者： 傅健，jiafu@cisco.com(轉載請注明作者)

經驗6： 非常贊同，注重線下溝通方式，與開發做朋友，更容易發現更多測試思路，解決好問題； 經驗10： 測試過程如若不限時間，很難定義窮盡之時，完美只是在指定時間/成本/質量要求下滿足老板的要求。

經驗11： 測試不能保證質量，非常贊同這個說話，考慮兩個因素：（1）你給的時間和成本是多少？如果是0，提什么保證質量？（2）質量形成與構建者，也受其他人制約，例如三聚氰胺奶粉生產商不知道自己加了嘛？

經驗13 ：測試確實應該盡其所能，橫向上覆蓋產品的設計，開發，發布，售后等過程，縱向覆蓋與其他模塊的交互；但是需要分析下為什么測試者往往有“不關我事”理論，無非涉及到管理的層面，例如：（1）薪資等不平等；（2）承接模塊過多，失去興趣和信心；

經驗14 ：過程改進很傷感情，測試人員在測試前期不應該成為吹毛求疵的挑剔者，如果如此很可能出現兩種情況：（1）開發的代碼還沒有完成階段，但明知有很多bug之地，這個時候QA不斷提出bug,勢必影響開發心情。尊重開發的開發過程很重要；（2）開發的設計或許有其他思路，QA不斷強調并說服開發者上司采用其他思路，如果不是非常有把握，就不要自作聰明強烈地說服開發者上司，這樣最后往往被證明不定合理；

經驗15：不要指望別人理解測試，需要不斷向別人解釋，這點在其他領域也適用，很多時候事實并不是就是事實，而是觀察者眼中的“事實”，因此推銷是門學問，“指鹿為馬”未嘗不可做到。

經驗21：測試遺漏的問題更多集中在沒有想到的用例，而不是執行不力；

經驗22：所以進行Code審查更多的是了解設計從來更好的測試，不能指望直接發現代碼錯誤； 經驗30：任何量的測試都不能“確定”一個產品的質量，證明失效比證明正確容易的多。

經驗31：客戶需求多變，或許自己也不明白真正要什么，需求分析即是輔助、辨別需求。

經驗32： 隱式規格說明很重要，很多測試依據都是這些“潛規則”，顯式說明文檔不可能也沒有必要面面俱到。

經驗33：測試員中的“它沒有問題”，與他人眼中不同。

經驗34：對質量印象只能限定在已知局限的前提下；

經驗35：配置、運行、觀察、評估是行為層面的用例；

經驗37：對于復雜的任務模塊需要間歇思考、細化擊破，同樣對于測試工作一樣，過大的壓力，無休止的加班不定有好的測試結果。測試應該有更多的思考時間；

經驗39：防止思維定勢，提倡多人思考互補，不用去偏執的帶有目的去證明缺陷，而是平常心的客觀測試。

經驗43：應該提倡結對測試，互補思考，同時要攻破“難”點，越復雜之地越容易出問題，且多次出現頻率更高。

經驗45: 測試用例過于細節話，有可能限制測試者的想象力和創造性，之所以同一個CASE跑出不同的結果往往也和測試用例不過于細節化有關，但我認為不細節化一定程度上是好事情。

經驗46：現在很多人還是以BUG數量、測試效果來衡量測試人員的水平，這條經驗告訴人們要看測試人員如何思考；同時我們應該加強測試人才的培養與重視，不要僅僅為的是表面化的一些工作； 經驗90：同行評審是個培訓、提高的好方式；

經驗103： 重試不同、多樣測試比反反復復運行自動化腳本有效的多；

經驗108： 專業培訓的測試員的頭腦是最好的測試工具；

經驗114： 如果不是非常優秀的開發人員，且具有良好的測試思維，就不要開發測試工具，否則一旦推廣害人害己，因為測試工具問題往往比普通產品更容易出現；

經驗117： 自動回歸測試有時候不能將改進和錯誤區分，特別是界面和輸出格式變動；

經驗118： 評估開發機構級別五級底部還有個級別是忘卻（Oblivious）級，很多自動化測試沒有提醒自己在執行軟件開發過程；

經驗122：評審自動化測試代碼比用代碼測試自動化測試代碼好；因為后者容易陷入一個無限的邏輯；

經驗130： 建議測試數據與測試執行分離；

經驗132： 自動化是否繞過界面直接操作API取決于到底是界面穩定還是API穩定；盡量依賴穩定的東西；

經驗133： 單元集成測試值得執行；

經驗137： 提早測試自動化的好處：1）均衡時間，前期可能不是太忙；2）防止后期測試已經進行中要求自動化所帶來的抵觸心理；3）在開發完成前可以讓開發提供更多的可測性；

經驗143： 流程、模板都是用來規范人的行為的，只有不斷了解、改善才有意義，如果一個流程、模板不允許任何應需改變則無意義；

經驗146： 形式化工作越多，往往本質工作預留的時間越少，思維也限制的更固定；

經驗148： 自己的測試文檔是產品還是工具？這個問題很好；過于頻繁的細節不要寫到文檔里，否則以后更新繁瑣；

經驗154： 不要利用程序員的弱點或透露的缺陷直接上報，類似于打小報告，以后的合作會減弱很多； 經驗157： 測試是一種服務，不是控制，無法控制最終產品的質量；

經驗168： 任務完成時間評估，應由掌握最佳知識的人進行，或者由估計錯誤需要負責的人執行，而不是根據測試經理的主觀期望。

經驗173： 可以拒絕某個版本的測試：1）新的版本很快就有，這個版本的測試結果會被忽略；2）重要的功能點沒有添加；3）基本功能點不工作，導致大部分測試無法進行；

經驗182： 提前應對可能風險，將潛在的風險預處理劃分到項目的各個階段而不是后期應急處理； 經驗183：測試思考中總體認為產品不是一天做出的，而是慢慢堆積出的，只要有東西提交，就有可測之地，同時越早越好，只是需要抱著同情、謹慎心態等不同心態而已；

經驗186：考慮二輪以上測試；

經驗189： 測試：開發人員比例這種問題如果不結合具體項目及要求就不要提！

經驗197：測試小組的真正力量是溝通，而非監管；

經驗199： Bug數隨進度推進而不斷降低不能完全說明質量已經符合要求，因為后期可能從事非發現缺陷的活動：如展示產品、回歸測試等；簡單說：當看到BUG數連續幾天較少時，不要完全覺得是產品質量變好，而可能是最近沒有從事太多新的測試；

經驗211： 要給予員工自己的思考、執行時空自由，尊重他們的測試思路，而不是模板化；

經驗213： 非常贊同：指明了如何評價一名測試人員的工作，但是很多公司做不到，因為很辛苦。或許他們更傾向于用BUG數來衡量，這樣簡單明了，雖然不正確。

經驗215： 贊同，所以假設必須分配多個任務給同一個員工，不要糾錯式的責備某個時刻某個任務沒有做好;

經驗216： 測試經理在測試產品領域的視角要開闊；

經驗220： 多了解員工的期待與現實感覺，不僅僅對于新員工需要這么做，留住老員工也是必須的，否則會出現離職都不知道真實原因的情況。關心員工、與員工做朋友非常重要。

經驗225： 不要在項目末尾添加新手，有可能起到相反作用，這點在項目管理上也提到；同時不要為了以后可能有的培訓或者職位更換理由，浪費太多時間在文檔活動；在開發程序時也一樣，不要為了以后可能還用不到的需求做無限擴大需求活動，否則永無盡頭且不實際。

經驗226：經理應該 客觀評價事物，不要不懂裝懂，否則容易誤導員工，有失公正；

經驗227： 不要使自己陷入導致工作失敗（如工作量過大）或者沒有希望的工作上，最終只會使自己的情緒受到傷害。管理者總是覺得應該給能者更多的工作，而員工則希望更多的休息，如果給予信任的員工更多的工作，最終可能導致其失敗并有損情緒，實際上就是摧殘而已。

經驗228： 測試經理不應該是傳話筒，否則有可能是成為不同決策者的執行機器，而應該是中間溝通協調層，保護其員工不受不同決策者的不同觀點的影響，但是這種保護應該是正確的觀點指導下。經驗235：多樣化是項目團隊建議的良藥；

經驗238：跳槽時不要顯示對原來公司的不滿或泄露原公司的信息；

經驗239：速度測驗高分只能反映是腦力兔子，或者有可能是訓練、練習所致；而低分者可能是腦力烏龜，慢工出細活。

經驗245： 從職業發展角度來說，掌握測試技術本身比掌握專業業務邏輯更好，當然這里的專業業務是銀行系統等的話，另當別論。

經驗250： 面試貫徹2個逐條：逐條解釋簡歷中的每條：逐條解釋招聘要求的每個條目為什么自己符合，不符合，但是可以很快學習的地方；

經驗252： 和其他公司測試員建立聯系，有助于以后的職業發展。

經驗253： 如有可能，多休息也是一種緩和跳槽的想法；

經驗278：測試計劃經常漏掉如何保障測試策略的執行與工作產品；

經驗280：討論風險和覆蓋率，研究用例內容比單純統計測試用例數量更有意義；

經驗284： 策略決策可利用資源可簡單歸納為：人、事、物；

經驗285： V字軟件測試模型強調軟件測試策略早先制定，實際上隨著測試的深入，策略會因風險識別的準確度提高等因素而做出調整，因為V不是非常好的項目組織方法。

經驗286： 不要將測試局限在某個階段，抓住一切機會測試可以測試并值得測試的事物；

經驗297：項目初期：同情的測試；開發只想知道已經完成的功能的測試結果，不是想知道自己還沒有做的功能的測試結果；整個測試按項目發展分為：同情地測試-》積極地測試-》多樣地測試=》謹慎地測試；

經驗292： 當遇到測試問題過多的模塊（可能需要其他設計替換），應提醒開發，不要再痛打落水狗；要測試模糊不清的地方（接口之地、新的技術方案、需求模糊之地）；測試員負責任務之間的縫隙處（交叉部分）容易出問題；

總結：

（1）關注如何思考；

（2）關注本質，少看數量；

（3）關注多樣化；

（4）強調結對測試；

（5）測所有可測之地，越早介入越好；

（6）不同階段，擁有不同心態；