一、熟悉的場景
生產環境出現問題-定位問題-解決問題-原因復盤-問題定級-劃分責任人（每次都希望不會是自己的問題）
無休止的測試-回歸-再測試-再回歸測試-已經投入了很大精力，但仍對項目質量不信心（每次都在祈禱上線順利）
我相信很多人都會遇到上面兩種情況吧，如果自己所負責或參與的項目經常遇到上面的兩種情況，不妨從項目測試流程角度，去思考原因以及破開瓶頸的方法，從根本上去解決問題，或者減傷出現問題的頻率。
二、測試流程拆解分析
1、需求評審
需求評審流程：
需求背景–>需求價值–>需求帶來的收益–>用戶場景與需求–>功能模塊及操作–>流程講解–>原型演示–>迭代計劃及項目排期–>與各方確認是否有疑義
人人都是產品經理，需求評審對于測試來說就是項目最初的“產品測試”，在理解的基礎上發現產品設計缺陷，其中包括邏輯錯誤，功能缺失，細節問題等等，這樣就會有效的在前期規避很多后期開發中產生的bug，減少了很多后期返工的成本�？善枨笤u審往往是最不重視的一環，甚至可以說是沒有這個環節，追其原因無非因為項目時間緊迫或者覺得沒有必要，其實這是本末倒置和得不償失的。
產品需求作為程序的源頭，只有控制好最開始部分，才不會到最后去亡羊補牢。我有過很多血的教訓，所以才深深的體會到需求評審的重要性。舉個栗子
記得有一次由于項目時間比較緊迫，沒有對需求進行評審，當開始測試的時候發現需求的優惠券計算邏輯有一個重大的錯誤，經過和產品經理討論后發現是需求設計有缺陷，需要重新設計一套優惠券計算邏輯。于是改完需求后反饋到開發這里的時候，開發原來的代碼不能處理這種邏輯，只能把代碼邏輯重新寫一遍，最后又花了好幾天重構代碼，項目就延遲了一周上線。
后來回頭想想如果當時在需求評審的時候把這個問題拋出來，開發就不需要編寫錯誤的代碼，測試也不需要再多測試一遍，項目也不會延遲那么久才能上線。類似的教訓還有很多，都是由于不重視需求評審造成的，雖然大多數問題還是可以通過后期的測試來彌補的，但這樣反正折騰真的是累人累己，如果可以有好的方法來優化，為什么不用呢？
說了需求評審的重要性，接著就來談談如何進行需求評審，總的來說分3步走：
第一步就是要完全讀懂產品需求，這個過程只需要理解而不是去挑刺，因為要明白這個需求的目的是什么，為什么這樣做，怎么做等等，只有在理解的基礎上才能去發現問題，而不是一知半解的去挑毛病，有些需求設計的是不合理，但也許有其特殊的用意，或者只是沒有更好的方案，不能為了挑毛病而去挑刺。
第二步就是分析和找問題，這就有點類似寫測試用例的時候設計測試方案了，把邏輯梳理出來，看看有沒有不對或者遺漏的點，整理出來反饋給產品經理。除了考慮有問題的地方，沒問題的地方也是需要分析的，比如有些設計非常合理，但會增加代碼的復雜度或者不利于后續的擴展和修改，同時也可能會給測試帶來成倍的工作量，這些也是需要指出的，因為測試要考慮的東西一定要比產品經理多，用戶使用習慣，程序復雜度，與線上系統的兼容性等等，不然直接讓產品經理做測試不就好了嗎？
第三步就是細節問題的糾正，可以是界面，可以是文字，開發一般都是復制黏貼或者照著樣子畫葫蘆，這些小問題后期其實也可以測試出來的，但其鍋不在于開發，早點發現問題早點解決也是好事一件，至少不用提bug走一套bug處理流程了，也算給大家省點工作量，積少成多也是極好的。
當然需求評審能解決的問題也是有限的，一方面計劃往往趕不上變化，中間會有部分需求的改動，另外一方面有些深層次的問題只有在測試之后才會發現。但無論如何對于測試來說還是非常有必要的，大家一定要積極的參與進去，而不是像聽故事一樣啥問題都沒有，如果能重視起來不僅僅對項目的效率提高不少，而且也能讓后期測試壓力減小，何樂而不為呢？
2、技術設計評審
通過參與技術設計評審，可以為測試方案提供依據。**例如：核心業務是否需要接口測試、新老數據兼容問題、測試場景的數據構造以及測試所需的工具等，都可以在這個階段進行思考和產出。另外，可以有效的評估需求影響范圍和風險點，避免遺漏。
此階段是質量的基石，通過測試左移，盡早發現需求設計缺陷、技術方案風險、關聯方依賴影響等方面，了解測試關注點，需求可測試性以及預留排期等問題。
例如：
接口測試：會員權益核銷&&優惠券核銷&&退款，接口都需要對前端傳入的參數進行校驗
新老數據兼容，比如說小程序的發版，一般會滯后于接口發布，一定要測試舊版本的兼容性
3、測試方案設計
測試用例設計
需要從整體入手，而不僅僅局限于待測功能本身的業務邏輯。 好的測試用例，是質量保證的核心
測試用例評審
避免三方需求不一致，減少測試執行階段做無效工作，如執行無效用例、提交無效BUG等
測試數據準備
此階段是質量的骨架，通過測試設計，覆蓋更多的測試點、模擬更多的場景、做好更充分的測試準備，為質量保駕護航，為測試贏得更多寶貴的時間。
測試用例這一步不能忽略，即使改動很小，排期很緊，也建議要畫出思維導圖；要想提高測試用例設計能力，就需要平時就要多積累，對常見的缺陷模式、典型的錯誤類型以及遇到過的缺陷，要不斷地總結、歸納，才能逐漸形成體系化的用例設計思維。
同時，對于高質量的測試活動，用例設計不僅需要考慮明確的顯式功能性需求，還要涉及兼容性、安全性和性能等一系列的非功能性需求。
那好的測試用例是如何定義的呢？我在這里說說個人的見解：
不應該從是否能發現BUG的維度去定義，而是應該從集合的完備性角度去思考，也就是測試用例是否能夠覆蓋所有等價類以及各種邊界值為維度去衡量。
如果把被測系統看作一個池塘，BUG是池塘中的魚，設計測試用例集的過程就像是在編織一張捕漁網。好的用例集就是一張能夠覆蓋整個池塘的大漁網，只要池塘里有魚，這個大漁網就一定能把魚給撈上來。如果漁網本身是完整的且合格的，那么撈不到魚，就證明池塘中沒有魚，而漁網的好壞與池塘中是否有魚無關。漁網眼就是測試用例的粒度，粒度越大，意味著網眼越大，這就只能捕撈大魚，一些小魚就會漏網。這也是一些項目通用的現狀，測試活動由于受限于時間成本和經濟成本，只能采用基于風險驅動的模式，選擇合適的測試粒度，即有所側重地選擇測試范圍和設計測試用例，以尋求缺陷風險和研發成本之間的平衡。
我個人從下面3個維度出發：
整體完備性： “好的”測試用例一定是一個完備的整體，是有效測試用例組成的集合，能夠完全覆蓋測試需求
等價類劃分的準確性： 指的是對于每個等價類都能保證只要其中一個輸入測試通過，同子集下其他輸入也一定測試通過
等價類集合的完備性： 需要保證所有可能的邊界值和邊界條件都已經正確識別。做到了以上三點，就可以肯定測試是充分且完備的，即做到了完整的測試需求覆蓋
4、線下測試（含灰度）
橫向覆蓋：
對于一個場景，從開始到結束涉及到的關鍵節點，都要進行檢查點覆蓋，包括功能實現、數據讀取、數據計算、數據寫入等的正確性
縱向覆蓋：
正常場景、異常場景、補償場景都要覆蓋
探索性測試：
憑個人經驗進行探索性測試
回歸測試：拉取回歸測試集，手動測試和自動化測試相結合，在測試環境驗證新功能對原有功能是否產生影響；
此階段是質量的成型，通過測試設計的充分準備、線下測試的嚴格、立體的執行，發現和解決絕大部分問題。
在這里我把探索性測試單獨拉出來講一講：
根據需求描述來設計最初的測試用例，然后執行測試；在執行過程中，如果得到的輸出和預期輸出不完全一致，于是會猜測這種不一致是否可能是軟件的缺陷造成的；為了驗證想法，你會根據錯誤輸出，設計新的測試用例，然后采用不同的輸入再次檢查軟輸出。經過幾輪這樣的猜測和驗證，進行反復“探索”，最終確定了一個軟件的缺陷。
但是識別缺陷的思路和測試用例的設計，并沒有出現在最初的測試設計和測試用例文檔中。探索性測試是一種測試風格，并且強調依據當前項目上下文選擇最適合的測試技術。同樣的測試風格，由不同的人來具體執行，得到的結果可能會差別巨大，一直強調測試分析能力是最重要的技能。
5、線上測試
回歸測試：
拉取線上回歸測試集，并結合自動化測試，保證核心流程測試通過
新功能測試：
拉取新功能快速驗證測試集，并確保覆蓋新功能核心測試點
此階段是版本質量終態，線上測試主要是為了確保代碼部署、生產配置、生產環境對質量的影響。
6、測試復盤
在發布上線后，對測試過程進行復盤，總結遇到的問題，對當時的解決方案進行探討。通過復盤，從而達到指導后續工作，減少重復踩坑。并在可以在個人復盤完成后，在部門內進行信息共享。每個人負責的項目雖然不同，但是測試思想確有共通之處。通過復盤分享，可以有效提升團隊整體測試經驗。
此階段是測試經驗累積階段，也是容易被忽略的階段。通過信息共享，大大降低重復踩坑的概率。
7、線上監控
通過選取業務流程中優先級高的測試用例，作為心跳測試用例定時運行，并持續進行補充完善。
接口測試用例的開發進度落后于新功能的發布節點。自動化不是跟著新需求走，而是測變化的東西對不變東西的影響。
此階段是測試活動右移，質量補償，快速響應和解決，降低生產事故造成的損失。
三、總結
通過規范測試流程，全覆蓋產品生命周期，量化測試產出，在有限測試資源下的提升產出
推動力是衡量測試角色能力的重要指標，特別是一些需求不明確的項目，在各個階段都要保證信息在團隊成員間的一致性
目前的不足之處：
測試用例評審流程：郵件or會議， 需要產研給出積極響應；
測試各階段的準入準出條件模糊：進入開發、進入測試，要有基本的要求，一環連著一環，在某些階段確實可以加入一些提交基線，比如進入測試階段之前增加提測基線（類似冒煙）
技術沉淀不足，異常場景模擬依賴開發人員
本文內容不用于商業目的，如涉及知識產權問題，請權利人聯系51Testing小編(021-64471599-8017)，我們將立即處理
亚洲春色校园小说_欧洲精品色在线观看视频_国产思思99RE99在线观看_天天躁日日躁狠狠躁日日躁