Kiểm thử không phải là một hoạt động độc lập. Nó có vị trí trong mô hình vòng đời phát triển phần mềm và do đó vòng đời được áp dụng sẽ quyết định phần lớn cách tổ chức kiểm thử.

Có nhiều hình thức kiểm thử khác nhau. Bởi vì một số lĩnh vực, thường có các mối quan tâm khác nhau, có liên quan đến vòng đời phát triển, điều quan trọng là phải hiểu và xác định rõ ràng các cấp độ và loại kiểm thử khác nhau.

Chương này thảo luận về các mô hình phát triển phần mềm được áp dụng phổ biến nhất, các cấp độ kiểm thử và các loại kiểm thử. Bảo trì có thể được coi là một ví dụ cụ thể của một quy trình kiểm thử. Cách thức bảo trì ảnh hưởng đến quy trình kiểm thử, các cấp độ, các loại và cách thức kiểm thử có thể được tổ chức được mô tả trong phần cuối cùng của chương này.

CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM

Các phần sẽ xuất hiện trong đề thi

1. Hiểu mối quan hệ giữa phát triển, hoạt động kiểm thử và sản phẩm công việc trong vòng đời phát triển và đưa ra các ví dụ dựa trên đặc điểm và bối cảnh của dự án và sản phẩm. (K2)
2. Nhận ra thực tế rằng các mô hình phát triển phần mềm phải được điều chỉnh cho phù hợp với bối cảnh của dự án và các đặc tính của sản phẩm. (K1)
3. Nhắc lại lý tại sao có các mức độ kiểm thử khác nhau và các đặc điểm của bài kiểm thử tốt trong bất kỳ mô hình vòng đời nào. (K1)

Quy trình phát triển được chọn cho một dự án sẽ phụ thuộc vào mục tiêu ngắn hạn và mục tiêu dài hạn của dự án. Có rất nhiều vòng đời phát triển đã được phát triển để đạt được các mục đích  yêu cầu khác nhau.

Các vòng đời này bao gồm từ các phương pháp nhẹ và nhanh , trong đó thời gian đưa ra thị trường là cốt lõi, cho đến các phương pháp được kiểm soát và tài liệu hóa đầy đủ, trong đó chất lượng và độ tin cậy là động lực chính.

Mỗi phương pháp đều có vị trí trong việc phát triển phần mềm hiện đại và quy trình phát triển phù hợp nhất nên được áp dụng cho mỗi dự án. Các mô hình chỉ rõ các giai đoạn khác nhau của quy trình và trình tự thực hiện chúng.

Mô hình vòng đời được áp dụng cho một dự án sẽ có tác động lớn đến quy trình kiểm thử được thực hiện. Kiểm thử không tồn tại một cách cô lập; hoạt động kiểm thử có liên quan nhiều đến hoạt động phát triển phần mềm. Nó sẽ xác định cái gì, ở đâu và khi nào của việc kiểm thử theo kế hoạch, ảnh hưởng đến kiểm thử hồi quy và phần lớn xác định kỹ thuật kiểm thử nào sẽ sử dụng.

Cách tổ chức kiểm thử phải phù hợp với vòng đời phát triển nếu không sẽ không mang lại lợi ích. Nếu thời gian để ra
thị trường là động lực chính, khi đó việc kiểm thử phải nhanh chóng và hiệu quả. Nếu vòng đời phát triển phần mềm phải được tài liệu hóa đầy đủ, thì việc kiểm thử cũng phải được tài liệu hóa đầy đủ.

Trong mọi vòng đời phát triển, một phần của kiểm thử tập trung vào kiểm thử xác minh (verification) và một phần tập trung vào kiểm thử xác nhận (validation).

Xác minh liên quan đến việc đánh giá một sản phẩm, thành phần hoặc hệ thống làm việc để xác định xem nó có đáp ứng các yêu cầu đặt ra hay không. Trên thực tế, việc xác minh tập trung vào câu hỏi “Có phải sản phẩm được xây dựng theo đặc điểm kỹ thuật không?”.

Xác nhận có liên quan đến việc đánh giá một sản phẩm, thành phần hoặc hệ thống làm việc để xác định xem nó có đáp ứng các nhu cầu và yêu cầu của người dùng hay không. Việc xác thực tập trung vào câu hỏi “Liệu sản phẩm đã xây dựng phù hợp với mục đích, ví dụ: nó có cung cấp giải pháp cho vấn đề không?”.

MÔ HÌNH CHỮ V (V-MODEL)

Trước khi thảo luận về V-Model, ta sẽ xem xét mô hình đi trước nó.

Mô hình thác nước (waterfall) là một trong những mô hình sớm nhất được thiết kế. Nó có một dòng thời gian tự nhiên, nơi các tác vụ được thực hiện theo cách tuần tự.

Bắt đầu từ đỉnh thác với một nghiên cứu khả thi và đi xuống thông qua các nhiệm vụ khác nhau của dự án để hoàn thành việc triển khai vào môi trường thực tế.  Thiết kế chuyển sang phát triển, sau đó chuyển sang xây dựng và cuối cùng là thử nghiệm.

Kiểm thử có xu hướng xảy ra vào cuối vòng đời của dự án vì vậy lỗi được phát hiện gần với ngày triển khai trực tiếp. Với mô hình này, rất khó để nhận được phản hồi được chuyển ngược lên thác nước và có những khó khăn nếu cần thực hiện nhiều lần lặp lại cho một giai đoạn cụ thể.

Mô hình thác nước

V-Model được phát triển để giải quyết một số vấn đề gặp phải khi sử dụng phương pháp tiếp cận thác nước truyền thống. Lỗi được phát hiện quá muộn trong vòng đời, vì kiểm thử không được tham gia cho đến khi kết thúc dự án.

Kiểm thử cũng tăng thêm thời gian thực hiện do sự tham gia muộn của nó. Mô hình V-Model cung cấp hướng dẫn rằng kiểm thử cần bắt đầu càng sớm càng tốt trong vòng đời, như chúng ta đã thấy trong Chương 1, là một trong những nguyên tắc cơ bản của kiểm thử có cấu trúc.

Nó cũng cho thấy rằng kiểm thử không chỉ là một hoạt động dựa trên thực thi. Có một loạt các hoạt động cần được thực hiện trước khi kết thúc giai đoạn lập trình. Các hoạt động này nên được thực hiện song song với các hoạt động phát triển và người kiểm thử cần làm việc với các nhà phát triển và BA để có thể thực hiện các tác vụ này.

Các sản phẩm công việc được tạo ra bởi các nhà phát triển và BA trong quá trình phát triển là cơ sở để kiểm thử ở một hoặc nhiều cấp độ. Bằng cách bắt đầu thiết kế kiểm thử sớm, lỗi thường được tìm thấy trong các tài liệu cơ sở kiểm thử. Thực tế là rất tốt nếu có tester tham gia thậm chí sớm hơn, trong quá trình xem xét các tài liệu cơ sở (dự thảo).

V-Model

V-Model là một mô hình minh họa cách các hoạt động kiểm thử xác minh và xác nhận (verification and validation) có thể được tích hợp vào từng giai đoạn của vòng đời. Trong V-Model, kiểm tra xác nhận diễn ra đặc biệt trong giai đoạn đầu (ví dụ: xem xét các yêu cầu của người dùng) và vào cuối vòng đời (ví dụ: trong quá trình kiểm thử chấp nhận của người dùng).

Mặc dù có các biến thể của V-Model, nhưng một loại V-Model phổ biến sử dụng bốn cấp độ kiểm thử. Bốn cấp độ kiểm tra được sử dụng, mỗi cấp độ có mục tiêu riêng, là:

• Kiểm thử thành phần: tìm kiếm lỗi và xác minh hoạt động của các thành phần phần mềm (ví dụ: mô-đun, chương trình, đối tượng, lớp, v.v.) có thể kiểm tra riêng biệt;
• Kiểm thử tích hợp: kiểm tra giao diện giữa các thành phần, tương tác với các phần khác nhau của hệ thống như hệ điều hành, hệ thống tệp và phần cứng hoặc giao diện giữa các hệ thống;
• Kiểm thử hệ thống: liên quan đến hành vi của toàn bộ hệ thống/sản phẩm như được xác định bởi phạm vi của một dự án phát triển hoặc sản phẩm. Trọng tâm chính của kiểm thử hệ thống là xác minh theo các yêu cầu cụ thể;
• Kiểm thử chấp nhận: kiểm thử xác nhận nhu cầu của người dùng, yêu cầu và các quy trình nghiệp vụ được tiến hành để xác định có chấp nhận hệ thống hay không.

Các cấp độ kiểm thử khác nhau được giải thích và thảo luận chi tiết trong Phần 2.2.

Trong thực tế, V-Model có thể có nhiều hơn, ít hơn hoặc nhiều mức độ phát triển và kiểm thử khác nhau, tùy thuộc vào dự án và sản phẩm phần mềm.

Ví dụ, có thể có kiểm thử tích hợp thành phần sau khi kiểm thử thành phần và kiểm thử tích hợp hệ thống sau khi kiểm thử hệ thống.

Các cấp độ kiểm thử có thể được kết hợp hoặc tổ chức lại tùy thuộc vào bản chất của dự án hoặc kiến ​​trúc hệ thống. Để tích hợp sản phẩm phần mềm bán sẵn (COTS) thương mại vào hệ thống, người mua chỉ có thể thực hiện kiểm thử tích hợp ở cấp hệ thống (ví dụ: tích hợp với cơ sở hạ tầng và các hệ thống khác) và ở giai đoạn sau kiểm thử chấp nhận

Lưu ý rằng các loại sản phẩm công việc được đề cập trong Hình 2.2 ở phía bên trái của mô hình chữ V chỉ là một minh họa. Trong thực tế, chúng có nhiều tên gọi khác nhau. Các tài liệu tham khảo cho các sản phẩm công việc chung bao gồm Tích hợp mô hình trưởng thành khả năng (CMMi) hoặc “Quy trình vòng đời phần mềm” từ ISO/IEC 12207.

CMMi là một khuôn khổ để cải tiến quy trình cho cả kỹ thuật hệ thống và kỹ thuật phần mềm. Nó cung cấp hướng dẫn về nơi tập trung và cách thức, để tăng mức độ hoàn thiện của quá trình. ISO/IEC 12207 là một tiêu chuẩn quy trình vòng đời phần mềm tích hợp đang nhanh chóng trở nên phổ biến hơn.

Nội dung tiếp theo sẽ tiếp tục giới thiệu về các mô hình phát triển phần mềm khác.

Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.

Syllabus tải về Tại đây