PPT模板下載：/moban/

軟件測試工作述職

陳鵬挑戰未來目錄測試部規劃測試部結構與職責測試部結構與職責職責項目測試組：負責所測試版本的功能及非功能性需求的測試及自動化工作，并對版本進行商用風險評估，確保版本發布質量以及重大問題的提前暴露，并對版本上線質量負責。自動化組：負責自動化工具、自動化框架以及持續集成能力的建設。測試系統組：負責測試部的測試技術能力提升，包括但不限于測試設計、性能測試、穩定性測試、可靠性測試等軟件測試部測試系統組自動化組項目測試組全院自助測試組病歷本測試組……軟件研發部定位及時暴露從需求、設計、開發、測試、發布各階段在軟件質量方面的風險，并協助系統、開發組給出有效解決措施，確保軟件上線質量，并對版本上線質量負責。測試規劃測試需求及設計迭代開發發布擰的清需求1、參與到需求分析及方案設計的評審，可提出有效建議及可測試性需求；2、輸出性能、穩定性、可靠性測試方案與用例，輸出場景驗收用例3、提出自動化需求并遞交到自動化組實現框架講的了實現1、和開發結對，完成story文檔，并輸出用例2、對于迭代期間的用例，在轉測試前均可完成自動化；3、知道story實現細節，可以獨立畫出story的用例圖、時序圖，可以評審每一種實現細節的弊端以及測試重點4、和一線駐場維護人員建議并維護長連接，知道軟件現階段的痛點及典型使用場景，落實到story測試設計中做的好測試1、通過開發工具、打樁或提前準備等方式，可以完成全部用例的執行2、評估被測試版本的功能、性能、可靠性、安全等的質量，并輸出測試報告及商用風險評估報告3、可得到版本的代碼覆蓋率，并能評估未覆蓋部分的風險；4、將自動化用例集成到持續集成框架中，并能穩定運行5、有一套健壯的接口級及UI級自動化用例，可一鍵式，可覆蓋所有基本功能及基本異常干的了攻關1、可完成一線緊急問題的快速定位，并給出規避解決措施；2、能通過負面反饋回溯之前的測試過程問題，并能進行關聯分析測試，保證類似問題不再發生；時間表2015：完成紅色部分70%的成熟度建設2016：完成紅色部分90%的成熟度建設，并完成藍色部分50%的成熟度建設團隊協作（長期）1、系統組在輸出干凈的需求及方案設計的前提下，輸出軟件demo，確保方案的可行性，避免風險下沉到開發、測試團隊協作（長期）1、測試通過構建完善的一鍵式自動化用例集，逐步把功能測試移交到開發組內部，實現開發組內部可隨時開展系統測試，提升開發人員整體思維能力的同時，解放測試人員時間，測試人員專注開展DFX測試及項目風險熱圖問題解決測試人員能力提升計劃培養類別培養范圍達標項培養手段培養時間產品專家全員1、掌握產品實現細節，可獨立畫出功能的時序圖；2、詳細掌握內部日志細節，可以獨立定位出問題模塊，并給出解決建議；3、測試手段豐富，可以完成用例100%的測試執行。1、測試串講2、UML建模培訓，能熟練使用用例圖、時序圖等工具對于產品做場景分析及內部功能分析。2015.8.11--2015.9.15性能測試專家每個項目一名1、可以依據產品的內部架構以及實現方式，分析出精準的測試點；2、熟練使用loadrunner、jmeter等性能測試工具，或獨立依據測試需求開發測試工具進行性能測試3、可以進行性能問題定位，可以給性能調優給出有效解決方案1、每個產品開展性能專項測試，并由測試系統組成員專項指導2、組織性能測試培訓2015.8.11--2015.10.30可靠性測試專家每個項目一名1、可以依據一線的典型組網，分析出一線的全量故障模式；2、具備測試手段模擬全量故障模式，通過測試，可以給產品提出有效的優化方案。1、每個產品開展可靠性專項測試，并由測試系統組成員專項指導2、組織可靠性測試培訓2015.8.11--2015.10.30測試人員能力提升計劃培養類別培養范圍達標項培養手段培養時間自動化測試專家每一個測試小組內部至少2名自動化測試專家1、熟練掌握web、桌面應用、android、ios、協議的自動化測試工具，依據既定的測試框架，可以完成所負責用例的自動化；2、掌握至少一門語言（推薦python或者java）1、自動化用例實現任務下沉到測試項目組；2、組織自動化培訓，覆蓋selenium、autoIT、robotium、appium、GT等測試工具；2015.8.11--2015.12.31質量設計師每個項目至少一名1、從需求到發布階段，可以給出精準的風險熱圖，并持續推動解決；2、可以獨立進行產品質量評估，輸出有價值的測試報告，能給商用提供有效指導；1、項目實戰中輔導2015.8.11--2015.12.31安全專家測試組1~2名與開發一起培養，達標目的待定待定2015.8.11--2015.12.31與開發的合作模式項目上強矩陣的管理模式：測試人員同時給測試負責人和項目負責人匯報。人員上資源池的管理模式：測試人員在項目測試結束后，回測試資源池，并建設測試技術能力，如自動化、性能、可靠性等。思考—論分工亞當.斯密的《國富論》以英國的一個小作坊作為開篇：在一個小鎮的做針的作坊里面，一共有10個工人，他們一個人抽鐵線，一個人拉直，一個人切截，一個人削尖線的一端，一個人鉆鼻等，他們一天可以生產四萬八千枚針，平均每人一天四千八百枚，但是如果他們各自獨立工作，獨立生產，一天都不可能制造出哪怕二十枚。系統開發過于細致的分工，在軟件領域是否合適？分工細致的大公司在軟件領域普遍存在的問題：三種角色組成一個甩鍋團隊，擅長內部扯皮。1、不了解軟件實現2、輸出的設計文檔過粗，對于開發的參考價值不大3、站的位置太高，不接地氣，導致設計落地不下去1、不參考系統人員輸出的設計文檔，按照自己的想法重新設計，往往還更實用2、只關注實現基本的拉通功能代碼，只做簡單的測試。反正還有測試人員在后面，輸出的軟件質量類似于demo，不具備DFX能力3、普通開發人員不具備整體思維，不會搭建測試環境，只是碼代碼測試1、按照系統組的需求文檔以及設計文檔輸出的測試用例，怎么轉測試后，和預期的完全不一致？2、成為了開發人員的測試工具，過多的精力在簡單的功能測試中，導致軟件的性能、穩定性、可靠性、安全、易用性等問題大量漏測解決方案？思考--測試行業1、測試人員均是產品專家，對于產品內部的模塊劃分與實現細節熟練掌握，可以手工測試，自動化測試較少；2、測試團隊70%以上的時間在功能測試，性能、穩定性、可靠性等開展較少；3、沒有持續集成等工程能力；4、沒有取得代碼覆蓋度等數據，沒法評估測試充分性；測試高級階段測試初級階段測試中級階段1、建成了完善的灰盒、黑盒自動化框架，并輔助開發，逐步把功能測試移交到開發團隊內部進行；2、進行充分的性能、可靠性、穩定性、安全等測試，并可以給予評估；3、具備持續集成等工程能力，且可有效提高歸檔、測試效率；4、可以評估代碼覆蓋度，并能分析未覆蓋代碼的風險；5、可以對產品做商用風險評估。1、測試工作已完全融入團隊內每一個人的基礎工作中；2