By Design- 就是這么設計的，無效的
Bug Duplicate - 這個問題別人已經發現了，重復的Bug
External - 是個外部因素(比如瀏覽器、
操作系統、其他第3方軟件)造成的問題
Fixed - 問題被修理掉了。Tester要盡可能找到這種Bug
Not Repro - 無法復現你這個問題，無效的Bug
Postponed - 是個問題，但是目前不必修理了，推遲到以后再解
Won't Fix - 是個問題，但是不值得修理了，不管它吧
1.對response的處理：（其中Test Request是request的名稱）
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context ) def holder = groovyUtils.getXmlHolder( "Test Request#Response" ) log.info(holder.getNodeValue("http://sessionid")); def sessionid = holder.getNodeValue("http://sessionid") return sessionid <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sam="http://www.soapui.org/sample/"> <soapenv:Header/> <soapenv:Body> <sam:logout> <sessionid>${SessionId#result}</sessionid> </sam:logout> </soapenv:Body> </soapenv:Envelope> |
2.對斷言的處理:
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context ) def holder = groovyUtils.getXmlHolder( "Test Request - logout#Response" ) def sessioninfo = holder.getNodeValue("http://sessioninfo") log.info(sessioninfo) assert sessioninfo.equals("OK") |
1.盡快報告軟件缺陷
軟件缺陷發現的越早，在進度中留下的修復時間就越多。
軟件缺陷發現的越晚，越不可能被修復，特別是小缺陷。
2.有效描述軟件缺陷
有效的表現如下：
a.簡短：只解釋事實和演示、描述軟件缺陷必需的細節。
b.單一：每一個報告只針對一個軟件缺陷，應該分別報告缺陷，不能堆在一起。
c.明顯和通用：用使用者容易看懂的、展示通用性的、簡單易行的步驟描述軟件缺陷，得到的修復機會更大。
d.再現：要想得到重現，軟件缺陷報告必須展示其再現的能力，按照預定步驟可以使軟件達到缺陷再次出現的相同情況。
e.在報告軟件缺陷時不做評價：報告缺陷時，要不帶傾向性、個人觀點和煽動性。
f.補充完善軟件缺陷報告。
一、簡介
現在的服務器端程序很多都是基于
Java開發，針對于Java開發的Socket程序，這樣的服務器端上線后出現問題需要手動重啟，萬一大半夜的掛了，還是特別麻煩的。
大多數的解決方法是使用其他進程來守護服務器程序，如果服務器程序掛了，通過守護進程來啟動服務器程序。
萬一守護進程掛了呢？使用雙守護來提高穩定性，守護A負責監控服務器程序與守護B，守護B負責監控守護A，任何一方出現問題，都能快速的啟動程序，提高服務器程序的穩定性。
Java的運行環境不同于C等語言開發的程序，Java程序跑在JVM上面。不同于C語言可以直接創建進程，Java創建一個進程等同于使用java -jar xxx.jar啟動一個程序。
Java啟動程序并沒有C#類似的單實例限制，你可以啟動多個，但是你不能啟動多個，不能讓多個守護A去守護服務器程序，萬一啟動了多個服務器程序怎么辦？
二、技術講解
這里的技術講解比較粗略，具體請
百度一下，這里只講解作用。
1、jps命令。
JDK自帶的命令工具，使用jps -l可以列出正在運行的Java程序，顯示Java程序的pid與Name。只對Java程序有效，其實查看的是運行的JVM
2、java.nio.channels.FileLock類的使用
這個是Java new IO中的類，使用他可以維持在讀取文件的給文件加上鎖，判斷文件時候有鎖可以判斷該文件是否被其他的程序使用
3、ProcessBuilder與Process
這兩個原理差不多，都是調用系統的命令運行，然后返回信息。但是硬編碼會導致你的Java程序失去可移植性，可以將命令獨立到配置文件中。
三、設計原理
Server：服務器程序
A：守護進程A
B：守護進程B
A.lock:守護進程A的文件鎖
B.lock:守護進程B的文件鎖
----------------------------------------------------------------------------------
Step 1：首先不考慮Server，只考慮A與B之間的守護
1.A判斷B是否存活，沒有就啟動B
2.B判斷A是否存活，沒有就啟動A
3.在運行過程中A與B互相去拿對方的文件鎖，如果拿到了，證明對面掛了，則啟動對方。
4.A啟動的時候，獲取A.lock文件的鎖，如果拿到了證明沒有A啟動，則A運行;如果沒有拿到鎖，證明A已經啟動了，或者是B判斷的時候拿到了鎖，如果是A已經啟動了，不需要再次啟動A，如果是B判斷的時候拿到了鎖，沒關緊 要，反正B會再次啟動A。
5.B啟動的時候原理與A一致。
6.運行中如果A掛了，B判斷到A已經掛了，則啟動A。B同理。
Step 2：加入Server
1.A用于守護B和Server，B用于守護A。
2.原理與Step 1 一致，只是A多個一個守護Serer的任務。
3.當A運行的時候，使用進程pid檢測到Server已經掛了，就啟動Server
4.如果Server與A都掛了，B會啟動A，然后A啟動Server
5.如果Server與B掛了，A啟動Server與B
6.如果A與B都掛了，守護結束
Step 3：使用Shutdown結束守護，不然結束Server后會自動啟動
四、實現
1、GuardA的實現
1 public class GuardA { 2 // GuardA用于維持自己的鎖 3 private File fileGuardA; 4 private FileOutputStream fileOutputStreamGuardA; 5 private FileChannel fileChannelGuardA; 6 private FileLock fileLockGuardA; 7 // GuardB用于檢測B的鎖 8 private File fileGuardB; 9 private FileOutputStream fileOutputStreamGuardB; 10 private FileChannel fileChannelGuardB; 11 private FileLock fileLockGuardB; 12 13 public GuardA() throws Exception { 14 fileGuardA = new File(Configure.GUARD_A_LOCK); 15 if (!fileGuardA.exists()) { 16 fileGuardA.createNewFile(); 17 } 18 //獲取文件鎖，拿不到證明GuardA已啟動則退出 19 fileOutputStreamGuardA = new FileOutputStream(fileGuardA); 20 fileChannelGuardA = fileOutputStreamGuardA.getChannel(); 21 fileLockGuardA = fileChannelGuardA.tryLock(); 22 if (fileLockGuardA == null) { 23 System.exit(0); 24 } 25 26 fileGuardB = new File(Configure.GUARD_B_LOCK); 27 if (!fileGuardB.exists()) { 28 fileGuardB.createNewFile(); 29 } 30 fileOutputStreamGuardB = new FileOutputStream(fileGuardB); 31 fileChannelGuardB = fileOutputStreamGuardB.getChannel(); 32 } 33 34 /** 35 * 檢測B是否存在 36 * 37 * @return true B已經存在 38 */ 39 public boolean checkGuardB() { 40 try { 41 fileLockGuardB = fileChannelGuardB.tryLock(); 42 if (fileLockGuardB == null) { 43 return true; 44 } else { 45 fileLockGuardB.release(); 46 return false; 47 } 48 } catch (IOException e) { 49 System.exit(0); 50 // never touch 51 return true; 52 } 53 } 54 } |
2、GuardServer的實現
1 public class GuardServer { 2 private String servername; 3 4 public GuardServer(String servername) { 5 this.servername = servername; 6 } 7 8 public void startServer(String cmd) throws Exception { 9 System.out.println("Start Server : " + cmd); 10 //將命令分開 11 // String[] cmds = cmd.split(" "); 12 // ProcessBuilder builder = new ProcessBuilder(cmds); 13 14 // 15 ProcessBuilder builder=new ProcessBuilder(new String[]{"/bin/sh","-c",cmd}); 16 //將服務器程序的輸出定位到/dev/tty 17 builder.redirectOutput(new File("/dev/tty")); 18 builder.redirectError(new File("/dev/tty")); 19 builder.start(); // throws IOException 20 Thread.sleep(10000); 21 } 22 23 /** 24 * 檢測服務是否存在 25 * 26 * @return 返回配置的java程序的pid 27 * @return pid >0 返回的是 pid <=0 代表指定java程序未運行 28 * **/ 29 public int checkServer() throws Exception { 30 int pid = -1; 31 Process process = null; 32 BufferedReader reader = null; 33 process = Runtime.getRuntime().exec("jps -l"); 34 reader = new BufferedReader(new InputStreamReader(process.getInputStream())); 35 String line; 36 while ((line = reader.readLine()) != null) { 37 String[] strings = line.split("\\s{1,}"); 38 if (strings.length < 2) 39 continue; 40 if (strings[1].contains(servername)) { 41 pid = Integer.parseInt(strings[0]); 42 break; 43 } 44 } 45 reader.close(); 46 process.destroy(); 47 return pid; 48 } 49 } |
3、GuardAMain實現
1 public class GuardAMain { 2 public static void main(String[] args) throws Exception { 3 GuardA guardA = new GuardA(); 4 Configure configure = new Configure(); 5 GuardServer server = new GuardServer(configure.getServername()); 6 while (true) { 7 // 如果GuardB未運行 運行GuardB 8 if (!guardA.checkGuardB()) { 9 System.out.println("Start GuardB....."); 10 Runtime.getRuntime().exec(configure.getStartguardb()); 11 } 12 // 檢測服務器存活 13 if (server.checkServer() <= 0) { 14 boolean isServerDown = true; 15 // trip check 16 for (int i = 0; i < 3; i++) { 17 // 如果服務是存活著 18 if (server.checkServer() > 0) { 19 isServerDown = false; 20 break; 21 } 22 } 23 if (isServerDown) 24 server.startServer(configure.getStartserver()); 25 } 26 Thread.sleep(configure.getInterval()); 27 } 28 } 29 } |
4、Shutdown實現
1 public class ShutDown { 2 public static void main(String[] args) throws Exception { 3 Configure configure = new Configure(); 4 System.out.println("Shutdown Guards.."); 5 for (int i = 0; i < 3; i++) { 6 Process p = Runtime.getRuntime().exec("jps -l"); 7 BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream())); 8 String line; 9 while ((line = reader.readLine()) != null) { 10 if (line.toLowerCase().contains("Guard".toLowerCase())) { 11 String[] strings = line.split("\\s{1,}"); 12 int pid = Integer.parseInt(strings[0]); 13 Runtime.getRuntime().exec(configure.getKillcmd() + " " + pid); 14 } 15 } 16 p.waitFor(); 17 reader.close(); 18 p.destroy(); 19 Thread.sleep(2000); 20 } 21 System.out.println("Guards is shutdown"); 22 } 23 } |
5、GuardB與GuardA類似
五、下載與使用
項目文件夾：guard_demo
下載地址：http://pan.baidu.com/s/1bn1Y6BX
背景：項目上一SharePoint網站分為SharePoint前端與
數據庫，前端放在實體機上，數據庫放在VM9虛擬機中。
環境：
Windows Server 2008 r2+sp1, SharePoint Server 2013 Enterprise,
SQL Server 2008 r2+sp1, VM9虛擬機
存在的問題：虛擬機中實際上只有70G大小的文件，但是虛擬機在磁盤上的空間有700多G，嚴重占用資源，在網上嘗試用vmware-vdiskmanager.exe –k命令、VMwareToolboxCmd.exe disk shrinkonly命令基本上沒有作用（其中第二條命令壓縮一個幾十G的虛擬機差不多要十幾個小時，結果才壓縮了幾G）
解決思路：新建一個虛擬機，安裝SQL Server，備份SiteCollection，還原SiteCollection到新數據庫，刪除原有虛擬機。
以下是我所在項目的遷移過程：
1、備份原網站上的
web.config，CKFinder/CKEditer文件
2、備份SiteCollection，命令如下：
backup-spsite -identity http://spserver -Path c: \a.bak -force
3、新建虛擬機，并打上補丁，設置虛擬機允許域賬戶訪問，設置IP
4、用域賬戶通過IP登錄新虛擬機，安裝SQL Server 2008 r2，并打上補丁
5、運行SharePoint配置向導，關閉原場連接，新建場連接到新數據庫（一般第一次會失敗，失敗后再運行一次即可）
6、還原SiteCollection，命令如下：
restore-spsite -identity http://spserver -Path c:\a.bak -databaseserver spserver -databaseName WSS_Content -force
7、將代碼中的dll放到IIS的bin文件夾下面
8、重新部署wsp包，命令如下：
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\BIN\stsadm.exe" -o deletesolution -name Jurassic.NRC.wsp -override
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\BIN\stsadm.exe" -o addsolution -filename C:\Users\Administrator\Desktop\Jurassic.NRC.wsp
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\BIN\stsadm.exe" -o deploysolution -name Jurassic.NRC.wsp -url http://sp2014 -allowgacdeployment -immediate –force
9、設置網站最大上傳文件大小
10、設置列表閥值
11、重新配置Office Web Apps
以上步驟是我遷移我所在項目的全過程，歡迎相互交流！
1、查找當前目錄下所有以.tar結尾的文件然后
移動到指定目錄：
find . -name “*.tar” -exec mv {} ./backup/ ;
查找當前目錄30天以前大于100M的LOG文件并刪除。
find . -name "*.log" –mtime +30 –type f –size +100M |xargs rm –rf {} ;
寫一個腳本查找最后創建時間是3天前，后綴是*.log的文件并刪除。
find . -mtime +3 -name "*.log" |xargs rm -rf {} ;
寫一個腳本將某目錄下大于100k的文件移動至/tmp下。
find . -size +100k -exec mv {} /tmp ;
2、批量解壓當前目錄下以.zip結尾的所有文件到指定目錄：
for i in `find . –name “*.zip” –type f `
do
unzip –d $i /data/www/img/
done
如何去掉行首的.字符: sed -i 's/^.//g' test.txt
在行首添加一個a字符: sed 's/^/a/g' test.txt
在行尾添加一個a字符: sed 's/$/a/' tets.txt
在特定行后添加一個c字符: sed '/wuguangke/ac' test.txt
在行前加入一個c字符: sed '/wuguangke/ic' test.txt
4、如何判斷某個目錄是否存在，不存在則新建，存在則打印信息。
if
[ ! –d /data/backup/ ];then
Mkdir –p /data/backup/
else
echo "The Directory already exists,please exit"
fi
注解：if …;then …else ..fi：為if條件語句,!嘆號表示反義“不存在“，-d代表目錄。
5、監控
linux磁盤根分區，如果根分區空間大于等于90%，發送郵件給Linux SA
(1)、打印根分區大小
df -h |sed -n '//$/p'|awk '{print $5}'|awk –F ”%” '{print $1}'
(2)、if條件判斷該大小是否大于90，如果大于90則發送郵件報警
while sleep 5m
do
for i in `df -h |sed -n '//$/p' |awk '{print $5}' |sed 's/%//g'`
do
echo $i
if [ $i -ge 90 ];then
echo “More than 90% Linux of disk space ,Please Linux SA Check Linux Disk !” |mail -s “Warn Linux / Parts is $i%”
wugk@map.com
fi
done
done
6、統計Nginx訪問日志，訪問量排在前20 的 ip地址：
cat access.log |awk '{print $1}'|sort|uniq -c |sort -nr |head -20
7、sed另外一個用法找到當前行，然后在修改該行后面的參數：
sed -i '/SELINUX/s/enforcing/disabled/' /etc/selinux/config
Sed冒號方式 sed -i ‘s:/tmp:/tmp/abc/:g’test.txt意思是將/tmp改成/tmp/abc/。
11、打印出一個文件里面最大和最小值：
cat a.txt |sort -nr|awk ‘{}END{print} NR==1′
cat a.txt |sort -nr |awk ‘END{print} NR==1′
這個才是真正的打印最大最小值：sed ‘s/ / /g’ a.txt |sort -nr|sed -n ’1p;$p’
13、修改文本中以jk結尾的替換成yz：
sed -e ‘s/jk$/yz/g’ b.txt
14、網絡抓包：tcpdump
tcpdump -nn host 192.168.56.7 and port 80 抓取56.7通過80請求的數據包。
tcpdump -nn host 192.168.56.7 or ! host 192.168.0.22 and port 80 排除0.22 80端口！
16、顯示最常用的20條命令：
cat .bash_history |grep -v ^# |awk ‘{print $1}’ |sort |uniq -c |sort -nr |head -20
19、寫一個防火墻配置腳本，只允許遠程主機訪問本機的80端口。
iptables -F
iptables -X
iptables -A INPUT -p tcp --dport 80 -j accept
iptables -A INPUT -p tcp -j REJECT
或者
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
20、寫一個腳本進行nginx日志統計，得到訪問ip最多的前10個(nginx日志路徑：/home/logs/nginx/default/access.log)。
cd /home/logs.nginx/default
sort -m -k 4 -o access.logok access.1 access.2 access.3 .....
cat access.logok |awk '{print $1}'|sort -n|uniq -c|sort -nr |head -10
21.寫出下列命令的含義
（1）MaxKeepAliveRequests 100 連接的最大請求數
（2）Options FollowSymLinks 允許192.168.1.1可以列目錄
Order Deny Allow
Deny from all
Allow from 192.168.1.1
22.替換文件中的目錄
sed 's:/user/local:/tmp:g' test.txt
或者
sed -i 's//usr/local//tmp/g' test.txt
最近
工作上的活就是研究一下如何為一個歷史代碼工程添加
單元測試，已經做完了，就想拋磚引玉和大家分享一下結果，聽聽大家的反饋。
該工程目前還是VS2010下的C#代碼，雖然大量使用了繼承，封裝和多態，但對接口的應用非常少，所以基本上沒辦法用常見的Mock框架（如Moq， Rhino Mock，等）來寫單元測試。
考慮下來，解決方案無非兩種：一是重構現有代碼，通過接口（interface）來實現依賴注入（Dependency Injection, DI）;二是尋找無需通過接口直接支持虛擬實體類的Mock框架，用來攔截對依賴對象的訪問，返回預定的結果。采用方案一的話，優化了代碼架構，從長遠來說更好一些，但是工作量較大，還需要做大量的測試以保證不會改變現有代碼功能。采用方案二的話，則不需要對現有代碼做任何改動，只需要直接創建測試代碼就好了。因此方案二還是很有吸引力的，我就按這個方向做了一些研究。
我發現市面上暫時還沒有開源的Mock框架（.NET單元測試相關）支持虛擬實體類，而收費的我也只找到Microsoft Fakes, TypeMock Isolator和Telerik JustMock這三個。三者雖然用法上有些差異，但是主要功能比較接近，差別主要體現在以下幾個方面：
1.從價格上來看：
Microsoft Fakes，沒有免費版，只有在VS2012/VS2013的Premium和Ultimate版中才能用，而我們的開發環境用的主要是Professional版的，升級到相應版本的話成本很高（VS2013的話
Windows Store差價$1770，MSDN Subscription差價$4920）
Telerik JustMock滿足需求的版本價格是每個開發者$399，包含一年免費升級＋支持，（參見Buy JustMock）
TypeMock Isolator滿足需求的版本價格是$799每個license，$150每年升級＋支持，（參見Isolator Pricing)
由于Fakes價格太高，而且還需要升級現有代碼，我們直接就不考慮了。當然如果已經在用相應版本的話，還是可以考慮的，畢竟
微軟自己的東西還是用起來最方便的。
2.從功能上看，根據我們的一個測試用例分別用TypeMock和JustMock試寫了一下，發現JustMock更強大一些。 我們的這個測試用例是要測某個時間值由于特殊原因不包含年份，因此從客戶端傳到位于不同時區的服務端時，在跨年時會被解析到錯誤的年份。比如：客戶端位于GMT+8在2014/01/01 07:00:00時傳了01/01 07:00:00過來，而服務端位于GMT，當時是2013/12/31 23:00:00，這個時間就會被解析成2013/01/01 07:00:00。解析調用的是DateTime.ParseExact()方法。TypeMock對MSCorLib中類的虛擬只提供了有限的支持，不支持這個方法的虛擬。而JustMock在這方面則做得好一些，能夠支持該方法。
所以，我的最終結論是要么重構代碼，使用接口來實現依賴注入，那么基本上各種Mock框架都能用；要么就買JustMock，不用動現有代碼，直接加單元測試就好了。
內存泄漏的問題，在
百度是遇到最多的，阿里相對少點。與內存泄漏斗爭了很久，我總結下常用的一些有效
測試方法吧。
1、valgrind，這是非常好用的工具，雖然參數很多，輸出結果較多，但是只要認真看下，就很容易發現問題，報告是很詳細的，不要被嚇倒。valgrind檢測的內存泄漏是非常準的，可以精確定位到代碼行甚至是變量。valgrind基于valginrd core框架，這是個非常有強大的框架，他的作用不僅僅在于檢測內存泄漏的，強烈建議測試新手通讀下全部的文檔。valgind自己也會有誤報和漏報，所有具體場景需要具體分析。報告中一旦出現definitely lost的標記，就表示一定會有內存泄漏，泄漏的字節數也會報告出來，可以根據泄漏的內存大小和請求次數計算出到底是那個變量沒有釋放。
2、利用pmap+gdb，pmap可以列出特定進程的所有內存分配的地址和大小，通過gdb就可以直接看這些地址屬于什么變量，通過統計這些內存地址的大小，就可以很容易的發現問題。利用自動化的gdb調試工具也可以很方便的定位。
3、其他的還包括memprof、商業工具Purify
IBM出品，官方宣傳說的不錯，但是這種不開放的技術，在業界得不到認可，國內大公司一般那都不用，只有人傻錢多的公司在用。
4、利用一些trace工具，比如ptrace，strace之類的工具，這些trace工具會追蹤特定的api，只需要統計malloc和free的調用次數就可以簡單的發現是否有泄漏，但是無法定位代碼行。另外還有一個更高深的工具，SystemTap，這個在國內應用還不多，但是非常厲害，可以方便hook程序的關鍵邏輯并插入探針。從而可以方便的檢測內存泄漏。Systemtap目前還不通用，而且安裝復雜，暫時不推薦使用，可以關注下，過幾年可能會大規模應用。
valgrind是首選，因為他的設計就是為了解決所有的c++的內存問題。一些valgrind不能簡單發現的，我一般會review代碼，然后通過gdb自動調試技術來發現問題。通過valgrind+gdb，可以解決所有的內存泄漏。
另外，內存的泄漏也并不完全是沒有及時的free，還有可能是其他的原因，比如設計問題等。需要靠一定的開發經驗判斷。
要盡量把靜態測試和動態測試盡早的加入到持續集成中，以盡早的發現問題，不然一旦代碼復雜，追查的成本就會增大。
Web 應用的基礎概念
在討論 Web 應用安全之前，先簡單介紹一下 Web 應用基礎概念，這樣便于理解為什么 Web 應用是脆弱的，容易受到攻擊。
1、 什么是 Web 應用
Web 應用是由動態腳本、編譯過的代碼等組合而成。它通常架設在 Web 服務器上，用戶在 Web 瀏覽器上發送請求，這些請求使用 HTTP 協議，經過因特網和企業的 Web 應用交互，由 Web 應用和企業后臺的
數據庫及其他動態內容通信。
2、 Web 應用的架構
盡管不同的企業會有不同的 Web 環境搭建方式，一個典型的 Web 應用通常是標準的三層架構模型，如圖 1 所示。
圖 1: Web 應用通常是標準的三層架構模型
Web
在這種最常見的模型中，客戶端是第一層；使用動態 Web 內容技術的部分屬于中間層；數據庫是第三層。用戶通過 Web 瀏覽器發送請求（request）給中間層，由中間層將用戶的請求轉換為對后臺數據的查詢或是更新，并將最終的結果在瀏覽器上展示給用戶。
Web 應用安全全景
當討論起 Web 應用安全，我們經常會聽到這樣的回答：
“我們使用了防火墻”、“我們使用了網絡脆弱掃描工具”、“我們使用了 SSL 技術”、“我們每個季度都會進行滲透
測試”……所以，“我們的應用是安全的”。現實真是如此嗎？讓我們一起來看一下 Web 應用安全的全景圖。
圖 2: 信息安全全景
信息安全全景
在企業 Web 應用的各個層面，都會使用不同的技術來確保安全性。為了保護客戶端機器的安全，用戶會安裝防病毒軟件；為了保證用戶數據傳輸到企業 Web 服務器的傳輸安全，通信層通常會使用 SSL（安全套接層）技術加密數據；企業會使用防火墻和 IDS（入侵診斷系統）/IPS（入侵防御系統）來保證僅允許特定的訪問，不必要暴露的端口和非法的訪問，在這里都會被阻止；即使有防火墻，企業依然會使用身份認證機制授權用戶訪問 Web 應用。
但是，即便有防病毒保護、防火墻和 IDS/IPS，企業仍然不得不允許一部分的通訊經過防火墻，畢竟 Web 應用的目的是為用戶提供服務，保護措施可以關閉不必要暴露的端口，但是 Web 應用必須的 80 和 443 端口，是一定要開放的。可以順利通過的這部分通訊，可能是善意的，也可能是惡意的，很難辨別。這里需要注意的是，Web 應用是由軟件構成的，那么，它一定會包含缺陷（bugs），這些 bug 就可以被惡意的用戶利用，他們通過執行各種惡意的操作，或者偷竊、或者操控、或者破壞 Web 應用中的重要信息。
因此可以看出，企業的回答，并不能真正保證企業的應用安全：
網絡脆弱性掃描工具，由于它僅僅用來分析網絡層面的漏洞，不了解應用本身，所以不能徹底提高 Web 應用安全性；
防火墻可以阻止對重要端口的訪問，但是 80 和 443 端口始終要開放，我們無法判斷這兩個端口中通訊數據是善意的訪問還是惡意的攻擊；
SSL 可以加密數據，但是它僅僅保護了在傳輸過程中數據的安全性，并沒有保護 Web 應用本身；
每個季度的滲透測試，無法滿足處于不斷變更之中的應用。
只要訪問可以順利通過企業的防火墻，Web 應用就毫無保留的呈現在用戶面前。只有加強 Web 應用自身的安全，才是真正的 Web 應用安全解決之道。
常見的 Web 應用攻擊
兩個重要的國際應用安全組織
在討論常見的 Web 應用攻擊之前，我們需要先了解兩個組織：WASC 和 OWASP。這兩個組織在呼吁企業加強應用安全意識和指導企業開發安全的 Web 應用方面，起到了重要的作用。
Web Application Security Consortium（WASC），是一個由安全專家、行業顧問和諸多組織的代表組成的國際團體。他們負責為 WWW 制定被廣為接受的應用安全標準。WASC 組織的關鍵項目之一是“Web 安全威脅分類”，也就是將 Web 應用所受到的威脅、攻擊進行說明并歸納成具有共同特征的分類。該項目的目的是針對 Web 應用的安全隱患，制定和推廣行業標準術語。WASC 將 Web 應用安全威脅分為如下六類：
Authentication（驗證）
用來確認某用戶、服務或是應用身份的攻擊手段。
Authorization（授權）
用來決定是否某用戶、服務或是應用具有執行請求動作必要權限的攻擊手段。
Client-Side Attacks（客戶側攻擊）
用來擾亂或是探測 Web 站點用戶的攻擊手段。
Command Execution（命令執行）
在 Web 站點上執行遠程命令的攻擊手段。
Information Disclosure（信息暴露）
用來獲取 Web 站點具體系統信息的攻擊手段。
Logical Attacks（邏輯性攻擊）
用來擾亂或是探測 Web 應用邏輯流程的攻擊手段。
可以通過如下的網址訪問該組織網站，獲得更多詳細信息：[url]www.webappsec.org[/url]。也可以通過參考資料中鏈接，具體了解“Web 安全威脅分類”項目。
Open Web Application Security Project（OWASP），該組織致力于發現和解決不安全 Web 應用的根本原因。它們最重要的項目之一是“Web 應用的十大安全隱患”，總結了目前 Web 應用最常受到的十種攻擊手段，并且按照攻擊發生的概率進行了排序。這個項目的目的是統一業界最關鍵的 Web 應用安全隱患，并且加強企業對 Web 應用安全的意識。
圖 3: Web 應用十大安全隱患
Web
可以通過如下的網址訪問該組織。
IBM Rational，是上述兩個組織的成員。
常見的 Web 應用攻擊示例
在 OWASP 組織列舉的十大 Web 應用安全隱患中，有兩個概率最高的攻擊手段，它們分別是“跨站點腳本攻擊”（Cross-Site Scripting）和“注入缺陷”（Injection Flaws）。下面將通過舉例來說明這兩種攻擊是如何實施的。
1、 跨站點腳本攻擊
首先來看一下跨站點腳本的利用過程，如圖 4。
圖 4: 跨站點腳本攻擊的過程
跨站點腳本攻擊的過程
在上圖中，惡意攻擊者（這里使用 Evil.org 表示）通過 E-mail 或 HTTP 將某銀行的網址鏈接發給用戶（銀行用 bank.com 表示），該鏈接中附加了惡意的腳本（上圖步驟一）；用戶訪問發來的鏈接，進入銀行網站，同時，嵌在鏈接中的腳本被用戶的瀏覽器執行（上圖步驟二、三）；用戶在銀行網站的所有操作，包括用戶的 cookie 和 session 信息，都被腳本收集到，并且在用戶毫不知情的情況下發送給惡意攻擊者（上圖步驟四）；惡意攻擊者使用偷來的 session 信息，偽裝成該用戶，進入銀行網站，進行非法活動（上圖步驟五）。
因此，只要 Web 應用中，有可被惡意攻擊者利用執行腳本的地方，都存在極大的安全隱患。黑客們如果可以讓用戶執行他們提供的腳本，就可以從用戶正在瀏覽的域中偷到他的個人信息、可以完全修改用戶看到的頁面內容、跟蹤用戶在瀏覽器中的每一個動作，甚至利用用戶瀏覽器的缺陷完全控制用戶的機器。
目前，跨站點腳本攻擊是最大的安全風險。
2、 注入缺陷
目前的 Web 應用中，絕大多數都會向用戶提供一個接口，用來進行權限驗證、搜索、查詢信息等功能。比如一個在線銀行應用，首先會有對注冊客戶進行身份驗證的登錄界面，在正確登錄后，會提供更多交互功能，如根據客戶的銀行卡號信息，查詢客戶的最近交易、轉賬細節等。這些都是注入缺陷的最佳利用場景。所謂注入缺陷，就是在上述場景中，用戶輸入的數據被當做命令和查詢的一部分，送到后端的解釋器中解釋執行。如果用戶的輸入是正常合法的，Web 應用自然會返回正常合理的結果，但是，如果惡意攻擊者，利用輸入數據可被后臺執行的原理，偷梁換柱，使用非法的輸入，脆弱的 Web 應用會怎樣呢？
下面我們舉一個例子來說明注入缺陷是如何進行的。在一個交易網站中，用戶必須輸入產品 ID 號才可以查看該產品的詳細信息。為了實現這個需求，通常會用 SQL 語句查詢數據庫來實現。開發人員在編寫應用程序時，可能會使用如下的 SQL 語句來實現上述目的（這里僅為示例）：
1) Select * from products where product_id = ` + 用戶輸入的 ID + `
這里的 products 是數據庫中用來存放產品信息的表，＋號表示 SQL 語句需要和用戶輸入的真實 ID 進行拼接。如果用戶輸入 325，則該語句在執行時變為：
Select * from products where product_id = ` 325 `
數據庫會將 ID 為 325 的產品信息返回給用戶。
2) 在界面上，需要用戶輸入產品 ID 的地方，黑客會輸入如下數據：
` or `1`= `1
可以看到，黑客并沒有輸入正常合法的產品編號。
3) 通過黑客的非法輸入，需要執行的 SQL 語句變為：
Select * from products where product_id = ` ` or `1`=`1`
可以看出，SQL 語句的意義就完全改變了，當產品 ID 為空或者 1＝1 時，返回產品所有信息，而 1＝1 是永遠成立的條件，因此，黑客并沒有輸入任何產品編號，就可以返回數據庫中所有產品的詳細信息。
通過這個例子，我們可以看出，注入缺陷是風險非常高的安全漏洞，一旦 Web 應用中給用戶提供了需要其輸入數據的接口，就有可能遭到攻擊，將后臺的數據完全暴露在用戶的面前。
上述說明的“跨站點腳本攻擊”和“注入缺陷攻擊”，是目前 Web 應用中比例最高的兩種攻擊手段，按照 OWASP 的項目排序，還有如下八種風險性較高的攻擊方法：
Malicious File Execution（惡意文件執行）；
Insecure Direct Object Reference（不安全的直接對象引用）；
Cross-Site Request Forgery（跨站點的請求偽造）；
Information Leakage and Improper Error Handling（信息泄漏和不正確的錯誤處理）；
Broken Authentication & Session Management（損壞的認證和 Session 管理）；
Insecure Cryptographic Storage（不安全的密碼存儲）；
Insecure Communications（不安全的通信）；
Failure to Restrict URL Access（未能限制 URL 訪問）
在這里，我們就不過多的討論這幾種安全隱患，可以使用 3.1 節中提供的鏈接得到更多的描述信息。
構筑安全的 Web 應用
功能和性能，往往是我們衡量應用是否滿足需求的指標，但是，對于載體為 Internet 的特殊應用－Web 應用而言，安全性也是必要的考量標準，皮之不存，毛將焉附？如果失去了安全性，即使功能再完備、性能再可靠的 Web 應用，一旦遭到黑客的攻擊和破壞，一切都失去了意義。因此企業，尤其是提供 Web 應用的企業，一定要加強對應用安全的重視程度。
針對目前 Web 應用安全性不高的現狀，IBM Rational 提出了構筑安全 Web 應用的解決方案。
加強全員應用安全性意識
一個根本、底層的戰略手段就是加強企業全員的應用安全意識。正如前面所闡述過的，對于應用而言，無論是開發人員、測試人員、質量管理人員還是項目經理、企業高層，都會對其功能和性能做更多的關注，這也是由于早期應用多為 C/S 架構的應用，安全問題并不突出。但是在當今的環境，就不得不將安全作為應用質量的基礎。
圖 5 中功能、易用性、可靠性、性能、可支持性，是由 Rational Unified Process（RUP）定義的 FURPS 質量模型，它告訴我們應用的質量需要從這幾個方面著手衡量，對于 Web 應用，就必須將安全性作為質量模型的基礎條件。
圖 5: 適于 Web 應用的質量模型
在Eclipse中配置Junit的方法有兩種方式：
第一種方法：
1、下載junit的jar包，目前它的版本是junit3.8.1，可以從www.junit.org上下載。
2、在要使用Junit的project名上，點擊properties--java build path-libraries, 點擊Add External JARs,把Junit包點上就行了。如圖所示,點擊Add External JARs，選擇相應的Junit包
第二種方法：
１、在要使用Junit的project名上，點擊properties--java build path-libraries, 點擊Add library,選擇JunitT即可。如圖1所示，在圖1中點擊Add library，在彈出的對話框中選擇Jnuit，如圖3所示，接下來選擇junit版本即可。
（1）Eclpise中新建工程junittest
參考附件中的junittest-1.rar。其中定義了需要
單元測試的類：com.cvicse.test.junit. JunitTest
簡單的步驟：
1、建一個project工程，工程名字為junittest。
２、建立一個包，名字為com.cvicse.test.junit。
３、建立一個類JunitTest，其內容如下
package com.cvicse.test.junit; public class JunitTest { public boolean method1(int comp){ //do something if(comp>5){ //do something return false; }else{ //do something return true; } }
（2）建立類junittest的junit類
選擇要單元測試的類junittest，點擊右健，選擇”new”---“other”---“
java”—“junit”—“junit
test case”
1、選擇第一個對話框中的屬性，一般需要選擇setup復選框和teardown
Setup函數用于測試的初始化，而teardown用于測試的銷毀,前者相當于c++中的構造函數和析構函數。
2、進入第二個對話框，選擇需要測試的類方法，一般只是選擇被測試類本身的方法，
上圖中的junittest中的method1就是被測試類的實現方法。
3、點擊finish，自動生成該類的測試類JunitTestTest
4、生成的代碼如下所示。
package com.cvicse.test.junit; import junit.framework.TestCase; public class JunitTestTest extends TestCase { protected void setUp() throws Exception { } protected void tearDown() throws Exception { } public void testMethod1() { fail("Not yet implemented" ); } }
第二種工程（建立與源碼分離的工程）
建立與源碼工程分離的test工程（測試代碼與源碼分離）
一般情況，按照“建立類的junit類”的方法建立的測試單元，一般與源碼工程在同樣的包中，混雜在一起，需要將其分離。
分離步驟：
1、 在工程名下新建立“source folder”，命名為test，拷貝/src/*.*到/test下，并刪除非testcase類
2、 在源碼/src中建立testcase類，然后
移動到/test對應的目錄下，
3、 執行如果出現錯誤：”test type does not exist”，則需要將/test目錄添加工程的source屬性中：工程右健—“properties”—“java build path”—“source”—“add folder”—選擇/test
4、 如果需要的配置文件在web-inf下，則需要拷貝到src目錄下。
建立測試后的工程
建立單元測試的工程如：junitTest-2.rar
覆蓋率測試和報告
目前覆蓋率測試一般用jcoverage或者cobertura工具。
使用cobertura測試的配置文件為：cobertura/build.xml，為ant腳本。
工程參考：junitTest-3.rar；