CẤP ĐỘ KIỂM THỬ

Các mục sẽ xuất hiện trong đề thi

So sánh các cấp độ thử nghiệm khác nhau: mục tiêu chính, đối tượng kiểm thử điển hình, mục tiêu kiểm thử điển hình (ví dụ: chức năng hoặc cấu trúc) và các sản phẩm công việc liên quan, người kiểm thử, loại lỗi cần được xác định. (K2)

Các đặc điểm chính cho mỗi cấp độ kiểm thử được thảo luận và xác định để có thể phân tách rõ ràng hơn các cấp độ kiểm thử khác nhau.

Sự hiểu biết và định nghĩa kỹ lưỡng về các cấp độ kiểm thử khác nhau sẽ xác định các phần còn thiếu, ngăn ngừa sự chồng chéo và lặp lại. Đôi khi đưa ra sự chồng chéo có chủ ý để giải quyết những rủi ro cụ thể.  Hiểu được liệu chúng ta có muốn chồng chéo hay không và loại bỏ những khoảng trống sẽ làm cho việc kiểm thử hiệu quả hơn.

KIỂM THỬ THÀNH PHẦN

Kiểm thử thành phần, còn được gọi là kiểm thử đơn vị, kiểm thử mô-đun hay kiểm thử chương trình, tìm kiếm lỗi và xác minh hoạt động của phần mềm (ví dụ: mô-đun, chương trình, đối tượng, lớp, v.v.) có thể kiểm thử riêng biệt.

Kiểm thử thành phần có thể được thực hiện tách biệt với phần còn lại của hệ thống tùy thuộc vào bối cảnh của vòng đời phát triển và hệ thống.

Hầu hết các phần mềm sơ khai (stub) và trình điều khiển (driver) thường được sử dụng để thay thế phần mềm bị thiếu và mô phỏng giao diện giữa các thành phần phần mềm một cách đơn giản. Một stub được gọi từ thành phần phần mềm sẽ được kiểm thử; còn trình điều khiển gọi đến một thành phần được kiểm thử (xem Hình 2.5).

Kiểm thử thành phần có thể bao gồm kiểm tra chức năng và các đặc điểm phi chức năng cụ thể như hành vi tài nguyên (ví dụ: rò rỉ bộ nhớ), kiểm thử hiệu suất hoặc độ bền cũng như kiểm thử cấu trúc (ví dụ: phạm vi quyết định). Các trường hợp kiểm thử bắt nguồn từ các sản phẩm công việc như thiết kế phần mềm hoặc mô hình dữ liệu.

Thông thường, kiểm thử thành phần xảy ra với quyền truy cập vào mã đang được kiểm tra và với sự hỗ trợ của môi trường phát triển, chẳng hạn như khung kiểm tra đơn vị hoặc công cụ gỡ lỗi và trong thực tế, thường liên quan đến lập trình viên đã viết mã.

Đôi khi, tùy thuộc vào mức độ rủi ro có thể áp dụng, kiểm thử thành phần được thực hiện bởi một lập trình viên khác, do đó mang lại tính độc lập. Lỗi thường được sửa ngay sau khi chúng được tìm thấy, mà không cần chính thức ghi lại các sự cố được tìm thấy.

Một cách tiếp cận trong kiểm thử thành phần, được sử dụng trong Extreme Programming (XP), là chuẩn bị và tự động hóa các trường hợp kiểm thử trước khi mã hóa. Đây được gọi là phương pháp tiếp cận kiểm thử đầu tiên hoặc phát triển theo hướng kiểm thử. Cách tiếp cận này có tính lặp lại cao và dựa trên các chu kỳ phát triển các trường hợp kiểm thử , sau đó xây dựng và tích hợp các đoạn mã nhỏ và thực hiện các kiểm thử thành phần cho đến khi chúng được vượt qua.

KIỂM THỬ TÍCH HỢP

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. Lưu ý rằng kiểm thử tích hợp nên được phân biệt với các hoạt động tích hợp khác.

Kiểm tra tích hợp thường được thực hiện bởi người tích hợp, nhưng tốt nhất là do người kiểm thử tích hợp cụ thể hoặc nhóm kiểm thử.

Có thể có nhiều hơn một cấp độ kiểm thử tích hợp và nó có thể được thực hiện trên các đối tượng kiểm thử có kích thước khác nhau. Ví dụ:

• Kiểm thử tích hợp thành phần kiểm tra sự tương tác giữa các thành phần phần mềm và được thực hiện sau khi kiểm thử thành phần;
• Kiểm thử tích hợp hệ thống kiểm tra sự tương tác giữa các hệ thống khác nhau và có thể được thực hiện sau khi kiểm thử hệ thống. Trong trường hợp này, tổ chức đang phát triển có thể chỉ kiểm soát một mặt của giao diện, vì vậy các thay đổi có thể gây mất ổn định. Các quy trình nghiệp vụ được thực hiện dưới dạng quy trình công việc có thể liên quan đến một loạt hệ thống thậm chí có thể chạy trên các nền tảng khác nhau.

Phạm vi tích hợp càng lớn, càng khó tách rời các lỗi đối với một giao diện cụ thể, điều này có thể dẫn đến tăng rủi ro. Điều này dẫn đến các cách tiếp cận khác nhau để kiểm thử tích hợp.

Một điểm cực đoan là tất cả các thành phần hoặc hệ thống được tích hợp đồng thời, sau đó mọi thứ đều được kiểm thử tổng thể. Đây được gọi là kiểm thử tích hợp “big bang“. Kiểm thử big bang có lợi thế là mọi thứ đã hoàn thành trước khi bắt đầu kiểm thử tích hợp. Không cần phải mô phỏng các bộ phận (khi chưa hoàn thành). Nhược điểm lớn là nói chung việc này tốn nhiều thời gian và khó tìm ra nguyên nhân gây ra lỗi.

Vì vậy, tích hợp big-bang có vẻ là một ý tưởng hay khi lập kế hoạch dự án, lạc quan và hy vọng sẽ không gặp vấn đề gì.

Nếu ai đó nghĩ rằng kiểm thử tích hợp sẽ tìm thấy lỗi, thì đó là một thực tiễn tốt để xem xét liệu có thể tiết kiệm thời gian bằng cách chia nhỏ quy trình kiểm thử tích hợp hay không.

Một điểm cực đoan khác là tất cả các chương trình đều được tích hợp từng cái một và một bài kiểm thử được thực hiện sau mỗi bước (kiểm thử gia tăng). Giữa hai thái cực này, có một loạt các biến thể. Phương pháp gia tăng có ưu điểm là lỗi được tìm thấy sớm trong từng phần nhỏ hơn khi nó tương đối dễ dàng để phát hiện ra nguyên nhân. Một bất lợi là nó có thể tốn nhiều thời gian vì phải phát triển và sử dụng trình điều khiển trong quá trình kiểm thử.

Trong kiểm thử tích hợp gia, một loạt các khả năng tồn tại, một phần tùy thuộc vào kiến ​​trúc hệ thống:

• Top-down (trên xuống): việc kiểm thử diễn ra từ trên xuống dưới, tuân theo luồng điều khiển hoặc cấu trúc kiến ​​trúc (ví dụ: bắt đầu từ GUI (giao diện người dùng) hoặc menu chính). Các thành phần hoặc hệ thống được thay thế bằng các stub.
• Bottom-up (dưới lên): việc kiểm thử diễn ra từ dưới cùng của luồng kiểm soát trở lên. Các thành phần hoặc hệ thống được thay thế bởi drivers.
• Gia tăng chức năng: việc tích hợp và kiểm thử diễn ra trên cơ sở các chức năng như được ghi trong đặc tả chức năng.

Trình tự tích hợp ưu tiên và số lượng các bước tích hợp cần thiết phụ thuộc vào vị trí trong kiến ​​trúc của các giao diện rủi ro cao.

Sự lựa chọn tốt nhất là bắt đầu tích hợp với những giao diện được cho là sẽ gây ra hầu hết các vấn đề. Làm như vậy sẽ ngăn ngừa được lỗi lớn ở cuối giai đoạn kiểm thử tích hợp. Để giảm nguy cơ phát hiện lỗi muộn, việc tích hợp thường nên tăng dần thay vì “big-bang”.

Lý tưởng nhất là người kiểm thử nên hiểu kiến ​​trúc và ảnh hưởng đến việc lập kế hoạch tích hợp. Nếu các bài kiểm thử tích hợp được lên kế hoạch trước khi các thành phần hoặc hệ thống được xây dựng, chúng có thể được phát triển theo thứ tự cần thiết để kiểm thử hiệu quả nhất.

Ở mỗi giai đoạn tích hợp, người kiểm thử chỉ tập trung vào chính quá trình tích hợp. Ví dụ, nếu họ đang tích hợp thành phần A với thành phần B, họ quan tâm đến việc kiểm tra giao tiếp giữa các thành phần, chứ không phải chức năng của một trong hai thành phần.

Cả hai phương pháp tiếp cận chức năng và cấu trúc có thể được sử dụng. Kiểm thử các đặc tính phi chức năng cụ thể (ví dụ: hiệu suất) cũng có thể được đưa vào kiểm thử tích hợp. Kiểm thử tích hợp có thể được thực hiện bởi các nhà phát triển, nhưng có thể được thực hiện bởi một nhóm chuyên gia kiểm thử tích hợp riêng biệt hoặc bởi một nhóm chuyên gia gồm các nhà phát triển/tích hợp bao gồm cả các chuyên gia phi chức năng.

Phần tiếp theo sẽ trình bày về các cấp độ kiểm thử 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