梅子：關于測試用例設計的那些事兒

問：如果測試部門的人員質量比較低，如何快速培養新人，并留住新人（正式和實習生比是1:6.5）？那又該如何快速培養這些新人的測試用例設計能力和測試思路呢？

答：快速培養新人，導師制，一帶一比較不錯。另外團隊要做知識管理，鼓勵老員工多做總結。還可以做一個知識沙盤，告訴大家要學習哪些知識。

快速培養測試思維，就是車輪圖，然后用例評審，最后一對一的輔導。

用例評審的時候，如果新人多，可以慢點，先讓新人講，然后大家都來給新人挑問題，最后做一些力所能及的一對一分享。

問：如果對一個接口進行測試，接口有n個入參，需要對不同的入參組合檢驗接口的輸出，這應該是屬于參數類的吧？如果要對入參組合做到全覆蓋，從排列組合的角度講就是C n n種組合，在n很大的情況下組合就會非常多，而項目測試時間有限，這種情況下怎么辦呢？ 我現在是選擇通過只覆蓋業務當前調用場景的參數組合來壓縮測試時間，這樣就可能會為未來的業務調用留下隱患，不知道梅子有沒更好的建議？

答：你們選擇的思路是對的，測試沒法總是全覆蓋，而需要“有策略的覆蓋”。有測試不到的地方，留下隱患是不可避免的。理論上，用自動化可以遍歷，但效率并不高。我們不妨分析一下你們漏掉的部分，到底是哪些問題，是正常值的組合居多，還是一些異常的情況居多。個人經驗針對異常情況，設計一些fuzzing遍歷，可能效率會更高。

問：梅子好，我拜讀過你的大作，想問一下在做每一個項目，質量屬性如何和測試類型相結合？

答：可能我們的測試層次有點不一樣，產品也有點差異，所以不能一概而論。我是用車輪圖，這樣每個項目都把質量屬性和測試類型結合起來了。 測試類型對應測試level,每個level都可以關注質量屬性的幾個方面。

問：一個陌生的項目從交付測試到上線，在沒有用例的情況下，如果只有2天時間，應該怎么去完成測試？

答：首先要看這2天要測的產品是什么。我在項目中也會遇到要求兩天交付的情況，一般是緊急的安全補丁，或是bug，或者小功能改進。如果是前兩種情況會比較簡單，針對修改進行測試，有時候甚至對比一下代碼，就可以了。

如果是針對小功能改進或者是定制很緊急的任務，就特別適合用探索式測試的方式來進行測試。在測試前，測試人員一定要和產品經理充分溝通，徹底了解提出這個需求的客戶的原始訴求：這個點是演示，還是正式交付，還是別的目的。然后和開發溝通，收集確定信息，邊收集邊做探索地圖，并確認輸出。接著開始探索測試（我習慣以2小時作為時間窗），一邊探索學習，一邊總結測試。一般4個時間窗就可以完成一輪。

然后開發可以再出一個版本，修改第一次探索測試的問題，再探索測試幾個時間窗。車輪圖也可以作為探索地圖的框架。

以上是我操作的步驟。只要開發靠譜，一般我6~8個時間窗就可以完成測試了。

問：作為業務人員，如果是對某些業務系統做一些測試（少量功能需要發散空間去思考），如何比較好的滿足業務，比較快地測試和驗證系統實現的功能？

答：前提是這些需要發散的點是事先可以識別。你說的這個情況，特別適合車輪圖的方式。建議團隊做一個大的車輪圖，把基本點包含進去。如果有時間還可以把這部分測試點做成測試用例，并建立基線，持續維護。這部分是基礎，必須要保證。

對可以發散的地方，如果你們有明確的可以發散的地方，可以直接用探索測試的技術進行探索。如果不明確，我建議根據缺陷來找，哪些可以作為探索式測試的點，再來進行探索式測試。

問：對于現在特性團隊里面的QA，在兩個星期的迭代周期來說既要做測試設計和分析，又要做自動化測試開發，很難再花大量時間做測試設計的文檔化的工作，這個怎么破？是否有些測試設計的流程在敏捷的背景下可以簡化？

答：要想快，先要建立一些基線。用例可以建立基線，車輪圖也可以不斷總結建立基線。建立基線是第一個方法。

第二個方法是，時間太緊不寫完整的用例，而寫一句話用例。不對所有的點都寫測試用例，有些測試點只到寫測試方法這個層面就夠了。維護一句話測試用例+測試方法，可以大大減少用例寫作的工作量。

第三個方法是，測試設計模型化，規范化。特別是對自動化測試的部分，一定是先保證基本的，可以模型化的部分自動化，也就是mbt的思路。

總之，用例基線化來增加用例復用性；用一句話用例+測試方法來替代傳統完整的用例，減少用例編寫工作量；設計模型化，多用工具進行mbt的測試，并盡量對次部分用例自動化。

問： 1、敏捷項目中的測試人員如何定位，如何讓測試人員在敏捷全流程中起到反推作用，使開發質量更高？ 2、怎么保證敏捷項目中的長時間穩定性測試？

答：一、關于敏捷項目中測試人員的定位，我覺得和團隊當前的能力有關（是全角色、開發、產品、測試等）。團隊能力如果比較低，測試就是“鏡子”，就是幫團隊反映出缺陷。團隊能力比較高，測試談“缺陷預防”才比較有意義。

要想起到反推作用，我覺得測試可以從用戶層面獨立思考，有能力對需求提出建議是反推的前提。如果只是順著開發走，談不上反推。所以測試要更關注業務，理解客戶，了解友商，理解特性的真正價值，才能起到反推的作用。

二、關于在敏捷項目中的穩定性，我有個實踐是，當版本達到可以測試穩定性的標準后，我就開始做不間斷的穩定性測試，發版本的時候，就升級，繼續測。我有專門的穩定性環境，希望對你有啟發。我的產品對穩定性要求高，所以我隨時都在關注穩定性，不管大小版本，這個和產品有關系。

問：現在對測試部門來說，安全問題壓力超大。雖然知道安全應該從架構設計就開始，但現在產品已經成了，只能說從測試角度發現、修復。如何改善這種情況呢？

答： 我們是安全公司，做安全測試比較有優勢。首先是安全測試方面的設計規范。有些安全漏洞，看起來很嚇人，其實可能就是編程規范的問題，所以在給程序員培訓了基本的安全編碼知識后，代碼檢視，靜態檢查等其實很重要。

在測試時，我們會做一些簡單的安全測試，如基本的注入測試等，還有因為產品的特點，fuzzing測試我們做得比較多。另外我們有個研究院，會專門給我們做一些滲透測試、漏洞掃描等。這會在發布前做。確保產品不會有已知漏洞（有了就是打臉，對安全產品來說丟不起這個人）。

安全測試可能你們感興趣的是滲透測試，服務器安全測試等。我實際做網絡安全的，我們做得多的是已知的那些攻防測試，漏洞挖掘我沒做過。

問：我們也想過出安全編碼規范，但是呢測試部出的規范，開發并不一定采納，確實我們也并不一定專業。我們不做服務器攻防，重點還是在軟件產品本身的安全漏洞。

答：這個測試部自己出肯定不行。要做缺陷分析，用反饋數據，反過來給開發領導一些壓力，可能會好些。

問：快速迭代中如何更高效的編寫和維護測試用例，有沒有好用的工具？我現在的項目兩個禮拜一個迭代，有6個不同的平臺，平臺間存在需求不同步和需求差異化的問題，管理測試用例就比較麻煩。

答：編寫用例可以考慮“車輪圖分析用例-一句話用例”的方式。維護用例，我建議以“功能-子功能-子子功能”來組織用例，不要完全以測試類型來組織用例。管理用例我就用testlink，基本可以滿足我的需求。

另外你現在的問題，看起來不是測試的問題，應該是需求和管理的問題。測試可能無法從根本上改變什么。還得找領導協助解決。

問：我們現在有持續測試和持續部署平臺，也有持續集成流程，但都是偏工具些，但工具如果沒有相應的方法策略，不能發揮大的價值，梅子有什么建議嗎？

答：我覺得測試最重要的是測試策略——測什么和怎么測。確定測試范圍、目標、重點難點、深度廣度、測試順序和評估。工具就是實現這個策略的。我建議先花一點時間分析測試策略，讓工具具有靈魂。

問：1）工作這么久，梅子認為測試對團隊最大的價值在哪里？之前就有測試將死的話題，初創公司也較少有測試崗。如果開發做TDD，自己本身代碼質量就很高，測試還要去對這種人的產出做二次檢查感覺就很浪費，無奈有的公司就是覺得無論大小項目都要過測試的手。2）現在國內對測試人員感覺越來越往像開發人員一樣的要求走，開發能力強，能寫什么什么工具，就說明你牛，對這個梅子怎么看？雖然我始終覺得用例設計水平其實更應該受到測試重視。

答：1）測試對團隊最大的價值，我覺得還是預防缺陷。做鏡子，也是價值之一。

測試將死，我認可這個觀點。我也認為測試將死。但測試會以新的方式重生。比如提供測試平臺的支持，或者更關注專項測試，需要復雜組網或者測試工具的測試，或者是業務專家。

初創公司，比如做一些app開發，web的，沒有測試崗是正確的，我可以理解。

公司覺得大小項目都要過測試的手，可能有公司的考慮，也許是歷史慣性，也許是一些利益關系。

2）對第二個問題，我想說我就是這樣一路被嫌棄過來的。我是2005年做測試，我的主管開發出身，1999年開始做測試。他對我們就說，你們真的能力很差，沒有代碼能力，所以我是測試，但經常被逼考試，比如C語言。但好處也是明顯的，我可以和開發很順暢的溝通，也不太懼怕代碼，我愿意一邊測試一邊寫自動化，并自己寫小工具。

所以我覺得，測試真的要多學習多了解代碼。有機會多看看開發的程序。這樣可以和開發更好的溝通交流。否則真的的雞同鴨講。當然，測試用例設計也很重要。最重要的，我覺得是測試方法。用例設計是寫出來的那部分測試方法。還有一些測試方法，寫成測試用例不一定好寫。但測試同學也不要陷在開發代碼里，或者想把自己弄成全棧全才。測試首先要獨立思考，獨立分析。學會思考和分析對測試很重要。

（以上內容轉自GitChat，版權歸GitChat所有，轉載請聯系GitChat，微信號：GitChat，原文：?《梅子：關于測試用例設計的那些事兒》）

本文轉載自異步社區。

其他

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。