Tải bản đầy đủ (.docx) (43 trang)

Báo Cáo Thực Tập Nghề Nghiệp - Quản Trị Hệ Thống Thông Tin - Đề Tài - Nghiên Cứu Kiểm Thử Thủ Công Trên Ứng Dụng BOOKING SPA tại CÔNG TY NINE PLUS SOLUTIONS VÀ LÝ THUYẾT VỀ NGÀNH TESTER

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.55 MB, 43 trang )

TRƯỜNG ĐẠI HỌC KINH TẾ

KHOA THỐNG KÊ – TIN HỌC

BÁO CÁO THỰC TẬP NGHỀ NGHIỆP

NGÀNH HỆ THỐNG THÔNG TIN QUẢN LÝ
CHUYÊN NGÀNH QUẢN TRỊ HỆ THỐNG THÔNG TIN

Đề tài:
NGHIÊN CỨU KIỂM THỬ THỦ CÔNG TRÊN ỨNG DỤNG

2

MỤC LỤC

LỜI CẢM ƠN iii

LỜI CAM ĐOAN iv

MỤC LỤC v

DANH MỤC HÌNH ẢNH viii

DANH MỤC BẢNG BIỂU ix

LỜI MỞ ĐẦU 1

CHƯƠNG 1 : TỔNG QUAN CÔNG TY NINE PLUS SOLUTIONS VÀ LÝ

THUYẾT VỀ NGÀNH TESTER 2



1.1. Giới thiệu tổng quát về công ty Nine Plus Solutions 2

1.1.1. Quá trình hình thành và phát triển của công ty 2

1.1.2. Tầm nhìn và sứ mệnh 2

1.1.3. Dịch vụ 2

1.1.4. Giải pháp công nghệ 3

1.2. Tổng quan về vị trí việc làm Tester 4

1.3. Cơ hội nghề nghiệp với vị trí Tester 5

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT VỀ TESTER 6

2.1. Tổng quan về kiểm thử phần mềm 6

2.1.1. Giới thiệu về kiểm thử phần mềm 6

2.1.2. Mục tiêu của kiểm thử 6

2.1.3. Quy trình phát triển phần mềm 6

2.1.4. Các nguyên tắc của kiểm thử phần mềm 8

3

2.1.5. Phân biệt Error/ Fault/ Failure 10


2.1.6. Phân biệt Verification & Validation 10

2.1.7. Phân biệt QA & QC 11

2.2. Các loại kiểm thử phần mềm 12

2.2.1. Functional testing 12

2.2.2. Non - Functional testing 13

2.2.3. Structural testing 14

2.2.4. Confirmation and regression testing 15

2.3. Các phương pháp kiểm thử phần mềm 16

2.3.1. White Box Testing 16

2.3.2. Black Box Testing 17

2.3.3. Gray Box Testing 18

2.4. Mức độ của kiểm thử 19

2.4.1. Unit Testing 19

2.4.2. Integration Testing 19

2.4.3. System Testing 20


2.4.4. Acceptance Testing 20

2.5. Tổng quan về Test case 21

2.5.1. Khái niệm 21

2.5.2. Kỹ thuật thiết kế Test case 22

2.6 Kết chương 24

CHƯƠNG 3: TRIỂN KHAI KIỂM THỬ THỦ CÔNG TRÊN HỆ THỐNG

BOOKING SPA 25

3.1 Tổng quan về dự án Booking Spa 25

4

3.1.1. Break down task 25

3.1.2. Database Design 27

3.2 Kiểm thử module Quản lý khách hàng 27

3.1.1 Kiểm thử chức năng Danh sách khách hàng 27

3.1.2 Kiểm thử chức năng Thêm mới khách hàng 30

3.3 Kết quả sau khi Test 33


3.3 Báo cáo Bugs 33

3.6 Kết chương 34

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 35

TÀI LIỆU THAM KHẢO 37

5

DANH MỤC HÌNH ẢNH

Hình 1: Hình ảnh logo cơng ty Nine Plus Solutions 2

Hình 2: Hình ảnh mơ tả phương pháp White Box Testing 17

Hình 3: Hình ảnh mơ tả phương pháp Black Box Testing 18

Hình 4: Hình ảnh mơ tả phương pháp Gray Box Testing 19

Hình 5: Database của dự án 27

Hình 6: Giao diện chức năng danh sách khách hàng 27

Hình 7: Test case cho chức năng Danh sách khách hàng 28

Hình 8: Test case cho chức năng Danh sách khách hàng 28

Hình 9: Test case cho chức năng Danh sách khách hàng 29


Hình 10: Giao diện chức năng Thêm mới khách hàng 30

Hình 11: Giao diện chức năng Thêm mới khách hàng 30

Hình 12: Test case cho chức năng Thêm mới khách hàng 31

Hình 13: Test case cho chức năng Thêm mới khách hàng 31

Hình 14: Test case cho chức năng Thêm mới khách hàng 31

Hình 15: Test case cho chức năng Thêm mới khách hàng 32

Hình 16: Test case cho chức năng Thêm mới khách hàng 32

Hình 17: Test case cho chức năng Thêm mới khách hàng 32

Hình 18: Kết quả test chức năng Danh sách khách hàng 33

Hình 19: Kết quả test chức năng Thêm mới khách hàng 33

Hình 20: Báo cáo Bugs 33

Hình 21: Báo cáo Bugs 34

6

DANH MỤC BẢNG BIỂU

Bảng 1: Bảng phân chia chức năng nhiệm vụ của Admin 26


Bảng 2: Bảng phân chia chức năng nhiệm vụ của Client 26

7

LỜI MỞ ĐẦU
1. Mục tiêu của đề tài

Mục tiêu của nghiên cứu là tiến hành kiểm thử thủ công trên ứng dụng Booking Spa để
đánh giá tính năng, tìm ra các lỗi và sự cố có thể xảy ra trong quá trình sử dụng ứng
dụng. Nghiên cứu sẽ tập trung vào việc xác định khả năng ứng dụng đáp ứng yêu cầu
chức năng, giao diện người dùng và hiệu suất. Kết quả từ nghiên cứu này sẽ cung cấp
thông tin quan trọng để cải thiện chất lượng và đáng tin cậy của ứng dụng Booking Spa.
2. Đối tượng và phạm vi nghiên cứu

Đối tượng và phạm vi của nghiên cứu sẽ tập trung vào kiểm thử thủ cơng của tính
năng chính của ứng dụng Booking Spa, bao gồm quá trình đặt lịch, quản lý thơng tin
khách hàng, thanh tốn và xử lý đánh giá. Nghiên cứu sẽ không đi sâu vào kiểm thử tự
động hoặc kiểm thử bảo mật, mà tập trung vào các khía cạnh chính liên quan đến trải
nghiệm người dùng.
3. Kết cấu của đề tài

Đề tài được tổ chức gồm phần mở đầu, 3 chương nội dung và phần kết luận...
- Mở đầu
- Chương 1: Tổng quan về công ty Nine Plus Solutions và lý thuyết về ngành

Tester
- Chương 2: Cơ sở lý thuyết về Tester
- Chương 3: Triển khai kiểm thử thủ công trên hệ thống Booking Spa
- Kết luận và hướng phát triển


8

CHƯƠNG 1 : TỔNG QUAN CÔNG TY NINE PLUS SOLUTIONS VÀ LÝ
THUYẾT VỀ NGÀNH TESTER

1.1. Giới thiệu tổng quát về công ty Nine Plus Solutions
1.1.1. Quá trình hình thành và phát triển của công ty

Công ty Nine Plus Solutions được thành lập vào tháng 2 năm 2021, là 1 công ty
vừa là outsource vừa là product đã có nhiều năm kinh nghiệm hợp tác làm việc cùng các
cơng ty trong và ngồi nước. Cơng ty hiểu rõ những điều cần thiết nhất để triển khai một
dự án outsource thành công cho khách hàng. Luôn tận dụng tối đa nguồn nhân lực với chi
phí phù hợp nhất.

Hình 1: Hình ảnh logo công ty Nine Plus Solutions
- Tháng 2 năm 2021, thành lập công ty Nine Plus Solutions.
- Tháng 3 năm 2022, công ty mở văn phịng đại diện tại 193 Xơ Viết Nghệ Tĩnh, Đà

Nẵng sau khoảng thời gian dịch covid phát triển mạnh.
- Tháng 10 năm 2022, công ty đạt được 50 thành viên.
- Tháng 12 năm 2022, công ty mở rộng hợp tác với công ty Hàn Quốc.
1.1.2. Tầm nhìn và sứ mệnh

Tầm nhìn của cơng ty là xây dựng một công ty công nghệ cung cấp những giải
pháp công nghệ thông tin, giải pháp chuyển đổi số.

Sứ mệnh của công ty là làm vượt xa sự mong đợi của khách hàng bằng cách vượt
ra ngoài phần mềm để cung cấp các giải pháp Web tốt nhất chuyển đổi dữ liệu thành kiến
thức, cho phép họ giải quyết các vấn đề của mình.

1.1.3. Dịch vụ

● Giải pháp ERP

9

Bạn đang tìm kiếm phần mềm hoạch định nguồn lực doanh nghiệp? Chúng tơi có
thể giúp bạn xây dựng một giải pháp ERP đáp ứng nhu cầu kinh doanh phù hợp với tầm
nhìn sứ mệnh của tổ chức doanh nghiệp.

● Phát triển ứng dụng di dộng

Tại Nine Plus, chúng tôi muốn hợp tác với bạn để định hướng phát triển ứng dụng
di động của bạn. Chúng tôi sử dụng các phương pháp có cấu trúc, được tổ chức tốt trong
quá trình phát triển ứng dụng dành cho thiết bị di động của mình, đảm bảo rằng bạn nhận
được các giải pháp chất lượng hàng đầu cho doanh nghiệp của mình và đáp ứng kết quả
mong muốn của bạn.

● Hệ thống quản lý nội dung (WordPress)

42% trang web được xây dựng trên WordPress. Nhiều blogger, doanh nghiệp nhỏ
và các công ty trong danh sách Fortune 500 sử dụng WordPress hơn tất cả các tùy chọn
khác cộng lại.

● Thiết kế Web

Thiết kế website chuyên nghiệp sẽ là chìa khóa dẫn đến sự thành cơng cho doanh
nghiệp của bạn. Bằng cách thuê nguồn nhân lực CNTT ngoài để thiết thiết kế web sẽ giúp
bạn tiết kiệm chi phí hơn mà không ảnh hưởng đến chất lượng. Tất cả các thiết kế web
được gia công bởi Nine Plus đều là sự riêng biệt và độc đáo.


● Phát triển ứng dụng Web

Tương tự ứng dụng di dộng, Nine Plus hợp tác với khách hàng để định hướng phát
triển ứng dụng Web theo hướng khách hàng mong muốn

● Dịch vụ cung ứng nhân lực

Nếu doanh nghiệp có đang phải đối mặt với sự thiếu hụt kỹ sư phần mềm? Có thể
đội ngũ nội bộ của doanh nghiệp khơng thể theo kịp với nhu cầu ngày càng cao? Dịch vụ
cung ứng nhân lực của Nine Plus là một giải pháp tuyệt vời cho các doanh nghiệp cần
thêm năng lực hoặc chun mơn cụ thể mà họ khơng có sẵn.
1.1.4. Giải pháp công nghệ

● Nine+ Hệ thống đặt chỗ

10

Hệ thống đặt phịng trực tuyến. Đặt trang web hoặc tiện ích cho trang web của
riêng bạn. Cho phép khách hàng lên lịch cuộc hẹn, nhận lời nhắc và thanh toán trực tuyến
24/7.

● Nine+ ERP
Giải pháp hoạch định nguồn lực doanh nghiệp.

● Nine+ Học điện tử
Hệ thống quản lý giáo dục & khóa học trực tuyến.

● Nine+ Nền tảng thương mại điện tử
Xây dựng nền tảng mạng xã hội, truyền thông.


● Nine+ Nền tảng khách hàng thân thiết
Nền tảng để xây dựng hệ thống khách hàng thân thiết.

● Nine+ Nền tảng ví điện tử
Giải pháp ví kỹ thuật số, Nền tảng ví điện tử trực tuyến.

1.2. Tổng quan về vị trí việc làm Tester
Vị trí tester đóng vai trò quan trọng trong lĩnh vực phát triển ứng dụng. Để tạo ra

những ứng dụng hoàn hảo và tối ưu cho người dùng, đòi hỏi bộ phận tester phải kiểm tra
luồng hệ thống, chạy thử phần mềm để phát hiện lỗi và điều chỉnh kịp thời.

Tester là người kiểm tra và chạy thử phần mềm, chịu trách nhiệm phát triển chất
lượng, tối ưu quy trình và giao diện người dùng trước khi đưa sản phẩm công nghệ vào
ứng dụng thực tế. Tuỳ thuộc vào từng lĩnh vực mà nhân viên tester có thể thực hiện kiểm
tra thử ứng dụng phần phương pháp thủ cơng hoặc bằng các phần mềm khác. Có thể hiểu
đơn giản hơn, một nhân viên tester cần đảm bảo phần mềm khơng phát sinh lỗi hay sự cố
gì khi đưa vào sử dụng thực tế.

Nhiệm vụ của Tester là tìm kiếm bugs hay errors (được hiểu là những lỗi phần
mềm mà người dùng có thể gặp phải). Sau đó ghi chú và báo cáo lại cho bộ phận lập trình
viên để họ “fix bug” (sửa lỗi) và hoàn thiện sản phẩm.

Mô tả công việc của Tester cụ thể như sau:

11

● Nghiên cứu, phân tích những yêu cầu liên quan đến kỹ thuật


Tester sẽ phối hợp cùng bộ phận lập trình viên để làm việc cùng khách hàng, lắng
nghe và tìm hiểu nhu cầu của khách hàng để đưa ra phân tích, phương án sản phẩm phù
hợp với yêu cầu của khách hàng. Khi đó, tester sẽ thẩm định các tài liệu liên quan, đảm
bảo chất lượng phần mềm đúng với yêu cầu sử dụng và xây dựng bản mô tả vắn tắt giúp
người dùng dễ dàng sử dụng.

● Đánh giá, phát hiện những vấn đề của phần mềm
Một trong những nhiệm vụ chính của nhân viên tester chính là kiểm thử phần

mềm và phát hiện lỗi hệ thống. Có thể nói, tìm lỗi là một trong những kỹ năng cần thiết
đối với tester, đòi hỏi tester phải có khả năng đánh giá và quan sát nhạy bén để tìm thấy
những lỗi quan trọng trong hệ thống, từ đó nâng cao hiệu suất cơng việc.

● Ngăn ngừa những lỗi có khả năng phát sinh của phần mềm

Nhiệm vụ của nhân viên tester không chỉ là tìm ra lỗi phần mềm mà cịn phải phối
hợp với bộ phận lập trình để giải quyết những lỗi phát sinh ngay từ ban đầu giúp doanh
nghiệp tối ưu chi phí, nguồn lực và thời gian xây dựng sản phẩm.

● Một số công việc liên quan khác

Ngoài những cơng việc chính được mơ tả như trên, nhân viên tester cịn có nhiệm
vụ khác như: tương tác với khách hàng để hiểu rõ yêu cầu, xây dựng kịch bản hoặc danh
mục cần kiểm tra khi chạy thử phần mềm, chuẩn bị báo cáo liên quan đến việc kiểm thử
phần mềm, hỗ trợ lập trình viên phát triển phần mềm,...

1.3. Cơ hội nghề nghiệp với vị trí Tester
Với sự phát triển nhanh chóng của cơng nghệ và ngành cơng nghiệp phần mềm, việc
làm Tester ngày càng trở nên quan trọng và có nhiều cơ hội. Cơng việc Tester có thể tìm
thấy trong các cơng ty phần mềm, cơng ty phát triển ứng dụng di động, công ty dịch vụ

công nghệ thông tin, và các tổ chức chuyên về phát triển phần mềm. Đồng thời, nhu cầu
tuyển dụng Tester cũng đang gia tăng trong các dự án phát triển phần mềm lớn và quy
mô lớn.

12

CHƯƠNG 2: CƠ SỞ LÝ THUYẾT VỀ TESTER

1.1. Tổng quan về kiểm thử phần mềm
1.1.1. Giới thiệu về kiểm thử phần mềm

Kiểm thử phần mềm là phương pháp kiểm tra xem sản phẩm phần mềm đó trên
thực tế có phù hợp với các yêu cầu đã đặt ra hay khơng, và đảm bảo rằng khơng có lỗi
hay khiếm khuyết. Nó bao gồm việc kiểm tra, phân tích, quan sát và đánh giá các khía
cạnh khác nhau của sản phẩm. Người kiểm thử phần mềm (Tester) sử dụng kết hợp các
công cụ thủ công và tự động. Sau khi tiến hành kiểm thử, Tester báo cáo kết quả cho
team phát triển. Mục đích là xác định các lỗi, khiếm khuyết hoặc các yêu cầu còn thiếu so
với yêu cầu thực tế.
1.1.2. Mục tiêu của kiểm thử

- Xác định phần mềm phù hợp với yêu cầu đặc tả
- Xác định phần mềm phù hợp với nhu cầu người dùng
- Đủ tự tin để cung cấp một sản phẩm chất lượng
- Phát hiện các lỗi trong quá trình phát triển phần mềm
1.1.3. Quy trình phát triển phần mềm
Quy trình phát triển phần mềm là một chuỗi các bước và hoạt động được thực hiện
để thiết kế, phát triển và triển khai một sản phẩm phần mềm. Quy trình này giúp đảm bảo
rằng phần mềm được xây dựng đúng tiêu chuẩn, chất lượng và đáp ứng yêu cầu của
khách hàng. Dưới đây là một quy trình phát triển phần mềm phổ biến được gọi là "Quy
trình phát triển phần mềm chuẩn" (SDLC - Software Development Life Cycle):

1. Phân tích yêu cầu:
Thu thập và phân tích yêu cầu từ khách hàng hoặc người dùng cuối.
Xác định yêu cầu chức năng, phi chức năng và ràng buộc của phần mềm.
2. Thiết kế:
Thiết kế kiến trúc tổng thể của phần mềm dựa trên yêu cầu đã phân tích.

13

Chia nhỏ hệ thống thành các thành phần nhỏ hơn và xác định các giao diện giữa
chúng.
Lựa chọn công nghệ và các công cụ phù hợp để triển khai hệ thống.
3. Phát triển:
Thực hiện việc lập trình và viết mã dựa trên thiết kế đã được xác định.
Xây dựng các chức năng và tính năng của phần mềm.
Kiểm tra từng phần của mã để đảm bảo tính đúng đắn và hiệu quả.
4. Kiểm thử:
Thực hiện các ca kiểm thử để đảm bảo rằng phần mềm hoạt động chính xác và
không có lỗi.
Phát hiện và sửa lỗi nếu có.
Kiểm tra tính bảo mật và hiệu suất của phần mềm.
5. Triển khai:
Đưa phần mềm vào môi trường thực tế.
Đào tạo người dùng cuối và hướng dẫn họ sử dụng sản phẩm.
Tiến hành triển khai và cài đặt phần mềm trên hệ thống thực tế.
6. Vận hành và bảo trì:
Theo dõi và duy trì phần mềm sau khi nó đã được triển khai.
Sửa lỗi và cải tiến phần mềm khi cần thiết.
Đáp ứng các yêu cầu và phản hồi từ người dùng cuối.
Có 3 kiểu mơ hình phát triển phần mềm được áp dụng phổ biến: Waterfall
model (Mơ hình thác nước), V model (Mơ hình chữ V), Agile model & Scrum Process

Waterfall model (Mơ hình thác nước)
Waterfall model được coi là mơ hình phát triển phần mềm đầu tiên được sử dụng.
Đây là mơ hình áp dụng theo tính tuần tự của các giai đoạn phát triển phần mềm; giai

14

đoạn sau chỉ được thực hiện tiếp khi giai đoạn trước đã kết thúc. Nhược điểm của mơ
hình này là khơng được quay lại giai đoạn trước để xử lí các thay đổi trong u cầu. Vì
vậy, mơ hình thác nước chỉ phù hợp với các dự án không thường xuyên bị thay đổi về
nghiệp vụ.

V model (Mơ hình chữ V)

V model là quy trình được sử dụng nhiều tại các cơng ty sản xuất phần mềm. Khi
áp dụng V model, toàn bộ quy trình phát triển phần mềm được chia thành 2 giai đoạn tiến
hành song song tương ứng nhau: Phát triển và Kiểm thử. Trong mơ hình chữ V, việc
kiểm thử được diễn ra ngay từ giai đoạn lấy yêu cầu nên lỗi được tìm ra ngay từ sớm để
khắc phục. Muốn áp dụng được mơ hình chữ V thì u cầu phần mềm phải xác định rõ
ràng; công nghệ phần mềm và các cơng cụ phải được tìm hiểu kỹ.

Agile model & Scrum Process

Agile model được tạo ra dựa trên 2 mơ hình: Iterative (Lặp lại) và Incremental
(Tăng dần). Mơ hình Agile có thể được sử dụng với bất kỳ loại hình dự án nào, nhưng
cần sự tham gia và tính tương tác của khách hàng. Agile được sử dụng khi khách hàng
yêu cầu chức năng sẵn sàng trong khoảng thời gian ngắn như 3 - 4 tuần.

Scrum là một “khung quản lý dự án” được áp dụng rất rộng rãi từ những dự án
đơn giản với một nhóm phát triển nhỏ cho đến những dự án có yêu cầu rất phức tạp với
hàng trăm người tham gia. Ngoài ra, Scrum Process cũng phù hợp với những dự án đòi

hỏi khung thời gian cố định.

Trong Scrum, công việc sẽ được chia nhỏ thành nhiều giai đoạn gọi là Sprint. Mỗi
Sprint chỉ kéo dài từ 1 đến 4 tuần, không quá một tháng. Đầu Sprint sẽ lên kế hoạch làm
những yêu cầu nào rồi thực hiện code và test. Cuối Sprint là một sản phẩm hoàn thiện cả
code lẫn test có thể demo và chạy được.
1.1.4. Các nguyên tắc của kiểm thử phần mềm

1. Kiểm thử chứng minh sự hiện diện của lỗi

Kiểm thử chỉ có thể chứng minh được rằng sản phẩm có lỗi. Kiểm thử phần mềm
khơng thể chứng mình rằng sản phẩm khơng cịn lỗi. Nghĩa là sản phẩm ln có lỗi cho

15

dù có kiểm thử nhiều bao nhiêu. Do đó, điều quan trọng là chúng ta phải thiết kế các
trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt.

2. Kiểm thử toàn bộ là không thể

Hầu hết các sản phẩm ngày nay rất đa dạng và phức tạp do được phát triển trên
nhiều nền tảng, công nghệ phong phú cũng như khả năng lưu trữ kết nối dữ liệu lớn,
khiến việc kiểm thử trở nên khó khăn và việc kiểm thử toàn bộ là gần như không thể.
Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là khơng thể trừ
phi nó chỉ bao gồm ít trường hợp thì có thể kiểm thử tồn bộ.

3. Kiểm thử càng sớm càng tốt

Nguyên tắc này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của
vòng đời phát triển phần mềm. Các hoạt động kiểm thử phần mềm từ giai đoạn đầu sẽ

giúp phát hiện bug sớm hơn. Nó cho phép chuyển giao phần mềm theo yêu cầu đúng thời
gian với chất lượng dự kiến.

4. Lỗi thường được phân bố tập trung

Thông thường, phần lớn lỗi tập trung vào những module, thành phần chức năng
chính của hệ thống. Điều này cũng thuận theo nguyên lý Pareto: 80% số lượng lỗi được
tìm thấy trong 20% tính năng của hệ thống. Nếu bạn thành công xác định được điều
này, bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Nó được coi là một
trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả.

5. Nghịch lý thuốc trừ sâu

Trong kiểm thử phần mềm, nếu bạn cứ thực thi lặp đi lặp lại một bộ test case thì
có khả năng rất thấp bạn sẽ tìm được lỗi từ những trường hợp kiểm thử này. Nguyên
nhân là do khi hệ thống ngày càng hồn thiện, những lỗi được tìm thấy lúc trước đã được
sửa trong khi những trường hợp kiểm thử đã cũ. Do đó, khi một lỗi được sửa hay một
tính năng mới được thêm vào, chúng ta nên tiến hành làm regression (kiểm thử hồi qui)
nhằm mục đích đảm bảo những thay đổi này không ảnh hưởng đến những vùng khác của
sản phẩm.

6. Kiểm thử phụ thuộc vào ngữ cảnh

16

Theo nguyên tắc này thì nếu bạn đang kiểm thử ứng dụng web và ứng dụng di
động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì điều đó là sai lầm. Chiến
lược để kiểm thử nên khác nhau và phụ thộc vào chính ứng dụng đó.

7. Quan niệm sai lầm về việc “hết lỗi”


Việc khơng tìm thấy lỗi trên sản phẩm khơng đồng nghĩa với việc sản phẩm đã sẵn
sàng để tung ra thị trường. Việc khơng tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm
thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì
nhằm tìm kiếm lỗi mới.
1.1.5. Phân biệt Error/ Fault/ Failure

Trong kiểm thử phần mềm, "error" là lỗi do con người gây ra trong quá trình kiểm
thử, "fault" là lỗi công nghệ trong mã nguồn phần mềm, và "failure" là sự cố hoặc hiện
tượng không thể hoạt động đúng do có lỗi trong phần mềm. Cụ thể thì:

1. Error (Lỗi):

Trong kiểm thử phần mềm, lỗi (error) được hiểu là một tình huống mà một con
người thực hiện sai hoặc không thực hiện đúng các u cầu hoặc quy trình kiểm thử.
Điều này có thể là kết quả của việc hiểu sai yêu cầu, thiết kế khơng chính xác, hoặc mắc
lỗi khi thực hiện kiểm thử. Lỗi thường do con người gây ra và có thể được phát hiện và
sửa chữa trong q trình kiểm thử.

2. Fault (Lỗi công nghệ):

Fault trong kiểm thử phần mềm thường được hiểu là một khuyết điểm hoặc sai sót
trong mã nguồn của phần mềm. Đây là nguyên nhân gốc rễ của lỗi và được coi là lỗi
cơng nghệ. Fault có thể do sai sót trong việc thiết kế, triển khai hoặc lập trình phần mềm.
Trong kiểm thử phần mềm, cơng việc chính là tìm ra và báo cáo các lỗi này để nhà phát
triển có thể khắc phục chúng.

3. Failure (Lỗi hoạt động):

Failure là một sự cố hoặc hiện tượng không thể hoạt động đúng theo yêu cầu hoặc

mong đợi. Trong kiểm thử phần mềm, failure là kết quả của việc sử dụng phần mềm hoặc
hệ thống có chứa lỗi (fault) đã được tìm thấy trong quá trình kiểm thử. Failure là điều mà

17

người dùng hoặc hệ thống cuối cùng phải đối mặt khi sử dụng phần mềm không hoạt
động đúng.
1.1.6. Phân biệt Verification & Validation

Trong ngữ cảnh testing, 2 khái niệm Verification (Xác minh) và Validation (Xác
nhận) được sử dụng rộng rãi. Trong đa số các trường hợp, chúng ta thường coi chúng có
cùng nghĩa nhưng thực ra nó là 2 khái niệm khác nhau.

Verification là một quá trình đánh giá các sản phẩm làm việc trung gian của một
vòng đời phát triển phần mềm để kiểm tra xem liệu rằng chúng ta có đi đúng hướng để
tạo ra sản phẩm cuối cùng.

Validation là quá trình đánh giá sản phẩm cuối cùng để kiểm tra xem phần mềm
có đáp ứng được yêu cầu nghiệp vụ không? Hoạt động validation bao gồm smoke testing,
functional testing, regression testing, systems testing etc…

Và đây là sự khác nhau giữa Verifycation và Validation:

Verification:
● Đánh giá các sản phẩm trung gian để kiểm tra xem nó có đáp ứng các yêu cầu cụ

thể của từng giai đoạn không.
● Kiểm tra xem sản phẩm có được xây dựng đúng theo yêu cầu và đặc điểm kỹ thuật

thiết kế không.

● Kiểm tra xem "Chúng tôi xây dựng sản phẩm đúng không"?
● Điều này được thực hiện mà không cần chạy phần mềm.
● Bao gồm tất cả các kỹ thuật test tĩnh Ví dụ bao gồm các bài đánh giá, kiểm tra và

hướng dẫn

Validation:
● Đánh giá sản phẩm cuối cùng để kiểm tra xem nó có đáp ứng được yêu cầu nghiệp

vụ không.
● Xác định xem phần mềm có phù hợp với nhu cầu sử dụng và đáp ứng yêu cầu

nghiệp vụ không.
● Kiểm tra "Chúng tôi xây dựng đúng sản phẩm"?

18

● Được thực hiện cùng với việc chạy phần mềm.
● Bao gồm tất cả các kỹ thuật test động Ví dụ bao gồm tất cả các loại test như

smoke test, regression test, functional test, systems test và UAT.
1.1.7. Phân biệt QA & QC

1. Sự khác nhau về định nghĩa: QA là đảm bảo chất lượng, Còn QC là Kiểm soát
chất lượng.

2. Khác nhau về mục đích: QA nhằm mục đích ngăn ngừa những lỗi sai và ngăn
ngừa những rủi ro liên quan đến chất lượng. Trong khi QC có mục đích nhằm phát hiện
lỗi sai trong sản phẩm và tiến hành sửa chữa chúng.


3. Phạm vi của QA và QC: QA có quy trình làm việc rộng hơn so với QC.

4. Thời điểm áp dụng QC và QA: QA sẽ được thực hiện diễn ra trong suốt q
trình làm sản phẩm. Cịn QC chỉ thực hiện sau khi có sản phẩm hồn thiện.

5. Sự khác nhau giữa các hoạt động của QA và QC trong doanh nghiệp. Đây cũng
là điểm khác biệt dễ dàng nhận thấy nhất của QA và QC. Các hoạt động có thể kể đến
như:

Đối với QA: Các hoạt động bao gồm: Đảm bảo chất lượng, kiểm toán chất lượng
sản phẩm, dịch vụ. Xác định quy trình. Đồng thời nhận dạng và lựa chọn quy trình sao
cho phù hợp. QA cũng cho phép hoạt động đào tạo về quy trình và tiêu chuẩn chất lượng.

Đối với QC: Các hoạt động của QC có thể kể đến bao gồm: Kiểm soát chất lượng,
hướng dẫn, thử nghiệm, điều tra, đánh giá kết quả, đưa ra phương án khác.

Tóm lại thì:

QA (Đảm bảo chất lượng) tập trung vào việc đảm bảo rằng quy trình và phương
pháp là chính xác để sản xuất sản phẩm hoặc dịch vụ chất lượng cao.

QC (Kiểm soát chất lượng) tập trung vào việc kiểm tra và kiểm soát chất lượng
của sản phẩm hoặc dịch vụ cuối cùng trước khi nó được cung cấp cho khách hàng.

1.2. Các loại kiểm thử phần mềm
1.2.1. Functional testing

19

Kiểm thử chức năng là một loại kiểm thử phần mềm tập trung vào đảm bảo rằng

các chức năng của phần mềm hoạt động đúng theo yêu cầu và các kịch bản đã được xác
định trước. Mục tiêu của kiểm thử chức năng là đảm bảo rằng phần mềm thực hiện đúng
các chức năng đã được thiết kế và được mong đợi sẽ hoạt động một cách chính xác trong
mơi trường thực tế.

Quá trình kiểm thử chức năng có thể bao gồm các bước sau:
- Phân tích yêu cầu: Kiểm tra và hiểu rõ các yêu cầu chức năng đã được xác định

trong tài liệu yêu cầu hoặc thiết kế.
- Xác định các kịch bản kiểm thử: Tạo các kịch bản kiểm thử dựa trên các yêu cầu

chức năng để đảm bảo kiểm tra toàn diện cho mọi khả năng của phần mềm.
- Chuẩn bị dữ liệu kiểm thử: Xác định dữ liệu kiểm thử cần thiết cho các kịch bản

kiểm thử.
- Thực hiện kiểm thử: Thực hiện các kịch bản kiểm thử trên phần mềm để xác

minh xem các chức năng hoạt động như mong đợi.
- Ghi nhận kết quả: Ghi lại kết quả của các kịch bản kiểm thử, bao gồm các lỗi và

sai sót phát hiện được.
- Xác minh kết quả: Xác minh và xử lý các lỗi phát hiện trong quá trình kiểm thử.
- Tạo báo cáo kiểm thử: Tạo báo cáo về kết quả kiểm thử và tình trạng chất lượng

của phần mềm.
1.2.2. Non - Functional testing

Kiểm thử phi chức năng (Non-functional Testing) là một loại kiểm thử phần mềm
tập trung vào đánh giá các khía cạnh khác ngồi chức năng của phần mềm. Trong kiểm
thử phi chức năng, không xét đến các chức năng cụ thể của phần mềm, mà tập trung vào

các yếu tố không phải là chức năng của phần mềm như hiệu năng, bảo mật, giao diện
người dùng, khả năng chịu tải, độ tin cậy, hiệu quả và tính khả dụng.

Mục tiêu của kiểm thử phi chức năng là đảm bảo rằng các yếu tố không phải chức
năng đáp ứng các yêu cầu và tiêu chuẩn đã được xác định trước, và phần mềm hoạt động
một cách ổn định và đáng tin cậy dưới nhiều điều kiện khác nhau.

Dưới đây là một số loại kiểm thử phi chức năng:

20

- Kiểm thử hiệu năng (Performance Testing): Đánh giá hiệu năng của phần
mềm trong điều kiện tải công việc cao, đảm bảo rằng nó đáp ứng được các
yêu cầu về thời gian phản hồi, tốc độ và tải trọng.

- Kiểm thử bảo mật (Security Testing): Xác định và đánh giá các lỗ hổng bảo
mật trong phần mềm để đảm bảo tính bảo mật và bảo vệ thơng tin của
người dùng.

- Kiểm thử giao diện (Usability Testing): Đánh giá tính thẩm mỹ, sự tương
tác dễ sử dụng và trải nghiệm người dùng của giao diện người dùng.

- Kiểm thử khả dụng (Availability Testing): Đánh giá tính khả dụng của phần
mềm, đảm bảo rằng nó có sẵn và có thể truy cập bất kỳ lúc nào khi người
dùng cần.

- Kiểm thử độ tin cậy (Reliability Testing): Đánh giá độ tin cậy của phần
mềm, xem xét khả năng hoạt động ổn định và duy trì chức năng trong thời
gian dài.


- Kiểm thử khả năng chịu tải (Load Testing): Đánh giá khả năng chịu tải của
phần mềm trong điều kiện tải công việc cao và xác định giới hạn tải mà
phần mềm có thể xử lý.

1.2.3. Structural testing

Kiểm thử cấu trúc (Structural Testing) là một loại kiểm thử phần mềm tập trung
vào việc kiểm tra và đánh giá cấu trúc bên trong của phần mềm. Nó cịn được gọi là kiểm
thử hộp trắng (White-box testing) vì trong quá trình kiểm thử này, kiểm thử viên có
quyền truy cập vào mã nguồn và kiến trúc bên trong của phần mềm để thực hiện các kỹ
thuật kiểm thử.

Mục tiêu của kiểm thử cấu trúc là đảm bảo rằng mã nguồn của phần mềm hoạt
động đúng, bao gồm cả các nhánh điều kiện, vịng lặp và các phương thức khác. Q
trình kiểm thử cấu trúc giúp phát hiện các lỗi cú pháp, lỗi logic, vấn đề hiệu năng, và các
vấn đề khác liên quan đến cấu trúc của mã nguồn.

Dưới đây là một số kỹ thuật kiểm thử cấu trúc phổ biến:

21


×