做軟件測試要想保質保量，就要做到測試充分，什么是測試充分，就是把所需要覆蓋的場景都要覆蓋到。

    如何做到場景全面覆蓋，特別是在時間緊任務重的時候？

    我把我這些年來工作的一點經驗總結一下分享給大家，希望對大家有點幫助：

    No.1 提前介入測試那么什么時候測試介入比較好？在需求明確下來進入開發之前，測試就可以介入了解需求的相關內容了。
    這塊一般有兩個階段：
    第一個階段是需求澄清階段，這個階段就是需求接口人向開發講解需求的詳細要求及實現功能，這個時候測試就可以參與進來一起聽，聽過之后我們就對這個需求有了一個大概的了解，知道了這個功能的是要做什么，輸入輸出是什么，為后期了解詳細的實現方案做準備。
    第二個階段是開發實現方案澄清階段，這個階段一般是相關的開發人員把需求的功能實現方案和詳細邏輯跟需求提出人和接口人確認，我們這個時候參與進來，就可以根據開發講的實現方案和邏輯了解相關的的內容：比如算法判斷邏輯是啥，取值是啥，輸入值的類型是啥，取的哪個表哪個字段的值，或者調取那個接口服務，異常輸入又是如何處理的，結果體現在哪里等等。
    當然有些小公司是沒有給這些階段的時間的，拿到需求就可能是口頭說一下開發就直接實現，不會再次的澄清，這個時候我們怎么辦，只有自己主動找開發溝通，遇到與開發理解不一致的時候，還要找產品經理或需求拉口人再次確認，來避免需求不清晰導致的一些不必要的問題，也為我們后期的測試用例編寫找到明確的答案。
    No.2 測試分析，測試用例設計根據前期的了解，接下來我們就是要把這些存在于我們腦海中的信息轉化為文字形式列出來，并分析出我們的測試場景。
    為啥要把這些信息轉化文字，不根據所想直接列測試場景，因為這些信息存在我們腦海中的很容易忘記，而且不是很清晰，只有通過有章法的梳理信息后，才能形成對我們有用的信息。
    不知道大家有沒有這樣的情景，一個需求你看文檔或者聽需求接口人和開發都講過了，你也知道是啥了，感覺沒啥問題了，可是當你下去寫測試用例的時候，你還是會有些地方模糊不清楚。
    那么把我們了解的信息形成文字，就能很好的幫助我們解決這個問題。
    如何梳理這些信息呢，我一般是按照這樣的順序來的：
    1）先分析需求的背景，業務要求。
    把之前了解的需求背景都寫出來，遇到不明確的及時詢問相關人員，直到明確。
    比如一個需求的背景是這樣的：業務人員在一線作業的時候發現某個模塊在一些國家是需要特殊型號的，而在系統訂單中默認配置的是另外一個型號，他們希望配置這個國家訂單的時候，系統能自動識別出來并把這個模塊替換成指定的型號。
    那我們在寫需求背景的時候不僅僅是寫上面那段話了，就要把“一些國家”中的國家給明確寫出來，就是這些國家是哪幾個國家，國家名稱是啥，代碼是啥，同時模塊型號也要明確寫出來，替換前的模塊是哪個？型號是啥？替換后的模塊是啥，型號又是啥？
    2)分析需求實現方案和邏輯
    這里就是把我們前期了解到的開發實現方案和邏輯一一羅列出來，有必要的可以用圖畫出來如開發的實現流程，邏輯判斷流程，數據走向等等。
    就比如上面那個需求，開發的實現方案是應該包括這個國家是從訂單哪個信息里面取出來的，需要更換模塊型號的國家又是放在哪里的，是怎么取模塊型號的，更換后的結果在哪里體現等等
    那我們在這個分析模塊就要把這些都列出來，并一一明確。
    3）分析測試要點，測試要素
    根據前面兩項的分析，我們應該很快的就理出我們的測試要點，重點關注項等內容
    就說上面這個模塊型號更換吧，我們知道了：國家，指定模塊型號，更換后的模塊型號體現在哪里，都是我們的關注對象，同時我們還應知道這個更換型號對于沒有不在指定國家的范圍內的，型號是不受影響的。那么這些就是我們的測試要點和要素了。
    4）列出測試場景
    根據上面的分析，我們可以把我們所需要測試的場景以表格的形式寫出來了
    5）把測試場景轉化為測試用例
    到此，我們就可以輸出測試用例了，那我們這個用例到底充分與否，結果輸出是否正確，我們的理解是否到位呢？
    接下來我們就要請相關的人員對我們的文檔和用例進行一個評審了。
    No.3 測試用例評審測試用例評審不僅僅評審的是測試用例，還有我們對這個需求的理解和我們的思路，所以在評審的時候我們應該先把我們的測試分析文檔講一下，然后再把我們的測試用例拿出來給大家講一下，重點講測試的輸入和輸出結果。
    這樣下來在開發和系統設計人員的幫助下，我們就可以及早發現用例的不足以及我們忽略的測試點，及時補充測試用例，完善測試用例。
    這個在以前的公司測試用例評審是要求很嚴的，每個參于評審的人都必須要提出問題點，就是為了避免有些參于評審的人員只參于不評審，導致一些問題遺留到最后。
    No.4 嚴格按照測試用例執行測試這一點很重要，為什么這么說呢？因為你測試用例設計的再好，你不按照它來執行，你的測試就不可能做到充分。
    還記得有一次我做好了一個需求的測試用例，評審完去測試的時候，我覺得自己記得差不多了就按自己記的開始測試沒有按測試用例一個個的執行，前面測試的很快，問題也不多。
    等后面回歸測試的時候，我就突然發現多出好幾個問題，原因就是我沒按測試好的測試用例全面覆蓋漏測了兩個關聯點，打此以后，我再也不敢脫離測試用例，自己憑記憶測試了。
    No.5 分解需求有些需求接到的晚或著手測試的晚，功能又復雜，又要求按時上線，這個時候怎么辦？
    把需求測試用例完成后，按功能分成幾個小功能點，分配給多個組員測試（當然這個在給參與測試的人員之前要把需求功能詳細的講解一下），在測試的過程中要保持經常溝通，做到寧可交叉重復測試也不脫節測試。
    我記得當時有一個web系統的功能，前期的時候因為忙著應對其他緊急的需求，就把它放在一邊了，后面提上日程的時候發現留給我的時間不多了，我一個人測試肯定測試不全，這時我就主動找主管溝通，多調兩個同事來和我一起測試，然后在兩個同事的協助下，才順利完成了這個功能的測試。
    No.6 交叉測試對于大的需求或都功能復雜的需求要做到多人交叉測試，這種測試在系統測試的時候就可以進行，以前我所在公司的項目每到系統測試都會進行這樣的安排，這樣就可以避免到后期回歸測試出現更多的問題。
    No.7 重點功能要及時跟蹤進行測試充分性分析對于那些功能復雜，風險性高的項目，我們要在每進行完一輪測試，進行一次測試充分性分析以便及時做出調整。

    有一次我們有一個比較大的改動，而這個改動涉及到了我們這個軟件流程中的一個核心點，也就是涉及到的內容比較多，然而留給測試的時間卻不是很多只有兩周，怎么辦呢？組長首先把這個改動按影響到的功能點細化分了一下，分給了三個人進行測試，每天她都跟進統計測試進度，分析問題分布點，跟進問題修改情況，然后再根據這些及時調整測試策略，經過兩周緊張的有序的測試，這個功能最終穩當的上線。

    本文由培訓無憂網長沙牛耳教育課程顧問老師整理發布，希望能夠對想參加長沙軟件測試培訓的學生有所幫助。更多軟件測試培訓課程信息可關注培訓無憂網電腦IT培訓或添加老師微信：15033336050

      注：尊重原創文章,轉載請注明出處和鏈接 http://www.dedgn.cn/news-id-11367.html 違者必究！部分文章來源于網絡由培訓無憂網編輯部人員整理發布,內容真實性請自行核實或聯系我們，了解更多相關資訊請關注軟件測試頻道查看更多，了解相關專業課程信息您可在線咨詢也可免費申請試課。關注官方微信了解更多：150 3333 6050