Kiểm thử phần mềm: Các mô hình phát triển phần mềm.

Tiếp tục series tóm tắt từ cuốn sách: FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION của tác giả Dorothy Graham, Erik van Veenendaal, Isabel Evans và Rex Black và một số kinh nghiệm của cá nhân trong quá trình làm việc nhằm cung cấp cho các bạn một cái nhìn tổng quan về kiểm thử phần mềm và các kiến thức cơ bản về kiểm thử, các kỹ thuật dùng trong kiểm thử và các công cụ hỗ trợ.

Để tiếp nối nội dung từ bài viết Kiểm thử phần mềm: Các nguyên tắc cơ bản (Phần 2), trong bài viết lần này, mình sẽ giới thiệu Các mô hình phát triển phần mềm (Software Development Models).

1. Mô hình thác nước (Waterfall model).

Phân tích mô hình:

• Requirement gathering: Thu thập và phân tích yêu cầu được ghi lại vào tài liệu đặc tả yêu cầu trong giai đoạn này.
• System Analysis: Phân tích thiết kế hệ thống phần mềm, xác định kiến trúc hệ thống tổng thể của phần mềm.
• Coding: Hệ thống được phát triển theo từng unit và được tích hợp trong giai đoạn tiếp theo. Mỗi Unit được phát triển và kiểm thử bởi dev được gọi là Unit Test.
• Testing: Cài đặt và kiểm thử phần mềm. Công việc chính của giai đoạn này là kiểm tra và sửa tất cả những lỗi tìm được sao cho phần mềm hoạt động chính xác và đúng theo tài liệu đặc tả yêu cầu.
• Implementation: Triển khai hệ thống trong môi trường khách hàng và đưa ra thị trường.
• Operations and Maintenance: Bảo trì hệ thống khi có bất kỳ thay đổi nào từ phía khách hàng, người sử dụng.

Ưu điểm:

• Dễ sử dụng, dễ tiếp cận, dễ quản lý.
• Sản phẩm phát triển theo các giai đoạn được xác định rõ ràng.
• Xác nhận ở từng giai đoạn, đảm bảo phát hiện sớm các lỗi.

Nhược điểm:

• Ít linh hoạt, phạm vi điều chỉnh hạn chế.
• Rất khó để đo lường sự phát triển trong từng giai đoạn.
• Mô hình không thích hợp với những dự án dài, đang diễn ra, hay những dự án phức tạp, có nhiều thay đổi về yêu cầu trong vòng đời phát triển.
• Khó quay lại khi giai đoạn nào đó đã kết thúc.

2. Mô hình chữ V (V-model).

V-model là một framework để mô tả các hoạt động vòng đời phát triển phần mềm từ các yêu cầu đặc tả đến bảo trì. Mô hình chữ V minh họa các hoạt động kiểm thử (xác nhận và phê duyệt) có thể được tích hợp vào từng giai đoạn của vòng đời phát triển phần mềm như thế nào, kiểm thử xác nhận diễn ra đặc biệt trong giai đoạn đầu.

Mô hình chữ V có 4 mức độ kiểm thử:

• Kiểm thử thành phần ( Component testing ).
• Kiểm thử tích hợp (integration testing ).
• Kiểm thử hệ thống (system testing).
• Kiểm thử chấp nhận ( acceptance testing).
• Ưu điểm.
  • Đơn giản dễ sử dụng.
  • Có hoạt động, kế hoạch cụ thể cho quá trình test.
  • Tiết kiệm được thời gian, và có cơ hội thành công cao hơn waterfall.
  • Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bước đầu.
• Nhược điểm:
  • Khó quản lý kiểm soát rủi ro, rủi ro cao.
  • Không phải là một mô hình tốt cho các dự án phức tạp và hướng đối tượng.
  • Mô hình hoạt động không hiệu quả đối với các dự án dài và đang diễn ra.
  • Không thích hợp cho các dự án có nguy cơ thay đổi yêu cầu trung bình đến cao.

3. Các Chu trình lặp(Iterative life cycles )

Ở mô hình này các quá trình thực hiện được lặp đi lặp lại theo từng giai đoạn, những giai đoạn sau sẽ là cơ sở để hỗ trợ hoàn thiện chức năng được xây dựng từ các giai đoạn trước. Vào cuối mỗi lần lặp của mô hình sẽ tạo ra một phiên bản mới của phần mềm theo đó kiểm thử sẽ phải kiểm thử chức năng mới, kiểm thử hồi quy, kiểm thử tích hợp.
Ưu điểm:

• Xây dựng và hoàn thiện sản phẩm theo từng bước.
• Thời gian làm tài liệu sẽ ít hơn so với thời gian thiết kế.
• Một số chức năng làm việc có thể được phát triển nhanh chóng và sớm trong vòng đời.
• Ít tốn kém hơn khi thay đổi phạm vi, yêu cầu.
• Dễ quản lý rủi ro.
• Trong suốt vòng đời, phần mềm được sản xuất sớm để tạo điều kiện cho khách hàng đánh giá và phản hồi.

Nhược điểm:

• Yếu cầu tài nguyên nhiều.
• Các vấn đề về thiết kế hoặc kiến trúc hệ thống có thể phát sinh bất cứ lúc nào.
• Yêu cầu quản lý phức tạp hơn.
• Tiến độ của dự án phụ thuộc nhiều vào giai đoạn phân tích rủi ro.

4. Mô hình gia tăng (Incremental model)

Mô hình gia tăng là sự kết hợp của 1 hoặc nhiều mô hình thác nước. Trong mô hình này các yêu cầu được chia thành nhiều mô đun và mỗi mô đun được phát triển riêng biệt, cuối cùng tích hợp các mô đun đã phát triển trở thành một hệ thống hoàn chỉnh.

Ưu điểm:

• Phát triển nhanh chóng, sau khi hoàn thành 1 mô đun là có thể chuyển giao cho khách hàng.
• Mô hình này linh hoạt hơn, ít tốn kém hơn khi thay đổi phạm vi và yêu cầu.
• Dễ dàng hơn trong việc kiểm tra và sửa lỗi.

Nhược điểm:

• Cần lập kế hoạch và thiết kế tốt.
• Tổng chi phí là cao hơn so với mô hình thác nước.

5. Mô hình RAD (Rapid Application Development)

Mô hình RAD là một phương pháp phát triển phần mềm sử dụng quy hoạch tối thiểu có lợi cho việc tạo mẫu nhanh. Các mô đun chức năng được phát triển song song và được tích hợp để tạo ra sản phẩm hoàn chỉnh để phân phối sản phẩm nhanh hơn.

Ưu điểm:

• Cho phép xác định sớm rủi ro công nghệ.
• Đáp ứng nhanh chóng với sự thay đổi yêu cầu của khách hàng.
• Giảm được thời gian phát triển của sản phẩm.
• Sớm đưa ra được những đánh giá, nhận xét, phản hồi từ khách hàng nên dễ dàng điều chỉnh.

Nhược điểm:

• Chỉ áp dụng mô hình RAD khi dự án có thời gian gấp rút từ 2 đến 3 tháng.
• Chỉ được sử dụng khi thiết kế có sẵn các module.
• Các yêu cầu dự án rõ ràng.
• Có đủ nguồn lực cả về công cụ, con người, tài liệu, phần mềm hỗ trợ.
• Tốn chi phí khi xây dựng nhiều team phát triển song song.

6. Mô hình Agile.

Mô hình Agile phát triển dựa vào mô hình lặp (Iterative life cycles) và gia tăng (Incremental model)tập trung vào khả năng thích ứng của quy trình và sự hài lòng của khách hàng bằng cách phân phối nhanh sản phẩm phần mềm.
Trong mô hình này:

• Hệ thống được chia thành các mô đun nhỏ, mỗi lần lặp liên quan đến các quy trình: lập kế hoạch, phân tích yêu cầu, thiết kế, code, kiểm thử.
• Vào cuối mỗi vòng lặp sẽ hoàn thành được một module hoặc chức năng và có thể đưa cho khách hàng đánh giá và phản hồi.

Ưu điểm:

• Đạt được sự hài lòng của khách hàng bằng cách bàn giao nhanh chóng, liên tục các sản phẩm phần mềm có ích.
• Con người và tương tác được nhấn mạnh hơn là quá trình và công cụ. Khách hàng, nhà phát triển và người thử nghiệm liên tục trao đổi với nhau.
• Sản phẩm làm việc được bàn giao thường xuyên (vài tuần chứ không phải vài tháng).
• Cuộc đối thoại trực tiếp (face-to-face) là hình thức giao tiếp tốt nhất.
• Gần gũi với nhau hơn, hợp tác hàng ngày giữa các khách hàng và các lập trình viên.
• Chú ý liên tục về kỹ thuật và bản thiết kế tốt.
• Thường xuyên thích nghi với hoàn cảnh thay đổi.
• Ngay cả những thay đổi muộn trong yêu cầu cũng được hoan nghênh.

Nhược điểm:

• Không thích hợp để xử lý các phụ thuộc phức tạp.
• Có nhiều rủi ro về tính bền vững, khả năng bảo trì và khả năng mở rộng.
• Cần một team có kinh nghiệm.
• Phụ thuộc rất nhiều vào sự tương tác rõ ràng của khách hàng.
• Chuyển giao công nghệ cho các thành viên mới trong nhóm có thể khá khó khăn do thiếu tài liệu.

Kết thúc phần này, các bạn có thể hiểu được các mô hình được sử dụng trong một vòng đời phát triển của phần mềm, ưu điểm, nhược điểm và phạm vi áp dụng của từng mô hình.

Sang bài viết tiếp theo mình sẽ giới thiệu 4 mức kiểm thử: kiểm thử thành phần, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận.
Link bài viết tiếp theo Kiểm thử phần mềm: Các mức kiểm thử (Test levels)