Tìm hiểu V-Model trong Kiểm thử phần mềm

Giới thiệu V-Model

Trong kiểm thử phần mềm, V-Model (hay mô hình chữ V) là một mô hình dạng SDLC (Software Development Life Cycle) có tính kỷ luật cao, trong đó có một giai đoạn kiểm thử chạy song song với mỗi giai đoạn của phát triển. Mô hình chữ V là một phần mở rộng của mô hình thác nước (Waterfall), trong đó việc kiểm thử được thực hiện trên từng giai đoạn song song với việc phát triển một cách tuần tự. Nó còn được biết đến với tên gọi Validation Model (mô hình xác thực) hoặc Verification Model (mô hình xác minh).

  • Một số Thuật ngữ được dùng trong bài viết:
    1. SDLC (Software Development Life Cycle): còn gọi là vòng đời phát triển phần mềm. Nó là một chuỗi các hoạt động được thực hiện bởi các Developers để thiết kế và phát triển thành một phần mềm chất lượng cao.
    2. STLC (Software Testing Life Cycle): còn gọi là vòng đời kiểm thử phần mềm. Nó bao gồm một loạt các hoạt động do các Testers thực hiện theo phương pháp có sẵn để kiểm thử sản phẩm phần mềm có đáp ứng được yêu cầu đề ra hay không.
    3. Waterfall Model: còn gọi là mô hình thác nước. Nó là một mô hình tuần tự được chia thành các giai đoạn khác nhau của hoạt động phát triển phần mềm. Mỗi giai đoạn được thiết kế để thực hiện một hoạt động cụ thể. Giai đoạn kiểm thử trong mô hình thác nước chỉ bắt đầu sau khi phần mềm đã được phát triển hoàn tất.

Ví dụ giúp hiểu rõ hơn về V-Model

Giả sử, bạn được giao một trách nhiệm là tăng trưởng một ứng dụng tùy biến cho người mua. Không cần quá chăm sóc đến những nền tảng kỹ thuật hay những công nghệ tiên tiến sẽ vận dụng, bạn hãy thử đưa ra Dự kiến có mạng lưới hệ thống về trình tự những bước bạn sẽ làm theo để hoàn thành xong được trách nhiệm này .

Các bước bạn nghĩ ra thông thường sẽ bao gồm như sau:

  • Quyết định về nền tảng sử dụng, có thể là Java, PHP hoặc .NET, với hệ quản trị cơ sở dữ liệu Oracle, MySQL … Bất cứ cái nào, miễn nó phù hợp cho dự án.
  • Kiểm tra phần mềm để xác minh rằng nó đã được xây dựng dựa trên spec cung cấp bởi khách hàng
  • Viết mã nguồn cho phần mềm
  • Tìm tất cả các thông tin có thể về chi tiết thiết kế và đặc tả kỹ thuật cho phần mềm từ khách hàng.

Chúng ta có lẽ rằng cần sắp xếp lại một chút ít, ví dụ điển hình bạn cần tìm thông tin trước, sau đó lên kế hoạch mình sẽ thao tác bằng công nghệ tiên tiến nào, rồi viết mã cho nó, ở đầu cuối mới kiểm tra lại xem ứng dụng đã cung ứng hết những nhu yếu chưa .

Và thực tế chúng ta sẽ cần nhiều bước hơn thế này, bảng dưới đây mô tả các bước cần thiết cho giai đoạn phát triển trong mô hình thác nước (Waterfall)

Giai đoạnHoạt độngThu thập yêu cầuThu thập càng nhiều thông tin càng tốt về các chi tiết thiết kế và đặc tả kỹ thuật của phần mềm từ các mong muốn của khách hàng. Giai đoạn này đơn giản chỉ là thu thập các yêu cầu, không cần làm gì khác.Thiết kếLên kế hoạch về ngôn ngữ lập trình được sử dụng như Java, PHP, .net; cơ sở dữ liệu như Oracle, MySQL, v.v. Quyết định cái nào sẽ phù hợp với dự án, cũng như một số chức năng và kiến trúc cấp cao.Xây dựngViết source code cho phần mềmKiểm thửKiểm tra phần mềm để xác minh rằng nó được xây dựng theo các đặc tả kỹ thuật do khách hàng cung cấp.Triển khaiTriển khai phần mềm trong môi trường thực tếBảo trìĐây là trạng thái khi phần mềm sẵn sàng để sử dụng, có thể bạn sẽ được khách hàng yêu cầu thay đổi (nếu có).

Vấn đề của mô hình thác nước – Waterfall

Như bạn thấy, quy trình kiểm thử trong quy mô này chỉ mở màn sau mã nguồn được tiến hành xong .Nếu bạn đang thao tác trong một dự án Bất Động Sản lớn, nơi mà có những mạng lưới hệ thống phức tạp, bạn rất dễ bỏ lỡ những cụ thể chính trong quy trình tiến độ nhu yếu. Trong những trường hợp như vậy, một mẫu sản phẩm trọn vẹn sai sẽ được giao cho người mua và bạn hoàn toàn có thể phải khởi đầu lại dự án Bất Động Sản HOẶC nếu bạn quản trị để ghi chú những nhu yếu một cách đúng chuẩn nhưng mắc lỗi nghiêm trọng trong phong cách thiết kế và kiến trúc ứng dụng của bạn, bạn sẽ phải phong cách thiết kế lại hàng loạt ứng dụng để sửa lỗi .

Theo đánh giá của hàng nghìn dự án áp dụng mô hình thác nước đã chỉ ra rằng các defects được đưa ra trong quá trình yêu cầu & thiết kế chiếm gần một nửa. Và vì đây là giai đoạn rất sớm của toàn bộ quá trình, hậu quả xấu nhất xảy ra là chúng ta cần làm lại từ đầu tất cả các bước nếu chúng ta không phát hiện ra vấn đề sớm 😭

.

Chi tiêu cần bỏ ra để thay thế sửa chữa một khiếm khuyết sẽ tăng lên trong suốt vòng đời tăng trưởng. Và xui cho tất cả chúng ta là nó sẽ tăng theo cấp số nhân. Một lỗi được phát hiện càng sớm trong vòng đời, thì việc thay thế sửa chữa nó càng thuận tiện .

Giải pháp: V-Model

Mô hình chữ V được tạo ra như một giải pháp để xử lý yếu tố của quy mô thác nước. Thay vì chỉ kiểm thử khi quy trình tăng trưởng mã nguồn kết thúc như trong quy mô thác nước, quy mô chữ V cung ứng một quy trình kiểm thử chạy song song cho mỗi bước của quy trình tăng trưởng .

Mô hình chữ V thực chất là tổ hợp của vòng đời phát triển phần mềm SDLC ở bên trái và vòng đời kiểm thử phần mềm STLC ở bên phải.

  • Requirement Analysis (Phân tích yêu cầu) sẽ có quá trình tương ứng là System Testing (Kiểm thử hệ thống) : Ở bước này chúng ta sẽ kiểm tra tổng quan toàn bộ hệ thống.
  • High Level Design (Thiết kế cấp cao) sẽ có quá trình tương ứng là Integration Testing (Kiểm thử tích hợp): Ở bước này chúng ta sẽ kiểm tra sự kết nối và tương hợp giữa các thành phần của phần mềm.
  • Low Level Design (Thiết kế cấp thấp) sẽ có quá trình tương ứng là Unit Testing (Kiểm thử đơn vị): Ở bước này chúng ta sẽ kiểm tra ở mức function (tính năng) của phần mềm
  • Coding không cần một quá trình kiểm thử tương ứng, thật ra là không cần thiết do ở bước này hầu như các công nghệ và nền tảng kỹ thuật đã hoàn toàn được kiểm tra trước đó bởi nhà sản xuất của mỗi hãng trước khi được sử dụng chính thức. Vì vậy chúng ta không phải kiểm tra lại ở bước này, thường sẽ do Dev đảm bảo.

Ngoài mô hình chữ V, hiện nay cũng có các mô hình phát triển lặp đi lặp lại, trong đó việc phát triển được thực hiện theo các giai đoạn, với mỗi giai đoạn bổ sung một chức năng cho phần mềm. Mỗi giai đoạn bao gồm một tập hợp các hoạt động phát triển và thử nghiệm độc lập và được lặp lại ở giai đoạn phát triển tiếp theo khi giai đoạn hiện tại kết thúc.
Ví dụ điển hình về các vòng đời Phát triển theo phương pháp lặp lại là Rapid Application Development, Agile Software Development.

Kết luận

Hiện nay theo mình thấy có rất nhiều quy mô vòng đời tăng trưởng. Mô hình tăng trưởng được lựa chọn cho một dự án Bất Động Sản phụ thuộc vào vào tiềm năng và đích đến hướng tới của dự án Bất Động Sản đó. Chúng ta cần quan tâm như sau :

  • Kiểm Thử không phải là một hoạt động độc lập và nó phải điều chỉnh dựa theo mô hình phát triển được chọn cho dự án.
  • Trong bất kỳ mô hình nào, việc kiểm thử phải được thực hiện ở tất cả các cấp, tức là ngay từ khi yêu cầu cho đến khi bảo trì để đảm bảo quá trình phát triển có thể khắc phục được tối đa các vấn đề gặp phải.

Cảm ơn mọi người đã đọc bài viết .

Tài liệu tham khảo

Rate this post

Bài viết liên quan

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments