Kiểm thử hộp đen là gì? - What is Black box testing?

[Võ Thị Trường An]

Mình đang bắt đầu làm tester, nhưng không biết nhiều về black box testing.
Xin các bạn giúp mình với.
Thanks.

[Nguyễn Thảo]

Bạn có thể hiểu đơn giản về Black-box testing như sau

Black-box testing: là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong được viết ra sao. Phương pháp này thường dùng để test chức năng của chương trình.

[huyen_tr2001]

* Đối với HTML:
Theo H hiểu thì HTML chủ yếu dùng để hiển thị trang web(nội dung và hình ảnh).
--> những lỗi HTML sẽ làm trang web hiển thị không đúng như mong đợi
--> khi nào ta test lỗi liên quan đến HTML? những lỗi đó là gì?
- Theo H thì chỉ khi nào test Web thì những lỗi do HTML mới xảy ra:
VD:
+ Hình ảnh, dữ liệu trên trang web sẽ hiển thị lộn xộn
+ Hình ảnh background sẽ lớn quá cỡ
+ Bể layout ...
Cách test:
- Chạy từng bước để vào UD Web: có thể xảy ra lỗi bể layout, dữ liệu lôn xộn,...
- Chạy UD Web trên những trình duyệt mà khi lập trình đã qui định --> kết quả mong đợi là tất cả các trình duyệt đó đều hiển thị đúng kết quả(layout, background,dữ liệu, ....)
http://www.webdeveloper.com/forum/showt ... p?t=233313
* Đối với XML:
XML đóng vai trò như 1 database, và có thể chuyển dữ liệu từ XML sang HTML hay sang 1 dữ liệu XML khác
Vậy khi nào những lỗi liên quan đến XML xảy ra? và test nó như thế nào?
1. Đối với UD game nhiều màn, khi 1 màn chơi đã vượt qua, người chơi không muốn chơi tiếp mà muốn lưu lại kết quả đó để hôm sau chơi, thì kết quả đó sẽ được lưu ra 1 file XML, và khi test trong trường hợp này theo H thì chỉ test bằng cách là ghi lại kết quả trước khi lưu ra giấy  rồi tiến hành lưu kết quả lại rồi tắt UD rồi thoát ra khỏi tài khoản hay không thoát rồi mở lại UDgame đăng nhập vào tài khoản của mình khi đã lưu kết quả lần trước xem coi có giống với những gì mình ghi chép lại không?
2. Tiến hành test UD game này trên các trình duyệt mà khi code đã quy định, xem kết quả có đúng và giống nhau không?
- Đến đây H có 1 suy nghĩ là vậy 1 UD Web thông thường thì có xảy ra lỗi lien quan đến dữ liệu XML không????? Hi bà con giúp H với!
* Trên đây là những gì mà H nghĩ về Test BlackBox đối với UD viết bằng HTML hay XML, mong bà con góp ý kiến thêm nha! Thanks bà con nhiều nhiều!

[hoangliensonmt]

Theo mình thì Black box Testing không quan tâm hoặc không biết chương trình được viết như thế nào nên việc biết HTML hay không thì không cần thiết.

[tvn]

Các bạn tham khảo thêm back box testing ở đây nhé.

Black box testing

Phương pháp kiểm thử Black box là nghiên cứu xem phần mềm như là một “hộp đen” – không biết gì về hoạt động bên trong của nó. Các phương pháp kiểm thử Black box bao gồm Equivalence partitioning (phân vùng tương đương), boundary value analysis (phân tích giá trị biên), all-pairs testing (kiểm thử tất cả các cặp), fuzz testing (cách test: nhập vào các điều kiện sai hoặc data một cách ngẫu nhiên), model-based testing (Kiểm thử dựa trên model), traceability matrix (các chức năng của chương trình được tạo thành một ma trận, các trường hợp test là sự kết hợp các dòng hoặc các cột có liên quan), exploratory testing (kiểm thử chủ yếu dựa vào kinh nghiệm và khả năng focus vào việc test các chức năng của tester) và specification-based testing (kiểm thử dựa vào chức năng).

Phương pháp kiểm thử dựa vào chức năng - Specification-based testing: Việc kiểm thử được tiến hành dựa vào việc kiểm thử chức năng của phần mềm xem nó có phù hợp với yêu cầu của người dùng hay không. Vì vậy, các tester nhập data vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục tiêu test. Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test, khi test, đơn giản chỉ cần thực hiện theo các bước mô tả trong test case thao tác và nhập data vào, sau đó xem kết quả trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đợi đã được viết trong test case, điền kết quả test vào test case là OK (OK = is – chương trình làm đúng theo mong đợi) hay NG (not good = is not – chương trình không làm đúng theo mong đợi).

Specification-based testing là cần thiết, nhưng nó không đủ để bảo đảm chắc chắn các rủi ro xảy ra (nó chỉ là điều điện cần chứ không phải là điều kiện đủ).

Ưu điểm và nhược điểm: Các tester kiểm thử theo phương pháp black box không có “mối ràng buộc” nào với code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi. Sử dụng nguyên tắc, "Hỏi và bạn sẽ nhận" các tester black box tìm được nhiều bug ở nơi mà các DEV không tìm thấy. Mặt khác, việc kiểm thử black box được xem như "là bước đi trong mê cung tối đen mà không mang đèn pin” bởi vì tester không biết phần mềm đang test đã được xây dựng như thế nào. Như là một kết quả, ở đây có nhiều trường hợp khi một tester viết rất nhiều trường hợp test để kiểm tra một số thứ có thể chỉ được test bằng một trường hợp test (1), và/hoặc một vài phần cuối cùng không được test hết.

Vì vậy, black box testing có ưu điểm là "an unaffiliated opinion" (một quan điểm độc lập), mặt khác, nó có nhược điểm là "blind exploring" (khám phá mù).

[trongnhantvu]

Tại sao các lập trình viên thường hay bắt đầu công việc lập trình quá sớm, khi chưa hoàn tất việc thiết kế hệ thống và modun. Những vấn đề nảy sinh?

[tvn]

Tại sao các lập trình viên thường hay bắt đầu công việc lập trình quá sớm, khi chưa hoàn tất việc thiết kế hệ thống và modun. Những vấn đề nảy sinh?

Không thể bắt đầu code khi chưa có tài liệu thiết kế. Có thể là do thiết kế chưa tốt nên phải thay đổi.

Theo mình thì việc thiết kế hệ thống và các module sẽ hoàn thiện dần trong quá trình phát triển phần mềm (thay đổi thiết kế liên tục trong quá trình code và test).
Nếu là thiết kế tốt thì sẽ hạn chế được sự thay đổi này. Không có dự án nào mà không phải mất thời gian cho việc thay đổi thiết kế => thay đổi code => và test lại.

[trongnhantvu]

Tại sao lập trình viên phải đặt kế hoạch kiểm thử modun trước khi viết chương trình?

[tvn]

Tại sao lập trình viên phải đặt kế hoạch kiểm thử modun trước khi viết chương trình?

Việc tạo test plan (kế hoạch kiểm thử) là không phải do lập trình viên làm, mà là do QC Leader của dự án lập ra. Sau đó trình lên cho Projet Leader hoặc Project Manager xem, trong test plan có mô tả phạm vi, chức năng nào sẽ phải test, phần nào sẽ không test, chức năng nào cần phải test cái gì - ví dụ test giao diện, chức năng, hiệu năng,...

Đó chỉ là test plan.

Sau đó sẽ phải có lịch test (dựa vào lịch code - do Project Leader tạo ra cho các bạn lập trình viên biết mình phải code cái gì, khi nào bắt đầu, khi nào kết thúc)

QC sẽ làm theo lịch test (có thể không cần biết nội dung của test plan), công việc của QC có thể bị gián đoạn phụ thuộc vào tiến độ của DEV (lập trình viên)

[nguyenxinhdn]

mới học test buổi đầu, bài này xọ bài kia, đọc xong nhức 2 con mắt dễ sợ, không biết đến bao giờ mới làm được tester nữa