TEST BASIC

1.Khái niệm Test

Là quá trình thực hiện một chương trình (hay một phần của một chương trình) để tìm ra lỗi

Là bước quan trọng trong quá trình phát triển hệ thống giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã thoả mãn yêu cầu đề ra chưa

2.Tầm quan trọng của việc Test

Một phần mềm được làm ra không ai có thể đảm bảo nó không có lỗi

Testing sẽ tìm và phát hiện với mục đích cuối cùng là bảo đảm sản phẩm đến tay người dùng phải là tốt nhất, nhanh nhất, ổn định nhất

Hoạch định ra các chiến lược để đảm bảo sản phẩm làm ra đạt tiêu chí và kỹ thuật đề ra

Ghi nhận các ý kiến, đề xuất hoặc báo cáo hỏng hóc từ người dùng

3.Các phương pháp Testing

Black box test Black box test: hay còn gọi là test hộp đen

Test dựa trên hoạt động của chức năng, không đòi hỏi kiến thức về các code hoặc cấu trúc bên trong

Phương pháp này quan tâm tới việc thực hiện các chức năng (hành vi), dữ liệu đầu vào và kết quả đầu ra ra sao -> fải dự đoán khả năng có thể xảy ra và chuẩn bị các của dữ liệu Input

White box test Quan tâm tới cấu trúc và logic bên trong của đoạn mã -> cần có kiến thức về cấu trúc phần mềm

4.Các giai đoạn Test

• Unit Test a. Đặc điểm

•      Test ở mức thấp nhất
  

•      Sử dụng phương pháp test hộp trắng
  

•      Kiểm tra độc lập từng thành phần
  

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

•      Phát hiện các vấn đề tiềm ẩn hoặc lỗi kỹ thuật
  

b. Ví dụ

Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then … else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm tra và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.

Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng.

• Intergration test a. Đặc điểm

•      Kiểm tra cấu trúc (structure): Tương tự White Box Test, chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình
  

•      Kiểm tra chức năng (functional): Tương tự Black Box Test, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật
  

•      Kiểm tra hiệu năng (performance): Kiểm tra vận hành của hệ thống
  

•      Kiểm tra khả năng chịu tải (stress): Kiểm tra giới hạn của hệ thống
  

b. Ví dụ

Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng. Nhằm mục đích

Phát hiện lỗi giao tiếp xảy ra giữa các Unit. Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test). Vì trên thực tế, quá trình tích hợp các Unit thường phát sinh lỗi

• System test a. Đặc điểm

•      Kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không
  

•      Là Black box test
  

•      Được thực hiện độc lập bởi một nhóm test (test hệ thống)
  

b. Ví dụ

System Test bắt đầu khi tất cả các bộ phận của PM đã được tích hợp thành công. Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng.

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.

Sau khi hoàn thành Integration Test, một hệ thống PM đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc tester bắt đầu kiểm tra PM như một hệ thống hoàn chỉnh. System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với PM hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, PM thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

• Acceptance test a. Đặc điểm

•      Alpha test: người sử dụng kiểm tra phần mềm ngay tại nơi PTPM, lập trình viên ghi nhận lỗi hoặc phản hồi và lên kế hoạch sửa chữa
  

•      Beta test: Phần mềm được gửi tới cho người sử dụng để kiểm tra ngay trong môi trường thực, lỗi, hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa
  

b. Ví dụ

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh PM thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

Acceptance Test có ý nghĩa hết sức quan trọng. Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm tra gọi là Alpha Test và Beta Test. Với Alpha Test, người sử dụng (tiềm năng) kiểm tra PM ngay tại nơi PTPM, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, PM sẽ được gửi tới cho người sử dụng (tiềm năng) để kiểm tra ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình PTPM thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù PM đã trải qua tất cả các kiểm tra trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng.

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v… Tất cả tài liệu đi kèm phải được cập nhật và kiểm tra chặt chẽ. gyazo.com/cc786069a79805abc4f4ef28a763ca15

5.Process Test

Đầu vào

•      Yêu cầu của khách hàng, các tiêu chuẩn
  

•      Các yêu cầu thay đổi
  

•      SRS
  

•      Tài liệu thiết kế (ADD, DDD)
  

•      Chương trình
  

Đầu ra

•      Tài liệu: test plan, test case và procedures
  

•      List lỗi
  

•      Báo cáo test (test report)
  

Test Plan

•      Phạm vi test: Trạng thái và loại test?
  

•      Xác định yêu cầu cho test: Test sẽ làm gì?
  

•      Xác định chiến lược test: Thực hiện như thế nào?
  

•      Xác định nguồn lực và môi trường
  

•      Tổng hợp thông tin, lập kế hoạch Test
  

•      Xem xét và thông qua kế hoạch Test.
  

•      Tiêu chuẩn hoàn thành.
  

•      Công cụ (tool) sẽ sử dụng để Test
  

•      Đánh giá rủi ro và lập mức độ rủi ro cho các yêu cầu.
  

•      Chuyển giao test.
  

Test Specification

•      Test case
  

• Tài liệu bao gồm các giá trị input thực tế và kết quả mong đợi cho mỗi test case được thực hiện.

• Việc định nghĩa các test case là độc lập với việc thiết kế test để có thể sử dụng lại một cách đễ dàng.

•      Test procedure
  

• Định nghĩa tất cả các bước thực hiện test

Chạy hệ thống

Thực hiện các testcase

• Đưa ra các chỉ dẫn

Test Report

•      Định nghĩa các tài liệu
  

•      Tổng kết
  

•      Chỉ ra các mâu thuẫn, thay đổi
  

•      Đánh giá một cách toàn diện
  

•      Tóm tắt sơ lược kết quả
  

•      Ước lượng/Tổng kết các hoạt động
  

•      Phê chuẩn.
  

Viết TC hiệu quả Một testcase được cho là hiệu quả:

•      Test case hiệu quả là test case mà tìm thấy bug.
  

•      Tìm được nhiều bug khó.
  

•      Chỉ ra được những điểm ban đầu  mà khi thực hiện test không tìm ra vấn đề
  

•      Tuân theo đúng các con số thống kê bug
  

•      Theo dõi các lỗi theo các trường hợp đã được tìm thấy
  

Ưu tiên Test

•      Những vùng quan trọng nhất của phần mềm
  

•      Những vùng phần mềm hay được dùng nhất
  

•      Những vùng có đặc trưng riêng, khác biệt hẳn với các vùng khác của phần mềm
  

•      Những vùng phần mềm dễ bị ảnh hưởng nhất của các thay đổi vừa có (khi regression test)
  

•      Những lỗi dễ xảy ra nhất
  

•      Những lỗi (người dùng) dễ nhìn thấy nhất
  

•      Những loại lỗi khó fix nhất
  

•      Những loại lỗi mà tester biết rõ nhất
  

•      Những loại lỗi mà tester biết lờ mờ nhất
  

•      Positive test trước, negative test sau (test các trường hợp hợp lệ trước, các trường hợp không hợp lệ sau)