資料結構
網路
RDBMS
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝學
法學SDLC vs STLC – 區別是什麼？
軟體開發生命週期 (SDLC) 和軟體測試生命週期 (STLC) 儘管名稱相似，但卻是兩種不同且獨立的方法，用於確保軟體開發專案成功。讓我們瞭解如何充分利用兩者來完成您的軟體開發專案：
什麼是軟體開發生命週期？
軟體開發生命週期 (SDLC) 指的是建立軟體的過程。
根據 Winston Royce 博士於 1970 年發表的一篇研究論文，軟體開發生命週期 (SDLC) 是交付軟體的線性流程式列。該流程如下：
需求收集
一旦發現組織應用程式環境中的差距或機會，就需要充分理解和記錄業務需求，以便選擇最佳解決方案。在此階段，避免立即跳到解決方案的誘惑至關重要，利益相關者可能需要指導和幫助，以保持對任何他們可能已經擁有的解決方案偏好的開放心態。
此時，務必確保當前應用程式不滿足或無法滿足要求。透過收集需求並審查當前應用程式組合，解決方案架構師、業務分析師以及其他具有類似技能的人員可以幫助完成此步驟。
此時，最好聯絡組織中的其他人，看看已識別的或類似的需求是否也在其他領域需要，以避免構建或採購重複的系統並允許系統重用。
此階段的主要成果將是業務需求文件 (BRD)，其中將列出所有必要的函式，可以使用 MoSCoW 方法（必須有/應該有/可以有/現在沒有）進行優先順序排序，並按業務領域進行適當的可追溯性。
設計
在新程式的需求已妥善記錄並批准後，即可開始設計工作。在此階段，企業應考慮其資源是否更好地用於構建自定義系統或購買市場上的產品。可能需要招標流程，例如投標請求 (RFP) 或資訊請求 (RFI)。
一般來說，如果需要高度標準化的功能（例如，工資單、預約安排和電子銷售點），通常最好為這些所謂的“記錄系統”或“區分系統”購買現成的系統。“創新系統”被稱為“創新系統”，當它們具有特定於行業或組織的需求或提供具有競爭優勢的功能時，更有可能適合定製構建。
業務分析師和 UX 設計師可以在設計階段進行協作，以開發系統的線框圖或模型。技術架構師和解決方案設計師可以開始構建系統的架構並做出技術棧、託管和程式語言的決策，同時記住組織的現有技能和供應商。
設計階段的主要輸出因系統而異，但它們可能包括線框圖、系統架構圖、技術棧選擇以及所需資源技能的指示。
構建
在構建階段，軟體開發人員將“需求”和“設計”階段的輸出轉換為可用的軟體。這可能包括建立前端、後端、資料庫、微服務以及各種其他元件。
軟體將被構建以提供需求文件中指定的功能，而最好的專案將在整個階段保持終端使用者的參與，以確保正在構建的內容與最初宣告的需求緊密一致，因為構建的內容有時會偏離此目標。
測試
在測試過程中，測試分析師將對程式執行各種驗證測試，包括效能測試、負載測試和探索性手動測試。主要目標是確保在構建階段完成的工作質量足夠高，能夠承受在正常執行設定下系統將承受的要求，以及弄清楚當這些條件超過時會發生什麼。
使用者驗收測試現在可以開始驗證系統的行為是否符合需求收集階段的既定期望，而構建階段使用者和開發團隊之間的緊密協作有助於最大限度地減少返工並消除意外。
部署
在部署階段，程式被放入所需的生產環境和平臺，將在其中執行。這些環境可以是公司資料中心中的實際伺服器，也可以是越來越流行的雲託管平臺。
預計在此階段開始終端使用者培訓，以確保每個人都瞭解如何使用新系統，並將完成從先前遺留系統的任何資料傳輸，以避免需要“雙重鍵入”。
應該已經開始與將在其“業務照常”狀態下支援和維持系統的團隊進行討論，並且在培訓階段應考慮這些團隊，以確保他們在專案團隊解散後能夠支援該系統。
維護
在維護階段，系統被移交給將在公司剩餘生命週期內支援它的團隊。為了讓服務檯運營商知道如何將使用者支援請求傳送給合適的團隊，需要開發適當的文件和幫助檔案。
隨著時間的推移，可能會對系統進行增強和更改，例如，如果發現新的需求或出現外部因素（例如法規更改），則必須考慮執行此操作的方法，即，是否將保留內部資源來進行此類更改，或者這些更改是否將臨時外包給外部提供商。
檢視我們的帖子，瞭解更多關於軟體開發生命週期以及如何擴充套件它以確保在整個過程中內建安全性的資訊：[實用指南] 安全軟體開發生命週期。
軟體測試生命週期 (STLC)
軟體測試生命週期 (STLC) 是一種方法，用於確保從系統開發開始到結束都實施充分徹底、嚴格的測試。它分為五個階段，如下所示：
需求分析
在需求分析階段，測試團隊審查在 SDLC 需求階段編寫的業務需求文件 (BRD)，以識別新系統所需的重要結果和功能。
測試團隊將與主要利益相關者和業務分析師一起審查 BRD，以確保每個人都瞭解正在建立的內容及其工作方式。他們還應考慮系統的業務關鍵性以及任何適用的法規要求，以確保滿足任何合規性需求。
測試準備
一旦瞭解了功能和後果，測試團隊就能規劃如何實施測試。他們將為專案建立一個測試策略文件，概述他們將如何使用可用的不同技術，包括手動測試、自動化測試、整合測試和單元測試。他們可以開始列出需要編寫的確切測試用例或指令碼，以驗證系統是否經過了徹底測試。
測試開發
在定義了高階測試用例和方法後，就可以開始細化測試指令碼的工作，其中包含更多資訊，例如需要評估的各個使用者體驗，包括積極路徑和邊緣情況。
測試環境搭建
在建立了可行的系統版本後，測試團隊可以開始構建與生產環境和開發環境不同的適當測試環境。在這個測試環境中，他們將確保他們已經建立了正確的使用者配置檔案，具有正確的使用者登入憑據和足夠測試資料來執行他們的指令碼。
測試執行和結束
最後，在建立穩定的環境後，測試團隊執行他們準備的指令碼並將結果報告給專案團隊和利益相關者。隨著專案團隊處理結果然後重新測試，此步驟和其他步驟可能需要多次執行。
SDLC 與 STLC：有什麼區別？
下表突出顯示了 SDLC 和 STLC 之間的重大區別。
| 因素 | SDLC | STLC |
|---|---|---|
| 標題 | 軟體交付生命週期 (Software Delivery Lifecycle, SDLC) 是一個用來描述軟體如何交付的術語。 | 軟體測試生命週期 (Software Testing Life Cycle, STLC) |
| 摘要 | 關注軟體開發 | 關注軟體測試 |
| 目標 | 確保軟體系統構建良好。 | 確保軟體系統經過充分測試。 |
| 階段 | 需求設計、構建、測試、部署和維護 | 分析需求、規劃測試開發、測試執行和環境關閉 |
| 參與人員 | 整個專案團隊 | 測試人員/質量保證工程師 |
| 輸出 | 可使用的軟體系統 | 經過徹底測試的軟體系統 |
結論
總而言之，SDLC 和 STLC 是兩個不同但互補的流程，在開發新系統時都必須考慮。
SDLC 參與新系統的開發，而 STLC 專注於其測試。
SDLC 是一個線性流程，確保您設計和構建正確的系統，而 STLC 是一種允許您徹底測試所開發內容的技術。
雖然 STLC 是一種獨立的測試方法，但這並不排除在 SDLC 中包含質量保證。STLC 並不是優秀設計的替代品，也不是糟糕開發的補救措施；質量應該融入軟體，而不是“測試出來”。
任何成功的新的軟體系統幾乎肯定都會包含 SDLC 和 STLC。
SDLC 以分階段和系統化的方式提供對定義良好的軟體專案的交付。STLC 使這些專案能夠進行徹底的測試，以驗證其效率、可靠性和實用性。
瀏覽量：1K+
