5.2.1 測試計畫的目的與內容
測試計畫羅列了開發和維護專案的測試活動。規劃受組織的測試方針和測試策略、開發生命週期和使用的方法（見第2.1節）、測試範圍、目標、風險、約束、重要性、可測試性和資源的可用性等因素的影響。
隨著專案和測試計畫的進展，更多的資訊變得可用，更多的細節可以包括在測試計畫中。測試計畫是一項持續的活動，貫穿於整個產品的生命週期。（請注意，產品的生命週期可能超出專案的範圍以包括維護階段。）根據測試活動的反饋來確認不斷變化的風險，從而調整規劃。計畫可記錄在主測試計畫和單獨的測試級別測試計畫中，如系統測試和驗收測試，或單獨的測試型別，如易用性測試和效能測試。測試規劃活動可包括以下內容，其中一些內容可記錄在測試計畫中：
• 確定測試的範圍、目標和風險
• 確定測試的總體方法
• 將測試活動納入軟體生命週期活動並加以協調
• 確定測試什麼、進行各種測試活動所需的人員和其他資源，以及如何進行測試活動
• 按照特定的日期（例如：在順序開發中）或在每個迭代的上下文中，針對測試分析、設計、實現、執行和評估活動制訂時間進度表
• 選擇測試監視和控制相關的度量
• 確定測試活動預算
• 確定測試文件的詳細程度和結構(例如：通過提供模板或示例文件)
測試計畫的內容各不相同，並且可以延伸到上述主題之外。測試計畫的例子可以在iso標準中找到（iso/ieee/ieee 29119-3）。
5.2.2 測試策略和測試方法
測試策略通常在產品或組織級別對測試過程進行了描述。常見的測試策略包括：
• 分析型:該型別測試策略基於對一些因素(例如需求或風險)進行分析。基於風險的測試是分析型方法的乙個例子，根據風險級別設計測試並確定其優先順序。
• 基於模型的：該型別的測試策略，測試的設計是基於產品某些方面的模型，如功能、業務流程、內部結構或非功能特性（如可靠性）。這類模型的例子包括業務流程模型、狀態模型和可靠性增長模型。
• 方法型：該型別的測試策略依賴於系統化使用一些預定義的測試集或測試條件，如常見或可能的失效分類，重要質量特性的列表，或全公司的手機應用程式或網頁的視覺和感覺標準。
• 符合過程(或標準)：該類測試策略基於外部規則和標準的測試分析、設計和實現測試，如特定行業標準，流程文件，嚴格標識和使用的測試依據，或組織主動或被動強制的過程或標準。
• 指導型(或諮詢型)：該類測試策略主要通過利益相關者、業務領域專家或技術專家的建議、指導或指示驅動，他們可能來自測試小組或組織外。
• 回歸避免：該型別的測試策略的動機是希望避免現有能力的回歸。這個測試策略包括重用現有的測試件（特別是測試用例和測試資料）、回歸測試的廣泛自動化以及標準化測試套件。
• 應對型：該型別的測試策略是對正在測試的元件或系統以及在測試執行過程中發生的事件作出反應，而不是事先計畫好的（如前面的策略）。設計和實現的測試，可能會根據以前測試結果中獲得的知識立即得到執行。探索性測試是應對型策略中常用的一種技術。
合適的測試策略通常是結合多種其中幾種型別的測試策略來建立的。例如，例如：基於風險的測試（分析型測試）可與探索性測試（應對型策略）相結合；它們相輔相成，並可在一起使用時實現更有效的測試。
測試策略提供了測試過程的廣義描述，而測試方法則針對特定專案或發布對測試策略進行裁剪。測試方法是選擇測試技術、測試級別和測試型別的起點，也是定義入口準則和出口準則（或分別是已準備的定義和已完成的定義）的起點。根據專案的複雜性和目標、正在開發的產品型別以及產品風險分析作出的決定，對測試策略進行裁剪。選擇的方法取決於上下文，並考慮風險、安全、可用資源和技能、技術、系統特點(例如：定製與cots)、測試目標和法規等因素。
為了有效控制軟體和測試的質量，建議制定準則，以定義特定測試活動何時開始，以及何時完成。入口準則（敏捷開發中更典型地稱為已準備的定義）定義了進行特定測試活動的先決條件。如果不符合入口準則，則說明該活動很可能會更困難、更耗時、更昂貴和風險更大。出口準則（敏捷開發中更典型地稱為已完成的定義）必須達到的條件，以宣告乙個測試級別或一組測試已經完成。針對每個測試級別和測試型別，都應該定義入口準則和出口準則，並根據測試目標而有所不同。
典型的入口準則包括：
• 可測試的需求、使用者故事和/或模型(例如：在採用基於模型的測試策略時)的可用性
• 已滿足上乙個測試級別出口準則的測試項的可用性
• 測試環境的可用性
• 所需測試工具的可用性
• 測試資料和其他必要資源的可用性
典型的出口準則包括：
• 完成已計畫測試的執行
• 已達到規定的覆蓋率(如需求、使用者故事、驗收準則、風險、**)
• 未解決的缺陷數目在商定的範圍內
• 估計剩餘的缺陷數量足夠低
• 對可靠性、效能效率、易用性、安全性和其他相關質量特性的評估得到的級別，已經滿足要求
即使沒有滿足出口準則，由於預算超支、計畫完成的時間耗完，和/或產品推向市場的壓力等原因，而減少測試活動也是常見的。如果專案利益相關者干係人和業務負責人所有人已經評審並接受不再進一步測試的風險，此時結束測試是可接受的。
5.2.4 測試執行進度
一旦生成各種測試用例和測試規程（有些測試規程是自動化的）並組成測試套件，測試套件就可以安排在定義了它們執行順序的測試執行進度中。測試執行進度應考慮到諸如優先順序、依賴關係、確認測試、回歸測試以及執行測試的最有效順序等因素。
理想情況下，測試用例應該是按照其優先順序順序進行執行的，通常是先執行優先順序最高的測試用例。但是，如果測試用例具有依賴關係或正在測試的特性之間具有依賴關係，那該實踐會不起作用。如果優先順序較高的測試用例依賴於優先順序較低的測試用例，則必須先執行優先順序較低的測試用例。同樣，如果測試用例之間存在依賴關係，則必須適當地對它們進行排序，而不管它們的相對優先順序如何。確認測試和回歸測試也必須根據變更的快速反饋，進行優先順序排序，但這裡同樣受依賴關係的影響。
在某些情況下，可能存在各種不同的測試順序，不同的順序之間的效率是不同。在這種情況下，必須在測試執行效率與優先順序之間作出平衡。
5.2.5 影響測試工作量的因素
測試工作量估算包括針對特定專案、發布或迭代的測試目標，**與測試相關工作的數量。影響測試工作量的因素包括產品特點、開發過程特點、人員特點和測試結果，如下所示。
產品特點
• 產品相關的風險
• 測試依據的質量
• 產品的規模
• 產品領域的複雜性
• 質量特性需求（例如安全性、可靠性）
• 測試文件所需的詳細程度
• 遵守法律和法規的需求
開發過程特點
• 組織的穩定性和成熟性
• 正在使用的開發模型
• 測試方法
• 使用的工具
• 測試過程
• 時間壓力
人的特點
• 參與人員的技能和經驗，特別是類似專案和產品有關的技能和經驗（如領域知識）
• 團隊凝聚力和領導能力
測試結果
• 發現缺陷的數量和嚴重程度
• 需要的返工量
5.2.6 測試估算技術
有許多估計技術用於確定充分測試所需的工作量。最常用的兩種技術是：
• 基於度量的技術：根據以前類似專案的度量，或根據典型值估算測試工作量
• 基於專家的技術：根據測試任務責任人或專家的經驗估算測試工作量
例如，例如：在敏捷開發中，當工作量被收集捕獲和報告時，燃盡圖可以作為基於度量的方法的例子，然後將其作為團隊速度的輸入，以確定團隊在下一次迭代中能做的工作數量；而計畫撲克是基於專家的方法的乙個例子，因為團隊成員正是根據他們的經驗來估計提供乙個功能所需的工作量（istqb-at基礎級別敏捷測試擴充套件大綱）。
在順序開發模型的專案中，缺陷移除模型是基於度量的方法的例子，其中捕獲和報告了大量缺陷以及移除缺陷的時間，從而為估算未來類似性質的專案提供了基礎；而寬頻德爾菲估算技術是基於專家的方法的乙個例子，其中專家小組根據他們的經驗提供了估算結果（istqb-atm高階測試經理大綱）。
csp s模擬測試52
標籤 平均數處理 查單點上的區間操作 期望得分 40 40 40 實際得分 40 40 40 打了三個暴力 查詢第k小的連續子串行平均值。二分，很妙 二分平均值x，所有數減去x，做字首和，平均值比x小的區間 l,r 有 sum r sum 0 sum的逆序對數即是x在所有區間裡的排名。由於實數域，歸...
《軟體測試52講》 效能測試篇
軟體測試52講 1 測試基礎知識篇 0 11講 2 gui自動化測試篇 12 21講 3 api自動化測試篇 22 24講 4 測試篇 25 27講 5 效能測試篇 28 34講 6 測試資料準備篇 35 38講 7 測試基礎架構篇 39 42講 8 測試新技術篇 43 47講 9 測試人員的網際網...
5 2 更多的條件測試
你並非只能建立10個測試。如果你想嘗試做更多的比較，可再編寫一些測試，並將它們加入到conditional tests.py中。對於下面列出的各種測試，至少編寫乙個結果為true和false的測試。檢查兩個字串相等和不等。使用函式lower 測試。檢查兩個數字相等 不等 大於 小於 大於等於和小於等...