1、測試用例是測試工作的核心，寫測試用例的時候建議先提取測試點，再編寫測試用例。清晰且不容易遺漏。（寫測試用例的過程中要不斷的調整，之前用例覆蓋到的測試點可以不寫，覆蓋率全且避免重複）
2、測試資料要盡量真實。
3、測試時考慮到了別人沒有考慮到的問題點，最好要去一一和產品確認溝通過；或者是發現了設計上有不合理的地方也要指出，不要覺得測試的工作就只是找bug，要站在更高的層面上看問題。依稀記得產品經理說過的一句話：「如果開發沒有發現產品設計上存在的缺陷並提出，只能說明開發沒有站在乙個更高的點看問題」。
4、搞清楚bug產生的根源。好處在於：
5、描述bug時要準確，沒必要的誤導資訊不要寫，容易誤導開發人員，畢竟開發爸爸的思維有時候很獨特。。還有一點，遇到報錯的時候，bug描述裡可以把請求體和response裡的內容一同寫進去，這樣開發可以很快速的定位問題，他們也更偏向於喜歡這樣的測試人員。
6、心態方面：與開發溝通要掌握技巧，不要硬碰硬，站立自己的觀點的同時，語氣也要平和一些。還有就是提錯bug的時候（可能是產品改需求未及時通知，可能是自身原因）也不要覺得很尷尬、覺得很委屈，或者是去爭無畏的自尊心。在我看來做測試的基本條件之一就是心理素質要過硬。當然如果是產品改需求未及時通知，可以和產品提意見要求。
7、開發和運維之間的問題盡量讓開發自己去溝通，只需要提交到測試人員這邊是可測的就ok，提交過來不可測讓開發去溝通，因為自己攬過來可能又說不明白，切記不要做個傳話筒，除非自己很懂。
8、測試週期如果較短的話，一些偶然性問題不容易被發現，因此測試人員要盡量為自己爭取測試時間，盡量不要讓開發占用測試的時間。
1、在資料字段較多時，前後端容易取錯字段
2、格式轉換容易出現問題，前後端編碼不一致，導致特殊符號、括號變成亂碼；在測試之前要確認都會有那些特殊字元，建議是產品在原型上體現出來，開發和測試都可以注意到。
3、開發本地是好的，發布後測試是有bug的，一般有幾種情況：開發的**是否提交；運維發布的時候是否有更新修改點；開發本地環境與測試環境不一致；當然除了這三個原因，還會存在諸多因素，需要具體問題具體分析。
4、每次一輪回歸測試完成，第二天來了工作量不大的情況下建議上午還是要繼續測試，隨機性探索性測試，很可能會找到昨天沒發現的bug。需要不斷迴圈的測試，不是說一輪測完就等著回歸了~~
只是個人測試過程中的一些思考，如有錯誤望大家積極指正我哦~~~加油，在平凡的每一天給自己打氣~~~
1、測試用例是測試工作的核心，寫測試用例的時候建議先提取測試點，再編寫測試用例。清晰且不容易遺漏。（寫測試用例的過程中要不斷的調整，之前用例覆蓋到的測試點可以不寫，覆蓋率全且避免重複）
2、測試資料要盡量真實。
3、測試時考慮到了別人沒有考慮到的問題點，最好要去一一和產品確認溝通過；或者是發現了設計上有不合理的地方也要指出，不要覺得測試的工作就只是找bug，要站在更高的層面上看問題。依稀記得產品經理說過的一句話：「如果開發沒有發現產品設計上存在的缺陷並提出，只能說明開發沒有站在乙個更高的點看問題」。
4、搞清楚bug產生的根源。好處在於：
5、描述bug時要準確，沒必要的誤導資訊不要寫，容易誤導開發人員，畢竟開發爸爸的思維有時候很獨特。。還有一點，遇到報錯的時候，bug描述裡可以把請求體和response裡的內容一同寫進去，這樣開發可以很快速的定位問題，他們也更偏向於喜歡這樣的測試人員。
6、心態方面：與開發溝通要掌握技巧，不要硬碰硬，站立自己的觀點的同時，語氣也要平和一些。還有就是提錯bug的時候（可能是產品改需求未及時通知，可能是自身原因）也不要覺得很尷尬、覺得很委屈，或者是去爭無畏的自尊心。在我看來做測試的基本條件之一就是心理素質要過硬。當然如果是產品改需求未及時通知，可以和產品提意見要求。
7、開發和運維之間的問題盡量讓開發自己去溝通，只需要提交到測試人員這邊是可測的就ok，提交過來不可測讓開發去溝通，因為自己攬過來可能又說不明白，切記不要做個傳話筒，除非自己很懂。
8、測試週期如果較短的話，一些偶然性問題不容易被發現，因此測試人員要盡量為自己爭取測試時間，盡量不要讓開發占用測試的時間。
1、在資料字段較多時，前後端容易取錯字段
2、格式轉換容易出現問題，前後端編碼不一致，導致特殊符號、括號變成亂碼；在測試之前要確認都會有那些特殊字元，建議是產品在原型上體現出來，開發和測試都可以注意到。
3、開發本地是好的，發布後測試是有bug的，一般有幾種情況：開發的**是否提交；運維發布的時候是否有更新修改點；開發本地環境與測試環境不一致；當然除了這三個原因，還會存在諸多因素，需要具體問題具體分析。
4、每次一輪回歸測試完成，第二天來了工作量不大的情況下建議上午還是要繼續測試，隨機性探索性測試，很可能會找到昨天沒發現的bug。需要不斷迴圈的測試，不是說一輪測完就等著回歸了~~
只是個人測試過程中的一些思考，如有錯誤望大家積極指正我哦~~~加油，在平凡的每一天給自己打氣~~~
菜鳥的測試心得
1 完善的需求文件，原型，概要設計文件 通過這些開發文件可以了解整個系統的架構。要實現的功能，及業務流程。為測試計畫中的測試要素和測試策略提供依據。在沒有詳細的開發文件時，可以項開發人員詢問，或參考先前的軟體版本。抓住業務流程。2 測試計畫的重要性 測試計畫從時間上進行了部署，明確的測試的重點和內容...
關於測試的心得
1.深入理解uc 不管是日常還是專案，都要對uc有充分的理解。uc是由開發人員來編寫的，在思維方式與側重點上會和測試人員有所偏差。有時候會出現這樣的情況 開發人員認為自己的uc已經寫得很詳細了，但是測試人員卻不知道如何測試。這時候就需要測試人員和開發溝通，直至充分理解uc。這樣以後的uc評審 設計評...
Web測試心得
概論 文章中提到的東西都是工作中實踐過的經驗,並不保證全面性.web測試一般包含如下內容 功能測試 效能測試 使用者介面測試 相容性測試 安全性測試 其實這只是大概的區分,各種不同的類別的測試之間其實是有很多交集的.比如 以上的五項內容中的每一項都可以是乙個大的主題做深入的分析.另外,對於所有的we...