Mô hình chữ V trong kiểm thử phần mềm (V Model) còn được gọi là mô hình xác thực hay mô hình xác minh. Nó là mô hình có tính kỷ luật cao, trong đó, giai đoạn kiểm thử chạy song song với mỗi giai đoạn phát triển phần mềm.
Đọc thêm: Các mô hình kiểm thử phần mềm
Mô hình chữ V trong kiểm thử phần mềm là gì?
Mô hình chữ V trong kiểm thử phần mềm còn được gọi là mô hình xác minh (Verification Model) hay mô hình xác thực (Validation Model). Đây là mô hình mở rộng của Waterfall Model (mô hình thác nước).
Không giống như mô hình thác nước, với mô hình V, tương ứng với mỗi giai đoạn phát triển phần mềm là một giai đoạn kiểm thử. Việc kiểm thử trong mô hình chữ V thường được tiến hành ngay từ giai đoạn lấy yêu cầu. Để hiểu rõ hơn về mô hình chữ V trong kiểm thử phần mềm, trước tiên, chúng ta sẽ cùng nhau tìm hiểu về xác minh (verification) và xác nhận hợp lệ (validation) trong phần mềm.
-
Xác minh (verification): Đây là một kỹ thuật phân tích tĩnh trong kiểm thử, nghĩa là, kỹ thuật này được thực hiện mà không cần chạy code. Xác minh bao gồm một số hoạt động như: xem lại (review), kiểm tra (inspection) và kiểm tra từ đầu đến cuối (walkthrough).
-
Xác nhận hợp lệ (validation): Với kỹ thuật này, việc kiểm thử sẽ được thực hiện bằng cách chạy code. Chẳng hạn: kỹ thuật kiểm tra chức năng (function) và phi chức năng (non-function).
Hiện nay, mô hình chữ V trong kiểm thử phần mềm được sử dụng rộng rãi. Với mô hình này, kiểm thử sẽ được thực hiện trong từng giai đoạn, song song với chu kỳ phát triển phần mềm (Software Development Life Cycle).
Đọc thêm: Các phương pháp kiểm thử phần mềm
Nguyên lý hoạt động của V Model
Về cơ bản, mô hình chữ V (V Model) gần giống với mô hình thác nước (Waterfall Model). Cụ thể, cách thực hiện từng giai đoạn của V Model tương tự mô hình thác nước, tức là, mỗi giai đoạn cần được hoàn thiện trước khi bắt đầu giai đoạn tiếp theo.
Trong V Model, các hoạt động phát triển và đảm bảo chất lượng được thực hiện đồng thời. Không có pha rời rạc mà thay vào đó, kiểm thử sẽ được bắt đầu ngay từ giai đoạn lấy yêu cầu. Các hoạt động xác minh và xác nhận được thực hiện song song trong từng giai đoạn.
Trong quá trình phát triển theo V Model, phía bên trái là các hoạt động phát triển phần mềm (phân tích yêu cầu, yêu cầu hệ thống, thiết kế kiến trúc, thiết kế mô-đun, code) và bên phải là các hoạt động kiểm thử (kiểm tra đơn vị, kiểm tra tích hợp, kiểm tra hệ thống).
Các hoạt động phát triển phần mềm
Các hoạt động phát triển phần mềm (bên trái) bao gồm phân tích yêu cầu, yêu cầu hệ thống, thiết kế kiến trúc, thiết kế mô-đun và code. Cụ thể:
-
Phân tích yêu cầu: Các yêu cầu được thu thập, phân tích và nghiên cứu kỹ lưỡng. Trong giai đoạn này, việc hệ thống có những chức năng gì quan trọng hơn hệ thống chạy như thế nào. Brainstorming, interviews cần được thực hiện để có mục tiêu rõ ràng.
-
Hoạt động xác minh: Đánh giá yêu cầu (requirements review)
-
Hoạt động xác nhận: Tạo test case UAT, đầu ra cần có là tài liệu về yêu cầu, UAT test case
Yêu cầu hệ thống: Trong giai đoạn này, yêu cầu hệ thống của phần mềm sẽ được xây dựng. Nhóm sẽ tìm hiểu, nghiên cứu về các yêu cầu có thể được thực hiện. Ngoài ra, tính khả thi về mặt kỹ thuật của yêu cầu, nhu cầu phần cứng/phần mềm và các mô-đun sẽ được tạo cũng được tìm hiểu.
-
Hoạt động xác minh: Đánh giá thiết kế (design reviews)
-
Hoạt động xác nhận: Tạo test plan và test case và traceability metrics
-
Đầu ra cần có: System test plan, feasibility reports, Feasibility report, các mô-đun, tài liệu yêu cầu phần cứng
Thiết kế kiến trúc: Trong giai đoạn này, kiến trúc phần mềm được tạo ra dựa trên thiết kế mức cao. Sơ đồ kiến trúc, bảng cơ sở dữ liệu, các mô-đun, chi tiết về công nghệ, mối quan hệ về sự phụ thuộc sẽ được hoàn tất trong giai đoạn này.
-
Hoạt động xác minh: Đánh giá thiết kế
-
Hoạt động xác nhận: Kế hoạch thử nghiệm tích hợp và các trường hợp thử nghiệm
Đầu ra cần có: Tài liệu thiết kế, kế hoạch kiểm thử tích hợp, các trường hợp thử nghiệm, thiết kế bảng cơ sở dữ liệu,…
Thiết kế mô-đun: Thiết kế mô-đun là thiết kế cấp thấp, theo đó, mỗi mô-đun hay thành phần đều được thiết kế riêng biệt. Các kiểu dữ liệu, giao diện, method, class đều được hoàn thiện trong giai đoạn này.
-
Hoạt động xác minh: Đánh giá thiết kế
-
Hoạt động xác nhận: Tạo và xem xét các trường hợp kiểm tra đơn vị
-
Đầu ra cần có: Các đơn vị kiểm tra
Code: Giai đoạn này cũng bao gồm các hoạt động xác minh, hoạt động xác nhận và đầu ra cần có. Cụ thể:
-
Hoạt động xác minh: Xem xét mã và kiểm tra các trường hợp
-
Hoạt động xác nhận: Tạo các trường hợp kiểm tra chức năng
-
Đầu ra cần có: Tất cả trường hợp kiểm thử và danh sách kiểm tra lại
Các hoạt động kiểm thử phần mềm
Các hoạt động kiểm thử phần mềm (bên phải) hay chính là giai đoạn xác nhận. Chúng ta sẽ bắt đầu phân tích từ dưới lên trên: kiểm tra đơn vị, kiểm tra tích hợp, kiểm tra hệ thống, thử nghiệm chấp nhận của người dùng.
Kiểm tra đơn vị (Unit test): Các đơn vị đã được tạo ra trong giai đoạn thiết kế cấp thấp sẽ được thực hiện ở giai đoạn này. Mỗi đoạn code được viết sẽ có một phương pháp kiểm tra xem đoạn code đó có cho kết quả như mong muốn không.
Kiểm tra đơn vị (Unit test) là một kỹ thuật kiểm thử hộp trắng. Về cơ bản, kiểm tra đơn vị được thực hiện bởi nhóm phát triển. Khi phát hiện bất thường, lỗi sẽ được ghi lại và theo dõi.
Đầu ra cần có: Kết quả thực hiện kiểm thử đơn vị
Kiểm thử tích hợp: Đây là một kỹ thuật mà đơn vị kiểm tra là mô-đun, được tích hợp, xem xét kết quả. Hiểu một cách đơn giản, kiểm thử tích hợp sẽ xác nhận các thành phần của ứng dụng hoạt động với nhau có đúng như mong đợi hay không.
Trong giai đoạn kiểm thử tích hợp (Integration testing), các trường hợp kiểm thử tích hợp đã được tạo ra trong giai đoạn thiết kế kiến trúc. Nếu xuất hiện bất thường, bug sẽ được ghi lại và theo dõi.
Đầu ra cần có: Các kết quả kiểm tra tích hợp
Kiểm tra hệ thống (System testing):
Kiểm thử chức năng và phi chức năng sẽ được thực hiện trong giai đoạn này. Nói theo một cách khác, việc kiểm tra thực tế hoạt động của ứng dụng diễn ra trong giai đoạn kiểm tra hệ thống. Khi tiến hành kiểm tra hệ thống, lỗi được phát hiện và theo dõi để sửa. Trong giai đoạn này, báo cáo tiến độ cũng là một phần quan trọng. Để kiểm tra mức độ bao phủ và giảm bớt rủi ro, ma trận truy vết sẽ được cập nhật.
Đầu ra cần có: Báo cáo tóm tắt kiểm tra, các bản ghi kiểm tra, báo cáo lỗi, ma trận truy vết và kết quả kiểm tra
Thử nghiệm chấp nhận của người dùng: Về cơ bản, thử nghiệm chấp nhận có liên quan đến việc kiểm tra các yêu cầu business. Tại đây, kiểm tra sẽ được thực hiện nhằm xác nhận rằng, các yêu cầu kinh doanh đã được đáp ứng trong môi trường người dùng.
Trong giai đoạn này, thử nghiệm khả năng tương thích sẽ được thực hiện. Đôi khi, thử nghiệm phi chức năng (load, volume, stress) cũng được thực hiện trong thử nghiệm chấp nhận của người dùng.
Đầu ra cần có: Kết quả UAT, ma trận độ bao phủ business được cập nhật
Ví dụ về V Model - mô hình chữ V trong kiểm thử phần mềm
Chẳng hạn, bạn được giao nhiệm vụ phát triển phần mềm cho khách hàng. Chúng ta sẽ không nhắc đến nền tảng kỹ thuật mà sẽ đưa ra giả thiết về các bước thực hiện để hoàn thành nhiệm vụ.
|
Các giai đoạn trong chu kỳ phát triển phần mềm
|
Các hoạt động được thực hiện trong từng giai đoạn
|
|
Thu thập yêu cầu
|
Thu thập thông tin chi tiết, thông số kỹ thuật của phần mềm, mong muốn của khách hàng
|
|
Thiết kế hệ thống
|
Lên kế hoạch lựa chọn cơ sở dữ liệu (MySQL, Oracle,…) và ngôn ngữ lập trình (PHP, Java,…)
|
|
Giai đoạn xây dựng
|
Giai đoạn này sẽ triển khai thực hiện mã hóa code
|
|
Giai đoạn kiểm thử
|
Xác minh xem nó được xây dựng đúng theo thông số kỹ thuật được cung cấp bởi khách hàng hay không
|
|
Giai đoạn triển khai
|
Triển khai ứng dụng, phần mềm trong môi trường thật
|
|
Giai đoạn bảo trì
|
Nâng cấp, bảo trì hoặc thay đổi code theo yêu cầu của khách hàng
|
Đây là các bước của mô hình thác nước trong kiểm thử phần mềm. Với mô hình này, việc kiểm thử sẽ được tiến hành sau khi code xong. Tuy nhiên, khi bạn làm việc trong hệ thống phức tạp, dự án lớn, những chi tiết chính trong giai đoạn lấy yêu cầu có thể bị bỏ qua.
Như vậy, một sản phẩm kém chất lượng sẽ được bàn giao cho khách hàng. Bạn có thể phải thực hiện lại từ đầu để có thỏa mãn yêu cầu của khách hàng. Hoặc khi bạn quản lý các yêu cầu một cách chính xác nhưng xuất hiện lỗi nghiêm trọng trong kiến trúc phần mềm và thiết kế, để sửa lỗi, bạn có thể phải thiết kế lại toàn bộ phần mềm.
Theo đánh giá từ các dự án, 1/2 tổng số lỗi thường được tìm thấy trong các yêu cầu và thiết kế. Bên cạnh đó, chi phí khắc phục lỗi sẽ tăng lên trong suốt vòng đời phát triển phần mềm. V Model xuất hiện và có khả năng khắc phục những vấn đề của mô hình thác nước. Với mô hình V Model, mỗi giai đoạn phát triển tương ứng với một giai đoạn kiểm thử:
-
Toàn bộ mô hình giống như chữ V, cho nên được gọi là V Model
-
Bên trái của mô hình là vòng đời phát triển phần mềm – SDLC
-
Phía bên phải của mô hình là vòng đời kiểm thử phần mềm – STLC
Khi nào áp dụng V Model và cho những dự án như thế nào?
V Model thường được áp dụng khi nhà thầu triển khai dự án có đội ngũ kỹ thuật vững chuyên môn, giàu kinh nghiệm; sẵn nguồn tài nguyên và phong phú, có khả năng đáp ứng yêu cầu, thiết kế, thi công và bàn giao nhanh.
Hiện nay, mô hình chữ V trong kiểm thử phần mềm được sử dụng phổ biến. Mô hình này thường được áp dụng cho những dự án nhỏ và trung bình, trong đó, các yêu cầu của dự án cố định, rõ ràng theo tiêu chuẩn trong nước và quốc tế.
Ưu điểm và nhược điểm khi sử dụng mô hình V
Mô hình chữ V trong kiểm thử phần mềm sở hữu rất nhiều ưu điểm vượt trội. Tuy nhiên, cũng giống như những mô hình kiểm thử phần mềm khác, mô hình chữ V vẫn tồn tại một số nhược điểm nhỏ.
Ưu điểm
-
Đơn giản, thân thiện và tiết kiệm thời gian
-
Có kế hoạch, hoạt động cụ thể cho quá trình kiểm thử
-
Khả năng thành công cao hơn so với mô hình thác nước
-
Phát hiện nhanh sai sót và tìm ra nguyên nhân từ bước đầu
Nhược điểm
-
Còn tồn tại sự cứng nhắc, ít linh hoạt (sau mỗi step phải kiểm tra, xác nhận)
-
Không đáp ứng được yêu cầu dịch vụ là vừa phát triển vừa bán sản phẩm
-
Nếu yêu cầu dự án đơn giản thì việc thực hiện các công đoạn xác minh sẽ tiêu tốn rất nhiều thời gian
-
Phải quay lại các bước đầu tiên, update tài liệu nếu có sự thay đổi về kỹ thuật giữa chừng
-
Sản phẩm của dự án chỉ được ra mắt khi hoàn thành các bước, không có nguyên mẫu ngay từ ban đầu
Tham khảo: Khóa học kiểm thử phần mềm tại NIIT
Kết luận: Mô hình chữ V trong kiểm thử phần mềm (V Model) giúp khắc phục những hạn chế lớn nhất của mô hình thác nước. Mô hình này phù hợp với những dự án nhỏ, trung bình và được áp dụng khi nhà thầu triển khai dự án có đội ngũ kỹ thuật giỏi cùng nguồn tài nguyên phong phú.
Đọc thêm các bài viết liên quan khác: