ĐỀ CƯƠNG ÔN TẬP MÔN KIỂM THỬ

LỚP CT02
1. I/ Lý thuyết
1. Lợi ích chính của việc kiểm thử sớm trong chu kỳ phát triển phần mềm là
gì? Vì sao nói lỗi càng phát hiện muộn thì chi phí sửa lỗi càng cao?
- Hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong chu trình phát triển
mềm và cần được tập trung vào các mục tiêu xác định.
- Kiểm thử sớm, phát hiện lỗi sớm, lỗi được sửa sớm sẽ đảm bảo được dự án
hoàn thành đúng tiến độ và chất lượng sản phẩm cũng được đảm bảo. Chi phí
của dự án cũng sẽ không bị phát sinh.
- Lỗi phát hiện muộn, sửa muộn, nhất là dồn vào giai đoạn thời gian cuối dự án,
sẽ dẫn đến sửa vội, test vội, code vội, chất lượng ko được đảm bảo, tiến độ
không hoàn thành được dẫn đến phải overtime, tăng chi phí của dự án.
- Phù hợp theo mô hình Thác nước.
- Giúp phát hiện sớm các lỗi nghiêm trọng trong chu kỳ kiểm thử.
- Giúp Nhóm Phát triển ổn định mã nguồn sớm.
- Giúp giảm thiểu chi phí do sửa lỗi.
- Giúp Nhóm phát triển xác định các lỗi một cách chi tiết ngay từ đầu trong chu
kỳ phát hành.
- Nhóm quản lý có thể đưa ra các quyết định kinh doanh phù hợp dựa trên khối
lượng các lỗi nghiêm trọng chưa được giải quyết trong Dự án/phiên bản phát
hành.
- Giúp phân phối tài nguyên dùng cho việc Phát triển và kiểm thử một cách hiệu
quả.
Vì sao lỗi càng phát hiện muộn thì chi phí sửa lỗi càng cao?
- Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời
phát triển sản phẩm. Từ giai đoạn Phân tích đặc tả nghiệp vụ, Thiết kế, Coding
chứ không chỉ riêng giai đoạn test hay tập trung cho tất cả giai đoạn test.
- Lỗi được phát hiện càng muộn thì chi phí cho việc sửa lỗi càng lớn, bởi vì có
những lỗi sẽ phải thực hiện lại từ khâu Thiết kế, rồi coding lại và mới thực hiện
test được. Nên lỗi được phát hiện càng sớm, càng ở những giai đoạn đầu dự án,
thậm chí ngay từ giai đoạn làm Yêu cầu/ Nghiệp vụ giúp cho các giai đoạn sau
thực hiện được chính xác, giảm được số lượng lỗi và sản phẩm hoàn thành
đúng tiến độ theo kế hoạch.
- Bug phát sinh ở giai đoạn release là nghiêm trọng và tốn kém nhất. Không chỉ
bị ảnh hưởng về mặt uy tín chất lượng sản phẩm, mà còn dẫn đến việc phải
coding và testing lại, phát sinh chi phí về nhân lực dự án, chậm trễ tiến độ.
- Bug được phát hiện càng muộn thì chi phí sửa càng lớn. Đôi khi không chỉ tỷ lệ
với thời gian mà có thể là tỷ lệ bình phương thời gian.
2. Trình bày về ca kiểm thử và kịch bản kiểm thử? Lấy ví dụ minh họa
Ca kiểm thử:
 - Là một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng có thỏa
mãn yêu cầu đặt ra hay không.
- Một Test Case mô tả dữ liệu đầu vào (input), hành động (action) và kết quả
mong đợi (expected respone), kết quả thực tế, để 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.
- Mô tả Test case chi tiết hay ngắn gọn phụ thuộc vào quy mô của dự án hay quy
mô của công ty sản xuất phần mềm.VD….
Kịch bản kiểm thử:

- Test Scenario bao gồm tất cả các chức năng có thể được kiểm thử .
- Test Scenario còn được gọi là Test Condition hoặc Test Possibility.
- Mục đích của Test scenario: Cung cấp cái nhìn tổng thể cho các tester, nhà
phân tích, nhà phát triển, khách hàng vv.. Tạo đề xuất về tổ chức hoặc nguồn
nhân lực, Các Tester sẽ dựa trên Test Scenario để xây dựng các Test Case/Test
script.

3. Lỗi thường xuất hiện ở giai đoạn nào là chủ yếu trong chu kỳ phát triển
phần mềm?
- Lỗi xuất hiện ở tất cả các giai đoạn của phát triển phần mềm, Ở giai đoạn sau
khi code xong và bàn giao sang cho tester bắt đầu giai đoạn testing là nhiều
nhất. Một bên test và 1 bên fix bug, đây là giai đoạn nhiều lỗi nhất trong chu kỳ
phát triển phần mềm.

4. So sánh kiểm thử mức đơn vị và kiểm thử tích hợp? Lấy ví dụ minh họa
Kiểm thử đơn vị
- Là hoạt động kiểm thử nhỏ nhất, - Là loại kiểm thử trong đó các module
được tiến hành trên các Unit.
- Người thực hiện: developers
- Ưu điểm: Phát hiện và sửa lỗi sớm
(giai đoạn lập trình) ⁄ Tài liệu kiểm
thử có thể tái sử dụng lại ⁄ Độc lập
với các thành phần khác của hệ
thống.
- Nhược điểm: Không thể phát hiện
mọi lỗi của chương trình, Khi thay
đổi interface của module → phải sửa
lại nhiều testcase
- Dữ liệu kiểm thử: Đặc tả các module
- Kỹ thuật sử dụng: kỹ thuật bao phủ
code (code coverage) – thống kê dựa
vào số lượng code được kiểm tra.
- Bao phủ dòng lệnh
- Bao phủ nhánh
Kiểm thử tích hợp
của phần mềm được tích hợp logic,
được kiểm thử theo nhóm và thực
hiện sau khi kiểm thử đơn vị.
- Mục tiêu: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ỏ
(subsystem) và cuối cùng là hệ thống
hoàn chỉnh để chuẩn bị cho kiểm thử
mức System
- Dữ liệu kiểm thử: Đặc tả thiết kế.
Tập trung vào các giao diện và luồng
xử lý thông tin giữa các module
- Cách tiếp cận:
Big bang: các thành phần được tích
hợp cùng lúc, sau đó tiến hành kiểm
thử
- Bao phủ điều kiện Tiếp cận tăng dần: ghép hai hoặc
nhiều module có liên quan đến logic,
quá trình tiếp tục cho đến khi tất cả các
module được them vào và hoàn thành
quá trình kiểm thử:Bottom Up, Top
Down.

Ví dụ về Test Case trong kiểm thử tích hợp

5. Phân biệt kiểm thử hộp đen, kiểm thử hộp trăng và kiểm thử hộp xám.
Kiểm thử hộp đen Kiểm thử hộp trắng Kiểm thử
hộp xám
- Tập trung vào các yêu cầu chức - Dựa trên việc phân tích mã - là sự kết hợp
năng của phầm mềm chương trình hoặc của một mô giữa black
- KTV xem phần mềm như là một hình của mã chương trình để xây box test và
hộp đen: Không quan tâm đến dựng các phép thử theo các tiêu white box test
cấu trúc và hành vi bên trong chuẩn bao phủ. Kiểm thử cấu trúc - Trong Kiểm
thử Hộp xám,
phần mềm. Chỉ quan tâm đến các bên trong của phần mềm, với mục cấu trúc bên
“hoạt động bề ngoài” của phần đích kiểm tra tất cả các câu lệnh trong sản
mềm. và điều kiện tồn tại trong phần phẩm chỉ
- Mức áp dụng: kiểm tra hệ thống, mềm đó. được biết một
kiểm trachấpnhận - Mức áp dụng: phần.
- KTCN không cần biết về lập - Kiểm thử đơn vị: kiểm tra đường
trình,cố gắng tìm ra các LỖI sau: dẫn trong một đơn vị
- Chức năng THIẾU hoặc KHÔNG Kiểm thử tích hợp: kiểm tra đường
ĐÚNG
 - Lỗi giao diện
- Lỗi cấu trúc dữ liệu
- Lỗi truy cập CSDL bên ngoài.
- Lỗi thi hành
- Lỗi khởi tạo/kết thúc.
- Kiểm tra hộp đen được bắt đầu
dựa trên tài liệu yêu cầu kỹ thuật
dẫn giữa các đơn vị
- Kiểm thử hệ thống: Kiểm tra
đường dẫn giữa các hệ thống con.
- KTCN cần có kiến thức về lập
trình
- Kiểm tra hộp trắng được bắt đầu
dựa trên các tài liệu thiết kế chi
tiết

6. So sánh kiểm thử hệ thống và kiểm thử chấp nhận. Lấy ví dụ minh họa.

7. Lấy ví dụ về việc xây dựng kế hoạch kiểm thử cho tổng thể?
Ví dụ: kiểm thử website
Bước 1: Phân tích sản phẩm: Trả lời các câu hỏi: Ai là người dùng website,
Website được dùng được dùng để làm gì, Website sẽ hoạt động như thế nào?
Phần mềm/phần cứng mà sản phẩm sử dụng là gì? ⁄ Xem xét qua website và tài
liệu của sản phẩm, đánh giá tài liệu sản phẩm giúp ta hiểu tất cả các tính năng
của website cũng như cách sử dụng nó. ⁄ Có thể phỏng vấn thêm khách hang,
developers hoặc nhà thiết kế. → Mục đích là hiểu chi tiết về sản phẩm
Bước 2: Xây dựng chiến lược kiểm thử ⁄ Chiến lược kiểm thử là tài liệu cấp cao,
thường được phát triển bởi Test Manager. ◼ Mục tiêu kiểm thử của dự án và các
phương tiện để đạt được mục tiêu ◼ Xác định efforts và chi phí kiểm thử
Phạm vi kiểm thử ⁄ Trong phạm vi: Kiểm thử chức năng, Kiểm thử API ⁄ Ngoài
phạm vi: Kiểm thử CSDL, phần cứng và bất kỳ giao diện bên ngoài nào khác. ♦
Loại kiểm thử: ⁄ Kiểm thử API (kiểm thử các giao diện lập trình ứng dụng) ⁄
Kiểm thử tích hợp ⁄ Kiểm thử hệ thống
Tài liệu rủi ro và các vấn đề khác

Lựa chọn Testers ⁄ Ai sẽ kiểm thử và khi nào kiểm thử? ⁄ Dựa trên kỹ
năng của từng thành viên để lựa chọn.
Bước 3: xác định mục tiêu và tiêu chí dừng kiểm thử ♦ Liệt kê các tính năng
phần mềm (chức năng, hiệu suất, GUI, …) có thể cần kiểm thử ♦ Xác định mục
tiêu kiểm thử dựa trên các tính năng trên. ♦ Xác định tiêu chí dừng kiểm thử ♦
Ví dụ: kiểm thử website ⁄ Sử dụng pp Top-Down để xác định các tính năng của
website (tốt nhất nên sử dụng bản đồ tư duy) ⁄ Xác định mục tiêu, ví dụ:
Kiểm thử chức năng đăng nhập có hoạt động đúng như mong đợi không ◼ Kiểm
thử giao diện website có hoạt động như mong đợi và đáp ứng nhu cầu khách
hàng không? ◼ Xác minh khả năng sử dụng của website. Các chức năng có
thuận tiện cho người sử dụng không?
Xác định tiêu chí kiểm thử ♦ Tiêu chí tạm dừng ⁄ Ví dụ: nếu các thành viên
trong nhóm báo cáo rằng có 40% test case thất bại, ta cần tạm dừng kiểm thử
cho đến khi nhóm developers sửa tất cả các trường hợp failed. ♦ Tiêu chí kết
thúc: có nhiều phương pháp ⁄ Dựa trên tỷ lệ thực hiện: là tỷ lệ giữa số test case
được thực hiện/tổng số test case đặc tả kiểm thử. ◼
VD: Tng là 120 TC, thc hin 100TC T l: 83%
⁄ Dựa trên tỷ lệ pass: là tỷ lệ giữa số lượng test case
pass/test case thực hiện. ◼ VD: 100 TC, 80TC pass → Tỷ lệ: 80% Xác định
tiêu chí kiểm thử ♦ Chú ý: ⁄ Tỷ lệ thực hiện là bắt buộc 100% ⁄ Tỷ lệ pass phụ
thuộc vào phạm vi dựa án .
Bước 4: Lập kế hoạch nguồn lực ♦ Kế hoạch tài nguyên là bản tóm tắt chi tiết
các loại tài nguyên (con người, thiết bị, vật liệu vv…) cần để hoàn thành dự án
♦ Ví dụ: ⁄ Bảng nguồn nhân lực ⁄ Bảng tài nguyên hệ thống.
Bước 5: Thiết lập môi trường kiểm thử ♦ Môi trường kiểm thử là một thiết lập
giữa phần mềm và phần cứng mà nhóm kiểm thử sẽ thực hiện các test case. ♦
Bao gồm: môi trường và người dùng thực tế, môi trường vật lý như máy chủ,
vv… ♦ Ví dụ: kiểm thử website, hỏi developer ⁄ Số người dung tối đa? ⁄ Yêu cầu
phần cứng/ phần mềm? ⁄ Có cần sử dụng một cài đặt cụ thể nào để duyệt
webhay không?
Bước 6: Lịch trình và Ước lượng.

Bước 7: Bàn giao sản phẩm kiểm thử ♦ Trước giai đoạn kiểm thử: Test Plan,
Test Case, kiểm thử thông số thiết kế kỹ thuật ♦ Trong quá trình kiểm thử: Test
Scripts, mô phhongr, dữ liệu, file mô tả lỗi và các bước thực hiện ♦ Sau kiểm
thử: báo cáo kết quả, hướng dẫn quy trình kiểm thử, ghi chú.

8. Phân biệt giữa kiểm thử bởi nhóm kiểm thử độc lập và kiểm thử bởi lập
trình viên. Lấy ví dụ minh họa.

9. Kiểm thử phần mềm nhúng có gì khác so với kiểm thử phần mềm thông
thường? Lấy ví dụ minh họa.
Kiểm thử phần mềm hệ thống nhúng có nhiều điểm chung với kiểm thử phần
mềm ứng dụng. Vì vậy, phần lớn ở bài viết là một bản tóm tắt các khái niệm và
thuật ngữ thử nghiệm cơ bản. Tuy nhiên, có một số khác biệt quan trọng giữa
thử nghiệm ứng dụng và thử nghiệm hệ thống nhúng:
Các nhà phát triển nhúng thường có quyền truy cập vào các công cụ kiểm thử
dựa trên phần cứng, việc này thường không được sử dụng trong phát triển ứng
dụng.
Ngoài ra, các hệ thống nhúng thường có các đặc điểm độc đáo cần được phản
ánh trong kế hoạch kiểm tra. Những khác biệt này có xu hướng cung cấp cho
các hệ thống nhúng cách thử nghiệm đặc biệt riêng của nó.

10. Trong quá trình kiểm thử, tester tìm thấy bug và báo cho developer nhưng
developer không đồng ý đó là bug. Tester nên làm gì tiếp theo?
11. Một báo cáo công việc kiểm thử (test report) gồm những gì? Và ích lợi của
bảng báo cáo này?
Lợi ích: Bản Test Report tốt sẽ cho phép chúng ta (và không chỉ riêng chúng ta)
có thể đánh giá trạng thái hiện tại của dự án cũng như chất lượng của sản phẩm.
Có khả năng đưa ra những quyết định sáng suốt nếu cần thiết.
Test Report có thể là tài liệu cuối cùng xác định việc sản phẩm đã sẵn sàng phát
hành hay chưa.
Nội dung của một bản Test Report
Các bước:
- Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa
- Đánh giá độ bao phủ
- Phân tích lỗi
- Xác định quá trình kiểm thử có đạt yêu cầu không
- Báo cáo tổng hợp
Thông tin dự án
Thông thường, bạn nên ghi rõ tên dự án, tên sản phẩm và phiên bản của sản phẩm
trong bản Test Report. Như ví dụ ở hình ảnh dưới đây.
Mục tiêu kiểm thử
Mục tiêu của từng giai đoạn trong quy trình kiểm thử phần mềm (kiểm tra chức
năng, kiểm tra hiệu năng, kiểm tra giao diện người dùng, vv) cần phải được mô tả
trong Test Report.
Tóm tắt kiểm thử
Điều tiếp theo bắt buộc phải được chỉ ra như phần dưới đây:

● Số lượng các trường hợp kiểm thử đã thực hiện

● Số lượng các trường hợp kiểm thử thành công
● Số lượng các trường hợp kiểm tra không thành công
● Tỷ lệ phần trăm các trường hợp kiểm thử thành công
● Tỷ lệ phần trăm các trường hợp kiểm thử không thành công
● Các bình luận liên quan

Việc trình bày sẽ tốt hơn nếu bạn thể hiện các thông tin một cách trực quan. Dùng
các chỉ dẫn màu sắc, các biểu đồ, và các bảng biểu được đánh dấu nổi bật.

Bạn có thể xem ví dụ dưới đây về Test Report cho các trường hợp kiểm thử (Test
cases)
Các lỗi
Phần này nên chứa những thông tin sau:

● Tổng số lỗi đã phát hiện

● Trạng thái mỗi lỗi (mở, đóng, đã sửa lỗi, v.v.) - (open, closed, fixed etc.)
● Số lỗi theo từng trạng thái (mở, đóng, đã sửa lỗi, v.v.) - (open, closed, fixed
etc.)
● Phân tích mức độ ưu tiên và mức độ xảy ra lỗi - (Severity and priority)

Hình ảnh phía dưới đây minh hoạ bản Test Report cho các lỗi
Giả sử nhóm dự án đã gửi cho bạn thông tin về lỗi như sau:

● Mật độ lỗi là trung bình 20 lỗi/1000 dòng mã code

● Tổng số 90% lỗi đã được sửa
● Chi tiết của các lỗi được mô tả trong trình theo dõi lỗi

Vậy bạn có thể biểu diễn dữ liệu về lỗi như biểu đồ sau:

12. Kiểm thử tự động là gì? Những loại kiểm thử nào không nên kiểm thử tự
động?
- Kiểm thử tự động là việc sử dụng các công cụ để thực hiện các test case. Kiểm
thử tự động cũng có thể nhập dữ liệu thử nghiệm vào hệ thống kiểm thử, so
sánh kết quả mong đợi với kết quả thực tế và tạo ra các báo cáo kiểm thử chi
tiết.

13. Trong một dự án kiểm thử thì những hoạt động kiểm thử nào có thể kiểm
thử tự động được?
- Kiểm thử tự động được sử dụng khi:
 Các trường hợp kiểm thử được thực hiện lặp đi lặp lại để đảm bảo tính
năng. của phần mềm/ sản phẩm.
Thực hiện ở các trường hợp mà kiểm thử thủ công khó thực hiện.
Các trường hợp kiểm thử cần tốn nhiều thời gian.
14. Những yếu tố nào cần cân nhắc khi lựa chọn các công cụ kiểm thử tự
động? Kiểm thử tự động có thay thế được kiểm thử thủ công?
Một số yếu tố bạn cần cân nhắc bao gồm:

Tính khả thi về mặt kĩ thuật

Độ phức tạp
Tính ổn định của ứng dụng cần test
Test data
Kích thước dự án
Khả năng tái sự dụng của automated scrip
Khả năng execute với nhiều môi trường...
Kiểm thử tự động không thay thế được kiểm thử thủ công:
1. Usability testing không thể test bởi test tự động.
Không thể Tự động kiểm tra Usability testing. Kiểm tra khả năng sử dụng đòi
hỏi con người phải thực hiện. Bạn không thể đào tạo một máy tính để xác định
khả năng sử dụng "tốt" và "xấu". Có lẽ bạn đang nghĩ, "ok, chúng ta sẽ bỏ qua
Usability testing", như thế bạn đang có một lượng lớn rủi ro. Bước này trong
quá trình đảm bảo chất lượng là rất quan trọng để đảm bảo sự tự tin trong việc
release sản phẩm, và không có cách nào để tham gia vào việc kiểm tra khả năng
sử dụng ngoài con người.
2. Automated testing chỉ kiểm tra những gì có thể dự đoán.
Các bài kiểm tra tự động cho thấy rằng những gì chúng ta mong đợi thực sự
được xảy ra. Chúng tôi gọi đó là "happy parth". Tự động hóa tập trung vào các
chức năng đã tồn tại. Phạm vi của nó là rộng lớn, nhưng nó không sâu.
automated testing là rất tốt cho các bài kiểm tra hồi quy, đặc biệt là khi nguồn
lực được giới hạn. Nhưng Automated testing chắc chắn sẽ còn một số thất bại
và lỗ hổng trong quá trình thử nghiệm.
3. Tất cả chúng ta đều là exploratory testers.
Sự thật là, tất cả chúng ta làm kiểm thử phần mềm. Ngay cả khi bạn không phải
là "tester" hoặc "qa" , có thể bạn đã tham gia vào một số cuộc thử nghiệm thăm
dò.
Thí nghiệm khám phá cho phép chúng tôi lấy các phần của ứng dụng và lột lại
các lớp để khám phá những điều kiểm tra tự động sẽ không bao giờ tìm thấy.
Thử nghiệm thăm dò là một quá trình thủ công, và không thể thay đổi được.
4. Kiểm tra tự động có thể chứa lỗi.
Giống như mã ứng dụng của bạn có thể chứa lỗi, các bài kiểm tra tự động cũng
có thể. Nếu bạn viết các bài kiểm tra tự động bị lỗi, bạn sẽ có các kết quả sai.
Điều này có thể dẫn đến các vấn đề nghiêm trong cho khách hàng và nhóm của
bạn. Yếu tố con người trong kiểm tra thủ công có thể xác định những lỗi này và
đảm bảo rằng bạn đang kiểm tra đúng.
5. Các hạn chế kỹ thuật có thể được đưa vào.
Một số kịch bản thử nghiệm chỉ là quá phức tạp hoặc thật sự không thể tự động
hóa. Một lập luận chung là "thử nghiệm tự động rẻ hơn". Nhưng không tốn
nhiều thời gian và tiền bạc cho việc tự động hoá phức tạp.

Ví dụ, thử nghiệm một loạt các thiết bị màn hình cảm ứng. Làm thế nào để bạn
áp dụng test tự động với các công việc là "tap" và một "swipe". Bạn không thể
làm điều đó theo cách nào ngoài việc sử dụng của con người.
15. Làm thế nào để bạn biết hoạt động kiểm thử của bạn có hiệu quả hay
không?

2. II. Bài tập

Xây dựng các test case dựa trên các kỹ thuật kiểm thử:
16. Phân vùng tương đương
17. Phân tích giá trị biên
18. Bảng quyết định
19. Đồ thị nguyên nhân – kết quả
20. Luồng điều khiển