Tìm hiểu về các loại Test Level

Nội dung bài viết này được dịch từ Chương 2. Testing throughout the software life cycle trong cuốn Foundations Of Software testing (ISTQB certification) của các tác giả Rex Black, Erik Van Veenendaal, Dorothy Graham hi vọng sẽ giúp mọi người hiểu thêm về các loại Test Level cũng như áp dụng một cách tốt hơn trong công việc của mình.

1. Component testing

Component testing còn được biết đến với tên gọi là Unit, Module và Program testing. Component testing kiểm tra các hàm trong source code để tìm ra lỗi.

Phụ thuộc vào vòng đời phát triển của phần mềm, component testing có thể hoàn thành một cách độc lập từng phần một trong hệ thống. Thông thường ta sẽ sử dụng stub và drive để mô phỏng các interface giữa các component một cách đơn giản. Component gọi tới stub và sử dụng driver để gọi tới component.

Thông thường, component testing được tiến hành với việc truy cập vào source code của component đang test kết hợp với việc sử dụng một vài developer eviroment như là Unit test framework hoặc Debugging tool, và thực tế trong quá trình test còn cần đến sự hỗ trợ của cả lập trình viên, người đã code ra component đó. Đôi khi tùy thuộc vào mức độ rủi ro của component đang test , việc thực hiện component testing sẽ được tiến hành bởi một lập trình viên khác, người không code ra component đó. Lỗi thường được fix ngay sau khi chúng được tìm ra mà không cần lưu lại và quản lý một cách thông thường như ở các test level khác.

Một trong những cách khác để thực hiện component testing là sử dụng Extreme Programing (XP). Đó là chuẩn bị và chạy automation các test case trước khi code. Phương pháp này được gọi là test-first approach hoặc test-drive development. Cách tiếp cận này có tình lặp cao dựa trên vòng đời của việc phát triển test case. Sau khi chạy automation, nhưng đoạn nhỏ của code được xây dựng và tích hợp để tiến hành component testing cho đến khi nó pass.

2. Integration testing

Integration testing là quá trình kiểm thử interface (giao diện) giữa các thành phần và sự tương tác giữa những thành phần khác nhau trong hệ thống như là operating system, file system, hardwrare hay interface giữa các system. Chú ý rằng integartion testing cần được phân biệt với những hoạt động integartion khác. Intergation testing thường được tiến hành bởi một tác nhân integator, nhưng tốt nhất là nó nên được tiến hành bởi những tester intergration chuyên biệt hay test team integration.

Có nhiều hơn 1 level integration testing và nó có thể được tiến hành với các đối tượng khác nhau. Ví dụ:

• Component integration tesing: Kiểm thử sự tương tác giữa các component với điều kiện là các component này đã pass ở phần test component trước đó.
• System integration testing: Kiểm thử sự tương tác giữa các system khác nhau và các system này đã pass ở system testing trước đó. Trong trường hợp này, team phát triển có thể chỉ quản lý duy nhất một mặt của tương tác, nếu có bất kì sự thay đổi nào cũng dẫn đến sự bất ổn của phần mềm. Tiến trình nghiệp vụ được thực thi như workflow và có thể bao gồm một loạt các hệ thống.

Với những phạm vi test integration lớn, việc cô lập lỗi để xác định xem nó thuộc integration nào lại càng khó khăn hơn. Điều này dẫn đến nhiều cách tiếp cận integration test khác nhau. Một cách triệt để là cho mọi component và mọi system được tích hợp vào cùng mọt lúc, sau đó sẽ kiểm tra toàn thể mọi tính năng một lúc. Các tiếp cận này được gọi là Big-bang integration testing. Big-bang testing có một lợi thế là mọi thành phần phải được hoàn thành xong trước khi tiến hành kiểm thử integration. Do đó ta không cần phải giả lập những thành phần chưa hoàn thành xong. Tuy nhiên một điểm trừ lớn là hướng tiếp cận này tốn khá nhiều thời gian và khó để điều tra bug. Chính vì thế Big-bang có vẻ như là giải pháp hay để lên kế hoạch cho dự án và nếu như suy nghĩ một cách lạc quan rằng dự án không có vấn đề gì. Nếu nghĩ rằng integration testing sẽ tìm ra bug, sẽ tốt hơn nếu xem xét để tăng thêm thời gian ở quá trình thực hiện integration testing.

Một số phương pháp thực hiện integration testing:

• Top-down: Thử nghiệm diễn ra từ trên xuống dưới. Ví dụ như bắt đầu từ trình tự giao diện trên xuống hay bắt đầu từ main menu.

• Bottom-up: Thử nghiệm diễn ra từ dưới cùng của dòng điều khiển trở lên trên.

• Functional incremental: Tích hợp và thử nghiệm diễn ra trên cơ sở các hàm hoặc chức năng như là dựa trên tài liệu đặc tả hàm để làm cơ sở test.

Trình tự ưu tiên và và số lượng các bước thực hiện integration test phụ thuộc vào độ rủi ro cao thấp của interface giữa các phần. Lựa chọn tốt nhất đó là bắt đầu tích hợp với những interface có khả năng gây ra nhiều vấn đề nhất. Ở mỗi giai đoạn integration, tester tập chung duy nhất vào việc tích hợp, kiểm tra tương tác và giao tiếp giữa các phần. Ví dụ nếu tích hợp phần A với thành phần B, họ chỉ quan tâm đến việc trao đổi, giao tiếp giữa 2 thành phần mà không quan tâm gì đến chức năng của A hay chức năng của B. Integration testing cũng có thể sử dụng phương pháp tiếp cận chức năng (functional) và cấu trúc (structural). Kiểm thử integration có thể được thực hiện bởi developer, một test team chuyên biệt hay một nhóm chuyên developer/kiểm thử viên tích hợp bao gồm cả kiểm thử phi chức năng.

Một cách tốt nhất, tester nên hiểu được cấu trúc và phạm vi ảnh hưởng của hệ thống tích hợp trong integration testing. Nếu integation testing được lên plan trước component testing hay system testing thì đội phát triển sẽ xây dựng các component theo thứ tự phù hợp, sao cho integration testing được hiệu quả nhất.

3. System testing

System testing quan tâm tới hành vi của toàn bộ system/product như là xác định phạm vi của dự án, sản phẩm...System testing có thể dựa trên mức độ rủi ro, đặc tả yêu cầu, bussiness process, use case, hay những mô tả hành vi hệ thống ở mức cao như tương tác với hệ điều hành hay tài nguyên hệ thống để thực hiện. Đối với đội phát triển dự án, System testing là bước test cuối cùng để kiểm tra xem hệ thống chuẩn bị deliver đã thỏa mãn yêu cầu và mục tiêu hay chưa và tìm ra càng nhiều bug càng tốt. Hầu hết system test sẽ được tiến hành bởi một team test có chuyên môn, độc lập nhưng vẫn thuộc development team và báo cáo kết quả với quản lý dự án. Trong một số tổ chức dự án khác, system testing còn được tiến hành bởi một bên thứ 3 hoàn toàn tách biệt với development team hoặc một bên chuyên về phân tích nghiệp vụ (bussiness analyst). Tất nhiên mức độ độc lập này hoàn toàn phụ thuộc và độ rủi ro của dự án và việc lựa chọn độ độc lập như nào sẽ ảnh hưởng lớn đến việc tổ chức system testing.

System testing kiểm tra cả những yêu cầu chức năng và phi chức năng của hệ thống. Kiểm thử phi chức năng bao gồm performance và reliabiliy. Tester có thể phải kiểm thử trong trường hợp không có tài liệu đặc tả hoặc có nhưng không đầy đủ. System testing với những yêu cầu chức năng bắt đầu bằng việc sử dụng những phương pháp specification-base (black-box) phổ biến. Ví dụ như decision table sử dụng để kiểm thử với nhiều bussiness rule phải kết hợp với nhau. Phương pháp structure-base (White-box) có thể sử dụng để đánh giá một cách chi tiết các phần tử như là cấu trúc menu dialog hoặc chuyển hướng trang.

System testing yêu cầu một môi trường test phải kiểm soát được tất cả các yếu tố liên quan và một số yếu tố khác như là phiên bản của phần mềm, testware, testdata. System testing được chạy bởi tổ chức phát triển tại môi trường test. Môi trường test nên được thiết lập sao cho giống hoặc gần giống nhất với môi trường thật để giảm thiểu những rủi ro do đặc thù của môi trường gây ra.

4. Acceptance testing

Khi một tổ chức phát triển đã hoàn thành xong System testing, phần mềm sẽ được delivere cho khách hàng để tiến hành acceptance testing. Acceptance testing sẽ trả lời các câu hỏi như là : "Liệu rằng phần mềm có thể release không?", "Liệu rằng có còn các vấn đề rủi ro nào đáng lo ngại không? " "Dev đã làm đúng cái khách hàng cần hay chưa?". Acceptance testing hầu hết được tiền hành bởi người dùng hoặc khách hàng và đôi khi là cả stackholder. Thực thi acceptance testing yêu cầu môi trường test phải đầy đủ, đại diện cho môi trường sử dụng sau này.

Mục tiêu của acceptance testing là để lấy lại sự tin tưởng tự tin với phần mềm, những thuộc tính phi chức năng, tính usability của hệ thống. Acceptance testing hầu hết tập chung vào một loại test type để xác định xem liệu rằng hệ thống đã đáp ứng đủ những mục tiêu đã đặt ra hay chưa. Tìm ra bug không phải là mục tiêu chính của Acceptance testing. Việc tiến hành Acceptance testing cũng không nhất thiết phải tiến hành khi hệ thống đã đầy đủ cho việc sử dụng và cũng không nhất thiết là phải thực hiện cuối cùng sau các test level khác. Ví dụ Integration testing của một hệ thống lớn sẽ tiến hành sau khi Acceptance tesing từng thành phần đã hoàn thành.

Acceptance testing cũng được thực hiện ở nhiều test level khác. Hãy xem một số ví dụ sau:

• A Commercial Off The Shelf (COTS) software: Acceptance được tiến hành ngay sau những lần cài đặt hoặc sau khi tích hợp. Để hiểu thêm về A Commercial Off The Shelf (COTS) software các bạn có thể xem tại đây: http://www.businessdictionary.com/definition/commercial-off-the-shelf-COTS-software.html
• Acceptance testing có thể sử dụng để kiểm tra tính khả dụng của một component trong khi thực hiện Component testing
• Trước khi thực hiện System testing, acceptance testing kiểm tra chức năng từng thành phần xem đã đáp ứng mong muốn chưa

Chú ý rằng tổ chức phát triển phần mềm có thể sử dụng một team khác có chuyên môn riêng để thực hiện acceptance trước khi chuyển giao sản phẩm đến tay khách hàng.