1、為什麼我們需要ui自動化測試？ui自動化測試的focus應該在哪幾個方面？
測試自動化並不是為了贏得老闆的讚賞，或者認為這是乙個很潮的技術，不用就會落後，而是為了發現問題，提高產品的質量。做ui自動化測試的主要目的也是基於此的。 除此之外，ui自動化測試還可以從乙個終端使用者（end user）的角度來發現問題，對大數有ui的系統來說，ui是最理想的整合/系統測試入口，也是最需要測試的地方。
ui自動化測試應該集中在：
1）ui的文字，**顯示正確性
2）ui的互動邏輯正確性測試
3）ui上的使用者行為正確性測試
4）如果可能，ui的使用者體驗性測試（這個通常並不適合）
2、什麼是gui自動化測試的難點？
對比手工ui測試，ui自動化測試有如下的難點：
1）從ui測試的角度來說，乙個非「預期」產生的缺陷很難被自動化測試發現，而手工測試則能輕鬆的發現這個缺陷；
2）ui本身的變化性，要想達到和手工測試相同的覆蓋率，單純的ui自動化測試往往很難證明自己的投資回報；
3）ui控制項元素本身識別的複雜性；
4）ui自動化測試出現問題時，恢復到下一條測試case執行的場景是複雜的。因為出現這種問題的意外，是非「預期」的；
5）ui的測試case，有很多是關於使用者互動方面的，而這方面也其一定的複雜性；
3、如何做出更好的ui自動化測試？
1）要盡量避免ui自動化測試。這點似乎與我們的初衷有點背道而馳。但細想一下，它還是有一定道理的。
其原因是api和功能層級來說更加穩定，所以其自動化和維護的成本都比較低。相比而言，ui自動化測試因為有上述的諸多難點，所以其實施起來比較困難，導致它的開發成本和維護成本都要高出許多。因此，有的公司的自動化測試就有乙個721原則，即70%的測試工作集中在底層介面測試和單元測試，20%的測試工作為整合測試，其他10%的測試即為介面測試。
2）對於ui本身的變化性和ui控制項識別的複雜性，利用id/name定位元素設定ui map，與開發團隊約定元素的命名規則，在盡可能的情況下，確保ui的可自動化測試性。當業務發生變更時，乙個好的模式或者框架來讓測試自動化更加便捷，包括要對業務進行分層，關注資料儲存和資料驅動，做到測試資料與測試**的隔離，ui自動化操作與業務測試邏輯的分離。
3）對ui自動化出現問題時，不能很好的恢復到下一條case的正確執行場景（我們可以稱之為恢復測試場景或batch run），可以通過組織良好的case，我們寫case的時候傾向於case之間是沒有關聯的。我們希望乙個case在執行的時候，它自己能夠將初始化和結尾的工作先做好，a case和b case不應該有關係，b case的成功與失敗不應該依賴於a case的成功與失敗，乙個好的case應該這樣設計。但是有時候a case做完，我們需要先新增乙個使用者，然後再刪除這個使用者，這種情況下，如果沒新增就去刪除，則是失敗的，兩者之間存在一種依賴關係。
在這種設計的情況下，有乙個解決的思路是支援case間的依賴，你可以定義乙個標籤去說明某個case依賴於其他的case，這樣就先執行被依賴的case，然後再執行這個case，確保了執行的順序。
如何做好非標自動化裝置的設計
2 在非標裝置的設計上，首先，在標準零部件的選擇上，盡量採用成品件，以便有效降低非標產品在原材物料消耗 管理費用 成品率等方面的成本。採用成品件還能使裝置在投入市場後有更好的可靠性能，延長裝置的設計製造週期，提高設計效率。其次，非標裝置的設計，還要在滿足工藝設計條件的基礎上，認真研究裝置的技術方案，...
自動化測試指令碼開發的方式
1 線性指令碼的編寫 就是順序的簡單的錄製回放 非常低的指令碼開發成本，要求 能力較低，不需要計畫和設計，測試資料在指令碼中，維護成本較高 2 結構化指令碼的編寫 就是在編寫的指令碼中使用結構控制 比線性開發指令碼成本較高，要求有一定的 能力，需要簡單的計畫和設計，測試資料在指令碼中，維護成本相對低...
如何採取衡量的方法來進行自動化滲透測試
發現和利用web應用登入機制 使用者會話管理和sql注入中的漏洞同樣是如此。同樣地，單個函式 例如發現sql注入和從資料庫提取資料 也可以實現自動化，但整個過程不能被自動化。這個過程需要人類互動和專業知識來知道在 定位漏洞利用以及如何獲得最好的結果。工具只是輔助 人們對自動化的渴望讓流行的漏洞掃瞄器...