Tìm hiểu kiểm thử phần mềm và ứng dụng vào website

TRƯỜNG ĐẠI HỌC VINH

KHOA CÔNG NGHỆ THÔNG TIN
--------------------------

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC
Tìm hiểu về kiểm thử phần mềm và ứng dụng vào website

Sinh viên thực hiện:
Trần Thị Hằng
Mã sinh viên:
0851070256
Lớp:
49K- Tin
Giáo viên hướng dẫn: TS. Phan Anh Phong

Nghệ An, tháng 12 năm 2012


Đồ án tốt nghiệp đại học
LỜI CẢM ƠN
Lời đầu tiên em muốn nói là em xin chân thành cảm ơn sự hướng dẫn tận tình
của thầy Phan Anh Phong, khoa Công nghệ thông tin trường Đại học Vinh. Trong suốt
thời gian thực hiện đồ án thầy đã giành nhiều thời gian và tâm huyết trong việc hướng
dẫn em. Trong quá trình thực hiện thầy ln định hướng, góp ý và sửa chữa sai sót
giúp em khơng bị lạc lối trong biển kiến thức mênh mông.
Em cũng xin chân thành cảm ơn các thầy cô trong khoa Công nghệ thông tin,
cũng như thầy cô trong trường đã giảng dạy, giúp đỡ em trong 5 năm học qua. Chính
các thầy cơ đã xây dựng cho chúng em những kiến thức nền tảng và những kiến thức
chun mơn để em có thể hồn thành đồ án này cũng như cơng việc của mình sau này.
Em cũng xin chân thành cảm ơn các anh chị trong công ty FPT software và các

bạn trong lớp 49k-Tin cùng gia đình đã giúp em hồn thành đồ án này.
Xin chân thành cảm ơn!
Sinh viên
Trần Thị Hằng

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

2


Đồ án tốt nghiệp đại học
LỜI MỞ ĐẦU
Với yêu cầu ngày càng cao của việc phát triển phần mềm, mức độ phức tạp
ngày càng lớn, giới hạn về thời gian và chi phí ngày càng khắt khe, khách hàng
ngày càng khó tính có nhiều u cầu cao nên các cơng ty phần mềm cần phải đưa
ra được những sản phẩm đạt yêu cầu, do đó việc kiểm thử phần mềm là một yếu tố
quan trọng khơng thể thiếu.
Những lập trình viên chủ quan luôn luôn nghĩ rằng họ code đúng nên lỗi luôn
xuất hiện hay tiềm ẩn trong các sản phẩm phần mềm, cần phải có một bộ phận
ngồi bộ phận phát triển phần mềm để bắt các lỗi đó.
Trong q trình thực tập tại cơng ty FPT Đà Nẵng em đã được tiếp xúc và tìm
hiểu về quá trình kiểm thử phần mềm.
Cùng với sự hướng dẫn và giúp đỡ của thầy Phan Anh Phong nên em đã chọn
đề tài “Tìm hiểu về kiểm thử phần mềm và ứng dụng vào website” làm đề tài
cho đồ án tốt nghiệp của mình.
Nội dung đề tài đề cập đến các cơ sở lý thuyết về kiểm thử phần mềm, các
phương pháp thiết kế ca kiểm thử cho website, hoạt động kiểm tra bằng cơng cụ tự
động và tìm hiểu về cơng cụ Quick Test Professionnal.

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

3


Đồ án tốt nghiệp đại học
MỤC LỤC
LỜI CẢM ƠN.......................................................................................................2
LỜI MỞ ĐẦU.......................................................................................................3
Chương 1: KIỂM THỬ PHẦN MỀM...................................................................6
1.1. Lỗi phần mềm...........................................................................................6
1.1.1. Định nghĩa..........................................................................................6
1.1.2. Nguyên nhân.......................................................................................6
1.1.3. Lỗi phần mềm phổ biến......................................................................6
1.2. Kiểm thử phần mềm.................................................................................6
1.2.1. Kiểm thử phần mềm là gì?.................................................................6
1.2.2. Mơ hình phát triển và kiểm thử phần mềm........................................7
1.2.3. Các chiến lược kiểm thử phần mềm...................................................8
1.2.4. Nguyên tắc kiểm thử phần mềm.......................................................13
1.2.5. Khó khăn của kiểm thử phần mềm...................................................14
1.3. Thiết kế các ca kiểm thử.........................................................................14
1.3.1. Khái niệm.........................................................................................14
1.3.2. Yêu cầu của một ca kiểm thử...........................................................14
1.3.3. Nội dung của một ca kiểm thử.........................................................15
1.3.4. Thiết kế ca kiểm thử.........................................................................15
Chương 2: CÔNG CỤ KIỂM TRA TỰ ĐỘNG..................................................20
2.1. Kiểm thử tự động......................................................................................20
2.1.1. Định nghĩa...........................................................................................20
2.1.2. Tại sao phải dùng công cụ kiểm tra tự động.......................................20
2.2. Công cụ kiểm tra tự động Quick Test Professionnal................................21
2.2.1. Giới thiệu............................................................................................21

2.2.2. Hướng dẫn sử dụng phần mềm Quick Test Professionnal..................22
Chương 3: THIẾT KẾ CA KIỂM THỬ CHO WEBSITE QUẢN LÝ GARA...34
3.1. Yêu cầu đặc tả chức năng của website quản lý Gara................................34
SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

4


Đồ án tốt nghiệp đại học
3.1.1. Website quản lý Gara..........................................................................34
3.1.2. Mơ tả các màn hình website quản lý Gara..........................................34
3.2. Thiết kế ca kiểm thử cho website quản lý Gara........................................46
3.3. Sử dụng Quick Test Professionnal chạy ca kiểm thử................................54
KẾT LUẬN.........................................................................................................57
TÀI LIỆU THAM KHẢO...................................................................................58

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

5


Đồ án tốt nghiệp đại học
Chương 1: KIỂM THỬ PHẦN MỀM
1.1. Lỗi phần mềm
1.1.1. Định nghĩa
Lỗi phần mềm là thể hiện khi chương trình khơng làm những gì mà người dùng
mong muốn nó làm.
1.1.2. Nguyên nhân
- Lỗi mã nguồn: Chương trình khơng làm những gì mà người lập trình mong
muốn chương trình làm.

- Vấn đề thiết kế: Chương trình thực hiện những gì mà lập trình viên yêu cầu,
nhưng khách hàng khơng thích và khơng vui với nó.
- Vấn đề yêu cầu: Chương trình đã được thiết kế và thực hành tốt nhưng nó
khơng phù hợp với u cầu của khách hàng.
- Khơng hịa hợp giữa tài liệu và mã nguồn.
- Khơng hịa hợp giữa đặc tả và mã nguồn: Đặc tả yêu cầu bị thay đổi.
1.1.3. Lỗi phần mềm phổ biến
- Lỗi giao diện.
- Xử lý sự kiện làm người dùng khơng hiểu.
- Ngồi giá trị biên.
- Lỗi tính toán.
- Giai đoạn khởi động và kết thúc.
- Luồng điều khiển.
- Lỗi nhập dữ liệu.
- Điều kiện tải.
- Điều kiện cạnh tranh.
- Điều kiện khơng tương thích với mơi trường.
- Dùng phần mềm phiên bản, ID điều khiển.
- Kiểm thử.
- Tài liệu.
1.2. Kiểm thử phần mềm
1.2.1. Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế
để đảm bảo quá trình xây dựng phần mềm thực hiện theo cái mà chúng đã được thiết

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

6

Đồ án tốt nghiệp đại học
kế để làm, và không thực hiện bất cứ thứ gì khơng mong muốn. Đây là một phần quan
trọng trong quá trình phát triển phần mềm, giúp cho người xây dựng phần mềm và
khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa?
1.2.2. Mơ hình phát triển và kiểm thử phần mềm

Kiểm thử chấp
nhận

Xác định yêu cầu

Xác định các chức
năng

Kiểm thử hệ thống

Thiết kế hệ thống

Kiểm thử tích hợp

Thiết kế nội dung
chi tiết

Kiểm thử đơn vị

Mã hóa
Hình 1.1. Mơ hình chữ V
Các tính chất quan trọng trên mơ hình kiểm thử:
- Các hoạt động xây dựng phần mềm và kiểm thử là tách biệt nhau.
- Cần phân biệt giữa các mức độ kiểm thử ở đó mỗi mức kiểm thử là kiểm thử

trên mức phát triển phần mềm tương ứng.
- Quy trình thiết lập các yêu cầu phần mềm, thiết kế, xây dựng, kiểm thử hệ
thống phần mềm được thực hiện như một chuỗi các chu trình phát triển ngắn hơn.
Các yếu tố quan trọng của quy trình kiểm thử:
- Cần có một mức độ kiểm thử cho mỗi công đoạn phát triển phần mềm.
- Các mục tiêu kiểm thử sẽ bị thay đổi, mỗi mức kiểm thử nên có các mục tiêu
đặc thù riêng.
- Việc phân tích và thiết kế các ca kiểm thử cho một mức độ kiểm thử nên bắt
đầu sớm nhất có thể.

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

7


Đồ án tốt nghiệp đại học
- Các kiểm thử viên nên xem xét các tài liệu sớm có thể, ngay sau khi các tài liệu
này được tạo ra trong chu kỳ phát triển phần mềm.
- Số lượng và cường độ của các mức kiểm thử được điều khiển theo các yêu cầu
đặc thù của dự án phần mềm đó.
1.2.3. Các chiến lược kiểm thử phần mềm
1.2.3.1. Phương pháp kiểm thử

1) Phương pháp kiểm thử hộp đen
Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng
dữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là một “hộp
đen”. Mục đích của bạn là hồn tồn khơng quan tâm về cách hoạt động và cấu
trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp mà
chương trình khơng thực hiện theo các đặc tả của nó.
Theo hướng tiếp cận này, dữ liệu kiểm tra chỉ được lấy từ các đặc tả yêu cầu.

Các phương pháp kiểm thử hộp đen:
- Phân lớp tương đương.
- Phân tích giá trị biên.
Kiểm thử dựa trên đặc tả yêu cầu tập trung vào kiểm tra tính thiết thực của
phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào,
và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu
các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác
minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có
giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không.
Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi
ro chắc chắn.
Ưu và nhược điểm:
Kiểm thử hộp đen khơng có mối liên quan nào tới mã lệnh, và kiểm thử đơn
vị nên rất đơn giản là luôn tâm niệm rằng: một mã lệnh phải có lỗi. Những kiểm
thử viên hộp đen tìm ra lỗi mà những lập trình viên khơng tìm ra. Nhưng, mặt
khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà
khơng có đèn vậy”, bởi vì kiểm thử viên khơng biết các phần mềm được kiểm tra
thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một
kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

8


Đồ án tốt nghiệp đại học
đáng lẽ có thể chỉ cần kiểm tra bằng một ca kiểm thử duy nhất, và/hoặc một số
phần của chương trình khơng được kiểm tra chút nào.
Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt
khác nó lại có nhược điểm của “thăm dị mù”.

2) Phương pháp kiểm thử hộp trắng
Phương pháp kiểm thử hộp trắng có thể được sử dụng để đánh giá sự hoàn thành
của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen. Điều
này cho phép các nhóm phần mềm khảo sát các phần của một hệ thống ít khi được
kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra.
Kiểm thử hộp trắng thường do các lập trình viên thực hiện.
1.2.3.2. Cấp độ kiểm thử cơ bản
Kiểm thử phần mềm gồm có các cấp độ: kiểm thử đơn vị, kiểm thử tích hợp,
kiểm thử hệ thống và kiểm thử chấp nhận sản phẩm.

Các đơn vị và thành
phần đơn giản

Kiểm thử đơn vị

Các nhóm đơn vị
Kiểm thử tích hợp

Tồn bộ hệ thống
Kiểm thử hệ thống

Kiểm thử chấp
nhận

Hệ thống nhìn từ
phía khách hàng

Hình 1.2. Sơ đồ các cấp độ kiểm thử
1) Kiểm thử đơn vị
Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được.

Ví dụ: các hàm, thủ tục, lớp hay phương thứ đều có thể được xem là đơn vị.

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

9


Đồ án tốt nghiệp đại học
Vì đơn vị được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt
động đơn giản, chúng ta khơng khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và
phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục
cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn vị đang kiểm tra. Một
nguyên lý đúc kết từ thực tiễn: Thời gian tốn cho kiểm tra đơn vị sẽ được đền bù bằng
việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức
kiểm thử sau đó.
Kiểm thử đơn vị thường do lập trình viên thực hiện. Công đoạn này cần được
thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển
phần mềm. Thông thường kiểm thử đơn vị địi hỏi kiểm thử viên có kiến thức về thiết
kế và code của chương trình. Mục đích của kiểm thử đơn vị là bảo đảm thông tin được
xử lý và kết quả đưa ra là chính xác, trong mối tương quan với dữ liệu nhập và chức
năng của đơn vị. Điều này thường đòi hỏi tất cả các nhánh bên trong đơn vị đều phải
được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các
lệnh được thực thi trong một đơn vị. Ví dụ: chuỗi các lệnh sau điều kiện If và nằm
giữa Then ... Else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc
kiểm thử và qt hết đơn vị địi hỏi phải có kỹ thuật, đơi khi phải dùng thuật tốn để
chọn lựa.
Cùng với các mục kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị
trước các ca kiểm thử hoặc kịch bản kiểm thử, trong đó chỉ định rõ dữ liệu đầu vào,
các bước thực hiện và dữ liệu đầu ra mong muốn. Các ca kiểm thử và kịch bản kiểm
thử này nên được giữ lại để tái sử dụng.

2) Kiểm thử tích hợp
Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thử như
một ứng dụng đã hoàn thành. Trong khi kiểm thử đơn vị kiểm tra các thành phần và
đơn vị riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau và kiểm tra sự giao
tiếp giữa chúng.
Hai mục tiêu chính của kiểm thử tích hợp:
- Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị.
- Tích hợp các đơn vị đơn lẻ thành các hệ thống nhỏ và cuối cùng là hệ thống
hoàn chỉnh chuẩn bị cho kiểm thử ở mức hệ thống.
Trong kiểm thử đơn vị, lập trình viên cố gắng phát hiện lỗi liên quan đến chức
năng và cấu trúc nội tại của đơn vị. Có một số phép kiểm thử đơn giản trên giao tiếp
giữa đơn vị với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

10


Đồ án tốt nghiệp đại học
đơn vị chỉ thật sự được kiểm tra đầy đủ khi các đơn vị tích hợp với nhau trong khi thực
hiện kiểm thử tích hợp.
Trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thực hiện trên những đơn vị đã
được kiểm tra cẩn thận trước đó bằng kiểm thử đơn vị, và tất cả các lỗi mức đơn vị đã
được sửa chữa. Một số người hiểu sai rằng đơn vị một khi đã qua giai đoạn kiểm thử
đơn vị với các giao tiếp giả lập thì khơng cần phải thực hiện kiểm thử tích hợp nữa.
Thực tế việc tích hợp giữa các đơn vị dẫn đến những tình huống hồn tồn khác. Một
chiến lược cần quan tâm trong kiểm thử tích hợp là nên tích hợp dần từng đơn vị. Một
đơn vị tại một thời điểm được tích hợp vào một nhóm các đơn vị khác đã tích hợp
trước đó và đã hồn tất các đợt kiểm thử đơn vị trước đó. Lúc này, ta chỉ cần kiểm thử
giao tiếp của đơn vị mới thêm vào với hệ thống các đơn vị đã tích hợp trước đó, điều

này sẽ làm cho số lượng ca kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể.

3) Kiểm thử hệ thống
Mục đích kiểm thử hệ thống là kiểm thử thiết kế và tồn bộ hệ thống (sau khi tích
hợp) có thỏa mãn yêu cầu đặt ra hay không.
Kiểm thử hệ thống bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp
thành cơng. Thơng thường loại kiểm thử này tốn rất nhiều công sức và thời gian.
Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc
phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ
thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng
tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến
chất lượng của toàn hệ thống.
Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm
thử hệ thống chú trọng các hành vi và lỗi trên tồn hệ thống, cịn kiểm thử tích hợp chú
trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau.
Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để bảo đảm mọi
đơn vị và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm thử hệ
thống.
Sau khi hồn thành kiểm thử tích hợp, một hệ thống phần mềm đã được hình
thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình
viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh.
Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phân
tích các u cầu.

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

11


Đồ án tốt nghiệp đại học

Kiểm thử hệ thống là kiểm thử cả các hành vi chức năng của phần mềm lẫn các
yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.
Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm
hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" hoặc chiếm dụng bộ nhớ.
Sau giai đoạn kiểm thử hệ thống phần mềm thường đã sẵn sàng cho khách hàng hoặc
người dùng cuối cùng kiểm thử chấp nhận sản phẩm hoặc dùng thử. Địi hỏi nhiều
cơng sức, thời gian và tính chính xác, khách quan, kiểm thử hệ thống thường được
thực hiện bởi một nhóm kiểm thử viên hồn tồn độc lập với nhóm phát triển dự án.
Bản thân kiểm thử hệ thống lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất
gồm:
- Kiểm thử chức năng: Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu
thiết kế.
- Kiểm thử hiệu năng: Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ
nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn...
- Kiểm thử khả năng chịu tải: Bảo đảm hệ thống vận hành đúng dưới áp lực cao
(ví dụ nhiều người truy xuất cùng lúc). Các trạng thái tới hạn, các "điểm chết", các tình
huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra
thiết bị như POS, ATM...)...
- Kiểm thử cấu hình: Hệ thống có thể chạy được trên các môi trường khác nhau.
- Kiểm thử bảo mật: Bảo đảm tính tồn vẹn, bảo mật của dữ liệu và của hệ thống.
- Kiểm thử khả năng phục hồi: Bảo đảm hệ thống có khả năng khơi phục trạng
thái ổn định trước đó trong tình huống mất tài ngun hoặc dữ liệu; đặc biệt quan
trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến...
Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng
bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực. Lưu ý là không nhất
thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trưng của
từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người
quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào.
4) Kiểm thử chấp nhận sản phẩm
Thông thường, sau giai đoạn kiểm thử hệ thống là kiểm thử chấp nhận sản phẩm

được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích
của kiểm thử chấp nhận sản phẩm là để chứng minh phần mềm thỏa mãn tất cả yêu

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

12


Đồ án tốt nghiệp đại học
cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh tốn hợp
đồng).
Kiểm thử chấp nhận sản phẩm có ý nghĩa hết sức quan trọng, mặc dù trong hầu
hết mọi trường hợp, các phép kiểm thử của kiểm thử hệ thống và kiểm thử chấp nhận
sản phẩm gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành để bán rộng rãi trên thị trường cho nhiều người sử
dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha và kiểm thử
Beta. Với kiểm thử Alpha, người dùng kiểm thử phần mềm ngay tại nơi phát triển
phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa.
Với kiểm thử Beta, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong
môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa
chữa.
Thực tế cho thấy, nếu khách hàng không quan tâm và khơng tham gia vào q
trình phát triển phần mềm thì kết quả kiểm thử chấp nhận sản phẩm sẽ sai lệch rất lớn,
mặc dù phần mềm đã trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan
đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đơi khi một
phần mềm xuất sắc vượt qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực
hiện dự án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình
nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v...
Gắn liền với giai đoạn kiểm thử chấp nhận sản phẩm thường là một nhóm những
dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v... Tất cả tài

liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ.
1.2.4. Nguyên tắc kiểm thử phần mềm
Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân thủ
một số quy tắc sau:
Quy tắc 1: Một phần quan trọng của một ca kiểm thử là định nghĩa của đầu ra
hay kết quả mong muốn.
Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình.
Quy tắc 3: Nhóm lập trình khơng nên kiểm thử chương trình của chính họ.
Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra.
Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không hợp
lệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mong muốn.

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

13


Đồ án tốt nghiệp đại học
Quy tắc 6: Khảo sát một chương trình để xem liệu chương trình có thực hiện cái
mà nó cần thực hiện chỉ là một phần, phần cịn lại là xem liệu chương trình có thực
hiện cái mà nó khơng cần phải thực hiện hay khơng.
Quy tắc 7: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là khơng tìm
thấy lỗi.
Quy tắc 8: Xác suất tồn tại lỗi trong một đoạn chương trình là tương ứng với số
lỗi đã tìm thấy trong đoạn đó.
Quy tắc 9: Kiểm thử là một nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí tuệ.
1.2.5. Khó khăn của kiểm thử phần mềm
- Liên quan đến tiến trình phát triển: Phần mềm phát triển qua nhiều giai
đoạn, sự mất mát thông tin.
- Về mặt con người: Thiếu đào tạo, ít chú trọng vào vai trị kiểm thử.

- Về mặt thuật tốn: Khơng tồn tại thuật tốn tổng qt có thể chứng minh sự
đúng đắn hồn tồn của bất ký một chương trình nào.
1.3. Thiết kế các ca kiểm thử
1.3.1. Khái niệm
Thiết kế ca kiểm thử trong kiểm thử phần mềm là quá trình xây dựng các phương
pháp kiểm thử có thể phát hiện lỗi, sai sót, khuyết điểm của phần mềm để xây dựng
phần mềm đạt tiêu chuẩn.
1.3.2. Yêu cầu của một ca kiểm thử
Tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của phần
mềm một cách nhiều nhất.
Tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian và cơng sức
nhất.
Khơng được quá đơn giản hay quá phức tạp, không thừa, khơng làm sai lệch
chương trình.
Một ca kiểm thử tốt:
- Nhận biết được đối tượng đang kiểm thử.
- Có tiêu chí đánh giá đúng hoặc sai.
- Phải chi tiết để bất cứ kiểm thử viên nào với những hiểu biết về hệ thống có thể
thực hiện được ca kiểm thử này.
Một ca kiểm thử không tốt:

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

14


Đồ án tốt nghiệp đại học
- Để người dùng tự tìm dữ liệu để kiểm tra.
- Đưa ra những ý tưởng quá cao.
- Không xem xét như một người kiểm thử có kinh nghiệm.

- Đưa ra những bước khó xác định đúng hay sai.
1.3.3. Nội dung của một ca kiểm thử
Yếu tố quan trọng của một ca kiểm thử:
- Test case ID: Xác định một ca kiểm thử .
- Test case Description: Mô tả nội dung của một ca kiểm thử.
- Test case Procedure: Tập hợp các bước, hành động cần thiết để hoàn thành một
đối tượng hay điều kiện nào đó.
- Expected output: Tập hợp các kết quả sau khi thực thi.
- Inter-test case Dependence: Ca kiểm thử phụ thuộc cần phải có đã thực hiện
trước đó.
- Result: Kết quả sau khi đã kiểm tra xong.
- Date test: Thời gian thực hiện kiểm tra.
- Note: Những ghi chú cần thiết của ca kiểm thử.
Cú pháp của một ca kiểm thử:
Hành động + Chức năng + Điều kiện
Chức năng có thể là : chức năng, tính năng, điểm xác định.
Điều kiện có thể là dữ liệu.
Hành động : xác định, kiểm thử, giá trị, thực thi, chạy, tính tốn…
Điểm xác định là dự kiến kết quả.
1.3.4. Thiết kế ca kiểm thử
Một trong những yếu tố quan trọng nhất trong kiểm thử chương trình là thiết kế
và tạo ra các ca kiểm thử có hiệu quả. Với những ràng buộc về thời gian và chi phí đã
cho, thì vấn đề then chốt của kiểm thử trở thành: Tập con nào của tất cả ca kiểm thử có
thể có khả năng tìm ra nhiều lỗi nhất?
Ví dụ về một ca kiểm thử của màn hình “Đăng nhập”:

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

15

Đồ án tốt nghiệp đại học

Hình 1.3. Màn hình “Đăng nhập”
Test case description: Kiểm tra đăng nhập với [Tên người dùng] và [Mật khẩu] hợp lệ.
Test case procedure:
a) Nhập “aaa” vào trường [Tên đăng nhập]
b) Nhập “bbb” vào trường [Mật khẩu]
c) Bấm vào nút [Đăng nhập]
Expected output: Hiển thị trang hộp thư đến của tài khoản gmail vừa nhập.
Thông thường, phương pháp kém hiệu quả nhất là kiểm tra tất cả các đầu vào,
kiểm tra ngẫu nhiên của quá trình kiểm thử một chương trình bằng việc chọn ngẫu
nhiên một tập con các giá trị đầu vào có thể. Về mặt khả năng tìm ra nhiều lỗi nhất, tập
hợp các ca kiểm thử được chọn ngẫu nhiên có rất ít cơ hội là tập hợp tối ưu hay gần tối
ưu. Sau đây là một số phương pháp để chọn ra một tập dữ liệu kiểm thử một cách
thông minh.

1.3.4.1. Phân lớp tương đương
Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào
của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử. Phương
pháp này cố gắng xác định ra một ca kiểm thử mà làm lộ ra một lớp lỗi, do đó làm
giảm tổng số các trường hợp kiểm thử phải được xây dựng.
Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về các lớp
tương đương với một điều kiện vào. Lớp tương đương biểu thị cho tập các trạng thái
hợp lệ hay không hợp lệ đối với điều kiện vào.
Một cách xác định tập con này là để nhận ra rằng một ca kiểm thử được lựa chọn
tốt cũng nên có 2 đặc tính khác:

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

16


Đồ án tốt nghiệp đại học
1) Giảm thiểu số lượng các ca kiểm thử khác mà phải được phát triển để hoàn
thành mục tiêu đã định của kiểm thử “hợp lý”.
2) Bao phủ một tập rất lớn các ca kiểm thử có thể khác. Tức là, nó nói cho
chúng ta một thứ gì đó về sự có mặt hay vắng mặt của những lỗi qua tập giá trị đầu
vào cụ thể.
Thiết kế ca kiểm thử bằng phân lớp tương đương tiến hành theo 2 bước:
(1). Xác định các lớp tương đương.
(2). Xác định các ca kiểm thử.
Cơ sở:
Lỗi thường xuất hiện gần các giá trị biên của miền dữ liệu.
Nguyên tắc:
- Giá trị nhỏ nhất.
- Giá trị gần kề lớn hơn giá trị nhỏ nhất.
- Giá trị bình thường.
- Giá trị gần kề nhỏ hơn giá trị lớn nhất.
- Giá trị lớn nhất.


Xác định các lớp tương đương

Các lớp tương đương được xác định bằng cách lấy mỗi trạng thái đầu vào và
phân chia nó thành hai hay nhiều nhóm.
Chú ý là hai kiểu lớp tương đương được xác định: lớp tương đương hợp lệ mô tả
các đầu vào hợp lệ của chương trình, và lớp tương đương khơng hợp lệ mơ tả tất cả
các trạng thái có thể khác của điều kiện. Với một đầu vào hay điều kiện bên ngoài đã
cho, việc xác định các lớp tương đương hầu như là một quy trình mang tính kinh

nghiệm. Để xác định các lớp tương đương có thể áp dụng tập các nguyên tắc dưới đây:
1) Nếu trạng thái đầu vào xác định rõ giới hạn của các giá trị, xác định được
một lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ.
2) Nếu trạng thái đầu vào xác định số giá trị, xác định được một lớp tương
đương hợp lệ và hai lớp tương đương không hợp lệ.
3) Nếu trạng thái đầu vào chỉ định tập các giá trị đầu vào và chương trình sử
dụng mỗi giá trị là khác nhau, xác định một lớp tương đương hợp lệ cho mỗi loại và
một lớp tương đương không hợp lệ.

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

17


Đồ án tốt nghiệp đại học
4) Nếu trạng thái đầu vào chỉ định một tình huống “chắc chắn”, xác định một
lớp tương đương hợp lệ và một lớp tương đương khơng hợp lệ.
Nếu có bất kỳ lý do nào để tin rằng chương trình khơng xử lý các phần tử trong
cùng một lớp là như nhau, thì hãy chia lớp tương đương đó thành các lớp tương đương
nhỏ hơn.


Xác định các ca kiểm thử

Với các lớp tương đương xác định được ở bước trên, bước thứ hai là sử dụng các
lớp tương đương đó để xác định các ca kiểm thử. Quá trình này như sau:
1) Gán một số duy nhất cho mỗi lớp tương đương.
2) Cho đến khi tất cả các lớp tương đương hợp lệ được bao phủ bởi các ca kiểm
thử, viết một ca kiểm thử mới bao phủ càng nhiều các lớp tương đương chưa được bao
phủ càng tốt.

3) Cho đến khi các ca kiểm thử của bạn đã bao phủ tất cả các lớp tương đương
không hợp lệ, viết một ca kiểm thử mà bao phủ một và chỉ một trong các lớp tương
đương không hợp lệ chưa được bao phủ.
4) Lý do mà mỗi ca kiểm thử riêng bao phủ các trường hợp không hợp lệ là vì
các kiểm tra đầu vào khơng đúng nào đó che giấu hoặc thay thế các kiểm tra đầu vào
không đúng khác.
Mặc dù việc phân lớp tương đương là rất tốt khi lựa chọn ngẫu nhiên các ca kiểm
thử, nhưng nó vẫn có những thiếu sót. Ví dụ, nó bỏ qua các kiểu kiểm tra có lợi nào
đó. Phương pháp tiếp theo, phân tích giá trị biên sẽ hạn chế được nhiều những thiếu
sót này.

1.3.4.2. Phân tích giá trị biên
Kinh nghiệm cho thấy các ca kiểm thử mà khảo sát tỷ mỷ các điều kiện biên có
tỷ lệ phần trăm cao hơn các ca kiểm thử khác. Các điều kiện biên là những điều kiện
mà các tình huống ngay tại trên và dưới các cạnh của các lớp tương đương đầu vào và
các lớp tương đương đầu ra. Phân tích các giá trị biên là phương pháp thiết kế ca kiểm
thử bổ sung thêm cho phân lớp tương đương, nhưng khác với phân lớp tương đương ở
hai khía cạnh:
1) Phân tích giá trị biên khơng lựa chọn phần tử bất kỳ nào trong một lớp tương
đương là điển hình, mà nó u cầu là một hay nhiều phần tử được lựa chọn như vậy
mà mỗi cạnh của lớp tương đương đó chính là đối tượng kiểm tra.

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

18


Đồ án tốt nghiệp đại học
2) Ngoài việc chỉ tập trung chú ý vào các trạng thái đầu vào (không gian đầu
vào), các ca kiểm thử cũng nhận được bằng việc xem xét không gian kết quả (các lớp

tương đương đầu ra).
Phân tích giá trị biên u cầu óc sáng tạo và lượng chun mơn hóa nhất định và
nó là một q trình mang tính kinh nghiệm rất cao. Tuy nhiên, có một số quy tắc
chung như sau:
1) Nếu trạng thái đầu vào định rõ giới hạn của các giá trị, hãy viết các ca kiểm
thử cho các giá trị cuối của giới hạn, và các ca kiểm thử đầu vào khơng hợp lệ cho các
trường hợp vừa ra ngồi phạm vi.
2) Nếu trạng thái đầu vào định rõ số lượng giá trị, hãy viết các ca kiểm thử cho
con số lớn nhất và nhỏ nhất của các giá trị và một giá trị trên, một giá trị dưới những
giá trị này.
3) Sử dụng quy tắc 1 cho mỗi trạng thái đầu vào. Sử dụng nguyên tắc 2 cho mỗi
trạng thái đầu ra.
4) Nếu đầu vào hay đầu ra của một chương trình là tập được sắp thứ tự tập
trung chú ý vào các phần tử đầu tiên và cuối cùng của tập hợp.
5) Sử dụng sự khéo léo để tìm các điều kiện biên.

1.3.4.3. Đốn lỗi
Một kỹ thuật thiết kế ca kiểm thử khác là đoán lỗi. Kỹ thuật viên kiểm tra được
đưa cho một chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác và kinh nghiệm,
các loại lỗi có thể và sau đó viết các ca kiểm thử để đưa ra các lỗi đó.
Thật khó để đưa ra một quy trình cho kỹ thuật đốn lỗi vì nó là một quy trình có
tính trực giác cao và khơng thể dự đốn trước. Ý tưởng cơ bản là liệt kê một danh sách
các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên
danh sách đó. Một ý tưởng khác để xác định các ca kiểm thử có liên đới với các giả
định mà lập trình viên có thể đã thực hiện khi đọc đặc tả (tức là: những thứ bị bỏ sót
khỏi đặc tả, hoặc là do tình cờ, hoặc là vì người viết có cảm giác những đặc tả đó là rõ
ràng). Nói cách khác, bạn liệt kê những trường hợp đặc biệt đó mà có thể đã bị bỏ sót
khi chương trình được thiết kế.

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

19


Đồ án tốt nghiệp đại học
Chương 2: CÔNG CỤ KIỂM TRA TỰ ĐỘNG
2.1. Kiểm thử tự động
2.1.1. Định nghĩa
Như đã biết cơng việc kiểm tra là một q trình đi tìm những khiếm khuyết cịn
sót lại trong khi làm một phần mềm hay một website. Và trong khi thực hiện cơng việc
đó bằng cách theo dõi mã lệnh, chạy kết quả thì cịn sử dụng những cơng cụ, phần
mềm hỗ trợ cho quá trình kiểm tra. Càng ngày đi theo sự tiến bộ của khoa học kỹ thuật
thì những kỹ thuật mới, những hỗ trợ mới cũng ra đời giúp cho kỹ thuật viên kiểm tra
dễ dàng thực hiện công việc của họ hơn. Và thành tựu đáng kể nhất trong cơng việc
kiểm tra phần mềm hiện nay có được đó là kỹ thuật kiểm tra tự động.
2.1.2. Tại sao phải dùng công cụ kiểm tra tự động
Công cụ kiểm tra tự động trong lĩnh vực phát triển phần mềm là công cụ giúp
thực hiện việc kiểm tra phần mềm một cách tự động. Tuy nhiên không phải mọi việc
kiểm tra đều có thể tự động hóa, câu hỏi đặt ra là trong điều kiện hoặc tình huống nào
dùng cơng cụ kiểm tra tự động là thích hợp? Việc dùng công cụ kiểm tra tự động
thường được xem xét trong một số tình huống sau:
- Khơng đủ tài ngun: Khi số lượng tình huống kiểm tra quá nhiều mà các kỹ
thuật viên khơng thể hồn tất bằng tay trong thời gian cụ thể nào đó. Có thể lấy một
dẫn chứng là khi thực hiện kiểm tra chức năng của một website. Website này sẽ được
kiểm tra với các môi trường gồm 3 trình duyệt và 2 hệ điều hành tình huống này đòi
hỏi số lần kiểm tra tăng lên và lặp lại nhiều lần so với việc kiểm tra cho một môi
trường cụ thể.
- Kiểm tra hồi quy: Trong quá trình phát triển phần mềm, nhóm lập trình thường
đưa ra nhiều phiên bản phần mềm liên tiếp để kiểm tra. Thực tế cho thấy việc đưa ra
các phiên bản phần mềm có thể là hàng ngày, mỗi phiên bản bao gồm những tính năng

mới, hoặc tính năng cũ được sửa lỗi hay nâng cấp. Việc bổ sung hoặc sửa lỗi code cho
những tính năng ở phiên bản mới có thể làm cho những tính năng khác đã kiểm tra tốt
chạy sai mặc dù phần code của nó khơng hề chỉnh sửa. Để khắc phục điều này, đối với
từng phiên bản, kỹ thuật viên không chỉ kiểm tra chức năng mới hoặc được sửa, mà
phải kiểm tra lại tất cả những tính năng đã kiểm tra tốt trước đó. Điều này khó khả thi
về mặt thời gian nếu kiểm tra thủ công.
- Kiểm tra khả năng vận hành phần mềm trong môi trường đặt biệt: đây là kiểm
tra nhằm đánh giá xem vận hành của phần mềm có thỏa mãn yêu cầu đặt ra hay không.

SVTH: Trần Thị Hằng - Lớp: 49K - Khoa: CNTTn Thị Hằng - Lớp: 49K - Khoa: CNTT Hằng - Lớp: 49K - Khoa: CNTTng - Lớp: 49K - Khoa: CNTTp: 49K - Khoa: CNTT

20