Lý thuyết Kiểm thử phần mềm: Quy trình & Vòng đời SDLC STLC
Tổng hợp kiến thức về SDLC, STLC, Agile Testing và Unit Test trong phát triển phần mềm. Hướng dẫn chi tiết quy trình đảm bảo chất lượng và kiểm soát lỗi phần mềm.
Kiểm thử phần mềmSDLCSTLCAgile TestingUnit TestQA QC là gìquy trình kiểm thử
Quy Trình và Vòng Đời Kiểm Thử Phần Mềm
1. Tổng quan về Phát triển và Kiểm thử Phần mềm (SDLC & STLC)
1.1. Vòng đời Phát triển Phần mềm (SDLC - Software Development Life Cycle)
SDLC là một quy trình chuẩn hóa có cấu trúc vững chắc được sử dụng bởi ngành công nghiệp phần mềm để thiết kế, phát triển và thử nghiệm các phần mềm chất lượng cao. Mục tiêu cốt lõi của SDLC là tạo ra phần mềm vượt qua sự mong đợi của khách hàng, hoàn thành trong thời gian dự kiến và tối ưu hóa chi phí đầu tư ban đầu.
Giai đoạn 1: Thu thập và Phân tích Yêu cầu
- Đây là giai đoạn quan trọng nhất mang tính chất nền tảng cho toàn bộ dự án.
- Được thực hiện bởi các thành viên cấp cao (Senior members), Chuyên viên phân tích nghiệp vụ (Business Analysts) và Chuyên gia tên miền (Domain Experts).
- Thu thập đầu vào chi tiết từ khách hàng, bộ phận bán hàng, chuyên gia thị trường và các bên liên quan (Stakeholders).
- Tiến hành nghiên cứu tính khả thi về mặt kỹ thuật, hoạt động và tài chính (Feasibility Study).
- Kết quả trả về là Tài liệu Đặc tả Yêu cầu Phần mềm (SRS - Software Requirement Specification).
Giai đoạn 2: Thiết kế Hệ thống
- Dựa trên tài liệu SRS đã được phê duyệt ở giai đoạn trước để tạo ra kiến trúc hệ thống.
- Đề xuất nhiều hơn một phương pháp thiết kế kiến trúc và ghi lại trong Tài liệu Đặc tả Thiết kế (DDS - Design Document Specification).
- Thiết kế bao gồm hai mức độ: Thiết kế Cấp cao (High-Level Design - HLD) mô tả kiến trúc tổng thể, và Thiết kế Cấp thấp (Low-Level Design - LLD) mô tả logic chi tiết của từng module.
- Đánh giá rủi ro, tính mạnh mẽ của sản phẩm, mô-đun hóa thiết kế, và các ràng buộc về ngân sách, thời gian.
Giai đoạn 3: Viết mã nguồn (Coding/Implementation)
- Bắt đầu quá trình phát triển thực tế, sản phẩm được xây dựng bằng cách dịch thiết kế thành mã nguồn có thể thực thi.
- Lập trình viên tuân thủ nghiêm ngặt các hướng dẫn lập trình (Coding Guidelines) do tổ chức quy định.
- Sử dụng các công cụ lập trình, trình biên dịch, trình thông dịch, và trình gỡ lỗi theo ngôn ngữ được chọn (C, C++, Java, Python, v.v.).
- Đây thường là giai đoạn tốn nhiều thời gian nhất và đòi hỏi sự tập trung cao độ của đội ngũ phát triển (Dev Team).
Giai đoạn 4: Kiểm thử Phần mềm (Testing)
- Giai đoạn phát hiện lỗi, khi phần mềm được triển khai trên môi trường thử nghiệm (Testing Environment).
- Đội ngũ QA/QC thực hiện tìm kiếm các khiếm khuyết, lỗi (Bugs/Defects) bằng cách đối chiếu với tài liệu SRS ban đầu.
- Kiểm thử sinh ra một chu trình lặp lại: Báo cáo lỗi -> Sửa lỗi -> Kiểm thử lại (Retesting) -> Kiểm thử hồi quy (Regression Testing) cho đến khi sản phẩm đạt chất lượng theo tiêu chuẩn.
Giai đoạn 5: Triển khai (Deployment)
- Khi sản phẩm phần mềm đã vượt qua quá trình kiểm thử nghiêm ngặt, nó sẽ được phát hành chính thức.
- Triển khai có thể diễn ra theo từng giai đoạn (Phased Deployment) tùy thuộc vào chiến lược kinh doanh của công ty.
- Bao gồm việc kiểm thử chấp nhận người dùng (UAT - User Acceptance Testing) trong môi trường thực tế bởi chính người dùng cuối hoặc khách hàng đại diện.
Giai đoạn 6: Bảo trì (Maintenance)
- Sau khi hệ thống được người dùng đưa vào sử dụng thực tế, các vấn đề phát sinh sẽ bắt đầu xuất hiện.
- Giai đoạn này tập trung vào ba nhiệm vụ cốt lõi: Sửa lỗi (Fix bugs chưa phát hiện ra), Nâng cấp (Upgrade phiên bản mới), và Cải tiến (Enhancement thêm tính năng mới).
- Đảm bảo hệ thống luôn hoạt động ổn định và thích ứng với môi trường công nghệ liên tục thay đổi.
1.2. Vòng đời Kiểm thử Phần mềm (STLC - Software Testing Life Cycle)
Nếu SDLC là vòng đời để xây dựng phần mềm, thì STLC là một tập hợp các bước được thực hiện một cách tuần tự và có phương pháp cụ thể nhằm đảm bảo mục tiêu chất lượng của phần mềm. STLC là một phần con nằm trọn trong giai đoạn "Kiểm thử" của SDLC.
Bước 1
Phân tích Yêu cầu
(Requirement Analysis)
Đội ngũ Kiểm thử (QA Team) tiến hành nghiên cứu sâu sắc các tài liệu yêu cầu từ góc độ kiểm thử.
- Xác định các loại hình kiểm thử sẽ được thực hiện (Kiểm thử chức năng, Kiểm thử hiệu năng, Kiểm thử bảo mật...).
- Tương tác liên tục với Khách hàng, Chuyên viên BA, và Quản lý kỹ thuật để giải quyết các thắc mắc và hiểu rõ những chi tiết mơ hồ.
- Xác định tính khả thi của việc tự động hóa kiểm thử (Automation Feasibility).
- Đầu ra (Deliverables): Tài liệu Ma trận truy xuất nguồn gốc (RTM) và Báo cáo tính khả thi của tự động hóa.
Bước 2
Lập kế hoạch Kiểm thử
(Test Planning)
Giai đoạn này còn được gọi là Lập chiến lược kiểm thử (Test Strategy). Người quản lý QA (QA Manager) sẽ chịu trách nhiệm chính.
- Ước lượng nỗ lực kiểm thử (Test Effort Estimation) và xác định chi phí dự án.
- Chuẩn bị Kế hoạch kiểm thử (Test Plan document), lựa chọn công cụ phù hợp.
- Xác định nguồn nhân lực (Resource Planning), phân công vai trò và trách nhiệm.
- Lên kế hoạch đào tạo nếu có công nghệ hoặc công cụ mới được áp dụng.
- Đầu ra (Deliverables): Tài liệu Test Plan, Tài liệu Test Strategy, Ước tính nỗ lực.
Bước 3
Phát triển Kịch bản
(Test Case Development)
Bắt đầu ngay sau khi Kế hoạch kiểm thử được hoàn thành và phê duyệt. Tập trung vào việc chi tiết hóa các bước kiểm thử.
- Viết các Test Case chi tiết bao gồm: Tiền điều kiện, các bước thực hiện, dữ liệu test, kết quả mong đợi.
- Viết kịch bản tự động hóa (Automation Scripts) nếu có yêu cầu tự động.
- Tạo mới, chuẩn bị, và trích xuất Dữ liệu kiểm thử (Test Data) từ môi trường hệ thống.
- Review chéo (Peer review) các Test Case bởi các thành viên trong đội để đảm bảo độ bao phủ 100%.
- Đầu ra (Deliverables): Bộ Test Cases, Automation Scripts, Test Data.
Bước 4
Thiết lập Môi trường
(Environment Setup)
Môi trường kiểm thử quyết định phần mềm sẽ được thử nghiệm trong điều kiện cơ sở hạ tầng (phần cứng/phần mềm) nào. Bước này có thể thực hiện song song với bước 3.
- Cấu hình kiến trúc phần cứng, cài đặt hệ điều hành, trình duyệt web tương ứng.
- Khởi tạo cơ sở dữ liệu, thiết lập hệ thống mạng.
- Thực hiện Smoke Test sơ bộ trên môi trường mới để đảm bảo việc triển khai build thành công và môi trường đã sẵn sàng.
- Đầu ra (Deliverables): Môi trường đã sẵn sàng tích hợp với Test Data, Báo cáo kết quả Smoke Test.
Bước 5
Thực thi Kiểm thử
(Test Execution)
Thực hiện các Test Case dựa trên Kế hoạch Kiểm thử và Môi trường đã chuẩn bị. Đội ngũ QA tiến hành tương tác thực tế với phần mềm.
- Thực thi đánh dấu các trạng thái: Pass (Đạt), Fail (Thất bại), Blocked (Bị chặn), Not Run (Chưa chạy).
- Ghi nhận và Báo cáo lỗi (Defect Logging) đối với các trường hợp Fail cho Đội phát triển (Dev) thông qua công cụ quản lý lỗi (Jira, Bugzilla...).
- Map các lỗi này ngược lại với Test Case trong tài liệu RTM.
- Thực hiện Retest sau khi Dev thông báo đã sửa lỗi.
- Đầu ra (Deliverables): Báo cáo thực thi Test Case, Báo cáo lỗi (Defect Reports).
Bước 6
Đóng chu trình
(Test Cycle Closure)
Giai đoạn tổng kết cuối cùng, phân tích hiệu suất và đúc rút kinh nghiệm sau toàn bộ quá trình thử nghiệm.
- Đánh giá các tiêu chí hoàn thành kiểm thử (Test completion criteria) dựa trên độ phủ sóng, chất lượng, chi phí, thời gian và mục tiêu kinh doanh.
- Chuẩn bị số liệu đo lường chất lượng phần mềm (Test Metrics). Ví dụ tính toán Mật độ lỗi để đánh giá độ ổn định.
- Đầu ra (Deliverables): Báo cáo đóng kiểm thử (Test Closure Report), Các chỉ số Metrics rút ra để cải thiện quy trình cho tương lai.
1.3. Mối quan hệ giữa SDLC và STLC
SDLC và STLC có sự liên kết chặt chẽ và hoạt động song song. Việc hiểu rõ mối tương quan này giúp dự án vận hành mượt mà.
2. Đảm bảo Chất lượng (QA) và Kiểm thử Phần mềm (Testing/QC)
Trong ngành công nghiệp phần mềm, các thuật ngữ Đảm bảo chất lượng (QA), Kiểm soát chất lượng (QC) và Kiểm thử (Testing) thường bị nhầm lẫn. Cần phân định rõ các khái niệm này để tối ưu hóa quy trình quản lý chất lượng.
QA (Đảm bảo chất lượng)
Phòng ngừa lỗi (Defect Prevention)
- Bản chất: Là các hoạt động định hướng vào Quá trình (Process-oriented).
- Mục tiêu: Ngăn chặn lỗi xảy ra bằng cách thiết lập và cải tiến các quy trình phát triển, phương pháp luận tiêu chuẩn.
- Phạm vi: Bao trùm toàn bộ Vòng đời phát triển phần mềm (SDLC). Bắt đầu từ lúc lấy yêu cầu cho đến khi bảo trì.
- Hoạt động chính: Đánh giá tài liệu, định nghĩa quy trình, Audit (kiểm toán) quy trình, kiểm tra chất lượng đào tạo, phân tích nguyên nhân gốc rễ.
- Trách nhiệm: Là trách nhiệm của toàn bộ các thành viên trong dự án, không chỉ riêng đội ngũ test.
- Công cụ: Checklists, Đánh giá dự án, Tiêu chuẩn chất lượng (ISO, CMMI).
Testing / QC
Phát hiện lỗi (Defect Detection)
- Bản chất: Là các hoạt động định hướng vào Sản phẩm (Product-oriented).
- Mục tiêu: Tìm ra lỗi, khiếm khuyết (bugs) trong phần mềm hiện tại để sửa chữa trước khi giao cho khách hàng.
- Phạm vi: Một tập con cụ thể nằm trong quy trình QA. Bắt đầu sau khi source code đã được sinh ra.
- Hoạt động chính: Viết test case, thiết lập môi trường, thực thi test (manual hoặc automation), báo cáo lỗi.
- Trách nhiệm: Là trách nhiệm chuyên biệt của Đội ngũ Kiểm thử (Testers / Test Engineers).
- Công cụ: Automation tools (Selenium, Appium), Bug tracking tools (Jira, Bugzilla), Performance tools.
Tóm lại: QA đảm bảo rằng bạn đang làm đúng những việc cần làm theo đúng quy trình. Còn Testing/QC đảm bảo rằng kết quả công việc đã làm ra là chính xác và không có lỗi.
3. Kiểm thử trong Mô hình Thác nước (Waterfall)
3.1. Đặc điểm của Kiểm thử Waterfall
Mô hình Thác nước là phương pháp luận SDLC truyền thống và cổ điển nhất. Trong mô hình này, tiến trình được nhìn thấy chảy đều đặn xuống (như một thác nước) thông qua các giai đoạn nối tiếp nhau.
Vai trò của Kiểm thử: Giai đoạn kiểm thử (Testing Phase) chỉ được bắt đầu sau khi giai đoạn lập trình (Coding Phase) đã hoàn tất 100%. Mọi thứ tuân theo một cấu trúc vô cùng cứng nhắc. Đội kiểm thử không can thiệp vào các giai đoạn trước đó.
3.2. Ưu điểm và Nhược điểm
Ưu điểm
- Dễ hiểu và dễ quản lý nhờ cấu trúc tuyến tính chặt chẽ.
- Phù hợp với các dự án nhỏ có yêu cầu (requirements) cực kỳ rõ ràng, không thay đổi ngay từ đầu.
- Có mốc thời gian (milestones) rõ ràng cho từng giai đoạn kiểm thử.
- Tài liệu được lưu trữ kỹ lưỡng (Heavy documentation), tester mới dễ dàng tham gia bằng cách đọc tài liệu.
Nhược điểm
- Phát hiện lỗi quá trễ: Do việc test diễn ra cuối cùng, các lỗi liên quan đến yêu cầu hoặc thiết kế (Architecture bugs) khi được phát hiện sẽ tốn chi phí khổng lồ để sửa.
- Không thể phản hồi linh hoạt khi yêu cầu của khách hàng thay đổi giữa chừng.
- Sản phẩm phần mềm thực tế không được tạo ra cho đến chặng cuối cùng của vòng đời, gây rủi ro cao.
- Khó khăn trong việc tích hợp nhiều thành phần phức tạp ở cuối dự án.
4. Kiểm thử trong Mô hình Agile
4.1. Khái niệm và Nguyên tắc
Khác biệt hoàn toàn với Waterfall, Agile Testing là thực tiễn kiểm thử phần mềm tuân theo các nguyên tắc của phát triển phần mềm linh hoạt (Agile). Trong Agile, hoạt động kiểm thử không phải là một giai đoạn tách rời mà là một quá trình liên tục được tích hợp vào mọi chặng của vòng đời phát triển.
Kiểm thử liên tục
Testing diễn ra liên tục song song với Coding trong mỗi Sprint.
Cộng tác chặt chẽ
Tester, Developer và Khách hàng (PO) làm việc trực tiếp hàng ngày.
Phản hồi nhanh
Lỗi được báo cáo và khắc phục ngay lập tức, giảm thiểu kỹ thuật nợ (Tech debt).
4.2. Các Phương pháp Kiểm thử Agile Phổ biến
TDD (Test-Driven Development)
Phát triển hướng kiểm thử.
Trong phương pháp này, Developer (lập trình viên) bắt đầu bằng việc viết một Test Case (Unit Test) tự động trước khi viết bất kỳ dòng code thực tế nào. Ban đầu test case này chắc chắn thất bại (Red). Sau đó họ viết đoạn code vừa đủ để test case đó chạy qua (Green). Cuối cùng là tối ưu hóa mã nguồn (Refactor). Chu trình Red-Green-Refactor giúp mã nguồn an toàn và hạn chế tối đa lỗi từ gốc.
BDD (Behavior-Driven Development)
Phát triển hướng hành vi.
Là phần mở rộng của TDD, nhưng tập trung vào hành vi của hệ thống từ góc độ người dùng kinh doanh. Khuyến khích sự giao tiếp giữa các bên phi kỹ thuật (BA, PO) và kỹ thuật (Dev, QA). Các kịch bản test được viết bằng ngôn ngữ tự nhiên dễ hiểu theo cú pháp: Given (Cho trước hoàn cảnh) - When (Khi có hành động) - Then (Thì kết quả là). Công cụ phổ biến: Cucumber, SpecFlow.
ATDD (Acceptance Test-Driven Development)
Phát triển hướng kiểm thử chấp nhận.
Toàn bộ đội ngũ (Khách hàng, Dev, QA) cùng ngồi lại để định nghĩa rõ ràng các tiêu chí nghiệm thu (Acceptance Criteria) trước khi bắt đầu Sprint. Các tiêu chí này được chuyển đổi thành các bộ kiểm thử chấp nhận tự động. Mã nguồn chỉ được coi là hoàn thành khi nó vượt qua các bài kiểm thử nghiệm thu này. ATDD đảm bảo rằng mọi người đều có chung một hiểu biết về tính năng cần xây dựng.
4.3. Ưu điểm của Agile Testing
- Tiết kiệm thời gian và chi phí so với mô hình lỗi thời, do lỗi được phát hiện và sửa chữa tức thì.
- Sản phẩm luôn ở trạng thái sẵn sàng để phát hành (shippable product).
- Thích ứng linh hoạt: Thay đổi yêu cầu từ khách hàng ở giữa quá trình không còn là thảm họa.
- Hồ sơ tài liệu được tinh gọn (Lightweight documentation), thay vì viết những tài liệu dài dòng, đội ngũ tập trung vào việc tạo ra phần mềm chạy tốt và test case tự động.
5. Unit Testing trong DevOps
DevOps là văn hóa làm việc kết hợp giữa Phát triển phần mềm (Development) và Vận hành công nghệ thông tin (IT Operations) nhằm rút ngắn vòng đời phát triển và cung cấp các bản phát hành liên tục chất lượng cao. Trong môi trường nhịp độ cao này, tự động hóa kiểm thử, đặc biệt là Unit Testing, đóng vai trò sống còn.
5.1. Vai trò của Unit Testing trong DevOps
Unit Testing (Kiểm thử mức Đơn vị) là mức độ kiểm thử thấp nhất, tập trung kiểm tra từng đơn vị mã nguồn nhỏ nhất (như một hàm, một phương thức) một cách riêng biệt.
Trong DevOps, tốc độ là ưu tiên hàng đầu. Nếu hệ thống không có một nền tảng Unit Test vững chắc (có độ bao phủ mã code - code coverage cao), việc đẩy code liên tục lên môi trường sẽ trở thành một rủi ro lớn, dễ gây sập toàn bộ hệ thống. Unit test cung cấp mạng lưới an toàn (safety net) đầu tiên cho lập trình viên.
5.2. Tích hợp liên tục và Kiểm thử liên tục (CI/CD)
Unit Test được kích hoạt hoàn toàn tự động trong đường ống CI/CD (Continuous Integration / Continuous Deployment).
- Mỗi khi Developer đẩy (push/commit) code lên repository chung (như Git).
- Hệ thống CI server (như Jenkins, GitLab CI) sẽ tự động kích hoạt tiến trình Build.
- Ngay lập tức, hàng ngàn Unit Test sẽ chạy độc lập trong vài giây.
- Gatekeeper: Nếu chỉ một Unit Test thất bại, tiến trình Build sẽ bị hủy (Fail Build) lập tức. Code lỗi không thể đi qua các giai đoạn tiếp theo (như Integration Test hay Deployment). Dev buộc phải sửa ngay đoạn mã vừa viết.
5.3. Lợi ích khi áp dụng Unit Test trong quy trình DevOps
Thực thi cực nhanh
Unit Test không phụ thuộc vào database hay network bên ngoài (nhờ sử dụng Mocking), giúp hàng ngàn test case có thể chạy trong vài mili-giây, cung cấp phản hồi tức thời (Fast feedback loop) cho Dev.
Tối ưu chi phí
Việc tìm và sửa lỗi ở cấp độ Unit Test tiêu tốn chi phí và công sức thấp nhất. Lỗi càng bị rò rỉ sang các môi trường sau (QA, UAT, Production) chi phí khắc phục càng tăng theo cấp số nhân.
Cải thiện thiết kế phần mềm
Việc phải viết mã sao cho có thể test được (Testable code) buộc lập trình viên phải thiết kế hệ thống theo hướng chia nhỏ (Modular) và giảm sự phụ thuộc lẫn nhau (Loose coupling).
Sự tự tin khi Refactor
Khi một hệ thống cũ (Legacy) cần được tối ưu lại cấu trúc, bộ Unit Test khổng lồ đóng vai trò là một lớp lá chắn. Dev hoàn toàn tự tin chỉnh sửa mã vì ngay khi họ làm hỏng chức năng cũ, bộ test sẽ báo đỏ lập tức.
2.371 xem 12 kiến thức 5 đề thi
20.991 lượt xem 11/04/2026
21.011 lượt xem 11/04/2026
21.122 lượt xem 11/04/2026
21.100 lượt xem 11/04/2026
20.922 lượt xem 11/04/2026
21.150 lượt xem 11/04/2026
20.945 lượt xem 11/04/2026
21.038 lượt xem 11/04/2026
21.069 lượt xem 11/04/2026
