個人工作月總結范文
一、需求測試總結
加入到產品化項目組已有兩個月之多，參加過完整的需求測試模塊-我的云盤，對于需求測試的認識有了較大轉變。剛開始認為需求文檔僅是我們測試人員熟悉系統的文檔，方便后期用例框架和用例的編寫，我們應該嚴格按照需求標準去評判對錯，認為需求是產品人員獨立定下來的和開發人員以及測試人員無關。但是真正的經歷過一個完整的項目周期后，會發現之前的認識是很片面的。對于一個產品來說，需求很可能是不斷變化的，不是每個需求都是有效的，更不是每個需求開發都能實現的，項目后期一個小小的變更都要付出較大的人力和時間，因此我們有必要對需求進行嚴格的測試和把關，爭取做到每個需求都是有效并且可以實現的。目前，我們產品化項目組采用的是敏捷開發模式，這就要求測試人員能夠快速應對新的需求，短時間內熟悉功能并提出需求疑問。
對待提出的需求疑問不能坐以等待，作為敏捷測試人員，我們應該是主動去推動產品進行需求答疑，及時組織好需求傳遞工作。主動性在敏捷模式中顯得尤為重要，有新的需求就應該主動積極的`了解并去思考與它有關聯的模塊，會不會對已用功能產生影響，會產生怎樣的影響等等。功能需求、非功能需求都應該是可驗證的，需要將需求中有二義性和需求不夠明確的都提出來，解決需求中所有不明確的地方。
真正的了解需求才有資格做測試，如果你不知道什么是正確的，那你提BUG的依據又在哪里?你提的BUG又怎么讓開發人員心悅誠服地接受并修改呢？話又說回來，只有明確了需求，也才能真正提出隱藏在軟件內部，深層次的BUG，提出那些讓開發人員覺得受益的BUG，也會受到開發人員的尊重與歡迎，也才能體現我們測試的價值。否則，不明確需求，在界面上點點，提一些邊邊角角的缺陷，讓開發人員不開心，覺得測試人員沒水平，竟提些無關痛癢的BUG，浪費他們的時間，領導也會覺得測試的意義不大。
二、測試能力的提高
從需求測試—用例框架—用例設計，測試的基本能力相比之前有了較大提高。用例框架我是寫了又改，重復了很多次，期間很感謝組內的小伙伴給我的指導和意見。記得學科資源后臺管理用例框架改了不少于10次，這個也是我第一次接觸的較為完整的系統框架，剛開始各功能點很零散，沒有一個測試主線。學習到一個檢查用例好壞的方法，就是自己執行一遍自己的用例，感受一下效果，你會發現很多用例中不合理的地方。測試從UI到功能都需要有一條完整的線路，沿著一條主線走，不至于寫出的測試點看起來很混亂�？蚣艿闹黧w有了之后，就需要向里面注入詳細內容，結合測試模塊的特點，將其細化成一個個用例點。框架有血有肉之后，用例就可水到渠成了，需要注意的是用例語言的描述，一些語言的描述盡量做到大家熟知，用例描述詳細的基礎上盡量做到簡潔明了。用例的描述對于我們新人來說往往是矛盾的，既要做到所有人都能看懂并會去執行它，同時又要做到步驟清晰明了，沒有冗余描述。這其中的技巧絕不是一時半會就可實現的，需要我們不斷的去練習，不斷的去思考，不斷的去學習。
三、個人總結
分配到資源平臺項目組這段時間，讓我對測試工作有了更全面的了解。書本的知識到實際運用中會有許多差距，但是有一些本質的東西還是不變的�！盾浖こ獭分性S多關于測試知識當時很難明白，尤其是一個項目中代碼開發的工作量確不到工作總量的30%，把很多問題都花費在文檔編寫、需求分析等等。軟件開發不就是寫代碼實現功能嗎，為何做哪些無用功呢？當我參加了項目的實施后，就逐漸的明白了這其中的道理。
目前，還存在許多欠缺的地方：1.根據指導人分配的階段性任務，不能很好的安排每日工作計劃，導致實際工作于預期差距較大，需要從每日的計劃中吸取經驗，逐步完善。2.工作的效率不高，缺乏主觀能動性，需要在今后的工作中逐步克服。3.測試技術的極度缺乏，自動化測試、安全測試、性能測試這些都是大數據時代的主流測試方向，學會這些必須掌握測試技術，至今為止還沒接觸過。需要利用課余時間自主學習，另外可利用公司的培訓增加自己的測試技能。
【個人工作月總結范文】相關文章：
金店銷售個人工作月總結11-10
出納月個人工作總結09-18
教師一月個人工作總結范文01-08
教育實習月個人工作總結08-02
安全生產月個人工作總結08-24
12月班主任個人工作總結范文12-14
二月份個人工作總結范文03-26
12月保險公司個人年終工作總結范文12-20
幼師實習月總結范文_幼師工作總結范文08-25
園長月的工作總結范文07-07