web測試技術經典案例(3)

　　測試狀態之間最不常用的分支

　　測試所有錯誤狀態及其返回值

　　測試隨機狀態轉換

　　2.2.4 競爭條件測試技術

　　競爭條件典型情形參考如下:

　　兩個不同的程序同時保存或打開同一個文檔

　　共享同一臺打印機,通信端口或者其他外圍設備

　　當軟件處于讀取或者修改狀態時按鍵或者單擊鼠標

　　同時關閉或者啟動軟件的多個實例

　　同時使用不同的程序訪問一個共同數據庫

　　2.3 負載/壓力測試(StressTest)

　　在這里的負載/壓力和功能測試中的不同,他是系統測試的內容,是基本功能已經通過后進行的.可以在集成測試階段,亦可以在系統測試階段進行.

　　使用負載測試工具進行,虛擬一定數量的用戶看一看系統的表現,是否滿足定義中的指標.

　　負載測試一般使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的內容都是編寫出測試腳本，腳本中一般包括用戶一般常用的功能，然后運行，得出報告。所以負載測試包括的主要內容就不介紹了。

　　負載測試技術在各種極限情況下對產品進行測試 (如很多人同時使用該軟件，或者反復運行該軟件)，以檢查產品的長期穩定性。例如，使用壓力測試工具對web服務器進行壓力測試. 本項測試可以幫助找到一些大型的問題，如死機、崩損、內存泄漏等，因為有些存在內存泄漏問題的程序，在運行一兩次時可能不會出現問題，但是如果運行了成千上萬次，內存泄漏得越來越多，就會導致系統崩滑。用J2EE實現的系統很少但是并不是沒有內存問題.

　　無論什么工具基本的技術都是利用線程技術模仿和虛擬用戶，在這里主要的難點在與測試腳本的編寫，每種工具使用的腳本都不一樣，但是大多數工具都提供錄制功能就算是不會編碼的測試人員同樣可以測試。

　　對負載工具的延伸使用可以進行系統穩定性測試，系統極限測試，如使用100的Load Size連續使用24小時，微軟定義的通過準則是通過72小時測試的程序一般不會出現穩定性的問題。

　　2.4 回歸測試 (Regression Test)

　　過一段時間以后，再回過頭來對以前修復過的Bug重新進行測試，看該Bug 是否會重新出現。

　　回歸測試技術可以在測試的各個階段出現，無論是單元測試還是集成測試還是系統測試。是對以前問題進行驗證的過程。

　　回歸測試的目的就是保證以前已經修復的Bug不會再出現。實際上，許多Bug都是在回歸測試時發現的，在此階段，我們首先要檢查以前找到的Bug 是否已經更正了。值得注意的是，已經更正的Bug 也可能又回來了，有的Bug 經過修改之后可能又產生了新的Bug。所以，回歸測試可保證已更正的Bug不再重現，不產生新的Bug。

　　2.5 Alpha 和Beta 測試 (Alpha and Beta Test):

　　在正式發布產品之前往往要先發布一些測試版，讓用戶能夠反饋出相關信息，或者找到存在的Bug，以便在正式版中得到解決。

　　特別是在有客戶參加的情況下，對系統進行測試可能會出現一些我們沒有考慮的情況，還可以解決一些客戶實際關心的問題

　　3 不同的測試技術區分

　　3.1 覆蓋測試技術

　　說明:測試覆蓋率可以看出測試的完成度,在測試分析報告中可以作為量化指標的依據，測試覆蓋率越高效果越好。

　　覆蓋測試可以是程序代碼的執行路徑覆蓋，亦可以是功能實現的步驟覆蓋(可以理解成流程圖的路徑覆蓋)。

　　該技術可以用在任何測試階段，包括單元測壞死、集成測試、系統測試。

　　使用該技術時可以使用以上的任何測試方法和測試技術。

　　3.2 白盒測試和黑盒測試技術

　　白盒測試技術 (White Box Testing)該技術主要的特征是測試對象進入了代碼內部,根據開發人員對代碼和對程序的熟悉程度,對有需要的部分進行在軟件編碼階段，開發人員根據自己對代碼的理解和接觸所進行的軟件測試叫做白盒測試。這一階段測試以軟件開發人員為主，使用Xunit系列工具進行測試，可以包括很多方面如功能性能等。

　　黑盒測試 (Black Box Testing)測試的主體部分黑盒測試的內容主要有以下幾個方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結合兼容，性能測試等方面進行,包括的不同測試類型請參考以上內容。

　　3.3 手工測試和自動化測試

　　手工測試(Manual Testing)：即依靠人力來查找Bug。方法可以參考上邊的測試，也可以根據對實現技術及經驗等進行不同的測試。

　　自動測試(Automation Testing)使用有針對工具實行?？梢宰鞒?a href='http://www.kjueaiud.com/ceshi/ceshijishu/zdcs/' target='_blank'>自動化測試的計劃,對可以進行自動化測試的部分編寫或者錄制相應的腳本,可以加入功能,容錯,表單提交等,可以參考MI,Rational或者其他類測試工具說明.

　　根據權威的軟件測試經驗，手工測試還是主要的測試方法，自動測試不夠靈活，在這里不再詳述。微軟的測試過程80%還是手工完成。

　　自動測試永遠也代替不了手工測試，但是手工測試的工作量很大是不爭的事實。

　　3.4 根據RUP標準按階段區分測試

　　單元測試在上邊有詳細的敘述，還有針對單元測試和集成測試的論述，請參考。

　　集成測試分為功能集成測試和系統集成測試，相互有調用的功能集成，在系統環境下功能相互調用的影響等，使用方法可以任意選用上面的內容。注重功能方面。

　　系統測試在功能實現的基礎上，可以加入兼容性，易用性，性能等等

　　驗收測試可以包括Alpha和Beta測試，在這里就不再詳述。

　　4. 存在風險及解決方法

　　說明：測試不能找出所有的問題，只是盡量將問題在開發階段解決大多數的問題而已。

　　測試風險如下：

　　軟硬件的測試環境提供上也對測試結果有很大的影響。

　　測試團隊的水平，經驗，合作效果等

　　整個開發流程對測試的重視程度，測試的進入時間等

　　由于測試環境操作系統，網絡環境，帶寬等情況可能產生的測試結果可能不同這是就需要經驗以及對測試環境的保護等方面下一些功夫。

　　5. 軟件缺陷的原則

原文轉自：http://www.kjueaiud.com