最新一期班級的web實戰項目已經結束，除了必要提交的一些測試相關文檔外，還特意給每位學生布置了一個作業：
寫一篇關於項目實戰的心得，內容主要是總結項目經驗不足以及項目收穫。就好像真實工作中，項目完結後的項目總結一樣。藉此希望培養大家的自我認識和總結能力。
當然不排除有個別些同學會提交一些“流水賬”給老師，不過總體而言，發現很多童鞋還是很有感觸的。
現給大家做下部分作業分享，這些來自於新手測試人員的經驗，希望可以幫助正在讀這篇文章且處在測試入門的你，能少走彎路。
@檸檬班45期來自廣州學員-貓咪：
通過參與項目實戰，更加清晰測試工作一個完整流程：測試計劃-測試用例-用例評審-執行測試-提交BUG-迴歸BUG-BUG關閉-BUG分析與總結-寫測試報告的每一個階段。
在編寫測試用例的過程過重新複習了一次等價類，邊界值，流程圖，場景法，錯誤分析法等各種方法，懂得考慮功能交互以及隱含需求的挖掘。進一步鞏固了測試知識。
瞭解一個新的BUG管理工具-禪道，初步掌握了禪道的基本應用功能，以前公司使用的BUG管理工具是TD。熟悉web端的測試方式。
懂得了需求分析的重要性，操作web端功能不熟悉，執行用例比較慢，執行效率不高，從而更加認識到需求分析和熟悉業務操作的重要性，一定要理解需求，熟悉業務流程。
對於寫測試報告，再次熟悉了寫測試報告的規範內容。以及如何使用BUG管理工具導出圖表。
@檸檬班45期來自杭州的學員--VV：
對於沒有測試經驗的我來說，這次的測試項目真正的讓我有了測試整個流程的體驗，前面幾節課的理論也有了真正的應用。這個模擬真實場景的體驗讓我也體會到了很多思維方式上的不足。
首先是需求分析部分。這次的項目是第一次有了需求規格說明書，需要我們對需求進行學習以及分析.
老師對於項目需求的講解也讓我瞭解到了需求分析時對業務流程熟悉的重要性。在自己畫完業務流程圖後確實對於整個項目操作的流程更加的清晰明確。
在測試用例的編寫部分是學習到最多的。
1、在測試用例的編寫上首先一個用例儘量覆蓋所有有效類、一個用例只覆蓋一個無效類。
2、在測試步驟的編寫上可以融入很多正常功能測試的測試點，這樣就能避免測試用例的繁瑣冗餘。
3、對於一些錯誤格式長度的測試用例編寫，可以寫在同一個測試用例中，並在測試輸入中明確寫出錯誤的類型以及長度和組合，便於後續的測試及測試用例的補充，整體也不會顯得太過繁瑣複雜。
4、子項目的測試用例編寫應該每個輸入框都分開分析，如手機號輸入框和密碼輸入框，如果手機號密碼一起寫容易漏掉一些測試點。
5、在測試點的分析上需要更嚴謹的正反面思維方式以及更多發散的思維，根據長度、組合、必填、重複這四個點對功能進行正反面的測試點分析.
一一寫出各方面對應的數據要求，不能只在腦海裡無序的想，在測試中還要有一定的發散思維，對用例進行完善，如對於超時驗證碼的驗證這個就是我原來沒有想到的一個測試點。
@檸檬班45期來自上海的學員--杯子：
一個實戰項目全程跟下來，對小白的我來說，從聽的時候懵懵懂懂，到自己編寫測試用例、再修改、再執行、再找bug並跟蹤，最後編寫測試報告，可以說還是學到很多的。
在需求分析評審階段，老師一開始先是發了前後臺的需求規格說明書以及業務流程圖等讓我們自己進行預習，理解，之後再課上逐一的講解了金融公司的項目的聯繫以及相對應的系統操作，同時把成員架構也解釋了一下。
之後按照大致需要測試的模塊以及人員的情況進行分組，以便更好地測試。
到了設計階段，我個人覺得這是整個測試的關鍵，一個好的測試用例的編寫可以省去後期很多的麻煩，這就需要提前和項目經理、產品經理再三確認產品的需求.
我主要要通過等價類、邊界值等用例設計方法按照說明書中的需求去一一尋找出測試點，因為以前從沒有經歷過編寫測試點，這就更需要我耐心，沉得住氣去慢慢摸索，歸納出一條方法。
給出的說明書中先要仔細通讀，然後研究每個模塊中他所要進行測試的點。
首先要進行的是冒煙測試，對大體流程能否順利完成進行的測試，如果主流程都無法完成更不要說後期的測試；
之後每一個可以輸入字段的文本框肯定也都是一個測試點，關於手機號，驗證碼，密碼這類都需要運用到等價類、邊界值這些分析方法；
其次每一次鼠標點擊也都是一個測試點，我要看能否順利的跳轉，能否給出正確的反應。
除了這些測試點我還要自己去深度挖掘這份說明書中隱含的一些需求以及行業標準，比如不同銀行卡的構成是什麼樣的，長度的邊界值是多少，諸如此類，只有更好的瞭解了這些知識才能幫助我把測試點更全面的羅列出來。
整理完測試點之後測試用例的編寫就會較容易了，我這時候根據所羅列的測試點來編寫測試數據，然後寫出測試步驟，預期。這樣初步的測試用例就可以完成了，後期如果還有根據場景法以及錯誤推測法整理出的測試點也直接往裡添加就可以了。
設計階段結束就應該是執行階段了，根據整理的測試用例來一一進行測試，有問題的就在禪道提交bug。在找bug的階段要注意的是bug最好都有截圖配，如果是偶現bug那最好多執行幾次。其次不要提交重複bug，這樣對開發、對自己都是很浪費時間的。
等自己測試完畢bug也都提交完畢，等待開發修改bug並且重新部署測試環境，我們進行迴歸測試進行追蹤，解決了就關閉bug，沒有就繼續跟蹤直到最後達到上線標準。
最後就是評估階段，我們測試都結束了之後需要編寫一份測試報告，彙報測試情況.
具體的執行情況包括實際案例總數、案例成功率、執行個數、成功個數等等，除此還有bug的提交情況，已解決的、未解決的、延期解決的這些情況都需要在報告中體現出來。
@檸檬班45期來自福建的學員--禮：
本次測試經歷了一個項目完整的軟件測試工作流程，使我們真實體會到了測試工作的具體流程是怎麼樣的。經過此次測試後，我從中學到了以下幾點：
第一，需求的分析與評審。
對項目需求的分析深度直接關係到後面測試的內容是否完整，所以這第一步也是非常重要的一步。經過此次需求分析我從中發現了自己對於功能交互方面的需求分析還不夠充分，還需要更加深入的分析才可以。
第二，測試用例的設計與評審。
測試用例的設計直接關係到我們測試結果的質量，首先，測試用例的覆蓋率應當達到100%；其次，測試用例的優劣也很重要；最後，測試用例在設計時應當結合多種用例設計方法對系統進行更加深入的測試。
測試人員在用例設計時應當具有發散性思維，多考慮用戶真實操作環境可能出現的情況，從而進行用例的設計可以使測試內容更加完善。
第三，測試工作的開展。在進行系統的正式測試前應先進行冒煙測試對系統主要流程正常驗證，冒煙測試是正式測試前最基本的且必須進行的測試，是後面的測試的基礎。
測試工作正式開始的時候，除了按照測試用例對系統進行全部的測試外，測試人員還應當通過發散性的思維對系統真實操作環境可能出現的情況進行更加深入的測試。
======================
因為篇幅有限，所以我們這次只分享了三位同學的作業，以後有好的作業會再拿出來給大家分享，這些都是來自檸檬班內部學員一些心得分享，如果想要交流可以後臺留言哦。
PS：
檸檬班明天有公開課哦
2018年開年第一次公開課
由咱們的華華老師主講
專門給跳槽換工作的你所準備的
《年後跳槽必殺技》
閱讀更多 檸檬班軟件測試 的文章
