Báo cáo môn kiểm thử và đảm bảo chất lượng phần mềm

Mục lục

Mục lục.................................................................................................................1
Chương I: Tổng quan lý thuyết kiểm thử phần mềm......................................4

1.1. Kiểm thử phần mềm là gì?..........................................................................4
1.2. Lý do phải kiểm thử phần mềm..................................................................4
1.3. Vai trò của kiểm thử phần mềm?...............................................................5

1.3.1. Chất lượng...........................................................................................5
1.3.2. Tính năng.............................................................................................5
1.3.3. Độ tin cậy............................................................................................5
1.3.4. Chi phí.................................................................................................5
1.4. Mục tiêu của kiểm thử phần mềm?............................................................6
1.4.1. Phát hiện lỗi.........................................................................................6
1.4.2. Đánh giá chất lượng............................................................................6
1.4.3. Đảm bảo độ tin cậy..............................................................................6
1.4.4. Kiểm tra tính năng...............................................................................6
1.4.5. Xác thực yêu cầu.................................................................................6
1.5. Các phương pháp kiểm thử phần mềm?....................................................7
1.5.1. Kiểm thử đơn vị (Unit Testing)...........................................................7
1.5.2. Kiểm thử tích hợp (Intergration Testing)............................................7
1.5.3. Kiểm thử hệ thống (System Testing)..................................................7
1.5.4. Kiểm thử chấp nhận (Acceptance Testing).........................................7
1.6. Các chiến lược kiểm thử?............................................................................8
1.6.1. Kiểm thử từ trên xuống (Top – Down Testing)..................................8
1.6.2. Kiểm thử từ dưới lên (Bottom – Up Testing)......................................8
1.6.3. Kiểm thử hộp đen (Black Box Testing)..............................................8
1.6.4. Kiểm thử hộp trắng (White Box Testing)...........................................8
1.6.5. Kiểm thử hồi quy (Regression Testing)..............................................8

1.6.6. Kiểm thử tương quan (Concurrent Testing)........................................8
1.7. Nguyên tắc kiểm thử phần mềm?...............................................................9
1.7.1. Nguyên tắc 1: Test chỉ chứng tỏ được việc có lỗi...............................9

1

1.7.2. Nguyên tắc 2: Khơng thể Test tồn bộ................................................9
1.7.3. Nguyên tắc 3: Test từ giai đoạn đầu....................................................9
1.7.4. Nguyên tắc 4: Sự phân bổ không đồng đều của lỗi...........................10
1.7.5. Nguyên tắc 5: Nghịch lý thuốc trừ sâu..............................................10
1.7.6. Nguyên tắc 6: Test tùy thuộc vào điều kiện......................................10
1.7.7. Ngun tắc 7: Cạm bẫy khơng có BUG............................................10
1.8. Quy trình kiểm thử phần mềm – Test Process........................................11
1.8.1. Phân tích yêu cầu...............................................................................11
1.8.2. Lập kế hoạch kiểm thử......................................................................12
1.8.3. Thiết kế kịch bản kiểm thử................................................................13
1.8.4. Thiết lập môi trường kiểm thử..........................................................14
1.8.5. Thực hiện kiểm thử...........................................................................14
1.8.6. Đóng hoạt động kiểm thử..................................................................15
Chương II: Lập kế hoạch test..............................................................................17
Chương III. Giới thiệu về công cụ kiểm thử katalon..........................................20
3.1 Giới thiệu về kiểm thử tự động...................................................................20
3.2 Tổng quan về lịch sử ra đời của công cụ kiểm thử katalon.....................21
3.3 Tính năng chính...........................................................................................21
3.4 Ưu, nhược điểm...........................................................................................23
3.5 Hướng dẫn cài đặt, hướng dẫn sử dụng công cụ......................................23
3.6 So sánh với công cụ khác..........................................................................33
Chương IV. Giới thiệu về hệ thống quản lý siêu thị...........................................35
4.1 Mô tả chung về sản phẩm phần mềm........................................................35
4.2 Đặc tả chức năng.........................................................................................35

4.3 Demo giao diện.............................................................................................35
4.3.5. Quét mã QR..........................................................................................38
4.3.6. Cập nhật thông tin cá nhân.................................................................40
Chương V: Báo cáo kết quả buổi test tổng thể....................................................41
5.1 Kiểm thử hộp đen......................................................................................41
5.1.1 Chức năng thêm hàng hóa..........................................................41
5.1.2 Chức năng sửa hàng hóa.............................................................47
5.1.3 Chức năng xóa hàng hóa.............................................................52

2

5.1.4 Chức năng thêm nhà cung cấp...................................................56
5.1.5 Chức năng sửa nhà cung cấp......................................................63
5.1.6 Chức năng App Quét Mã QR của hàng hóa (App)..................68
5.1.7 Chức năng đổi mật khẩu (App)..................................................70
5.1.8 Chức năng cập nhật thông tin (App).........................................73
5.2. Kiểm thử hộp trắng...............................................................................81
5.2.1. Chức năng App Quét Mã QR của hàng hóa (APP)..................81
5.2.2. Chức năng đổi mật khẩu (APP).................................................84
5.2.3. Chức năng cập nhật thông tin (APP).........................................87
5.2.4. Tổng hợp Test Case Kiểm thử hộp trắng các chức năng của
App (QR, đổi mật khẩu, cập nhật thông tin)..........................................90

3

Chương I: Tổng quan lý thuyết kiểm thử phần mềm
1.1. Kiểm thử phần mềm là gì?

Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm và phát
hiện ra các lỗi của phần mềm, đảm bảo phần mềm chính xác, đúng và đầy đủ theo yêu

cầu của khách hàng, yêu cầu của sản phẩm đã đặt ra. Software testing 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 đánh giá và hiểu rõ các rủi
ro khi thực thi phần mềm.

Theo IEEE: Kiểm thử phần mềm là tiến trình vận hành hệ thống hoặc thành
phần dưới những điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh
giá về hệ thống hoặc thành phần đó.

Theo Myers: Kiểm thử là tiến trình thực thi chương trình với mục đích tìm thấy
lỗi.

Lỗi là kết quả của những sai sót. Sai sót là sự nhầm lẫn hay hiểu sai trong quá
trình phát triển phần mềm của người phát triển. Khi lỗi trở nên quá nhiều hoặc gây ảnh
hưởng lớn đến hệ thống khi đó sẽ gây ra hỏng hóc, khiến chương trình khơng thể hoạt
động hoặc hoạt động thiếu chính xác và tin cậy.
1.2. Lý do phải kiểm thử phần mềm

Kiểm thử phần mềm là hoạt động đảm bảo chất lượng phần mềm và mang tính
sống cịn trong các dự án sản xuất phần mềm. Vì vậy nó đã trở thành quy trình bắt
buộc trong các dự án phần mềm hiện nay.

Các lý do khiến một phần mềm cần phải kiểm thử:
- Tiết kiệm chi phí: Việc phát hiện lỗi sớm sẽ giảm chi phí để sửa so với các

giai đoạn sau cũng như giảm thiểu rủi ro sản phẩm bị hỏng hóc.
- Bảo mật: Một phần mềm gây rị rỉ thơng tin cá nhân người dùng sẽ không

được cấp phép hoạt động.
- Chất lượng của sản phẩm: Dựa theo độ hoàn thiện chức năng của yêu, chức

năng càng hoàn thiện, yêu cầu càng thực hiện trọn vẹn, chất lượng của sản
phẩm được đánh giá cao.
- Sự hài lòng của khách hàng: Chất lượng cao nhưng đặc biệt phải có được sự
hài lòng từ người dùng phần mềm.

4

- Tối ưu quá trình phát triển: Việc phát hiện lỗi sớm, lỗi sẽ được nhanh chóng
sửa chữa vì nó còn đơn giản. Lỗi được phát hiện muộn màng sẽ gây khó
khăn và rối rắm khi chỉnh sửa lại, làm chậm tiến trình phát triển phần mềm.

- Dễ dàng thêm mới tính năng: Với việc kiểm thử được trọn vẹn hoàn thành,
nhà phát triển có thể tự tin phát triển các tính năng mới mà khơng cần lo
nghĩ sẽ vo tình phá vỡ cấu trúc các tính năng cũ.

- Xác định hiệu suất của phần mềm: Hiệu suất của phần mềm cực kỳ quan
trọng trong việc có được lịng tin của khách hàng.

KẾT LUẬN: Để có thể thực hiện kiểm thử phần mềm, thì hiểu được lý do tại
sao kiểm thử phần mềm là cực kỳ quan trọng, nó sẽ đưa ra mục tiêu và điểm đích của
cơng việc kiểm thử đang diễn ra với một sản phẩm cụ thể nào đó.
1.3. Vai trị của kiểm thử phần mềm?

1.3.1. Chất lượng
Sản phẩm đến tay của khách hàng phải đảm bảo về yêu cầu, giao diện, cấu trúc,
tính năng và một số các yêu cầu đặc hữu khác đồng thời đảm bảo không còn tồn tại lỗi
trong hệ thống.
1.3.2. Tính năng
Sản phẩm phải đảm bảo đầy đủ về tính năng, tuân thủ những yêu cầu đã được
đặt ra. Trong q trình phát triển rất có thể sẽ phát sinh thêm nhiều nhiều yêu cầu từ

khách hàng. Kiểm thử cần bảo đảm các yêu cầu được hoàn thiện và hoàn thành đúng
với kết quả mà yêu cầu giao.
1.3.3. Độ tin cậy
Một sản phẩm chỉn chu, hoàn thiện tạo ra được những trải nghiệm người dùng
tốt nhất sẽ đạt được niềm tin của đối tác, khách hàng về sau.
1.3.4. Chi phí
Việc phát hiện lỗi sớm sẽ mang lại nhiều lợi ích trong q trình phát triển.
Giảm chi phí vận hành chính là một trong số đó. Phát hiện lỗi sớm có thể kịp
thời sửa chữa và dự đốn những lỗi có thể bắt gặp trong tương lai, mở rộng tầm nhìn
và thu hẹp phạm vi lỗi được xác định.
Xử lý lỗi ở giai đoạn đầu sẽ mất chi phí ít hơn là giai doạn sau bởi nó dễ dàng
xử lý và khơng có nhiều khó khăn.

5

Ở giai đoạn sau, khi chương trình được kiểm thử hoặc đã được phát hành thì chi
phí sửa chữa thường cao hơn do có nhiều khó khăn trong việc xử lý đồng thời cũng sẽ
ảnh hưởng đến độ tin cậy của phần mềm

KẾT LUẬN: Kiểm thử phần mềm là một phần không thể thiếu trong q trình
phát triển phần mềm, đóng vai trị quan trọng trong việc đảm bảo chất lượng và tính
ứng dụng của sản phẩm. Mục tiêu của kiểm thử là phát hiện lỗi, đánh giá chất lượng,
đảm bảo độ tin cậy, kiểm tra tính năng, và xác thực yêu cầu. Điều này đóng góp quan
trọng vào việc cung cấp sản phẩm phần mềm chất lượng cao cho khách hàng và bảo vệ
danh tiếng của tổ chức phát triển.
1.4. Mục tiêu của kiểm thử phần mềm?

1.4.1. Phát hiện lỗi
Mục tiêu chính của kiểm thử phần mềm là phát hiện và xác định các lỗi trong
phần mềm. Các lỗi này có thể là lỗi logic, lỗi giao diện người dùng, lỗi hiệu suất, hoặc

lỗi bảo mật. Để đảm bảo tính ổn định và đáng tin cậy của sản phẩm, các lỗi này cần
phải được báo cáo và sửa chữa.
1.4.2. Đánh giá chất lượng
Kiểm thử phần mềm giúp đánh giá chất lượng của sản phẩm. Điều này bao gồm
việc kiểm tra tính năng, hiệu suất, bảo mật, và tương thích với các môi trường khác
nhau. Đánh giá chất lượng giúp đảm bảo rằng sản phẩm đáp ứng tiêu chuẩn chất lượng
của công ty và mong đợi của khách hàng.
1.4.3. Đảm bảo độ tin cậy
Mục tiêu khác của kiểm thử phần mềm là đảm bảo độ tin cậy của phần mềm.
Điều này đảm bảo rằng phần mềm hoạt động đáng tin cậy và không gây ra sự cố
không mong muốn. Độ tin cậy là một yếu tố quan trọng đối với sự hài lòng của khách
hàng và danh tiếng của sản phẩm.
1.4.4. Kiểm tra tính năng
Kiểm thử phần mềm kiểm tra tính năng của sản phẩm để đảm bảo rằng nó hoạt
động theo cách được thiết kế và đáp ứng nhu cầu của người dùng. Điều này bao gồm
kiểm tra các tính năng cơ bản cũng như các tính năng phức tạp.
1.4.5. Xác thực yêu cầu

6

Mục tiêu cuối cùng của kiểm thử phần mềm là xác minh rằng phần mềm tuân
thủ các yêu cầu đã được đặt ra ban đầu. Điều này đảm bảo tính nhất quán và chính xác
của sản phẩm, và giúp đảm bảo rằng sản phẩm hoạt động theo cách mà khách hàng
mong đợi.

KẾT LUẬN: Kiểm thử phần mềm là một phần không thể thiếu trong q trình
phát triển phần mềm, đóng vai trị quan trọng trong việc đảm bảo chất lượng và tính
ứng dụng của sản phẩm. Mục tiêu của kiểm thử là phát hiện lỗi, đánh giá chất lượng,
đảm bảo độ tin cậy, kiểm tra tính năng, và xác thực yêu cầu. Điều này đóng góp quan
trọng vào việc cung cấp sản phẩm phần mềm chất lượng cao cho khách hàng và bảo vệ

danh tiếng của tổ chức phát triển.
1.5. Các phương pháp kiểm thử phần mềm?

1.5.1. Kiểm thử đơn vị (Unit Testing)
Đây là phần quan trọng nhất của quá trình kiểm thử phần mềm.
Trong kiểm thử đơn vị, các đơn vị nhỏ nhất của mã nguồn, như các hàm hoặc
phương thức được kiểm tra độc lập để đảm bảo tính đúng đắn của chúng. Thường thực
hiện bởi nhà phát triển.
Kiểm thử đơn vị giúp phát hiện và sửa lỗi ngay từ khi chúng xuất hiện.
1.5.2. Kiểm thử tích hợp (Intergration Testing)
Sau khi các đơn vị đã được kiểm thử đơn lẻ, kiểm thử tích hợp đảm bảo rằng
cho chúng hoạt động đúng cách khi được kết hợp lại với nhau.
Mục tiêu là phát hiện lỗi liên quan đến sự tương tác giữa các thành phần với nhau và
đảm bảo rằng tích hợp hoạt động mượt mà.
1.5.3. Kiểm thử hệ thống (System Testing)
Kiểm thử hệ thống là bước kiểm tra toàn bộ ứng dụng hoặc hệ thống sau khi đã
được tích hợp hồn chỉnh.
Giai đoạn này, người kiểm thử đảm bảo rằng hệ thống hoạt động như một thực
thể duy nhất và đáp ứng các yêu cầu chức năng và phi chức năng.
1.5.4. Kiểm thử chấp nhận (Acceptance Testing)
Loại kiểm thử này tập trung vào việc đảm bảo rằng phần mềm đáp ứng các yêu
cầu của khách hàng và có khả năng sử dụng trong mơi trường thực tế.

7

Kiểm thử chấp nhận có thể chia thành kiểm thử chấp nhận người dùng (UAT)
do khách hàng thực hiện kiểm thử và kiểm thử chấp nhận hệ thống (SAT) do người
kiểm thử độc lập thực hiện.
1.6. Các chiến lược kiểm thử?

1.6.1. Kiểm thử từ trên xuống (Top – Down Testing)
Trong chiến lược này, kiểm thử bắt đầu từ thành phần cấp cao hơn của hệ thống
và sau đó lan tỏa xuống các thành phần cấp thấp hơn. Điều này giúp kiểm tra sự tích
hợp của các thành phần và đảm bảo tích hợp đúng cách.
Top – Down Testing cũng giúp xác định các thành phần giả thiết (stub) cho các
thành phần chưa hoàn thành.
1.6.2. Kiểm thử từ dưới lên (Bottom – Up Testing)
Chiến lược này là ngược lại với Top – Down. Nó bắt đầu từ các thành phần cấp
thấp và sau đó tích hợp chúng lên các thành phần cao hơn.
Thường sử dụng khi các thành phần cấp cao hơn chưa hoàn thành
1.6.3. Kiểm thử hộp đen (Black Box Testing)
Trong kiểm thử hộp đen, người kiểm thử không cần quan tâm cấu trúc nội bộ
của phần mềm. Họ chỉ quan tâm đến cách phần mềm hoạt động từ bên ngoài và kiểm
tra các đầu vào – dầu ra để đảm bảo tính đúng đắn.
1.6.4. Kiểm thử hộp trắng (White Box Testing)
Kiểm thử hộp trắng liên quan đến việc kiểm tra cấu trúc nội bộ của mã nguồn.
Người kiểm thử sử dụng kiến thức về mã nguồn để tạo các bộ kiểm tra dựa trên
mã nguồn để đảm bảo tính logic và đúng đắn của phần mềm.
1.6.5. Kiểm thử hồi quy (Regression Testing)
Chiến lược này đảm bảo rằng các thành phần đã kiểm thử trước đó khơng bị
ảnh hưởng bởi các thay đổi sau này trong mã nguồn.
Regression Testing đảm bảo tính ổn định của phần mềm sau mỗi lần cập nhật
hoặc thay đổi.
1.6.6. Kiểm thử tương quan (Concurrent Testing)
Kiểm thử này kiểm tra khả năng của hệ thống hoạt động đúng cách trong mơi
trường có nhiều tương tác đồng thời (ví dụ có nhiều người dùng truy cập cùng lúc).

8

KẾT LUẬN: Thông qua sự kết hợp và lựa chọn phương pháp kiểm thử và

chiến lược kiểm thử phù hợp, nhà phát triển có thể đảm bảo chất lượng và tính ổn định
của sản phẩm phần mềm của họ. Quá trình kiểm thử phần mềm là một quá trình quan
trọng trong quy trình phát triển, và cải thiện liên tục là điều không thể thiếu để đáp ứng
yêu cầu của thị trường.
1.7. Nguyên tắc kiểm thử phần mềm?

1.7.1. Nguyên tắc 1: Test chỉ chứng tỏ được việc có 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 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.
1.7.2. Nguyên tắc 2: Khơng thể Test tồn bộ
Trừ khi sản phẩm được kiểm thử q đơn giản cũng như khơng có nhiều giá trị
đầu vào (chẳng hạn như “Hello World”) thì việc chứng minh sản phẩm khơng cịn bug
cho dù có kiểm thử nhiều đến đâu là không khả thi.
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ử tồ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ộ. Thay vì
kiểm thử tồn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể
tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn.
1.7.3. Nguyên tắc 3: Test từ giai đoạn đầu
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.
Ngoài ra ai làm phần mềm cũng biết được rằng việc phát hiện lỗi càng trể bao
nhiêu thì chi phí để sửa lỗi càng cao bấy nhiêu. Tương tự, việc thay đổi yêu cầu không

đúng ngay từ đầu thường tốn ít chi phí thay đổi tính năng trong hệ thống.

9

1.7.4. Nguyên tắc 4: Sự phân bổ không đồng đều của lỗi
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ả
1.7.5. Nguyên tắc 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 hoà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.
1.7.6. Nguyên tắc 6: Test tùy thuộc vào điều kiện
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 đó. Chiến lược cho
test web application phải khác với ứng dụng android mobile.
1.7.7. Nguyên tắc 7: Cạm bẫy khơng có BUG
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.

KẾT LUẬN: Kiểm thử không phải chỉ đơn thuần là một hoạt động riêng lẻ mà
là một loạt các hoạt động liên quan và bổ sung cho nhau và phức tạp. Tuy nhiên, việc
dựa theo 7 nguyên tắc trên sẽ giúp cho chúng ta có cái nhìn tổng qt hơn về kiểm thử

10

cũng như giúp chúng ta đánh giá được tính hiệu quả của hoạt động kiểm thử được thực
thi.
1.8. Quy trình kiểm thử phần mềm – Test Process

1.8.1. Phân tích yêu cầu
 Đầu vào

Đầu vào của giai đoạn phân tích yêu cầu bao gồm các tài liệu như: tài liệu đặc
tả yêu cầu, tài liệu thiết kế hệ thống, tài liệu khách hàng yêu cầu về các tiêu chí chấp
nhận của sản phẩm, bản prototype của khách hàng yêu cầu (nếu có) …

 Hoạt động
- Phân tích yêu cầu là giai đoạn đầu tiên trong quy trình kiểm thử phần mềm.
- QA team sẽ thực hiện đọc hiểu, nghiên cứu và phân tích cụ thể các yêu cầu

trong tài liệu đặc tả của dự án hoặc tài liệu khách hàng. Qua hoạt động này, QA
team sẽ nắm bắt được các yêu cầu mà dự án đưa ra bao gồm yêu cầu kiểm thử
chức năng/ phi chức năng nào.
- Ngồi ra, trong q trình phân tích, nghiên cứu tài liệu, nếu có câu hỏi phát sinh
hay đề xuất giải quyết, QA team sẽ đưa ra câu hỏi với các bên liên quan như
BA(Business Analysis), PM( Project Manager), team leader, khách hàng để
hiểu chính xác hơn về yêu cầu của sản phẩm. Những câu hỏi này sẽ được lưu
trữ vào file Q&A (Question and Answer). Các câu hỏi nên được đưa ra dưới

dạng Yes/No question hoặc các lựa chọn để tiết kiệm thời gian trả lời cũng như
hỗ trợ đưa ra những gợi ý hay để xây dựng sản phẩm ngay từ đầu. Như vậy,
đương nhiên là chúng ta không nên nêu ra những câu hỏi dạng là gì, như thế
nào, tại sao,.. Những câu hỏi như thế thường mất thời gian để giải thích và cũng
khó có thể giải thích một cách chi tiết nhất có thể. Hơn nữa, đối với khách hàng
khơng có sự hiểu biết về lĩnh vực phần mềm mà họ yêu cầu thì càng khơng thể
trả lời những câu hỏi mang tính chun mơn cao. Chính chúng ta sẽ là người hỗ
trợ và đưa ra giải pháp thích hợp cho khách hàng lựa chọn.

 Đầu ra
Đầu ra của giai đoạn phân tích yêu cầu bao gồm tài liệu chứa các câu hỏi và câu
trả lời liên quan đến nghiệp vụ của hệ thống, tài liệu báo cáo tính khả thi, phân tích rủi
ro của việc kiểm thử phần mềm.

11

1.8.2. Lập kế hoạch kiểm thử
 Đầu vào

Đầu vào của giai đoạn lập kế hoạch kiểm thử là các tài liệu đặc tả đã được cập
nhật thông qua các câu hỏi và trả lời được đưa ra trong giai đoạn phân tích yêu cầu, tài
liệu báo cáo tính khả thi, phân tích rủi ro của việc kiểm thử phần mềm.

 Hoạt động
Dựa vào các tài liệu được cung cấp và cập nhật mới nhất, thông thường, test
manager hoặc test leader sẽ là người lập kế hoạch kiểm thử cho cả QA team. Lập kế
hoạch kiểm thử nhằm xác định một số yếu tố quan trọng sau:
- Xác định phạm vi (Scope) dự án: Dự án thực hiện trong thời gian bao lâu? Bao
gồm những cơng việc gì cho từng khoảng thời gian xác định? Từ đó đưa ra lịch
trình thực hiện cho từng cơng việc nhỏ sao cho phù hợp với tồn bộ đội dự án.

- Xác định phương pháp tiếp cận: Nói về cách tiếp cận để kiểm thử cho một đối
tượng nào đó, thì phải dựa vào nhiều thứ, ví dụ như: Thời gian cho phép test có
phù hợp với con số ước lượng, nhiều hay ít, yêu cầu chất lượng từ phía khách
hàng thế nào? Cao, thấp hay khắc khe hay sao cũng được? Công nghệ / kỹ thuật
sử dụng để phát triển ứng dụng này là gì? Lĩnh vực của hệ thống/sản phẩm đang
được test (domain) là gì? ...Từ đó, test manager có thể đưa ra những phương
pháp và kế hoạch phù hợp nhất cho cả quá trình thực hiện dự án sao cho đúng
với các tiêu chí chấp nhận của sản phẩm và kịp tiến độ với các mốc thời gian
bàn giao, phát hành.
- Xác định các nguồn lực
Con người: Bao nhiêu người tham gia dự án, ai sẽ test phần nào, bao nhiêu
tester tham gia? Tester và nhóm phát triển có kinh nghiệm về lĩnh vực này
không?
Thiết bị: số lượng server, version, máy tính, mobile để thực hiện test là bao
nhiêu.
- Lên kế hoạch thiết kế công việc test: Bản kế hoạch kiểm thử sẽ bao gồm các nội
dung:
Liệt kê các chức năng cần kiểm thử.
Để thực hiện test chức năng này thì cần làm những cơng việc gì, trong thời gian

12

bao lâu, cái nào thực hiện trước, cái nào thực hiện sau, ai là người thực hiện.
Xác định điều kiện bắt đầu: xác định những điều kiện tối thiểu để bắt đầu hoạt
động kiểm thử cho từng chức năng.
Xác định điều kiện kết thúc: khi có những điều kiện nào thì sẽ kết thúc việc
kiểm thử.

 Đầu ra
Đầu ra của giai đoạn lập kế hoạch bao gồm các tài liệu như test plan, test

estimation, test schedule.
1.8.3. Thiết kế kịch bản kiểm thử

 Đầu vào
Đầu vào của giai đoạn thiết kế kịch bản kiểm thử là test plan, test estimation,
test schedule, các tài liệu đặc tả đã được cập nhật.

 Hoạt động
- Review tài liệu: Đầu tiên, các kiểm thử viên cần review lại tất cả các tài liệu để

xác định cơng việc cần làm, các cơng việc có khác gì so với dự án trước khách
hàng đưa cho, chức năng nào cần test, chức năng nào không cần test lại nữa. Từ
đó, vừa có thể tiết kiệm thời gian mà vẫn đưa ra được một kịch bản kiểm thử
đầy đủ và hiệu quả.
- Viết test case/ check list: Sau đó, tester bắt tay vào việc viết test case chi tiết
dựa vào kế hoạch đã đưa ra và vận dụng các kỹ thuật thiết kế kịch bản kiểm
thử. Test case cần bao phủ được tất cả các trường hợp kiểm thử có thể xảy ra
cũng như đáp ứng đầy đủ các tiêu chí của sản phẩm. Đồng thời tester cũng cần
đánh giá mức độ ưu tiên cho từng test case.
- Chuẩn bị dữ liệu kiểm thử: Cùng với việc tạo ra các test case chi tiết, đội kiểm
thử cũng cần chuẩn bị trước các dữ liệu kiểm thử cho các trường hợp cần thiết
như test data, test script.
- Review test case/ check list: Sau khi hoàn thành, các thành viên trong đội kiểm
thử hoặc test leader cũng cần review lại test case đã tạo để có thể bổ sung, hỗ
trợ lẫn nhau nhằm tránh những sai sót trong thiết kế test case và rủi ro về sau.

 Đầu ra

13

Sau khi hoàn thành thiết kế kịch bản kiểm thử, đội kiểm thử sẽ có các tài liệu
bao gồm: test design, test case, check list, test data, test automation script.

1.8.4. Thiết lập môi trường kiểm thử
 Đầu ra

Đầu vào của giai đoạn cài đặt môi trường kiểm thử là test plan, smoke test case,
test data.

 Hoạt động
- Việc cài đặt môi trường kiểm thử là giai đoạn cũng rất quan trọng trong vòng

đời phát triển phần mềm. Môi trường kiểm thử sẽ được quyết định dựa trên
những yêu cầu của khách hàng, hay đặc thù của sản phẩm ví dụ như server/
client/ network...
- Tester cần chuẩn bị một vài test case để kiểm tra xem môi trường cài đặt đã sẵn
sàng cho việc kiểm thử hay chưa. Đây chính là việc thực thi các smoke test
case.

 Đầu ra
Đầu ra của giai đoạn này là môi trường đã được cài đặt đúng theo yêu cầu, sẵn
sàng cho việc kiểm thử và kết quả của smoke test case.

1.8.5. Thực hiện kiểm thử
 Đầu vào

Tài liệu đầu vào của giai đoạn này là test plan, test design, test case, check list,
test data, test automation script.

 Hoạt động

- Thực hiện các test case như thiết kế và mức độ ưu tiên đã đưa ra trên môi

trường đã được cài đặt.
- So sánh với kết quả mong đợi sau báo cáo các bug xảy ra lên tool quản lý lỗi và

theo dõi trạng thái của lỗi đến khi được sửa thành công.

14

- Thực hiện re-test để verify các bug đã được fix và regression test khi có sự thay
đổi liên quan.

- Trong quá trình thực hiện kiểm thử, kiểm thử viên cũng có thể hỗ trợ, đề xuất
cho cả đội dự án để có giải pháp hợp lý và kết hợp công việc hiệu quả.

- Đo và phân tích tiến độ: kiểm thử viên cũng cần kiểm sốt chặt chẽ tiến độ cơng
việc của mình bằng cách so sánh tiến độ thực tế với kế hoạch, nếu chậm cần
phải điều chỉnh sao cho kịp tiến độ dự án, nếu nhanh cũng cần điều chỉnh vì có
thể test lead lên kế hoạch chưa sát với thực tế dự án. Từ đó có thể sửa chữa test
plan cần điều chỉnh để phù hợp với tiến độ dự án đưa ra.

- Report thường xuyên cho PM và khách hàng về tình hình thực hiện dự án: Cung
cấp thơng tin trong q trình kiểm thử đã làm được những chức năng nào, còn
chức năng nào, hồn thành được bao nhiều phần trăm cơng việc, báo cáo các
trường hợp phát sinh sớm, tránh ảnh hưởng tiến độ công việc của cả ngày.
 Đầu ra
Đầu ra của giai đoạn này là test results (kết quả kiểm thử), defect reports (danh

sách các lỗi tìm được).

1.8.6. Đóng hoạt động kiểm thử
 Đầu vào

Đầu vào của giai đoạn đóng chu trình kiểm thử là bao gồm tất cả những tài liệu
liên quan đã được tổng hợp, ghi chép và hoàn thiện đầy đủ trong suốt quy trình kiểm
thử của dự án: tài liệu phân tích đặc tả yêu cầu, test plan, test results, defect reports, tài
liệu Q&A,…

 Hoạt động
- Đây là giai đoạn cuối cùng trong quy trình kiểm thử phần mềm.
- Ở giai đoạn này, QA team thực hiện tổng kết, báo cáo kết quả về việc thực thi

test case, bao nhiêu case pass/ fail, bao nhiêu case đã được fix, mức độ nghiêm
trọng của lỗi, bao nhiêu lỗi cao/ thấp, lỗi còn nhiều ở chức năng nào, dev nào
nhiều lỗi. Chức năng nào đã hoàn thành test/ chưa hoàn thành test/ trễ tiến độ
bàn giao.

15

- Đánh giá các tiêu chí hồn thành như phạm vi kiểm tra, chất lượng, chi phí, thời
gian, mục tiêu kinh doanh quan trọng.

- Ngoài ra, giai đoạn này cũng thảo luận tất cả những điểm tốt, điểm chưa tốt và
rút ra bài học kinh nghiệm cho những dự án sau, giúp cải thiện quy trình kiểm
thử.
 Đầu ra
Đầu ra của giai đoạn này bao gồm các tài liệu:
– Test report
– Test results (final)

16

Chương II: Lập kế hoạch test

 Website test: myphamthainguyen.com.vn

Hệ thống cung cấp các chức năng quản lý hàng hóa, sản phẩm, thanh tốn đơn hàng

cho siêu thị.

 Phạm vi:

- Các chức năng test:

+ App: Quét QR, Đổi mật khẩu, Cập nhật thông tin cá nhân, Xem thông tin cá

nhân.

+ Web: Thêm sửa xóa hàng hóa, Thêm sửa xóa loại hàng hóa, Thêm sửa xóa

nhà cung cấp, Quản lý hóa đơn (tạo mới).

- Các chức năng khơng test: Đăng kí, đăng nhập, quên mật khẩu, Thống kê.

 Nhân sự:

Nhân sự Nhiệm vụ Kết quả
Triệu Hoàng Đức Kiểm thử app chức năng ĐÃ HOÀN THÀNH

Trần Văn Hải quét QR, đổi mật khẩu ĐÃ HOÀN THÀNH

Kiểm thử website chức

Trần Nguyên Bình năng quản lý hàng hóa ĐÃ HỒN THÀNH
Kiểm thử website chức

Phạm Quang Minh năng quản lý nhà cung cấp ĐÃ HOÀN THÀNH
Kiểm thử website chức

Bế Chí Kiên năng quản lý hóa đơn ĐÃ HOÀN THÀNH
Kiểm thử app chức năng

đổi thông tin cá nhân

 Mô tả chi tiết công việc:

Họ tên Công việc Mô tả
Triệu Hoàng Đức Kiểm thử app chức năng - Chọn kĩ thuật kiểm

quét QR, đổi mật khẩu thử
- Xây dựng testcase
- Tìm hiểu về công cụ

katalon
- Kiểm thử chức năng

quét QR

17

Trần Văn Hải Kiểm thử website chức - Kiểm thử chức năng

Trần Nguyên Bình năng quản lý hàng hóa đổi mật khẩu

Kiểm thử website chức - Báo cáo kết quả
năng quản lý nhà cung cấp - Chọn kĩ thuật kiểm

18 thử
- Xây dựng testcase
- Tìm hiểu về cơng cụ

katalon
- Kiểm thử chức năng

thêm hàng hóa
- Kiểm thử chức năng

sửa hàng hóa
- Kiểm thử chức năng

xóa hàng hóa
- Kiểm thử api gửi

thơng tin hàng hóa từ
barcode
- Báo cáo kết quả
- Chọn kĩ thuật kiểm
thử
- Xây dựng testcase
- Tìm hiểu về công cụ
katalon
- Kiểm thử chức năng

thêm nhà cung cấp
- Kiểm thử chức năng
sửa nhà cung cấp
- Kiểm thử chức năng
xóa nhà cung cấp
- Kiểm thử chức năng
nhập hàng
- Báo cáo kết quả

Phạm Quang Minh Kiểm thử website chức - Chọn kĩ thuật kiểm
Bế Chí Kiên năng quản lý hóa đơn thử

Kiểm thử app chức năng - Xây dựng testcase
đổi thông tin cá nhân - Tìm hiểu về cơng cụ

katalon
- Kiểm thử chức năng

tạo hóa đơn
- Báo cáo kết quả
- Tìm hiểu về lý thuyết

kiểm thử
- Chọn kỹ thuật kiểm

thử
- Xây dựng testcase
- Tìm hiểu về công cụ

katalon

- Kiểm thử app chức

năng đổi thông tin cá
nhân
- Báo cáo kết quả

 Môi trường test (Công cụ): Katalon, Chrome (Version 77.0.3865.120 (Official
Build) (64-bit))

 Phân tích, đánh giá rủi ro

19