intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE

Nhập môn Công nghệ phần mềm: Chương 2 - Lương Trần Hy Hiến

Chia sẻ: Lê Quang Sáng | Ngày: | Loại File: PPTX | Số trang:30

122
lượt xem
12
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Nhập môn Công nghệ phần mềm - Chương 2: Các khái niệm cơ bản trong kiểm thử phần mềm trình bày các nội dung: quy trình kiểm tra phần mềm, kế hoạch kiểm tra (Test plan), tình huống kiểm tra (Test case), dữ liệu kiểm tra (Test Data), lỗi (Bug), báo cáo kiểm tra (Test Report), các vai trò của kiểm thử phần mềm.

Chủ đề:
Lưu

Nội dung Text: Nhập môn Công nghệ phần mềm: Chương 2 - Lương Trần Hy Hiến

  1. Kiểm th ử Ph ần m ềm – S o ftware Te s ting Ch ương 2: Các khái niệm c ơ b ản trong kiểm th ử Ph ần m ềm Lương Trần Hy Hiến, Khoa CNTT, ĐH S ư ph ạm 1
  2. Nội dung 2.1. Quy trình kiểm tra phần mềm 2.2. Kế hoạch kiểm tra (Test plan) 2.3. Tình huống kiểm tra (Test case) 2.4. Dữ liệu kiểm tra (Test Data) 2.5. Lỗi (Bug) 2.6. Báo cáo kiểm tra (Test Report) 2.7. Các vai trò
  3. 2.1 Qui trình kiểm thử PM • Kiểm thử thành phần – Kiểm thử của các từng thành phần chương trình; – Thường là trách nhiệm của lập trình viên tạo ra thành phần đó; – Các test được tạo ra từ kinh nghiệm của lập trình viên. • Kiểm thử hệ thống – Kiểm thử một nhóm các thành phần được kết hợp lại để tại ra hệ thống hay hệ thống con; – Trách nhiệm của một đội test độc lập; – Các test được tạo ra dựa trên bản đặc tả hệ thống.
  4. 2.1 Qui trình kiểm th ử PM Bắt đầu Lập kế Phân tích, Chuẩn bị dữ Chạy ứng dụng hoạch test Thiết kế test liệu test với bộ dữ liệu test Test Data/S Test plan Test Case Test Results So sánh kết quả Kết thúc Test Report test với test case
  5. 2.2. Kế ho ạc h kiểm tra (Te s t plan) • Cấu trúc chung của một test plan – Tên project – Danh sách các Module cần test – Ngày bắt đầu, ngày kết thúc – Danh sách các Test case – Nhân sự tham gia – Tài nguyên sử dụng (Servers, Workstations, Printers, …) – Kế hoạch thực hiện (sử dụng Ms Project lập kế hoạch) – …
  6. 2.3. Tình hu ống kiểm tra (Te s t c as e ) • Cấu trúc chung của một test case: – Tên project, module – Màn hình, chức năng – Mã số – Tài liệu tham khảo (SRS) – Mục đích – Dữ liệu test – Mô tả các bước (Test step) – Trạng thái – Ngày tạo – …
  7. Te s t cas e • Ví dụ: kiểm tra màn hình đăng nhập
  8. Te s t cas e • Ví dụ: kiểm tra màn hình đăng nhập – Project: Web testing application – Module: Testing – Màn hình: Đăng nhập hệ thống – Chức năng: đăng nhập – Mã số: TC001 – Dữ liệu test • Username =“hienlth”, pass =“123456” • Username =“admin”, pass =“admin” – Các bước thực hiện kiểm tra
  9. Te s t cas e – Te s t s te p Step  Steps Data Expected result Actual  no results 1 Nhập  Username và ấn  Username = “hienlth” Hiển thị thông báo “Vui lòng  nút OK nhập username và password” 2 Nhập  Password và ấn  Password = “123456” Hiển thị thông báo “Vui lòng  nút OK nhập username và password” 3 Nhập  Username ,  Username = “hienlth” Hiển thị thông báo “Username  password và ấn nút OK Password = “abc” và password không hợp lệ” 4 Nhập  Username ,  Username = “abc” Hiển thị thông báo “Username  password và ấn nút OK Password = “hienlth” và password không hợp lệ” 5 Nhập  Username,  Username = “abc” Hiển thị thông báo “Username  password và ấn nút OK Password = “abc” và password không hợp lệ” 6 Nhập  Username,  Username = “” Hiển thị thông báo “Username  password và ấn nút OK Password = “” và password không hợp lệ” 7 Nhập  Username,  Username = “hienlth” Hiển thị trang chính của user  password và ấn nút OK Password = “123456” “hienlth” 8 Nhập  Username,  Username = “admin” Hiển thị trang chính của user  password và ấn nút OK Password = “admin” “admin”
  10. 2.4. Dữ liệu kiểm tra (Te s t Data) • Te s t Data là g ì? Test Data là b ộ d ữ liệu  được xây dựng để chạy thử các test case. Dữ liệu trong Test Data gồm có hai loại là dữ liệu thường (normal data) và dữ liệu bắt buộc (Initial Data). Xây dựng Test Data là một khâu rất quan trọng trong tiến trình test, vì kết quả test phụ thuộc rất lớn vào dữ liệu trong Test Data.
  11. 2.4. Dữ liệu kiểm tra (Te s t Data) • Initial Data là g ì? Initial Data là các trường dữ liệu dùng để khởi tạo chương trình, bắt buộc cần phải có để hệ thống có thể làm việc được. Initial Data là một bộ phận của Test Data.
  12. 2.4. Dữ liệu kiểm tra (Te s t Data) • Te s t Data do ai th ực hiện? Test Data thường do Test Leader và Developer xây dựng, sau khi có tài liệu phân tích thiết kế mức chi tiết.  Dữ liệu khởi tạo (Initial Data) là phần bắt buộc cần phải có để hệ thống có thể hoạt động được, thường do lập trình viên tạo lập sau khi hoàn chỉnh từng bộ phận của hệ thống. Test Leader chịu trách nhiệm xây dựng bộ dữ liệu Test Data thông thường. Sau đó, Tester sẽ dùng các dữ liệu này để thực hiện Test Case.
  13. 2.5. Lỗi (Bug) • Cấu trúc chung của Bug: – Tên bug – Mã số, mức độ – Test case tương ứng (nếu có) – Màn hình, chức năng – Dữ liệu – Mô tả các bước thực hiện – Hình chụp màn hình/quay phim các thao tác. – Trạng thái – Ngày tạo – …
  14. 2.5 Bug (tt) Bug và vòng đ ời c ủa bug : - Bug (b ọ): là thu ật ng ữ c ủa nh ững ng ười làm c ông việc kiểm tra ph ần m ềm g ọi các lỗi c ủa ph ần m ềm, là bug. - Vòng đ ời c ủa bug: Là th ời gian c ủa 1 bugs tồn tại từ lúc phát s inh cho tới lúc bug đ ược s ửa.
  15. 2.5 Bug (tt)
  16. Các trạng thái c ủa bug a. NEW. -. Trạng thái này bug m ới đ ược po s t lê n h ệ th ống . Ng ay lập tức Bug zilla s ẽ g ửi mail tới thành viê n liê n quan (De ve lo pe r, PJ Le ade r...) -. Từ Ne w c ó th ế c huy ển qua trạng thái khác : AS S IGNED ho ặc RES OLVED .
  17. Các trạng thái c ủa bug b. AS S IGNED. - Trạng thái này bug đ ược phân c ô ng c ho DEV fix, ở trạng thái này, bug c h ưa đ ược fix. - Từ trạng thái này, c ó th ể c huy ển qua: NEW (c huy ển c ho ng ười khác fix), RES OLVED (đã fix xo ng bug ).
  18. Các trạng thái c ủa bug c . RES OLVED. - Trạng thái này bug đã đ ược fix xo ng . Kết qu ả c ó th ể là FIXED, INVALID, WONTFIX, DUPLICATE, LATER ho ặc REMIND. - Từ trạng thái này, bug c ó th ể c huy ển qua: REOPEN, VERIFIED, CLOS ED ho ặc UNCONFIRMED
  19. Các trạng thái c ủa bug c . RES OLVED (2). - FIXED : Bug đã fix xong. - INVALID : Vấn đ ề không ph ải bug. - WONTFIX : Vì lý do nào đó, bug nào s ẽ không fix. - DUPLICATE : Pos t b ị trùng v ới m ột bug nào đó đã pos t. - WORKSFORME : - LATER : bug tạm ch ưa fix đ ược. - REMIND : Giống LATER.
  20. Các trạng thái c ủa bug d. REOPENED. - Trạng thái này do TESTER/QC c huy ển từ trạng thái RESOLVED s ang. Do fix rồi mà v ẫn b ị lỗi ho ặc gây ra lỗi khác n ữa. - Trạng thái này c ó th ể c huy ển s ang trạng thái RESOLVED ho ặc ASSIGNED.
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

 

Đồng bộ tài khoản
3=>0