A. TỔNG QUAN

– Phân loại kiểm thử:

  • Kiểm thử đơn vị (Unit Testing)
  • Kiểm thử tích hợp (Integration Testing)
  • Kiểm thử hệ thống (System testing)
  • Kiểm thử chấp nhận (Acceptance Testing)

 1. Kiểm thử đơn vị

  • Một đơn vị là một thành phần nhỏ nhất của phần mềm có thể kiểm tra được.
  • Functions, Procedures, Classes, và Methods —> “đơn vị”
– Ví dụ :
  • C++ or Java: lớp (Class)
  • C: hàm hoặc chương trình con
  • Pascal: hàm hoặc thủ tục
  • 4GL: Menu hoặc GUI
 – Nội dung Kiểm thử đơn vị:
  • Giải thuật và logic
  • Cấu trúc dữ liệu
  • Giao diện
  • Các nhánh độc lập
  • Giá trị biên, điều kiện biên
  • Bẫy lỗi và kiểm soát lỗi
 – Qui trình:
untitled

2. Kiểm thử tích hợp

– Kiểm thử tích hợp là tổ hợp các thành phần của một phần mềm (tạo thành một chức năng đầy đủ).
  • Làm thế nào –> các thành phần (đơn vị) làm việc với nhau.
– Mục đích:
  • Phát hiện lỗi trong giao diện.
  • Ráp các đơn vị riêng rẽ –> hệ thống con + hệ thống hoàn chỉnh cuối cùng.
 3. Kiểm thử hệ thống
– Kiểm tra thiết kế+hệ thống —> thỏa mãn đặc tả
– Đơn vị –> Tích hợp –> Hệ thống
 4. Kiểm thử chấp nhận
  • Đánh giá phần mềm —> mục đích+kỳ vọng của họ.
  • ––> Xác định mức độ thỏa mãn các yêu cầu.
  • – Hệ thống —> Chấp nhận.
– Thực thi trong thế giới thực (phần mềm, phần cứng)
– Nếu cho thị trường lớn –> 2 bước:
  • Alpha test: trên máy nhà phát triển.
  • Beta test: người dùng install và dùng thử trong thế giới thực.
 5. Các mô hình
– KT Chữ V
– KT Hồi qui:
  • Trên một phiên bản mới
  • Kiểm tra thay đổi –> đúng đắn
  • Đảm bảo code ko lỗi

– KT Xác nhận:

  • Validation testing
    • Chỉ ra –> phần mềm đúng, thỏa yêu cầu
    • Chỉ ra –> hệ thống vận hành như mong đợi.
  • Defect testing
    • Tìm lỗi –> hành vi –> không đúng / không thỏa đặc tả;
    • Chỉ ra –> không hoạt động đúng và làm xuất hiện lỗi.
 6. Chính sách
– Vét cạn –> có thể sạch lỗi. Tuy nhiên vét cạn là không thể
–> cách thức tiếp cận để kiểm thử có hệ thống và bao quát, cần test :
  • Tất cả chức năng truy cập từ menu
  • Tổ hợp các chức năng truy cập trên cùng menu
  • Input –> test với dữ liệu đúng và dữ liệu sai.
7. Nguyên tắc
– Chọn các dữ liệu test để lộ ra lỗi
  • Chọn đầu vào làm cho hệ thống sinh ra các thông báo lỗi
  • Thiết kế input sao cho tràn buffer, tràn số,…
  • Lặp lại cùng input vài lần
  • Chọn dữ liệu vào làm sinh ra output sai
  • Chọn dữ liệu vào làm sinh tính toán quá lớn hoặc quá nhỏ
 8. Loại kiểm thử
– Kiểm thử chuần mực  (Benchmark test)
  • so sánh hiệu năng của một đối tượng cần test với một chuẩn mực đã biết.
– Kiểm thử cấu hình (Configuration test)
  • Kiểm tra với các cấu hình phần mềm/cứng khác nhau.
– Kiểm thử chức năng  (Functional test)
  • –> hoạt động đúng như mong đợi.
– Kiểm thử cài đặt (Installation test)
  • Cấu hình, môi trường và điều kiện khác nhau (ví dụ thiếu không gian đĩa)
– Kiểm thử tính toàn vẹn (Integrity test)
  •  Kiểm tra tính tin cậy, chắc chắn và sức chịu đựng lỗi trong khi thực thi.
– Kiểm thử tải (Load test)
  • Điều kiện vận hành: số user, số transaction với cùng một cấu hình.
– Kiểm thử hiệu năng (Performance test)
  • Các cấu hình khác nhau với cùng điểu kiện vận hành
Stress test
  • Điều kiện bình thường và bất thường (ví dụ không đủ nguồn lực, số user cực kỳ cao)
– Các loại test khác
  • Security testing
  • Recovery testing
  • Usability testing
  • Compatibility testing
– Các kiểu kiểm thử đòi hỏi trong một project dựa trên:
  • Nhu cầu của project
  • Nhu cầu của khách hàng
  • Các cải tiến cho tương lai

9. Kiểm thử hộp đen

  • functional, data-driven, input/output driven testing
  • Dựa trên đặc tả
– Nó chỉ ra trạng thái của thành phần được test với các input, output và một đặc tả.
  • Dùng để xác định rằng chương trình hoạt động đúng (hoặc sai) đặc tả
10. Kiểm thử hợp trắng
  • Khảo sát cấu trúc điều khiển /logic chương trình
– Thường dùng với kiểm thử đơn vị
– Thực hiện bởi người phát triển kiêm tester
– Mục tiêu: kiểm tra thành phần (đơn vị) bằng cách khảo sát tất cả các đường đi/nhánh chương trình.
 11. Chu trình kiểm thử
  1. Phần tích yêu cầu: kiểm thử phải bắt đầu từ giai đoạn đặc tả phần mềm.
  2. Phân tích thiết kế : trong giai đoạn thiết kế, tester làm việc với developper để xác định các đặc trưng cần test và test được cùng với các tham số cần thiết.
  3. Lập kế hoạch test: chọn chiến lược, lập kế hoạch, tạo ra các yêu cầu test.
  4. Phát triển test: qui trình test, kịch bản test, Test Cases, Test Scripts dùng để test.
  5. Thực hiện test: thực hiện test theo kế hoạch ghi nhận và báo cáo lỗi cho bộ phận phát triển.
  6. Báo cáo test: sau khi hoàn tất test, tester làm các độ đo cần thiết và làm báo cáo tổng kết về công việc test đồng thời xác định phần mềm có thề release được hay không (dựa vào chuẩn) .
  7. Test lại sau khi sửa đổi
 12. Các công việc
– Kế hoạch kiểm thử:
  • Xác định phạm vi công việc cần làm (test)
  • Qui trình test: tài liệu xác định cách thức tiến hành.
  • Báo cáo Test (Report): tài liệu ghi nhận trạng thái của test khi thực hiện
 – Ước lượng công việc: trả lời các câu hỏi
  • Cần bao nhiêu test?
  • Phát triển các test bao lâu?
  • Thực hiện các test bao lâu?
  • Cần bao nhiêu thời gian/người?
 13. Fault, error and failure 
– Software Fault : một sai sót (defect) tĩnh trong phần mềm
  • Ví dụ: quên cấp phát ô nhớ cho con trỏ
– Software Error : một trạng thái sai (bên trong) thể hiện một sai sót nào đó trong phần mềm.
  • Ví dụ: truy xuất con trỏ chưa được cấp phát bộ nhớ
– Software Failure : một hành vi không đúng, không mong đợi thể hiện ra bên ngoài
  • Ví dụ: chương trình bị treo (do truy xuất con trỏ không được cấp phát bộ nhớ)
 14. Test tự động
– Các Test được thực thi tự động
– 4 bước:
  1. Phân tích các trường hợp test và thiết kế test
  2. Viết tập lệnh test (Test Scripts)
  3. Kiểm tra tập lệnh test
  4. Đóng gói và giao cho khách hàng
– Dùng chủ yếu:
  • Hồi qui mỗi khi dịch và tích hợp hệ thống (build)
  • Hướng dữ liệu: dùng nhiều giá trị dữ liệu test cùng một hoạt động
  • Hiệu năng
  • Stress
  • Load
  • Special test, or customer required
  • Tests required detailed information from application internals (e.g., SQL, GUI attributes)
Ví dụ:  Junit trợ giúp test các chương trình Java.

B. CĂN BẢN VỀ KIỂM THỬ

1. Kiểm tra đặc tả
– Đặc tả là tài liệu text, không phải code
  • Không thực thi được
  • Kỹ thuật test tĩnh (static): đọc, xem xét, duyệt
  • Không cần đi sâu vào tìm lỗi nhưng sẽ đi sâu vào các vấn đề cốt lõi, tổng quan; tránh chi tiết
– Kiểm tra đặc tả là nghiên cứu đặc tả và làm cho đặc tả rõ hơn cái gì phần mềm phải làm.
– Nghiên cứu: thuật ngữ, chuẩn (theo luật), chuẩn kỹ thuật (công nghiệp), giao diện, an toàn.

– Kiểm tra dựa vào phần mềm “tương tự”

  • Scale: nhiều/ít chức năng/code hơn?
  • Complexity
  • Testablity: có đủ nguồn lực thực hiện test (CSVC, thời gian, chuyên gia)
  • Quality/Reliability: software có khả năng đạt được chất lượng tương tự (hoặc hơn hoặc kém)
  • Security: mức độ an toàn của các đối thủ cạnh tranh?
– Checklist
  • Đầy đủ
  • Chính xác
  • Rõ ràng (precise, clear)
  • Nhất quán
  • Thích đáng
  • Khả thi
  • Không mất chi phí (Cost-free)
  • Test được
 2. Kiểm thử hộp đen
– Một test
  • Đầu vào
  • Đầu ra kỳ vọng
  • Kết quả thực hiện và so sánh với kết quả kỳ vọng
– Test to pass
– Test to fail
– Phân lớp tương đương
– Kiểm thử dữ liệu
  • Giá trị
  • Điều kiện biên
  • Các kiểu điều kiện biên: first, last, min, max
  • Kiểm tra giá trị biên
  • Điều kiện con
  • Không thỏa, sai, không chính xác
– Kiểm tra trạng thái
  • – Các dòng logic
  • – Kiểm tra fail
  • Điều kiện hiếm
  • Bad timing
 – Xem xét code
  • Xem xét hình thức
  • Peer review
  • Walkthroughs
  • Inspection
  • Xem xét dựa trên chuẩn và hướng dẫn – Checklist
 – Các lỗi
  • Khai báo
  • Tính toán
  • Phép toán so sánh
  • Dòng điều kiểm – If … else. If (không else)
  • Truyền tham số sai
  • Dữ liệu vào ra
  • Lỗi khác: font, chuẩn (ASCII, Unicode)
 3. Các text đặc biệt
– Kiểm tra cấu hình
  • PC
  • Thành phần (card)
  • Ngoại vi
  • Giao diện (chuẩn giao tiếp)
  • Tùy chọn và bộ nhớ
 – Kiểm tra khả năng tương thích
– Khả năng tương thích: giao tiếp & chia sẻ đúng đắn với soft khác
  • Platforme
  • Chuẩn và guidelines
– Application version
  • Backward
  • Forward
– Chia sẻ dữ liệu
  • File import/export
  • Save as
  • Copy, cut, paste
 – Kiểm tra ngôn ngữ nước ngoài
  • – Từ/ hình ảnh có nghĩa
  • – Kích thước từ à thiết kế lại giao diện
  • – Phím nóng
  • – Các kí tự mở rộng: a, ả, ã
  • – Thứ tự đọc: trái à phải, phải à trái
  • – Hãy để code độc lập với text
  • – Data format:
  • Số 5.5; 5,5
  • Tiền tệ
  • Ngày tháng
 – Kiểm tra tính dùng được
  • Hợp chuẩn
  • Trực quan
  • Nhất quán
  • Mềm dẽo
  • Thuận tiện
  • Đúng đắn
  • Hữu ích
 – Kiểm tra tài liệu
  • Các tài liệu khớp nhau
  • Chính tả, soạn thảo
  • Hợp chuẩn
– Kiểm tra an toàn phần mềm
  • Secure product: bảo vệ tính riêng tư, toàn vẹn và sẳn dùng về thông tin của người dùng.
 – Kiểm thử web
  • Hộp đen
    • Text
    • Layout
    • Links
    • Đồ họa
    • Forms: Ràng buộc dữ liệu
  • Hộp trắng
    • Cấu hình và tương thích
      • Hardware
      • Browser
      • Plugins
      • Độ phân giải Video
      • Text size
    • Tính dùng được
 – Kiểm tra tải
  • Kiểm tra giới hạn khả năng của hệ thống
    • Số truy cập đồng thời
    • Lượng dữ liệu upload,…
  • Dùng các scripts/ chương trình giả lập
    • Viết bởi đội QA
    • Kiểm tra chức năng
  • Có thể chỉ ra
    • Các chức năng ẩn
    • Khả năng cực đại của hệ thống
    • Thiếu vắng data hoặc dịch vụ
    • Xác lập khả năng của hệ thống: Các yêu cầu phi chức năng

C. THIẾT KẾ CHƯƠNG TRÌNH KIỂM THỬ

1. Chung

– Kiểm thử có 4 bước:

  1. Chọn các chức năng kiểm thử: Phân tích yêu cầu
  2. Quyết định test như thế nào
  3. Phát triển test cases 
  4. Tạo Test oracle 

Lớp tương đường: Các lớp tương đương rời nhau hợp thành toàn bộ tập hợp đang xét

  •   S = S1 U S2 U … U Sn
  • Dùng lớp tương đương
    • Bao trùm các trường hợp
    • Tránh dư thừa

– Phương trình 3 ẩn: 3*4*2 = 24 test cases

2. Công cụ kiểm thử

– Lợi ích:

  • Dùng lại test cũ
  • Tốc độ nhanh
  • Chính xác và rõ ràng
  • Dùng tài nguyên hiệu quả
  • Có thể giả lập, lập tình được
  • Nhất quán: chuỗi test bao trùm các ứng dụng

– Công cụ:

  • Viewer and monitor
  • Driver
  • Stubs
  • Stress and load tools
  • Tạo ra nhiểu
  • Công cụ phân tích

3. Các kiểu test với công cụ

– Xác nhận code: Kiểm tra code hợp chuẩn
  • Qui cách viết code: đặt tên biến, các biến không dùng, style của code
  • Độ dài module
  • Mức lồng nhau của các cấu trúc
  • Cấu trúc bị cấm dùng, ví dụ GOTO
– Kiểm tra bao trùm
  • Số dòng lệnh được test, chưa được test
– Kiểm tra chức năng
  • Các test được lưu trữ trong CSDL và dùng lại trong test hồi qui
– Kiểm tra tải
  • Maximum load
  • Thay đổi cấu hình (phần cứng, phần mềm)
  • Kiểm tra các kịch bản khác nhau
– Ghi macro và thực hiện lại
– Viết các marco
– Dùng các công cụ phân tích
  • Bảng tính
  • Phân tích call graph

4. Test tự động

– Test tự động là gì?
  • Script, tool, framework
  • Thực hiện bằng máy, không phải bằng người
– Tại sao phải dùng test tự động?
  • Nhanh, ít công sức, có thể chạy ban đêm, có thể làm các công việc năng nề
– Khi nào dùng test tự động?
  • Tính ổn định của phần mềm y (regression test)
  • Nâng cấp khả năng phần mềm (load/stress/performance test)
– Làm thế nào để dùng?
  • Chọn công cụ thích hợp với tính chất của phần mềm
  • Chọn phạm vi test, phát triển các test case, cân bằng chi phí
  • Xây dựng và thực thi các test script.

5. Công cụ Test tự động

– Junit

– Quick Test Pro

vi → en
But is not exhaustive
en → vi
( Kiểm tra tải)