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

KIỂM THỬ PHẦN MỀM, Nghiên cứu tìm hiểu về kĩ thuật Cloud Testing và Cookies Testing

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 (882.17 KB, 44 trang )

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

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

BÁO CÁO BÀI TẬP LỚN HỌC PHẦN:

KIỂM THỬ PHẦN MỀM
Đề tài :

Nghiên cứu tìm hiểu về kĩ thuật Cloud Testing
và Cookies Testing
CBHD
Nhóm
Mã lớp
Sinh viên

Ths. Hoàng Quang Huy
5
20212IT6013002


Hà Nội, Năm 2022
MỤC LỤC
Phần 1 : Phần mở đầu

5

1.

Tên đề tài



5

2.

Lý do chọn đề tài

5

3.

Mục tiêu đề tài

5

4.

Bố cục đề tài

5

Phần 2 : Nội dung
Chương 1 : Tổng quan về kiểm thử phần mềm
1.

Một số khái niệm

7
7
7


1.1.

Kiểm thử phần mềm (Software testing)

7

1.2.

Kiểm thử hộp đen (Black box testing)

8

1.3.

Kiểm thử hộp trắng (White box testing)

8

1.4.

Kiểm thử đơn vị (Unit test)

9

1.5.

Kiểm thử tích hợp (Integration test)

9


1.6.

Kiểm thử hệ thống (System test)

9

1.7.

Kiểm thử chấp nhận (Acceptance test)

9

1.8.

Kiểm thử chức năng (Functional testing)

9

1.9.

Kiểm thử phi chức năng (NonFunctional testing)

10

1.10.

Test cấu hình (Shakeout testing)

10


1.11.

Smoke testing

10
2


1.12.

Adhoc testing

10

1.13.

Monkey testing

10

1.14.

Kiểm thử hiệu suất (Performance testing)

11

1.15.

Kiểm thử hồi quy (Regression testing)


11

1.16.

Test case

11

1.17.

IPA testing

11

1.18.

Backward compatibility testing

12

1.19.

Binary Portability testing

12

1.20.

Test plan


12

2.

Quy trình kiểm thử

12

2.1.

Phân tích yêu cầu

13

2.2.

Lập kế hoạch kiểm thử

13

2.3.

Thiết kế kịch bản cho quy trình kiểm thử

13

2.4.

Thiết lập mơi trường kiểm thử


14

2.5.

Thực hiện kiểm thử

14

2.6.

Đóng chu trình kiểm thử

14

3.

Các kỹ thuật kiêm thử

15

3.1.

Kiểm thử thủ công

15

3.2.

Kiểm thử tự động


16

3.3.

So sánh kiểm thử tự động và kiểm thử thủ công

17

Chương 2 : Tìm hiểu kĩ thuật Cloud Testing và Cookie Testing

17

1.

Cloud Testing

17

1.1.

Khái niệm

17

1.2.

Phân loại điện tốn đám mây

18


1.3.

Tìm hiểu về kiểm thử SaaS

18

1.4.

Tại sao nên sử dụng công cụ Cloud Testing

20

1.5.

Vòng đời phát triển của Cloud Testing

20

1.6.

Các lại kiểm thử được thử nghiệm trong Cloud Testing

21

1.7.

Một số công cụ Cloud Testing

23

3


1.8.

Cách thực hiện Cloud Testing

23

1.9.

Các trường hợp thử nghiệm mẫu cho Cloud Testing

24

1.10.

So sánh kiểm thử đám mây với kiểm thử thông thường

25

1.11.

Thách thức trong Cloud Testing

26

2.

Cookies Testing


29

2.5.

Các trường hợp cần kiểm tra Cookie

30

2.6.

Các plugin để kiểm tra Cookie

31

2.7.

Cách kiểm tra Cookie trên Website

32

2.8.

Sự khác nhau của Cookie và Session

33

2.9.

Những hạn chế của Cookie


34

Chương 3: Sử dụng công cụ vào thực tiễn
1.

Tìm hiểu phần mềm Postman trong kiểm thử Cookie

35
35

1.1.

Lịch sử phát triển công cụ

35

1.2.

Đặc điểm

35

1.3.

Ưu và nhược điểm

35

2.1.


Định nghĩa

27

2.2.

Nội dung của kiểm thử Cookie

28

2.3.

Phân loại Cookie

28

2.4.

Nơi lưu trữ Cookie
Quá trình cài đặt

1.5.

Các sử dụng postman

27

2.


Mợt số kịch bản biểm thử

1.4.
36
37
39

2.1.

Điều kiện thực hiện

39

2.2.

Các bước tiến hành thực hiện kiểm thử

39

4


Phần 1 : Phần mở đầu
1. Tên đề tài
Nghiên cứu tìm hiểu về kĩ thuật Cloud Testing và Cookie Testing

2. Lý do chọn đề tài
Ngày nay công nghệ thông tin đang ngày càng phát triển nhanh chóng, 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 theo quy mô
rộng và cả về chất lượng phần mềm theo chiều sâu. Nhưng cũng từ đó đã nảy sinh

ra 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 đến xã hội, kinh tế,... Những lỗi này có thể do tự bản thân phần mềm
bị hỏng do 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ằm đánh cắp thơng tin cá nhân như
mã số tài khoản ngân hàng, số điện thoại, danh bạ, tin nhắn,...Những vấn đề nan
giải và cấp thiết này càng có xu hướng mở rộng trong các năm gần đây, điển hình
như sự cố máy tính Y2K năm 2000 làm tê liệt nhiều hệ thống máy tính lớn hay như
càng có nhiều loại virus phá hoại mới xuất hiện, tấn công vào các lỗ hổng bảo mật
phần mềm làm tê liệt nhiều hệ thống phần mềm và phần cứng. Nhận thấy “ Kiểm
thử phần mềm trong sản xuất phần mềm” là 1 quy trình quan trọng . Hơn thế, với
cơng nghệ ngày càng phát triển thì Cloud Testing và Cookie Testing đang đang
mang lại nhiều giá trị và lợi ích cho nhà phát triển cũng như những bộ phận kiểm
thử. Chính vì lí do đó nhóm 5 chúng em quyết định chọn đề tài này thực hiện tìm
hiểu và thực hành.

5


3. Mục tiêu đề tài





Tìm hiểu khái niệm của 2 quy trình kiểm thử Cloud và Cookie
Tìm hiểu được những lợi ích cũng như thách thức của 2 kĩ thuật trên
Tìm hiểu các cơng cụ thường được sử dụng của 2 kĩ thuật trên
Ứng dụng được các công cụ vào sản phẩm thực tế

4. Bố cục đề tài

Nội dung chính đề tài gồm 3 chương
Chương 1: Tổng quan về kiểm thử phần mềm
Chương này giới thiệu sơ lược các khái niệm trong kiểm thử, giới thiệu quy
trình cũng như các kĩ thuật kiểm thử
Chương 2: Tìm hiểu kĩ thuật Cloud Testing và Cookie Testing
Chương này đi sâu vào tìm hiểu 2 kĩ thuật chính đó là Cloud Testing và
Cookie Testing
Chương 3: Sử dụng công cụ vào thực tiễn
Chương này sẽ sử dụng công cụ kiểm thử Cloud Testing và Cookie Testing
để kiểm thử sản phẩm thực tế

6


Phần 2 : Nội dung
Chương 1 : Tổng quan về kiểm thử phần mềm
1. Một số khái niệm
1.1.Kiểm thử phần mềm (Software testing)
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm
ra lỗi. Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng đầy đủ, chính
xác và đúng yêu cầu khách hàng, yêu cầu sản phẩm đã đặt ra. Kiểm thử phần mềm
cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc
đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Kiểm thử phần mềm tạo điều
kiện cho tận dụng tối đa tư duy đánh giá và sáng tạo để có thể phát hiện ra những
điểm mà người khác chưa nhìn thấy.
Trong kỹ thuật, kiểm thử không chỉ giới hạn ở việc thực hiện một chương
trình hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm mà còn là một q trình
phê ch̉n, xác minh một chương trình máy tính / ứng dụng / sản phẩm nhằm:
● Đáp ứng mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm.
● Thực hiện công việc đúng như kỳ vọng.

● Có thể triển khai được với những đặc tính tương tự.
● Đáp ứng được mọi nhu cầu của các bên liên quan.
Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất
cứ lúc nào trong quá trình phát triển phần mềm. Theo truyền thống, các nỗ lực
kiểm thử được tiến hành sau khi các yêu cầu được xác định và việc lập trình được
hồn tất, Nhưng trong Agile (là tập hợp các phương pháp phát triển phần mềm linh
hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiến hành
7


liên tục trong suốt quá trình xây dựng phần mềm. Như vậy, mỗi một phương pháp
kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định.
Kiểm thử phần mềm đóng vai trò quan trọng trong việc đánh giá và thu được
chất lượng cao của sản phẩm phần mềm trong q trình phát triển. Thơng qua chu
trình “kiểm thử – tìm lỗi – sửa lỗi”, chất lượng của sản phẩm phần mềm sẽ được
cải tiến. Mặt khác, thông qua việc tiến hành kiểm thử mức hệ thống trước khi cho
lưu hành sản phẩm, ta biết được sản phẩm tốt ở mức nào.
1.2.Kiểm thử hộp đen (Black box testing)

Hình 1. 1 Kiểm thử hộp đen
Kiểm thử hộp đen là phương pháp kiểm thử mà tester chỉ xem xét đến đầu vào
và đầu ra của chương trình mà khơng quan tâm code bên trong được viết ra sao.
Tester thực hiện việc kiểm thử dựa hoàn toàn vào đặc tả u cầu. Mục đích của
kiểm thử hộp đen là tìm ra các lỗi ở giao diện, chức năng của phần mềm. Các
trường hợp kiểm thử sẽ được xây dựng xung quanh đó.
1.3.Kiểm thử hợp trắng (White box testing)

Hình 1. 2 Kiểm thử hộp trắng
8



Kiểm thử hộp trắng là một phương pháp kiểm thử mà cấu trúc thuật tốn của
chương trình được đưa vào xem xét. Các trường hợp kiểm thử được thiết kế dựa
vào cấu trúc mã hoặc cách làm việc của chương trình. Tester truy cập vào mã
nguồn của chương trình để kiểm tra nó.
1.4.Kiểm thử đơn vị (Unit test)
Kiểm thử đơn vị là hoạt động kiểm thử nhỏ nhất. Kiểm thử này được thực
hiện trên các hàm hoặc các thành phần riêng lẻ. Để thực hiện được nó thì người
kiểm thử phải hiểu biết về code, về chương trình, các hàm, … Mục đích của việc
thực hiện kiểm thử đơn vị là cơ lập từng thành phần của chương trình và chứng
minh các bộ phận riêng lẻ chính xác về yêu cầu chức năng.
1.5.Kiểm thử tích hợp (Integration test)
Kiểm thử tích hợp được thực hiện bằng cách gom các module lại với nhau để
kiểm tra sự giao tiếp giữa các module cũng như bản thân từng thành phần module.
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 Unit.
● Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ và cuối cùng là một hệ
thống hoàn chỉnh để chuẩn bị cho bước kiểm thử hệ thống.
1.6.Kiểm thử hệ thống (System test)
Kiểm thử tập chung nhiều hơn vào chức năng hệ thống. Nó kiểm tra chức năng,
giao diện, các hành vi của hệ thống một cách hoàn chỉnh, đáp ứng với yêu cầu.
1.7.Kiểm thử chấp nhận (Acceptance test)
Kiểm thử chấp nhận hướng tới sự mong đợi của người dùng với sản phẩm. Có
hai loại kiểm thử chấp nhận: Kiểm thử alpha và kiểm thử Beta.
● Kiểm thử Alpha: là loại kiểm thử nội bộ, nghĩa là phần mềm được một đội
kiểm thử độc lập hoặc do khách hàng thực hiện tại nơi sản xuất phần mềm.
● Kiểm thử Beta: là loại kiểm thử mà khách hàng thực hiện kiểm thử ở chính
mơi trường của họ. Loại kiểm thử này được thực hiện sau kiểm thử Alpha.

9



1.8.Kiểm thử chức năng (Functional testing)
Kiểm thử chức năng là một loại kiểm thử hộp đen và các trường hợp kiểm thử
được dựa trên đặc tả của ứng dụng phần mềm/thành phần đang test. Các chức năng
được test bằng cách nhập vào các giá trị nhập và kiểm tra kết quả đầu ra và ít quan
tâm đến cấu trúc bên trong của ứng dụng.
1.9.Kiểm thử phi chức năng (NonFunctional testing)
Kiểm thử phi chức năng tập trung vào các khía cạnh phi chức năng của ứng
dụng, gồm: kiểm thử chịu tải, kiểm thử bảo mật, kiểm tra tính tương thích trên
từng mơi trường, …
1.10.

Test cấu hình (Shakeout testing)

Kiểm thử cấu hình là kiểu kiểm thử về khả năng của hệ thống mạng, kết nối dữ
liệu và sự tương tác của các module. Thông thường kiểu kiểm thử này được thực
hiện do nhóm quản lý cấu hình ch̉n bị thiết lập các môi trường kiểm thử thực sự.
Họ sẽ kiểm tra xem các thành phần chính của phần mềm có hoạt động bất thường
hay không. Kiểu kiểm thử này được thực hiện trước khi tiến hành thực hiện trong
môi trường test.
1.11.

Smoke testing

Smoke testing là một quá trình để kiểm tra xem liệu bản build có ổn định hay
khơng, để xem bản build có đủ ổn định để thực hiện test chi tiết hay không (trong
trường hợp bản build không ổn định, lỗi ln chức năng chính hoặc build lỗi thì sẽ
được trả lại cho lập trình viên u cầu sửa ln). Nó là một bài test hồi quy nhỏ
đơn giản và nhanh của các chức năng chính, cho thấy sản phẩm đã sẵn sàng cho

việc test hay chưa.
1.12.

Adhoc testing

Adhoc testing là phương pháp kiểm thử dạng hộp đen mà không theo cách
thông thường. Với quy trình test thơng thường là phải có tài liệu yêu cầu, kế hoạch
test (test plan), kịch bản kiểm thử. Kiểu test này không theo bất cứ loại kỹ thuật
test nào để tạo test case.

10


1.13.

Monkey testing

Monkey testing là một phương pháp kiểm thử với đầu vào ngẫu nhiên, không
theo test case hay một chiến lược test nào. Trong monkey testing, tester (đôi khi cả
developer) sẽ áp dụng các kịch bản kiểm thử ngẫu nhiên trên hệ thống để tìm ra lỗi
mà khơng cần xác định trước. Trong 1 số trường hợp, Monkey testing chỉ dành cho
Unit Testing hoặc GUI Testing (Kiểm thử giao diện người dùng).
1.14.

Kiểm thử hiệu suất (Performance testing)

Ở kiểm thử hiệu suất, ứng dụng được test dựa vào sức nặng như: sự phức tạp
của giá trị, độ dài của đầu vào, độ dài của các câu truy vấn… Loại test này kiểm tra
bớt phần tải (Load) của ứng dụng có thể được chắc chắn hơn.
1.15.


Kiểm thử hồi quy (Regression testing)

Test hồi quy là test lại một chức năng đã được làm xong, đã được test xong rồi,
đã hết lỗi nhưng do có sự sửa đổi một chức năng khác mà lại có ảnh hưởng đến nó,
thì phải test một chức năng được gọi là test hồi quy.
1.16.

Test case

Test case là mô tả dữ liệu đầu vào, hành động và 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 test case cơ bản cần có các
trường sau: Testcase ID, mục tiêu test, các bước thực hiện test, kết quả trả về.
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 test case có hiệu quả để bao phủ hết các trường hợp cần test thì
test case 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ả khơng được bỏ sót, sử dụng các kỹ thuật thiết kế test case (Test hộp
đen) để viết được testcase có độ bao phủ tối đa.
1.17.

IPA testing

● API (Application Programming Interface): cho phép kết nối, và trao đổi dữ
liệu giữa hai hệ thống phần mềm riêng biệt. Một hệ thống phần mềm có thể
nhúng các API bao gồm các hàm/thủ tục con (functions/sub-routines) mà có
thể chạy bởi một hệ thống phần mềm khác.
11



● Kiểm thử API khác hoàn toàn với kiểm thử GUI và các thành phần chủ yếu
khác trong tầng business logic của kiến trúc phần mềm. Loại kiểm thử này
không tập trung vào phần giao diện và thao tác giao diện của một ứng dụng.
Thay vì sử dụng các đầu vào từ bàn phím và đầu ra tiêu chuẩn, trong kiểm
thử API, ta có thể sử dụng một phần mềm để gửi các yêu cầu đến API, nhận
đầu ra và ghi lại phản hồi của hệ thống.
1.18.

Backward compatibility testing

Backward compatibility testing (Kiểm tra sự tương thích ngược): là việc kiểm
tra xem các sản phẩm của ứng dụng cũ có tiếp tục làm việc tốt trên phiên bản mới
của ứng dụng đó hay khơng.
1.19.

Binary Portability testing

Binary Portability testing (Kỹ thuật test tính di động) của phần mềm bằng cách
chạy phần mềm trên các nền tảng và mơi trường khác nhau. Nó được sử dụng cho
cấu tạo của Application Binary Interface. Binary Portability testing nên tiến hành
trên các loại khác nhau của platform, như Windows (x86, X86-64), Linux, Mac
OS, Java, Solaris, và Android. Nếu ứng dụng có tính di động cao thì người dùng có
thể chạy ứng dụng trên bất kỳ nền tảng. Do đó, để test Binary portability nghĩa là
khi xây dựng một phần mềm thì cần test việc nó thực thi được ứng dụng đó trên
nhiều hệ điều hành khác nhau, nếu nó là website thì cần chạy được trên nhiều trình
duyệt khác nhau để kiểm tra tính di động (Được thực hiện bởi nhóm test).
1.20.

Test plan


Test plan là tài liệu tổng quan về việc kiểm thử một dự án: phạm vi kiểm thử,
hướng tiếp cận, quy trình kiểm thử, tài nguyên và nhân lực test cần có, các chức
năng/ module cần được test, các công cụ và môi trường cần có. Dựa vào kế hoạch
chung của dự án để lên kế hoạch cho bên kiểm thử. Trong trường hợp làm thực tế
thấy có khả năng khơng đúng như kế hoạch đã lên thì phải báo cáo lại cho leader
hoặc quản trị dự án sớm.

2. Quy trình kiểm thử
Vòng đời kiểm thử phần mềm là quá trình đảm bảo chất lượng liên tục và nhất
quán, nó là dòng chảy của một q trình kiểm thử. Thơng thường, mơ hình vòng
12


đời trong kiểm thử phần mềm liên quan đến tập hợp 6 bước cần được hồn thành
cho một tính năng nhất định hoặc sản phẩm nói chung để được coi là đã kiểm tra.
Đơi khi, giai đoạn thứ 6 có thể bị bỏ qua. Các giai đoạn này bao gồm:
1. Phân tích yêu cầu
2. Lập kế hoạch kiểm thử
3. Thiết kế kịch bản cho quy trình kiểm thử
4. Thiết lập mơi trường kiểm thử
5. Thực hiện kiểm thử
6. Đóng chu trình kiểm thử
Mỗi giai đoạn này đều có tiêu chí đầu vào và đầu ra. Tiêu chí đầu vào xác
định khi nào giai đoạn có thể được bắt đầu và tiêu chí đầu ra xác định khi nào giai
đoạn có thể được coi là hồn thành.
2.1.Phân tích u cầu
Phân tích yêu cầu là giai đoạn đầu tiên của vòng đời kiểm thử phần mềm.
Mục tiêu của nó là phân tích các yêu cầu thông qua những tài liệu bao gồm: tài liệu
yêu cầu của khách hàng, prototype của khách hàng, tài liệu đặc tả yêu cầu của phần
mềm, tài liệu thiết kế hệ thống, …

QA team có nhiệm vụ phân tích và xác định u cầu của khách hàng, trong
đó có yêu cầu về kiểm thử chức năng/phi chức năng của phần mềm. Trong q
trình phân tích, QA team có thể đặt ra câu hỏi để hiểu chính xác hơn về yêu cầu
của sản phẩm, đồng thời hỗ trợ đưa ra giải pháp thích hợp cho khách hàng.
2.2.Lập kế hoạch kiểm thử
Dựa vào tài liệu nhận được trong giai đoạn đầu, Test Manager hoặc Test Lead
sẽ lên kế hoạch kiểm thử cho QA team để xác định một số yếu tố:
● Phạm vi dự án: Thời gian thực hiện dự án là bao lâu? Trong từng khoảng
thời gian sẽ có những cơng việc gì?
● Phương pháp tiếp cận: Dựa vào yêu cầu chất lượng của khách hàng, thời
gian test, kỹ thuật phát triển ứng dụng, lĩnh vực của sản phẩm, … Test
13


Manager sẽ đưa ra phương pháp tiếp cận sao cho đảm bảo tiến độ và chất
lượng của sản phẩm. Sau khi kết thúc giai đoạn này, QA team cần nhận
được test plan, test schedule và test estimation.
2.3.Thiết kế kịch bản cho quy trình kiểm thử
Trong giai đoạn này, Tester sẽ đọc hiểu tất cả các tài liệu. Từ đó xác định
những việc cần làm, chức năng nào cần test hoặc khơng. Sau đó, dựa vào kế hoạch
và kỹ thuật thiết kế kịch bản kiểm thử, Tester sẽ bắt đầu viết test case.
Yêu cầu của test case: Thể hiện tất cả các trường hợp kiểm thử có thể phát
sinh để đáp ứng yêu cầu sản phẩm. Ngoài test case, Tester cũng cần chuẩn bị các
dữ liệu cần thiết khác như test data, test script, test design, test automation script.
2.4.Thiết lập môi trường kiểm thử
Đây là một trong những giai đoạn đóng vai trò rất quan trọng trong vòng đời
phát triển phần mềm. Dựa trên yêu cầu khách hàng và đặc thù sản phẩm, môi
trường kiểm thử sẽ được xác định. Tester cần chuẩn bị smoke test case để kiểm tra
môi trường cài đặt đã đáp ứng yêu cầu và sẵn sàng cho giai đoạn kiểm thử tiếp
theo hay chưa.

2.5.Thực hiện kiểm thử
Theo test case đã thiết kế và môi trường kiểm thử đã hoàn tất cài đặt, Tester
sẽ báo cáo bug lên tool quản lý lỗi và theo dõi đến khi fix bug thành cơng.
Tiếp đó, Tester thực hiện kiểm thử lại để verify fix bug và kiểm thử hồi quy
trong trường hợp có sự thay đổi. Sau khi hồn tất giai đoạn này, các chuyên viên
kiểm thử cần có được kết quả kiểm thử và danh sách các lỗi tìm được.
2.6.Đóng chu trình kiểm thử
Để đóng chu trình kiểm thử phần mềm, QA team cần có được những tài liệu đã
được tổng hợp và hoàn thiện từ những giai đoạn trước: tài liệu phân tích đặc tả yêu
cầu, test plan, defect reports, test results, … Tiếp đó, QA team sẽ tổng kết, báo cáo
về q trình kiểm thử, có bao nhiêu bug đã được fix, bug có nghiêm trọng hay
khơng, chức năng nào còn lỗi, chức năng nào đã hoàn thành.
14


Như vậy, có thể nói kiểm thử phần mềm là một vòng tròn không bao giờ kết
thúc (chỉ kết thúc khi ứng dụng được phân phối). Tất cả 6 giai đoạn trên nên được
lặp đi lặp lại nhiều lần để đảm bảo giải pháp phần mềm là đáng tin cậy, hiệu quả và
khơng có lỗi.
Khi hồn thành chu kỳ kiểm thử đơn vị phải tiến hành kiểm thử tích hợp. Khi
chu kỳ này hoàn thành, lại bắt đầu một chu kỳ mới để kiểm thử hệ thống. Mỗi khi
một tính năng mới được thêm vào, phải bắt đầu lại với từng giai đoạn.

3. Các kỹ thuật kiêm thử
3.1.Kiểm thử thủ công
Khái niệm
Kiểm thử thủ công: Tester làm mọi công việc bằng tay, từ viết test case đến
thực hiện test, mọi thao tác như: nhập điều kiện đầu vào, thực hiện sự kiện một số
sự kiện khác: kích nút và quan sát kết quả thực tế, sau đó so sánh kết quả mong
muốn với kết quả thực tế. Hiện nay, phần lớn các công ty phần mềm, các tổ chức,

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.
Mục tiêu của kiểm thử thủ công
● Đảm bảo ứng dụng hoạt động phù hợp với yêu cầu chức năng được
chỉ định.
● Đảm bảo rằng các lỗi tìm thấy được sửa chữa bởi các developer và
được kiểm thử lại bởi tester.
● Kiểm tra chất lượng của hệ thống và cung cấp sản phẩm khơng có
lỗi cho khách hàng.
Ưu, nhược điểm của kiểm thử thủ công
⮚ Ưu điểm:
● Cho phép tester thực hiện kiểm thử khám phá.
● Nhận phản hồi trực quan nhanh và chính xác.
● Thích hợp kiểm tra cho sản phẩm lần đầu tiên.
● Thích hợp kiểm thử các test case chỉ thực hiện một số ít lần.
● Giảm chi phí ngắn hạn. Không cần phải chi ngân sách cho các
cơng cụ và quy trình tự động hóa.
15


⮚ Nhược điểm:
● Ít tin cậy hơn vì được thực thi bởi con người. Do đó, dễ mắc sai
lầm và khơng tìm thấy lỗi.
● Q trình kiểm thử khơng được ghi lại. Do đó, khơng thể sử dụng
lại.
● Tốn nhiều thời gian. Với mỗi lần release, người kiểm thử phải thực
hiện lại tập hợp các test case đã chạy dẫn đến sự mệt mỏi, lãng phí.
3.2.Kiểm thử tự đợng
Khái niệm
Kiểm thử tự động: là thực hiện kiểm thử phần mềm bằng một chương trình
đặc biệt với í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ử không phải lặp đi lặp lại các bước. Cơng cụ kiểm thử tự động có thể
lấy dữ liệu từ file bên ngoài nhập vào ứng dụng, sau đó so sánh kết quả thực tế với
kết quả mong đợi và xuất báo cáo kiểm thử.
Mục đích kiểm thử tự động
● Giảm công sức và thời gian thực hiện kiểm thử
● Tăng độ tin cậy
● Giảm sự nhàm chán cho tester
● Rèn kỹ năng lập trình cho tester
● Giảm chi phí cho tổng q trình kiểm thử
Quy trình kiểm thử tự đợng
● Phân tích u cầu, xác định mơi trường và cơng cụ
● Xác định tiêu chí đầu ra
● Lập kế hoạch và kiểm sốt
● Thiết lập mơi trường kiểm thử
● Triển khai, thiết kế kiểm thử
● Thực thi kiểm thử
● Phân tích và báo cáo
Ưu, nhược điểm của kiểm thử tự đợng
⮚ Ưu điểm:
● Thích hợp với trường hợp test nhiều lần cho một test case.
16


● Có thể thực hiện các thao tác lặp đi lặp lại, giúp tester không phải
làm những việc gây nhàm chán.
● Quá trình kiểm thử được ghi lại. Cho phép sử dụng lại, thực hiện
cùng loại hoạt động kiểm thử.
● Được thực hiện bằng cơng cụ. Do đó, có thể hoạt động liên tục
khơng biết mệt mỏi.
● Giảm chi phí đầu tư dài hạn.

⮚ Nhược điểm:
● Tốn kém hơn kiểm thử thủ cơng, chi phí đầu tư ban đầu lớn.
● Khơng có yếu tố con người. Khó hiểu sâu về các khía cạnh trực
quan của giao diện người dùng như màu sắc, phơng chữ, kích
thước, …
● Kiểm thử thủ cơng khơng thể thay thế vì người ta khơng thể tự
động hóa mọi thứ
3.3.So sánh kiểm thử tự đợng và kiểm thử thủ cơng
Tiêu chí
Chi phí
Tốc độ thực
hiện

Kiểm thử tự động
Giảm tiêu chí đầu tư dài hạn.
Kiểm thử tự động nhanh hơn
đáng kể so với kiểm thử thủ
cơng.
u
cầu Phải có khả năng lập trình.
người kiểm
thử
Độ tin cậy
Là phương pháp đáng tin cậy.
Vì được thực hiện bởi các
cơng cụ nên chính xác và
không gây nhàm chán.
Phụ
thuộc Giúp người kiểm thử không
người kiểm phải làm những việc gây

thử
nhàm chán, dễ nhầm lẫn.
Báo
cáo Tất cả các bên liên quan có
kiểm thử
thể đăng nhập vào hệ thống
và xem được kết quả kiểm
thử.

Kiểm thử thủ công
Giảm chi phí ngắn hạn.
Nhanh, chậm tùy thuộc vào người
kiểm thử.
Khơng u cầu khả năng lập
trình.
Kiểm thử thủ cơng có thể gây
nhàm chán và dễ bị lỗi.

Phụ thuộc vào cảm xúc của người
kiểm thử.
Kết quả thường được ghi lại trong
Excel hoặc Word.

17


Chương 2 : Tìm hiểu kĩ thuật Cloud Testing và
Cookie Testing
1. Cloud Testing
1.1.

Khái niệm
Cloud Testing là một loại kiểm thử phần mềm sử dụng các dịch vụ điện toán
đám mây để kiểm tra ứng dụng phần mềm. Mục đích của kiểm thử đám mây là để
kiểm tra phần mềm cho các yêu cầu chức năng cũng như phi chức năng. Nó sử
dụng điện tốn đám mây đảm bảo tính khả dụng nhanh hơn với khả năng mở rộng
và linh hoạt để tiết kiệm thời gian và chi phí cho thử nghiệm phần mềm.
Điện toán đám mây là một nền tảng dựa trên internet hiển thị các dịch vụ điện
toán khác nhau như phần cứng, phần mềm và các dịch vụ liên quan đến máy tính
khác từ xa.
Chủ yếu có ba mơ hình điện tốn đám mây :
● SaaS (Software as a service)– Phần mềm như một dịch vụ
● PaaS (Platform as a service)– Nền tảng như một dịch vụ
● IaaS (Infrastructure as a service) – Cơ sở hạ tầng như một dịch vụ

1.2.

Phân loại điện toán đám mây

Toàn bộ thử nghiệm đám mây được chia thành bốn loại chính :
● Thử nghiệm toàn bộ đám mây: Đám mây được xem như một thực thể
toàn bộ và dựa trên thử nghiệm tính năng của nó được thực hiện. Các nhà
cung cấp đám mây và SaaS, cũng như người dùng cuối, quan tâm đến
việc thực hiện loại thử nghiệm này.
● Thử nghiệm trong mợt đám mây: Bằng cách kiểm tra từng tính năng
nội bộ của nó, thử nghiệm được thực hiện. Chỉ có các nhà cung cấp đám
mây mới có thể thực hiện loại thử nghiệm này
● Thử nghiệm trên đám mây: Thử nghiệm được thực hiện trên các loại
đám mây riêng, công cộng và lai giống như đám mây khác nhau
● Thử nghiệm SaaS trên đám mây : Thử nghiệm chức năng và phi chức
năng được thực hiện trên cơ sở yêu cầu ứng dụng


1.3.

Tìm hiểu về kiểm thử SaaS
18


SaaS Testing là một quá trình kiểm thử phần mềm, trong đó ứng dụng phần
mềm được xây dựng trong phần mềm dưới dạng mơ hình Dịch vụ được kiểm tra
cho các yêu cầu chức năng cũng như phi chức năng. Mục tiêu của thử nghiệm SaaS
là đảm bảo chất lượng bằng cách kiểm tra bảo mật dữ liệu, tính tồn vẹn, hiệu suất,
khả năng tương thích và khả năng mở rộng của ứng dụng phần mềm.

Thử nghiệm đám mây tập trung vào các thành phần cốt lõi như:
● Ứng dụng: Nó bao gồm kiểm tra các chức năng, quy trình kinh doanh đầu
cuối, bảo mật dữ liệu, khả năng tương thích của trình duyệt, v.v.
● Mạng : Nó bao gồm kiểm tra các băng thông mạng, giao thức khác nhau và
truyền dữ liệu thành công qua các mạng.
● Cơ sở hạ tầng : Nó bao gồm các chính sách kiểm tra khơi phục thảm họa,
sao lưu, kết nối an tồn và lưu trữ. Cơ sở hạ tầng cần được xác nhận để tuân
thủ quy định
Các loại Thử nghiệm khác trong Đám mây bao gồm:
● Hiệu suất
● Tính khả dụng
● Tuân thủ
19


● Bảo vệ
● Khả năng mở rộng

● Kiểm tra nâng cấp trực tiếp

1.4.

Tại sao nên sử dụng công cụ Cloud Testing

● Tính khả dụng đợng của mơi trường kiểm thử:
Phương pháp kiểm thử bình thường trong bất kỳ tổ chức nào là đầu tư vào cơ sở hạ
tầng phần cứng / phần mềm cần thiết để kiểm thử. Hầu hết các bạn sẽ đồng ý rằng
môi trường cung cấp cho các nhóm kiểm thử rất hiếm khi phù hợp với môi trường
của khách hàng dựa trên các yêu cầu thay đổi nhanh chóng, do đó rất khó để các
cơng ty duy trì nó. Cloud là câu trả lời duy nhất cho vấn đề này, theo đó, người
dùng có thể dễ dàng tái tạo mơi trường khách hàng và tìm lỗi sớm trong q trình
phát triển.
● Chi phí thấp:
Một góc độ khác với điểm trước đó là khi các cơng ty đầu tư vào cơ sở hạ tầng,
trường hợp thông thường của nó là nhiều máy chủ của họ khơng được sử dụng mọi
lúc. Do đó, họ có thể phải chịu thêm chi phí cho việc gia hạn giấy phép. Việc
chuyển đổi sang đám mây cũng giúp ích trong trường hợp này, vì người dùng có
thể sử dụng các thiết bị bất cứ khi nào họ muốn, do đó tiết kiệm chi phí rất lớn cho
một tổ chức.
● Dễ dàng tùy chỉnh:
Với việc sử dụng đám mây, đây là một công cụ dễ dàng để các tổ chức mô phỏng
môi trường trung tâm của người dùng cuối bằng cách tùy chỉnh nó theo cách sử
dụng, tiết kiệm chi phí và thời gian. Các nhóm kiểm thử có thể dễ dàng thực hiện
các kịch bản kiểm thử tải và hiệu suất bằng việc thay đổi và kết hợp khác nhau
giữa các hệ điều hành, trình duyệt, cấu hình khác nhau,...
⮚ Khả năng mở rợng:
Đây là một trong những tính năng hấp dẫn nhất của đám mây nhờ đó tài ngun
máy tính có thể được tăng hoặc giảm bất cứ nơi nào cần thiết. Điều này được sử

dụng rộng rãi trong các tình huống mà yêu cầu nghiệp vụ thay đổi thường xuyên.

20



×