ĐỀ 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

Tổng hợp và thử nghiệm toàn bộ: Các đơn vị chương trình riêng lẻ haycác chương trình được tích hợp lại và thử nghiệm như là một hệ thốnghoàn tất và chứng tỏ được các yêu cầu của phần mềm

KHOA CÔNG NGHỆ THÔNG TIN

Tel (84-511) 736 949, Fax (84-511) 842 771Website: itf.ud.edu.vn, E-mail: cntt@edu.ud.vn

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

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

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

Đà Nẵng ngày … tháng … năm 2011 Cán bộ hướng dẫn

K.s Võ Đức Hoà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

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

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

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

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

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 đíchthườ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ờigian và sai sót Ngành công nghệ thông tin nói chung và cụ thể là phát triểnphần mềm cũng không ngoại lệ Như chúng ta đã biết, để tạo ra một sản phẩmcông nghệ thông tin hay phần mềm có chất lượng thì hoạt động kiểm tra phầnmề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ạithành công cho hoạt động kiểm tra phần mềm Kiểm thử tự động giúp giảm bớtcô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ănglậ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ầnmềm, Test Tool, kiểm tra tự động và giới thiệu một công cụ kiểm tra tự độngkhá 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ủacác bạn để đồ án được hoàn thiện hơn

Chúng tôi xin chân thành cảm ơn!

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ìnhphá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

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ụctiê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àoviệ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ầnmềm phải được chứng thực như là một tập hợp nhiều chương trình haynhiều đơn vị nhỏ Thử nghiệm các đơn vị bao gồm việc xác minh rằngmỗ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ẻ haycác chương trình được tích hợp lại và thử nghiệm như là một hệ thốnghoà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 rathành những phần riêng của các giai đoạn Hệ thống phân phối đôi khi khôngdù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ô

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ữanhữ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ềntrong những khung thời gian ngắn Mỗi bước lặp giống như phát triển một phầnmề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ẩmphầ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 độiphát triển theo kiểu Agile đều được tập trung trong một môi trường có điềukiệ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 đượcthự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 ứngdụng đến từ khách hàng

- Kiểm thử phần mềm theo GlenMyers: Là quá trình vận hành chươngtrì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?

 ≥ 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

- 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ềmnó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ểnnày cho chúng ta biết ứng dụng phá triển đang ở vị trí nào trong vòng đời pháttriển của phần mềm

Các giai đoạn kiểm thử và mốc:

Intergration (Tích hợp)

System (Hệ thống)

User Acceptance (chấp nhận sản phẩm) Thực hiện Developer Developer/

Định

nghĩa

Kiểm thử mộtđơn vị code trong 1 thời gian

Lặp đi lặp lại 1 hệthống hoàn chỉnh

Kiểm tra các đơn

vị code khi nólàm việc chungmôi trường vớinhau

Là mức độ kiểm thử toàn

bộ chức năng

hệ thống Kiểmtra 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

tế hay không

Mục đích Xác nhận giá

trị các modunđộc lập

Tìm lỗi và biết vềsản phẩm, xácnhận giá trị cácyêu cầu tích hợp

Tìm lỗi, xácnhận giá tri hệthống, luồng dữliệu…

Xác nhận cácyêu cầu của

II.3 Tổng Quan Về Kiểm Thử Phần Mềm

- 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ảotiế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.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

 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

 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ể

 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 Kiểm thử hộp trắng

II.3.4.1.1 Khái niệm kiểm thử hộp trắng

Kiểm thử hộp trắng (kiểm thử theo cấu trúc) là kiểm thử được thực hiệntrự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áctrạ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ị

thị và được thực hiện ở cấp độ kiểm thử đơn vị Việc xác định các trường hợpđược thực hiện ở cấp độ kiểm thử đơn vị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ìnhthà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ộtlầ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ựchiệ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

+ 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ôngkiể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 thaycho đ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

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:

Pre-test Loop

Post-test Loop

If-Then

If-Then-Else

Cas e Sequence

ee

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ểmthử 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 Kiểm thử hộp đen

II.3.4.2.1 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ộthà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ươngtrì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

- 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 tathay đổ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

- 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 trongchươ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

Hình 6: Kiểm thử theo giá trị biên với một biến a ≤ x ≤ b

x

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ựchiệ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ộckiểu

Hình 8: Kiểm thử theo giá trị biên đầy đủ với 1 biến a ≤ x ≤ b

Hình 9: Kiểm thử theo giá trị biên đầy đủ với 2 biến x1 và x2

* Số lượng trường hợp kiểm thử:

- Kiểm thử theo giá trị biên: 4n+1

- Kiểm thử theo giá trị biên đầy đủ: 6n+1

Với n là số lượng các biến

* Nhược điểm của kiểm thử theo giá trị biên

- Các biến phải độc lập với nhau

- Không áp dụng được cho các biến thuộc kiểu logic

II.3.4.2.5 Kỹ thuật phân hoạch tương đương (kiểm thử theo

- Ca kiểm thử được thiết kế cho từng lớp tương đương

* Các trường hợp kiểm thử theo kỹ thuật phân hoạch tương đương:

+ Kiểm thử theo phân hoạch tương đương- lỗi đơn

+ Kiểm thử theo phân hoạch tương đương- lỗi kết hợp

+ Kiểm thử theo phân hoạch tương đương- lỗi đơn đầy đủ

+ Kiểm thử theo phân hoạch tương đương- lỗi kết hợp đầy đủ

* Ví dụ:

- Hãy xem xét một hàm F với các biến đầu vào x1, x2 có giá trị đượcgiới hạn và nằm trong các khoảng sau:

 a<= x1<=d với các khoảng giá trị là [a b), [b c), [c d]

 e<=x2<=g với các khoảng giá trị là [e f), [f g]

 Các giá trị không đúng là x1< a, x1>d and x2<e, x2>g

* Kiểm thử theo phân hoạch tương đương – lỗi đơn (hình 10)

- Sử dụng một biến từ mỗi lớp tương đương (hay một khoảng giá trị)trong một trường hợp kiểm thử

- Dựa trên giả thiết lỗi đơn

- Số lượng trường hợp kiểm thử bằng số lượng nhiều nhất các khoảnggiá trị đúng mà một biến có thể nhận

Hình 10: Kiểm thử theo phân hoạch tương đương - lỗi đơn

* Kiểm thử theo phân hoạch tương đương- lỗi kết hợp

+ Không sử dụng giả thiết lỗi đơn

+ Mỗi trường hợp kiểm thử tương ứng với một phần tử của tích Đề cáccủa các lớp tương đương

Hình 11: Kiểm thử theo phân hoạch tương đương- lỗi kết hợp

* Kiểm thử theo phân hoạch tương đương- lỗi đơn đầy đủ: Xem xét

cả các giá trị không đúng với giả thiết lỗi đơn

Hình 12: Kiểm thử theo phân hoạch tương đương- lỗi đơn đầy đủ

* Kiểm thử theo phân hoạch tương đương- lỗi kết hợp đầy đủ: Xem

xét cả các giá trị không đúng với giả thiết lỗi đơn

Hình 13: Kiểm thử theo phân hoạch tương đương- lỗi kết hợp đầy đủ

II.3.4.2.6 Kiểm thử dựa vào bảng quyết định

Bảng quyết định được dùng để biểu diễn và phân tích các mối quan hệlogic phức tạp

Chúng thường được dùng để mô tả các tình huống mà một số các hànhđộng sẽ được thực hiện khi một số điều kiện nhất định được thoả mãn

* Cấu trúc bảng quyết định gồm 4 phần:

+ Tên điều kiện

+ Giá trị điều kiện

+ Tên hành động

+ Giá trị hành động

Bảng quyết định trong đó các điều kiện chỉ có thể nhận giá trị True hoặcFalse được gọi là bảng quyết định với giá trị giới hạn Nếu các điều kiện có thểnhận nhiều giá trị khác nhau được gọi là bảng quyết định với giá trị mở rộng

* Cách lập bảng quyết định:

- Lập bảng gồm 4 phần: Tên điều kiện, Giá trị điều kiện, Tên hành động,Giá trị hành động

- Dữ liệu vào (input) đóng vai trò là các điều kiện của bảng quyết định

- Dữ liệu ra (output) đóng vai trò là các hành động của bảng quyết định

II.3.4.2.7 Kỹ thuật đồ thị nhân quả

- Đồ thị nhân quả là một kỹ thuật thiết kế ca kiểm thử Nó cung cấp mộtbiểu diễn chính xác các điều kiện logic và các hành động tương ứng.

- Kỹ thuật đồ thị nhân quả gồm 4 bước:

+ Lập danh sách các nguyên nhân (ĐK vào) và kết quả (hành động thựchiện) cho từng module và gán định danh cho chúng

+ Phát triển một đồ thị nhân quả

+ Chuyển đồ thị đó thành bảng quyết định

+ Sử dụng các quy luật của bảng quyết định để xây dựng các ca kiểm thử

* Ngoài hai phương pháp phổ biến trên ta cũng có thể tìm hiểu thêm vềphương pháp kiểm thử hộp xám (Gray – Box Test)

II.3.4.3 Kiểm thử hộp xám (Gray-Box Test)

Kiểm thử hộp xám là sự kết hợp giữa kiểm thử hộp đen và kiểm thử hộptrắng Mục đích của việc kiểm thử này là tìm ra những nhược điểm có liên quantới lỗi thiết kế, hoặc lỗi thi hành của hệ thống

Trong kiểm thử hộp xám, người kiểm thử cần phải có những hiểu biết về

hệ thống và thiết kế các testcase hoặc dữ liệu kiểm thử dựa trên những kiếnthức về hệ thống

Ví dụ, giả sử bạn phải test một ứng dụng web Chức năng của ứng dụng

này rất đơn giản, bạn chỉ cần nhập các thông tin chi tiết về cá nhân bạn nhưemail và các trường quan trọng trên form web và submit form này Server sẽlấy được thông tin này và dựa trên các trường quan trọng thu được và mail tớiemail của bạn Việc xác thực email xảy ra nơi client sử dụng Java Scripts

Trong trường hợp này, không biết chi tiết sự thực thi , bạn phải test formvới những ID hợp lệ/không hợp lệ và các trường khác nhau để chắc chắn chứcnăng đó là đúng

Nhưng nếu bạn biết chi tiết việc thực hiện, bạn biết rằng hệ thống thựchiện các giả định sau:

+ Server sẽ không bao giờ lấy mail không hợp lệ

+ Server sẽ không bao giờ gửi mail tới ID không hợp lệ

+ Server sẽ không bao giờ nhận các khai báo lỗi cho mail này

Với mục đích của kiểm thử hộp xám, trong ví dụ trên bạn sẽ có mộttestcase trên các client, nơi mà Java Scripts không hoạt động Nó có thể xảy ravới bất kỳ lí do nào và nếu nó xảy ra, việc xác thực có thể không thực hiện ởsite client Trong trường hợp này, giả định hệ thống bị xâm phạm và:

+ Server sẽ lấy mail không hợp lệ

+ Server sẽ gửi mail tới những địa chỉ mail không hợp lệ

+ Server sẽ nhận những thông báo lỗi

II.4 Các giai đoạn kiểm thử

- Trừ hệ thống nhỏ nói chung không nên kiểm thử nguyên cả khối, quátrình kiểm thử có thể chia là các giai đoạn: kiểm thử đơn vị, tích hợp, hệ thống

và thẩm định

II.4.1 Kiểm thử đơn vị

Kiểm thử đơn vị tập trung nỗ lực kiểm chứng vào đơn vị nhỏ nhất củathiết kế phần mềm module Bằng việc dùng mô tả thiết kế chi tiết làm hướngdẫn các đường điều khiển quan trọng được kiểm thử và phát hiện ra lỗi trongbiên giới của module

Kiểm thử đơn vị có các nội dung sau :

 Kiểm thử giao diện

 Khám nghiệm cấu trúc dữ liệu cục bộ

 Kiểm thử với các điều kiện biên

- Tích hợp từ trên xuống là cách tiếp cận tăng dần tới việc xây dựng cấutrúc chương trình Các modul được tích hợp bằng cách đi dần xuống qua cấpbậc điều khiển, bắt đầu với module điều khiển chính (chương trình chính)

- Tích hợp từ dưới lên: bắt đầu xây dựng và kiểm thử với các modulenguyên tử (tức là các module ở mức thấp nhất trong cấu trúc chương trình), vìcác module này từ dưới lên nên việc xử lý yêu cầu với các module phụ thuộcvào mức nào đó

- Kiểm thử tích hợp nhằm nhận được một phần hay toàn bộ hệ thốngnhư mong đợi Khi tích hợp các thành phần có thể gặp các sai:

 Dữ liệu bị mất khi đi qua một giao diện

 Hiệu ứng bất lợi 1 module vô tình gây ra đối các module khác

 Sự kết hợp các chức năng phụ có thể không sinh ra chức năngchính mong muốn.

 Sự phóng đại các sai sót riêng rẽ có thể bị đến mức không chấpnhận được

 Vấn đề của cấu trúc dữ liệu toàn cục có thể để lộ ra

II.4.3 Kiểm thử hệ thống

Là một loạt các bước kiểm thử khác nhau có mục đích chính là thử đầy

đủ hệ thống dựa trên máy tính Mặc dù mỗi kiểm thử đều có một mục tiêu khácnhau, tất cả các việc nên kiểm thử lại rằng mọi phần tử hệ thống đều được tíchhợp đúng đắn và thực hiện chức năng được cấp phát

Mỗi giai đoạn kiểm thử đều được thực hiện thông qua một loạt các kỹthuật kiểm thử có hệ thống, đều trợ giúp cho việc thiết kế các trường hợp kiểmthử

II.4.4 Kiểm thử thẩm định

Phần mềm được lắp ráp hoàn toàn thành một chương trình hoàn chỉnh,các lỗi giao tiếp đã được phát hiện, sửa chữa và loạt kiểm thử phần mềm cuốicùng - kiểm thử thẩm định - có thể bắt đầu

Mục tiêu thẩm định: xem phần mềm có đáp ứng được yêu cầu kháchhàng không?

Việc thẩm định có thể được xác định theo nhiều cách, nhưng một địnhnghĩa đơn giản là ở chỗ việc thẩm định thành công khi các chức năng phầnmềm theo một cách thức nào đó chính là cái khách hàng trông đợi một cáchhợp lý

CHƯƠNG III

ĐỊNH NGHĨA TEST REQUIREMENT (TR)

VÀ TEST CASE (TC) III.1 Test Requirement (TR)

Test requirement là một trình bày về những gì cần phải được kiểm thử trongquá trình kiểm thử ứng dụng đó

Yêu cầu chức năng: Yêu cầu về chức năng mà ứng dụng phải làm

Yêu cầu phi chức năng : Yêu cầu về đặc tính mà chức năng phải có hay là

có thể được nhìn thấy Ở đây có 3 loại: Look n feel, Boundary, Negative

 Mục tiêu nền tảng của TR

 Yêu cầu về hệ thống

 Sự mô tả về chức năng

 Dự kiến vùng có vấn đề

Thuộc tính và yêu cầu của TR:

 TR phải được viết ra

 TR phải rõ ràng và đặc trưng

 TR phải hoàn chỉnh

 TR phải chính xác

 TR phải phù hợp và nhất quán

 TR phải có dộ ưu tiên

 TR không được tối nghĩa

 TR có thể xác minh được

 TR phải xúc tích

 TR dung ngôn ngữ phải hiểu được

Tài liệu của 1 ứng dụng gồm có 3 loại: yêu cầu, đặc tả kỹ thuật, và thiết kế

1 TR có thể được viết như 1 user story hay từ nguồn khác của phần mềm.Người kiểm thử có thể sử dụng TR để thi hành, cài đặt test case

III.2 Test case

III.2.1 Giới thiệu

Định nghĩa: Là 1 tình huống kiểm tra, được thiết kế để kiểm tra 1 đối tượng

có thoả yêu cầu đặt ra hay không

Mục đích của test case:

- Tạo sự tin tưởng

- Thực thi lặp để tạo kết quả

- Lưu trữ kết quả test từ testcases

- Tự động

- Để tìm lỗi

- Để xác định rằng kiểm thử đang thực hiện đúng

- Sử dụng như công cụ để training kiểm thửu viên mới

- Xác nhận kiểm thử bao phủ

III.2.2 Yêu cầu của test case

- Phải có khả năng băt được lỗi

- Không được quá đơn giản cũng không được quá phức tạp

- Không thừa

- Làm cho sự sai lệch của chương trình trở nên rõ ràng

* 1 test case tốt:

Nhận biết được đối tượng đang kiểm thử

Có tiêu chí đánh giá pass hay fail

Phải chi tiết để bất cứ tester nào với những hiểu biết về hệ thống có thể thựchiện được test case này

* 1 test case không tốt:

Để người dung tự tìm dữ liệu test

Đưa ra những ý tưởng quá cao

Không xem xét như 1 người kiểm thử có kinh nghiệm

Đưa ra những bước khó xác định pass hay fail

III.2.3 Bản chất test case

Những thứ quan trọng trong 1 test case:

III.2.4 Cú pháp test case

Hành động + Chức năng + Điều kiện

Chức năng có thể là : chức năng, tính năng, điểm xác định

Điều kiện có thể là dữ liệu

Hành động :

Điểm xác định là là dự kiến kết quả.

Nó phải được viết ra

III.3 Phương thức kiểm thử và kỹ thuật thiết kế Test

case

Tìm hiểu một vài loại kiểm thử

- Kiểm thử yêu cầu (Requirement testing)

- Kiểm thử thăm dò (Exploratory)

- kiểm thử smoke (Smoke testing)

- Kiểm thử hồi quy (Regresstion)

Test case:

- Tiêu chuẩn test case

- Bản chất test case

- Cú pháp test case

Một vài kỹ thuật thiết kế test case:

- Phân vùng tương đương

- Phân tích giá trị biên

III.3.1 Phương thức kiểm thử và một vài loại kiểm thử

III.3.1.1 Phương thức kiểm thử

Một định nghĩa xây dựng để xác định, và đánh giá một sản phẩm , hệ thống,hay 1 hệ thống mà sản xuất ra một kết quả kiểm thử

III.3.1.2 Các loại kiểm thửIII.3.1.2.1 Kiểm thử yêu cầu cơ sở

- Kiểm thử yêu cầu

- Kiểm thử đặc tả phần mềm

- Kiểm thử sản phẩm dựa trên thông tin yêu cầu và tài liệu đặc tả kỉ thuật

- Mục đích chính của kiểm thử này là xác định lại yêu cầu(RequirementValidation )

- Các bước xây dựng kiểm thử này:

+ Phân tích những yêu cầu cơ sở

+ Tập hợp thật nhiều thông tin

+ Bảo đảm chức năng đó hoạt động

+ Thực thi test case

III.3.1.2.2 Kiểm thử thăm dò

- Mục đích của kiểm thử thăm dò là để phát hiện ra những khiếm khuyết trong

- Một vài điều kiện lỗi phải đựơc kiểm tra:

- Ngoài giá trị biên

- Giá trị vào null và quá tải

- Lỗi phần cứng và bộ nhớ

- Kiểm thử thăm dò có thể xây dựng với số lỗi cao nhất

III.3.1.2.3 Kiểm thử hồi quy

- Là loại kiểm thử chung của công việc

- Thực hiện re-run

- Kiểm định chất lượng không testing , không thực hiện tìm lỗi

- Hao phí thời gian lớn

Kiểm thử hồi quy thì được thực hiện sau khi đã tạo thêm chức năng hay chỉnhsửa lại chương trình

Mục đích:

- Chạy lại những test case để xác định rằng những sửa đổi không gâyhỏng kết quả và hệ thống kia luôn đáp ứng yêu cầu với những chi tiết kỹthuật

- Chạy lại test case để chắc chắn rằng những cái lỗi kia đã được sữa vàthật sự đã được sữa bởi những người lập trình

III.3.1.2.4 Kiểm thử Smoke

- Kiểm thử smoke được biết đến như môt kiểm thử xác nhận

- Kiểm thử này tiếp cận ứng dụng theo kiểu “rộng và sâu”

III.3.2 Một vài kỹ thuật thiết kế test case

- Phân vùng tương đương

- Phân tích giá trị biên

- Phân tích ràng buộc

- Quan hệ dữ liệu

- Chuyển trạng thái

- Điều kiện kết hợp

III.3.2.1 Phân vùng tương đương: (đã tìm hiểu ở chương

trên)

III.3.2.2 Phân tích giá trị biên: (đã tìm hiểu ở chương trên)

III.3.2.3 Điều kiện ràng buộc:

Là quan hệ giữa các biến khác nhau

Các bước chung để thiết kế kiểm thử sử dụng điều kiện rang buộc

- Xác định các biến độc lập và tìm quan hệ của chúng

- Xác định tất cả các giá trị vào ra cho các biến

- Danh sách các biến với dữ liệu vào ra và quan hệ của chúng

III.3.2.4 Quan hệ dữ liệu:

Những dữ liêu có quan hệ rang buộc với nhau

Ví dụ: Chương trình kiểm tra “end day” với ngày “start day” thì start daykhông thể sau “end day” được và “end day” thì không thế trước “start day”

“end day”được định nghĩa bởi “start day”

III.3.2.5 Chuyển trạng thái:

Liên quan đến một phân tích mối quan hệ trong những giai đoạn, sự kiệnhay hành động mà gây ra chuyển trạng thái từ trạng thái này sang trạng tháikhác

Các bước chung:

Xác định tất cả các giai đoạn hổ trợ

Định nghĩa kiểm thử

- Trạng thái băt đầu

- Sự kiện vào mà gây ra chuyển trạng thái

- Kết quả ra khi chuyển trạng thái

- Giai đoạn kết thúc

Người kiểm thử phải bao phủ hết cả khẳng đinh và phủ định

III.3.2.6 Điều kiện kết hợp:

Liên quan đến phân tích quan hệ kết hợp của các biến Quan hệ đại diệncho một điều kiện để kiêm thử

Bước thực hiện;

- Xác định các biến

- Xác định các giá trị có thể của các biến

- Tạo bảng quan hệ điều kiện cho các biến

III.4 Các lỗi thường gặp khi kiểm thử

III.4.1 Các lỗi dữ liệu vào ra

I Kiểu II Thể hiện

III Dữ liệu vào

IV Dữ liệu vào đúng nhưng không được chấp nhận

V Chấp nhận dữ liệu vào không đúng

VI Mô tả sai hoặc thiếu VII Tham số sai hoặc thiếu

• Thiếu điều kiện

• Điều kiện không liên quan đến công việc

• Kiểm tra sai biến

• Vòng lặp không đúng

• Sai toán tử

III.4.3 Các lỗi tính toán

• Thuật toán sai

III.4.4 Các lỗi giao diện

• Bắt lỗi dừng chương trình không đúng

• Thời gian vào ra dữ liệu

• Gọi đến thủ tục sai

• Gọi đến thủ tục không tồn tại

• Thiếu tham số

• Kiểu dữ liệu không thích hợp

• Sự bao gồm không cần thiết

III.4.5 Các lỗi dữ liệu

 Khởi tạo không đúng

• Lưu trữ/Truy cập không đúng

• Giá trị cờ/chỉ số sai

• Sử dụng biến sai

• Tham chiếu dữ liệu không đúng

• Kích thước dữ liệu không đúng

• Kiểu dữ liệu không đúng

• Phạm vi dữ liệu không đúng

• Dữ liệu không nhất quán

CHƯƠNG IV

ỨNG DỤNG LÝ THUYẾT ĐỂ THIẾT KẾ

TEST REQUIREMENTS VÀ TEST CASE

web và ứng dụng Evernote

Từ những kiến thức đã học, thiết kế test requirement và test case cho một chức

năng trong gmail Và chức năng được thực hiện trong ứng dụng này là “Thiết

kế test requirement và test case cho chức năng attachments trong Gmail”

Mục tiêu:

Biết cách để tạo test reuirement và test case cho một ứng dụng

Thiết kế test requirement và test case theo chuẩn

Test requirement :

TR-ID Test Requirements Status Resolution TR Type Traceability

Requirements For Attachments

TR-001

Verify that user can attach a file by choose

"Attach A File " link. New New Functional http://mail.google.com/support/bin/topic.py?hl=en&topic=12834TR-

002 Verify that user can remove file they attached by choose "Remove"button New New

Look n Feel

http://mail.google.com/support/bin/topic.py?hl=en&topic=12834 TR-

003 Verify that user can't attach a file larger than 25Mb New New Negativel http://mail.google.com/support/bin/topic.py?hl=en&topic=12834TR-

004 Verify that user can download attachments are sent. New New Function http://mail.google.com/support/bin/topic.py?hl=en&topic=12834TR-

006 Verify that user will get advice when download attachments file types exe New New Look nFeel http://mail.google.com/support/bin/topic.py?hl=en&topic=12834TR-

007 Verify that user can attach multiple files at a time by choose "Attach More File" link. New New Function http://mail.google.com/support/bin/topic.py?hl=en&topic=12834TR-

008 Verify that user can choose path for multiple filesneed attach after choose "Attach More File" link New New Function http://mail.google.com/support/bin/topic.py?hl=en&topic=12834TR-

009 Verify that user can see size file after attached successful. New New Look nFeel http://mail.google.com/support/bin/topic.py?hl=en&topic=12834

TR-010

Verify that user can choose file want to send after

attached successful by tick on check box.

New New

Look n Feel http://mail.google.com/support/bin/topic.py?hl=en&topic=12834