Please enable JavaScript.

Coggle requires JavaScript to display documents.

TESTING OVERVIEW (2. Vai trò của tester (Vai trò của tester thành viên…

- - - - Phải giả định là có lỗi
      - Lấy mục tiêu là lỗi phần mềm, chứ không phải là chỉ ra phần mềm đang hoạt động đúng.
      - Không bao giờ chứng tỏ được rằng phần mềm không còn lỗi
      - việc test không nâng cao chất lượng phần mềm
    - - Là biết khi nào thì dừng lại!
      - Là quyết định thực hiện những test case nào cho hiệu quả!
- - - - Test leader
        
        làm test plan
        
        test evaluation report
        
        phân công tester
      - Test designer
        
        thiết kế test cases
        
        sắp xếp thứ tự test
      - Test worker
        
        thực hiện test
        
        làm test result report
- - - - Test dựa trên cấu trúc của code
    - - Test không quan tâm đến code, test
        dựa trên hành vi của hệ thống
  - - - Unit là phần nhỏ nhất có thể được compiled, linked, và
        loaded
      - Unit testing được thực hiện bởi Developer
      - Sử dụng phương pháp test hộp trắng
    - - Software Integration là quá trình hợp nhất các unit đơn lẻ
        vào thành một hệ thống (hoặc một tiểu hệ thống).
      - Integration testing là test các liên kết giữa các unit thành
        phần
      - Có 3 cách intergration: top-down, bottom-up, big-bang.
        Tương ứng là các cách test.
      - Integration testing đòi hỏi các module phải được unit test trước
      - Nếu có nhiều lỗi lẽ ra phải tìm thấy từ Unit testing, thì ngừng Integration testing, trả module nhiều lỗi về cho developer.
    - - Khi integration đã được hoàn tất
      - Sử dụng phương pháp test hộp đen
      - Test dựa trên requirements
      - Là sân của nhóm tester độc lập
      - Cần có một cơ chế để nhập inputs và quan sát reponses của
        hệ thống, ví dụ như GUI.
    - - System Requirements Specification
      - Interface Specifications
      - Users Guide
      - Use Cases
      - Customers
      - Domain Experts
      - Bug Data
      - Re-engineering
    - - Nên được gọi là Acceptance Demonstration thay cho
        Acceptance Test
      - Để chứng minh phần mềm đã đủ sẵn sàng để bàn giao cho
        khách hàng
      - Khi tất cả các testing stages khác đã được hoàn tất
      - Dựa trên cơ sở là toàn bộ hay một phần của system
        requirements
      - Các thủ tục test/demo phải được khách hàng chấp nhận
        trước khi thực hiện để nghiệm thu
    - - Nhằm tìm lỗi trong các phần “unchanged” của một software
        có các phần khác “changed”
      - Khi bảo trì hay nâng cấp phần mềm lên version mới
      - Khi tích hợp các phần của một phần mềm
  - - - Phân các test cases vào các class. Mỗi class là một nhóm các test cases tương tự nhau
      - Trong mỗi class chọn test chỉ một vài test case
      - Nên test nhiều class thay cho test nhiều test cases của cùng một class
      - Các class lại có thể xếp vào 2 nhóm
        
        Negative tests (dirty tests)
        
        Test nhằm tìm ra lỗi
        
        Test những trường hợp, hoàn cảnh sử dụng đặc biệt, bất thường (như
        invalid input, vượt quá trị biên, chịu stress,…)
        
        Positive tests (clean tests)
        
        Test dựa trên defined requirements
        
        Test những trường hợp, hoàn cảnh sử dụng thông thường
    - - Áp dụng cho các hệ thống xử lý giao dịch (như đặt vé máy bay, đặt phòng khách sạn, …)
      - Sử dụng mô hình xử lý của hệ thống, chú trọng đến điểm bắt đầu,điểm kết thúc của từng xử lý, chú trọng tới hàng đợi (queue)
    - - Áp dụng cho các xử lý mà có xác định phạm vi (range) giá trị dữ
        liệu
      - Chú trọng test các giá trị biên on và off
    - - Áp dụng trong whitebox testing: quan tâm đến vòng lặp trong code
      - Áp dụng trong backbox testing: quan tâm đến vòng lặp trong hành vi của hệ thống
    - - Test các câu lệnh (commands)
      - Test việc xử lý các trường phải tuân theo một định dạng xác định
      - trình tự thực hiện
        
        Phân tích, nắm rõ qui tắc syntax
        
        Thiết kế các positive test cases, sử dụng kỹ thuật Equivalence class partitioning
        
        Thiết kế các negative test
        
        Thực hiện test
    - - Áp dụng khi
        
        Test các “menu driven application”
        
        Test các hệ thống thiết kế bằng phương pháp hướng đối tượng
        
        Test bất cứ hệ thống nào có sơ đồ chuyển đổi trạng thái (state)
      - phương pháp
        
        Vẽ một sơ đồ chuyển đổi trạng thái cho đối tượng cần test
        
        Positive tests: thiết kế test cases cho từng lần chuyển đổi trạng thái
        
        Negative tests: thiết kế các test cases nhằm cố chuyển đổi trạng
        thái một cách bất hợp lệ
    - - Load testing: bắt hệ thống phải chịu tải lớn (thực hiện nhiều xử lý)
        
        Có nhiều client cùng lúc truy cập
        
        Có nhiều giao dịch cùng một lúc
        
        Xử lý file rất lớn
        
        Xử lý cùng lúc nhiều file
      - Stress testing: bắt hệ thống vận hành trong điều kiện bất thường
        
        Thiếu bộ nhớ
        
        Kết nối mạng bị ngắt khi đang vận hành
        
        Database server down
    - - Sử dụng sơ đồ luồng xử lý (control flow graph)
      - Đó là sơ đồ mô hình hoá hành vi của hệ thống, chứ không phải là
        sơ đồ mô tả các câu lệnh trong code
      - Áp dụng được cho hầu hết các phần mềm, và có hiệu quả
      - Áp dụng được trong mọi testing stages
    - - Áp dụng cho các hệ thống “data-intensive” (các hệ thống sản sinh báo cáo, thống kê, các hệ thống có tính toán thay đổi số liệu)
      - Phương pháp xây dựng test case
        
        Lập sơ đồ luồng dữ liệu (Data flow diagram)
        
        Lần theo từng đường dẫn trong sơ đồ
        
        Bắt đầu từ node output
        
        Lần ngược lại tới khi gặp node input
- - - - Xét xem liệu còn những thao tác nào khác dẫn cũng dẫn bug?
      - Tìm ra các thao tác tối thiểu dẫn đến bug
      - Để ý xem dữ liệu test , cấu hình (settings) hay các option hiện tại có gìđặc biệt?
- - - - Test không có tài liệu đầu vào
      - Test nhằm phát hiện và sửa lỗi được chút nào hay chút ấy
    - - Dự án quá gấp, không đủ thời gian cho nhóm phát triển lập tài liệu
      - Requirements không thể được xác lập rõ ràng
    - - Tích cực, mau chóng trao đổi với nhóm phát triển để nắm bắt được bài toán
      - Tham khảo các sản phẩm tương tự, nếu có thể
      - Thống nhất với nhóm phát triển danh sách những vùng trọng tâm
        cần test
      - Tranh thủ tiếp xúc với khách hàng, làm sáng tỏ những nghi vấn về yêu cầu, nghiệp vụ
      - Lập checklist cho việc test, nếu kịp
      - Tập trung test với cường độ cao
      - Thường xuyên review Mức độ khẩn cấp của các lỗi.
      - Làm các báo cáo ngắn và linh hoạt về tình trạng lỗi để thúc đẩy tiến độ fix lỗi.
      - Tranh thủ xây dựng và tận dụng các testing checklist sẵn có
- - - - Project Test Leader
    - - Càng sớm càng tốt, ngay từ khi nhóm dự án có Project Plan và
        Requirements Spec.
      - Quá muộn nếu làm Test plan khi cần bắt đầu thực hiện test
    - - Giới thiệu tài liệu
      - Sơ lược hệ thống cần test
        
        Các nhiệm vụ (mission) test trọng tâm
        
        Các định hướng (motivator) để test
      - Các item cần test
      - Chiến lược test
        
        Dùng phương pháp gì?
        
        Có các testing stages nào?
        
        Chọn những loại test nào?
        
        Sử dụng những kỹ thuật test nào?
        
        Sử dụng những công cụ nào?
        
        Các tài liệu, báo cáo test
        
        Các vai trò, trách nhiệm của nhóm test
        
        Tổ chức nhân sự và đào tạo
        
        Tiến độ dự kiến
  - - - Test Leader hoặc Tester
    - - Cần khi dự án đòi hỏi phạm vi test rộng, có nhiều test case phức
        tạp, cần có hướng dẫn chi tiết về kỹ thuật test
      - Làm khi đã có test plan và bắt đầu tạo test cases.
    - - Giới thiệu tài liệu
      - Tinh chỉnh, phát triển, chi tiết hoá chiến lược test
      - Liệt kê các test case cần có (mã và mô tả vắn tắt trường hợp test)
    - - Là tài liệu trình bày về các test case sẽ được thực hiện.
      - Ai làm Test case spec?
        
        Tester
      - Khi nào làm Test case spec?
        
        Làm khi đã có test plan.
        
        Trước khi bắt tay vào test.
      - Nội dung căn bản của Test case spec
        
        Giới thiệu tài liệu
        
        Phân nhóm và trình bày các test case. Thông tin về mỗi test case
        
        Mục đích thực hiện
        
        Các bước thực hiện
        
        Điều kiện trước khi thực hiện
        
        Kết quả mong muốn
        
        Dữ liệu test (nếu cần)
    - - Là tài liệu hướng dẫn chi tiết về các bước thực hiện một hoặc một số test case
      - Ai làm Test procedure spec?
        
        Tester
      - Khi nào làm Test procedure spec?
        
        Khi đã thiết kế các test case
        
        Trước khi bắt tay vào test
  - - - Là tài liệu ghi lại theo trật tự thời gian những sự kiện test đã được thực hiện và kết quả.
      - Khi nào làm Test log?
        
        Trong khi thực hiện test.
    - - Là tài liệu báo cáo kết quả thực hiện test.
      - Khi nào làm Test result report?
        
        Sau khi thực hiện test xong một test item
        
        Sau khi test được một khoảng thời gian nào đó
        
        Sau khi test xong một lượt của toàn hệ thống hay một tiểu hệ thống.
        
        Khi cần cung cấp thông tin cho người quản lý dự án
        
        Khi Test leader yêu cầu
      - Nội dung căn bản của Test result report
        
        Giới thiệu tài liệu
        
        Giới thiệu các test item mục tiêu
        
        Các test case dự kiến thực hiện
        
        Các test case đã thực hiện
        
        Kết quả chi tiết của việc thực hiện từng test case
        
        Thống kê tỉ lệ test case được thực hiện và tỉ lệ pass của các test
        case
        
        Đưa ra các change request
        
        Ghi chú về các hiện tượng cần theo dõi thêm
    - - Là tài liệu báo cáo kết quả test của sản phẩm, đánh giá chất lượng sản phẩm đã đủ tốt để release hay chưa?
      - Ai làm Test release report
        
        Test leader
      - Khi nào làm Test release report?
        
        Khi ngừng test một bản sản phẩm
        
        Khi cần kết luận sản phẩm có thể được release hay chưa?
      - Nội dung căn bản của Test Release Report
        
        Giới thiệu tài liệu
        
        Giới thiệu hệ thống được test
        
        Khái quát về kết quả test
        
        Đánh giá chung về hệ thống được test, kết luận release hoặc không.
        
        Đánh giá ảnh hường của môi trường kiểm tra
        
        Các nhận xét khuyến nghị
        
        Kết quả test chi tiết
        
        Các phụ lục: thống kê số lỗi, số test case được thực hiện,…