Đề cương môn học kiểm thử phần mềm nhúng

Đề cương môn học kiểm thử phần mềm nhúng

ĐỀ CƯƠNG ÔN TẬP MÔN KIỂM THỬ
LỚP CT02
1. I/ 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 gì?
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 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 độ 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 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 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 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 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 kiểm thử một cách hiệu quả.
sao lỗi càng phát hiện muộn thì chi phí sửa lỗi càng cao?
- Kiểm thử sửa lỗi 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 những
lỗi sẽ phải thực hiện lại từ khâu Thiết kế, rồi coding lại 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 sản phẩm hoàn thành đúng tiến độ theo kế hoạch.
- Bug phát sinh giai đoạn release nghiêm trọng 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, còn dẫn đến việc phải coding 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 thể tỷ lệ bình phương thời gian.
2. Trình bày về ca kiểm thử kịch bản kiểm thử? Lấy dụ minh họa Ca kiểm
thử:
- một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng thỏa mãn
yêu cầu đặt ra hay không
- Một Test Case tả dữ liệu đầu vào (input), hành động (action) 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.
- tả Test case chi tiết hay ngắn gọn phụ thuộc vào quy của dự án hay quy
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 thể được kiểm thử . - Test Scenario
còn được gọi 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 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 bàn giao sang cho tester bắt đầu giai đoạn testing nhiều nhất. Một bên
test 1 bên fix bug, đây 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ị kiểm thử tích hợp? Lấy dụ minh họa
Kiểm thử đơn vị
Kiểm thử tích hợp
- hoạt động kiểm thử nhỏ nhất,
được tiến hành trên các Unit.
- Người thực hiện: developers
- Ưu điểm: Phát hiện sửa lỗi sớm
(giai đoạn lập trình) Tài liệu
kiểm thử 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 dựa vào số lượng code
được kiểm tra. - Bao phủ dòng lệnh
- Bao phủ nhánh
- Bao phủ điều kiện
- loại kiểm thử trong đó các
module của phần mềm được tích
hợp logic, được kiểm thử theo
nhóm 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) cuối cùng 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
luồng xử 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ử
Tiếp cận tăng dần: ghép hai hoặc
nhiều module 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 hoàn
thành quá trình kiểm thử:Bottom
Up, Top
lOMoARcPSD|35883770
Down.
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 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
năng của phầm mềm
- KTV xem phần mềm như
một hộp đen: Không quan tâm
đến cấu trúc hành vi bên
trong phần mềm. Chỉ quan tâm
đến các “hoạt động bề ngoài”
của phần mềm.
- Mức áp dụng: kiểm tra hệ
thống, kiểm trachấpnhận
- KTCN không cần biết về lập
trình,cố gắng tìm ra các LỖI sau:
- Chức năng THIẾU hoặc
KHÔ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ựa trên việc phân tích
chương trình hoặc của một
hình của chương trình để
xây dựng các phép thử theo các
tiêu chuẩn bao phủ. Kiểm thử
cấu trúc bên trong của phần
mềm, với mục đích kiểm tra tất
cả các câu lệnh điều kiện tồn
tại trong phần mềm đó.
- Mức áp dụng:
- Kiểm thử đơn vị: kiểm tra
đường dẫn trong một đơn vị
Kiểm thử tích hợp: kiểm tra
đường 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 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
- sự kết
hợp giữa
black box
test
white box
test
- Trong Kiểm
thử Hộp
xám, cấu
trúc bên
trong sản
phẩm chỉ
được biết
một phần.
6. So sánh kiểm thử hệ thống kiểm thử chấp nhận. Lấy dụ minh họa.
7. Lấy dụ về việc xây dựng kế hoạch kiểm thử cho tổng thể? 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 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 sản phẩm sử dụng gì? Xem xét qua website
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ó. thể phỏng vấn thêm khách
hang, developers hoặc nhà thiết kế. Mục đích 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ử 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
các phương tiện để đạt được mục tiêu Xác định efforts 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 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 các vấn đề khác
Lựa chọn Testers Ai sẽ kiểm thử 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 tiêu chí dừng kiểm thử Liệt các tính năng
phần mềm (chức năng, hiệu suất, GUI, …) 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ử 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 đồ duy) Xác định mục tiêu,
dụ:
Kiểm thử chức năng đăng nhập hoạt động đúng như mong đợi không
Kiểm thử giao diện website hoạt động như mong đợi đá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
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 dụ: nếu các thành viên
trong nhóm báo cáo rằng 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: nhiều phương pháp Dựa trên tỷ lệ thực hiện: 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 120 TC, thực
hiện 100TC Tỷ lệ: 83% Dựa trên tỷ lệ pass: 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 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 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
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ử một thiết lập
giữa phần mềm phần cứng nhóm kiểm thử sẽ thực hiện các test case.
Bao gồm: môi trường người dùng thực tế, môi trường vật như máy chủ,
vv… 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ầ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 Ướ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, phhongr, dữ liệu, file tả lỗi 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 kiểm thử bởi lập trình
viên. Lấy dụ minh họa.
9. Kiểm thử phần mềm nhúng khác so với kiểm thử phần mềm thông
thường? Lấy dụ minh họa.
Kiểm thử phần mềm hệ thống nhúng nhiều điểm chung với kiểm thử phần
mềm ứng dụng. vậy, phần lớn bài viết một bản tóm tắt các khái niệm
thuật ngữ thử nghiệm bản. Tuy nhiên, một số khác biệt quan trọng giữa
thử nghiệm ứng dụng thử nghiệm hệ thống nhúng:
Các nhà phát triển nhúng thường 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 đ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 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 báo cho developer nhưng
developer không đồng ý đó bug. Tester nên làm tiếp theo? 11. Một báo cáo
công việc kiểm thử (test report) gồm những gì? í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)
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.
khả năng đưa ra những quyết định sáng suốt nếu cần thiết.
Test Report thể 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 đề 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ử đạ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 tên dự án, tên sản phẩm phiên bản của sản phẩm
trong bản Test Report. Như 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 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 đồ, các bảng biểu được đánh dấu nổi bật.
Bạn thể xem 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 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 trung bình 20 lỗi/1000 dòng code Tổng số 90% lỗi đã được
sửa
Chi tiết của các lỗi được tả trong trình theo dõi lỗi
Vậy bạn thể biểu diễn dữ liệu về lỗi như biểu đồ sau:
12. Kiểm thử tự động gì? Những loại kiểm thử nào không nên kiểm thử tự
động?
- Kiểm thử tự động 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 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ế 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 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 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 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 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"
"xấu". lẽ bạn đang nghĩ, "ok, chúng ta sẽ bỏ qua
Usability testing", như thế bạn đang một lượng lớn rủi ro. Bước này trong
quá trình đảm bảo chất lượng rất quan trọng để đảm bảo sự tự tin trong việc
release sản phẩm, không 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 thể dự đoán.
Các bài kiểm tra tự động cho thấy rằng những chúng ta mong đợi thực sự
được xảy ra. Chúng tôi gọi đó "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 rộng lớn, nhưng không sâu.
automated testing rất tốt cho các bài kiểm tra hồi quy, đặc biệt 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
lỗ hổng trong quá trình thử nghiệm.
3. Tất cả chúng ta đều 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
"tester" hoặc "qa" , 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 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 một quá trình thủ công, không thể thay đổi được.
4. Kiểm tra tự động thể chứa lỗi.
Giống như ứng dụng của bạn thể chứa lỗi, các bài kiểm tra tự động cũng
thể. Nếu bạn viết các bài kiểm tra tự động bị lỗi, bạn sẽ các kết quả sai.
Điều này thể dẫn đến các vấn đề nghiêm trong cho khách hàng nhóm của
bạn. Yếu tố con người trong kiểm tra thủ công thể xác định những lỗi này
đảm bảo rằng bạn đang kiểm tra đúng.
5. Các hạn chế kỹ thuật thể được đưa vào.
Một số kịch bản thử nghiệm chỉ quá phức tạp hoặc thật sự không thể tự động
hóa. Một lập luận chung "thử nghiệm tự động rẻ hơn". Nhưng không tốn
nhiều thời gian tiền bạc cho việc tự động hoá phức tạp.
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 "tap" 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 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
| 1/13

Preview text:

ĐỀ 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