中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：如何提升項目管理過程中，測試階段的工作效率呢？本文作者將測試過程整體分為幾個階段，分析如何提升測試階段的工作效率，希望能給你帶來幫助。

最近兩個月一直在協助交付團隊面試測試人員（功能測試），但是不知道什么原因，通過率極低。包括去年也斷斷續續在面試測試崗位，通過率也不高。

我始終覺得自己的要求并不高，沒有很多天馬行空或者實際工作用不太上的問題考察，始終圍繞一個核心問題在考量，也就是今天想和大家分享的：如何提升項目管理過程中測試階段的工作效率。

大多數候選人在回答這類問題時，更多的是把角度放在了某一具體節點上。比如執行案例的時候怎樣更快一點，或者想辦法讓開發人員改bug更快一點（沒有具體更快的方式，只是提到了要更快），或者說引入自動化測試、引入某些測試管理工具。但是無論哪個回答，都缺乏深入思考，缺乏具體可行的方法，缺乏對整個測試管理過程的全盤考慮。

下面我來分享一下自己的想法。

首先把測試過程整體分為如下幾個階段：

• 分析需求
• 制定計劃
• 用例設計（編寫+評審）
• 用例執行（冒煙+內部+聯調+驗收）
• 配合上線、測試總結

Ps：不同的團隊分析需求（和需求分析不一樣）和制定計劃順序可能有先有后，用例執行階段會有差異，且整體執行的測試輪次也不一樣，這些區別就不詳細贅述了。

01 測試人員對需求有天然的優勢

測試人員對需求的理解、熟悉程度，往往對后續的工作效率高低起著決定性影響。而且我始終認為一個熟練的功能測試者，應該是對所測系統中細節、邏輯、真實情況最了解的人，沒有之一，了解程度超越了項目經理、需求人員。

因此在需求分析階段，測試人員可以提出很多建設性意見，比如這個改造對現有邏輯影響的大小，或者細節上是否考慮不周等。而實際中很多團隊的測試人員可能就沒有參與需求分析，這也側面形成了后續測試過程進度緩慢或者質量不佳的原因。

所以需求分析階段測試的提前參與，或者針對已經定版的需求盡快吸收消化，對后面整體的執行過程會起到很大的促進作用。

02 測試人員的計劃往往不是自己定的

按正常流程來說，需求理解之后，會形成用例的腹案，針對本需求的難易程度及時間計劃會有一個大體的概念，最終在制定計劃的時候再結合團隊中各個崗位的實際情況評估出最終計劃。

但更多情況是：任務計劃的節點是跟著項目周期而定的。

比如說我評估一個項目的測試時間計劃為1個月，但是項目整體周期才3個月，需求、設計、開發、投產準備，哪個階段都不能省，哪個階段時間都會被壓縮。所以測試時間被領導或者甲方壓縮了?！鞍雮€月能不能干完？能干完那就按照這個時間來做計劃吧?！?/p>

所以在計劃階段，我覺得更重要的不是我們評估需要多久，怎么安排組內工作。而是在工期被壓縮的情況下如何排計劃、分任務。

如果我們能找到“主線任務”，合理的進行優先級排序，并在任務安排過程中能夠人盡其才，那制定出來的計劃才可能是一個高效的計劃。同時還可以考慮和其他節點交叉時間，比如提前進行用例評審，提前進入某些功能的測試執行階段等。

03 用例到底寫到什么程度才算合格

在用例編寫和評審階段，我們可以從工具、規范、全面性三個角度來提升效率。

工具即選擇更適合團隊的用例管理工具。如果是一兩個人的測試組，那可能Excel或者思維導圖更高效；如果是多人測試組或者遇到異地辦公的小組，可能需要線上的用例管理工具，但工具又會有工具的弊端。無論哪種方式，都要適合團隊，且能講出工具的優勢。

規范則是大家對測試用例編寫和評審的規則要求，所有人都要按照同樣的規范編寫，后續評審、執行、組內協同、人員變動才能更節省時間。同時規范也是為了易讀、易用。比如所屬模塊一定要用詞統一；一定要包含測試點、前置條件、執行步驟、預期結果等關鍵要素；不同的要素怎么寫，也可以根據項目情況來自行定義。

評審時針對規范性、易讀易理解等方面進行考量，也能保證用例的產出質量，為后續的執行階段鋪路。

全面性就不用解釋了，用例是否滿足需求，覆蓋度是否完整，本身就是測試人員始終需要重點關注的問題。但是當有候選人說出了要盡量保證用例的全面性之后，我會反問：怎么保證全面性呢？大多數候選人除了表達和需求一致之外，就沒有什么其他具體方法了。

所以這個問題大家可以交流一下，今天就不展開探討了。

04 執行階段的幾個常見問題

用例執行階段是耗時最長，最有可能造成計劃延期的，也不是寥寥數語能涵蓋全面的。我想重點從幾個常見問題上入手來提高測試效率。

1. 你會把缺陷定位準確之后再提給開發人員嗎？
2. 你會幫開發人員排查關鍵問題嗎？
3. 冒煙測試沒通過，你有把代碼打回去的勇氣嗎？
4. 修復A缺陷從而引起B缺陷發生，這種關聯性bug你有預防手段嗎？
5. 發現功能邏輯不合理，你會和需求或項目經理據理力爭嗎？
6. 你和開發人員相處愉快嗎？溝通效率上有提升空間嗎？
7. 如果有甲方或者第三方的人員來進行驗收測試，你和他們相處有哪些技巧或經驗嗎？
8. 你們團隊開發組有自測流程嗎？是形同虛設嗎？

以上8個問題都或多或少的指向了提升測試效率的具體方法，本次只重點聊一下第四個問題。

關于關聯性bug我在面試時經常會問，我覺得測試人員在提一個新的bug時，如果能夠預想到關聯功能，或者在解決這個bug時有自己的分析方案，一定要在備注中寫出來。

當然這些關鍵性問題在需求評審、用例評審過程中可以提前預知的，就可以先提出改造風險并形成相應的設計方案，以提高各方關于這類問題的重視程度與方案的完備程度。

這種關聯性bug是非常耗時耗力的，最好的預防手段就是提前指出、提前關注。

我相信大部分項目在熟悉之后，都是能夠準確預見關聯性缺陷的，能多預見一個，測試效率就提高了一分。

05 寫在最后

其他的階段就不再詳細討論了，還是希望我們在工作之余，能夠跳出工作中的繁瑣事務，針對自己的效率、方法、目標等進行復盤。自己復盤收效少的，可以多找同事、領導聊天，打破自己的思維限制，不然天花板就在前方等你了。

關于測試階段提升效率的方法，從思維模式到某些具體的方式，都能夠舉一反三到其他崗位的工作中。所以今天分享以上的內容，希望能夠拋磚引玉，為大家帶來些更好的思路。

可能是因為我們的招聘范圍更多在二三線城市，互聯網行業平均線本身就與一線城市有差距，同時又有出差的要求，所以讓很多有能力的測試人員望而卻步。

希望我們團隊能盡快招到合適的人員，也希望各位互聯網同行們能努力工作、善于總結、提高效率、共同成長。

本文由 @不想延期了 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。