很多專案都有自己對應的自動化測試系統，你當前的系統體現出價值了嗎？覺得有下列幾種情況：
1、人力精力投入了，能經常發現**更新引起的bugs；
2、人力精力投入了，偶爾能發現bugs，不多，覺得投入與產出價效比不高；
3、沒怎麼發現問題，價效比低，甚至後期都沒動力維護。
當然還可以從 用例覆蓋率作為產入 發現bugs作為產出 作為維度來分析問題！
當然，自動化測試的啟動都是奔向第乙個目標，然後系統持續整合保持強壯性！
下面收集自動化測試過程中遇到的一些問題、方法思路
1、針對功能點寫了很多用例，貌似沒發現多少問題
應該思考的是，當前功能點是有經常改動維護的，不是一些已經成型很久都不動的功能點，對於前者如果寫了很多用例但是沒怎麼發現問題，問題有可能出在**呢？
舉個例子，該功能點經過評審後總結出需要寫10個用例，並分出來了3個優先順序高7個普通的，所以，最先入手並效果最明顯的就是先搞定那3個用例
當然寫用例要先看看實現起來困難不，一般是集中先寫 優先順序高+實現難度適中 的用例，其他的後續再補充。
也就是說用例的選型方法是值得斟酌的！
2、團隊裡面的反角色
有時候寫了很多用例，難道要等到問題出現的那天才知道自己用例的質量如何？不是的，可以在團隊裡面使用反角色人物，經過他的破壞，能及時反饋到測試用例質量如何。
3、需求經常變，我們只能等到研發最後開發完再寫用例
也就是說此刻測試的角色很被動，但是可以改善嗎？
需求會變，但是主線應該不會變吧？你總可以先寫主線的用例吧？然後及時跟進修改都行啊，連主線都改動很大那是需求方的工作有問題i啊！
既然主線還是比較明確的，先寫用例，後續需求明確下來了，有稍微改動，你再更新下用例也行啊！
也就是說，要從被動轉換到主動來進行。
4、糾結點，文件與robot用例如何加強關聯
魚與熊掌不能兼得啊，有了所謂的測試文件，評審後感覺像模像樣，後續robot用例展開了，需求變更的時候就體會到如果文件和robot用例能有個強關聯就好了，比如文件可以生成自動化用例等，目前還沒有比較好的對策啊。
5、配置如何only
一般來說，比如robot用例的配置-resource，庫的配置，shell指令碼的配置 三者如何只公用乙個配置的問題
6、追求易除錯
目前使用robot-jenkins環境，發現進行dailybuild後，如果發現問題除錯起來比較麻煩，所以從設計上講，不僅僅是當前能寫用例，還要講究後續方便維護和除錯，措施後續研究總結
自動化測試思考 2關注質量
如何讓花了很多人力精力的自動化測試體現出應有的價值？當專案越大，自動化測試內容就變得更龐大，易維護也成為問題，總的來說，基礎性工作要做好，基本來說我個人認為要做好如下 1 讓自動化測試系統穩定 環境要穩定 用例取樣要穩定 比如某些url受網路或者http伺服器的影響等，為了減少這種影響常規目的的因素...
自動化測試（1）
一 為什麼要進行自動化測試 1 解決 回歸測試 2 解決 壓力測試 3 解決 相容性測試 4 提高測試效率，保證產品質量 回歸測試 專案在發新版本之後對之前的功能進行驗證 壓力測試 可以理解為多使用者同時去操作軟體，統計軟體伺服器處理多使用者請求的能力 相容性測試 如針對web測試，可以對不同瀏覽器...
測試計畫和自動化測試思考
這幾天對 的測試計畫和自動化測試進行思考。先說測試計畫，測試計畫需要依據迭代開發計畫制定，需要有明確的測試範圍和測試目標。看了下q1的迭代開發計畫主要有 功能改進 bui改進 系統安全性改進 全頁面子資源監測 api元件改進。這些改進都是持續性的，沒有明確的改進需求和改進結果要求。因此進入測試之前無...