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).
Bạn đang xem: Mô hình chữ v trong kiểm thử phần mềm
Một số Thuật ngữ được dùng trong bài viết: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.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.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-ModelGiả sử, bạn được giao một nhiệm vụ là phát triển một phần mềm tùy biến cho khách hàng. Không cần quá quan tâm đến các nền tảng kỹ thuật hay các công nghệ sẽ áp dụng, bạn hãy thử đưa ra dự đoán có hệ thống về trình tự các bước bạn sẽ làm theo để hoàn thành được nhiệm vụ 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ẽ cần sắp xếp lại một chút, chẳng hạn bạn cần tìm thông tin trước, sau đó lên kế hoạch mình sẽ làm việc bằng công nghệ nào, rồi viết mã cho nó, cuối cùng mới kiểm tra lại xem phần mềm đã đáp ứng hết các yêu cầ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)
| Thu thập yêu cầu | Thu 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, My SQL, 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ựng | Viết source code cho phần mềm |
| Kiể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 khai | Triể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ó). |
Như bạn thấy, quá trình kiểm thử trong mô hình này chỉ bắt đầu sau mã nguồn được triển khai xong.
Nếu bạn đang làm việc trong một dự án lớn, nơi mà có các hệ thống phức tạp, bạn rất dễ bỏ lỡ các chi tiết chính trong giai đoạn yêu cầu. Trong những trường hợp như vậy, một sản phẩm hoàn toàn sai sẽ được giao cho khách hàng và bạn có thể phải bắt đầu lại dự án HOẶC nếu bạn quản lý để ghi chú các yêu cầu một cách chính xác nhưng mắc lỗi nghiêm trọng trong thiết kế và kiến trúc phần mềm của bạn, bạn sẽ phải thiết kế lại toàn bộ phần mềm để 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 phí cần bỏ ra để sửa chữa một khiếm khuyết sẽ tăng lên trong suốt vòng đời phát triển. Và xui cho 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 sửa chữa nó càng dễ dàng.
Giải pháp: V-ModelMô hình chữ V được tạo ra như một giải pháp để giải quyết vấn đề của mô hình thác nước. Thay vì chỉ kiểm thử khi quá trình phát triển mã nguồn kết thúc như trong mô hình thác nước, mô hình chữ V cung cấp một quá trình kiểm thử chạy song song cho mỗi bước của quá trình phát triển.
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ềmCoding 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.Xem thêm: Top 11 phần mềm quản lý bệnh nhân miễn phí tốt, phần mềm quản lý bệnh nhân
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ậnHiện nay theo mình thấy có rất nhiều mô hình vòng đời phát triển. Mô hình phát triển được lựa chọn cho một dự án phụ thuộc vào mục tiêu và đích đến hướng tới của dự án đó. Chúng ta cần chú ý 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.
Bên cạnh selenium webdriver, log Bug thì mô hình chữ V cũng là một khái niệm cần quan tâm khi bắt đầu với sự nghiệp kiểm thử. Vậy, bạn đã biết đây là mô hình gì và cách thức hoạt động ra sao chưa? Tìm hiểu ngay trong nội dung bài viết dưới đây của chúng tôi.
Tìm hiểu về mô hình chữ V
Trong kiểm thử phần mềm, mô hình chữ V được biết đến với tên gọi là mô hình xác minh (Verification Model) hay mô hình xác thực (Validation Model). Đây là một kiểu mở rộng của mô hình thác nước. Theo đó, việc kiểm thử sẽ được thực hiện trên từng giai đoạn một cách tuần tự để đảm bảo chất lượng của phần mềm khi đến tay khách hàng.
Mô hình chữ V được ra đời nhằm khắc phục nhược điểm của mô hình thác nước chỉ diễn ra khi mã nguồn đã được triển khai xong. Điều đó sẽ rất bất lợi, nhất là khi tham gia các dự án lớn với hệ thống phức tạp. Việc bỏ lỡ một chi tiết nào đó sẽ khiến cho công sức của toàn team có thể bị đổ sông đổ biển.
Theo đánh giá của hàng nghìn dự án được áp dụng mô hình thác nước thì các defects được tìm thấy trong quá trình yêu cầu & thiết kế thường chiếm đến phân nửa. Trong khi đó, đây lại là giai đoạn rất sớm mà mô hình thác nước bỏ qua. Đấy là lý do tại sao mô hình chữ V được ra đời như một giải pháp để giải quyết vấn đề này. Mô hình này đang được sử dụng khá rộng rãi trong từng giai đoạn và song song với chu kỳ phát triển phần mềm.
Nguyên lý hoạt động của V-Model
Vì là một biến thể của mô hình thác nước nên mô hình chữ V cũng có cách thức hoạt động tương tự. Điều đó có nghĩa là các giai đoạn sẽ được hoàn thiện rồi mới sang công đoạn kế tiếp. Các hoạt động sẽ được diễn ra đồng thời, không có pha rời rạc. Thay vào đấy, kiểm thử sẽ được bắt đầu ngay từ giai đoạn lấy yêu cầu để đảm bảo tìm ra tất cả lỗi có thể phát sinh.
Step 1: BRS
BRS là viết tắt của Business requirement Specification hay còn được hiểu là các yêu cầu kỹ thuật của công việc. Ở giai đoạn này, chuyên viên kiểm thử sẽ tìm hiểu tài liệu một cách kỹ lưỡng để biết được mục đích ra đời của phần mềm, các tiêu chuẩn để đánh giá về chất lượng… Hoàn thành bước này, chúng ta sẽ đến với một bước được gọi là Acceptance test.
Step 2: SRS
SRS là viết tắt của System requirement Specification. Dịch ra tiếng việt có nghĩa là phân tích yêu cầu hệ thống. Vì vậy, bản chất của step 2 chính là phân tích tính chất của công việc. Đi kèm với đó sẽ là quá trình System Testing.
Trong giai đoạn này, chúng ta sẽ cần xác minh các yêu cầu và xác nhận đầu ra cần có, các tài liệu cũng như UAT test case. Đặc biệt nhấn mạnh vào chức năng hoạt động của hệ thống.
Step 3: HLD
Đến với bước 3 – High Level Design hay còn được gọi là HLD. Giai đoạn này được thực hiện dựa trên kỹ thuật hệ thống và thiết kế. Mục đích chính là cung cấp các giải pháp giúp xử lý tổng quan về hệ thống sản phẩm cũng như các dịch vụ. Ở bước này, chúng ta sẽ phải thực hiện Integration Test.
Hoạt động xác minh ở đây bao gồm các đánh giá thiết kế còn xác nhận thì thiên về Test plan, test case và các ma trận truy vết. Đầu ra sau khi kết thúc step 3 gồm có System test cases, Feasibility reports, System test plan, các mô đun và tài liệu yêu cầu phần cứng liên quan…
Step 4: LLD
Ở bước tiếp theo, LLD – Low Level Design, phần mềm sẽ được xác định các yếu tố logic, các sơ đồ với mọi phương thức hay các mối liên quan. Trong quá trình đó, sẽ có nhiều mâu thuẫn phát sinh gây ảnh hưởng đến chất lượng sản phẩm. Và tất nhiên, nhiệm vụ của các chuyên viên kiểm thử chính là xác định lỗi để khắc phục kịp thời.
Khi thực hiện thành công bước này, chúng ta sẽ đến với công đoạn test Component Test. Các hoạt động xác minh, xác nhận cũng được thực hiện song song. Trong đó, chuyên viên kiểm thử sẽ đánh giá các thiết kế để xác nhận với các trường hợp kiểm tra đơn vị. Đầu ra đạt được sẽ gồm các đơn vị kiểm tra đơn vị đã được kiểm thử.
Step 5: Coding
Khi đã có đủ các yêu cầu triển khai sản phẩm rồi, vậy thì đây sẽ là lúc bắt đầu phát triển phần mềm. Mỗi thành viên trong nhóm sẽ được phân công với những nhiệm vụ cụ thể. Họ sẽ sử dụng các ngôn ngữ lập trình và các thuật toán để code phần mềm. Cuối step 5, chúng ta sẽ đến với một công đoạn test được gọi là Unit Test.
Ở bước quan trọng này, người ta sẽ xác minh các mã và kiểm tra các trường hợp test. Hoạt động xác nhận sẽ xoay quanh việc tạo các trường hợp kiểm tra chức năng. Sau đấy, xác nhận lại về các trường hợp kiểm tra chức năng. Đầu ra nhận được sẽ gồm danh sách các trường hợp thử nghiệm hay những vấn đề cần kiểm tra lại.
Step 6: Code/Testing
Bước này thực chất là để review lại Low Level Design ở Step 4. Sau khi việc thiết kế phần mềm với các yêu cầu cụ thể được hoàn tất thì các chuyên viên kiểm thử sẽ kiểm tra lại tính tối ưu của các đoạn Code. Lúc này việc Unit Test sẽ được thực hiện lại để đảm bảo chất lượng của phần mềm đáp ứng với các yêu cầu đã được đặt ra.
Đánh giá ưu nhược điểm của mô hình chữ V
Về cơ bản, mô hình chữ V cũng có những ưu và nhược điểm riêng biệt. Do đó, để có thể sử dụng một cách hiệu quả, chúng ta sẽ phải phân tích rõ về 2 khía cạnh này. Cụ thể:
Về ưu điểm:
V Model có cơ chế hoạt động đơn giản, dễ sử dụng. Lên kế hoạch cụ thể cho việc triển khai dự án, test phần mềm. Giúp tester dễ dàng phát hiện defect ngay từ những bước đầu tiên, tránh việc “sai cả dây”.Tiết kiệm kha khá thời gian khi kiểm tra kỹ lưỡng ở từng giai đoạn phát triển phần mềm. Mang đến nhiều cơ hội thành công hơn cho các dự án đang được triển khai.Về nhược điểm:
Mô hình chữ V vẫn khá cứng nhắc khi yêu cầu công đoạn kiểm tra xác nhận ở từng bước. Nếu sử dụng với các dự án đơn giản thì sẽ gây tốn kém về thời gian cũng như nhân lực cho các công đoạn xác minh. Nếu xuất hiện sự thay đổi về kỹ thuật ở giữa chừng, tester sẽ phải thực hiện lại, chuẩn bị tài liệu mới, gây tốn kém về thời gian, chi phí.Không thể sử dụng để vừa phát triển song song với vừa bán sản phẩm.Sản phẩm của dự án sẽ không có nguyên mẫu ban đầu. Thay vào đó, sản phẩm chỉ xuất hiện khi tất cả các bước hoàn thành xong.Khi nào sử dụng mô hình chữ V?
Dựa vào những ưu nhược điểm kể trên, chúng ta có thể biết được khi nào nên dùng mô hình chữ V để mang đến hiệu quả cao nhất. Cụ thể nên dùng V Model cho các trường hợp như sau:
Dự án có kích thước nhỏ và trung bình khi có yêu cầu rõ ràng, cụ thể, không thay đổi. Tem có đội ngũ kỹ thuật tốt với nguồn tài nguyên phong phú, sẵn có. Từ đấy có thể đảm bảo được các yêu cầu. Nên sử dụng mô hình chữ V cho các dự án mà khách hàng có sự tự tin cao trong yêu cầu thiết kế. Hiểu một cách đơn giản là không có nhiều thay đổi hay dao động trong quá trình phát triển phần mềm.Trên đây là những thông tin cơ bản về mô hình chữ V hay còn gọi là mô hình xác minh hay mô hình xác thực. Đây là một kỹ thuật kiểm thử rất phù hợp cho các dự án có yêu cầu cụ thể, ít thay đổi. Vì vậy, có thể là một công cụ đắc lực cho việc phát triển, hoàn thiện phần mềm trước khi đến tay khách hàng.
