ĐỀ 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ị
Kiểm thử tích hợp
- Là hoạt động kiểm thử nhỏ nhất,
- Là loại kiểm thử trong đó các
được tiến hành trên các Unit.
module của phần mềm được tích
- Người thực hiện: developers
hợp logic, được kiểm thử theo
- Ưu điểm: Phát hiện và sửa lỗi sớm
nhóm và thực hiện sau khi kiểm
(giai đoạn lập trình)  Tài liệu thử đơn vị.
kiểm thử có thể tái sử dụng lại 
- Mục tiêu:Phát hiện lỗi giao tiếp
Độc lập với các thành phần khác
xảy ra giữa các Unit, Tích hợp các của hệ thống.
Unit đơn lẻ thành các hệ thống nhỏ
- Nhược điểm: Không thể phát hiện
(subsystem) và cuối cùng là hệ
mọi lỗi của chương trình, Khi thay
thống hoàn chỉnh để chuẩn bị cho
đổi interface của module → phải kiểm thử mức System sửa lại nhiều testcase
- Dữ liệu kiểm thử: Đặc tả thiết kế.
- Dữ liệu kiểm thử: Đặc tả các
Tập trung vào các giao diện và
module - Kỹ thuật sử dụng: kỹ thuật
luồng xử lý thông tin giữa các
bao phủ code (code coverage) – module - Cách tiếp cận:
thống kê dựa vào số lượng code
Big bang: các thành phần được tích
được kiểm tra. - Bao phủ dòng lệnh
hợp cùng lúc, sau đó tiến hành kiểm - Bao phủ nhánh 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 lOMoARcPSD|35883770 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 năng của phầm mềm
chương trình hoặc của một mô hợp giữa
- KTV xem phần mềm như là
hình của mã chương trình để black box
một hộp đen: Không quan tâm
xây dựng các phép thử theo các test và
đến cấu trúc và hành vi bên
tiêu chuẩn bao phủ. Kiểm thử white box
trong phần mềm. Chỉ quan tâm
cấu trúc bên trong của phần test
đến các “hoạt động bề ngoài”
mềm, với mục đích kiểm tra tất - Trong Kiểm của phần mềm.
cả các câu lệnh và điều kiện tồn thử Hộp xám, cấu
- Mức áp dụng: kiểm tra hệ tại trong phần mềm đó. trúc bên
thống, kiểm trachấpnhận - Mức áp dụng: trong sản
- KTCN không cần biết về lập
- Kiểm thử đơn vị: kiểm tra phẩm chỉ
trình,cố gắng tìm ra các LỖI sau:
đường dẫn trong một đơn vị được biết - Chức năng THIẾU hoặc
Kiểm thử tích hợp: kiểm tra một phần. KHÔNG ĐÚNG
đường dẫn giữa các đơn vị - Lỗi giao diện
- Kiểm thử hệ thống: Kiểm tra
- Lỗi cấu trúc dữ liệu
đường dẫn giữa các hệ thống - Lỗi truy cập CSDL bên
con. - KTCN cần có kiến thức về ngoài. - Lỗi thi hành lập trình
- Lỗi khởi tạo/kết thúc.
- Kiểm tra hộp trắng được bắt
- Kiểm tra hộp đen được bắt đầu
đầu dựa trên các tài liệu thiết kế
dựa trên tài liệu yêu cầu kỹ thuật 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: Tổng là 120 TC, thực
hiện 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