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

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

作者： 傅健，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）不同階段，擁有不同心態；

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

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

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

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

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

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

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

第三篇：軟件測試經驗與教訓 學習筆記 1 1-15

測試員是項目的前燈。測試就是要找到信息。測試的使命決定要做的一切。快速找出重要軟件問題，對產品質量提出總體評估，確認產品達到某種具體標準，幫助客戶改進產品質量和可測性，保證測試過程能夠達到可分清責任的標準，就測試和與測試員協作方式培訓客戶，采用特定的方法集或遵循特定的規則集，幫助預測和控制支持成本，幫助客戶改進其過程，以最小化成本，時間或盡可能減少副作用的方式，完成自己的工作，為滿足特定客戶要求，完成所有必要的工作。測試員為很多客戶服務。項目經理----向此客戶報告工作狀態，迅速報告重要問題。程序員---向此客戶提供好的錯誤報告。技術文檔編寫員---向此客戶報告文檔類型錯誤，技術支持員和市場開發員，項目負責人，用戶。測試員發現的信息會打擾客戶。測試團隊需要根據客戶對價值的定義，通知客戶有關威脅產品價值的任何信息。迅速找出重要程序問題。首先測試經過變更的部分，后測試沒有變化的部分。先核心功能，后輔助功能，先測試能力后測試可靠性，先測試常見情況，后測試少見情況。先測試常見威脅，后罕見威脅，先測試影響大的問題，后影響小的問題，先測試最需要的部分，后測試沒有要求的部分。跟著程序員走。及時的向程序員報告發現的問題。讓程序員成為項目的瓶頸。詢問一切，但不是外漏。測試員想到的任何問題，都會有助于啟發自己的思想，最終產生對問題新的認識測試員關注失效，客戶才能關注成功。不能說 通過測試來確認程序正常，只能說 就我所執行的測試來說，沒有發現產品不正常。測試員通過發現程序中客觀存在的問題，是為了更好的能夠幫助項目團隊更加了解自己的技能以及產品風險。不會發現所有程序問題。知道并承認自己不能做所有的事之后，測試員必須選擇如何使用自己的時間 10 當心“完備的”測試。總結自己實施的測試以及為什么值得實施這些測試，并告訴客戶自己沒有做的其它值得做的測試，以及為什么沒有做這些測試。通過測試不能保證質量。測試員測試和錯誤報告提供促進項目質量保證的信息，但是這種保證要來自整個團隊。永遠別做看門人。要由控制項目，條件最好的人承擔發布產品的責任。當心測試中的不關我事理論。應盡其所能，通知團隊可能會對產品的價值產生消極影響的所有問題。14 當心成為過程改進小組。可以成為過程改進的一員，但避免成為全部。別指望任何人會理解測試，或理解測試員需要什么條件才能搞好測試。測試員可以向管理層和程序員提供幫助自己的機會

第四篇：軟件測試經驗與教訓 學習筆記2 16-30

Flowing is the today's summary.測試運用的是認知論。認知論研究如何認識所了解的東西，研究證據和推理。目標是了解如何才能改進我們的思維。多用how提問。how to know the software is perferct? if it is not perfect how to know?研究認識論有助于更好的測試 研究認識論 可幫助測試員設計有效的測試策略，更好的意識工作中的錯誤，理解自己的測試能證明什么，不能證明什么。入門書籍 《批判性思維的工具:心里學的元思想》，《思考與決策》，《研究的技巧》認知心理學是測試的基礎。認知 心里 學 告訴 我們的是我們是如何思考的。有助于理解 影響測試員工作成績的因素，以及影響人們理解自己工作方式的因素。測試在測試員的頭腦中。注重測試設計選擇，解釋所觀察的現象的能力，以及非常令人信服的分析描述這些現象的能力。測試需要判斷，并不是只做輸出與預期結果的比較。掌握探索時推斷的藝術。以一種不能事先預測的方式，通過一種思想引出另外一種思想，然后再引出下一種思想。優秀測試員會進行技術性，創制性，批判性和實用性地思考。黑盒測試并不是基于無知的測試 更應該了解用戶，了解結束，了解軟件運行環境的配置，了解開發過程，了解這個軟件要與之交互的其他軟件。黑盒強調有關軟件的用戶和環境知識。測試員不只是游客。測試員做的大量非測試事是為了更好的了解產品，但是需要把精力放在評估產品上。所有的測試都試圖回答某些問題。所執行的測試，都是要回答有關現實的產品和應該得到的產品之間關系的某個問題。所有的測試都基于模型。學會一種對產品建模的新方法，就像是學會了觀察產品的一種新方法。26 直覺是不錯的開始，但又是糟糕的結束。直覺只是在開始的時候更有用，而非其他時候。把直覺當做指南，而不能用作合理性證明。為了測試，必須探索。探索需要大量的思索。前向思索，后向思索，側向思索。實用誘導推斷邏輯發現推測實用猜想與反駁邏輯評估產品。

第五篇：無領導小組經驗與教訓

人力資源管理之無領導小組經驗與教訓

2011/11/28

一、評委

1.評分細則，評分表的制作（前期準備，評分標準不容易明確）

2.加減分細則，標準不統一

3.不可避免受到平時印象的影響加減分數，很難做到絕對的公平公正。

4.前期分工和合作很重要

5.忽略某些細則（如加減分）

6.評委前期應該開會統一意見，制定標準

7.評委應該對考生進行近距離全方位的觀察

8.評分表的操作性高很重要

9.評委應該保留數據

10.考官各方面的比例應該合理（譬如：性別、人數）

二、考生

1.2.3.4.5.6.把握自己在討論中的位置 首先統一共識的標準 注意自己在討論中的行為舉止 性別有可能對結果造成影響 注意對討論內容的規劃 考官不可能看到過程中的每一細節，所以考生不必太過在意自己一時的錯誤

7.獨立發表意見，綜合整合結果

8.更早地確定小組發言人

9.聲音洪亮，語速平緩，觀點明確

三、觀眾

1.過于關注考生考官

2.考官男女比例失調，人數不足

3.考生之間關系協調度，情商的注意

4.音量音速的控制，信息表達效果，觀點長度的控制

5.明確出題人的意圖，注意本次考核的價值觀

6.總結觀點時應該注意取舍問題

7.明確目的，標準統一

8.團隊：交流方式，對觀點的自信度，意見的深思熟慮