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