HỌC VIỆN NGÂN HÀNG
KHOA HỆ THỐNG THÔNG TIN QUẢN LÝ
----------------

BÁO CÁO THỰC TẬP TỐT NGHIỆP

ĐỀ TÀI: ỨNG DỤNG KIỂM THỬ PHẦN MỀM
VÀO KIỂM THỬ TRANG WEB LOTTE CINEMA

Giáo viên hướng dẫn: ThS. Nguyễn Dương Hùng
Sinh viên thực hiện: Nguyễn Bảo Ngọc
Mã sinh viên : 18A4040157

HÀ NỘI – 2019


LỜI CAM ĐOAN

Em xin cam đoan kết quả đạt được trong báo cáo là sản phẩm nghiên cứu, tìm hiểu
của riêng cá nhân em. Trong toàn bộ nội dung của báo cáo, những điều được trình bày
hoặc là của cá nhân em hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả các tài liệu
tham khảo đều có xuất xứ rõ ràng và được trích dẫn hợp pháp.
Em xin hoàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời
cam đoan của mình.

SINH VIÊN THỰC HIỆN
Ngọc
Nguyến Bảo Ngọc

2

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN
Về các mặt: Ý thức chấp hành nội quy, thái độ làm việc của sinh viên tại nơi thực tập;
Tiến độ, kết quả thực hiện công việc được giao.
……………………………………………………………………………………………………………………………………..
………………………………………………………………………………………….…………………………………………..
……………………………………………………………………………………………………………………………………...
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
………………………………………………………………………………………….…………………………………………..
3


LỜI CẢM ƠN

Lời đầu tiên em xin chân thành cảm ơn thầy giáo Nguyễn Dương Hùng, người đã
tận tình hướng dẫn, giúp đỡ em hoàn thành Báo cáo thực tập trong thời gian vừa qua.
Em xin chân thành cảm ơn các thầy cô trong khoa Hệ thống thông tin quản lý nói
riêng và các thầy cô trường Học viện Ngân hàng nói chung đã trang bị cho chúng em

những kiến thức quý báu trong những năm học vừa qua.
Mặc dù đã cố gắng nỗ lực để hoàn thành Báo cáo tốt nghiệp, tuy nhiên thời gian thực
tập có hạn, kiến thức bản than còn nhiều hạn chế nên không thể tránh khỏi những sai sót, em
kính mong nhận được sự cảm thông và tận tình chỉ bảo từ phía Thầy, Cô và các bạn.
Em xin chân thành cảm ơn!

4


MỤC LỤC

5


DANH MỤC HÌNH VẼ

6


DANH MỤC BẢNG

7


MỞ ĐẦU
1. Lý do lựa chọn đề tài

Công nghệ ngày càng phát triển, kéo theo đó là hệ thống mạng và các phần mềm cũng
gia tăng cả về số lượng và cả về chức năng phần mềm. Nhưng cũng song song nảy sinh
thêm nhiều vấn đề về lỗi hỏng hóc phần mềm không đáng có gây ra các ảnh hưởng

nghiêm trọng. Những lỗi này có thể do thiết kế, lập trình, không được kiểm duyệt kỹ
lưỡng trước khi đưa cho người dùng cuối hay cũng có thể do có người cố tình phá hoại.
Những vấn đề nan giải và cấp thiết ngày càng được mở rộng. Chính vì vậy có thể thấy
rằng việc kiểm thử phần mềm thực sự quan trọng trong quy trình sản xuất và phát triển
phần mềm.
Do đó yêu cầu đặt ra là cần có công tác kiểm thử phần mềm thật ký lưỡng nhằm hạn
chế các lỗi hay hỏng hóc còn tiềm tàng bên trong phần mềm mà ta chưa kịp nhận ra. Đây
chính là lý do em lựa chọn đề tài “Ứng dụng kiểm thử phần mềm vào kiểm thử trang web
Lotte Cinema” để thực hiện báo cáo tốt nghiệp.
2. Mục đích của đề tài

Thứ nhất là hiểu rõ về tầm quan trọng của kiểm thử thủ công và kiểm thử tự động đối
với dự án, đóng góp và hoàn thành tốt nhiệm vụ tại nơi thực tập.
Thứ hai, nắm vững kiến thức về kiểm thử phần mềm, cách kiểm thử hiệu năng và
chức năng của một ứng dụng web cụ thể. Biết cách xây dựng test script, sử dụng cơ bản
công cụ kiểm thử tự động.
Thứ ba, đây là cơ hội tốt tại nơi thực tập khi được tham gia vào một dự án cụ thể,
nâng cao khả năng làm việc nhóm, nắm vững quy trình kiểm thử tại FPT-IS, có thể đưa ra
các tài liệu về trường hợp kiểm thử, báo cáo kiểm thử.
3. Kết cấu đề tài

Chương 1: Giới thiệu về công ty thực tập, dự án thực tế và nhiệm vụ được giao tại
công ty thực tập.
Chương 2: Tổng quan về kiểm thử phần mềm và các kỹ thuật kiểm thử, các mức độ
kiểm thử.
Chương 3: Quy trình kiểm thử phần mềm cụ thể, cách kiểm thử một ứng dụng web
Chương 4: Tiến hành kiểm thử trên trang web Lotte Cinema.
8



CHƯƠNG 1: MÔ TẢ BÀI TOÁN
1.1. Tổng quan về công ty thực tập
Tên công ty: Công ty Hệ thống Thông tin FPT
Thành lập: 31/12/1994
Doanh thu: 208 triệu USD (2015)
Nhân sự: 3.200 người (2015)
Hệ thống chất lượng: Hệ thống chất lượng tại FPT IS được đảm bảo bởi những
chứng chỉ quốc tế về quản lý chất lượng, bảo mật thông tin và quy trình sản xuất phần
mềm: ISO 9001:2008, ISO 27001 và CMMi3. Ngoài ra, qui trình quản trị dự án tại FPT
IS được xây dựng dựa trên các tiêu chuẩn quản trị dự án quốc tế PMP và CMMI, các
phương pháp luận triển khai tiêu biểu của các hãng: ASAP (SAP), ADM (Accenture) và
OUM (Oracle).
Dịch vụ: Cung cấp các giải pháp chuyên ngành, đa ngành, tích hợp hệ thống và
dịch vụ CNTT,…
Khách hàng và đối tác: Hàng trăm khách hàng và đối tác là những tập đoàn hàng
đầu thế giới: IBM, Oracle, Cisco, Microsoft, …
Lĩnh vực: Tài chính công, Viễn thông, Tài chính ngân hàng, Giao thông vận tải, Y tế,…
Với hơn 20 năm kinh nghiệm, Công ty Hệ thống Thông tin FPT (FPT IS) là nhà
tích hợp hệ thống, cung cấp giải pháp hàng đầu Việt Nam và khu vực. Sở hữu năng lực
công nghệ được thừa nhận bởi các khách hàng và đối tác toàn cầu, FPT IS mang đến
những dịch vụ và giải pháp phục vụ các lĩnh vực trọng yếu của từng quốc gia.
1.2. Xác định yêu cầu bài toán
Lotte Cinema trực thuộc tập đoàn LOTTE, một trong những tập đoàn kinh tế đa
ngành lớn nhất của Hàn Quốc có mặt ở 22 quốc gia trên thế giới. Lotte Cinema là một
trong top 5 cụm rạp chiếu phim lớn nhất toàn cầu và là một trong những nhà phát hành,
cụm rạp chiếu phim lớn nhất Việt Nam. Mục tiêu của Lotte Cinema là trở thành hình
mẫu công ty điển hình đóng góp cho sự phát triển không ngừng của ngành công nghiệp
điện ảnh Việt Nam.
9



Với chiến lược đẩy mạnh thị trường phù hợp với sự phát triển nhanh chóng của
công nghệ và Internet. Lotte Cinema trong 2 năm gần đây đã hợp tác cùng FPT-IS để
hoàn thiện, nâng cấp trang web . Với các chức năng chính:
Đăng ký, đăng nhập, xem lịch chiếu trực tuyến, thông tin phim, ngày chiếu và các cụm
rạp của Lotte Cinema trên toàn quốc, quảng cáo… Lotte Cinema mong muốn sẽ có một
trang mạng đáp ứng tất cả các chức năng đó và giúp Lotte Cinema cạnh tranh được với
các đối thủ cùng lĩnh vực, thu hút thêm được nhiều khách hàng tiềm năng hơn nữa trong
tương lai. Mới đây, FPT-IS đang tiến hành xây dựng thêm một chức năng nữa trên trang
web trực tuyến của Lotte Cinema đó là: Thanh toán trực tuyến. Trong quá trình thiết kế
và xây dựng, đội kiểm thử có nhiệm vụ kiểm tra, thực hiện các kịch bản kiểm thử và đưa
ra báo cáo về việc hoạt động của các chức năng còn lại khi chức năng Thanh toán trực
tuyến đưa vào hoạt động trên trang web của Lotte Cinema. Trong quá trình thực tập, tôi
được phân công đảm nhiệm kiểm thử độ chịu tải trang Web và kiểm thử chức năng hai
trang chính là: đăng nhập và đăng ký.

10


CHƯƠNG 2: CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
2.1. Tổng quan về kiểm thử phần mềm
2.1.1. Các khái niệm cơ bản
a, Phần mềm là gì?
Phần mềm là các chương trình máy tính, các thủ tục, các tài liệu có liên quan và
các dữ liệu để vận hành một hệ thống máy tính. (1)
b, Quy trình phát triển phần mềm
Là một tập hợp các hoạt động có mục tiêu nhằm phát triển và tiến hóa phần mềm.
Các tổ chức khác nhau có những tiến trình khác nhau. Tuy nhiên có 4 hoạt động chung
nhất (2):
 Đặc tả : Xác định yêu cầu, là tiến trình tìm hiểu và định ra các dịch vụ, chức năng


được đòi hỏi từ hệ thống và xác định các ràng buộc lên vận hành và phát triển hệ
thống. Các pha chính trong tiến trình phát triển phần mềm đó là:
• Nghiên cứu khả thi: Giúp xác định những yêu cầu của người sử dụng có
•

thỏa mãn những công nghệ hiện tại không.
Phân tích yêu cầu: Đưa ra các yêu cầu hệ thống thông qua một số phương
pháp như: quan sát hệ thống hiện tại, phỏng vấn và thảo luận với người sử

dụng, phân tích tài liệu hệ thống cũ,..
• Đặc tả yêu cầu: sẽ tư liệu hóa những thông tin thu thập được.
 Đánh giá yêu cầu: Pha này sẽ kiểm tra lại các yêu cầu xem chúng có đúng thực tế
không, có thống nhất không, có đầy đủ không. Nếu phát hiện ra lỗi thì ta phải
chỉnh sửa các lỗi này.
 Phát triển phần mềm: Là tiến trình chuyển đổi các đặc tả thành một hệ thống có
thể chạy được trên máy tính, thường bao gồm tiến trình thiết kế và lập trình phần
mềm. Trong đó:
• Thiết kế (Design): Dịch các yêu cầu thành bản thiết kế.
• Lập trình (Coding): Các lập trình viên chuyển thiết kế thành chương trình
máy tính bằng một ngôn ngữ phần mềm.
 Phê duyệt phần mềm: Phần mềm được đánh giá và kiểm định để đảm bảo phù hợp
với đặc tả về nó và đáp ứng các yêu cầu của khách hàng. Quy trình kiểm thử gồm
các giai đoạn sau:
11


•

Kiểm thử thành phần: Các thành phần riêng biệt được kiểm định để đảm

bảo rằng chúng vận hành đúng đắn. Mỗi thành phần được kiểm định độc

lập, không có các thành phần khác.
• Kiểm định hệ thống: Các thành phần được tích hợp thành hệ thống. Tiến
trình này đề cập đến việc tìm ra các sai sót dẫn đến từ các tương tác không
•

đoán trước được giữa các thành phần.
Kiểm định chấp nhận: Hệ thống được kiểm định với các dữ liệu được cung

•

cấp bởi khách hàng.
Kiểm thử hồi quy: Khi hệ thống đi vào vận hành, hoặc thêm chức năng
mới, kiểm thử hồi quy lúc này mang tính bảo trì có nghĩa là kiểm thử lại

các chức năng đã kiểm thử trước đó.
 Nâng cấp, phát triển phần mềm: Sự sửa đổi các hệ thống phần mềm hiện đang tồn
tại để đáp ứng các yêu cầu mới (2).
c, Lỗi phần mềm
Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó.
Có thể phân biệt lỗi phần mềm thành 3 dạng:
•
•

Lỗi sai: Sản phẩm phần mềm được xây dựng khác với đặc tả.
Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tả nhưng

lại không có trong sản phẩm thực tế.
• Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong tài liệu đặc tả.

d, Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới
những điều kiện xác định, quan sát và ghi lại kết quả, và đánh giá một khía cạnh nào đó
của hệ thống hay thành phần đó (1).
Có thể định nghĩa một cách đơn giản: Kiểm thử phần mềm là quá trình thực thi
một hệ thống phần mềm với mục đích tìm lỗi và để xác định xem phần mềm có đúng với
đặc tả không, thực hiện trong môi trường như mong đợi hay không.
2.1.2. Mục tiêu chính của kiểm thử phần mềm
Kiểm thử phần mềm có những mục tiêu chính sau:
•
•

Phát hiện được càng nhiều lỗi càng tốt trong quá trình kiểm thử.
Chứng minh được rằng sản phẩm phần mềm phù hợp với các đặc tả yêu cầu
của nó.
12


•

Tạo các trường hợp kiểm thử chất lượng cao, thực hiệ kiểm thử hiệu quả và

tạo ra được các báo cáo vấn đề đúng và hữu dụng.
• Đảm bảo rằng kết quả cuối cùng đáp ứng các yêu cầu kinh doanh và người
sử dụng.
• Cung cấp cho khách hàng một sản phẩm chất lượng.
Nhìn chung, kiểm thử không thể chứng minh rằng phần mềm hoàn toàn không có
lỗi hoặc nó thích nghi được trong mọi môi trường làm việc. Tuy nhiên, mục tiêu của kiểm
thử phần mềm là tạo niềm tin cho khách hàng, rằng phần mềm đủ tốt và có thể sử dụng
được. Kiểm thử là quá trình làm tăng độ tin cậy của phần mềm.

2.2. Phân loại và các kỹ thuật kiểm thử
Ta phân loại kiểm thử dựa vào các yếu tố: phương pháp tiến hành kiểm thử, kỹ
thuật kiểm thử, chiến lược kiểm thử và các mức kiểm thử.
2.2.1. Các phương pháp kiểm thử
a, Kiểm thử tĩnh
Là phương pháp kiểm thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc
tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không
cần chạy chương trình. (3)
Kiểm thử tĩnh chủ yếu để kiểm tra cú pháp của code và/hoặc review code (kiểm
tra xem code có được viết theo đúng tiêu chuẩn code. Ví dụ cách đặt tên hàm tên biến,
cách sử dụng hàm chung đã đưa ra hay chưa) hoặc tài liệu để tìm lỗi bằng cách thủ công.
Đây là loại kiểm thử được thực hiện bởi DEV (những người lập trình), làm việc một cách
độc lập.
Lỗi được phát hiện ở giai đoạn phát triển này là ít tốn kém để sửa chữa hơn so với
lỗi phát hiện được ở các giai đoạn sau này trong các quy trình phát triển phần mềm.
b, Kiểm thử động
Là phương pháp kiểm thử phần mềm thông qua việc dùng máy chạy chương trình
để kiểm tra hoạt động của chương trình. Kiểm thử động kiểm tra cách thức hoạt động của
mã lệnh. Trong kiểm thử tự động, cần nhập các giá trị đầu vào và kiểm tra xem liệu đầu
ra có như mong muốn hay không. (3)
13


Kiểm thử động và kiểm thử tĩnh là hai phương pháp bổ sung cho nhau, tìm các
loại lỗi khác nhau mang lại hiểu quả kiểm thử cao hơn.
2.2.2. Các kỹ thuật kiểm thử
Hai trong số những kỹ thuật kiểm thử thông dụng nhất hiện nay đó là:
- Kỹ thuật kiểm thử hộp đen (Black – box Testing) hay còn gọi là kỹ thuật kiểm
thử chức năng (Functional Testing)
- Kỹ thuật kiểm thử hộp trắng (White – box Testing) hay còn gọi là kỹ thuật kiểm

thử cấu trúc (Structural Testing).
a, Kiểm thử hộp đen
Kiểm thử hộp đen còn được gọi là kiểm thử hướng dữ liệu (data - driven) hay là
kiểm thử hướng vào/ra (input/output driven). (3)
Trong kỹ thuật này, người kiểm thử xem phần mềm như là một hộp đen. Người
kiểm thử hoàn toàn không quan tâm đến cấu trúc và hành vi bên trong 14 của chương
trình. Người kiểm thử chỉ cần quan tâm đến việc tìm các hiện tượng mà phần mềm không
hành xử theo đúng đặc tả của nó. Do đó, dữ liệu kiểm thử sẽ xuất phát từ đặc tả.
Như vậy, cách tiếp cận kiểm thử hộp đen tập trung vào các yêu cầu chức năng của
phần mềm. Kiểm thử hộp đen cho phép người kiểm thử xây dựng các nhóm giá trị đầu
vào sẽ thực thi đầy đủ tất cả các yêu cầu chức năng của chương trình. Kiểm thử hộp đen
không thay thế kỹ thuật kiểm thử hộp trắng, nhưng nó bổ sung khả năng phát hiện các lớp
lỗi khác với các phương pháp hộp trắng.
Kiểm thử hộp đen cố gắng tìm các loại lỗi sau:
- Các chức năng thiếu hoặc không đúng.
- Các lỗi giao diện.
- Các lỗi cấu trúc dữ liệu trong truy cập cơ sở dữ liệu bên ngoài.
- Các lỗi thực hiện.
- Các lỗi khởi tạo hoặc kết thúc.
- Và các lỗi khác ...
Không giống với kiểm thử hộp trắng được thực hiện sớm trong quá trình kiểm thử,
kiểm thử hộp đen được áp dụng trong các giai đoạn sau của kiểm thử. Vì kiểm thử hộp
14


đen không để ý có chủ đích cấu trúc điều khiển, sự quan tâm tập trung trên miền thông
tin. Nếu người kiểm thử muốn sử dụng phương pháp này để tìm tất cả các lỗi trong
chương trình thì điều kiện bắt buộc là phải kiểm thử tất cả các đầu vào, tức là mỗi một
điều kiện đầu vào có thể có là một trường hợp kiểm thử. Bởi vì nếu chỉ kiểm thử một số
điều kiện đầu vào thì không đảm bảo được chương trình đã hết lỗi.

b, Kiểm thử hộp trắng
Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra cấu
trúc bên trong của phần mềm với mục đích bảo đảm rằng tất cả các câu lệnh và điều kiện
sẽ được thực hiện ít nhất một lần. Kiểm thử hộp trắng được thực hiện sớm trong quá trình
kiểm thử, người kiểm thử truy nhập vào mã nguồn chương trình và có thể kiểm tra nó, lấy
đó làm cơ sở để hỗ trợ việc kiểm thử. (3)
Kiểm thử hộp trắng xem xét chương trình ở mức độ chi tiết và phù hợp khi kiểm
tra các môđun nhỏ. Tuy nhiên, kiểm thử hộp trắng có thể không đầy đủ vì kiểm thử hết
các lệnh không chứng tỏ là chúng ta đã kiểm thử hết các trường hợp có thể. Ngoài ra
chúng ta không thể kiểm thử hết các đường đi đối với các vòng lặp lớn.
Phương pháp kiểm thử hộp trắng và kiểm thử hộp đen là hai phương pháp cơ bản
có vai trò rất quan trọng trong quá trình phát triển phần mềm, nếu chúng ta biết kết hợp
chúng để bổ sung khiếm khuyết lẫn nhau.
2.2.3. Các chiến lược kiểm thử
Với chiến lược kiểm thử có thể kể đến kiểm thử thủ công và kiểm thử tự động.
a, Kiểm thử thủ công
Kiểm thử thủ công: chính là kiểm thử viên làm mọi công việc hoàn toàn bằng tay,
từ viết trường hợp kiểm thử (test case) đến thực hiện kiểm thử, mọi thao tác như nhập
điều kiện đầu vào, thực hiện một số sự kiện khác như click nút và quan sát kết quả thực
tế, sau đó so sánh kết quả thực tế với kết quả mong muốn trong test case, điền kết quả
kiểm thử. Hiện nay, phần lớn các tổ chức, các công ty phần mềm, hoặc các nhóm làm
phần mềm đều thực hiện kiểm thử thủ công là chủ yếu. (4)
b, Kiểm thử tự động
Kiểm thử tự động: kiểm thử phần mềm tự động là thực hiện kiểm thử phần mềm
15


bằng một chương trình đặc biệt với rất ít hoặc không có sự tương tác của con người, giúp
cho người thực hiện việc kiểm thử phần mềm (tester) không phải lặp đi lặp lại các bước
nhàm chán. (4)

Công cụ kiểm thử tự động có thể lấy dữ liệu từ file bên ngoài (excel, csv…) nhập
vào ứng dụng, so sánh kết quả mong đợi (từ file excel, csv…) với kết quả thực tế và xuất
ra báo cáo kết quả kiểm thử.
2.2.4. Các mức kiểm thử
Các công việc kiểm thử thường được phân nhóm khi thêm vào quy trình phát triển
phần mềm, hoặc được phân theo mức kiểm thử đặc trưng
Kiểm thử phần mềm gồm các mức độ: 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.

Hình1: Bốn cấp độ cơ bản của kiểm thử phần mềm
a, Kiểm thử mức đơn vị (Unit Test)
Một đơn vị (Unit) 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 (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức
16


(Method). (5)
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.
Mục đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và kết xuất (khỏi
Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng xử lý của Unit.
Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát
hiện nhánh phát sinh lỗi. Cũng như 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ử (hay trường hợp kiểm thử) (test case) hoặc kịch bản
(test script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong muốn
sẽ xuất ra. Các test case và test script được giữ lại để sử dụng sau này.
b, Kiểm thử tích hợp (Intergration Test)
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à Unit
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. (5)
Kiểm thử tích hợp có hai mục tiêu chính là:
- Phát hiện lỗi giao tiếp xảy ra giữa các Unit
- Tích hợp các Unit đơn lẻ thành các hệ thống con (gọi là subsystem) và cuối cùng
là nguyên hệ thống hoàn chỉnh chuẩn bị cho kiểm thử ở mức hệ thống (system test).
Có 4 loại kiểm thử trong kiểm thử tích hợp như sau:
- Kiểm thử cấu trúc (Structure test): Kiểm thử nhằm bảo đảm các thành phần bên
trong của một chương trình chạy đúng, chú trọng đến hoạt động của các thành phần cấu
trúc nội tại của chương trình, chẳng hạn các lệnh và nhánh bên trong.
- Kiểm thử chức năng (Functional test): Kiểm thử chỉ chú trọng đến chức năng của
chương trình, không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương
trình theo yêu cầu kỹ thuật.
- Kiểm thử hiệu năng (Performance test): Kiểm thử việc vận hành của hệ thống.
- Kiểm thử khả năng chịu tải (Stress test): Kiểm thử các giới hạn của hệ thống.
17


c, Kiểm thử hệ thống (System Test)
Kiểm thử hệ thống kiểm tra 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
đích của kiểm thử hệ thống là kiểm thử xem thiết kế và toà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. (5)
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.
Kiểm thử hệ thống thường có các loại kiểm thử sau:

- Kiểm thử chức năng (Functional test): 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ử khả năng vận hành (Performance test): 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 (Stress test hay Load test): 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). Stress test tập trung
vào 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 test thiết bị như POS, ATM),....
- Kiểm thử cấu hình (Configuration test): Đảm bảo hệ thống hoạt động tương thích
với các loại phần cứng khác nhau.
- Kiểm thử khả năng bảo mật (Security test): Bảo đảm tính toà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 (Recovery test): 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 13 tài nguyên 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.
18


d, Kiểm thử chấp nhận(Acceptance Test)
Mục đích của kiểm thử chấp nhận là kiểm thử khả năng chấp nhận cuối cùng để
chắc chắn rằng sản phẩm là phù hợp và thỏa mãn các yêu cầu của khách hàng và khách
hàng chấp nhận sản phẩm. (5)
Trong giai đoạn kiểm thử chấp nhận thì người kiểm tra là khách hàng. Khách hàng
sẽ đánh giá phần mềm với mong đợi theo những thao tác sử dụng quen thuộc của họ.
Việc kiểm tra ở giai đoạn này có ý nghĩa hết sức quan trọng tránh cho việc hiểu sai yêu
cầu cũng như sự mong đợi của khách hàng.
Gắn liền với giai đoạn kiểm thử chấp nhận 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 tra chặt chẽ.

CHƯƠNG 3: QUY TRÌNH VÀ KẾ HOẠCH KIỂM THỬ ỨNG DỤNG WEB
3.1. Quy trình kiểm thử phần mềm
3.1.1. Khái niệm quy trình kiểm thử phần mềm
Quy trình kiểm thử phần mềm là tập hợp những hoạt động của người kiểm thử
nhằm kiểm thử một ứng dụng phần mềm. (6)
3.1.2. Tại sao cần phải thực hiện quy trình kiểm thử phần mềm
Việc thực hiện quy trình kiểm thử phần mềm nhằm mục đích
 Cần làm rõ vai trò và trách nhiệm của việc kiểm thử phần mềm.
 Cần làm rõ các công đoạn, các bước kiểm thử.
 Cần phải hiểu và phân biệt các tính chất kiểm thử (tại sao phải kiểm thử), các bước

kiểm thử (khi nào kiểm thử), và các kỹ thuật kiểm thử (kiểm thử bằng cách nào).
3.1.3. Ai liên quan đến việc kiểm thử phần mềm
Các đối tượng trong quy trình kiểm thử phần mềm gồm: quản lý dự án, leader,
kiểm thử viên.

19


Hình 2: Các đối tượng trong quy trình kiểm thử phần mềm

3.1.4. Quy trình kiểm thử tổng quát

20


Hình3: Quy trình kiểm thử tổng quát
a, Xây dựng kế hoạch kiểm thử (Test Planning)
Test Manager hoặc Test Leader sẽ xây dựng kế hoạch \ịnh nghĩa phạm vi kiểm thử.
 Định nghĩa các chiến lược kiểm thử.

 Nhận dạng các rủi ro và yếu tố bất ngờ.
 Nhận dạng các hoạt động kiểm thử nào là thủ công, kiểm thử nào là tự động hay

cả hai.
 Ước lượng chi phí kiểm thử và xây dựng lịch kiểm thử.
 Nhận dạng môi trường kiểm thử.

Kế hoạch kiểm thử cần được:
 Xem lại bởi QC team, Developer, Business Analysis. TA (nếu cần), PM và

Customer.
 Chấp thuận bởi: Quản lý dự án và khách hàng.
 Hiểu chỉnh trong suốt chu kỳ kiểm thử để phản ánh các thay đổi nếu cần thiết.
b, Phân tích và thiết kế kiểm thử (Test Analysis và Test Design)
Test Analysis hoặc test Designer sẽ thiết kế (định nghĩa) các testcase từ các yêu cầu
21


liên quan (ví dụ từ thông tin trong usecase)
 Thiết kế (định nghĩa) các trường hợp kiểm thử (testcase) từ các yêu cầu chức năng

và yêu cầu không chức năng của phần mềm.
 Các testcase cần bao phủ tất cả khía cạnh kiểm thử cho từng yêu cầu phần mềm.
 Các testcase cần bao phủ tất cả yêu cầu trong các chiến lược kiểm thử.
 Nếu cần kiểm thử tự động, Test Designer sẽ xây dựng các kịch bản dựa trên các

testcase.
Các testcase cần được:
 Xem xét lại bởi người quản lý dự án, lập trình viên có liên quan, các kiểm thử viên


khác, Test Leader, nhân viên phân tích nghiệp vụ và khách hàng.
 Chấp thuận bởi Test Leader hoặc khách hàng.
 Hiệu chỉnh/cập nhật nếu Tester đã tìm được những lỗi mà không nằm trong
testcase hiện có.
c, Tiến hành kiểm thử (Test Executing)
Các kiểm thử viên sẽ được bố trí công việc bởi Test Leader để tiến hành kiểm thử.
 Thi hành kiểm thử theo từng trường hợp kiểm thử (testcase).
 Kiểm thử lại các lỗi đã được sửa.
 Kiểm thử viên sẽ tạo các báo cáo về lỗi trong suốt quá trình kiểm lỗi và theo dõi

chúng cho đến khi chúng đã được xử lý.
 Ở công đoạn kiểm thử chấp nhận, khách hàng sẽ thi hành kiểm thử để kiểm định
xem hệ thống phần mềm có thỏa mãn các nhu cầu của người dùng không?
d, Báo cáo kiểm thử và đánh giá (Test Report and Evaluation)
Test Manager hoặc Test Leader sẽ phân tích các lỗi trong hệ thống teo dõi các lỗi.






Tạo các báo cáo lỗi (nếu có).
Đánh giá các kết quả kiểm thử, thống kê các yêu cầu thay đổi.
Tính và phân phối các thông tin đo lường hoạt động kiểm thử.
Tạo bảng tổng kết đánh giá hoạt động kiểm lỗi.
Xác định xem đã đạt tiêu chí thành công và hoàn thành kiểm thử chưa.

3.2. Trường hợp kiểm thử (Test case)
3.2.1. Định nghĩa
Test case là mô tả một dữ liệu đầu vào, hành động và một kết quả mong đợi

(expected result) để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay
không. Test case thường được viết trên excel. Một file Testcase cơ bản cần có các trường
22


sau: TestcaseID, mục tiêu test, các bước thực hiện test, và kết quả trả về (expected result)
có đúng với yêu cầu test không.Ngoài ra còn có thể có thêm điều kiện tiên quyết và dữ
liệu test.
Để viết được testcases có hiệu quả bao phủ hết các trường hợp cần test thì testcases
phải có đầy đủ hết các Nghiệp vụ mà hệ thống yêu cầu (các yêu cầu trong tài liệu Đặc tả
ko được bỏ sót), sử dụng các kỹ thuật thiết kế test case để viết được test case có độ bao
phủ tối đa.
3.2.2. Các phương pháp thiết kế testcase
Bất kỳ sản phẩm kỹ thuật nào (phần mềm không phải ngoại lệ) đều có thể được
kiểm thử bởi 1 trong 2 cách:
 Kiểm thử hộp đen (Black box testing): theo góc nhìn sử dụng
• Không cần kiến thức về chi tiết thiết kế và thành phần bên trong hệ thống.
• Kiểm thử dựa trên các yêu cầu và đặc tả sử dụng phần mềm.
 Kiểm thử hộp trắng (White box testing): theo góc nhìn hiện thực
• Cần kiến thức về chi tiết thiết kế và thành phần bên trong hệ thống.
• Kiểm thử dựa vào phủ các lệnh, phủ các nhánh, phủ các điều kiện con.

Bảng 1: Các kỹ thuật kiểm thử
Kiểu kiểm thử
Kiểm thử đơn vị
Kiểm thử tích hợp
Kiểm thử chức năng
Kiểm thử hệ thống
Kiểm thử chấp nhận


Kỹ thuật kiểm thử được dùng
Kiểm thử hộp trắng, hộp đen
Kiểm thử hộp trắng, hộp đen
Kiểm thử hộp đen
Kiểm thử hộp đen
Kiểm thử hộp đen

3.3. Kế hoạch kiểm thử
3.3.1. Định nghĩa
Kế hoạch kiểm thử thường được để trong 1 tài liệu và chứa các kết quả của các
hoạt động sau: (7)
 Nhận dạng các chiến lược được dùng để kiểm tra và đảm bảo rằng sản phẩm thỏa

mãn đặc tả thiết kế phần mềm và các yêu cầu khác về phần mềm.
 Định nghĩa các mục tiêu và phạm vi kiểm thử.
 Nhận dạng phương pháp luận mà đội kiểm thử sẽ dùng để thực hiện công việc
23







kiểm thử.
Nhận dạng phần cứng, phần mềm và các tiện ích cần cho kiểm thử.
Nhận dạng các tính chất và các chức năng sẽ được kiểm thử.
Xác định các hệ số rủi ro gây nguy hại cho việc kiểm thử.
Test Leader sẽ xây dựng kế hoạch kiểm thử


3.3.2. Mục đích cần phải có kế hoạch kiểm thử
Kế hoạch kiểm thử cần được xây dựng sớm nhằm:






Tập hợp và tổ chức các thông tin kiểm thử cần thiết.
Cung cấp thông tin về quy trình kiểm thử sẽ xảy ra trong tổ chức kiểm thử.
Cho mỗi thành viên trong đội kiểm thử có hướng đi đúng.
Gán các trách nhiệm rõ rang cụ thể cho mỗi thành viên đội kiểm thử.
Có lịch biểu làm việc rõ rang và các thành viên có thể làm việc với nhau tốt.

3.3.3. Kế hoạch kiểm thử
Kế hoạch kiểm thử được xây dựng dựa theo kế hoạch xây dựng hệ thống và kế
hoạch triển khai, thông thường sẽ được thực hiện theo các giai đoạn dưới đây:

24


Bảng2: Bảng kế hoạch test
Giai đoạn dự án
Phân tích, thiết
kế hệ thống
Xây dựng hệ
thống

Công việc kiểm thử được thực hiện
Xây dựng chiến lược kiểm thử

Xây dựng kịch bản kiểm thử (một phần)
Xây dựng kế hoạch kiểm thử
Xây dựng kịch bản kiểm thử
Chuẩn bị môi trường kiểm thử
Tiến hành kiểm thử đơn vị/Kiểm thử hệ thống

Người thực hiện
Quản trị dự án
Nhóm nghiệp vụ
Quản trị dự án
Nhóm nghiệp vụ
Nhóm kỹ thuật
Nhóm nghiệp vụ/
kiểm thử
Kiểm thử chấp nhận của người sử dụng
Các cán bộ nghiệp
vụ chủ chốt của
khách hàng
Triển khai
Kiểm thử hiệu năng
Nhóm triển khai
Kiểm tra tính sẵn sang của hệ thống trước Nhóm kỹ thuật
khi đi vào vận hành
3.4. Các kỹ thuật kiểm thử ứng dụng Web
3.4.1. Các kỹ thuật kiểm thử ứng dụng Web
Để kiểm thử 1 ứng dụng web chúng ta sẽ kiểm thử theo các kỹ thuật sau:








Kiểm thử chức năng
Kiểm thử tính sử dụng
Kiểm thử giao diện
Kiểm thử tính tương thích
Kiểm thử hiệu năng/năng suất
Kiểm thử độ an toàn/bảo mật

a, Kiểm thử chức năng
Việc kiểm thử chức năng yêu cầu tester thực hiện test tất cả các link trong trang
web, định dạng được sử dụng trong các trang web để gửi và nhận các thông tin cần thiết từ
người dùng. Ngoài ra còn có kết nối cơ sở dữ liệu, kiểm tra cookies và xác minh
HTML/CSS.
 Kiểm tra các liên kết (links) bao gồm kiểm tra liên kết ngoài trang web, liên kết

nội bộ, liên kết tới các vị trí trong cùng trang, liên kết sử dụng để gửi email tới
admin hoặc người dùng khác trong trang…
 Kiểm tra form của các trang: form là phần cơ bản của các trang web, nên cần được
kiểm tra một cách kỹ càng, bao gồm các yêu cầu sau:
• Không nhập gì vào các trường bắt buộc thì sao?
• Giá trị mặc định của các trường là gì?
25