ĐỀ TÀI : TÌM HIỂU CÁC PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG CÔNG CỤ KIỂM TRA TỰ ĐỘNG TESTARCHITECT ĐỂ KIỂM THỬ TỰ ĐỘNG CHO ỨNG DỤNG DOLPHIN
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (3.58 MB, 88 trang )
ĐẠI HỌC ĐÀ NẴNG
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA CÔNG NGHỆ THÔNG TIN
Tel. (84-511) 736 949, Fax. (84-511) 842 771
Website: itf.ud.edu.vn, E-mail:
LUẬN VĂN TỐT NGHIỆP KỸ SƯ
NGÀNH CÔNG NGHỆ THÔNG TIN
MÃ NGÀNH : 05115
ĐỀ TÀI :
TÌM HIỂU CÁC PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM VÀ
ỨNG DỤNG CÔNG CỤ KIỂM TRA TỰ ĐỘNG TESTARCHITECT
ĐỂ KIỂM THỬ TỰ ĐỘNG CHO ỨNG DỤNG DOLPHIN
Mã số : 06T2 – 49
06T1 – 67
Ngày bảo vệ : 14 - 15/ 06 /2011
SINH VIÊN : NGUYỄN TÙNG
06T2
NGUYỄN ĐĂNG QUYỀN 06T1
CBHD :
K.S VÕ ĐỨC HOÀNG
ĐÀ NẴNG, 06/2011
LỜI CẢM ƠN
Chúng tôi xin được gửi lời cảm ơn tới các thầy cô trong khoa công nghệ thông
tin trường Đại học Bách Khoa Đà Nẵng và công ty Logigear đã tạo điều kiện và
mang lại những kiến thức quý báu để chúng tôi có thể thực hiện đề tài này.
Xin cảm ơn thầy giáo Võ Đức Hoàng đã tận tình hướng dẫn và chỉ bảo chúng
tôi trong suốt quá trình làm đồ án để chúng tôi có thể hoàn thành tốt đề tài này.
Cuối cùng chúng tôi xin cảm ơn các bạn trong khoa công nghệ thông tin,
những người đã giúp đỡ, chia sẽ những kiến thức, kinh nghiệm, tài liệu…trong suốt
quá trình nghiên cứu thực hiện đề tài.
Chúng tôi xin chân thành cảm ơn!
Nhóm sinh viên thực hiện
Nguyễn Tùng
Nguyễn Đăng Quyền
LỜI CAM ĐOAN
Tôi xin cam đoan :
1 Những nội dung trong báo cáo này là do chúng tôi thực hiện dưới
sự hướng dẫn trực tiếp của thầy Võ Đức Hoàng.
2 Mọi tham khảo dùng trong báo cáo này đều được trích dẫn rõ ràng
tên tác giả, tên công trình, thời gian, địa điểm công bố.
3 Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá,
chúng tôi xin chịu hoàn toàn trách nhiệm.
Nhóm Sinh Viên
Nguyễn Tùng
Nguyễn Đăng Quyền
NHẬN XÉT CỦA CÁN BỘ HƯỚNG DẪN
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
Đà Nẵng ngày … tháng … năm 2011
Cán bộ hướng dẫn
K.s. Võ Đức Hoàng
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
NHẬN XÉT CỦA CÁN BỘ PHẢN BIỆN
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
........................................................................................................................................................................
Đà Nẵng, ngày … tháng … năm 2011
Cán bộ phản biện
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 5
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
TÓM TẮT ĐỒ ÁN
Đồ án gồm những nội dung chính sau:
- Khái quát về kiểm thử phần mềm:
o Khái niệm kiểm thử phần mềm
o Một số phương pháp kiểm thử phần mềm
o Các giai đoạn kiểm thử phần mềm
o Các lỗi thường gặp khi kiểm thử
- Sơ lược về Test Tool và kiểm tra tự động
- Giới thiệu chương trình kiểm thử phần mềm TestArchitect
- Thực hành kiểm thử Ứng dụng web cộng đồng Dolphin bằng công cụ
TestArchitect
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 6
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
DANH SÁCH HÌNH SỬ DỤNG TRONG ĐỒ ÁN
Hình 1: Mô hình thác nước......................................................................12
Hình 2: Mô hình Agile..............................................................................14
Hình 3: Luồng điều khiển của lập trình theo cấu trúc.............................21
Hình 4: Đồ thị chương trình của bài toán tam giác.................................22
Hình 5: Mô hình kiểm thử hộp đen...........................................................23
Hình 6: Kiểm thử theo giá trị biên với một biến a ≤ x ≤ b.......................24
Hình 7: Kiểm thử theo giá trị biên với hai biến x1 và x2.........................25
Hình 8: Kiểm thử theo giá trị biên đầy đủ với 1 biến a ≤ x ≤ b...............25
Hình 9: Kiểm thử theo giá trị biên đầy đủ với 2 biến x1 và x2................26
Hình 10: Kiểm thử theo phân hoạch tương đương - lỗi đơn...................27
Hình 11: Kiểm thử theo phân hoạch tương đương- lỗi kết hợp...............28
Hình 12: Kiểm thử theo phân hoạch tương đương- lỗi đơn đầy đủ........28
Hình 13: Kiểm thử theo phân hoạch tương đương- lỗi kết hợp đầy đủ. . .29
Hình 14: Mối tương quan giữa KTTĐ và chu trình KTPM......................51
Hình 15: So sánh 3 loại kiểm thử.............................................................54
Hình 16 : Mô hình ABT...........................................................................54
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 7
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
MỤC LỤC
LỜI NÓI ĐẦU.................................................................................................10
VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM........................................................11
I.1. Vòng đời phát triển phần mềm............................................................11
I.2. Mô hình thác nước..............................................................................11
I.3. Mô hình Agile:...................................................................................13
TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM.................................................15
II.1.
Kiểm thử phần mềm.....................................................................15
II.1.1.
Khái niệm..............................................................................15
II.1.2.
Lý do cần kiểm thử................................................................15
II.1.3.
Vai trò....................................................................................15
II.1.4.
Mục tiêu................................................................................16
II.1.5.
Lợi ích...................................................................................16
II.2. Các giai đoạn kiểm thử và điểm xác định:........................................16
II.3. Tổng Quan Về Kiểm Thử Phần Mềm...............................................17
II.3.1 Tìm hiểu Testing, QA, QC........................................................17
II.3.2 Nhóm kiểm thử.........................................................................17
II.3.2.1. Mục tiêu.............................................................................17
II.3.2.2. Trách nhiệm của Tester......................................................17
II.3.3.
Mục tiêu của kiểm thử...........................................................18
II.3.3.1. Lớp tương đương và phân tích giá trị biên.........................18
II.3.3.2. Thiết kế kiểm thử...............................................................18
II.3.4. Các phương pháp kiểm thử.......................................................18
II.4.
Các giai đoạn kiểm thử...................................................................31
II.4.1.
Kiểm thử đơn vị.....................................................................31
II.4.2.
Kiểm thử tích hợp..................................................................31
II.4.3.
Kiểm thử hệ thống.................................................................32
II.4.4.
Kiểm thử thẩm định...............................................................32
ĐỊNH NGHĨA TEST REQUIREMENT (TR) VÀ TEST CASE (TC).............33
III.1.
Test Requirement (TR).................................................................33
III.1.1. Định nghĩa.............................................................................33
III.1.2. Thuộc tính của TR.................................................................33
III.2.
Test case.......................................................................................33
III.2.1. Giới thiệu.................................................................................33
III.2.2. Yêu cầu của test case...............................................................34
III.2.3. Bản chất test case....................................................................34
III.2.4. Cú pháp test case....................................................................34
III.3.
Phương thức kiểm thử và kỹ thuật thiết kế Test case....................35
III.3.1. Phương thức kiểm thử và một vài loại kiểm thử....................35
III.3.2. Một vài kỹ thuật thiết kế test case..........................................36
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 8
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
III.3.2.1.Phân vùng tương đương: (đã tìm hiểu ở chương trên).....37
III.3.2.2. Phân tích giá trị biên: (đã tìm hiểu ở chương trên)......37
III.3.2.3. Điều kiện ràng buộc:...................................................37
III.3.2.4. Quan hệ dữ liệu:..........................................................37
III.3.2.5. Chuyển trạng thái:.......................................................37
III.3.2.6. Điều kiện kết hợp:.......................................................37
III.4.
Các lỗi thường gặp khi kiểm thử..................................................37
III.4.1. Các lỗi dữ liệu vào ra.............................................................37
III.4.2. Các lỗi logic..........................................................................38
III.4.3. Các lỗi tính toán....................................................................38
III.4.4. Các lỗi giao diện....................................................................39
III.4.5. Các lỗi dữ liệu.......................................................................39
ỨNG DỤNG LÝ THUYẾT ĐỂ THIẾT KẾ TEST REQUIREMENTS VÀ
TEST CASE.....................................................................................................40
IV.1. Ví dụ về thiết kế TR và TC cho Gmail web và ứng dụng Evernote.40
IV.1.1. TR và TC cho 1 số chức năng gmail.........................................40
IV.1.2. TR và TC cho ứng dụng Evernote............................................43
IV.2. Ví dụ về Bug và cách viết Bug...........................................................46
SƠ LƯỢC VỀ TEST TOOL.............................................................................50
V.1.
Test Tool.......................................................................................50
V.2.
Kiểm thử tự động.........................................................................51
TÌM HIỂU VÀ GIỚI THIỆU VỀ CÔNG CỤ KIỂM THỬ TỰ ĐỘNG TEST
ARCHITECT...................................................................................................53
VI.1.
Giới thiệu về nền tảng Action Based Testing................................53
VI.1.1. Action based testing là gì ?....................................................53
VI.1.2. Cách làm việc của ABT là gì ?..............................................54
VI.2.
GIỚI THIỆU VỀ TOOL TESTARCHITECT...............................56
VI.2.1. Giới thiệu...............................................................................56
VI.2.2. Chức năng cơ bản..................................................................58
VI.2.2.1.Automation Engineers....................................................60
VI.2.2.2.Software Testers..............................................................60
VI.2.2.3.Managers........................................................................62
VI.2.2.4.Revision Control.............................................................63
VI.2.2.5.Built-In Platform Support...............................................63
VI.2.2.6.Action Recording............................................................64
VI.2.2.7.Control Flow, Variables & Expressions..........................65
VI.2.2.8.Debugging......................................................................65
VI.2.3. Mô hình hoạt động.................................................................66
ỨNG DỤNG TESTARCHITECT ĐỂ KIỂM THỬ ỨNG DỤNG WEB
DOLPHIN........................................................................................................68
VII.1.
Giới thiệu.....................................................................................68
VII.2.
Kiểm thử ứng dụng với TestArchitect..........................................72
Những kết quả nhận được................................................................................87
Hướng phát triển..............................................................................................87
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 9
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
LỜI NÓI ĐẦU
Ngày nay tự động hóa được ứng dụng ở rất nhiều lĩnh vực, mục đích
thường rất đa dạng và tùy theo nhu cầu đặc thù của từng lĩnh vực, tuy nhiên ưu
điểm chung nhất của việc ứng dụng tự động hoá vẫn là giảm nhân lực, thời
gian và sai sót. Ngành công nghệ thông tin nói chung và cụ thể là phát triển
phần mềm cũng không ngoại lệ. Như chúng ta đã biết, để tạo ra một sản phẩm
công nghệ thông tin hay phần mềm có chất lượng thì hoạt động kiểm tra phần
mềm đóng vai trò rất quan trọng, trong khi đó hoạt động này lại tiêu tốn và
chiếm tỷ trọng khá lớn công sức và thời gian trong một dự án. Do vậy, nhu cầu
tự động hoá qui trình kiểm tra phần mềm đã được đặt ra.
Qua thực tế cho thấy việc áp dụng kiểm thử tự động hợp lý sẽ mang lại
thành công cho hoạt động kiểm tra phần mềm. Kiểm thử tự động giúp giảm bớt
công sức thực hiện, tăng độ tin cậy, giảm sự nhàm chán và rèn luyện kỹ năng
lập trình cho kiểm thử viên. Nhận thấy tầm quan trọng đó của kiểm thử phần
mềm trong việc phát triển phần mềm hiện nay, chúng em đã chọn đề tài: “Tìm
hiểu các phương pháp kiểm thử phần mềm và ứng dụng công cụ kiểm tra tự
động TestArchitect để kiểm thử tự động cho ứng dụng Dolphin” làm đề tài
cho đồ án tốt nghiệp. Nội dung đồ án sẽ giới thiệu khái quát về kiểm thử phần
mềm, Test Tool, kiểm tra tự động và giới thiệu một công cụ kiểm tra tự động
khá mạnh hiện nay là TestArchitect của Logigear.
Mặc dù đã có nhiều cố gắng trong quá trình làm bài, nhưng do thời gian
và kinh nghiệm còn hạn chế nên bài làm không thể tránh được thiếu sót, vì vậy
chúng tôi rất mong nhận được sự chỉ bảo của thầy cô và sự đóng góp ý kiến của
các bạn để đồ án được hoàn thiện hơn.
Chúng tôi xin chân thành cảm ơn!
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 10
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
CHƯƠNG I
VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM
I.1.
Vòng đời phát triển phần mềm
Quy trình phát triển phần mềm là tập hợp các thao tác và các kết quả tương
quan để sản xuất ra một sản phẩm phần mềm. Hầu hết các thao tác này được tiến
hành bởi các kỹ sư phần mềm. Các công cụ hỗ trợ máy tính về kỹ thuật phần mềm có
thể được dùng để giúp trong một số thao tác.
Có 4 thao tác là nền tảng của hầu hết các quy trình phần mềm là:
1. Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt
động phải được định nghĩa.
2. Sự phát triển phần mềm: Để phần mềm được đặc tả thì phải có quy trình
phát triển này.
3. Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng
nó làm những gì mà khách hàng muốn.
4. Sự tiến hóa của phần mềm: Phần mềm phải tiến hóa để thỏa mãn sự thay
đổi các yêu cầu của khách hàng.
I.2. Mô hình thác nước
Là 1 mô hình phát triển phần mềm tuần tự.
Chuyển đổi giữa các giai đoạn được thực hiện bằng một đánh giá chính thức.
Đánh giá là một điểm kiểm tra để xác nhận là bạn có đi đúng hướng hay không.
Trong mô hình này giai đoạn test bắt đầu sau giai đoạn code.
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 11
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
Hình 1: Mô hình thác nước
Mô hình này làm cho ý nghĩa việc sản xuất được rõ hơn.
1. Phân tích các yêu cầu và định nghĩa: hệ thống dịch vụ, khó khăn và mục
tiêu được hình thành bởi sự trợ giúp của hệ thống người tiêu dùng. Sau
đó các yếu tố này được định nghĩa sao cho có thể hiểu được bởi cả
người phát triển và người tiêu dùng.
2. Thiết kế phần mềm và hệ thống: Thiết kế hệ thống các quy trình, các bộ
phận và các yêu cầu về cả phần mềm lẫn phần cứng. Hoàn tất hầu như
tất cả kiến trúc của các hệ thống này. Thiết kế phần mềm tham gia vào
việc biểu thị các chức năng hệ thống phần mềm mà có thể được chuyển
đổi thành một hay nhiều chương trình khả thi.
3. Thực hiện và thử nghiệm các đơn vị: Trong giai đoạn này, thiết kế phần
mềm phải được chứng thực như là một tập hợp nhiều chương trình hay
nhiều đơn vị nhỏ. Thử nghiệm các đơn vị bao gồm việc xác minh rằng
mỗi đơn vị thỏa mãn đặc tả của nó.
4. Tổng hợp và thử nghiệm toàn bộ: Các đơn vị chương trình riêng lẻ hay
các chương trình được tích hợp lại và thử nghiệm như là một hệ thống
hoàn tất và chứng tỏ được các yêu cầu của phần mềm được thỏa mãn.
Sau khi thử nghiệm phần mềm được cung ứng cho người tiêu dùng.
5. Sản xuất và bảo trì: Thông thường (nhưng không bắt buộc) đây là giai
đoạn lâu nhất của chu kỳ sống (của sản phẩm). Phần mềm được cài đặt
và được dùng trong thực tế. Bảo trì bao gồm điều chỉnh các lỗi mà chưa
được phát hiện trong các giai đọan trước của chu kì sống; nâng cấp sự
thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ cho là
các phát hiện vê yêu cầu mới.
Chỗ yếu của mô hình này là nó không linh hoạt. Các bộ phận của đề án chia ra
thành những phần riêng của các giai đoạn. Hệ thống phân phối đôi khi không
dùng được vì không thỏa mãn được yêu cầu của khách hàng. Mặc dù vậy mô
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 12
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
hình này phản ảnh thực tế công nghệ. Như là một hệ quả đây vẫn là mô hình cơ
sở cho đa số các hệ thống phát triển phần mềm - phần cứng.
I.3. Mô hình Agile:
I.3.1.
Giới thiệu của mô hình
Phương pháp Agile (phát triển phần mềm linh hoạt) bắt đầu ra đời vào giữa
những năm 90 với mục tiêu là phần mềm có khả năng mở rộng hay tiến hoá
theo thời gian mà không cần phải làm lại từ đầu. Phần mềm này tập trung vào:
Tạo ra một phần mềm đơn giản có thể đáp ứng nhu cầu khách hàng hiện tại và
có khả năng mở rộng, sẵn sàng thay đổi đáp ứng cho nhu cầu trong tương lai.
Phương pháp Agile cố gắng cực tiểu hoá rủi ro bằng cách phát triển phần mền
trong những khung thời gian ngắn. Mỗi bước lặp giống như phát triển một phần
mềm hoàn chỉnh cũng gồm có lấy yêu cầu, làm phân tích thiết kế, code, test,
viết tài liệu. Tuy mỗi bước lặp có thể không bổ sung đủ chức năng để đảm bảo
sự ra đời của sản phẩm cuối cùng, nhưng nó nhằm cho ra đời một sản phẩm
phần mềm mới sau mỗi bước lặp kết thúc. Cuối mỗi bước lặp bất kể kết quả thế
nào, nhóm phát triển cũng đánh giá lại các ưu tiên của dự án.
Phương pháp Agile nhấn mạnh tầm quan trọng của giao tiếp thời gian thực,
giao tiếp mặt đối mặt được đánh giá cao hơn là các tài liệu viết. Hầu hết các đội
phát triển theo kiểu Agile đều được tập trung trong một môi trường có điều
kiện thuận lợi cho việc giao tiếp và các đội này phải bao gồm các lập trình viên
và các khách hàng của họ.
I.3.2.
Đặc điểm của mô hình
-
Chu kỳ giao hàng ngắn. Phát triển rất tập trung
-
Mô hình, uses case, user stories, index card, hay đặc tả chức năng được
sử dụng như tài liệu để test.
-
Dự án thực hiện với mô hình Agile thường có rất nhiều test unit được
thực hiện bởi những người phát triển.
-
Do cấu trúc năng động của mô hình này nên việc phát triển cũng cần sử
dụng phương pháp kiểm thử hồi quy.
-
Mô hình phát triển phần mềm này rất hoan nghênh sự thay đổi cho ứng
dụng đến từ khách hàng.
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 13
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
ITERATION
FEATURES
Plan &
Dev
Evauate
Learn
New Product
Priorized
FEATURE LIST
Hình 2: Mô hình Agile
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 14
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
CHƯƠNG II
TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
II.1.
Kiểm thử phần mềm
1 Khái niệm
Kiểm thử phần mềm là quá trình xác minh và thẩm định động tức là quá
trình thực hiện kiểm tra, kiểm soát ngay khi thực hiện chương trình (thường
làm được khi có mã nguồn của chương trình) để tìm ra các lỗi có thể. Hiện nay
đây cũng là kỹ thuật được phổ biến nhất.
- Kiểm thử phần mềm theo GlenMyers: Là quá trình vận hành chương
trình để tìm ra lỗi.
- Cần vận hành như thế nào để hiệu suất tìm ra lỗi là cao nhất và chi phí
(thời gian, công sức) ít nhất?
II.1.1.
Lý do cần kiểm thử
- Để đánh giá chất lượng sản phẩm
- Để phát hiện ra các vấn đề
- Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này (hiệu
quả)
- Có kế hoạch tốt nâng cao chất lượng cho suốt quá trình phát triển (giải
pháp).
II.1.2.
Vai trò
- Chi phí của kiểm thử chiếm:
40% tổng công sức phát triển
≥ 30% tổng thời gian phát triển
Với các phần mềm có ảnh hưởng tới sinh mạng, chi phí có thể
gấp từ 3 đến 5 lần tổng các chi phí khác cộng lại.
- Kiếm thử tốt sẽ:
Giảm chi phí phát triển
Tăng độ tin cậy của phần mềm
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 15
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
II.1.3.
Mục tiêu
- Cố gắng tạo ra các ca kiểm thử để chỉ ra lỗi của phần mềm được xây
dựng
- Có một chương trình tốt, chi phí ít.
II.1.4.
Lợi ích
- Thuyết minh rằng các chức năng phần mềm tương ứng với đặc tả (xác
minh).
- Yêu cầu thực thi là phù hợp (thẩm định),
- Cung cấp thêm các chỉ số độ tin cậy và chỉ số chất lượng phần mềm
nói chung (thẩm định).
- Tuy nhiên, kiểm thử không thể khẳng định rằng phần mềm không có
khiếm khuyết
II.2. Các giai đoạn kiểm thử và điểm xác định:
Giai đoạn phát triển: là một lượng thời gian trong vòng đời của việc phát
triển phần mềm với một số các hoạt động phải làm trong lượng thời gian này.
Mốc phát triển: Đánh dấu một sự kiện trong tiến trình phát triển phần mềm,
khi phần mềm di chuyển từ giai đoạn này qua giai đoạn khác. Mốc phát triển
này cho chúng ta biết ứng dụng phá triển đang ở vị trí nào trong vòng đời phát
triển của phần mềm
Các giai đoạn kiểm thử và mốc:
Bảng 1
Test
Phase
Thực hiện
Định
nghĩa
Pre- Alpha
Alpha
Beta
GM/Release
Unit
(Đơn vị)
Intergration
(Tích hợp)
System
(Hệ thống)
User
Acceptance
(chấp nhận
sản phẩm)
User
Developer
Developer/
Technical Tester
Kiểm thử một Lặp đi lặp lại 1 hệ
đơn vị code
thống hoàn chỉnh.
trong 1 thời
Kiểm tra các đơn
gian
vị code khi nó
làm việc chung
môi trường với
nhau.
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Tester
Là mức độ
kiểm thử toàn
bộ chức năng
hệ thống. Kiểm
tra như sản
phẩm được đưa
ra sử dụng.
Đánh giá phần
mềm có đáp
ứng được các
yêu cầu của
người dùng đã
đề ra hay
không? Có thể
triển khai cho
công việc thực
Trang 16
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
Kết quả
Mục đích
tế hay không
Ít lỗi
Tìm lỗi
Tìm lỗi/QC
QC
Xác nhận giá Tìm lỗi và biết về Tìm lỗi, xác Xác nhận các
trị các modun sản phẩm, xác nhận giá tri hệ yêu cầu của
độc lập
nhận giá trị các thống, luồng dữ người sử dụng.
yêu cầu tích hợp liệu…
Tùy thuộc vào ứng dụng dự kiến, mà chúng ta sẽ chọn mô hình phát triển phần
mềm cho phù hợp.
Có nhiều giai đoạn trong SLDC. Trong từng giai đoạn, có các mốc và tiêu chí
của từng cột mốc. Tiêu chí, mốc và những giai đoạn giúp phát triển ứng dụng
đúng phù hợp, tiếc kiệm thời gian và hiệu quả cao.
II.3. Tổng Quan Về Kiểm Thử Phần Mềm
II.3.1
Tìm hiểu Testing, QA, QC
-
Testing : Tiến trình thực thi chương trình để tìm ra những thiếu sót của
chương trình.
-
Quality Assurance (QA): Tập hợp các hoạt động được lập ra để đảm bảo
tiến trình phát triển và duy trì là phù hợp để chắc chắn một hệ thống sẽ
đáp ứng các mục tiêu của nó.
-
Quality Control (QC): Tập hợp các hoạt động được tạo ra để đánh giá
sản phẩm đang được tiến hành.
II.3.2
Nhóm kiểm thử
II.3.2.1. Mục tiêu
-
Tìm và viết báo cáo lỗi.
-
Xác định các vùng yếu của chương trình.
-
Xác định các vung nguy cơ cao của chương trình.
-
Giải thích những gì vừa tìm được.
II.3.2.2. Trách nhiệm của Tester
- Tìm những vấn đề .
Tìm lỗi.
Tìm vấn đề về thiết kế.
Tìm nhiều cách hiệu quả để tìm lỗi.
- Vấn đề về giao tiếp.
Báo cáo lỗi và thiết kế lại vấn đề
Báo cáo về tiến trình kiểm thử.
Đánh giá và báo cáo tính ổn định của chương trình.
- Trách nhiệm của quản lý và team leader.
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 17
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
Sửa chữa kế hoạch và lịch trình kiểm thử
Dự toán công việc kiểm thử, thời gian, và tiền của ứng dụng.
Xác nhận và báo cáo tiến trình kiểm thử qua các giai đoạn các cột mốc.
Dạy cho các tester khác để tìm lỗi.
II.3.3.
Mục tiêu của kiểm thử
II.3.3.1.
Lớp tương đương và phân tích giá trị biên
- Lớp tương đương : hai lớp được gọi là tương đương nếu kết quả dự kiến của
hai lớp này là như nhau.
- Biên: Điểm đánh dấu hay vùng chuyển tiếp từ 1 lớp tương đương đến 1 lớp
khác gọi là biên.
Kiểm thử điều kiện biên có ưu điểm vượt trội khi lớp tương đương được sử
dụng.
II.3.3.2.
Thiết kế kiểm thử
Các bước chung:
- Xác định các lớp
-
Xác định giá trị biên
-
Xác định dự kiến đầu vào đầu ra
-
Xác định dự kiến các lỗi với giá trị vào không phù hợp.
-
Tạo bảng kiểm thử.
a.Mục tiêu của kiểm thử
- Mục tiêu của kiểm thử không phải là xác minh chương trình làm việc
đúng.
- Mục tiêu của kiêm thử chương trình là tìm ra các vấn đề trong phần
mềm.
- Mục đích của việc tìm ra vấn đề là để sửa lại chúng cho phù hợp.
b. Bạn không thể kiểm thử mọi thứ , vì thế:
-
Chúng ta tập trung và sử dụng thời gian test để tìm nhiều lỗi nhất có thể.
Chúng ta cần bao phủ hết vùng của ứng dụng với thời gian xác định.
Tìm các lỗi nghiêm trọng 1 cách nhanh nhất có thể.
II.3.4.
Các phương pháp kiểm thử
Hai phương pháp phổ biến:
Kiểm thử hộp trắng (white box)
Kiểm thử hộp đen (black box)
II.3.4.1.
II.3.4.1.1
Kiểm thử hộp trắng
Khái niệm kiểm thử hộp trắng
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 18
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
Kiểm thử hộp trắng (kiểm thử theo cấu trúc) là kiểm thử được thực hiện
trực tiếp trên mã nguồn, khám xét các chi tiết thủ tục; các con đường logic, các
trạng thái của chương trình.
Kiểu kiểm thử này thường sử dụng công thức toán học và lý thuyết đồ
thị và được thực hiện ở cấp độ kiểm thử đơn vị.
vị Việc xác định các trường hợp
kiểm thử không dễ dàng
- Số đường lôgíc là rất lớn. Một chương trình nhỏ:
+ với 100 dòng PASCAL
+ với một vòng lặp
số con đường logic có thể tới: 1014.
cần 3170 năm để kiểm thử tất mọi con đường và
mọi ràng buộc lôgic trên nó!
II.3.4.1.2
Đối tượng kiểm thử hộp trắng
- Cách thức: Sử dụng cấu trúc điều khiển của thiết kế thủ tục để hình
thành các ca kiểm thử
- Kiểm thử cái gì?
Mọi lệnh được thực hiện
Mọi điều kiện được kiểm tra
Mọi chu trình được duyệt qua
Mọi cấu trúc dữ liệu được dùng
Mọi tiến trình được lần vết
II.3.4.1.3
Yêu cầu kiểm thử hộp trắng
- Yêu cầu đặt ra:
+ Mọi con đường độc lập trong một module cần được thực hiện ít nhất một
lần.
+ Mọi ràng buộc logic được thực hiện cả hai phía: phía đúng & phía sai
+ Tất cả các vòng lặp ở biên của nó và cả các biên vận hành phải được thực
hiện.
+ Mọi cấu trúc dữ liệu nội tại được dùng để bảo đảm tính hiệu lực của nó
II.3.4.1.4
Lý do kiểm thử hộp trắng
- Vì sao cần tốn tiền cho kiểm thử hộp trắng?
+ Các lỗi logic & giả thiết không đúng đắn tỷ lệ nghịch với xác suất để
một con đường logic được thi hành.
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 19
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
+ Thực tế: mọi con đường lôgic đều có thể được thi hành trên 1 cơ sở
nhất định (ta cho rằng 1con đường logic nào đó là không thể được thi hành).
+ Có những sai sót chính tả có thể là ngẫu nhiên trên đường ta không
kiểm tra.
II.3.4.1.5
Kiểm thử theo đường dẫn
- Các đường dẫn được xác định bằng việc xây dựng đồ thị chương trình
- Mỗi trường hợp kiểm thử sẽ tương ứng với một đường dẫn
* Đồ thị chương trình:
- Đồ thị chương trình là một đồ thị có hướng trong đó:
+ Mỗi nút (hình tròn) biểu thị một hay một số lệnh tuần tự, hoặc thay
cho điểm hội tụ các đường điều khiển.
+ Mỗi cạnh nối hai nút biểu diễn dòng điều khiển.
Nghĩa là, có một cạnh từ đỉnh i đến đỉnh j nếu câu lệnh tương ứng với
đỉnh j có thể được thực thi ngay lập tức sau câu lệnh tương ứng với đỉnh i
+ Kết quả: đồ thị dòng
Chia mặt phẳng thành nhiều miền.
Có nút vị từ biểu thị sự phân nhánh hoặc hội nhập của các cung.
* Cách xây dựng đồ thị chương trình:
+ IF
+ IF-Then-Else
+ For
+ While
+ Do-While
+ Case
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 20
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
Sequence
ee
If
Then
Pretest
Loop
IfThen
Else
Posttest
Loop
Cas
e
Hình 3: Luồng điều khiển của lập trình theo cấu trúc
Ví dụ: Vẽ đồ thị chương trình của bài toán tam giác có chương trình như
sau:
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 21
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
Hình 4: Đồ thị chương trình của bài toán tam giác
* Kết luận:
Kiểm thử theo đường dẫn dựa vào phương pháp của Tom McCabe được
sử dụng cho cấp độ kiểm thử đơn vị. Nó có nhược điểm là yêu cầu người kiểm
thử phải có kỹ năng lập trình đủ tốt để có thể hiểu được mã nguồn và luồng
điều khiển trong chương trình
II.3.4.2.
II.3.4.2.1
Kiểm thử hộp đen
Khái niệm
- Kiểm thử hộp đen dựa trên việc xem xét một chương trình như là một
hàm ánh xạ miền giá trị dữ liệu vào thành miền kết quả ra
- Còn được gọi là kiểm thử theo chức năng
- Phương pháp kiểm thử này chỉ dựa vào các chức năng trong chương
trình, bỏ qua cấu trúc bên trong của mã lệnh
- Đặc trưng:
+ Nhằm thuyết minh: các chức năng phần mềm đủ & vận hành đúng
+ Thực hiện các phép thử qua giao diện
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 22
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
- Cơ sở: đặc tả, các điều kiện vào/ra và cấu trúc dữ liệu
+ Ít chú ý tới cấu trúc logic nội tại của nó
* Ưu điểm:
Chúng độc lập với cách thức mà phần mềm được cài đặt, vì vậy, nếu ta
thay đổi cách cài đặt thì vẫn có thể sử dụng được các trường hợp kiểm thử,
chúng ta có thể thực hiện kiểm thử song song với quá trình cài đặt phần mềm,
làm giảm thời gian phát triển dự án.
Hình 5: Mô hình kiểm thử hộp đen
* Các kỹ thuật kiểm thử hộp đen:
- Kiểm thử theo giá trị biên
- Kiểm thử theo các lớp tương đương
- Kiểm thử dựa vào bảng quyết định
- Kiểm thử dựa vào đồ thị nguyên nhân-kết quả
II.3.4.2.2
Mục tiêu
- Kiểm thử hộp đen nhằm tìm ra các loại sai:
+ Chức năng thiếu hoặc không đúng đắn.
+ Sai về giao diện.
+ Sai trong cấu trúc hoặc trong truy cập dữ liệu ngoài.
+ Sai thực thi chức năng.
+ Sai khởi đầu hoặc kết thúc module.
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 23
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
- Kiểm thử hộp đen tập trung trả lời các câu hỏi:
+ Hiệu lực chức năng (chức năng, hiệu suất) được kiểm thử đến đâu?
+ Lớp đầu vào nào cho các ca kiểm thử tốt?
+ Sự nhạy cảm của module với giá trị vào nào?
+ Các biên của lớp dữ liệu được cô lập chưa?
+ Dung thứ lỗi đối với các nhịp điệu/khối lượng dữ liệu như thế nào?
+ Tổ hợp dữ liệu đặc biệt ảnh hưởng gì đến hoạt động hệ thống.
II.3.4.2.3
Tiêu chuẩn
Áp dụng kỹ thuật kiểm thử hộp đen, cần tìm ra các ca kiểm thử thoả
mãn các tiêu chuẩn:
+ Rút gọn (ít, đơn giản).
+ Cho biết về sự tồn tại hoặc vắng mặt của một lớp sai (không phải về
một sai cụ thể gắn với một kiểm thử riêng biệt)
II.3.4.2.4
Kiểm thử theo giá trị biên
Khi một hàm chức năng F với hai biến x1 và x2 được cài đặt trong
chương trình, các biến đầu vào x1 và x2 sẽ có các giới hạn:
a<=x1<=b
c<=x2<=d
Các đoạn [a,b] và [c,d] được gọi là các miền giá trị của x1 và x2
Ý tưởng chính của kiểm thử theo giá trị biên là sử dụng giá trị của biến
đầu vào tại giá trị nhỏ nhất, lớn hơn giá trị nhỏ nhất, giá trị thông thường, giá
trị lớn nhất, và nhỏ hơn giá trị lớn nhất
a
b
x
X(min)
X(min+)
X(nom)
X(max-)
X(max)
Hình 6: Kiểm thử theo giá trị biên với một biến a ≤ x ≤ b
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
Trang 24
Tìm hiều về kiểm thử phần mềm và kiểm thử tự động
x2
d
c
a
b
x1
Hình 7: Kiểm thử theo giá trị biên với hai biến x1 và x2
* Kiểm thử theo giá trị biên đầy đủ
- Là một mở rộng của kiểm thử theo giá trị biên bao gồm các giá trị nhỏ
hơn giá trị nhỏ nhất và lớn hơn giá trị lớn nhất (cho phép vượt quá miền giá trị)
- Là một hình thức kiểm thử với lỗi để biết được chương trình sẽ thực
hiện như thế nào nếu dữ liệu vào có lỗi
- Có thể không được áp dụng với một số ngôn ngữ lập trình có ràng buộc
kiểu
a
b
x
Hình 8: Kiểm thử theo giá trị biên đầy đủ với 1 biến a ≤ x ≤ b
x2
d
c
a
Nguyễn Tùng 06T2 – Nguyễn Đăng Quyền 06T1
b
x1
Trang 25
