Hướng dẫn tạo Test Case (cơ bản)

    B1: Xác định mục đích test.

    Trước tiên, bạn cần hiểu rõ đặc tả yêu cầu của khách hàng. Khi bắt đầu viết TCs cho các tính năng của 1 hệ thống phần mềm, việc đầu tiên cần xác định đó là cần hiểu và xác định được yêu cầu của hệ thống.

    B2: Xác định hiệu suất testing. ( Dựa trên sự hiểu biết về hệ thống phần mềm)

    Để viết kịch bản thử nghiệm tốt, bạn nên được cần với quen thuộc với các yêu cầu chức năng. Bạn cần phải biết làm thế nào phần mềm được sử dụng bao gồm các hoạt động , tổ chức chức năng khác nhau.

    B3: Xác định các yêu cầu phi chức năng.

    Bước thứ ba là để hiểu những khía cạnh khác của phần mềm liên quan đến các yêu cầu phi chức năng (non-function) như yêu cầu phần cứng, hệ điều hành, các khía cạnh an ninh(security) phải được xem xét và điều kiện tiên quyết khác như các tập tin dữ liệu hoặc chuẩn bị dữ liệu thử nghiệm.

    Thử nghiệm các yêu cầu phi chức năng là rất quan trọng.

    Ví dụ: Kiểm tra số record có thể download xuống và thời gian tải file của chức năng export excel (Performance test).
    Kiểm tra việc đăng nhập vào hệ thống = session của user khác (security test)
    Ngoài ra, còn cần 1 số case liên quan tới behavior của người dùng như : Không cho đăng nhập sai quá 5 lần với các hệ thống banking, kiểm tra tính toàn vẹn của dữ liệu.

    B4: Xác định biểu mẫu cho TCs

    Các mẫu , các trường hợp thử nghiệm nên bao gồm giao diện UI, chức năng, khả năng chịu lỗi, khả năng tương thích và hiệu suất của một số chức năng. Mỗi thể loại nên được xác định phù hợp với logic của ứng dụng phần mềm.

    B5: Xác định tính ảnh hưởng giữa các nguyên tắc mô-đun(module),chức năng(function), màn hình (screen) .

    Trước tiên cần hiểu rõ chức năng thực hiện của 1 mô-đun và sự tương tác của mô-đun đó với các mô-đun khác để xác định được follow, sự khớp nối của hệ thống

    TCs nên được thiết kế để có thể che phủ được sự ảnh hưởng của các mô-đun với nhau ở mức độ cao nhất. Muốn biết được vấn đề đó, bận cần xác định rõ được tính năng của từng mô-đun riêng biệt, cách thức nó hoạt động tương tác với mô-đun khác như thế nào?

    1 số tips khi muốn xác minh độ ảnh hưởng:

    Ví dụ: Khi test chức năng giỏ hàng của 1 website thương mại điện tử để kiểm tra bạn ngoài việc kiểm tra số lượng, giá của sản phẩm có trong giỏ hàng, bạn cũng cần phải kiếm tra các tính năng liên quan của ảnh hưởng của nó nữa, như: người bán update/xóa thông tin của sản phẩm, sau khi thêm sản phẩm vào giỏ hàng thì số lượng hàng của người bán có bị giảm đi hay k? check việc tương quan giữa giỏ hàng và chức năng thanh toán…

    Format của 1 TCs thông thường bao gồm:

    Test Case ID : Giá trị cần để xác định số lượng trường hợp cần để kiểm thử.

    Chức năng (Function): Dựa theo chức năng của hệ thống có thể chia nhở các functions ra để tạo TCs rõ ràng hơn. Ví dụ: Check form đăng nhập gmail được coi là 2 function lớn.

    Test Data : Những dữ liệu cần chuẩn bị để test

    Test Steps : Mô tả các bước thực hiện test

    Expected results: Kết quả mong đợi từ các bước thực hiện trên

    A result: Thông thường sẽ là pass, fail, và pending. Đây là kết quả thực tế khi thực hiện test theo test case trên môi trường của hệ thống

    Comments : Cột này dùng để note lại screen shot, thông tin liên quan khi thực hiện test case.

    **Ngoài ra, có thể thêm 1 số cột như: ** Tester ( người thực hiện test), Execute Date ( ngày thực hiện test),…

    Với 1 giá trị cần kiểm tra luôn luôn có 3 trường hợp lớn cần kiểm tra có thể xảy ra.

    Từ các trường hợp lớn trên tùy theo từng giá trị cần kiểm tra sẽ xác định và chia ra thành các case nhỏ hơn tương ứng.

    B1: Xác định yêu cầu.

    Yêu cầu là test form login của facebook theo đường link: https://www.facebook.com/

    B2: Xây dựng TCs.

    Đối với email/ điện thoại textbox:

  • Normal case sẽ gồm: đăng nhập với đúng sdt, địa chỉ email đã đăng ký với hệ thống facebook trước đó và đăng nhập với blank, sai sdt, địa chỉ email đã đăng ký với hệ thống facebook trước đó.

  • Abnormal case sẽ gồm: Đăng nhập với số điện thoại mà thêm mã vùng, mã nước vào trước đó (ví dụ: +849….) hoặc email mà không nhập tố email cho nó ( email đúng là: nguyen.thi.hong.nhung). Ngoài ra, còn có các cases: ngắt mạng, mạng yếu, sử dụng 3G, wi-fi, mạng lan, ăn cắp cookie, session, đăng nhập trên nhiều trình duyệt …

  • Boundary case sẽ gồm: Text số lương ký tự tối thiểu và tối đa mà ô text cho nhập. Có thể tạo ra 1 email với nhiều ký tự để test, hoặc 1 email ngắn nhất có thể để test.( Với trường hợp này tôi ko kiểm tra tính đúng đắn của follow đăng nhập mà chỉ kiểm tra khả năng cho nhập tối thiểu và tối đa của ô text.)