上下文驅動測試
原則
語境驅動的學校的七個基本原則
- 任何實踐的價值取決於其背景。
- 在上下文中有良好實踐，但沒有最佳實踐。
- 人們一起工作是任何專案背景中最重要的部分。
- 隨著時間的推移專案以往往無法預測的方式展開。
- 該產品是一種解決方案。如果問題仍未解決，則產品不起作用。
- 良好的軟體測試是具有挑戰性的智慧過程
- 只有通過在整個專案中協同行使的判斷和技巧，我們才能在合適的時間做正確的事情來有效地測試我們的產品。
行動原則的插圖
- 存在測試組以提供與測試相關的服務。他們沒有經營開發專案; 他們為專案服務。
- 代表利益相關者進行測試，以開發，驗證，除錯，調查或銷售產品。完全不同的測試策略可能適合這些不同的目標。
- 對於不同的測試組來說，完成不同的任務是完全正確的。為一項任務服務的核心做法可能與另一項任務的服務無關或適得其反。
- 無效的度量標準是危險的。
- 任何測試案例的基本價值在於其提供資訊的能力（即減少不確定性）。
- 所有的神諭都是錯誤的。即使產品似乎通過了您的測試，也可能以您（或自動測試程式）未監控的方式使其失敗。
- 自動化測試不是自動手動測試：談論自動化測試就好像是自動人體測試一樣毫無意義。
- 不同型別的測試將揭示不同型別的缺陷 - 隨著程式變得更加穩定，測試應該變得更具挑戰性或應該關注不同的風險。
- 測試工件在滿足其利益相關者的相關要求的程度上是值得的。
一個例子：
考慮兩個專案：
- 一個是開發飛機的控制軟體。“正確行為”意味著什麼是高度技術性和數學性的主題。必須遵守FAA規定。你做或不做的任何事情都將成為20年後訴訟中的證據。開發人員共享工程文化，重視謹慎，精確，可重複性，並仔細檢查每個人的工作。
- 另一個專案是開發一個將在網路上使用的文書處理器。“正確的行為”是微軟Word使用者對您的軟體的巨大和不明智的觀眾。沒有重要的監管要求（管理公開發行股票的除外）。上市時間問題 - 從現在起20個月，無論好壞，都將結束。開發人員顯然不是來自工程文化，並試圖以正常的方式談論第一種文化，這會使他們稱之為“傷害被繞過”。
- 適合第一個專案的測試實踐將在第二個專案中失敗。
- 適用於第二個專案的做法在第一個專案中將是犯罪疏忽。
來自Cem Kaner，James Bach和Bret Pettichord，軟體測試方面的經驗教訓 。
評論
自從我們首次釋出上述描述以來，有些人發現我們的定義過於複雜，並試圖將其簡化，試圖將方法與敏捷開發或敏捷測試等同，或者與軟體測試的探索風格等同。這是定義中的另一個裂縫：
上下文驅動的測試人員首先檢視具體情況的詳細資訊，包括委託測試的利益相關者的願望，選擇他們的測試目標，技術和可交付成果（包括測試文件）。上下文驅動測試的本質是專案適當的技能和判斷應用。上下文驅動的測試學院將這種方法置於人文社會和道德框架內進行測試。
最終，上下文驅動的測試就是盡我們所能，盡我們所能。我們不是試圖應用“ 最佳實踐 ”，而是接受非常不同的實踐（甚至****是常見測試術語的****不同定義 ）在不同情況下最有效。
對比上下文驅動 與上下文感知 測試。
許多測試人員認為他們的方法是上下文驅動的，因為他們在工作時會考慮上下文因素。以下是一些可能說明上下文驅動和上下文感知之間差異的示例：
- 上下文驅動的測試人員拒絕最佳實踐的概念，因為他們提供了適當的獨立於上下文的某些實踐。當然，人們普遍認為，在某些情況下，任何“最佳做法”都可能不適用。然而，當有人首先考慮最佳實踐並且首先考慮專案特定因素時，這可能是上下文感知的 ，但不是上下文驅動的 。
- 類似地，有些人建立標準，例如用於測試文件的IEEE標準829，因為他們認為有一個標準來規定通常正確的事情是有用的。這不是不尋常的，也不是聲名狼借的，但它不是由上下文驅動的。標準829始於 良好文件的願景，並鼓勵測試人員根據利益相關者的需求修改建立的內容。上下文驅動的測試始於 利益相關者的要求以及專案的實際約束和機會。對於上下文驅動的測試人員，該標準提供了實現級別的建議而不是處方。
對比上下文驅動 與上下文不注意 ，特定 於上下文 和上下文帝國 測試。
說“上下文驅動”是為了區分我們的測試方法與上下文不注意，特定於上下文或上下文帝國的方法：
- 在不考慮測試實踐和測試問題之間的匹配的情況下完成上下文不經意的測試。這在剛剛學習手藝的測試人員中很常見，或者只是複製他們看到其他測試人員所做的事情。
- 特定於上下文的測試應用針對特定設定或問題進行優化的方法，在上下文發生更改時無需進行調整。這在具有長期專案和團隊的組織中很常見，其中測試人員可能沒有在多個組織中工作。例如，一個測試組可能會開發軍事軟體的專業知識，另一個團隊開發遊戲。在特定情況下，特定於上下文的測試人員和上下文驅動的測試人員可能以完全相同的方式測試他們的軟體。但是，特定於上下文的測試人員只知道如何在她或他的一個開發環境（MilSpec）（或遊戲）中工作，並且他/她不知道在各種情況下熟練測試的程度會有所不同。
- Context-imperial測試堅持改變專案或業務，以適應測試人員自己的“最佳”或“專業”實踐的標準化概念，而不是設計或調整實踐以適應專案。上下文帝國方法在知識主要來自閱讀書籍，或者其實踐經驗是針對具體情況的，或者試圖吸引市場的顧問中很常見，這些市場認為其發展方法是一種真正的方式。
對比上下文驅動 的敏捷 測試。
敏捷開發模型倡導客戶響應，浪費最小化，人性化的軟體開發方法，以及上下文驅動的測試。但是，上下文驅動的測試本身並不是敏捷開發運動的一部分。
- 例如，敏捷開發通常主張廣泛使用單元測試。上下文驅動的測試人員將修改他們測試的方式，如果他們知道單元測試已經完成。許多（可能是大多數）上下文驅動的測試人員會建議將單元測試作為一種方法，使以後的系統測試更加高效。但是，如果開發團隊沒有建立可重用的測試套件，那麼上下文驅動的測試人員將建議不期望或依賴於成功的單元測試的測試方法。
- 同樣，敏捷開發人員通常會建議使用漸進式或螺旋式生命週期模型，並根據需要開發最少的文件。許多（也許是大多數）上下文驅動的測試人員在這個生命週期中工作會特別舒適，但是在瀑布專案中建立廣泛記錄的測試並且預先建立大量文件也同樣受上下文驅動。
最終，上下文驅動的測試就是盡我們所能，盡我們所能。在沒有有效的單元測試的情況下，可能沒有敏捷測試（在敏捷開發社群使用的意義上）這樣的東西，但肯定會有上下文驅動的測試。
對比環境驅動 與標準驅動的 測試。
一些測試人員提倡偏好生命週期模型，青睞組織模型或偏愛文物。例如，考慮V模型，程式設計和測試組之間相互可疑的分離，以及向測試人員提供的所有程式碼都帶有詳細規範的要求。
上下文驅動的測試沒有空間進行這種宣傳。測試人員得到他們得到的東西，熟練的上下文驅動的測試人員必須知道如何應對他們的方式。當然，我們可以而且應該向人們解釋權衡，明確是什麼使我們更有效率和更有效，但最終，我們將測試視為服務於做出更廣泛的專案管理決策的利益相關者。
- 是的，當然 ，有些要求是不合理的，我們應該拒絕它們，例如要求測試人員偽造記錄，對產品或測試做出虛假宣告，或者工作不合理的時間。但這並不意味著每個利益相關者的要求都是不合理的，甚至是一些我們不喜歡的。
- 是的，當然 ，有些要求是荒謬的，因為它們要求不可能，例如評估產品與合同規定的特性的一致性，而無需訪問合同或其規範。但這並不意味著我們不喜歡的每個利益相關者的要求都是荒謬的，或者是不可能的。
- 是的，當然 ，如果我們的任務是評估產品與其規格的一致性，我們需要一個規範。但這並不意味著我們總是需要規格，或者我們堅持接受它們總是合適的（甚至通常是合適的）。
總有約束。其中一些是實用的，另一些是道德的。但在這些限制條件下，我們從專案的需求開始，而不是從我們的流程偏好開始。
上下文驅動的技術？
上下文驅動的測試是一種方法，而不是一種技術。我們的任務是在這種情況下做最好的測試 - 我們知道的技術越多，在考慮如何應對新情況時我們可以獲得的選擇就越多。
我們需要的一套技術 - 或更好的知識體系 - 不僅僅是一套測試集。在此，我們遵循[Jerry Weinberg的腳步]從頭到尾，我們將軟體開發專案視為一項富有創意的複雜人類活動。要了解如何很好地為專案服務，我們必須瞭解專案，利益相關者和他們的興趣。][我們的許多核心技能來自心理學，經濟學，人種學和其他社會科學。
結束筆記
合理的人可以倡導標準驅動的測試。或者認為測試活動應該常規化，以便將它們委託給應用常規指示的較便宜和技能較低的人。或者認為今天最大的投資回報在於改進與編寫程式碼密切相關的測試實踐。這些都是廣泛支援的觀點。然而，即使他們的支持者強調需要針對特定情況定製這些觀點，這些觀點也反映出來自上下文驅動測試的根本不同的起點。
最後跟大家推薦一個學習資料分享群：672899761，
裡面大牛已經為我們整理好了許多的學習資料，有自動化，介面，效能等等的學習資料！人生是一個逆水行舟的過程，不進則退，咱們一起加油吧！