Công cụ hỗ trợ kiểm thử (CAST) Tài liệu ISTQB (SLIDE06) - misaphan/STQA-khoai-team GitHub Wiki
CÔNG CỤ HỖ TRỢ KIỂM THỬ (CAST)
Bộ môn: Kiểm thử vào đảm bảo chất lượng phần mềm.
Giảng viên: PGS.TS Trương Anh Hoàng
Nhóm 42:
- Ngô Quốc Thắng
- Phan Bá Mỹ
- Nguyễn Hoàng Quân
- Phạm Văn Bộ
Các công cụ được sử dụng trong quá trình phát triển phần mềm được thể hiện ở
Hình 1.
Hình1.
- Công cụ kiểm thử yêu cầu
- Công cụ phân tích tĩnh
- Công cụ kiểm thử thiết kế
- Công cụ kiểm thử dữ liệu
- Công cụ kiểm thử vận hành
- Công cụ so sánh
- Kiểm thử harnesses và driver
- Công cụ kiểm thử hiệu năng
- Công cụ phân tích động
- Công cụ gỡ lỗi (debugging)
- Công cụ quản lí
- Công cụ phân tích độ bao phủ
Công cụ kiểm thử này hỗ trợ tự động cho việc xác minh và phê chuẩn những yêu cầu theo mẫu có sẵn, kiểm tra tính nhất quán.
Công cụ kiểm thử mang một số đặc điểm sau:
- Cung cấp 1 phần thông tin và chất lượng phần mềm
- Mã nguồn sẽ được phân tích để tìm các lỗi hay gặp mà không cần phải thực thi
- Mục tiêu đo lường:
- Độ phức tạp lốc xoáy
- Vấn đề khác: mức độ lồng nhau, dung lượng
Công cụ này được sử dụng nhằm sinh ra các ca kiểm thử đầu vào, có thể từ đặc tả chính thức hoặc từ mã nguồn.
Công cụ kiểm thử phục vụ thao tác với dữ liệu có những đặc điểm:
- Được chọn từ những tệp hoặc cơ sở dữ liệu đã có
- Được tạo ra theo một số chuẩn
- Được chỉnh sửa từ những nguồn khác nhau
- Thực hiện/thực thi các ca kiểm thử
- Giám sát việc thực hiện từng ca kiểm thử
- Kịch bản kiểm tra được viết bằng ngôn ngữ của chương trình
- Bộ giá trị đầu vào, giá trị đầu ra mong muốn, và giá trị đầu ra thực tế nhằm tạo báo cáo kiểm thử
- Thường thấy trong tự động hóa kiểm thử hồi quy
- Dựa vào thuộc tính:
- Mô phỏng tương tác người dùng với các thiết bị đầu cuối
- Bắt sự kiện cho các phím tổ hợp và màn hình hồi đáp.
- GUI (Giao diện người dùng)
- Mô phỏng tương tác người dùng cho những ứng dụng WIMP(Windows, Icons, Mouse, Pointer)
- Bắt sự kiện cho chuyển động chuột, nhấp chuột, hay dữ liệu được nhập từ bàn phím
- Bắt các màn hình, hình ảnh, kí tự, trạng thái của đối tượng
- Phát hiện sự sai khác giữa kết quả kiểm thử thực tế và kết quả mong muốn
- screens, characters, bitmaps
- masking and filtering
- Thường dùng cho những phần mềm không có giao diện người dùng
- Thường chạy một nhóm các ca kiểm thử tự động hoặc đánh giá
- Đôi khi được sinh ra theo số đo
- Sử dụng các bộ phỏng (bởi vì khi thực nghiệm trong môi trường thực tế sẽ tốn kém và nguy hiểm)
- Load generation
- Chạy ứng dụng qua giao diện người dùng hoặc test harness
- Khả năng chịu tải
- Thời gian hồi đáp cho yêu cầu người dùng thông qua giao diện
- Hỗ trợ cả kiểm thử đơn vị và kiểm thử tích hợp
- Cho phép sinh ra các ca kiểm thử từ mã nguồn và thực thi chúng nhằm phát hiện các lỗi lập trình
- Cho phép định vị các lỗi được phát hiện bởi một ca kiểm thử.
- Cho phép kiểm tra chạy chương trình ở mức chi tiết
- Chạy từng câu lệnh
- Đánh dấu breakpoints hoặc watchpoint ở bất kỳ câu lệnh nào
- Kiểm tra giá trị của biến hoặc dữ liệu khác.
- Quản lý của phần kiểm thử: kế hoạch, chi tiết và kết quả kiểm thử;
- Quản lý dự án trong quy trình kiểm thử, ví dụ như ước lượng, kế hoạch test và kết quả ghi lại;
- Công cụ quản lý thay đổi (bao gồm thứ tự công việc để phân bổ, sửa chữa và kiểm tra lại);
- Truy hồi (kiểm tra lại đến yêu cầu và thiết kế).
- Mục đích: xác định những phần nào trong cấu trúc phần mềm đã được kiểm thử trong cấu trúc phần mềm;
- Trong kiểm thử tĩnh, mã nguồn sẽ được đánh giá độ bao phủ của 1 bộ test.
- Công cụ ghi lại những phần được bao phủ, cũng như không được bao phủ bởi bộ test (theo dòng) và báo cáo lại;
- Các loại độ bao phủ khác nhau: bao phủ dòng lệnh, bao phủ nhánh, bao phủ điều kiện.
Việc văn bản hóa những gì người kiểm thử đã thực hiện đem lại nhiều lợi ích:
- Hữu dụng cho việc bắt những bộ test tùy biến (ví dụ: người sử dụng cuối)
- Có thể phát hiện lỗi phần mềm để làm lại. Một kịch bản chi tiết sẽ:
- Ghi lại các đầu vào thực tế
- Có thể được sử dụng bởi người hiểu biết kỹ thuật để thực thi bộ test tự động đảm bảo hơn. Lý tưởng cho các task thực hiện 1 lần
- Chẳng hạn như nhập một dữ liệu dài phức tạp
Kịch bản test được lưu lại sẽ khá khó hiểu vì suy cho cùng nó được viết bằng một ngôn ngữ lập trình, hơn nữa kịch bản cũng sẽ không đáp ứng được nhiều thay đổi trong phần mềm bởi một sự thay đổi đơn giản trong giao diện cũng có thể tác động đến rất nhiều kịch bản.
So sánh kiểm thử mạnh và kiểm thử nhạy
Hình 2.
Hình 3.
Kiểm chứng tự động hóa có thể được thực hiện bởi nhiều cách như: so sánh nhiều/so sánh ít, khả năng thay đổi/hiệu quả phát hiện lỗi. Kịch bản sẽ ngày càng trở nên phức tạp và sẽ có nhiều tác vụ kéo theo. Thông thường nhiều sự kiểm chứng hơn có thể được hoàn thành, sự tự động hóa sẽ làm cho việc kiểm thử đạt kết quả tốt hơn.
Công sức bỏ ra cho một mỗi ca kiểm thử tự động thường dao động trong một khoảng rất lớn, thường là từ 2 đến 10 lần so với kiểm thử bằng tay. Việc này phụ thuộc vào công cụ kiểm thử, môi trường, kĩ năng người sử dụng và phần mềm cần kiểm thử.
- Kiểm thử bằng tay không có kịch bản trước
- Kiểm thử bằng tay có kịch bản (không rõ ràng, mơ hồ)
- Kiểm thử bằng tay có kịch bản (chi tiết)
Quy trình này gồm các bước thực hiện:
- Bước 1: Xác định điều kiện để kiểm thử.
- Bước 2: Tính toán những đầu vào cụ thể.
- Bước 3: Nhập đầu vào (input)
- Bước 4: Kiểm tra phần mềm liệu đã hoạt động tốt.
Hình 4.
Quy trình này gồm các bước thực hiện:
- Bước 1: Đọc những gì phải làm trong việc kiểm thử
- Bước 2: Phân loại đầu vào (input)
- Bước 3: Nhập đầu vào
- Bước 4: Kiểm tra liệu phần mềm đã hoạt động tốt
Hình 5.
Dưới đây là một ví dụ cho một kịch bản còn thiếu chi tiết:
Hình 6.
Quy trình này gồm các bước thực hiện:
- Bước 1: Đọc những gì phải làm trong việc kiểm thử
- Bước 2: Nhập đầu vào (input)
- Bước 3: Kiểm tra xem liệu hệ thống đã hoạt động tốt
Hình 7.
Các bộ kiểm thử sẽ ngày một lớn cùng với đó chi phí bảo trì cũng sẽ tăng theo, công sức bỏ ra ngày một nhiều mà không mang lại lợi ích gì. Các bộ kiểm thử cũng có vòng đời của nó, có những trường hợp có thể xảy ra như các kiểm thử viên rời đi, người mới đến, bộ kiểm thử sẽ ngày càng lớn trong khi không thể biết hết được chính xác những việc làm cũng từng người.
Trong suốt quá trình kiểm thử, những ca kiểm thử không quan trọng phải được lược bớt, đồng thời cần tính toán chi phí, lợi ích các hoạt động.
Công việc kiểm thử cần có sự đầu tư lớn về chi phí, công sức:
- Đảm bảo và bảo trì tài nguyên.
- Ủng hộ việc tự động hóa
- Hỗ trợ kĩ thuật
- Tư vấn/cho lời khuyên
- Phát triển vào bảo trì thư viện
- Phương pháp phân chia dữ liệu, sử dụng lại
Việc tự động hóa trong kiểm thử nên thực hiện khi chúng ta phải chạy các ca kiểm thử nhiều lần, khi ta nhận thấy làm thủ công sẽ rất tốn kém (về chi phí, thời gian, kiểm thử độ bền độ tin cậy). Khi việc kiểm thử quá phức tạp và rắc rối, tức khó để biểu diễn được thủ công thì cũng nên hướng tới tự động hóa.
Với những tác vụ mà việc chạy kiểm thử không quá thường xuyên hay các lỗi tìm ra khi kiểm thử không quá nghiêm trọng thì không nên thực hiện việc tự động hóa. Hay đơn giản, chúng ta cần kiểm thử tính tiện dụng của sản phẩm (màu sắc có đẹp không, âm thanh hay không…) thì cũng không cần đến việc tự động hóa.
Có rất nhiều loại công cụ khác nhau hỗ trợ cho kiểm thử, được sử dụng cho tất cả các giai đoạn trong quá trình phát triển phần mềm. Việc tự động hóa trong kiểm thử đòi hỏi việc lập kế hoạch chi tiết và công sức, chi phí, thời gian lớn. Việc xác định để lựa chọn áp dụng phương pháp nào trong kiểm thử là rất quan trọng, giúp cho kiểm thử phù hợp với từng giai đoạn và đạt hiệu quả cao.