Nhập môn công nghệ phần mềm - Giai đoạn kiểm tra (Testing)

Biết được quitrình kiểm tra phần

mềm

GNGHỆPH GNGHỆPH

HASE

mềm

•Biết được một sốloại test cơbản

MÔN CÔNG MÔN CÔNG

TING P TING P

•Biết được một khái niệm liên quan

NG NH NG NHẬP M ẬP M

TEST TEST

đến testing

BÀI GIẢN BÀI GIẢN

•Biết được côngviệc, côngcụthường

dùng của Tester

TRẦN NGỌC BẢO TRẦN NGỌC BẢO ”KHOA TOÁN KHOA TOÁN --TIN HỌC TIN HỌC ”ĐẠI HỌC SƯPHẠM TP.HCM ĐẠI HỌC SƯPHẠM TP.HCM TRẦN NGỌC BẢO TRẦN NGỌC BẢO ”KHOA TOÁN KHOA TOÁN --TIN HỌC TIN HỌC ”ĐẠI HỌC SƯPHẠM TP.HCM ĐẠI HỌC SƯPHẠM TP.HCM 3

dùng của Te

pdf44 trang | Chia sẻ: Mr Hưng | Lượt xem: 856 | Lượt tải: 0download
Bạn đang xem trước 20 trang nội dung tài liệu Nhập môn công nghệ phần mềm - Giai đoạn kiểm tra (Testing), để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
P H H A S E H A S E • Kiểm tra tất cả các mục khác có cùng chức năng trong hệ thống menu (Toolbar, Listbar, Dialog M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P bar, Context Menu,) • Kiểm tra cùng một chức năng với nhiều vai trò N G N H N G N H Ậ P M Ậ P M T E S T T E S T khác nhau (đối với hệ thống có nhiều người ù B À I G I Ả N B À I G I Ả N d ng) • Kiểm tra tất cả các dữ liệu bắt buộc nhập trong TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM35 các màn hình (hợp lệ/không hợp lệ) • Vai trò Tester H Ầ N M Ề M H Ầ N M Ề M – Kiểm lỗi phần mềm G N G H Ệ P H G N G H Ệ P H H A S E H A S E – Kiểm lỗi bản đóng gói Kiể lỗi tài liệ M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P – m u • User guide N G N H N G N H Ậ P M Ậ P M T E S T T E S T • Installation Guide • Release Notes B À I G I Ả N B À I G I Ả N • Troubleshooting TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM36 Công việc Tester H Ầ N M Ề M H Ầ N M Ề M • – Chuẩn bị môi trường test • Windows XP, 2000, 2003 G N G H Ệ P H G N G H Ệ P H H A S E H A S E • Linux • IE, FireFox, Netscape, Mozilla M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P • Test Database, Test data – Viết test case – Thực hiện test các test case trong từng môi trường N G N H N G N H Ậ P M Ậ P M T E S T T E S T khác nhau – Mô tả Bug và chi tiết các bước để tạo ra bug B À I G I Ả N B À I G I Ả N – Theo dõi quá trình Fix Bug – Báo cáo kết quả test TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM37 • Phần mềm sử dụng Tester H Ầ N M Ề M H Ầ N M Ề M – Web testing • Test Manager Role G N G H Ệ P H G N G H Ệ P H H A S E H A S E • Tester Role – Manual Test (Rational Manual Test, Test Complete) M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P – Automation Test (Rational Functional Test, Test Complete,) L d t ti N G N H N G N H Ậ P M Ậ P M T E S T T E S T – oa es ng – Code Analysis Project Management Tool B À I G I Ả N B À I G I Ả N – • Tester Role – Workflow TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM • Tester role • Testing Tools Tài liệu tham khảo H Ầ N M Ề M H Ầ N M Ề M – – G N G H Ệ P H G N G H Ệ P H H A S E H A S E 01.ibm.com/software/awdtools/tester/functional/features/ index.html?S_TACT=105AGX15&S_CMP=LP – M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P 01.ibm.com/software/awdtools/test/manager/ • Testing Course N G N H N G N H Ậ P M Ậ P M T E S T T E S T – – htt // f t / d t / i d t t ht l B À I G I Ả N B À I G I Ả N – p: www.appper ec .com pro uc s w n ows es er. m – do TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM39 HẦ N M Ề M H Ầ N M Ề M G N G H Ệ P H G N G H Ệ P H H A S E H A S E M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P N G N H N G N H Ậ P M Ậ P M T E S T T E S T B À I G I Ả N B À I G I Ả N TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM40 40 HẦ N M Ề M H Ầ N M Ề M G N G H Ệ P H G N G H Ệ P H H A S E H A S E M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P N G N H N G N H Ậ P M Ậ P M T E S T T E S T B À I G I Ả N B À I G I Ả N TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM HẦ N M Ề M H Ầ N M Ề M G N G H Ệ P H G N G H Ệ P H H A S E H A S E M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P N G N H N G N H Ậ P M Ậ P M T E S T T E S T B À I G I Ả N B À I G I Ả N TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM42 • White Box Testing are tests that are run an application with the knowledge White Box Testing H Ầ N M Ề M H Ầ N M Ề M of the internal working of the code base. White box testing is used in three of the six basic types of testing: unit, integration, and regression testing. Unit testing is done on a small piece, or unit, of code. This unit is usually a class. When a unit is integrated into the main code base, it is more difficult G N G H Ệ P H G N G H Ệ P H H A S E H A S E to find a bug in that unit. Integration testing looks at how all components of an application interact. White box integration tests specifically look at the interfaces between the components. Regression testing verifies that modifications to the system have not damaged the whole of the system. M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P Unit tests and integration tests can be rerun in regression testing to verify that modifications to the application work properly. • White box test cases should test different paths, decision points (both true and false decisions), execute loops, and check internal data structures of N G N H N G N H Ậ P M Ậ P M T E S T T E S T the application. Basis path testing, equivalence partitioning, and boundary value analysis are all used to create white box tests. Basis path testing looks at the decision points in the application. Equivalence partitioning divides the set of possible input values into equivalence classes. Only a B À I G I Ả N B À I G I Ả N value from each of the equivalence classes needs to be tested. Boundary value analysis looks at testing around a set boundary. A test case should be made for the boundary value, n, n-1, and n+1. • The goal of white box testing is to cover testing as many of the statements TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM43 , decision point, and branches in the code base as possible. • Black Box Testing treats an application as a black box and only looks at the Black Box Testing H Ầ N M Ề M H Ầ N M Ề M outputs that are produced by specific inputs into the application. The black box tester does not need to understand why the code does what it does, and they should not have access to the source code of the application. Requirements are used to determine the correct outputs of black box testing, and these test cases d t lid t th t th i ht ft i b i b ilt i th t th G N G H Ệ P H G N G H Ệ P H H A S E H A S E are use o va a e a e r g so ware s e ng u , .e. a e application does what the requirements say. • Black box testing checks that required functionality exists and is correct, the interface works properly, data structures behind the interface work properly, the behavior and performance of the system are within proper bounds and that the M Ô N C Ô N G M Ô N C Ô N G T I N G P T I N G P , initialization and termination of the program are correct. Integration, functional and system, acceptance, beta, and regression testing all are forms of black box tests. • A minimal black box test suite should have one test case for every requirement N G N H N G N H Ậ P M Ậ P M T E S T T E S T of the application. To optimize testing beyond this minimal set of tests equivalence partitioning, boundary value analysis, decision tables, and diabolical test cases should be created. Equivalence partitioning divides the set of possible input values into equivalence classes. Only a value from each of the equivalence B À I G I Ả N B À I G I Ả N classes needs to be tested. Boundary value analysis looks at testing around a set boundary. A test case should be made for the boundary value, n, n-1, and n+1. Decision tables looks at all decision points in the program and looks at the results of all decision paths in the scenario. Finally, diabolic tests investigate TRẦN NGỌC BẢO ” KHOA TOÁN -TIN HỌC ” ĐẠI HỌC SƯ PHẠM TP.HCM44 extreme use of the application.

Các file đính kèm theo tài liệu này:

  • pdfse_testing_6839_6222.pdf
Tài liệu liên quan