Tiểu luận môn kiểm chứng phần mềm Testing Applications on the Web

KIỂM CHỨNG
PHẦN MỀM
GVHD Th.s Nguyễn Công Hoan
Lớp: SE208.D22
GIỚI THIỆU VỀ NHÓM

Số thứ tự nhóm: 7

Các thành viên:
Trần Đạt 10520252
Phạm Văn Tú 10520254
NỘI DUNG SEMINAR
“Testing Applications on the Web: Test
Planning for Mobile and Internet-Based
Systems Second Edition”

Chương 11: Functional Tests

Chương 13: Using Scripts to Test
KIỂM THỬ
CHỨC NĂNG

Hiểu được kiểm thử chức năng là gì

Nắm bắt được các dạng kiểm thử
cũng như các kỹ thuật được sử dụng
trong kiểm thử chức năng và ứng
dụng trong kiểm thử web
KIỂM THỬ CHỨC NĂNG

Khái niệm

◦
Kiểm thử chức năng (Functional test) một
dạng của kiểm thử hộp đen mà các test case
của nó được thiết kế dựa trên các đặc tả của
các thành phần chương trình cần kiểm thử.
◦
Kiểm thử chức năng kiểm tra các chức năng
bằng cách cung cấp các thông số đầu vào và
kiểm tra các kết quả xuất ra.

Quy trình thực hiện chung
◦
Xác định chức năng cần kiểm thử
◦
Tạo dữ liệu đầu vào dựa trên đặc tả của chức
năng đó
◦
Xác định dữ liệu đầu ra cũng dựa trên đặc tả
chức năng
◦
Tiến hành kiểm thử
◦
So sánh kết quả thực tế với kết quả mong đợi
KIỂM THỬ CHỨC NĂNG

Phân loại
◦
FAST
◦
TOFT

◦
Forced-error
◦
Boundary
◦
Exploratory
◦
Software attack
KIỂM THỬ CHỨC NĂNG
FUNCTIONAL ACCEPTANCE SIMPLE TEST

Đại diện cho mức độ thứ hai của kiểm thử
chấp nhận (acceptance testing)

Kiểm tra các tính năng chính có thể truy
cập và hoạt động đúng hay không

Bao gồm các bộ test case đơn giản

Không hỗ trợ kiểm thử mối kết hợp giữa
các chức năng

Bản build có thể bị loại bỏ trong khi FAST
FUNCTIONAL ACCEPTANCE SIMPLE TEST

Cách thực hiện
◦
Phân rã chức năng xuống mức chỉ thị
◦
Áp dụng các test case để kiểm tra các chỉ thị

đã được phân rã
◦
Không quan tâm tới sự kết hợp của các chỉ
thị, bối cảnh được tạo ra bởi sự kết hợp này
hay kết quả cuối cùng của chức năng
FUNCTIONAL ACCEPTANCE SIMPLE TEST

FAST trong kiểm thử UI
◦
Là một trong những mục tiêu của FAST
◦ Bao gồm:

Kiểm tra sự tồn tại của đối tượng UI

Kiểm tra trạng thái mặc định

Kiểm tra giá trị mặc định, chế độ lựa chọn

Kiểm tra tab order

Kiểm tra phím tắt, phím truy cập
FUNCTIONAL ACCEPTANCE SIMPLE TEST

FAST trong kiểm thử Web
◦
Kiểm tra Link: content link, thumbnail link,
bitmap link
◦
Kiểm tra các điều khiển cơ bản: điều hướng
back/forward, zoom, làm mới nội dung

◦
Kiểm tra hành động: thêm, xoá sửa dữ liệu; tạo
tài khoản/hồ sơ người dùng
◦
Các tính năng khác: Đăng nhập/đăng xuất,
thông báo qua email, tìm kiếm
FUNCTIONAL ACCEPTANCE SIMPLE TEST
TASK-ORIENTED FUNCTIONAL TEST

Kiểm tra các tác vụ mà chức năng thực
hiện, đảm bảo các tác vụ đó thực hiện
chính xác

Chứa các test case ‘tích cực’

So sánh với đặc tả, tài liệu yêu cầu phần
mềm hoặc kỳ vọng của người dùng
TASK-ORIENTED FUNCTIONAL TEST

TOFT test case xây dựng dựa trên
◦
Danh sách các chức năng, tính năng cần được test
◦
Các yêu cầu phi chức năng

Mỗi chức năng cần xét
◦ Tính hợp lệ của các tác vụ mà nó thực hiện
◦
Tính toàn vẹn của kết quả cuối cùng
◦

Tính toàn vẹn của tính năng khi sử dụng kết hợp
với các tính năng khác
TASK-ORIENTED FUNCTIONAL TEST

Các bước thực hiện
◦
Xây dựng danh sách các tính năng cần kiểm
thử (bao gồm mọi chức năng, tính năng)
◦
Thiết kế test case dựa trên mỗi mục của danh
sách được lập, kiểm tra với các đặc tả của
chức năng hoặc trong tài liệu yêu cầu hệ
thống, hướng dẫn người dùng (nếu có)
◦
Tiến hành kiểm thử và đánh giá kết quả
TASK-ORIENTED FUNCTIONAL TEST
FORCED-ERROR TEST

Tìm ra tất cả các lỗi bằng cách cố ý đẩy
phần mềm vào các điều kiện có thể gây
lỗi.

Chứa các test case ‘tiêu cực’

Thực hiện khi và chỉ khi các lỗi đã được
xử lý, thông điệp xuất ra đã được code

Ví dụ: FET trong textfield/textbox?

Cách xây dựng danh sách lỗi

◦
Từ phía các deverloper
◦
Từ đặc tả
◦
Từ các tập tin tài nguyên
◦
Phân tích mỗi sự kiện dựa trên các trường hợp lỗi
có thể xảy ra
◦
Sử dụng kinh nghiệm
◦
Sử dụng ma trận kiểm chứng đầu vào tiêu chuẩn
FORCED-ERROR TEST

Các bước thực hiện kiểm tra lỗi
◦
Đẩy chương trình vào điều kiện lỗi
◦
Kiểm tra logic phát hiện lỗi
◦
Kiểm tra logic xử lý lỗi
◦
Kiểm tra thông báo lỗi
◦
Kiểm tra các vấn đề khác
FORCED-ERROR TEST

Chú ý
◦

L i có th x y ra m i n i trong 1 chu i x lýỗ ể ả ở ọ ơ ỗ ử
◦
M i thành ph n trong chu i có th không hoàn ỗ ầ ỗ ể
thành vi c xác đ nh và t ng tác l iệ ị ươ ỗ
◦
M i thành ph n trong chu i có th không hoàn ỗ ầ ỗ ể
thành vi c truy n l i t i thành ph n k ti pệ ề ỗ ớ ầ ế ế
◦
Thông đi p thông báo c n d hi u, đúng n i dungệ ầ ễ ể ộ
FORCED-ERROR TEST
BOUNDARY CONDITION TEST

Là mở rộng của TOFT và FET
EXPLORATORY TESTING

Là vi c ki m th các test cases và t o ra ệ ể ử ạ
nh ng test cases m i khác d a trên ữ ớ ự
thông tin nh n đ c t các l n ki m th ậ ượ ừ ầ ể ử
tr c đó.ướ

Còn đ c g i là unstructured testing ượ ọ
ho c ad hoc testingặ

Các b c th c hi nướ ự ệ
◦
Cài đ t môi tr ngặ ườ
◦
T o ta d li u đ u vàoạ ữ ệ ầ
◦
Ki m th ch ng trìnhể ử ư ơ

◦ Quan sát d li u đ u raữ ệ ầ
◦
Đánh giá k t quế ả
◦
Ti n hành các ki m th k ti p d a trên k t ế ể ử ế ế ự ế
qu đánh giáả
EXPLORATORY TESTING
SOFTWARE ATTACK

“How to Break Software: A Practical
Guide to Testing” - James A. Whittaker

21 kiểu “tấn công” phần mềm

Nhập đầu vào, buộc thông báo lỗi phải
xuất hiện

Nhập đầu vào, buộc chương trình phải
thiết lập giá trị mặc định
SOFTWARE ATTACK
Trên Windows ME, Powerpoint 2000
Chèn MSVSA Button Class Object
Thông qua menu Insert/Object
Word 2000, Insert/Index and
Tables/Table of Contents,
Chọn “Options” và Enter.