一級功能測試
業務場景測試
測試用例的優先順序用於標識測試用例的重要性和執行頻率，共分為4級，由高至低依次為p0-p3。
p0核心功能測試用例（冒煙測試），確定此版本是否可測的測試用例，此部分測試用例如果fail會阻礙大部分其他測試用例的驗證。
p1高優先順序測試用例，最常執行以保證功能性是穩定的；基本功能測試，和重要的錯誤、邊界測試
p2中優先順序測試用例，更全面地驗證功能的各個方面，異常測試，邊界、中斷、斷網、容錯、ui等測試用例
p3低優先順序測試用例，不常常被執行，效能、壓力、相容性、穩定性、安全、可用性等等。
1.把所有功能性驗證（或基本路徑）的測試標註為p1；
2.把所有錯誤、邊界值、ui測試標註為p2；
3.把所有非功能性的測試（例如效能、可用性、穩定性、安全、相容等）標註為p3。
並非所有的功能性測試都一樣的重要，並且有些邊界和非功能性測試也很重要。思考一下測試的重要性及相對於其他同等優先順序別的測試，你想要檢查這個功能的頻率，考慮質量目標和專案的需求，可以對case重新調整，規則如下：
1.把功能性驗證測試分為兩組：重要和不是十分重要，將「不是十分重要」的功能性驗證測試降級為p2；
2.把錯誤和邊界測試分成兩組：重要和不是十分重要，將「重要」的錯誤和邊界測試公升級為p1；
3.把非功能性測試分成兩組：重要和不是十分重要，把「重要」的非功能性測試公升級為p2；
4.針對每組高，中和低優先順序別的測試用例，重複劃分和公升級/降級流程直到你達到乙個點，可以在不同優先順序之間移動的測試用例的數量到最小。
注：所謂「重要」，可以理解為：bug多的、使用者使用頻率高的、最基本的這些概念。
為了確保小版本是可以測試的並準備好給小組其他成員執行准入測試，需從高優先順序別的case中挑選出p0 case，規則如下：
1.將高優先順序別的測試用例分成兩組：嚴重的和重要的，將「嚴重」的高優先順序的測試用例公升級為p0級
case優先順序劃分完成後，不同級別所佔百分比為：p0:10%-15%，p1:30%-40%，p2:30%-40%，p3:10%-15%。
另外，隨著專案的進行，通過調研和觀察缺陷出現的位置，你可能會重新給你的測試用例劃分優先級別。
bug優先順序定義
p.p1 p.p2 p.p3 span.s1 span.s2 優先順序定義如下 版本前期階段 功能剛提測 p0 緊急 完全不能滿足產品要求，基本功能明顯未實現或完全不可用，阻塞測試流程與進度 核心功能流程 p1 高 產品的功能實現和需求不符合，沒有達到預期的效果，但不阻塞測試進度 非核心功能流程，不...
執行緒優先順序測試
當可執行狀態的執行緒很多，那麼優先極高的執行緒將會先執行。執行緒的優先順序用1 10之間的整數表示，數值越大優先順序越高，預設的優先順序為5。執行緒還有三個常量，看下面的測試類。下面弄個小例子。1.執行緒類 package com.citi.thread public class threadtes...
STL 優先佇列 定義 優先順序
預設的優先佇列是個極大堆，如果要改變優先佇列中元素的優先順序，有下面這些方法 struct cmp1 struct cmp2 struct node2 int u bool operator const node2 a const return uq1 採用預設優先順序構造佇列 priority q...