Category: Basic knowledge

7 Nguyên tắc kiểm thử

Posted in Basic knowledgeLeave a comment

KIỂM THỬ CHỈ RA “CÒN LỖI”

  • Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi
  • Kiểm thử không thể chứng minh rằng phần mềm không có lỗi.

KIỂM THỬ VÉT CẠN LÀ KHÔNG THỂ

  •  Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể
  • Cần phân tích rủi ro và dựa trên sự mức độ ưu tiên để tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn.
Kiểm thử vét cạn tất cả trường hợp là không thể

KIỂM THỬ PHẢI BẮT ĐẦU SỚM
Các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong qui trình phát triển (vòng đời phát triển) phần mềm

Chi phí cho việc sửa lỗi sớm tăng theo tỷ lệ 1 – 10 – 100 theo giai đoạn phát hiện lỗi

LỖI QUẦN TỤ

  • Thông thường, lỗi tập trung vào những module, thành phần chức năng chính của hệ thống (nguyên tắc perato/ nguyên tắc tổ gián)
  • Nên tập trung vào tìm kiếm lỗi quanh khu vực được xác định
80% lỗi thường nằm ở 20% tính năng của phần mềm

TEST CASE CÙN DẦN THEO THỜI GIAN

  • Hiệu quả của các trường hợp kiểm thử bắt đầu giảm xuống sau một số lần thực hiện
  • Phải luôn xem xét và sửa đổi các trường hợp kiểm thử trên một khoảng thời gian thường xuyên
Test case luôn bị cùn dần theo thời gian

KIỂM THỬ THEO CÁC NGỮ CẢNH ĐỘC LẬP

  • Việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta phải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau
  • Mỗi ngữ cảnh cần có chiến lược kiểm thử phù hợp. Ví dụ:
    • Kiểm thử ứng dụng di động khác kiểm thử web/desktop
    • Kiểm thử cho quán cafe khác kiểm thử cho quán nhậu
Việc kiểm thử phải được đặt trong ngữ cảnh của người sử dụng

QUAN NIỆM SAI LẦM VỀ VIỆC “HẾT LỖI”

  • Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường
  • Có thể dừng test khi
    • Rủi ro về chất lượng ở mức chấp nhận đượcCác mục tiêu, chỉ tiêu đưa ra trong kế hoạch test đã đạt được

Khái niệm và Tầm quan trọng của kiểm thử

Posted in Basic knowledge, Software TestingLeave a comment

Lỗi phần mềm đầu tiên trong lịch sử

Vào ngày 9-9-1947, một chiếc máy tính Mark II ở trường Đại học Harvard đã không hoạt động. Sau khi kiểm tra, các kỹ sư đã phát hiện ra nguyên nhân – một con bướm đã mắc kẹt bên trong máy tính. Đây cũng chính là lỗi phần mềm đầu tiên trong lịch sử.

Bug đầu tiên trong lịch sử

Một số lỗi phần mềm đáng chú ý trong lịch sử

Năm 1991 Tên lửa Dhahran đã bắn vào căn cứ Mỹ ở Dhahran, A-rập Xê-út, làm chết 28 lính Mỹ do: pin của tên lửa Patriot được sử dụng cho phát hiện và đánh chặn tên lửa của đối phương bị đã chạy sai sau 100 giờ
Tàu thăm dò khí hậu Sao Hỏa được phóng lên vào năm 1998  đã bị phá hủy do ma sát với bầu khí quyển Sao Hỏa khi sai số lên đến 100 km bởi một lỗi dẫn đường (người điều khiển ở mặt đất đã sử dụng feet trong khi các phần mềm tính toán lại sử dụng hệ mét)
Trong năm 2014, GM đã triệu hồi gần 2,6 triệu xe do lỗi ở bộ phận đánh lửa khiến túi khí không bung ra trong trường hợp xảy ra tai nạn. GM xác nhận lỗi này khiến 124 người chết và 275 người bị thương và đã lập một quỹ độc lập để bồi thường cho các nạn nhân số tiền gần 600 triệu USD.

Tầm quan trọng của kiểm thử

  • Con người luôn mắc lỗi (mistake)
  • Phần mềm ngày càng đóng vai trò quan trọng trong đời sống, do đó lỗi phần mềm (fault) có thể gây ảnh hưởng nghiêm trọng, tổn thất về kinh tế, thậm chí tính mạng
  • Kiểm thử giúp phát hiện ra sai sót trong suốt quá trình phát triển, bảo trì sản phẩm nhằm giảm thiểu lỗi phần mềm trong quá trình sử dụng. Từ đó giúp đảm bảo chất lượng sản phẩm

Các khái niệm trong kiểm thử

  • Error (mistake): A human action that produces an incorrect result
  • Defect (bug, fault): A flaw in a component or system that can cause the component or system to fail to perfom its required function
  • Failue: Devisation of component or system from its expected delivery, service or result

Khái niệm kiểm thử

Là một quá trình bao gồm tất cả các hoạt động trong vòng đời sản phẩm liên quan tới việc lập kếhoạch, chuẩn bị và đánh giá các sản phẩm phần mềm và các sản phẩm có liên quan khác để xác định sản phẩm đó có thỏa mãn được những yêu cầu cụ thể hay không, đảm bảo các sản phẩm đó đáp ứng được mục tiêu và phát hiện ra lỗi.