資料結構
網路
關係型資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
時尚研究
法學研究什麼是敏捷測試？（流程、策略、測試計劃、生命週期示例）
什麼是敏捷測試？
敏捷測試是一種遵循敏捷軟體開發規則和概念的測試方法。與瀑布模型不同，敏捷測試可以在專案早期開始，持續整合測試和開發。敏捷測試方法不是按時間順序進行的（即僅在編碼過程之後進行），而是持續進行的。
在本文中，我們將討論：
敏捷測試計劃
敏捷測試策略
敏捷測試象限
敏捷軟體開發中的質量保證挑戰
敏捷流程中自動化的風險
敏捷測試計劃
敏捷測試計劃中包含在該迭代中執行的測試型別，例如測試資料需求、架構、測試環境和測試結果。與瀑布模型相反，敏捷方法包括為每個版本建立和修改的測試計劃。敏捷測試策略通常包括以下內容：
測試範圍
正在測試的新功能
測試級別或型別取決於特性的複雜性
效能和負載測試
基礎設施考慮
風險緩解計劃
獲取資源
里程碑和交付成果
敏捷測試策略
敏捷測試生命週期分為四個階段：
迭代 0
在第一步或迭代 0 中，您進行初始設定任務。這包括查詢測試物件、部署測試工具、安排資源（例如可用性測試實驗室）等等。在迭代 0 中，計劃完成以下步驟。
為專案建立商業案例 b) 定義專案的初始條件和目標
描述將影響設計權衡的必要標準和用例。
描述一種或多種可能的架構。
識別風險
成本估算和試點專案的開發
構建迭代
構建迭代是敏捷測試方法的第二階段，在這個階段進行大部分測試。此階段被視為一系列迭代以構建解決方案增量。為此，團隊在每次迭代中使用來自 XP、Scrum、敏捷建模和敏捷資料等方法的組合。
敏捷團隊在構建迭代期間實施優先順序需求方法——在每次迭代中，他們從工作項堆疊中選擇最重要的剩餘專案並執行它們。
構建迭代有兩種型別：確認測試和調查測試。由團隊進行的確認測試側重於確保系統滿足迄今為止向團隊展示的客戶目標。而調查測試則發現了確認團隊錯過或忽略的問題。在調查測試中，測試人員以錯誤的故事形式識別潛在問題。完整性測試、負載/壓力測試和安全測試是調查測試的示例。
同樣，確認測試也有兩種型別：開發人員測試和敏捷驗收測試。兩者都是自動的，允許在整個生命週期中進行持續測試。確認測試是規範測試的敏捷對應物。
敏捷驗收測試是傳統功能測試和可接受性測試的混合體，因為開發團隊和客戶共同參與其中。開發人員測試將經典單元測試與傳統的服務整合測試相結合。開發人員測試驗證應用程式程式碼和資料庫模式。
釋出收尾或過渡階段
“釋出，收尾”的目的是成功地將您的系統投入執行。此步驟包括諸如終端使用者培訓、支援人員和運營人員等活動。它還包括產品釋出營銷、備份和恢復、系統和使用者文件最終確定。
敏捷方法測試的最後階段包括全面的系統測試和驗收測試。為了在沒有障礙的情況下完成最終測試階段，您必須在構建迭代時更徹底地評估產品。測試人員將在最後階段專注於故障報告。
生產
釋出階段之後，產品將進入生產階段。
敏捷測試象限
敏捷測試象限將整個過程劃分為四個象限，有助於理解敏捷測試是如何進行的。
**敏捷象限 I** – 此區域主要關注內部程式碼質量，它包含旨在幫助團隊的技術驅動型測試用例，包括：
單元測試
元件測試
**敏捷象限 II** – 它包括旨在改進團隊的業務驅動型測試場景。此象限關注需求。在此階段執行的測試型別為：
實驗不同的情況和程式。
使用者體驗測試，例如原型測試
結對測試
**敏捷象限 III** – 此象限將資訊反饋給第一和第二部分。測試用例可以用作自動化測試的基礎。在此象限中執行許多迭代評估週期，從而增強對產品的信任。在此區域執行的測試型別為：
可用性測試
探索性測試
與客戶的結對測試
協作測試
使用者驗收測試
**敏捷象限 IV** – 此象限關注非功能性標準，例如效率、安全性和可靠性等。該應用程式旨在藉助此象限提供非功能性屬性和預期價值。
非功能測試，例如壓力和效能評估。
安全測試，用於識別和駭客攻擊
基礎設施測試
資料遷移測試
可擴充套件性測試
負載測試
敏捷軟體開發中的質量保證挑戰
由於敏捷方法較少重視文件，因此失敗的可能性增加，給質量保證團隊帶來了額外負擔。
升級快速釋出，減少了測試團隊確定當前功能是否符合要求並真正滿足業務需求的時間。
測試人員經常被迫承擔半開發人員的工作。
測試執行時間非常短。
設計測試計劃的時間非常少。
他們將盡可能少地使用時間進行迴歸測試。
將他們的工作從質量守門人轉變為質量夥伴。
在敏捷方法中，需求的變化和修改是不可避免的，這使得質量保證成為最困難的任務。
敏捷流程中自動化的風險
儘管自動化UI提供了高度的保證，但它實施緩慢，管理不穩定，並且開發成本高昂。除非測試人員瞭解如何進行測試，否則自動化可能不會顯著提高測試效率。
不可靠的測試是自動化測試的主要擔憂來源。為了避免誤報，應該高度關注解決失敗的測試和脆弱的測試問題。
如果自動化測試是手動開始的而不是透過 CI（持續整合）開始的，那麼它們實際上永遠不會定期執行，從而導致測試失敗。
自動化測試不應替代探索性手動測試。需要多種測試方法和級別才能達到預期的產品質量。
一些市售的自動化解決方案包括基本功能，例如手動測試用例的自動捕獲和回放。這種技術促進了透過UI進行測試，導致測試固有脆弱且難以管理。此外，將測試用例保留在版本控制系統之外會增加額外的複雜性。
為了節省時間，自動化測試策略經常設計不良或準備不足，導致測試失敗。
在測試自動化過程中，經常忽略測試設定和拆解過程。手動測試、測試設定和拆解過程似乎很簡單。
每天開發或執行的測試用例數量等生產力指標可能極具欺騙性，導致在執行無效測試方面產生巨大支出。
敏捷自動化團隊成員必須是高效的顧問：易於溝通、協作和足智多謀；否則，這個系統將迅速崩潰。
自動化可以提供並提供需要過度持續維護的測試解決方案，而與提供的價值相比。
設計和實施良好解決方案所需的技能在自動化測試中可能缺乏。
自動化測試可能非常有效，以至於它用完了需要解決的關鍵問題，迫使其關注無關緊要的問題。
結論
敏捷軟體測試方法強調在軟體開發生命週期開始時進行測試。它需要廣泛的客戶互動和對程式碼的測試，一旦程式碼公開可用。程式碼應該足夠可靠，可以在系統上進行測試。可以進行廣泛的迴歸測試，以確保所有問題都已修復並經過測試。敏捷模型測試成功的根本原因是團隊之間的互動。
1K+ 次瀏覽
