資訊專欄INFORMATION COLUMN
摘要：做軟件測試要想保質保量，就要做到測試充分，什么是測試充分，就是把所需要覆蓋的場景都要覆蓋到。重點功能要及時跟蹤進行測試充分性分析對于那些功能復雜，風險性高的項目，我們要在每進行完一輪測試，進行一次測試充分性分析以便及時做出調整。
做軟件測試要想保質保量，就要做到測試充分，什么是測試充分，就是把所需要覆蓋的場景都要覆蓋到。
如何做到場景全面覆蓋，特別是在時間緊任務重的時候？
我把我這些年來工作的一點經驗總結一下分享給大家，希望對大家有點幫助：
那么什么時候測試介入比較好？在需求明確下來進入開發之前，測試就可以介入了解需求的相關內容了。
這塊一般有兩個階段：
第一個階段是需求澄清階段，這個階段就是需求接口人向開發講解需求的詳細要求及實現功能，這個時候測試就可以參與進來一起聽，聽過之后我們就對這個需求有了一個大概的了解，知道了這個功能的是要做什么，輸入輸出是什么，為后期了解詳細的實現方案做準備。
第二個階段是開發實現方案澄清階段，這個階段一般是相關的開發人員把需求的功能實現方案和詳細邏輯跟需求提出人和接口人確認，我們這個時候參與進來，就可以根據開發講的實現方案和邏輯了解相關的的內容：比如算法判斷邏輯是啥，取值是啥，輸入值的類型是啥，取的哪個表哪個字段的值，或者調取那個接口服務，異常輸入又是如何處理的，結果體現在哪里等等。
當然有些小公司是沒有給這些階段的時間的，拿到需求就可能是口頭說一下開發就直接實現，不會再次的澄清，這個時候我們怎么辦，只有自己主動找開發溝通，遇到與開發理解不一致的時候，還要找產品經理或需求拉口人再次確認，來避免需求不清晰導致的一些不必要的問題，也為我們后期的測試用例編寫找到明確的答案。
根據前期的了解，接下來我們就是要把這些存在于我們腦海中的信息轉化為文字形式列出來，并分析出我們的測試場景。
為啥要把這些信息轉化文字，不根據所想直接列測試場景，因為這些信息存在我們腦海中的很容易忘記，而且不是很清晰，只有通過有章法的梳理信息后，才能形成對我們有用的信息。
不知道大家有沒有這樣的情景，一個需求你看文檔或者聽需求接口人和開發都講過了，你也知道是啥了，感覺沒啥問題了，可是當你下去寫測試用例的時候，你還是會有些地方模糊不清楚。
那么把我們了解的信息形成文字，就能很好的幫助我們解決這個問題。
如何梳理這些信息呢，我一般是按照這樣的順序來的：
1）先分析需求的背景，業務要求。
把之前了解的需求背景都寫出來，遇到不明確的及時詢問相關人員，直到明確。
比如一個需求的背景是這樣的：業務人員在一線作業的時候發現某個模塊在一些國家是需要特殊型號的，而在系統訂單中默認配置的是另外一個型號，他們希望配置這個國家訂單的時候，系統能自動識別出來并把這個模塊替換成指定的型號。
那我們在寫需求背景的時候不僅僅是寫上面那段話了，就要把“一些國家”中的國家給明確寫出來，就是這些國家是哪幾個國家，國家名稱是啥，代碼是啥，同時模塊型號也要明確寫出來，替換前的模塊是哪個？型號是啥？替換后的模塊是啥，型號又是啥？
2)分析需求實現方案和邏輯
這里就是把我們前期了解到的開發實現方案和邏輯一一羅列出來，有必要的可以用圖畫出來如開發的實現流程，邏輯判斷流程，數據走向等等。
就比如上面那個需求，開發的實現方案是應該包括這個國家是從訂單哪個信息里面取出來的，需要更換模塊型號的國家又是放在哪里的，是怎么取模塊型號的，更換后的結果在哪里體現等等
那我們在這個分析模塊就要把這些都列出來，并一一明確。
3）分析測試要點，測試要素
根據前面兩項的分析，我們應該很快的就理出我們的測試要點，重點關注項等內容
就說上面這個模塊型號更換吧，我們知道了：國家，指定模塊型號，更換后的模塊型號體現在哪里，都是我們的關注對象，同時我們還應知道這個更換型號對于沒有不在指定國家的范圍內的，型號是不受影響的。那么這些就是我們的測試要點和要素了。
4）列出測試場景
根據上面的分析，我們可以把我們所需要測試的場景以表格的形式寫出來了
5）把測試場景轉化為測試用例
到此，我們就可以輸出測試用例了，那我們這個用例到底充分與否，結果輸出是否正確，我們的理解是否到位呢？
接下來我們就要請相關的人員對我們的文檔和用例進行一個評審了。
測試用例評審不僅僅評審的是測試用例，還有我們對這個需求的理解和我們的思路，所以在評審的時候我們應該先把我們的測試分析文檔講一下，然后再把我們的測試用例拿出來給大家講一下，重點講測試的輸入和輸出結果。
這樣下來在開發和系統設計人員的幫助下，我們就可以及早發現用例的不足以及我們忽略的測試點，及時補充測試用例，完善測試用例。
這個在以前的公司測試用例評審是要求很嚴的，每個參于評審的人都必須要提出問題點，就是為了避免有些參于評審的人員只參于不評審，導致一些問題遺留到最后。
這一點很重要，為什么這么說呢？因為你測試用例設計的再好，你不按照它來執行，你的測試就不可能做到充分。
還記得有一次我做好了一個需求的測試用例，評審完去測試的時候，我覺得自己記得差不多了就按自己記的開始測試沒有按測試用例一個個的執行，前面測試的很快，問題也不多。
等后面回歸測試的時候，我就突然發現多出好幾個問題，原因就是我沒按測試好的測試用例全面覆蓋漏測了兩個關聯點，打此以后，我再也不敢脫離測試用例，自己憑記憶測試了。
有些需求接到的晚或著手測試的晚，功能又復雜，又要求按時上線，這個時候怎么辦？
把需求測試用例完成后，按功能分成幾個小功能點，分配給多個組員測試（當然這個在給參與測試的人員之前要把需求功能詳細的講解一下），在測試的過程中要保持經常溝通，做到寧可交叉重復測試也不脫節測試。
我記得當時有一個web系統的功能，前期的時候因為忙著應對其他緊急的需求，就把它放在一邊了，后面提上日程的時候發現留給我的時間不多了，我一個人測試肯定測試不全，這時我就主動找主管溝通，多調兩個同事來和我一起測試，然后在兩個同事的協助下，才順利完成了這個功能的測試。
對于大的需求或都功能復雜的需求要做到多人交叉測試，這種測試在系統測試的時候就可以進行，以前我所在公司的項目每到系統測試都會進行這樣的安排，這樣就可以避免到后期回歸測試出現更多的問題。
對于那些功能復雜，風險性高的項目，我們要在每進行完一輪測試，進行一次測試充分性分析以便及時做出調整。
有一次我們有一個比較大的改動，而這個改動涉及到了我們這個軟件流程中的一個核心點，也就是涉及到的內容比較多，然而留給測試的時間卻不是很多只有兩周，怎么辦呢？組長首先把這個改動按影響到的功能點細化分了一下，分給了三個人進行測試，每天她都跟進統計測試進度，分析問題分布點，跟進問題修改情況，然后再根據這些及時調整測試策略，經過兩周緊張的有序的測試，這個功能最終穩當的上線。
以上筆者的經歷更像一張橫向的知識網，創建了一個交流平臺 914172719 ，群內有各種技術同行交流、學習資料、面試經驗等。其中用到jenkins、docker、moutebank、python編程等，還需要花更多的精力去深入學習，當每項技能都能掌握到一定深度，才能稱為一個完整的知識體系。
最后： 可以關注公眾號：傷心的辣條 ！ 進去有許多資料共享！資料都是面試時面試官必問的知識點，也包括了很多測試行業常見知識，其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。
如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！
轉行面試，跳槽面試，軟件測試人員都必須知道的這幾種面試技巧！
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/119206.html
摘要：軟件測試從宏觀上可以分為功能測試性能測試安全性測試三個方面，如果能將三者結合起來就說明已經將這個崗位做的十分好了。 恍然間，發現自己已經在這個行業五年之久，回顧過往，思緒良多，一路走來，或多或少都經歷過一些坎坷，也碰到過不少大大小小的困難。在此就不多加敘述了。 本篇文章主要想寫給剛入門的測...
恍然間，發現自己已經在這個行業五年之久，回顧過往，思緒良多，一路走來，或多或少都經歷過一些坎坷，也碰到過不少大大小小的困難。在此就不多加敘述了。 本篇文章主要想寫給剛入門的測試員幾個忠告，在踏入職場初期，大多數人都還對未來一片迷茫，找不到北，當年剛畢業時的我也是這樣，可摸著石頭過河畢竟不是長久之計，希望新人能夠謹記以下幾點，在職場道路上走的更加通順一些。話不多說，開始分享。 01、在校期間的基礎...
閱讀 797·2023-04-25 22:57
閱讀 3050·2021-11-23 10:03
閱讀 613·2021-11-22 15:24
閱讀 3156·2021-11-02 14:47
閱讀 2900·2021-09-10 11:23
閱讀 3115·2021-09-06 15:00
閱讀 3936·2019-08-30 15:56
閱讀 3321·2019-08-30 15:52
