vmstat命令是最常見的Linux/Unix監控工具，可以展現給定時間間隔的服務器的狀態值,包括服務器的CPU使用率，內存使用，虛擬內存交換情況,IO讀寫情況。這個命令是我查看Linux/Unix最喜愛的命令，一個是Linux/Unix都支持，二是相比top，我可以看到整個機器的CPU,內存,IO的使用情況，而不是單單看到各個進程的CPU使用率和內存使用率(使用場景不一樣)。
一般vmstat工具的使用是通過兩個數字參數來完成的，第一個參數是采樣的時間間隔數，單位是秒，第二個參數是采樣的次數，如:
root@ubuntu:~# vmstat 2 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 0 3498472 315836 3819540 0 0 0 1 2 0 0 0 100 0
2表示每個兩秒采集一次服務器狀態，1表示只采集一次。
實際上，在應用過程中，我們會在一段時間內一直監控，不想監控直接結束vmstat就行了,例如:
root@ubuntu:~# vmstat 2 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 3499840 315836 3819660 0 0 0 1 2 0 0 0 100 0 0 0 0 3499584 315836 3819660 0 0 0 0 88 158 0 0 100 0 0 0 0 3499708 315836 3819660 0 0 0 2 86 162 0 0 100 0 0 0 0 3499708 315836 3819660 0 0 0 10 81 151 0 0 100 0 1 0 0 3499732 315836 3819660 0 0 0 2 83 154 0 0 100 0 |
這表示vmstat每2秒采集數據，一直采集，直到我結束程序，這里采集了5次數據我就結束了程序。
好了，命令介紹完畢，現在開始實戰講解每個參數的意思。
r 表示運行隊列(就是說多少個進程真的分配到CPU)，我
測試的服務器目前CPU比較空閑，沒什么程序在跑，當這個值超過了CPU數目，就會出現CPU瓶頸了。這個也和top的負載有關系，一般負載超過了3就比較高，超過了5就高，超過了10就不正常了，服務器的狀態很危險。top的負載類似每秒的運行隊列。如果運行隊列過大，表示你的CPU很繁忙，一般會造成CPU使用率很高。
b 表示阻塞的進程,這個不多說，進程阻塞，大家懂的。
swpd 虛擬內存已使用的大小，如果大于0，表示你的機器物理內存不足了，如果不是程序內存泄露的原因，那么你該升級內存了或者把耗內存的任務遷移到其他機器。
free 空閑的物理內存的大小，我的機器內存總共8G，剩余3415M。
buff Linux/Unix系統是用來存儲，目錄里面有什么內容，權限等的緩存，我本機大概占用300多M
cache cache直接用來記憶我們打開的文件,給文件做緩沖，我本機大概占用300多M(這里是Linux/Unix的聰明之處，把空閑的物理內存的一部分拿來做文件和目錄的緩存，是為了提高 程序執行的性能，當程序使用內存時，buffer/cached會很快地被使用。)
si 每秒從磁盤讀入虛擬內存的大小，如果這個值大于0，表示物理內存不夠用或者內存泄露了，要查找耗內存進程解決掉。我的機器內存充裕，一切正常。
so 每秒虛擬內存寫入磁盤的大小，如果這個值大于0，同上。
bi 塊設備每秒接收的塊數量，這里的塊設備是指系統上所有的磁盤和其他塊設備，默認塊大小是1024byte，我本機上沒什么IO操作，所以一直是0，但是我曾在處理拷貝大量數據(2-3T)的機器上看過可以達到140000/s，磁盤寫入速度差不多140M每秒
bo 塊設備每秒發送的塊數量，例如我們讀取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO過于頻繁，需要調整。
in 每秒CPU的中斷次數，包括時間中斷
cs 每秒上下文切換次數，例如我們調用系統函數，就要進行上下文切換，線程的切換，也要進程上下文切換，這個值要越小越好，太大了，要考慮調低線程或者進程的數目,例如在apache和nginx這種
web服務器中，我們一般做
性能測試時會進行幾千并發甚至幾萬并發的測試，選擇web服務器的進程可以由進程或者線程的峰值一直下調，壓測，直到cs到一個比較小的值，這個進程和線程數就是比較合適的值了。系統調用也是，每次調用系統函數，我們的代碼就會進入內核空間，導致上下文切換，這個是很耗資源，也要盡量避免頻繁調用系統函數。上下文切換次數過多表示你的CPU大部分浪費在上下文切換，導致CPU干正經事的時間少了，CPU沒有充分利用，是不可取的。
us 用戶CPU時間，我曾經在一個做加密解密很頻繁的服務器上，可以看到us接近100,r運行隊列達到80(機器在做壓力測試，性能表現不佳)。
sy 系統CPU時間，如果太高，表示系統調用時間長，例如是IO操作頻繁。
id 空閑 CPU時間，一般來說，id + us + sy = 100,一般我認為id是空閑CPU使用率，us是用戶CPU使用率，sy是系統CPU使用率。
wt 等待IO CPU時間。
下午內網
測試庫同事反應查詢更新數據很慢，有時甚至表都打不開，后來通過服務器【linux】的top命令查看了下，cpu和mem占用正常，但wait高達80%多(下面兩圖顯示的就是問題前后觀察EM對比的截圖,版本是oracle10gR2，EM的效果比oracle11gR2遜色不少哈)：
-------------------------------------->>
---------------------------->>
接著通過sqldevelpdev客戶端查詢有沒有鎖等待之類會話事件，果然有，而且是兩個session持有TX鎖，然后通過下面的sql查詢從oracle和linux級別kill掉了相應session,以為風波就此平靜，結果過了不到一分鐘查詢又出現，只不過這次只有一個session持有TX鎖，于是就去查找對應的sql_txt,找到后發現是個同事寫的存儲過程，定時任務，當時正在運行，讓其確認下是不是任務執行出問題了，結果一查，是程序問題，造成的死循環，它會批量發起會話，kill一個后接著又鎖，循環反復，后來他改了下程序后重新運行，一切恢復通暢.
--查詢死鎖 select sess.sid, sess.serial#, lo.oracle_username, lo.os_user_name, ao.object_name, lo.locked_mode from v$locked_object lo, dba_objects ao,v$session sess where ao.object_id = lo.object_id and lo.session_id = sess.sid; --oracle級別kill session alter system kill session '1627,1'; alter system kill session '1564,64740'; --查詢當前連接會話 select s.value,s.sid,a.username,a.MACHINE from v$sesstat S,v$statname N,v$session A where n.statistic#=s.statistic# and name='session pga memory' and s.sid=a.sid and a.sid=1626 order by s.value; --查詢造成死鎖的sql語句 SELECT a.SID, a.username, s.sql_text FROM v$session a, v$sqltext s WHERE a.sql_address = s.address AND a.sql_hash_value = s.hash_value and a.SID=1626 ORDER BY a.username, a.SID, s.piece; --造成鎖等待的操作內容 begin flt_com.p_line_relation_change(:A0,:B0,:C0,:D0,:E0,:ret_errorcode,:ret_errorname); end; --通過sid查找pid，進而通過系統級別kill select spid, osuser, s.program from v$session s,v$process p where s.paddr=p.addr and s.sid=1605; --服務器級別kill kill -9 spid --------------------------------over game |
java中環境變量的設置，主要是設置設置JAVA_HOME，CLASSPATH,在path變量中增加java的bin目錄。當然現在都是用工具開發，可以不設置CLASSPATH,可能會有問題，所以還是盡量設置、
JAVA_HOME
C:\Java\jdk1.6.0_30（java的安裝目錄，）
PATH
C:\Java\jdk1.6.0_30\bin（%JAVA_HOME%\lib）(不要新建path在原來的path路徑上新加java到bin的路徑就可以了，)
CLASSPATH
.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar;（注前面的點號和分號一定不能丟，還有中間的，后面的分號也不要丟了）
說明：CLASSPATH可以再增加一些第三方的jar文件，方便手工編譯和運行程序。
***********************************************************
在windows中查看環境變量，用set，要查看某一個環境變量的值，可以用set后面跟要查看的值，比如：set classpath ，查看path變量的話，可以直接輸入path就可以了。
設置環境變量，可以用set ，比如 set classpath=“新的路徑”; 這樣就可以了，但只是臨時的，doc窗口關閉的時候，設置的臨時環境變量就不存在了。
下午內網
測試庫同事反應查詢更新數據很慢，有時甚至表都打不開，后來通過服務器【linux】的top命令查看了下，cpu和mem占用正常，但wait高達80%多(下面兩圖顯示的就是問題前后觀察EM對比的截圖,版本是oracle10gR2，EM的效果比oracle11gR2遜色不少哈)：
-------------------------------------->>
---------------------------->>
接著通過sqldevelpdev客戶端查詢有沒有鎖等待之類會話事件，果然有，而且是兩個session持有TX鎖，然后通過下面的sql查詢從oracle和linux級別kill掉了相應session,以為風波就此平靜，結果過了不到一分鐘查詢又出現，只不過這次只有一個session持有TX鎖，于是就去查找對應的sql_txt,找到后發現是個同事寫的存儲過程，定時任務，當時正在運行，讓其確認下是不是任務執行出問題了，結果一查，是程序問題，造成的死循環，它會批量發起會話，kill一個后接著又鎖，循環反復，后來他改了下程序后重新運行，一切恢復通暢.
--查詢死鎖 select sess.sid, sess.serial#, lo.oracle_username, lo.os_user_name, ao.object_name, lo.locked_mode from v$locked_object lo, dba_objects ao,v$session sess where ao.object_id = lo.object_id and lo.session_id = sess.sid; --oracle級別kill session alter system kill session '1627,1'; alter system kill session '1564,64740'; --查詢當前連接會話 select s.value,s.sid,a.username,a.MACHINE from v$sesstat S,v$statname N,v$session A where n.statistic#=s.statistic# and name='session pga memory' and s.sid=a.sid and a.sid=1626 order by s.value; --查詢造成死鎖的sql語句 SELECT a.SID, a.username, s.sql_text FROM v$session a, v$sqltext s WHERE a.sql_address = s.address AND a.sql_hash_value = s.hash_value and a.SID=1626 ORDER BY a.username, a.SID, s.piece; --造成鎖等待的操作內容 begin flt_com.p_line_relation_change(:A0,:B0,:C0,:D0,:E0,:ret_errorcode,:ret_errorname); end; --通過sid查找pid，進而通過系統級別kill select spid, osuser, s.program from v$session s,v$process p where s.paddr=p.addr and s.sid=1605; --服務器級別kill kill -9 spid --------------------------------over game |
用CURL命令行測試
REST API 無疑是低效率的，這里把最近使用的兩款 Chrome 插件總結下
POSTMAN
簡單易用
REST Console
功能強大
使用的話用POSTMAN就夠用了，但是我更喜歡 REST Console ，因為她的功能非常強大和全面，一下子就能讓你搞清楚你在做的事情，你用不到的功能也可以幫助你更加了解 REST, http請求的過程。
下面是兩個的截圖界面
1. Authorization
Basic Auth
Digest Auth
OAuth 1.0
2. REQUEST METHOD
GET, PUT, POST, PATCH, DELETE, LINK, UNLINK, COPY, HEAD, OPTIONS, PURGE
3. Request Headers
Content-Type： form-data x-www-form-urlencoded raw Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryVQuD0ghtRqDehBQH Request Payload: ------WebKitFormBoundaryVQuD0ghtRqDehBQH Content-Disposition: form-data; name="image" dddddd ------WebKitFormBoundaryVQuD0ghtRqDehBQH-- Content-Type:application/x-www-form-urlencoded Form Data: image:bbbbbbb Content-Type:text/plain;charset=UTF-8 Request Payload: image=aaaaaaaaaaaaaa |
這3種方法其中 form-data 是不支持 PUT 方法的。而用REST Console中的 Content-Type:multpart/form-data 是支持 PUT 方法的。不知道是不是bug
4. Response Body
支持3種展示方式， 以及常用的XML和JSON格式。
Pretty
Raw
Preview
JSON/XML
5. Response Header
Connection → Connection Options that are desired for the connection Keep-Alive Content-Length →93 Content-Type →application/json; charset=UTF-8 Date →Fri, 01 Aug 2014 05:41:56 GMT Keep-Alive →timeout=5, max=100 Server →Apache/2.2.9 (Win32) PHP/5.4.30 mod_fcgid/2.3.6 X-Powered-By →PHP/5.4.30 |
2. REST Console 測試工具
1. Options
軟件相關設置，配色，主題，高亮設置等（說明這個東東功能比較全面）
特別說下一個選項就是 Help Lines， 開啟這個選項，對著 REST Console的每一個選項，就很容易搞清楚 http 的 請求和響應中的每一個項目是怎么回事
原創文章，轉載請注明 ： http://www.cnblogs.com/ganiks/
2. Target
設置下面內容：
Target Request URI ： 這個是請求的 ＵＲＩ Request Method : PUT POST ... Request Timeout Accept Accept: (注意區分這個type和后面的content-type) */*(一般都是這個選項) application/atom+xml test/plain application/javascript application/json application/http application/pdf application/rar ... ... Acceptable Language |
3. Body
Content Headers
Content-Type: mime type of the request body(跟PUT和POST方法配合使用)
application/x-www-form-urlencoded
text/plain
multipart/form-data
這3種是在 POSTMAN中支持的3種，但其實有很多很多種，在 REST Console 中的輸入框中輸入幾個字母，會自動匹配庫中的很多選項
Acceptable Encoding： 比如 utf-8（參考 HTTP compression）
Content-MD5: 比如 Q2hlY2sgSW50ZWdyaXR5IQ==
Request Payload
RAW BODY： image=ccccccccc
Request Params: key=>value
Attachements: upload files
Custom Headers
Request Parameters
對照個例子：
Accept:*/* Accept-Encoding:gzip,deflate,sdch Accept-Language:zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4 Authorization:Basic MTAwLXRva2VuOg== Cache-Control:no-cache Connection:keep-alive Content-Length:20 Content-Type:text/plain;charset=UTF-8 Host:192.168.4.126 Origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm User-Agent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36 |
4. Authorization
Basic Auth
Setup oAuth
Refresh oAuth
5. Headers
Headers
Max-Forwards: 10 (限制消息可以穿破 的代理和網關的層數)
Range
From: （發送消息者的郵件地址）
Warning
Pragma
...
Cache （內容太多了）
Common non-standard request headers
6. Response
Response Body: 支持 JSON XML HTML CSS 等高亮格式 { "id": "162", "image": "cccccccc", "link": "dd2", "show_date": "0000-00-00", "state": 1, "show_order": 0 } RAW Body {"id":"162","image":"cccccccc","link":"dd2","show_date":"0000-00-00","state":1,"show_order":0} Response Headers Status Code: 200 Date: Fri, 01 Aug 2014 06:39:00 GMT Server: Apache/2.2.9 (Win32) PHP/5.4.30 mod_fcgid/2.3.6 Connection: Keep-Alive X-Powered-By: PHP/5.4.30 Content-Length: 94 Keep-Alive: timeout=5, max=100 Content-Type: application/json; charset=UTF-8 Response Preview Request Body Request Url: http://192.168.4.126/news/162 Request Method: PUT Status Code: 200 Params: {} Request Headers Content-Type: multipart/form-data Authorization: Basic MTAwLXRva2VuOg== Accept: */* Connection: keep-alive Origin: chrome-extension: //rest-console-id User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36 |
3. http請求的Accept參數
上面提到了一個設置的地方， Accept 和 Content-Type
這兩個參數很重要
前者一般如果不設置默認的是 */*, POSTMAN 和 RESTConsole 工具中默認的是 application/json，因此在不設置 Headers:Accept 參數的情況下返回的按照 json格式；
而普通的瀏覽器中返回的則默認是 application/xml 格式。
后者這個 type 指的是head body 內容的 類型
這就是為什么這兩個參數分別被 REST Console 工具分別放在了 2. Target 3. Body 中。
在 yii 中默認支持的 rest api 格式有 xml 和 JSON， yii 會根據 請求的 head 的 Accept 參數來返回對應格式的數據。
這個參數 在chrome 中可以修改默認值嗎？
Eclipse自帶Junit插件，不用安裝就能在項目中編寫
測試用例，非常方便。
在項目中添加Junit庫
在編寫測試用例之前，需要先引入Junit。對項目根目錄右鍵，選擇Properties，Java Build Path，Libraries，如圖：
Add Library，選擇Junit:
點Next選擇Junit版本，然后Finish就完成了引入。
編寫測試用例
假設有如下類：
package choon.test;
public class Calculate {
public int Add(int x,int y) {
return x + y;
}
}
可以編寫測試用例如下：
package choon.test; import static org.junit.Assert.*; import org.junit.Test; public class Test1 { @Test Calculate calculate = new Calculate(); assertEquals(8, calculate.Add(3, 5)); } } |
對test方法右鍵Run As Junit Test即可運行該測試用例：
如圖，綠色狀態條表示測試通過，如果是紅色，則表示沒有通過。
before和after標簽
被before標記的方法在每個測試用例執行之前執行，被after標記的方法在每個測試用例執行后執行。
假如編寫如下測試用例：
package choon.test; import static org.junit.Assert.*; import org.junit.After; import org.junit.Before; import org.junit.Test; public class Test1 { @Before public void setUp() { System.out.println("---begin test---"); } @Test public void test() { Calculate calculate = new Calculate(); assertEquals(8, calculate.Add(3, 5)); System.out.println("test case"); } @After public void tearDown() { System.out.println("---end test---"); } } |
則會有下面的執行結果：
測試用例的編寫很重要，一個不好的測試用例既起不到測試作用又浪費時間，而一個好的測試用例可以很好的指出代碼中的問題，避免更大的麻煩。
skipfish是
Google的工程師MIchal Zalewski開發的另一款網站安全檢測工具，它完全實現了全自動化操作，所以不需要人工干預，這一點上比RatProxy要好用一些，當然在功能上也強大更多了。
可以從http://code.google.com/p/skipfish/下載它。
安裝Cygwin
與ratproxy一樣，在windows下需要安裝cygwin才能編譯它。
下載Cygwin(http://www.cygwin.com/)，一路默認下一步直到選擇下載站點，考慮到國外的源速度比較慢，所以選擇從ntu.edu.tw(速度還是不錯的)下載；然后下一步Select Packages，找到以下幾個包，并安裝它們：
gcc
make
libidn-devel
zlib-devel
openssl-devel
繼續下一步直至安裝完成。
生成skipfish
1、下載skipfish
2、運行cygwin.bat，并切換到skipfish所在目錄(cd “c:\skipfish”)
3、運行make，等它編譯完成
使用skipfish
在命令行輸入以下命令：
skipfish –o log –W “dictionaries/complete.wl” http://lwme.cnblogs.com
-o參數是輸出目錄，-W是選擇字典，然后就等著它掃描完看報告吧。
使用它的默認參數掃描起來是相當慢的，所以如果有需要的話，可以通過-h參數或者它的在線文檔：http://code.google.com/p/skipfish/wiki/SkipfishDoc去研究它。
在
測試領域，很多的測試從業人員都在討論或者曾經討論過
自動化測試。支持者認為自動化能夠提高測試效率，減少枯燥繁瑣的用例執行。持反對意見人的當心自動化測試的引入成本太大，反而沒有手工測試來的高效。更有人當心自動化測試無法保證軟件的質量，其實能否保證軟件的質量，不是由自動化測試決定，而是取決于你的用例的設計。對于新的事物，在沒有任何實踐的基礎上不能輕易地下結論，因為每個人都有慣性的思維，有時候很難跳出固有的思維去考慮新的事物。
自動化測試本身作為一種測試的手段不存在任何的問題。它的好與壞，本質是由其最終結果來決定的。如果自動化測試帶來收益大于我們投入的成本，那么自動化測試就是成功的。我們要做的就是在自動化測試實施過程中去提高我們的收益，去降低我們的成本。
何為自動化測試？自動化測試是希望能夠通過自動化測試工具或其他手段，按照測試工程師的預定計劃進行自動的測試。目的是減輕手工測試的勞動量，騰出更多的時間和精力去測試重要模塊，同時又保證已有覆蓋自動化測試的模塊的質量，從而達到提高軟件質量的目的。自動化測試的目的在于發現原有模塊引入的新缺陷，保證已有功能的質量。
自動化測試開展的前提
首先部門或者公司要從管理層次上支持你，其次要有專門的測試團隊去建立適合自動化測試的測試流程、測試體系，排除上面的因數之外我總結了自動化測試一些前提條件。
1. 長期性
指的是被測產品（或功能）是否需要一個長期的維護，因為短期的項目是沒有實現自動化測試的必要的，短期的項目很明顯他的投入成本肯定大于其收益。
2. 穩定性
被測產品（或功能）是否有一個相對穩定的產品。如果功能和界面都處于不穩定階段而且經常發生變化的，那腳本和用例的維護成本是非常高的，
所以也是不具備實施自動化的前提條件。
3. 合適測試工具
（工欲善其事，必先利其器）
假如被測產品（或功能）難以通過工具識別其控件的話
假如使用腳本語言難懂難學，而且擴展性差。
4. 人員
你的產品組內是否具備合適人員去開展自動化，是否具備一定合適的人去做自動化腳本開發。自動化測試實施的好與壞，很大程度上取決于該測試工程師，因為要有效實施自動化測試，單一的測試工具的熟練是遠遠不夠的，他需要其它一些輔助的測試手段，所以同時也就需要該測試工程師具備一定的方案解決能力，能夠找到較優的方案來解決現實中碰到的問題。
5. 用例
自動化測試需要好的
測試用例的輔助，這個應該是大家的共識，所以不展開來講。所以這里希望我們的自動化測試工程師需要與
用例設計者進行密切的合作。
整體來說自動化測試能否有效開展，能否有效的實施，不是單一取決于某一個人或者某自動化測試工程師的能力，他是整個團隊合作的結果。
自動化測試成本
這是領導們最關心的問題。因為他們都希望自動化測試帶來的收益要遠大于所投入的成本。不然怎么體現自動化測試價值？如果沒有價值還不如直接手工測試來的干脆。
那么自動化成本有哪些？
1、調研成本
2、腳本開發維護成本
3、自動化用例設計與維護成本
4、資源投入成本
如何有效的降低自動化測試成本呢?
一、 提高調研成本，減少人為因數成本
調研成本省不了，而且要加大投入，如果投入成本不大，選擇的工具和框架都不適合自動化的開展，那么自動化測試肯定以失敗告終。一旦給自動化測試選好了型，后期的轉化成本非常的高，所以一開始就要選擇合適的工具和框架。
當然為了盡量減少調研成本，需要選擇合適人，需要整個團隊的配合。
二、 選擇好的測試工具
選擇好的測試工具，首先要看其所使用的語言是否容易普及，是否功能強大，在自動化測試工具當中，我認為最重要的是GUI對象的識別能力，第三方接口的處理能力。
三、 構建合適的測試框架
有了好的測試工具之后，我們需要一個合適的測試框架，測試框架應該是一個企業級的應用，而不是單一的產品和功能。它至少可以減少重復代碼編寫，包含常用的操作，簡單的配置或自動配置，運行結果自動收集，運行結果簡潔且容易分析。
四、 選擇合適的人，減少研究，實施投入成本
這里我主要講是選擇合適的人，做正確的事上。那么什么樣的人適合做自動化測試呢，首先的一點肯定要有一定的代碼編寫能力。其次我覺得需要一定軟件工程的思想。沒有好的思想，是很難組織起清晰架構的代碼來的。
合適人，做正確的事。這里就充分體現管理者能力了，尤其是測試框架上的研究，往往不是靠單一的人所能夠做到，因為會受到知識體系，思維，能力等相關的束縛。所以我的意見是這些應該是交給一個組織，該組織內集合測試負責人，測試工程師，自動化測試工程師，來依靠團隊的力量來打造合適的測試框架。當然框架的實現上應該交給自動化測試工程師。
那么什么樣的人才是合適的呢
1、需要有一定的手工測試經驗和自動化測試經驗，能知道測試框架為誰而做，需要做什么？
2、能夠將復雜的設計簡單化，能夠充分理解軟件工程的思想，將最簡單的應用提供給測試工程師
五、 減少用例的設計維護成本
如果有好的框架支撐的話，那么用例的設計維護成本完全是可以減少的。
六、 保持腳本整體架構清晰易懂，易維護
七、 合適的加大資源投入成本
我覺得資源投入成本是值得的，資源投入如果能夠減少人力的投入的話。我想是所有管理者都愿意看到的。
自動化測試收益
在如何評價自動化測試收益方面，每個人的角度不通過，得出結果可能也不相同。我想從以下幾個方面來看自動化收益:
1、快速測試
測試人員手工測試多個功能，測試執行的并行度總有個上限。而多個并行執行的自動化測試腳本可以更快速地驗證版本，一次性地報告問題
2、降低手工測試投入成本
將功能測試人員從繁瑣重復的測試中解脫出來，有更多的時間和精力去進行一些探索性的測試。
3、提供了軟件的質量
自動化測試能夠幫助我們減少生產環境中某種特定類型的缺陷。這些缺陷包括環境或者配置相關的缺陷、在主流程上本來正常但因為后期修改影響到的功能、以及容易被忽略的地方等
4、提高了我們對軟件質量的信心
5、自動化測試可以喚起更高的工作熱情
這一方面來自于可以部分地將測試人員從大量重復的測試執行中解放出來，另一方面來自于新技術、新工具帶來的新鮮感
如何有效地提高自動化測試收益？
要有效的開展自動化，一定程度上來說，成本是很難降低的，只有將收益最大化。增加收益的方式有很多種：
一、提高自動化測試迭代次數，提高自動化的使用頻率
要提高自動化的使用頻率，就需要將原有觀念自動化測試收益往往來源于回歸階段進行更正，實際證明自動化同樣可以在日常測試中發揮作用。自動化的使用用例的重復性使用頻率越高，其價值也就越大，其收益也會越大。
二、腳本復用,提高腳本對應功能點的用例覆蓋率
提高該腳本所覆蓋功能點的用例覆蓋，也就是我們不但要考慮減少了自動化腳本開發成本以及降低維護成本，同時也要考慮該腳本帶來的收益已盡量去最大化。
三、提高自動化用例的覆蓋率，最大程度上減少手工重復的勞動
盡可能的提高用例的覆蓋率，并通過自動化來代替我們的手工測試，這樣不但能在保證軟件質量的同時減少手工重復的勞動，
四、建立并維護好測試用例庫，幫助我們節省資源并快速培養測試人員
五、推廣成功案例到其它產品
從入行一開始就決定了不走技術路線，因為游戲之所以是游戲是因為其游戲性而不是技術性，我愛的是游戲，而不是技術。
1：剛入行的時候：找嚴重bug，或者操作步驟很多的bug，很有成就感，因為找到別人找不到的bug
2：后來意識到，基礎的簡單的bug價值不見得比嚴重的難找的bug價值低，開始轉向追求覆蓋、不漏基礎簡單的bug
3：開始關注流程，流程可以減少人為失誤導致的bug，開始關注預防bug，特別是通過流程來預防人為bug
4：認為流程最重要，幾乎所有的bug都可以通過流程來預防和解決
6：開始認識到信息的重要性，認為測試的職責是提供產品信息，而不是自己掌控決定權
7：開始認識到，測試要做的太多，不可能全部做到，要做取舍
8：測試是輔助，不僅僅輔助產品，而且要輔助團隊；團隊重要性高于項目
9：測試不僅僅要提供產品的信息，也要提供人的信息，團隊的信息
推送并不是什么新技術，這種技術在
互聯網時代就已經很流行了。只是隨著進入
移動互聯網時代，推送技術顯得更加重要。因為在智能
手機中，推送從某種程度上，可以取代使用多年的短信，而且與短信相比，還可以向用戶展示更多的信息（如圖像、表格、聲音等）。
推送技術的實現通常會使用服務端向客戶端推送消息的方式。也就是說客戶端通過用戶名、Key等ID注冊到服務端后，在服務端就可以將消息向所有活動的客戶端發送。
實際上，在很多移動
操作系統中，官方都為其提供了推送方案，例如，
Google的云推送、IOS、
Windows Phone7/8也都提供了類似的推送方案。不過這些推送方案的服務器都在國外，有一些推送服務（如Google的云推送）在國內由于某些原因不太穩定，所以國內近幾年涌現出了很多專門為國人打造的推送服務。
本文將從各種流行移動操作系統入手介紹推送技術的各種實現方式。當然，我們的主要目的是討論
Android的推送技術。
一、iOS的推送技術
Apple為IOS提供了很完美的推送方案，其基本原理是Apple提供了自己的推送服務器，叫APNS（Apple Push Notification Service，
蘋果推送通知服務器）。而客戶端設備（IPhone、IPad等）直接與APNS建立長連接。不過向客戶端設備發送的消息并不是由APNS產生的，而是在需要發送消息的用戶自己提供的服務器（稱為Provider）中產生的，然后Provider將消息傳送給APNS，最后由APNS將消息傳送給客戶端設備。也就是說，消息最開始由Provider產生，然后Provider將消息傳送給APNS，最后再由APNS傳送給客戶端設備。消息傳遞的過程如圖1所示。
在發送消息到客戶端設備接收到消息的過程中，始終伴隨這一個令牌的傳送（device token）。要想使用APNS提供消息服務，應用程序需要先向IOS注冊需要提供的一個必要的信息就是與當前設備有關的device token，IOS在接收到devicetoken后，會向APNS查詢這個device token是否在APNS上注冊了（所有的IOS設備在第一次使用時都需要向蘋果服務器注冊一個賬號，否則無法從AppleStore下載應用，當然更無法使用推送服務了），如果已經注冊，APNS會直接向應用程序返回這個devicetoken。應用程序獲得這個devicetoken后，表示APNS已經允許向自己推送消息了，接著還需要將該device token發送給推送服務器（Provider）。到這里應用程序已經成功將自己注冊到APNS中了。現在就可以通過Provider產生要推送的消息，然后Provider會將消息發送給APNS服務器，最后APNS服務器會直接向應用程序發送消息。這個過程比較復雜，不過看一下圖2的描述就會對這一過程更加了解了。每一個流程描述前面的數字表示發送的時間先后順序。
二、Windows Phone的推送技術
微軟為Window Phone提供的推送方案與IOS類似，也需要自己準備推送服務器（可以稱為Cloud Service）。只是表示設備的ID變成了Uri。在Window Phone中有一個Push Client Service（PCS）。所有需要推送服務的應用程序都需要與Push Client Service通信。下面是Window Phone推送的基本步驟，讀者可以與圖3對照來看這一過程。
第1步：應用程序會向Push Client Service請求一個Push Notification URI（①）。
第2步：如果當前Window Phone設備已經在微軟服務器注冊了，Push Client Service會從MPNS（Microsoft Push Notification Service ，微軟推送通知服務）獲取Push Notification URI，并返回給應用程序，表示推送服務可用（②和③）。
第3步：應用程序需要將Push Notification URI發送給自己的推送服務器（Cloud Service）（④）。
第4步：如果需要推送消息，Cloud Service會將消息發送到MPNS，然后MPNS會將消息發送給Push Client Service，最后由Push Client Service將消息傳送給應用程序（⑤、⑥和③）。