軟件測試工作中找bug就是這個崗位本身立足的職責，那麼對于很多新人和新入行的同學們來說，這個過程會有點苦逼，畢竟經曆的項目經驗不多，想快速的切入尋找bug往往會比較痛苦。

1、熟悉你做的産品

不管你是Dev、Test或者PM，熟悉自己開發的産品越多越好，你不但應該熟悉自己開發的模塊，也應改熟悉和自己模塊相關的其他模塊，他們之間是怎樣協作的。比如數據庫中的某個字段，是如何被各個模塊使用的，這利于你在設計階段就能夠找到Bug，把修複的成本降到最低。

同樣，你需要熟悉這個産品以前的版本，因為無法向後兼容和升級的産品恐怕很難獲得用戶的認可。在測試過程中，如果你發現你的産品和以前不兼容或者不一緻，80％的情況，這是一個Bug。

2、盡早的去發現Bug

我們大家都知道，Bug修複的成本是和Bug被找到的時間成指數關系的。越早開始找Bug，你能找到的Bug也就越多，對項目的貢獻也就越大。

3、每天Review别人的Bug

如果你的團隊沒有每日的Bug Report，我建議你們建立一個，其實技術上應該沒有任何的難度，通過Bug追蹤系統的API或者數據庫，你完全可以得到你要的數據，這樣，整個團隊通過學習每天察看别人的Bug，你可以更加容易發現Bug，也不會發現那種Duplicated Bug。現在經常有人跑過來問我，某個Bug是不是一個已知的問題，因為我每天都看Bug Report。

4、在你的日常生活中多準備一些測試的模式

模式是一個很時髦的詞，因為它很有用。在日常的測試中，多準備一些測試模式，你會有非常大的驚喜，有時候一個使用一個模式，你可以找到10來個Bug也不是不可能的。比如，使用特殊字符作輸入數據；斷開網絡看UI是否會Crash；在本地化版本中，各個字符串提示是否被本地化；

5、多測試各個模塊之間的合作

各個模塊之間的測試往往是我們測試中的薄弱點，對于用戶來說模塊間的合作卻至關重要。往往一個數據在模塊A中是合法的，在B中卻是非法的，一定要找出這些數據，往往者都是Bug

6、編寫自動測試代碼

你肯定不原意每天都去做同樣的事情，那樣太沒有意思了，簡直就是對你的智慧的侮辱。但是一旦我們不進行這些測試，突然有一天早上，我們發現我們的産品以前能夠很好工作的功能突然就不工作了，于是大家亂作一團，有人急着修複它，有人在找是誰Check in的。

7、查看産品代碼

通過查看産品代碼，你往往能找到一些Dead Code或者邏輯上的Bug，這些Bug常常是你無法通過手工測試找到的。

有很多朋友初次寫用例，不知道從何下手，雖然有的公司給出了相關說明文檔，但是寫起來還是不能得心應手，編寫用例方法有很多種：功能導向用例（邊界值、等價類等等），用戶導向用例（場景法），用戶、功能相結合導向用例……

軟件測試的同學肯定都寫過測試用例，但是如何寫出一份高質量的測試用例呢？測試用例有哪些要求呢？為什麼要寫測試用例呢？

01

為什麼要寫測試用例？

在版本轉測試之後，我們測試的基礎是什麼？如果沒有測試用例，我們應該怎麼展開測試？怎麼樣保證測試點不遺漏、而且不人力投入不重複、怎麼樣追溯我們的測試質量？如果沒有測試用例，這些工作可能都無法開展， 所以測試用例是測試的根基，可以讓我們的測試活動從不可控的狀态變成可控的狀态， 讓測試活動開展起來更加順利，可視化的跟蹤我們的測試進度，哪些已測試、哪些未測試，所以要想成為一個高水平的測試人員，寫出一份高質量的測試用例是基礎。

02

測試用例由哪幾部分構成？

測試用主要由8部分構成： 所屬的模塊、名稱、編号、等級、描述、預制條件、操作步驟、預期結果

下面重點說明下面幾個部分 名稱、描述、預置條件 操作步驟 預期結果

名稱：要求熟練的測試人員看見名稱就大概明白測試用例所測試的點，大概怎麼測試，不要求描述過分詳細，盡量簡短、精練

描述：測試點的詳細描述，相當于測試用例名稱的詳細版

預制條件：就是在執行操作步驟前，系統需要達到的狀态

操作步驟：如果有多個步驟，每一個步驟都需要填上序号，每一行一個步驟， 不能寫得過于簡略，至少要讓熟悉過系統的測試人員可以執行，也建議不要寫得太複雜。

預期結果：如果有多個檢查點，需要都羅列出來，每一行一個标号， 讓人一目了然有幾個結果檢查點， 另外檢查點盡量寫詳細些，不要出現結果正常、不正常等字眼，應該描述 出正常的具體情況。

把測試用例的每一個部分寫好僅僅是測試用例的基本要求，就算這些都做好了，也不能說明這個測試用例是一個好的測試用例。

03

測試用例好壞的評判标準？

首先糾正一個誤區，測試用例不是越多越好？相反如果測試用例中冗餘用例太多，這樣在執行測試用例會浪費大量測試人力，而且不會産生測試效果。

标準如下：

1、測試用例書寫格式正确、描述清晰， 其他測試人員拿到測試用例可以在不詢問寫作人的情況下正常執行下去

2、測試用例對測試點覆蓋完全，也就是說測測過程中發現的問題基本都是通過測試用例發現的，發現的比例越高越好， 越高說明測試用力的防護能力越強，當然測試用例不可能特别完備，在我們執行測試用例的過程，如果bug不是通過用例發現，我們需要對用例進行增加，這樣我們下一次就可以把這個問題給防護住。

04

如何寫出一份高質量的測試用例？

1、測試人員盡早介入，徹底理解清楚需求，這個是寫好測試用例的基礎

2、如果以前有類似的需求，可以參考類似需求的測試用例， 然後還需要看類似需求的bug情況

3、清楚輸入、輸出的各種可能性，以及各種輸入的之間的關聯關系，理解清楚需求的執行邏輯， 通過等價類、邊界值、判定表等方法找出大部分用例

4、 找到需求相關的一些特性，補充測試用例

5、根據自己的經驗分析遺漏的測試場景

6、多總結類似功能點的測試點，才能夠寫出質量越來越高的測試用例

7、書寫格式一定要清晰

那麼對于初次編寫用例，應該怎樣高效率的編寫用例？應該注意點什麼？

一、功能導向用例是按照系統需要達到的每一個功能，進行編寫用例，這樣的用例着重點在功能實現上，而沒有考慮到每個功能之間的關聯，因而雖然用例已經達到功能覆蓋，卻不一定達到邏輯覆蓋，因而這種方法通常會和其他方法結合使用。功能導向用例是每個用例編寫者前期最常用的方法。

二、用戶導向用例是按照用戶的習慣，将用戶使用系統的每個目的作為一個目标，以每個目标實現為基點設計測試用例，但是設計這一類用例，初寫者，可能會産生很多困惑（下面寫一下我第一次寫的時候有哪些困惑，并針對這些困惑，後來采取了怎樣的解決方案）

1、編寫用例的第一步我該做什麼？

理解系統，首先站在測試的角度深入理解系統的每個功能與系統業務邏輯，畫出業務邏輯圖（即：系統能做什麼）。

其次站在用戶的角度，列出用戶使用系統的目的（即：用戶使用這個系統，想幹什麼？）

2、怎樣确定用戶目标？

不能确定用戶目标，可能由2方面原因造成:a>對系統不夠熟悉，b>不了解用戶背景。對于第一點原因，那是你自己的原因，隻有回過去頭看文檔了，對于第二點原因，可以從‘系統能做什麼’推算出‘用戶可以做什麼’然後再總結出‘用戶可能想做什麼’，當然這樣做的前提是你對系統已非常熟悉。

3.這個月我将做什麼？

剛進入測試行業是怎樣總結的（利用測試管理工具進行總結）：

1）把測試管理工具中的缺陷全部分類導出，總結一下哪些模塊容易産生哪些缺陷，重點看一下自己沒發現或沒有考慮到的缺陷。

2）如果說測試新人工作的第一層次是從執行用例開始，那麼第二層次就是編寫測試用例了。把測試管理工具中的用例詳細看幾遍，學習别人的用例編寫方法和思想，空閑時間可以自己試着編寫，看自己編寫的與别人編寫的用例差距在哪，從而不斷完善。重要說明；着重用例編寫方法和思想的學習，而不要死搬硬套。

3）進入一些測試論壇，把自己的困惑和經驗和大家一起分享，在學習中，不斷進步。

總結：

正所謂功夫在詩外，測試理論知識就是那麼多，理論知識掌握之後就要不斷的參與到項目中來，一個一個項目的練習，鍛煉自己的發現Bug的能力，就算随機測試，一個好的測試和一個壞的測試，他們發現問題的能力也是完全不同的。以上完全是個人的一點體悟，各位看官，看的時候也請多多指教。

The End

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!