Tổng hợp mô hình kiểm thử phần mềm Tester nên biết

Mô hình kiểm thử phần mềm là gì?

Kiểm thử phần mềm là hoạt động là hoạt động gắn kết với phát triển phần mềm. Nếu coi quá trình phát triển phần mềm là “xương sống” thì kiểm thử phần mềm chính là việc tạo nên “cơ bắp” cho phần mềm đó. 

Quá trình kiểm thử phần mềm thường được thực hiện theo những mô hình nhất định. Mỗi mô hình kiểm thử phần mềm sẽ có cách tiếp cận, sử dụng và sở hữu ưu điểm khác nhau. Vậy, mô hình kiểm thử phần mềm là gì? 
 

Mô hình kiểm thử phần mềm bao gồm các giai đoạn nhằm phát hiện lỗi và đảm bảo phần mềm thỏa mãn các yêu cầu của khách hàng. Tùy vào độ phức tạp của dự án và yêu cầu của khách hàng mà tester sẽ áp dụng mô hình kiểm thử phần mềm phù hợp. 

Các mô hình kiểm thử thường được tester sử dụng

Có rất nhiều mô hình kiểm thử phần mềm, tuy nhiên, một số mô hình được các tester thường xuyên sử dụng gồm: mô hình thác nước, mô hình chữ V, mô hình mẫu, mô hình Agile, mô hình xoắn ốc, mô hình Scrum, mô hình tăng trưởng và mô hình
RAD.

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

Mô hình kiểm thử phần mềm Waterfall model được sử dụng đầu tiên. Đây là mô hình áp dụng tuần tự các giai đoạn phát triển phần mềm, theo đó, đầu vào của giai đoạn sau chính là đầu ra của giai đoạn trước. 

• Requirement gathering: Thu thập, phân tích yêu cầu được ghi lại vào tài liệu đặc tả trong giai đoạn này. 
• System Analysis: Tiến hành phân tích thiết kế và xác định kiến trúc tổng thể của phần mềm.  
• Coding: Hệ thống được phát triển theo từng Unit, đồng thời được tích hợp trong giai đoạn tiếp theo. Unit được phát triển và kiểm thử bởi lập trình viên được gọi là Unit Test. 
• Testing: Giai đoạn này, công việc chủ yếu là kiểm tra, phát hiện và sửa lỗi để phần mềm hoạt động đú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: Khi có thay đổi từ khách hàng, người dùng sẽ tiến hành bảo trì hệ thống. 

• Thân thiện, dễ tiếp cận, sử dụng và quản lý
• Các giai đoạn phát triển sản phẩm được xác định rõ ràng
• Xác nhận ở từng giai đoạn để kịp thời phát hiện và sửa lỗi

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

Mô hình mẫu

• Cải thiện khoảng cách giữa nhà phát triển phần mềm và người dùng 
• Người dùng có thể sớm hình dung đặc điểm và chức năng của hệ thống phần mềm

• Mô hình mẫu vẫn chưa thể cải thiện hoàn toàn khoảng cách giữa yêu cầu và ứng dụng cuối cùng
• Prototype thường được làm vội vàng, có thể không phân tích, đánh giá kỹ lưỡng các khía cạnh liên quan đến hệ thống cuối cùng 
• Khi Prototype không chuyển tải hết các đặc điểm, chức năng của hệ thống phần mềm thì người dùng có thể “vỡ mộng” và không còn quan tâm đến hệ thống sẽ được phát triển 

Mô hình chữ V (V model)

Tức là, mỗi giai đoạn của chu kỳ phát triển phần mềm sẽ có một giai đoạn thử nghiệm liên quan trực tiếp. Mô hình kiểm thử phần mềm chữ V có tính kỷ luật cao, chỉ khi hoàn thành giai đoạn trước mới có thể bắt đầu giai đoạn tiếp theo. 
 

Với mô hình chữ V, việc kiểm thử xuất hiện ngay từ đầu. Từ lúc thu thập yêu cầu là có thể review tài liệu, review code, review đặc tả chi tiết các bản thiết kế, cuối cùng sẽ là test ở mức thấp nhất: từng module, màn hình, chức năng, test tích hợp và kiểm thử hệ thống.   
 

Mô hình chữ V và mô hình thác nước được ứng dụng gần giống nhau, bởi vì chúng đều thuộc loại tuần tự, yêu cầu rõ ràng trước khi bắt đầu dự án. Mô hình chữ V (V model) thường được ứng dụng trong phát triển Y tế. 

Ưu điểm:

 

• Đơn giản, dễ hiểu, dễ sử dụng và quản lý 
• Phân phối rõ từng giai đoạn, quy trình đánh giá cụ thể  
• Mô hình có tính kỷ luật cao, các giai đoạn được hoàn thành cùng lúc
• Phù hợp với những dự án nhỏ và các yêu cầu được hiểu một cách rõ ràng 

Nhược điểm:

• Khó khăn trong việc quản lý, kiểm soát rủi ro
• Khó để quay lại và thay đổi chức năng khi ứng dụng đang ở giai đoạn thử nghiệm
• Mô hình này không phù hợp với những dự án lớn, phức tạp, đang diễn ra và hướng đối tượng 

Mô hình Agile 
 

Mô hình kiểm thử phần mềm Agile khá linh hoạt, giúp đưa sản phẩm đến tay người dùng càng nhanh càng tốt. Mô hình này có sự cải tiến so với một số mô hình kiểm thử cũ, điển hình là mô hình thác nước (Waterfall model). 

Mô hình Agile dựa trên mô hình Iterative and incremental. Các giải pháp phát triển và yêu cầu dựa trên sự kết hợp của các function. Bên cạnh đó, những tính năng cụ thể của bản phát hành cuối sẽ được cung cấp bởi các tác vụ chia thành các khung thời gian nhỏ. 

Ưu điểm:

• Dễ hiểu, dễ sử dụng 
• Khách hàng hài lòng vì giao nhanh chóng
• Dễ dàng thay đổi và bổ sung theo yêu cầu 
• Các chức năng được xây dựng rõ ràng, dễ quản lý
• Khơi dậy tinh thần làm việc nhóm và trao đổi công việc hiệu quả 
• Nhà phát triển, người thử nghiệm và khách hàng thường xuyên trao đổi

Nhược điểm:

• Cần một nhóm dày dặn kinh nghiệm 
• Cần sự tương tác rõ ràng của khách hàng
• Không phù hợp để xử lý các phụ thuộc phức tạp
• Xuất hiện nhiều rủi ro về tính bền vững, khả năng mở rộng và bảo trì
• Gặp khó khăn khi chuyển giao công nghệ cho các thành viên mới trong nhóm

Mô hình xoắn ốc (Spiral model) 
 

Xoắn ốc là mô hình kiểm thử phần mềm được phát triển dựa trên sự kết hợp giữa mô hình thác nước (Waterfall model) và mô hình mẫu (Prototype model). Thông thường, mô hình xoắn ốc được dùng cho các ứng dụng lớn hay các hệ thống được xây dựng các phân đoạn/giai đoạn nhỏ. 

Các pha trong quy trình phát triển mô hình xoắn ốc (Spiral model) bao gồm: lập kế hoạch => đánh giá, giảm thiểu rủi ro => phát triển sản phẩm => đánh giá và lên kế hoạch pha tiếp theo. 
 

Lập kế hoạch (Planning phase): Thu thập và phân tích yêu cầu nhận được từ khách hàng. Cần xác định rõ ràng mục tiêu và đối tượng của từng pha.
 

Đánh giá, giảm thiểu rủi ro (Alternate evaluation): Xác định, đánh giá và thực hiện những hành động để giảm thiểu rủi ro. Nếu xuất hiện rủi ro trong quá trình này sẽ có các giải pháp thay thế phù hợp. 

Phát triển sản phẩm (Product development): Lựa chọn mô hình thích hợp để phát triển hệ thống phần mềm.

Đánh giá và lập kế hoạch (Next phase planning): Tiến hành đánh giá dự án và lập kế hoạch cho pha tiếp theo. 

Ưu điểm:

• Dễ dàng kiểm soát rủi ro
• Hiệu quả đối với phần mềm quy mô lớn
• Phát hiện sớm những vấn đề quan trọng 

Nhược điểm:
 

• Mô hình này chưa thực sự phổ biến
• Cần thay đổi thường xuyên dẫn đến lặp vô hạn 
• Phức tạp, không phù hợp với những dự án nhỏ, ít rủi ro
• Tiêu tốn nhiều thời gian và chi phí cao để hoàn thành dự án 
• Manager cần có kỹ năng tốt để đánh giá rủi ro và quản lý dự án hiệu quả

Mô hình Scrum

Mô hình kiểm thử phần mềm Scrum sử dụng các tiếp cận lặp, tăng trưởng để tối ưu hóa tính khả đoán và kiểm soát rủi ro. Những khía cạnh quan trọng của tiến trình cần được hiển thị cụ thể, rõ ràng cho những người có trách nhiệm trong tiến trình đó.

Mô hình Scrum chia các yêu cầu thành từng giai đoạn, mỗi giai đoạn gồm một số lượng nhất định yêu cầu và thường kéo dài từ 1 – 4 tuần (không quá 1 tháng). Đầu mỗi giai đoạn sẽ làm rõ những yêu cầu được thực hiện. Việc tiếp theo là code và test. 
 

Cuối giai đoạn là một sản phẩm hoàn thành cả code và test, có thể demo và chạy được. Khi hoàn thành giai đoạn 1 sẽ bắt đầu giai đoạn 2, giai đoạn 3, giai đoạn 4,… cho đến khi hoàn thành hết các yêu cầu đặt ra. 

Ba nhân tố quan trọng cấu thành nên Scrum gồm: tổ chức (Organization), tài liệu (Artifacts), quy trình (Process). Trong đó: 

• Tổ chức: Tổ chức nhóm và roles, người sở hữu sản phẩm, người điều phối, nhóm phát triển. 
• Tài liệu: Danh sách chức năng cần phát triển của sản phẩm, chức năng cần phát triển cho từng giai đoạn, kết quả ước lượng của nhóm. 
• Quy trình: Hoạch định, tổng kết cho mỗi giai đoạn và nhận xét theo ngày. 

Ưu điểm:

• Có khả năng phát hiện lỗi sớm 
• Một người có thể đảm nhận nhiều việc 
• Phù hợp với dự án mà khách hàng không yêu cầu rõ ràng từ đầu

Nhược điểm:

• Yêu cầu nhóm có kỹ năng nhất định 
• Nhóm phải có sự hiểu biết về mô hình Agile
• Xác định thời gian và ngân sách gặp nhiều khó khăn 
• Kéo dài thời gian vì phải thực hiện theo yêu cầu của khách hàng 
• PO có vai trò quan trọng, nếu không làm tốt sẽ ảnh hưởng đến kết quả chung

Mô hình tăng trưởng

Mô hình tăng trưởng sẽ chia chu kỳ phát triển phần mềm thành các mô-đun nhỏ để dễ dàng quản lý. Đây là mô hình kiểm thử phần mềm mà mỗi mô-đun sẽ trải qua rất nhiều giai đoạn: phân tích yêu cầu, thiết kế, thực hiện và thử nghiệm, giống như vòng đời phát triển thông thường. 

Mô hình tăng trưởng phù hợp với những dự án mà yêu cầu đã được mô tả rõ ràng và khách hàng có nhu cầu về sản phẩm sớm. Cũng giống như những mô hình kiểm thử phần mềm khác, mô hình tăng trưởng sở hữu nhiều ưu điểm nổi bật, tuy nhiên nó vẫn tồn tại một số hạn chế nhất định. 
 

Ưu điểm:

• Phát triển dễ dàng, nhanh chóng
• Kiểm tra và sửa lỗi đơn giản hơn 
• Linh hoạt, ít tốn kém khi thay đổi yêu cầu, phạm vi

Nhược điểm:

• Yêu cầu cao về lập plan và thiết kế
• Tổng chi phí của mô hình này cao hơn so với mô hình thác nước 

Mô hình RAD

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

• Tiết kiệm thời gian phát triển 
• Đưa ra đánh giá ban đầu nhanh chóng
• Khuyến khích khách hàng đưa ra phản hồi
• Tăng khả năng tái sử dụng của các thành phần 

• Nhóm thực hiện cần có kỹ năng nhất định 
• Mô hình này chỉ phù hợp với những hệ thống có mô-đun

• Các phương pháp kiểm thử phần mềm mới nhất 2022
• Các loại kiểm thử phần mềm cần biết trong năm 2022
• Các giai đoạn kiểm thử phần mềm tester nên biết
• Vòng đời kiểm thử phần mềm tester nên biết
• Các công cụ kiểm thử phần mềm phổ biến trong năm 2022