Tổng hợp những câu hỏi cần thiết và quan trọng của môn Kiểm thử phần mềm nhúng (KMA). Tài liệu này giúp các bạn sinh viên có thể vượt qua các bài kiểm tra giữa kỳ, cuối kỳ và đạt kết quả cao nhất. Xin cảm ơn các bạn đã xem và tải tài liệu.
Trang 1ĐỀ CƯƠNG ÔN TẬP CUỐI KỲ
I Lý thuyết
Câu 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?
• Lợi ích của kiểm thử sớm:
- 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 không đượ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ả
• Lỗi càng phát hiện muộn thì chi phí sửa lỗi càng cao vì:
- 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
Trang 2Câu 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 TC mô tả dữ liệu đầu vào, hành động và kết quả mong đợi, để 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ả TC 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
Ví dụ:
ID Test Case Description TC Procedure Expected Result Test Result
1 Tên không được để
trống
Không nhập vào trường tên
Click nút Đăng ký
Thông báo: “Vui lòng nhập tên”
Pass
• 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:
o Cung cấp cái nhìn tổng thể cho các tester, nhà ptích, nhà phát triển, khách hàng
o Tạo đề xuất về tổ chức hoặc nguồn nhân lực
o Các Tester sẽ dựa trên Test Scenario để xây dựng các Test Case/Test script
Ví dụ: Danh sách kiểm thử tính khả dụng cho một ứng dụng web
- Nội dung chính xác, không có bất kỳ lỗi chính tả hoặc ngữ pháp nào
- Tất cả font chữ phải giống nhau, theo đúng đặc tả
- Tất cả các văn bản phải được căn chỉnh đúng
- Phải có khoảng trống hợp lý giữa các nhãn trường, cột, hàng và thông báo lỗi
- Kiểm tra các liên kết và các hình ảnh
Câu 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 phần mềm xuất hiện ở tất cả các công đoạn nhưng ở phần đặc tả là xuất hiện nhiều nhất (chiếm 70%) Thường là định nghĩa các yêu cầu bị lỗi, lỗi trong giao tiếp giữa khách hàng và nhà phát triển, đặc tả không được viết ra, không đủ cẩn thận, đã thay đổi hoặc do chưa phối hợp tốt trong nhóm
Trang 3Câu 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
Đây là giai đoạn thử nghiệm ban đầu trong
vòng đời phát triển phần mềm
Được thực hiện sau khi kiểm thử đơn vị và trước khi kiểm thử hệ thống
Đoạn code nhỏ nhất sẽ được thử nghiệm Các module khác nhau được kết hợp hoặc
tích hợp để kiểm tra xem chúng có hoạt động cùng nhau hay không
Tập trung vào kiểm tra chức năng của từng
đơn vị riêng lẻ
Tập trung vào việc xác định các lỗi phát sinh bằng cách tích hợp các module khác nhau
Là một loại kiểm thử hộp trắng Là một loại kiểm thử hộp đen
Được thực hiện bởi các developer hoặc bởi
tester
Được thực hiện bởi tester
Maintain các trường hợp kiểm thử đơn vị là
rẻ hơn
Maintain các trường hợp kiểm thử tích hợp
là tốn kém hơn
Rất dễ dàng tìm thấy lỗi trong phương pháp
này
Tương đối khó xác định các vấn đề trong phương pháp này
Được bắt đầu với đặc tả module Được bắt đầu với các đặc tả giao diện
Ví dụ kiểm thử đơn vị: Hàm tinh_Tong(a, b) tính tổng của hai số a, b Để kiểm tra hàm này ta viết bộ kiểm thử đơn vị ba trường hợp:
- Test số nguyên dương: kiểm tra hàm tính tổng của 2 và 3, kết quả phải là 5
- Test số âm và số dương: Kiểm tra hàm với -1 và 1 kết quả phải là 0
- Test số thập phân: kiểm tra hàm với 0.1 và 0.2, kết quả bằng 0.3
Ví dụ về Test case trong kiểm thử tích hợp Cho ứng dụng có ba module: Đăng nhập, Hộp thư và Xoá Email
1 Kiểm thử liên kết giao diện giữa
module Đăng nhập và module
Hộp thư
Nhập thông tin đăng nhập và click vào nút Đăng nhập
Được chuyển đến hộp thư
2 Kiểm thử liên kết giao diện giữa
module Hộp thư và module Xoá
thư
Từ Hộp thư chọn email
và click vào nút xoá
Email đã xoá sẽ xuất hiện trong thư mục Đã xoá hoặc Thùng rác
Trang 4Câu 5: Phân biệt kiểm thử hộp đen, kiểm thử hộp trắng Lấy ví dụ minh họa
- Tập trung vào các yêu cầu cn của pm
- KTV xem phần mềm như là một hộp đen:
Không quan tâm đến cấu trúc và 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 tra
chấp nhậ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 mã chương trình hoặc của một mô hình của mã 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 và đ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 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
VD: Chức năng đnhập dựa trên username
và password, ta chỉ quan tâm đến việc cn
đnhập có hoạt động đúng đắn hay không,
không cần biết cách nó được lập trình
VD: Khi kiểm thử hàm Đăng nhập, ta phải kiểm tra tất cả các trường hợp tiêu biểu và biên của hàm để đảm bảo rằng tất cả các đoạn mã đã được thực thi đúng đắn
Câu 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
Là loại kiểm tra đầu cuối và hộp đen Là một loại kiểm tra chức năng
Được thực hiện để đảm bảo rằng hệ thống
đáp ứng các y/c chỉ định của khách hàng
Được thực hiện để đảm bảo sự tuân thủ của
sp với các yêu cầu nghiệp vụ
Được thực hiện sau khi hoàn thành kiểm
thử tích hợp
Được thực hiện sau khi kiểm thử hệ thống
Được thực hiện bởi tester và developer Được thực hiện bởi teser và khách hàng
Có thể là loại thử nghiệm c/n và phi c/n Chủ yếu là loại thử nghiệp chức năng VD: Sau khi hệ thống đã tích hợp các cn:
đnhập, thanh toán, q/lý sp Kiểm thử hệ
thống sẽ k/tra các cn này hoạt động chính
xác và mượt mà khi kết hợp lại với nhau
VD: Người dùng sẽ kiểm tra các tính năng
và cn của hệ thống để xác nhận rằng nó đáp ứng nhu cầu và mong đợi của họ trước khi
hệ thống được triển khai hoặc phát hành
Trang 5Câu 7: Lấy ví dụ về việc xây dựng kế hoạch kiểm thử cho tổng thể? VD: Kiểm thử website:
Bước 1: Phân tích sản phẩm
- Xem xét qua website và tài liệu của sp, đánh giá tài liệu sp giúp ta hiểu tất cả các tính năng của website cũng như cách sdung nó
- Có thể phỏng vấn thêm khách hàng, developer 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ử:
- 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:
o Rủi ro: (1) Thành viên trong nhóm thiếu các kỹ năng cần thiết để kiểm thử website, (2) lịch trình dự án quá chặt, khó để hoàn thành công việc, (3) Test manager có kỹ năng quản lý kém, (4) ước lượng ngân sách sai và vượt chi phí
o Giải pháp: (1) Lập khoá đào tạo, (2) Đặt mức độ ưu tiên cho từng hdong kiểm thử, (3) lập kế hoạch đào tạo l/đạo cho các q/lý, (4) Thiết lập phạm vi trước khi bdau dự án, chú ý nhiều đến việc lập kết hoạch dự án và l/tục theo dõi tiến độ
- Lựa chọn Tester: 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ử (Sử dụng pp Top-Down để xác định các tính năng của website)
- Xác định mục tiêu: Chức năng đăng nhập hoạt động như mong đợi, giao diện đáp ứng nhu cầu của khách hàng, chức năng thuận tiện cho người sử dụng,…
- Tiêu chí tạm dừng: Nếu có 40% test case thất bại, cần tạm dừng kiểm thử cho đến khi nhóm developer sửa tất cả các trường hợp failed
- Tiêu chí kết thúc: Nếu tổng là 120 Testcase, thực hiện 100 TC thì tỷ lệ là 83% Bước 4: Lập kế hoạch nguồn lực: Test Manager có nhiệm vụ quản lý toàn bộ dự án, xác định hướng đi của dự án, có nguồn tài nguyên lớn nhất Tài nguyên được sử dụng là Server Bước 5: Thiết lập môi trường kiểm thử: Số ng dùng tối đa của website là bao nhiêu, yêu cầu phần cứng, phần mềm
Bước 6: Lịch trình và ước lượng: Ví dụ như Tester có nhiệm vụ thực hiện tạo kiểm thử và báo cáo kiểm thử, ước lượng hoàn thành trong khoảng thời gian 80 giờ và 10 giờ
Bước 7: Bàn giao sản phẩm kiểm thử: Bàn giao website cho khách hàng
Trang 6Câu 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
Người
thực
hiện
Nhóm kiểm thử chuyên nghiệp hoặc
nhóm kiểm thử độc lập không liên
quan trực tiếp đến việc phát triển sản
phẩm
Lập trình viên đang phát triển sp
Mục
tiêu
Tập trung vào việc kiểm tra và đánh
giá tính năng, hiệu suất, bảo mật và
các tiêu chí khác một cách toàn diện
Tập trung vào việc kiểm tra các phần tử
cụ thể, hàm, phương thức hoặc module
mà họ đã viết Phạm
vi
Kiểm thử từ góc độ người dùng cuối,
tìm kiếm các lỗi và vấn đề tiềm ẩn mà
nhóm phát triển có thể bỏ sót
Kiểm thử từ góc độ kỹ thuật, tập trung vào việc xác nhận rằng mà nguồn được viết hoạt động theo t/kế và y/cầu
Ví dụ Phát triển một app di động để mua
sắm trực tuyến thì nhóm có thể tập
trung vào việc kiểm tra các tính năng
như đăng nhập, thêm sp vào giỏ hàng,
thanh toán và bảo mật Kiểm tra xem
hiệu suất app khi có nhiều ng dùng
truy cập cùng lúc
Lập trình viên đang viết mã cho cn đăng nhập trong app Sau khi hoàn thành, họ
sẽ thực hiện kiểm thử bằng cách nhập các thông tin đ/nhập (user, pass) và xác nhận xem cn này h/động có đúng như mong đợi hay không Họ cũng có thể tạo các TH kiểm thử để xác minh tính bảo mật và xử lý các TH ngoại lệ
Câu 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
- Môi trường hoạt động: Sản phẩm phần mềm nhúng thường được tích hợp vào phần cứng và hoạt động trong môi trường nhúng, chẳng hạn như thiết bị điện tử, máy móc, hoặc thiết bị y tế
- Tính hệ thống: Kiểm thử không chỉ tập trung vào phần mềm mà còn phải xem xét
sự tương tác giữa phần mềm và phần cứng
- Thách thức về nguồn lực: Các thiết bị nhúng thường có nguồn lực hạn chế về CPU,
bộ nhớ và năng lượng, điều này yêu cầu phải tối ưu hóa và kiểm tra hiệu suất một cách cẩn thận
Ví dụ minh họa: Giả sử bạn đang phát triển phần mềm cho một thiết bị nhúng để điều khiển một hệ thống tưới cây thông minh Bạn cần kiểm tra tính năng điều khiển của thiết bị, đồng thời cũng phải kiểm tra tính năng kết nối không dây và tiết kiệm năng lượng
Trang 7Câu 10: Trình bày phương pháp kiểm thử nhúng trên máy chủ bằng giàn giáo kiểm thử
Giàn giáo kiểm thử là 1 chương trình hay cụm chương trình phần mềm được xây dựng theo khung chức năng đảm bảo môi trường hoạt động như thực tế để tạo ra những tín hiệu, sự kiện, ngắt tác động vào chương trình nhúng kiểm thử
Test Scanffold tương tác đc với các thiết bị ngoại vi: màn hình, bàn phím, đĩa, mạng, giúp chúng ta kiểm thử và gỡ lỗi để có thể xây dựng phần mềm hoàn chỉnh hơn
Hoạt động:
- Mã độc lập vs phần cứng ở Target System và Test System là như nhau và đều từ 1 nguồn
- Mã giàn giáo kiểm thử cung cấp các điểm vào như mã phụ thuộc phần cứng ở máy đích, chúng gọi các c/năng và hàm đúng như mã phụ thuộc phần cứng gọi ở máy đích
- Mã giàn giáo kiểm thử lấy các lệnh từ bàn phím hoặc từ tệp và sản sinh ra kết quả được hiện trên màn hình hoặc ghi vào tệp lưu vết (log file) trên đĩa
Mã giàn giáo ở đây thay cho thiết bị phần cứng và mã phụ thuộc phần cứng của hệ thống đích
Vấn đề đặt ra trong kiểm thử nhúng đó là việc gọi các chương trình ngắt được chương trình nhúng thực hiện Môi trường đích cần thực thi chương trình ngắt tương ứng
và phản hồi lại kết quả cho chương trình nhúng Do đó, trong giàn giáo kiểm thử chúng ta cần chia chương trình ngắt thành hai phần: liên quan đến xử lý và tương tác với phần cứng, liên quan đến tương tác với phần còn lại của hệ thống
Câu 12: Các loại kiểm thử trong kiểm thử hộp trắng hay được thực hiện trong kiểm thử
nhúng?
- Kiểm thử đơn vị: cần viết các stubs để tạo môi trường như thật cho kiểm thử từng đơn vị, có thể tích hợp vào giàn giáo kiểm thử
- Kiểm thử hồi quy: áp dụng như kiểm thử phần mềm thông thường
- Kiểm thử chức năng: nên được thiết kế sớm, ngay khi xây dựng đặc tả yêu cầu
- Kiểm thử độ bao phủ: được thực hiện khi việc lập trình đã xong hoặc về cơ bản đã hoàn tất Thường thì kiểm thử độ bao phủ được tiến hành sau kiểm thử chức năng nhưng ở mức kiểm thử tích hợp thì hai loại kiểm thử này nên kết hợp với nhau
Trang 8Câu 11: Trình bày phương pháp kiểm thử nhúng bằng bộ mô phỏng tập lệnh
- Bộ mô phỏng tập lệnh là công cụ phần mềm chạy trên máy chủ và mô phỏng những hành vi của bộ vi xử lý, bộ nhớ và những thiết bị được gắn theo CPU của máy đích
- Đầu vào của bộ mô phỏng là chương trình đích dạng hợp ngữ hoặc ngôn ngữ máy đích
- Bộ mô phỏng thực hiện chương trình máy đích đúng như máy đích có thật để chúng
ta có thể quan sát và đánh giá chương trình nhúng Qua mô phỏng chúng ta có thể quan sát thực hiện chương trình đích và thiết lập các điểm kiểm tra (checkpoints); khảo sát dữ liệu biến đổi thế nào trong bộ nhớ, trên thanh ghi; giám sát từng bước thực thi từng lệnh trong mã máy đích
Các tính năng của bộ mô phỏng tập lệnh:
- Xác định thời gian hồi đáp và khả năng thông dòng của phần mềm nhúng: bộ mô phỏng cho biết thời gian thực hiện chương trình nhúng là bao nhiêu chu trình đồng
hồ, từ đó ta biết được thời gian hồi đáp khi nhân số chu trình đồng hồ với tần số đồng hồ của CPU máy đích
- Kiểm thử mã hợp ngữ: đầu vào là chương trình sinh chương trình dịch chéo sinh ra
ở dạng mã hợp ngữ máy đích Sử dụng bộ mô phỏng chúng ta có thể kiểm thử các đoạn chương trình ngắn viết trên hợp ngữ nhằm đảm bảo tốc độ hồi đáp và tối ưu khi viết trên C/C++
- Giải quyết những vấn đề khả chuyển: Việc thực hiện thành công chương trình nhúng trên bộ mô phỏng sẽ giúp cho việc chuyển sang máy đích thật thuận lợi và tiết kiệm được nhiều thời gian phát triển và gỡ lỗi trên máy đích thật
- Kiểm thử mã xử lý tương tác với các thiết bị ngoại vi kèm theo trong bộ vi xử lý: Phần lớn các bộ mô phỏng cũng thực hiện mô phỏng các thiết bị được kèm theo CPU của máy đích như ROM, RAM
Các vấn đề không được giải quyết bởi bộ mô phỏng:
- Lỗi chia sẻ dữ liệu: CPU chỉ thực hiện những gì mà các câu lệnh chỉ thị cho nó, còn
nd dữ liệu và tính đúng đắn của dữ liệu thì do người lập trình phải tự đánh giá
- Các thiết bị phần cứng khác: Bộ mô phỏng chỉ thực hiện mô phỏng CPU và những thiết bị được gắn theo như RAM, ROM, bộ đếm thời gian, vv… Còn các thiết bị khác như thiết bị cảm biến, mạch chuyên dụng, vv… thì bộ mô phỏng chưa thể giúp chúng ta mô phỏng tương tác với CPU
- Chú ý: Bộ mô phỏng chú yếu dùng để đánh giá (tính năng, khả năng hồi đáp, …)
và hỗ trợ gỡ lỗi Giàn giáo kiểm thử dùng để gỡ lỗi và kiểm thử
Trang 9Câu 13: Các loại kiểm thử trong kiểm thử hộp đen hay được thực hiện trong kiểm thử
nhúng?
- Kiểm thử độ căng (stress test): kiểm thử sức chịu đựng của phần mềm nhúng với các giá trị vượt ngưỡng quá cao hoặc quá thấp, khả năng chịu đựng của các bộ đệm của bộ nhớ và các kênh vào/ra, sức tải của mô-đun truyền thông, vv…
- Kiểm thử giá trị biên: với các trường dữ liệu có miền xác định thì cần kiểm thử với chính giá trị gần biên, đúng biên và ngoài biên xem hệ thống nhúng có phản ứng và
xử lý như thiết kế không
- Kiểm thử ngoại lệ: kiểm thử xem hệ thống nhúng có kích hoạt thông báo hay hỏng hóc hay phải xử lý ngoại leejhay không
- Kiểm thử đoán lỗi: Kiểm thử dựa trên kinh nghiệm của kiểm thử viên hoặc dựa trên các kiểm thử phần mềm tương tự
- Kiểm thử ngẫu nhiên: kiểm thử dạng này dù ít hiệu quả nhưng có ý nghĩa khi kiểm tra độ mạnh của hệ nhúng cũng như kiểm tra hiệu quả của giao diện người dùng
- Kiểm thử tính năng, hiệu năng: Kiểm thử để đánh giá xem tính năng, hiệu năng có nằm trong khoảng thời gian cho phép không, nhất là khả năng hồi đáp và đảm bảo tính thời gian thực
Câu 14: 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?
- Cung cấp thông tin chi tiết: Tester cung cấp thông tin chi tiết và minh họa rõ ràng
về vấn đề mà họ đã phát hiện, bao gồm các bước để tái tạo lỗi và tác động của lỗi
đó đối với hệ thống
- Bàn bạc trực tiếp: Thực hiện cuộc họp hoặc trao đổi trực tiếp giữa tester và developer
để trao đổi, hiểu rõ hơn về quan điểm và tìm ra giải pháp
- Kiểm tra và xác nhận lại: Tester và developer cùng kiểm tra và xác nhận lại vấn đề một cách kỹ lưỡng Có thể yêu cầu một người thứ ba, như Business Analyst, tham gia để có quan điểm trung lập
- Tạo ticket hoặc report: Nếu vấn đề vẫn chưa được giải quyết, tester có thể tạo một ticket hoặc report chi tiết để ghi lại vấn đề và đưa ra lập luận hỗ trợ cho quan điểm của mình
- Chấp nhận và chuyển tiếp: Nếu vấn đề vẫn không được giải quyết, tester cần chấp nhận quan điểm của developer và tiếp tục kiểm thử theo hướng dẫn hoặc yêu cầu mới từ developer
Trong mọi trường hợp, sự hợp tác và trao đổi thông tin một cách rõ ràng và xây dựng là chìa khóa để giải quyết mọi tranh chấp giữa tester và developer và đảm bảo chất lượng của sản phẩm phần mềm
Trang 10Câu 15: 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?
Báo cáo công việc kiểm thử (test report) thường bao gồm những thông tin sau:
- Thông tin cơ bản: Tên dự án, ngày thực hiện kiểm thử, tên người kiểm thử
- Phạm vi kiểm thử: Mô tả các phần tử đã kiểm thử (chức năng, module, tính năng)
- Kết quả kiểm thử: Số lượng test case đã thực hiện, số lượng bug được phát hiện, các bug đã được fix và chưa fix
- Bảng tổng kết: Tình trạng tổng quát của kiểm thử, tỷ lệ bug đã fix và bug chưa fix
- Ghi chú: Các vấn đề, khó khăn và nhận xét từ quá trình kiểm thử
Ích lợi của báo cáo kiểm thử:
- Xác định chất lượng: Đánh giá chất lượng của sản phẩm phần mềm dựa trên số lượng và tính năng của các bug
- Điều chỉnh chiến lược: Giúp quản lý và team định hướng lại chiến lược và nguồn lực kiểm thử
- Báo cáo cho các bên liên quan: Cung cấp thông tin cho các stakeholder để họ có cái nhìn tổng quan về tiến trình và chất lượng sản phẩm
- Dự đoán và ưu tiên: Hỗ trợ việc ưu tiên và xác định những phần cần kiểm thử mạnh
mẽ hơn trong các lần kiểm thử tiếp theo
Báo cáo kiểm thử là công cụ hữu ích để đảm bảo rằng việc kiểm thử được thực hiện đúng, đầy đủ và chất lượng, đồng thời cung cấp thông tin quan trọng cho việc ra quyết định và điều chỉnh trong dự án
Câu 16: Kiểm thử tự động là gì? Ưu nhược điểm của kiểm thử tự động?
Kiểm thử tự động hay còn gọi là Automation testing là một quá trình thực hiện một cách tự động các bước trong một kịch bản kiểm thử
Ưu điểm: Độ tin cậy cao: có tính ổn định cao
- Khả năng lặp: có thể kiểm tra các ca kiểm thử lặp lại nhiều lần
- Khả năng tái sử dụng: một bộ kiểm thử tự động, có thể sử dụng nhiều phiên bản ứng dụng khác nhau
- Thời gian kiểm thử nhanh
- Chi phí thấp: tiết kiệm thời gian và nguồn nhân lực
Nhược điểm:
- Khó mở rộng, khó bảo trì: để cập nhật, chỉnh sửa một ca kiểm thử, yêu cầu rất nhiều công việc như gỡ rối, thay đổi dữ liệu đầu vào, cập nhật mã nguồn…
- Khả năng về bao phủ thấp vì khó ứng dụng, đòi hỏi nhiều kĩ năng lập trình
- Công cụ và nhân lực: cần trả phí công cụ, đôi khi cần công cụ kiểm thử đặc thù nên khó đầu tư phát triển, nguồn nhân lực đạt yêu cầu cũng bị hạn chế