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）使用有針對工具實行�？梢宰鞒鲎詣踊瘻y試的計劃,對可以進行自動化測試的部分編寫或者錄制相應的腳本,可以加入功能,容錯,表單提交等,可以參考MI,Rational或者其他類測試工具說明.
根據權威的軟件測試經驗，手工測試還是主要的測試方法，自動測試不夠靈活，在這里不再詳述。微軟的測試過程80％還是手工完成。
自動測試永遠也代替不了手工測試，但是手工測試的工作量很大是不爭的事實。
3.4 根據RUP標準按階段區分測試
單元測試 在上邊有詳細的敘述，還有針對單元測試和集成測試的論述，請參考。
集成測試 分為功能集成測試和系統集成測試，相互有調用的功能集成，在系統環境下功能相互調用的影響等，使用方法可以任意選用上面的內容。注重功能方面。
系統測試 在功能實現的基礎上，可以加入兼容性，易用性，性能等等
驗收測試 可以包括Alpha和Beta測試，在這里就不再詳述。
4. 存在風險及解決方法
說明：測試不能找出所有的問題，只是盡量將問題在開發階段解決大多數的問題而已。
測試風險如下：
軟硬件的測試環境提供上也對測試結果有很大的影響。
測試團隊的水平，經驗，合作效果等
整個開發流程對測試的重視程度，測試的進入時間等
由于測試環境操作系統，網絡環境，帶寬等情況可能產生的測試結果可能不同這是就需要經驗以及對測試環境的保護等方面下一些功夫。
5. 軟件缺陷的原則
軟件缺陷區別于軟件bug,它是在測試過程中出現的對系統有影響的,但是在設計中沒有的或者對修改后的bug測試和開發人員有不同意見等
- 軟件未達到產品說明書標明的功能。
- 軟件出現了產品說明書指明不會出現的錯誤。
- 軟件功能超出產品說明書指明范圍。
- 軟件未達到產品說明書雖未指出但應達到的目標。
- 軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。
6. 文檔測試
產品說明書屬性檢查清單
- 完整.是否有遺漏和丟失?完全嗎?單獨使用是否包含全部內容?
- 準確.既定解決方案正確嗎?目標明確嗎?有沒有錯誤?
- 精確,不含糊,清晰.描述是否一清二楚?還是自說自話?容易看懂和理解嗎?
- 一致.產品功能能描述是否自相矛盾,與其他功能有沒有沖突?
- 貼切.描述功能的陳述是否必要?有沒有多余信息?功能是否原來的客戶要求?
- 合理.在特定的預算和進度下,以現有人力,物力和資源能否實現?
- 代碼無關.是否堅持定義產品,而不是定義其所信賴的軟件設計,架構和代碼?
- 可測試性.特性能否測試?測試員建立驗證操作的測試程序是否提供足夠的信息?
產品說明書用語檢查清單
說明 對問題的描述通常表現為粉飾沒有仔細考慮的功能----可歸結于前文所述的屬性.從產品說明書上找出這樣的用語,仔細審視它們在文中是怎樣使用的.產品說明書可能會為其掩飾和開脫,也可能含糊其詞----無論是哪一種情況都可視為軟件缺陷.
- 總是,每一種,所有,沒有,從不.如果看到此類絕對或肯定的,切實認定的敘述,軟件測試員就可以著手設計針鋒相對的案例.
- 當然,因此,明顯,顯然,必然.這些話意圖誘使接受假定情況.不要中了圈套.
- 某些,有時,常常,通常,慣常,經常,大多,幾乎.這些話太過模糊."有時"發生作用的功能無法測試.
- 等等,諸如此類,依此類推.以這樣的詞結束的功能清單無法測試.功能清單要絕對或者解釋明確,以免讓人迷惑,不知如何推論.
- 良好,迅速,廉價,高效,小,穩定.這些是不確定的說法,不可測試.如果在產品說明書中出現,就必須進一步指明含義.
- 已處理,已拒絕,已忽略,已消除.這些廉潔可能會隱藏大量需要說明的功能.
- 如果...那么...(沒有否則).找出有"如果...那么..."而缺少配套的"否則"結構的陳述.想一想"如果"沒有發生會怎樣.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
