讓自動化指令碼在冒煙前執行，我想很多人都曾想過，也曾試驗過，為什麼最後放棄了？
我能夠收集到的原因有以下幾種：
1．**開發沒有完成。
2．程式不穩定，頁面布局變動大。
3．編寫指令碼的時間緊張！
我作此嘗試的初衷是為了
1、拉長
web應用程式測試時間（測試時間是軟體質量保障最重要的手段之一）
2、讓自動化測試指令碼代替一部分手工測試，不是全部。
3、將資料庫中資料校驗部實現自動化。
所有的人都知道自動化測試指令碼不可能
100%
替代手工測試，既然這樣，能代替多少就多少。
總是能節約時間的，也能為日後的自動化測試回歸指令碼作準備。
所有測試都知道，測試介入越早越好，事情越早解決越好。
測試用例本來是要時時更新的，為什麼測試指令碼就不能時時更新呢
我暫時採用的工具是
qtp
1、使用物件庫
2、讓能跑起來的都跑起來，不能跑起來的暫時不管
3、先採取固化指令碼的思路寫指令碼
4、通過
url訪問開發人員本機（因為開發人員只開發本應用，其他調的是
daily
能實現）
5、並行編寫自動化指令碼
6、採用單瀏覽器
7、在測試計畫裡合理安排出編寫指令碼的時間
在實際運作過程中取得的經驗：
1．編寫
qtp指令碼的目的是提高效率，如果不能提高效率，就是暫不要作，別浪費寶貴的時間（這恰恰是太多使用自動化工具的人的誤區，一定要完美的用它解決所有問題）
2．修改指令碼時，錯誤大多類似，按照功能寫成函式，便於修改
3．編寫指令碼，當開發頁面大體出來時，要善於利用開發人員的邊角時間，比方說上班前半小時（這個時候開發在看郵件，或開晨會），或利用開發開週會時間，只要有1，
2個小時，足夠我們將頁面物件獲取了。
4．編寫指令碼，分成三步走
a.先編寫簡略版指令碼。例如
bwr().page().weblist(」
狀態「).select 「」
，先按這種方式寫乙個思路的初稿，特別是
sql語句要完成。
b.當頁面大體出來時，獲取開發的完成頁面（物件），此時再替換一下指令碼，修改一下，找出一些難點，衡量一下難度，如果有難度，就不要編寫，彈出乙個
msgbox
讓人工去校驗。
c.臨冒煙了，在搭環境時，將所有的指令碼放出來跑一跑，抓緊時機對對指令碼作修改，相信大多數的指令碼此時都能夠跑起來了。
d.ok
，開始冒煙了！，最讓人期待的時候來了，（此時指令碼的準確性，是讓很多人為之擔心的）那好，讓指令碼單步執行！我們盯著它！看看他實際運**況。相信這樣一種結合方式，自已能夠放心。也讓開發能夠採信我們的結果。
5．執行指令碼時，被測試的頁面程響應較
qtp指令碼速度慢，當乙個操作會更新資料庫時，讓指令碼
wait
一下，再去取資料。6．在
qtp中去資料庫取數時要用精確比較，不要用
like.
時刻謹記目標
,每天進步一點點
,然後就有一大步!
python自動化執行指令碼
2 終端下執行 crontab e解釋 users tongmeina pycharmprojects jiratopdf everyorg.py 的含義 為你要自動化執行指令碼的絕對路徑，必須是絕對路徑 30 的含義 參照鏈結 第1個 表示分鐘1 59 每分鐘用 或者 1表示 第2個 表示小時1 ...
UI自動化指令碼執行環境
專案頁面自動化分享 四 指令碼執行環境 x 專案，頁面自動化的執行大大降低了頻繁的手工測試，專案中不斷提出bug，開發修復bug，到bug再次批量出現，自動化節約了很多的手工測試時間，反覆的自動化回歸，使得專案測試效率大大提高。面對第二輪和主幹回歸測試中頁面自動化帶來的優勢，我真的很希望專案在預發和...
Xshell設定執行自動化指令碼
使用xshell工具連線操作linux系統，並編寫執行自動化指令碼示例 的例子，下面先貼上編寫的指令碼，這裡指令碼命名為cyp assout log.js 如下 xshell呼叫自動化js指令碼 主函式 function main view code 首先要先連線上準備操作的linux伺服器，然後在...