Bài giảng Software testing: Chương 2 - ThS. Nguyễn Quốc Huy

Đại học Sài Gòn

Bài 2 Qui trình kiểm thử

ễ 1 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Quy trình kiểm thử

 Test Plans và Test Cases  Regression và Kiểm thử chức năng mới  Tiêu chuẩn bắt đầu/kết thúc kiểm thử  Kiểm soát Phiên bản  Theo vết lỗi

ễ 2 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử

Test Plans và Test Cases  Kế hoạch kiểm thử là tài liệu mô tả các hoạt động kiểm

thử theo kế hoạch. Đối với dự án lớn, có thể chia thành nhiều kế hoạch con.

 Test case là danh sách các bước để kiểm thử tình huống

nào đó. Không nên dài quá 1 trang. Phải có phần pass/fail.

 Thông thường người ta dùng ma trận test case trong kế hoạch kiểm thử để xác định sự kết hợp/hoán vị các điều kiện sẽ được kiểm.

ễ 3 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử:Test Plans

Phần nhận dạng – Tên / Số hiệu • Giới thiệu – Mô tả vắn tắt sản phẩm & chiến lược kiểm thử • Các mục kiểm thử – Mô tả các mục được kiểm • Chi tiết kiểm thử - Liệt kê • Chi tiết không kiểm thử – Cần phải liệt kê, các giả định ngăn ngừa • Hướng tiếp cận – Mô tả chiến lược kiểm thử • Tiêu chuẩn pass/fail – Phải có tiêu chuẩn pass/fail criteria khi kiểm • Tiêu chuẩn đình chỉ và các yêu cầu bắt đầu lại – (tiêu chuẩn Entry / Exit) • Kết quả kiểm thử – Biểu đồ thực hiện, danh sách bug, biểu đồ bug • Các công việc kiểm thử • Cần môi trường gì – Thiết lập Lab • Trách nhiệm – Xác định rõ & đồng thuận • Yêu cầu nhân viên và huấn luyện – Huấn luyện tiếp, cho tương lai • Lịch trình – Thời gian thực hiện test cases và thời gian phần mềm ổn định • Rủi ro/điều không đoán trước – Xác định rủi ro trong thực tế • Phê duyệt – Người quản lý, đội ngũ khách hàng

ễ 4 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử: Test Plans

Mốc thực hiện:

• Duyệt kế hoạch kiểm thử • Bắt đầu công việc • Hoàn thành kịch bản • Bắt đầu kiểm thử • Kết thúc kiểm thử • Kịch bản được chuyển giao để kiểm ngẩu nhiên.

ễ 5 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử: Test Plans

ễ ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16 6

Qui trình kiểm thử: Test Plans

Ước lượng lịch trình là khó! • Có lịch trình đích (thực hiện hết khả năng dựa trên kinh nghiệm trước đó) • Khi 75% lịch trình trôi qua, chốt lại ngày hoàn thành kiểm thử, nhưng mà phải chú ý đến tiến trình. • Lưu vết những điều xảy ra trong dự án, vì vậy ta có thể ước tính chính xác lịch trình cho dự án tiếp theo.

ễ 7 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử:Test Cases

•Phần nhận dạng – Tên / Số hiệu • Người sở hữu Test case – Ai viết? Ai chịu trách nhiệm cập nhật? • Mục được kiểm – Mô tả • Xác định đầu vào/ đầu ra • Tiêu chuẩn pass/fail – Phải có tiêu chuẩn pass/fail cho test case • Tự động hoá – Có thể tự động không? Phải tự động? Chỉ ra file. •Công việc kiểm thử – dưới 1 trang • Môi trường cần – Thiết lập Lab • Yêu cầu thủ tục đặc biệt • Các phụ thuộc Inter-case • Độ ưu tiên Test case – có thể thay đổi, phụ thuộc nhiều yếu tố • Lưu vết phiên bản mà test case này hợp lệ • Lịch trình – Thời gian thực hiện test case – lưu vết thông tin này • Bugs tìm được từ test case – cập nhật mỗi khi tìm thấy bug mới

ễ 8 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử: Test Cases

ấ ấ

ệ ệ

ầ ầ

c yêu c u. c yêu c u.

ủ ủ

ậ ậ

ọ ọ

ế B t đ u công vi c vi ế B t đ u công vi c vi Đ a test cases cho ng Đ a test cases cho ng

t mã xem.  L y nh n xét c a h .   t mã xem.  L y nh n xét c a h .

ắ ầ ắ ầ ư ư Giúp ngăn ch n bugs t Giúp ngăn ch n bugs t

t mã. t mã.

ư ư

ử ử

ườ ườ

ệ ệ

ọ ọ

ế ế ự ự Test cases nên đ a đ y đ  thông tin th c hi n ki m th , nh ng  Test cases nên đ a đ y đ  thông tin th c hi n ki m th , nh ng  i có th  th c hi n.  Nên có  i có th  th c hi n.  Nên có

ộ ế ộ ế

ượ t test cases khi l y đ ượ t test cases khi l y đ ấ ườ ế i vi ấ ườ ế i vi ừ ặ ừ  khi vi ặ  khi vi ủ ầ ư ể ệ ủ ầ ư ệ ể ể ự ế ể t đ  cho m i ng không quá chi ti ể ự ế ể t đ  cho m i ng không quá chi ti ẩ ự ự đ  bi n thiên và s  ng u nhiên trong test case. ẩ đ  bi n thiên và s  ng u nhiên trong test case.

ễ 9 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Test Cases d Test Cases d

ươ ươ ứ ứ

ự ự

ư ư

ệ ệ

ầ ầ

Qui trình kiểm thử: Test Cases ng:  ng:  Th c hi n ch c năng nh  yêu c u. Th c hi n ch c năng nh  yêu c u.

Test Cases âm: Test Cases âm:

ợ ợ

ị ị

Tr Tr

ắ ườ ng h p b  ng t ắ ườ ng h p b  ng t ạ

ữ ữ

ư ư

ộ ộ

ớ ớ

ạM ng: Disconnected, No Ports available… M ng: Disconnected, No Ports available… Đĩa l u tr : File not found, File in use, Disk Full, Invalid Path, CRC error Đĩa l u tr : File not found, File in use, Disk Full, Invalid Path, CRC error B  nh : Not enough free memory, fragments too small… B  nh : Not enough free memory, fragments too small…

ệ ệ

ươ ươ

ướ ướ

ự ự

ệ ệ

Th c hi n testcases d Th c hi n testcases d

ng tr ng tr

c, sau đó th c hi n test cases  c, sau đó th c hi n test cases

ự ự âm.âm.

ễ 10 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử

 Test Plans và Test Cases  Regression và Kiểm thử chức năng mới  Tiêu chuẩn bắt đầu/kết thúc kiểm thử  Kiểm soát phiên bản  Lưu vết lỗi

ễ 11 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử

ứ ứ

ể ể ớ ớ

ớ ể  Ki m ch c năng m i:  Ki m ch c năng  Ki m ch c năng m i:  Ki m ch c năng  ể ớ ướ ớ ượ ướ ớ ượ c m i đ c m i đ

ứ ứ c thêm vào so v i chu kì tr c thêm vào so v i chu kì tr

ể ể

ứ ứ

ẫ ẫ

ứ ứ

ạ ể  Ki m Regression:  Ki m l ạ i ch c năng  Ki m Regression:  Ki m l ể i ch c năng  ả ể ả “cũ”  ng u nhiên đ  đ m b o không có  ả ể ả “cũ”  ng u nhiên đ  đ m b o không có  ị ỏ ị ỏ ch c năng nào b  h ng ch c năng nào b  h ng

ễ 12 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử

ể ể ầ ầ

ệ ệ

ườ ườ

ứ  Ki m ch c năng m i:   ứ Ki m ch c năng m i:   Ph n trăm kh i l Ph n trăm kh i l

ớ ớ ố ượ ố ượ ng công vi c th ng công vi c th

ng ít ng ít

ỗ ỗ

ứ ứ ồ ự ồ ự

ễ ễ

ể ể

ể  Ki m Regression:   ểKi m Regression:   ệ ố ượ ệ ố ượ ng công vi c tăng khi m i ch c năng  Kh i l ng công vi c tăng khi m i ch c năng  Kh i l ụ ế ớ ụ ế ớ m i thêm vào; d  tiêu th  h t ngu n l c ki m  m i thêm vào; d  tiêu th  h t ngu n l c ki m  thửthử

ễ 13 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử Độ ưu tiên của kiểm Regression

1.1.

ự ự

ự ượ ự ượ

ử ử

ư ư

c s a ch a c s a ch a

2.2.

3.3.

ể ể ể ể ể

ệ ệ

ả ả

ưở ưở

Ki m tra bug đó th c s  đ Ki m tra bug đó th c s  đ ểKi m tra các bug liên quan Ki m tra các bug liên quan ử Ki m tra vi c s a là không  nh h ử Ki m tra vi c s a là không  nh h

ng cái gì khác ng cái gì khác

Testing Computer Software, Kaner, Falk, Nguyen Testing Computer Software, Kaner, Falk, Nguyen

ễ 14 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử

 Test Plans và Test Cases  Regression và Kiểm thử chức năng mới  Tiêu chuẩn bắt đầu/kết thúc kiểm thử  Kiểm soát phiên bản  Lưu vết lỗi

ễ 15 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử

 Tiêu chuẩn bắt đầu/kết thúc

ễ ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16 16

Qui trình kiểm thử

Tiêu chuẩn bắt đầu kiểm thử  Danh sách các chức năng đã định nghĩa & hoàn thành  Hoàn thành kiểm tra mã, tài liệu  Việc phân tích tĩnh hoàn thành  Tài liệu người dùng bản nháp sẵn sàng  Hoàn thành Unit test

Xem chuẩn có đạt không?

Nếu có, thì thực hiện đúng thời hạn. Nếu không, sẽ thực hiện trễ hạn.

Đo số lượng và mức độ nghiêm trọng của bug tìm thấy từ khi bắt đầu:. Nếu bugs vượt quá giới hạn, thì sẽ trả lại sản phẩm, việc kiểm thử sẽ trễ hạn.

ễ 17 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử Tiêu chuẩn kết thúc  Sản phẩn có an toàn cho người dùng, tính chất

và dữ liệu? (“Đầu tiên, không gây hại”)

 Toàn bộ các thành viên trong đội test phải đồng

ý?

 Kiểm thử: Ít nhất 1 chu kì kiểm thử đầy đủ có

>75% tỷ lệ pass

 Kiểm Regression hoàn thành, >90% tỷ lệ pass  Hoàn thành việc phân tích kiểm mã, >70% nắm

bắt được mã

 Không còn bug nào được mở  Hoàn thành việc kiểm tra cuối cùng bugs đã mở

ễ 18 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử Chuyển giao công việc  Kịch bản kiểm thử tự động  Kế hoạch kiểm thử phiên bản cuối, test cases,

test scripts

 Số lượng lỗi, kết luận  Xong các báo cáo kiểm tra  Kiểm tra tài liệu hướng dẫn người dùng  Huấn luyện hỗ trợ khách hàng

ễ 19 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử

Một lời khuyên…

Đừng “đốt thời gian ban đầu” để chờ sản phẩm hoàn hảo, hoàn thành 100% mới kiểm. Bắt đầu ngay khi có thể.

Viết mã xong

Kiểm xong

Bắt đầu viết mã

Bắt đầu kiểm

Bắt đầu kiểm chính thức

ễ 20 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử

 Test Plans và Test Cases  Regression và Kiểm thử chức năng mới  Tiêu chuẩn bắt đầu/kết thúc kiểm thử  Kiểm soát phiên bản  Lưu vết lỗi

ễ 21 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử: Kiểm soát phiên bản

 Kiểm soát phiên bản kiểm thử khi sản phẩm

chưa xong

 Kiểm thử tập trung vào một nguồn trung tâm cho

sản phẩm

 Kiểm soát phiên bản cho các kế hoạch kiểm, test

cases, test scripts

 Lưu vết những gì đã kiểm trên bất kì phiên bản

phần mềm & phần cứng

ễ 22 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử: Kiểm soát phiên bản

 CVS - Concurrent Versions System  RCS - Revision Control System  Subversion

 Clearcase - Rational Software  PVCS - Merant

ễ 23 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Qui trình kiểm thử

 Test Plans và Test Cases  Regression và Kiểm thử chức năng mới  Tiêu chuẩn bắt đầu/kết thúc kiểm thử  Kiểm soát phiên bản  Lưu vết lỗi

ễ 24 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Lưu vết lỗi

 Thoả thuận mức độ nghiêm trọng của bug, trước khi

dự án bắt đầu.

 Chất lượng đặt hàng đầu – nếu có vấn đề gì, đó là

trách nhiệm của bạn khi báo cáo bug.

 Có cuộc họp xét lại bug hàng tuần.

ễ 25 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Lưu vết lỗi

 Bugzilla  GNATS  Debian Bug Tracking System

 Clear DDTS – Rational Software  SilkRadar – Segue Software

http://testingfaqs.org/t-track.html

ễ 26 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Báo cáo Bug  Tên  Mức độ nghiêm trọng  Đầu vào  Kết quả mong chờ  Kết quả thực  Quan sát các bất thường  Thông tin bug: Error logs, debug traces  Ngày và giờ  Các bước tìm ra bug  Môi trường  Người kiểm  Người giám sát  Phiên bản cuối cho pass

ễ 27 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Báo cáo Bug

 Tên bug là quan trọng nhất khi báo cáo

– phải rõ ràng và chính xác!

 Tìm cách bẩy lỗi đơn giản nhất cho bug  Tìm hệ quả nghiêm trọng nhất của bug  Cố gắng xác định nếu bug là phần nổi của tảng

băng

 Luôn luôn cho người viết mã cơ hội debug trong

thời gian thực – sẽ giúp ít tốn thời gian hơn

ễ 28 ố ThS Nguy n Qu c Huy ­ ĐHSG 07/04/16

Thống kê

Bug Trend

700

600

500

400

300

200

100

0

2 0

2 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

2 0

2 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

3 0

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

1 2

5 0

9 1

6 1

0 3

3 1

7 2

4 2

8 0

5 0

9 1

1 3

4 1

1 1

5 2

9 0

6 0

7 0

2 0

7 2

3 1

0 1

2 2

3 0

7 1

8 2

3 2

0 2

4 0

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

1 1

1 1

2 1

2 1

1 0

1 0

1 0

2 0

2 0

3 0

3 0

4 0

4 0

5 0

5 0

6 0

6 0

7 0

7 0

7 0

8 0

8 0

9 0

9 0

0 1

0 1

1 1

1 1

2 1

ễ 07/04/16 29 ố ThS Nguy n Qu c Huy ­ ĐHSG