Types of Testing

Bài viết này tôi giới thiệu tới các bạn các loại testing type

I. Unit test

1. Khái niệm

• Unit testing của phần mềm được thực hiện trong suốt quá trình phát triển (coding) phần mềm.

• Mục tiêu của Unit testing là test độc lập 1 phần mã code và xác minh tính đúng đắn của nó. Trong lập trình Unit testing có thể là một chức năng riêng biệt

• Unit testing thường được thực hiện bởi lập trình viên

2. Tại sao phải unit test? Và tầm quan trọng của unit test?

• Đôi khi do tính chủ quan của lập trình viên, họ thường không kiểm tra lại đoạn code mình đã phát triển dẫn đến hư hại hệ thống hoặc trả ra kết quả không mong đợi. Những ảnh hưởng trên dẫn đến việc tốn kém thời gian và tiền bạc để sửa lỗi.

• Đồng thời việc unit test còn giúp lập trình viên tăng khả năng tối ưu hóa code của mình hơn, nâng cao khả năng tư duy về code.

3. Xây dựng unit test case

• Unit test thường được thực hiện tự động, nhưng vẫn có thể được thực hiện bằng tay. Phương pháp tiếp cận unit test có thể được thực hiện theo các bước sau:

  • Lập trình viên có thể viết một phần mã trong các ứng dụng chỉ để kiểm tra các chức năng. Sau này họ có thể đưa ra nhận xét và cuối cùng loại bỏ các mã kiểm tra khi các ứng dụng được thực hiện.

  • Họ cũng có thể thực hiện đôc lập các chức năng để kiểm tra nó một cách chặt chẽ hơn. Sử dụng test tự động để lập trình viên đưa các mã tiêu chuẩn, kết quả mong muốn vào để thực hiện unit test. Trong thời gian thực thi test case framework test sẽ ghi lại quá trình kiểm thử. Tùy thuộc vào mức độ nghiêm trọng của một sự thất bại, framework Đơn vị xây dựng trường hợp thử nghiệm.

  • Đơn vị kiểm tra thường được tự động, nhưng vẫn có thể được thực hiện bằng tay. IEEE không ủng hộ một trong khác. Một phương pháp thủ công để kiểm tra đơn vị có thể sử dụng một tài liệu hướng dẫn step-by-step.

4. Giới thiệu 1 số unit test tool

Có một số công cụ tự động để hỗ trợ unit test. Tôi sẽ cung cấp một vài ví dụ dưới đây:

• Rational Software - Phần mềm Rational của IBM có một tính năng kiểm tra đơn vị được gọi là "Kiểm tra thời gian thực". Phần mềm này có chứa một loạt các công cụ thử nghiệm cho nhiều hơn là chỉ unit test. Nó được sử dụng cho Ada, Java, C và C ++. Nó tạo ra các đơn vị xét nghiệm bằng kỹ thuật đảo ngược phần mềm. Hệ điều hành nó hỗ trợ bao gồm Windows, Linux, Solaris, HP-UX và AIX. Tham khảo: http://www-01.ibm.com/software/rational/ để tìm hiểu thêm.

• JavaScript Assertion Unit- Còn được gọi là jsAsserUnit, phần mềm miễn phí JavaScript công cụ unit test này có thể được sử dụng trên bất kỳ nền tảng hỗ trợ JavaScript. Tham khảo: http://jsassertunit.sourceforge.net/docs/index.html

• CUT - CUT là một phần mềm unit test miễn phí cho C, C ++ và Objective C. Nó rất tốt cho các kiểm thử phần mềm nhúng và ứng dụng máy tính để bàn trên hệ điều hành Linux và Windows. Tìm hiểu thêm tại sourceforge.net bằng cách vào http://sourceforge.net/projects/cut/~~V.

• Dotunit - Dotunit là một khung lưới đơn vị phần mềm miễn phí công cụ kiểm tra. Một phần của JUnit trên net framework Microsoft, Dotunit được sử dụng để tự động kiểm tra đơn vị trên các hệ thống cửa sổ. Đây là một công cụ từ sourceforge.net, vì vậy hãy tìm nó tại: http://dotunit.sourceforge.net/

5. Lợi ích của unit test

• Lập trình viên có thể hiểu rõ hơn về các chứa năng của hệ thống họ đang phát triển thông qua unit test.

• Unit test cho phép lập trình cấu trúc lại mã vào một ngày sau đó, và chắc chắn rằng các module vẫn hoạt động một cách chính xác. Unit test sẽ nhanh chóng được phát hiện ra các bugs, lỗi phát triển và fix ngay nó.

• Do có tính chất module nên unit test có thể thực hiện ngay sau khi hoàn thành 1 module mà không cần phải chờ cả hệ thống hoàn thành.

6. Kết luận

Như bạn có thể thấy, unit test chủ yếu được thực hiện bởi lập trình viên, nó có thể đơn giản hay phức tạp à tùy thuộc vào ứng dụng đang được phát triển. Unit test giúp cho code và mục đích sử dụng hệ thống được đảm bảo hơn, mang tính chuyên nghiệp hơn, do đó unit test được cho là cần thiết khi phát triển phần mềm.

**II. Integration Testing **

**1. Khái niệm **

• Integration Testing là công việc kiểm thử tích hợp 1 nhóm các module riêng lẻ với nhau.

• Một dự án phần mềm điển hình bao gồm nhiều module phần mềm, được code bởi nhiều người khác nhau. Tích hợp thử nghiệm tập trung vào kiểm tra truyền dữ liệu giữa các module.

2. Tại sao Integration Testing là cần thiết

Mặc dù mỗi module đều được unit test nhưng các lỗi vẫn còn tồn tại với các lý do khác nhau:

• Một Module nói chung được thiết kế bởi một lập trình viên có hiểu biết và logic lập trình có thể khác với các lập trình viên khác. Kiểm thử tích hợp là cần thiết để đảm bảo tính hợp nhất của phần mềm.

• Tại thời điểm phát triển module vẫn có thể có thay đổi trong spec của khách hàng, những thay đổi này có thể không được kiểm tra ở giai đoạn unit test trước đó.

• Giao diện và cơ sở dữ liệu của các module có thể chưa hoàn chỉnh khi được ghép lại

• Khi tích hợp hệ thống các module có thể không tương thích với cấu hình chugn của hệ thống

• Thiếu các xử lý ngoại lệ có thể xảy ra

4. Intergration test case

Kiểm thử tích hợp khác với các trường hợp kiểm tra khác, nó tập trung chủ yếu vào các giao diện & lưu lượng dữ liệu / thông tin giữa các module. Ưu tiên được trao cho các liên kết tích hợp chứ không phải là các đơn vị chức năng.

Ví dụ 1 trường hợp mẫu Integration Test cho các kịch bản sau đây: Ứng dụng có 3 module gồm: 'Login Page, 'mail box' và 'delete mail'.

Trong đó tập trung chủ yếu vào phần Mail Box: Kiểm tra tích hợp của nó để delete mail.

4. Cách tiếp cận / phương pháp / chiến lược của intergration test

** Phương pháp tiếp cận Big Bang**

Tại đây tất cả các thành phần được tích hợp cùng 1 lúc, sau đó sẽ tiến hành kiểm thử.

Ưu điểm:

Thuận tiện với các dự án nhỏ

Nhược điểm:

Khó khăn trogn việc phát hiện bug.

Có thể bỏ qua các bug giao diện nhỏ trong quá trình tìm bug

Mât thời gian dành cho tích hợp hệ thống nên làm giảm thời gian dành cho test.

Vì các module được kiểm thử cùng 1 lúc nên các module có nguy cơ bị cô lập trong quá trình kiểm thử

** Phương pháp tiếp cận Incremental **

Trong phương pháp này, kiểm tra được thực hiện bằng cách kết hợp hai hay nhiều module có liên quan một cách hợp lý. Sau đó, các phân hệ liên quan khác được thêm vào và kiểm tra sự hoạt động đúng đắn. Quá trình tiếp tục cho đến khi tất cả các module được tham gia và thử nghiệm thành công.

Quá trình này được thực hiện bằng cách sử dụng các chương trình giả gọi là Stub and Driver. Sơ khai và trình điều khiển không thực hiện toàn bộ logic lập trình các module nhưng chỉ mô phỏng giao tiếp dữ liệu với các module được gọi.

Stub: Được gọi bởi Module dưới Test.

Driver: Gọi Module để được kiểm tra.

Phương pháp Incremental được thực hiện bởi hai phương pháp khác nhau:

Bottom Up Top Down Bottom up Integration

Trong chiến lược Bottom Up, mỗi module ở mức thấp hơn được thử nghiệm với các module cao hơn cho đến khi tất cả các module đều được kiểm tra. Nó được sử dụng cho Driver testing

Thể hiện bằng biểu đồ dưới đây:

Ưu điểm:

• Thu gọn phạm vi bug dễ dàng hơn

• Không mất thời gian chờ tất cả các module được tích hợp

Nhược điểm:

• Module quan trọng của hệ thống có thể dễ bị lỗi

• Không giữ được nguyên mẫu đầu tiên của hệ thống

Top down Integration:

Trong tiếp cận từ trên xuống , kiểm tra được thực hiện từ trên xuống dưới theo dõi dòng kiểm soát của hệ thống phần mềm.

Nó được sử dụng cho Stub testing

Ưu điểm:

• Thu gọn phạm vi bug dễ dàng hơn

• Khả năng để có được một nguyên mẫu ban đầu.

• Modules quan trọng đang được thử nghiệm trên mức ưu tiên; lỗi trong thiết kế lớn có thể được tìm thấy và cố định đầu tiên.

Nhược điểm:

• Cần nhiều Stub.

• Module ở mức độ thấp hơn sẽ được kiểm tra không đầy đủ.

5. Các bước thực hiện test tích hợp

• Chuẩn bị Integration Test Plan

• Thiết kế các kịch bản thử nghiệm, trường hợp, và Script (Test Scenarios, Cases, and Scripts ).

• Thực hiện kiểm tra theo test case đã viết

• Theo dõi & tái kiểm tra các lỗi ở trên.

• Bước 3 và 4 được lặp đi lặp lại cho đến khi hoàn thành Integration là thành công.

6. Kết luận

Intergration test là 1 bước rất quan trọng trong suốt quá trình kiểm thử, phần mềm có được đảm bảo chất lượng hay không?hệ thống có vận hành theo đúng mong muốn người dùng hay không sẽ được kiểm tra qua bước này.

**III.System Testing **

1. Khái niệm

• System test là quá trình kiểm tra của một sản phẩm đã hoàn chỉnh và tích hợp đầy đủ.

• Thông thường 1 sản phẩm phần mềm chỉ được test trên 1 vì môi trường demo, nhưng system test đảm bảo cho hệ thống vận hành trên nhiều môi trường khác nhau, tích hợp với nhiều phần mềm và hệ thống khác nhau.

• System test thuộc loại kiểm thử hộp đen. System liên quan đến các hoạt động bên ngoài của phần mềm từ quan điểm của người sử dụng.

2. Tại sao system test là cần thiết?

System test sẽ thực hiện các công việc sau:

• Sau khi hoàn thành quá trình test tích hợp chúng ta cần phải kiểm tra thêm về độ tương thích và tương tác với các thiết bị ngoại vi bên ngoài của ứng dụng để kiểm tra tính khả dụng của nó.

• System test là việc xác minh kiểm tra kỹ lưỡng của mỗi đầu vào trong các ứng dụng để kiểm tra các kết quả mong muốn.

• Thử nghiệm các kinh nghiệm của người dùng với các ứng dụng.

3. Types of system testing

System test có hơn 50 loại, ở đây tôi chỉ giới thiệu 1 số loại system test điển hình sau:

• Usability Testing - Kiểm tra tính khả dụng của ứng dụng, chủ yếu tập trung kiểm tra sự dễ sử dụng, tính linh hoạt, tính thân thiện của sản phẩm.

• Load Testing - Kiểm tra tốc độ vận hành của sản phẩm, một sản phẩm tốt là 1 sản phẩm phải vận hành với tốc độ cao và có thể chịu được sức tải lớn khi có nhiều user truy cập.

• Regression Testing - Kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi xảy ra một thay đổi mã chính. Cụ thể, nó tìm cách phát hiện ra các hồi quy của phần mềm hoặc các lỗi cũ quay trở lại. Những hồi quy như vậy xảy ra bất cứ khi nào chức năng phần mềm trước đây đang hoạt động giờ tạm ngưng như đã định. Thông thường, những hồi quy xảy ra như một hệ quả không lường trước được những thay đổi chương trình, khi một phần mới của phần mềm được phát triển xung đột với mã tồn tại trước đó. Phương pháp phổ biến của kiểm thử hồi quy bao gồm chạy lại những kiểm thử trước đó và kiểm thử xem lỗi cố định trước đây tại sao lại xuất hiện. Độ sâu của kiểm thử phụ thuộc vào các nguy cơ và giai đoạn trong quá trình phát hành các tính năng bổ sung. Chúng có thể được hoàn tất khi thay đổi thêm vào đầu hoặc cuối bản phát hành, cũng có thể được có mức độ nguy hiểm thấp khi thực hiện kiểm thử tích cực trên mỗi tính năng.

• Recovery Testing - Kiểm thử phục hồi là kiểm thử được thực hiện sau khi có các sự cố hệ thống dẫn đến chương trình lỗi, không hoạt động được. Kiểm thử phục hồi được thực hiện để đảm bảo chương trình sau khi khắc phục lỗi trên không xảy ra bug

• Migration Testing - Kiểm thử di động được thực hiện để đảm bảo tính linh động của phần mềm, phần mềm có thể di chuyển được chuyển từ cơ sở hạ tầng hệ thống cơ sở hạ tầng hệ thống cũ để hiện tại không có bất kỳ vấn đề

• Functional Testing - Kiểm thử chức năng nhằm đảm bảo chức năng phần mềm được vận hành theo đúng mục đích đưa ra

• Hardware/Software Testing - Đây là khi các thử nghiệm tập trung chú ý về sự tương tác giữa các phần cứng và phần mềm trong quá trình thử nghiệm hệ thống.

4. Kết Luận

Trong quá trình hoàn thiện sản phẩm system test là vô cùng quan trọng, system test sẽ đảm bảo cho ứng dụng của bạn có khả năng tương thích cao với môi trường thực trước khi sản phẩm được ra mắt.