測試策略制定常用的理論方法

A. 軟體測試的原則與策略是什麼

測試方法是指解決問題的技術手段或工具的集合。
軟體測試策略是指如何選擇和運用方法來解決具體問題。
軟體測試有很多方法等價類、邊界值、語句覆蓋、條件覆蓋、路徑覆蓋、場景法、自頂向下&自底向上集成法等等。當你掌握和了解這些方法之後，怎麼運用到實際項目中呢。就需要制定測試策略，在測試項目中什麼時間、什麼任務需要運用哪個或哪些方法或哪些工具、怎麼組織起來去解決完成，這就是策略。
例如：一個測試項目中在單元測試階段採用技術評審法（代碼審查），在集成階段採用三明治法，在系統測試階段採用場景法，在針對功能進行測試時選用適當的黑盒測試方法設計測試用例；在進行單元、集成測試時選用適當的白盒方法設計測試用例；在進行性能相關測試時選用適當的測試工具進行等等，這就是測試策略。
它們的范圍不是以大小而論，也不是包含關系。測試工作涉及的方法很多，策略是根據項目需要從方法集中選擇適合的技術方法，把他們合理的組織起來完成測試任務；測試策略能夠指導測試工作的順利進行。

B. 什麼是測試策略

測試策略描述測試工程的總體方法和目標。

描述目前在進行哪一階段的測試（單元測試、集成測試、系統測試）以及每個階段內在進行的測試種類（功能測試、性能測試、覆蓋測試等）。

測試策略的制定主要包含三個方面的內容：

（1）確定測試過程要使用的測試技術和工具；

（2）制定測試啟動、停止、完成標准；

（3）進行風險分析和應對方案。例如測試與外部介面或者模擬物理損壞、安全性威脅。測試計劃最關鍵的一步就是將軟體分解成單元，按照需求編寫測試計劃。

(2)測試策略制定常用的理論方法擴展閱讀。

測試英文名Test、Measure;中文拼音cè shì;由中文"測"與中文"試"兩個字組成的詞語。

是動詞、名詞。

測試行為，一般發生於為檢測特定的目標是否符合標准而採用專用的工具或者方法進行驗證，並最終得出特定的結果。

C. 測試架構師：4 如何才能制定好測試策略

測試策略總覺得這樣喊太深奧，或者換個方式:做什麼樣的事情才能將軟體的質量真實的評估出來，答案是，覆蓋所有業務路徑和功能場景，但是日常生產是不可能做到的，所以有取捨。取捨的依據有很多點可以參考衡量，一般核心業務比邊緣業務要投入更多，實現技術復雜的要比簡單的更側重，測試策略最終直接體現在我們如何安排系統的測試優先順序以及對於某個具體功能測試哪些點

D. 測試計劃的測試策略

提供了對測試對象進行測試的推薦方法。
對於每種測試，都應提供測試說明，並解釋其實施的原因。
制定測試策略時所考慮的主要事項有：將要使用的技術以及判斷測試何時完成的標准。
下面列出了在進行每項測試時需考慮的事項，除此之外，測試還只應在安全的環境中使用已知的、有控制的資料庫來執行。
注意：不實施某種測試，則應該用一句話加以說明，並陳述這樣的理由。例如，「將不實施該測試。該測試本項目不適用」。
[要<項目名稱>中，資料庫和資料庫進程應作為一個子系統來進行測試。在測試這些子系統時，不應將測試對象的用戶界面用作數據的介面。對於資料庫管理系統（DBMS），還需要進行深入的研究，以確定可以支持以下測試的工具和技術。]
測試目標：[確保資料庫訪問方法和進程正常運行，數據不會遭到損壞]
測試范圍：
技術：[調用各個資料庫訪問方法和進程，並在其中填充有效的和無效的數據（或對數據的請求）。
檢查資料庫，確保數據已按預期的方式填充，並且所有的資料庫事件已正常發生；或者檢查所返回的數據，確保正當的理由檢索到了正確的數據]
完成標准：[所有的資料庫訪問方法和進程都按照設計的方式運行，數據沒有遭到損壞。]
測試重點和優先順序：
需考慮的特殊事項：[測試可能需要DBMS開發環境或驅動程序在資料庫中直接輸入或修改數據。
進程應該以手工方式調用。
應使用小型或最小的資料庫（記錄的數量有限）來使所有無法接受的事件具有更大的可視度。]
測試目標：確保介面調用的正確性
測試范圍：所有軟體、硬體介面，記錄輸入輸出數據
技術：
開始標准：
完成標准：
測試重點和優先順序：
需考慮的特殊事項：介面的限制條件
[集成測試―主要目的檢測系統是否達到需求對業務流程及數據流的處理是否符合標准，檢測系統對業務流處理是否存在邏輯不嚴謹及錯誤，檢測需求是否存在不合理的標准及要求。此階段測試基於功能完成的測試。]
測試目標：檢測需求中業務流程，數據流的正確性
測試范圍：需求中明確的業務流程，或組合不同功能模塊而形成一個大的功能。
技術：[利用有效的和無效的數據來執行各個用例、用例流或功能，以核實以下內容：在使用有效數據時得到預期的結果。
在使用無效數據時顯示相應的錯誤消息或警告消息。各業務規則都得到了正確的應用。]
開始標准：在完成某個集成測試時必須達到標准
完成標准：[所計劃的測試已全部執行。所發現的缺陷已全部解決。]
測試重點和優先順序：測試重點指在測試過程中需著重測試的地方，優先順序可以根據需求及嚴重來定
需考慮的特殊事項：[確定或說明那些將對功能測試的實施和執行造成影響的事項或因素（內部的或外部的）]
[對測試對象的功能測試應側重於所有可直接追蹤到用例或業務功能和業務規則的測試需求。這種測試的目標是核實數據的接受、處理和檢索是否正確，以及業務規則的實施是否恰當。此類測試基於黑盒技術，該技術通過圖形用戶界面（GUI）與應用程序進行交互，並對交互的輸出或結果進行分析，以此來核實應用程序及其內部進程。以下為各種應用程序列出了推薦使用的測試概要：]
測試目標：[確保測試的功能正常，其中包括導航，數據輸入，處理和檢索等功能。]
測試范圍：
技術：[利用有效的和無效的數據來執行各個用例、用例流或功能，以核實以下內容：在使用有效數據時得到預期的結果。
在使用無效數據時顯示相應的錯誤消息或警告消息。各業務規則都得到了正確的應用。]
開始標准：
完成標准：
測試重點和優先順序：
需考慮的特殊事項：[確定或說明那些將對功能測試的實施和執行造成影響的事項或因素（內部的或外部的）]
[用戶界面（UI）測試用於核實用戶與軟體之間的交互。UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外，UI測試還可確保UI中的對象按照預期的方式運行，並符合公司或行業的標准。]
測試目標：[核實以下內容：
通過測試進行的瀏覽可正確反映業務的功能和需求，這種瀏覽包括窗口與窗口之間、欄位與欄位之間的瀏覽，以及各種訪問方法（Tab鍵、滑鼠移動、和快捷鍵）的使用窗口的對象和特徵（例如，菜單、大小、位置、狀態和中心）都符合標准。]
測試范圍：
技術：[為每個窗口創建或修改測試，以核實各個應用程序窗口和對象都可正確地進行瀏覽，並處於正常的對象狀態。]
開始標准：
完成標准：[成功地核實出各個窗口都與基準版本保持一致，或符合可接受標准]
測試重點和優先順序：
需考慮的特殊事項：[並不是所有定製或第三方對象的特徵都可訪問。]
[性能評測是一種性能測試，它對響應時間、事務處理速率和其他與時間相關的需求進行評測和評估。性能評測的目標是核實性能需求是否都已滿足。實施和執行性能評測的目的是將測試對象的性能行為當作條件（例如工作量或硬體配置）的一種函數來進行評測和微調。
註：以下所說的事務是指「邏輯業務事務」。這種事務被定義為將由系統的某個Actor通過使用測試對象來執行的特定用例，添加或修改給定的合同。]
測試目標：[核實所指定的事務或業務功能在以下情況下的性能行為：正常的預期工作量預期的最繁重工作量]
測試范圍：
技術：[使用為功能或業務周期測試制定的測試過程。通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務的迭代數量。腳本應該在一台計算機上運行（最好是以單個用戶、單個事務為基準），並在多個客戶機（虛擬的或實際的客戶機，請參見下面的「需要考慮的特殊事項」）上重復。]
開始標准：
完成標准：[單個事務或單個用戶：在每個事務所預期時間范圍內成功地完成測試腳本，沒有發生任何故障。][多個事務或多個用戶：在可接受的時間范圍內成功地完成測試腳本，沒有發生任何故障。]
測試重點和優先順序：
需考慮的特殊事項：[綜合的性能測試還包括在伺服器上添加後台工作量。可採用多種方法來執行此操作，其中包括：直接將「事務強行分配到」伺服器上，這通常以「結構化語言」（SQL）調用的形式來實現。通過創建「虛擬的」用戶負載來模擬許多個（通常為數百個）客戶機。此負載可通過「遠程終端模擬（Remote Terminal Emulation）工具來實現。此技術還可用於在網路中載入「流量」。使用多台實際客戶機（每台客戶機都運行測試腳本）在系統上添加負載。性能測試應該在專用的計算機上或在專用的機時內執行，以便實現完全的控制和精確的評測。性能測試所用的資料庫應該是實際大小或相同縮放比例的資料庫。]
[負載測試是一種性能測試。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。負載 測試的目標是確定並確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特徵，例如，響應時間、事務處理速率和其他與時間相關 的方面。]
[註：以下所說的事務是指「邏輯業務事務」。這各事務被定義為將由系統的某個最終用戶通過使用應用程序來執行的特定功能，例如，添加或修改給定的合同。]
測試目標：[核實所指定的事務或商業理由在不同的工作量條件下的性能行為時間。]
測試范圍：
技術：[使用為功能或業務周期測試制定的測試。通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務發生的次數。]
開始標准：
完成標准：[多個事務或多個用戶：在可接受的時間范圍內成功地完成測試，沒有發生任何故障。]
測試重點和優先順序：
需考慮的特殊事項：[負載測試應該在專用的計算機上或在專用的機時內執行，以便實現完全的控制和精確的評測。
負載測試所用的資料庫應該是實際大小或相同縮放比例的資料庫。]
[強度測試是一種性能測試，實施和執行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果內存或磁碟空間不足，測試對象就可能會表現出一些在正常條 件下並不明顯的缺陷。而其他缺陷則可能由於爭用共享資源（如資料庫鎖或網路帶寬）而造成的。強度測試還可用於確定測試對象能夠處理的最大工作量。]
[註：以下提到的事務都是指邏輯業務事務。]
測試目標：[核實測試對象能夠在以下強度條件下正常運行，不會出現任何錯誤：伺服器上幾乎沒有或根本沒有可用的內存（RAM和DASD）連接或模擬了最大實際（實際允許）數量的客戶機多個用戶對相同的數據或帳戶執行相同的事務最繁重的事務量或最差的事務組合（請參見上面的「性能測試」）。註：強度測試的目標可表述為確定和記錄那些使系統無法繼續正常運行的情況或條件。
客戶機的強度測試在「配置測試」的第3.1.11節中進行了說明。]
測試范圍：
技術：[使用為性能評測或負載測試制定的測試。要對有限的資源進行測試，就應該在一台計算機上運行測試，而且應該減少或限制伺服器上的RAM和DASD。對於其他強度測試，應該使用多台客戶機來運行相同的測試或互補的測試，以產生最繁重的事務量或最差的事務組合。]
開始標准：
完成標准：[所計劃的測試已全部執行，並且在達到或超出指定的系統限制時沒有出現任何軟體故障，或者導致系統出現故障條件的並不在指定的條件范圍之內。]
測試重點和優先順序：
需考慮的特殊事項：[如果要增加網路工作強度，可能會需要使用網路工具來給網路載入消息或信息包。應該暫時減少用於系統的DASD，以限制資料庫可用空間的增長。使多個客戶機對相同的記錄或數據帳戶同時進行的訪問達到同步。]
[容量測試使測試對象處理大量的數據，以確定是否達到了將使軟體發生故障的極限。容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。例 如，如果測試對象正在為生成一份報表而處理一組資料庫記錄，那麼容量測試就會使用一個大型的測試資料庫。檢驗該軟體是否正常運行並生成了正確的報表。]
測試目標：[核實測試對象在以下高容量條件下能否正常運行：連接或模擬了最大（實際或實際允許）數量的客戶機，所有客戶機在長時間內執行相同的、且情況（性能）最壞的業務功能。已達到最大的資料庫大小（實際的或按比例縮放的），而且同時執行多個查詢或報表事務。]
測試范圍：
技術：[使用為性能評測或負載測試制定的測試。應該使用多台客戶機來運行相同的測試或互補的測試，以便在長時間內產生最繁重的事務量或最差的事務組合（請參見上面的「強度測試」）創建最大的資料庫大小（實際的、按比例縮放的、或填充了代表性數據的資料庫），並使用多台客戶機在長時間內同時運行查詢和報表事務。]
開始標准：
完成標准：所計劃的測試已全部執行，而且達到或超出指定的系統限制時沒有出現任何軟體故障。]
測試重點和優先順序：
需考慮的特殊事項：[對於上述的高容量條件，哪個時間段是可以接受的時間？]
安全性和訪問 [故障轉移和恢復測試可可確保測試對象能成功完成轉移，並能從導致意外數據損失或數據完整性破壞的各種硬體、軟體可網路故障中恢復。故障轉移測試可確保：對於必須持續運行的系統，一旦發生故障，備用系統就將不失時機地「頂替」發生故障的系統，以避免丟失任何數據或事務。恢復測試是一種對抗性的測試過程。在這種測試中，將把應用程序或系統置於極端的條件下（或者是模擬的極端條件下），以產生故障（例如設備輸入/輸出（I/O）故障或無效的資料庫指針和關鍵字）。然後調用恢復進程並監測和檢查應用程序和系統，核實應用程序或系統和數據已得到了正確的恢復。]
測試目標：[確保恢復進程（手工或自動）將資料庫、應用程序和系統正確地恢復到預期的已知狀態。
測試中將包括以下各種情況：客戶機斷電、伺服器斷電、通過網路伺服器產生的通信中斷DASD和/或DASD控制器被中斷、斷電或與DASD和/或DASD控制器的通信中斷
周期未完成（數據過濾進程被中斷，數據同步進程被中斷）、資料庫指針或關鍵字無效、資料庫中的數據元素無效或遭到破壞]
測試范圍：
技術：[應該使用為功能和業務周期測試創建的測試來創建一系列的事務。一旦達到預期的測試起點，就應該分別執行或模擬以下操作：
 客戶機斷電：關閉PC機的電源。
 伺服器斷電：模擬或啟動伺服器的斷電過程。
 通過網路伺服器產生的中斷：模擬或啟動網路的通信中斷（實際斷開通信線路的連接或關閉網路伺服器或路由器的電源）。
 DASD和DASD控制器被中斷、斷電或與DASD和DASD控制器的通信中斷：模擬與一個或多個DASD控制器或設備的通信，或實際取消這種通信。
 一旦實現了上述情況（或模擬情況），就應該執行其他事務。而且一旦達到第二個測試點狀態，就應調用恢復過程。
 在測試不完整的周期時，所使用的技術與上述技術相同，只不過應異常終止或提前終止資料庫進程本身。
 對以下情況的測試需要達到一個已知的資料庫狀態。當破壞若干個資料庫欄位、指針和關鍵字時，應該以手工方式在資料庫中（通過資料庫工具）直接進行。其他事務應該通過使用「應用程序功能測試」和「業務周期測試」中的測試來執行，並且應執行完整的周期。]
開始標准：
完成標准：[在所有上述情況中，應用程序、資料庫和系統應該在恢復過程完成時立即返回到一個已知的預期狀態。此狀態包括僅限於已知損壞的欄位、指針或關鍵字范圍內的數據損壞，以及表明進程或事務因中斷面未被完成的報表。]
測試重點和優先順序：
需考慮的特殊事項： [恢復測試會給其他操作帶來許多的麻煩。斷開纜線連接的方法（模擬斷電或通信中斷）可能並不可取或不可行。所以，可能會需要採用其他方法，例如診斷性軟體工具。
 需要系統（或計算機操作）、資料庫和網路組中的資源。
 這些測試應該在工作時間之外或在一台獨立的計算機上運行。]
[配置測試核實測試對象在不同的軟體和硬體配置中的運行情況。在大多數生產環境中，客戶機工作站、網路連接和資料庫伺服器的具體硬體規格會有所不同。客戶機工 作站可能會安裝不同的軟體例如，應用程序、驅動程序等而且在任何時候，都可能運行許多不同的軟體組合，從而佔用不同的資源。]
測試目標：[核實測試可在所需的硬體和軟體配置中正常運行。]
測試范圍：
技術：[使用功能測試腳本。
 在測試過程中或在測試開始之前，打開各種與非測試對象相關的軟體（例如Microsoft應用程序：Excel和Word），然後將其關閉。
 執行所選的事務，以模擬Actor與測試對象軟體和非測試對象軟體之間的交互。
 重復上述步驟，盡量減少客戶機工作站上的常規可用內存。]
開始標准：
完成標准：[對於測試對象軟體和非測試對象軟體的各種組合，所有事務都成功完成，沒有出現任何故障。]
測試重點和優先順序：
需考慮的特殊事項：[需要、可以使用並可以通過桌面訪問哪種非測試對象軟體？
 通常使用的是哪些應用程序？
 應用程序正在運行什麼數據？例如，在Excel中打開的大型電子表格，或是在Word中打開的100頁文檔。
 作為此測試的一部分，應將整修系統、Netware、網路伺服器、資料庫等都記錄下來。]
[安裝測試有兩個目的。第一個目的是確保該軟體在正常情況和異常情況的不同條件下例如，進行首次安裝、升級、完整的或自定義的安裝都能進行安裝。異常情況 包括磁碟空間不足、缺少目錄創建許可權等。第二個目的是核實軟體在安裝後可立即正常運行。這通常是指運行大量為功能測試制定的測試。]
測試目標：核實在以下情況下，測試對象可正確地安裝到各種所需的硬體配置中：
 首次安裝。以前從未安裝過<項目名稱>的新計算機
 更新。以前安裝過相同版本的<項目名稱>的計算機
 更新。以前安裝過從未安裝過；<項目名稱>安裝過相同或較早的版本。
 啟動或執行安裝。
 使用預先確定的功能測試腳本子集來運行事務。
開始標准：
完成標准：<項目名稱>事務成功執行，沒有出現任何故障。
測試重點和優先順序：
需考慮的特殊事項：[應該選擇<項目名稱>的哪些事務才能准確地測試出<項目名稱>應用程序已經成功安裝，而且沒有遺漏主要的軟體構件？。

E. 如何制定測試計劃

測試計劃活動的輸出是一份測試計劃，它是一份或多份文檔，應該由測試團隊、開發團隊和項目管理層復查。測試計劃確定了測試產品所需的資源，確定了我們將測試什麼，測試將怎樣進行，測試將得到怎樣的輸出或提交產物。我們一直使用日事清來做軟體測試工作。日事清幫你來做軟體測試工作計劃：一是有明確的目標；二是有詳細的計劃；三是立刻採取行動；四是修復自己的行動。以上四點是高效完成測試工作的四個基本條件。首先把自己的軟體測試計劃通通列出來，清空大腦，做一個軟體測試計劃前的行動。根據自己的輕重緩急來分配軟體測試任務。
一是確定測試策略。測試策略一般描述軟體測試活動的一般方法和目標。其中包括要進行的測試階段（單元測試、集成測試和系統測試）以及要執行的測試類型（功能測試、性能測試、負載測試、強度測試等）。確定測試需求：明確測試的工作范圍，需要測試的對象、達到的指標等。可以來源於軟體需求，個人經驗，以前發生的錯誤等。
二是確定測試系統。確定測試環境。確定測試工具。確定配置情況。確定測試資源。測試人力資源。測試非人力資源（計算機、工具等）
三是確定測試任務。根據本階段測試需求，細化測試任務。劃分任務優先順序，和主要任務關聯關系。確定輔助任務清單（如培訓等）。確定資源情況。
四是評估和確定測試工作量。目前沒有任何一種方法能准確的評估出軟體測試工作的工作量，要想更有效的做出估算，必須持之以恆的統計和分析歷史數據。主要的估算方法為：分析以前的同類項目、同行專家判斷、分解細化項目、經驗主意預估模型（代碼行(LOC)和功能點(FP)估演算法等）。
五是確定時間進度。收集與進度相關的信息：總體工作量估算、人員數量、關鍵資源、項目時間安排等。確定各階段任務安排和資源分配，確定里程碑。依據項目總體時間安排，形成進度計劃。確定時間段。為每個測試目標規定合理的測試起始/中止時間。通常情況下，功能性需求和非功能性需求的測試存在先後順序，能並行。
六是評估風險。風險分析、對測試計劃中所有要執行的內容進行潛在的風險分析並給出規避措施、確定項目中可能會出問題的地方、如測試人員沒有接受必要的培訓、測試人員不足、需求變化過快、自動測試技術的採用等、評估風險的發生概率、如風險發生後可能的影響程度、如何降低風險乃至避免風險的方法。
七是確定測試過程評估方法。確定測試過程評估方法、評估內容：測試工作進展/缺陷分布/質量評估、評估間隔：每天/周/月、評估人員/報告原則。

F. 製作軟體測試計劃的方法和技巧

具體的要點有：
一是變更。說明有可能會導致測試計劃變更的事件。包括測試工具改進了，測試的環境改變了，或者是添加了新的功能。
二是產品規格。就是製造商和產品版本號的說明。
三是項目信息。說明要測試的項目的相關資料，如：用戶文檔，產品描述，主要功能的舉例說明。
四是測試需求說明。功能的測試：理論上是測試是要覆蓋所有的功能項，例如：在資料庫中添加、編輯、刪除記錄等等，這會是一個浩大的工程，但是有利於測試的完整性。設計的測試：對於一些用戶界面、菜單的結構還有窗體的設計是否合理等的測試。整體考慮：這部分測試需求要考慮到數據流從軟體中的一個模塊流到另一個模塊的過程中的正確性。
五是測試的策略和記錄。公正性聲明：要對測試的公正性、遵照的標准做一個說明，證實測試是客觀的，整體上，軟體功能要滿足需求，實現正確，和用戶文檔的描述保持一致。非凡考慮：有的時候，針對一些外界環境的影響，要對軟體進行一些非凡方面的測試。經驗判定：對以往的測試中，經常出現的問題加以考慮。設想：採取一些發散性的思維，往往能幫助你找的測試的新途徑。
六是測試資源配置。項目資源計劃：制定一個項目資源計劃，包含的是每一個階段的任務、所需要的資源，當發生類似到了使用期限或者資源共享的事情的時候，要更新這個計劃。問題跟蹤報告：問題描述盡可能是定量的，分門別類的列舉，問題有嚴重、一般、建議等幾種。
七是測試計劃的評審。又叫測試規范的評審，在測試真正實施開展之前必須要認真負責的檢查一遍，獲得整個測試部門人員的認同，包括部門的負責人的同意和簽字。
測試計劃很復雜，測試的流程可以使用日事清進行管理。日事清通過看板按照項目、部門、時間等維度組織團隊工作清單，創建團隊工作計劃，讓團隊工作可視化。任務會自動分解至團隊相關成員的個人日程中去，讓個人的日程和團隊的工作安排打通，實時跟進。

G. 請問系統測試的策略是什麼

系統測試策略
：測試策略用於說明某項特定測試工作的一般方法和目標。一個好的測試策略應該包括下列內容：
要實施的測試類型和測試的目標
採用的技術
用於評估測試結果和測試是否完成的標准
對測試策略所述的測試工作存在影響的特殊事項
系統測試類型和目標對於UT
or
IT
我們或許會有自頂向下，自底向上，孤立測試等策略，但是系統測試卻不能准確的有測試順序來制定測試策略，但是ST中有大量的測試類型：功能測試、性能測試、壓力測試、容量測試、安全性測試、GUI測試、可用性測試、安裝測試、穩定性測試等。根據項目需求從中選擇項目的關注點來進行測試，並規定每種測試使用的工具，達到的目標就是系統測試策略了！

H. 如何做好測試策略

16種測試策略:
功能測試，性能測試，壓力測試，容量測試，安全性測試，GUI測試，可用性測試，安裝測試，配置測試，
異常測試，備份測試，健壯性測試，文檔測試，在線幫助測試，網路測試，穩定性測試
在:正常情況下測試;非正常情況下測試;邊界測試;非法，極端測試;

I. 如何才能制定好測試策略

制定測試策略是軟體測試架構師最核心的技能，但是要想做好這項工作並不是一件容易的事情。
測試策略分為了一下幾個模塊：
1. 測試安排、發布計劃
這個模塊用來羅列測試項目本身重要的里程碑，每個里程碑都需要有明確的結束時間，這個時間可以指導我們後續的測試。如果測試時間安排不足，我們就可以在後續的測試范圍中挑選優先順序比較高的特性來執行測試，這樣可以最大限度的保證產品的質量。
2. 測試范圍（按優先順序排列）
這一部分分為In Scope和Out Of Scope.這一部分需要說明哪些產品模塊是在測試范圍中的，哪些是本階段測試不考慮的。對於在測試范圍中的模塊，需要給出優先順序以便相應測試時間不足的情況；對於不在測試范圍中的模塊，需要給出原因（為什麼在本測試階段不考慮測）。
3. 測試資源
測試資源在測試策略中也是很重要的一環，它分為人力和工具兩部分。人力資源主要說明參與測試的人員，當然可以包括很多的角色，如何專業測試人員，客戶，產品經理等。工具主要是指可能用到其他軟體（可能需要license）。
4. 測試環境
測試環境主要包括推薦環境解決方案，操作系統要求，軟硬體要求。
對於推薦解決方案，需要陳述的是對測試項目對其他軟體的依賴，比如測試項目對.Net有依賴，這時我們可能給出的推薦版本可能就是4.5.2，在之後的測試中主要是針對4.5.2進行驗證，而對其他版本進行簡單驗證，這樣在產品文檔中給出4.5.2的推薦方案，主要是為了說明4.5.2是沒問題的，其他版本不保證。
操作系統主要是說明對windows或者其他操作系統的版本的支持情況。
5. 測試方法
測試方法的羅列主要是為了說明針對測試項目我們要開展哪些類型的測試，功能測試是必須的，非功能測試是可選的。（相信各位童鞋對測試方法都已經倒背如流了，就不一一介紹了）
6. 用例設計方法
用例設計大家也很清楚了，不再介紹了。
7. 文檔管理
對於一個完整的產品來說，文檔是很重要的一環。它一般包括安裝、升級文檔，用戶指南等。文檔不單單是一個文件，它需要經過完整的測試才能發布給客戶。差的文檔很可能會誤導用戶，從而使他們對測試項目失去信心。
8. 風險管理
風險管理模塊需要羅列出來現在已知的可能會出現不確定性的因素，這些因素可能來自技術，資源或者其他方面的。
9. 發布包驗證
這部分有一定的特殊性，並不適用於所有的產品。這部分主要是對測試項目安裝包進行驗證，防止在製作ISO文件的過程中產生變動。

J. 軟體測試的基本方法和流程

軟體測試工作流程：
1、需求分析、需求評審
需求分析和評審就是分析客戶的需求可不可行，需要怎麼進行測試。
2、編寫測試計劃
編寫測試計劃通俗一點講就是什麼人在什麼時間做什麼事，最後產出什麼東西。那也就是測試人員要測試哪些模塊、在什麼期限內，提交哪些文檔。
3、編寫測試用例、用例評審
測試用例就是指導測試的文檔，比如我們要測試商城登錄、買東西等功能，通過測試方法和策略設計測試用例。
評審就是評價審查，不能想當然該怎麼測。不能只是輸入正確的用戶名和密碼，能登錄進去就完事了。作為軟測工程師需要有破壞性，比如密碼輸錯時怎麼辦?會不會有相應的報錯等等?
4、執行測試、提交bug、回歸測試
Bug就是缺陷，發現bug之後，要提交給開發人員讓他們去修改，然後進行回歸測試，驗證開發人員有沒有改好。
5、編寫測試總結報告
Bug都改好了之後，要編寫測試總結報告，這款軟體的質量如何。
制定測試計劃；
然後根據測試計劃做：
設計測試用例、實施測試（首先要搭建測試用環境）、管理測試時發現的BUG、測試完後（測試完，並且發現的BUG修正完）要做測試報告（這樣，該測試過程就算結束了，每種類型（單元測試、集成測試、系統測試、驗證測試）的測試都是如此）；

根據項目規模大小不同，不同公司規范不同，會有較大差別的；