做軟體測驗要想保質保量，就要做到測驗充分，什么是測驗充分，就是把所需要覆寫的場景都要覆寫到，
如何做到場景全面覆寫，特別是在時間緊任務重的時候？
我把我這些年來作業的一點經驗總結一下分享給大家，希望對大家有點幫助：
No.1 提前介入測驗
那么什么時候測驗介入比較好？在需求明確下來進入開發之前，測驗就可以介入了解需求的相關內容了，
這塊一般有兩個階段：
第一個階段是需求澄清階段，這個階段就是需求介面人向開發講解需求的詳細要求及實作功能，這個時候測驗就可以參與進來一起聽，聽過之后我們就對這個需求有了一個大概的了解，知道了這個功能的是要做什么，輸入輸出是什么，為后期了解詳細的實作方案做準備，
第二個階段是開發實作方案澄清階段，這個階段一般是相關的開發人員把需求的功能實作方案和詳細邏輯跟需求提出人和介面人確認，我們這個時候參與進來，就可以根據開發講的實作方案和邏輯了解相關的的內容：比如演算法判斷邏輯是啥，取值是啥，輸入值的型別是啥，取的哪個表哪個欄位的值，或者調取那個介面服務，例外輸入又是如何處理的，結果體現在哪里等等，
當然有些小公司是沒有給這些階段的時間的，拿到需求就可能是口頭說一下開發就直接實作，不會再次的澄清，這個時候我們怎么辦，只有自己主動找開發溝通，遇到與開發理解不一致的時候，還要找產品經理或需求拉口人再次確認，來避免需求不清晰導致的一些不必要的問題，也為我們后期的測驗用例撰寫找到明確的答案，
No.2 測驗分析，測驗用例設計
根據前期的了解，接下來我們就是要把這些存在于我們腦海中的資訊轉化為文字形式列出來，并分析出我們的測驗場景，
為啥要把這些資訊轉化文字，不根據所想直接列測驗場景，因為這些資訊存在我們腦海中的很容易忘記，而且不是很清晰，只有通過有章法的梳理資訊后，才能形成對我們有用的資訊，
不知道大家有沒有這樣的情景，一個需求你看檔案或者聽需求介面人和開發都講過了，你也知道是啥了，感覺沒啥問題了，可是當你下去寫測驗用例的時候，你還是會有些地方模糊不清楚，
那么把我們了解的資訊形成文字，就能很好的幫助我們解決這個問題，
如何梳理這些資訊呢，我一般是按照這樣的順序來的：
1）先分析需求的背景，業務要求，
把之前了解的需求背景都寫出來，遇到不明確的及時詢問相關人員，直到明確，
比如一個需求的背景是這樣的：業務人員在一線作業的時候發現某個模塊在一些國家是需要特殊型號的，而在系統訂單中默認配置的是另外一個型號，他們希望配置這個國家訂單的時候，系統能自動識別出來并把這個模塊替換成指定的型號，
那我們在寫需求背景的時候不僅僅是寫上面那段話了，就要把“一些國家”中的國家給明確寫出來，就是這些國家是哪幾個國家，國家名稱是啥，代碼是啥，同時模塊型號也要明確寫出來，替換前的模塊是哪個？型號是啥？替換后的模塊是啥，型號又是啥？
2)分析需求實作方案和邏輯
這里就是把我們前期了解到的開發實作方案和邏輯一一羅列出來，有必要的可以用圖畫出來如開發的實作流程，邏輯判斷流程，資料走向等等，
就比如上面那個需求，開發的實作方案是應該包括這個國家是從訂單哪個資訊里面取出來的，需要更換模塊型號的國家又是放在哪里的，是怎么取模塊型號的，更換后的結果在哪里體現等等
那我們在這個分析模塊就要把這些都列出來，并一一明確，
3）分析測驗要點，測驗要素
根據前面兩項的分析，我們應該很快的就理出我們的測驗要點，重點關注項等內容
就說上面這個模塊型號更換吧，我們知道了：國家，指定模塊型號，更換后的模塊型號體現在哪里，都是我們的關注物件，同時我們還應知道這個更換型號對于沒有不在指定國家的范圍內的，型號是不受影響的，那么這些就是我們的測驗要點和要素了，
4）列出測驗場景
根據上面的分析，我們可以把我們所需要測驗的場景以表格的形式寫出來了
5）把測驗場景轉化為測驗用例
到此，我們就可以輸出測驗用例了，那我們這個用例到底充分與否，結果輸出是否正確，我們的理解是否到位呢？
接下來我們就要請相關的人員對我們的檔案和用例進行一個評審了，
No.3 測驗用例評審
測驗用例評審不僅僅評審的是測驗用例，還有我們對這個需求的理解和我們的思路，所以在評審的時候我們應該先把我們的測驗分析檔案講一下，然后再把我們的測驗用例拿出來給大家講一下，重點講測驗的輸入和輸出結果，
這樣下來在開發和系統設計人員的幫助下，我們就可以及早發現用例的不足以及我們忽略的測驗點，及時補充測驗用例，完善測驗用例，
這個在以前的公司測驗用例評審是要求很嚴的，每個參于評審的人都必須要提出問題點，就是為了避免有些參于評審的人員只參于不評審，導致一些問題遺留到最后，
No.4 嚴格按照測驗用例執行測驗
這一點很重要，為什么這么說呢？因為你測驗用例設計的再好，你不按照它來執行，你的測驗就不可能做到充分，
還記得有一次我做好了一個需求的測驗用例，評審完去測驗的時候，我覺得自己記得差不多了就按自己記的開始測驗沒有按測驗用例一個個的執行，前面測驗的很快，問題也不多，
等后面回歸測驗的時候，我就突然發現多出好幾個問題，原因就是我沒按測驗好的測驗用例全面覆寫漏測了兩個關聯點，打此以后，我再也不敢脫離測驗用例，自己憑記憶測驗了，
No.5 分解需求
有些需求接到的晚或著手測驗的晚，功能又復雜，又要求按時上線，這個時候怎么辦？
把需求測驗用例完成后，按功能分成幾個小功能點，分配給多個組員測驗（當然這個在給參與測驗的人員之前要把需求功能詳細的講解一下），在測驗的程序中要保持經常溝通，做到寧可交叉重復測驗也不脫節測驗，
我記得當時有一個web系統的功能，前期的時候因為忙著應對其他緊急的需求，就把它放在一邊了，后面提上日程的時候發現留給我的時間不多了，我一個人測驗肯定測驗不全，這時我就主動找主管溝通，多調兩個同事來和我一起測驗，然后在兩個同事的協助下，才順利完成了這個功能的測驗，
No.6 交叉測驗
對于大的需求或都功能復雜的需求要做到多人交叉測驗，這種測驗在系統測驗的時候就可以進行，以前我所在公司的專案每到系統測驗都會進行這樣的安排，這樣就可以避免到后期回歸測驗出現更多的問題，
No.7 重點功能要及時跟蹤進行測驗充分性分析
對于那些功能復雜，風險性高的專案，我們要在每進行完一輪測驗，進行一次測驗充分性分析以便及時做出調整，
有一次我們有一個比較大的改動，而這個改動涉及到了我們這個軟體流程中的一個核心點，也就是涉及到的內容比較多，然而留給測驗的時間卻不是很多只有兩周，怎么辦呢？組長首先把這個改動按影響到的功能點細化分了一下，分給了三個人進行測驗，每天她都跟進統計測驗進度，分析問題分布點，跟進問題修改情況，然后再根據這些及時調整測驗策略，經過兩周緊張的有序的測驗，這個功能最終穩當的上線，
以上筆者的經歷更像一張橫向的知識網，創建了一個交流平臺 914172719 ，群內有各種技術同行交流、學習資料、面試經驗等，其中用到jenkins、docker、moutebank、python編程等，還需要花更多的精力去深入學習，當每項技能都能掌握到一定深度，才能稱為一個完整的知識體系，
最后： 可以關注公眾號：傷心的辣條 ！ 進去有許多資料共享！資料都是面試時面試官必問的知識點，也包括了很多測驗行業常見知識，其中包括了有基礎知識、Linux必備、Shell、互聯網程式原理、Mysql資料庫、抓包工具專題、介面測驗工具、測驗進階-Python編程、Web自動化測驗、APP自動化測驗、介面自動化測驗、測驗高級持續集成、測驗架構開發測驗框架、性能測驗、安全測驗等，
如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！
好文推薦
轉行面試，跳槽面試，軟體測驗人員都必須知道的這幾種面試技巧！
面試經：一線城市搬磚！又面軟體測驗崗，5000就知足了…
面試官：作業三年，還來面初級測驗？恐怕你的軟體測驗工程師的頭銜要加雙引號…
什么樣的人適合從事軟體測驗作業？
那個準點下班的人，比我先升職了…
測驗崗反復跳槽，跳著跳著就跳沒了…
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/297557.html
標籤：其他