CÁC CÔNG cụ KIỂM THỬ tự ĐỘNG mã NGUỒN mở

Tuy chưa đượcứng dụng nhiều trong các tổ chứ c ở Việt Nam, song với những ưu điểm trên,Selenium hứ a hẹn sẽ ngày càng phát triển và trở lên thông dụng hơn trong các tổchức phát triển phầ

Trang 1

MỤC LỤC

DANH MỤC HÌNH ẢNH 3

DANH MỤC CÁC BẢNG 7

MỞ ĐẦU 1

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 4

1.1 Phần mềm là gì? 4

1.1.1 Khái niệm: 4

1.1.2 Thế nào là lỗi phần mềm 4

1.2 Kiểm thử phần mềm là gì? 4

1.3 Mục tiêu của kiểm thử phần mềm 6

1.3.1 Mục tiêu trực tiếp 6

1.3.2 Mục tiêu gián tiếp 6

1.4 Các nguyên tắc cơ bản của kiểm thử phần mềm 6

1.5 Qui trình kiểm thử phần mềm 7

1.6 Các kỹ thuật kiểm thử phần mềm 9

1.6.1 Kiểm thử hộp đen 9

1.6.2 Kiểm thử hộp trắng 10

1.6.3 Kiểm thử hộp xám 10

1.7 Các giai đoạn kiểm thử phần mềm 10

1.7.1 Kiểm thử đơn vị 11

1.7.2 Kiểm thử tích hợp 11

1.7.3 Kiểm thử hệ thống 12

1.7.4 Kiểm thử chấp nhận 25

1.7.5 Kiểm thử hồi qui 26

1.8 Kiểm thử tự động 27

1.8.1 Khái quát kiểm thử tự động 27

1.8.2 Tại sao dùng công cụ kiểm thử phần mềm? 30

1.8.3 Phân loại một số công cụ kiểm thử tự động 31

1.8.4 Chi phí thực hiện kiểm thử hiệu năng 33

SVTH : Nguyễn Thị Minh Khuyến – lớp Tin Địa Chất k57

2

Trang 2

1.9 Tổng kết chương 1 33

CHƯƠNG 2 : CÁC CÔNG CỤ KIỂM THỬ TỰ ĐỘNG MÃ NGUỒN MỞ 34

2.1 Giải pháp mã nguồn mở 34

2.2 Một số công cụ mã nguồn mở hỗ trợ kiểm thử ứng dụng web 36

2.2.1 Phần mềm Selenium 36

2.2.2 Phần mềm The Grinder 42

2.2.3 Phần mềm TestMaker 44

2.2.4 Phần mềm webload Opensource 45

2.2.5 Phần mềm Open STA 46

2.2.6 Phần mềm jmeter 46

2.2.7 Phần mềm TestLink 48

2.2.8 Đánh giá một số công cụ kiểm thử mã nguồn mở hiện nay 55

CHƯƠNG 3: PHẦN MỀM KIỂM THỬ TỰ ĐỘNG MÃ NGUỒN MỞ SELENIUM 57 3.1 Giới thiệu tổng quan về Selenium 57

3.1.1 Selenium là gì? 57

3.1.2 Các thành phần của Selenium 57

3.2 Selenium IDE 59

3.2.1 Cài đặt Selenium IDE 59

3.2.2 Các icon của Selenium IDE 61

3.2.3 Các thao tác thực hiện kiểm thử tự động với Selenium 63

3.2.4 Selenese 67

3.3 Selenium Remote Control (Selenium RC) 70

3.3.1 Các thành phần của Selenium Remote Control 71

3.3.2 Cài đặt Selenium Remote Control 72

3.3.3 Các thao tác với Selenium RC 75

4 CHƯƠNG 4: THỬ NGHIỆM 90

4.1 Bài toán thực hiện với Selenium 90

4.2 Các test case 91

4.3 Kiểm thử tự động trên ứng dụng Selenium IDE và Selenium RC 93

4.4 Báo cáo kết quả thử nghiệm 102

2

Trang 3

KẾT LUẬN 103

DANH MỤC TÀI LIỆU THAM KHẢO 105

DANH MỤC HÌNH ẢNH Hình 2.1: Tỉ lệ dùng phần mềm mã nguồn mở cho các dự án 36

Hình 2.2: Pop up cài đặt Selenium 39

Hình 2.3: Kiểm tra cài đặt Selenium thành công 40

Hình 2.4: Các icon của Selenium IDE 41

Hình 2.5: Test case Selenium IDE 42

Hình 2.6: Giao diện phần mềm The Grinder 44

Hình 2.7: Giao diện phần mềm TestMaker 45

Hình 2.8: Giao diện phần mềm Webload 46

Hình 2.9: Giao diện test trong Webload IDE 46

Hình 2.10:Giao diện cửa sổ ứng dụng của jmeter 47

Hình 2.11: cửa sổ tạo project 50

Hình 2.12: cửa sổ tạo Test Plan 51

Hình 2.13: cửa sổ tạo build creation 52

Hình 2.14: cửa sổ create Test Suite 53

Hình 2.15: cửa sổ Test Case Operations 53

Hình 2.16: Cửa sổ create Step 54

Hình 2.17: Hiển thị test case mới tạo 55

Hình 2.18: Tỷ lệ bình chọn công cụ kiểm thử mã nguồn mở 56

2

Trang 4

DANH MỤC CÁC BẢNG

Bảng 1.1: Kiểm thử giao diện người sử dụng 13

Bảng 1.2: Kiểm thử luồng nghiệp vụ 14

Bảng 1.3: Kiểm thử hiệu năng 15

Bảng 1.4: Kiểm thử an toàn thông tin 16

Bảng 1.5: Kiểm thử hồi qui 27

Bảng 1.6: Các bước thực hiện KTTĐ 30

2

Trang 5

MỞ ĐẦU

1 Lý do chọn đề tài

Trong giai đoạn phát triển của công nghệ thông tin, ngành công nghệ phầnmềm đang ngày một chiếm vị trí quan trọng trong xu hướng phát triển kinh tế côngnghiệp hóa,hiện đại hóa của đất nước ta Cùng với sự phát triển của công nghệ phầnmềm, lỗi phần mềm và chất lượng phần mềm luôn là thách thức lớn với bản thânngành phần mềm khi thực tế đã chứng minh, kiểm thử phần mềm là giai đoạn chiếmhơn 40% thời gian, kinh phí và nguồn nhân lực phát triển dự án phần mềm.Tuynhiên ở Việt Nam hiện nay, việc kiểm thử phần mềm vẫn chưa thực sự được nhìnnhận đúng với tầm quan trọng của nó Điều này thể hiện ở tỷ lệ kỹ sư kiểm thử phầnmềm ở Việt Nam còn khá thấp, cứ 5 lập trình viên thì mới có 1 kỹ sư kiểm thử (sốliệu thống kê năm 2011 của công ty LogiGear), trong khi tỷ lệ này theo chuẩn quốc

tế là 3:1.Thêm vào đó, mức độ đáp ứng của kỹ sư kiểm thử phần mềm ở Việt Namchưa cao Nguyên nhân của việc này đến từ sự thiếu hụt các đơn vị đào tạo chuyênsâu về kiểm thử và nguyên nhân sâu xa vẫn là vấn đề kiểm thử ở Việt Nam vẫnchưa được chuyên nghiệp hóa và đầu tư đúng mức

Ngày nay, tự động hóa đang được nghiên cứu và ứng dụng trong nhiềulĩnh vực trong đó công nghệ phần mềm nói chung và kiểm thử phần mềm nói riêngcũng không ngoại lệ Khi mà kiểm thử phần mềm vẫn tiêu tốn một lượng lớn thờigian, kinh phí và nhân lực trong một dự án phân mềm thì song song với kiểm thửtruyền thống thủ công , sự ra đời của các công cụ hỗ trợ kiểm thử tự động nhưQuick Test Professional, Nunir, Junit, Jmeter là tất yếu Selenium là một phần mềm

mã nguồn mở mạnh mẽ, hỗ trợ trên nền Web, có nhiều Platform và các trình duyệtphổ biến Công cụ này được phát triển bởi ThoughtWorks từ năm 2004 với tên banđầu là JavaScriptTestRunner Đến năm 2007, tác giả Jason Huggins rờiThoughtWorks và gia nhập Selenium team, một phần của Google và phát triểnthành Selenium như hiện nay Selenium là một công cụ kiểm thử các ứng dụng web

có khá nhiều ưu điểm như có thể kiểm thử trên nhiều trình duyệt, hỗ trợ nhiều ngônngữ lập trình, giao tiếp được với các công cụ kiểm thử khác như Junit, testNG (vớiJava) hay Nunit(với C#), và ưu điểm đặc biệt của công cụ này là nó là một bộ mã

2

Trang 6

nguồn mở, do đó các tổ chức sẽ không tốn kinh phí mua bản quyền Tuy chưa đượcứng dụng nhiều trong các tổ chứ c ở Việt Nam, song với những ưu điểm trên,Selenium hứ a hẹn sẽ ngày càng phát triển và trở lên thông dụng hơn trong các tổchức phát triển phần mềm ở nước ta.

Với mong muốn có cái nhìn xác thực, rõ ràng hơn về kiểm thử phần mềm vàtiếp nhận được với công cụ kiểm thử tự động Selenium để làm tiền đề cho địnhhướng tương lai khi tốt nghiệp đại học sẽ trở thành một kỹ sư kiểm thử phần mềm,

cá nhân em lựa chọn đề tài “Nghiên cứu ứng dụng mã nguồn mở Selenium trong kiểm thử phần mềm” làm đề tài cho đồ án tốt nghiệp đại học của mình, đồ án chỉ

dừng lại ở việc đưa ra lý thuyết về kiểm thử phần mềm và giới thiệu phần mềm mãnguồn mở kiểm thử selenium, do thời gian và kinh nghiệm thực tế còn hạn chế nên

có những phần thực hiện chưa được tốt ,em rất mong nhận được sự góp ý của thầy

cô và các bạn

2 Mục tiêu nghiên cứu

- Có cái nhìn đúng đắn và sâu sắc hơn về các vấn đề cơ bản của công nghệ

phần mềm, lỗi phần mềm và kiểm thử phần mềm

- Hiểu biết rõ hơn về các công cụ kiểm thử phần mềm mã nguồn mở

- Hiểu rõ về các thành phần của công cụ Selenium và cách sử dụng công cụ

này

- Ứng dụng các kiến thức về kiểm thử phần mềm và về công cụ kiểm thử

Selenium để viết kịch bản kiểm thử cho một ứng dụng cụ thể

3 Bố cục nội dung của đồ án

Đồ án được chia thành 6 chương với nội dung như sau:

- Mở đầu: Chương này trình bày về lý do chọn đề tài, mục tiêu nghiên cứu đồ

án và bố cục nội dung của đồ án

- Chương 1: Tổng quan về phần mềm kiểm thử phần mềm: Chương này

trình bày những kiến thức cơ bản về kiểm thử phần mềm như định nghĩa cơ bản vềphần mềm, lỗi phần mềm, và quy trình xử lý lỗi phần mềm, những kiến thức cơ bản

về kiểm thử phần mềm như các nguyên tắc kiểm thử, các phương pháp kiểm thử,các giai đoạn kiểm thử phần mềm

- Chương 2: Các công cụ kiểm thử phần mềm: Chương này trình bày vềgiải pháp công cụ mã nguồn mở và một số công cụ mã nguồn mở phục vụ kiểm thử

2

Trang 7

- Chương 3: Công cụ kiểm thử tự động Selenium: Chương này trình bàytổng quan về bộ công cụ Selenium, đi sâu vào các thao tác với Selenium IDE vàSelenium RC.

- Chương 4: Thử nghiệm: Chương này trình bày kịch bản kiểm thử viết cho một

số chức năng cơ bản của ứ ng dụng web https://mail.viettel.com.vn và thử nghiệm một số

trường hợp kiểm thử tự động viết bằng Selenium IDE và Selenium RC

- Kết luận: chương này đưa ra những kết quả đồ án đạt được, những thiếu sót

chưa thực hiện được và hướng phát triển đề tài trong tương lai

Hà Nội, tháng /2017

Người thực hiện

Nguyễn Thị Minh Khuyến

2

Trang 8

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

o Sai: Sản phẩm được xây dựng khác với đặc tả

o Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm đượcxây dựng

o Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả Cũng

có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng chấpnhận nhưng lại khác với đặc tả nên vẫn coi là có lỗi

Một hình thức khác nữa cũng được xem là lỗi, đó là phần mềm khó hiểu, khó

sử dụng, chậm hoặc dễ gây cảm nhận rằng phần mềm hoạt động không đúng

1.2 Kiểm thử phần mềm là gì?

Kiểm thử phần mềm có nhiều định nghĩa khác nhau đề xuất bởi nhiều

tổ chức hay cá nhân khác nhau Phần này của đồ án sẽ trình bày một số định nghĩanổi bật:

o Định nghĩa của Myer (1979): "Kiểm thử là quá trình thực thi một

chương trình với mục đích tìm ra lỗi" Theo như định nghĩa này, quá trình kiểm thửbao gồm tất cả các hoạt động từ kiểm tra mã nguồn được thực hiện bởi trưởng

2

Trang 9

nhóm phát triển, đến việc chạy thử chương trình được tiến hành bởi các đồngnghiệp khác Tất cả các hoạt động trên đều được coi là các hoạt động kiểm thử.

o Hai định nghĩa của IEEE (1990):

Định nghĩa 1: Kiểm thử phần mềm là quá trình vận hành một hệ thống

hoặc một thành phần của hệ thống với các điều kiện xác định, nhận xét và ghi lạicác kết quả, tạo ra đánh giá về những khía cạnh của hệ thống hay thành phần hệthống

Định nghĩa 2: Kiểm thử phần mềm là quá trình phân tích các yếu tố phần

mềm để phát hiện những khác biệt giữa chương trình với các điều kiện yêu cầu vàđánh giá các đặc điểm của các yếu tố phần mềm

Theo như định nghĩa 2, việc chạy chương trình như một phần của tiến trìnhkiểm thử phần mềm là không cần thiết

o Định nghĩa của Daniel Galin: "Kiểm thử phần mềm là một quá trình

được tiến hành bởi một nhóm chuyên viên kiểm thử, trong đó một đơn vị phầnmềm, một nhóm các đơn vị được tích hợp, hoặc cả gói phần mềm được kiểm trabằng cách chạy các chương trình trên máy tính Tất cả các bước kiểm tra liên đượctiến hành theo các thủ tục kiểm thử và các trường hợp kiểm thử đã được thông qua"

Định nghĩa của Daniel Galin là một định nghĩa khá hoàn thiện về kiểm thửphần mềm Một số thuật ngữ có trong định nghĩa của Daniel Galin:

Nhóm chuyên viên kiểm thử: Một nhóm độc lập hoặc nhóm tư vấn từ bênngoài, những người chuyên kiểm thử được chỉ định để thực hiện các nhiệm vụ chủyếu là để phát hiện và loại bỏ sai lệch và để đảm bảo kiểm thử hiệu quả bởi cácchuyên gia kiểm thử được đào tạo

2

Trang 10

Các thủ tục kiểm thử đã được thông qua: Quá trình kiểm thử được thựchiện theo kế hoạch kiểm thử và các thủ tục kiểm thử được thông qua phù hợp vớicác thủ tục đảm bảo chất lượng phần mềm được thông qua bởi tổ chức phát triểnphần mềm.

Các trường hợp kiểm thử được thông qua: Các trường hợp kiểm thử đượcđịnh nghĩa đầy đủ trong kế hoạch kiểm thử Không có sự thiếu xót hoặc bổ sung nàođược mong đợi xảy ra trong suốt quá trình thực thi kiểm thử

o Định nghĩa đúc kết được trong quá trình học tập và làm việc: Kiểm

thử phần mềm là quá trình phê chuẩn và xác minh một chương trình máy tính,một ứng dụng hay 1 sản phẩm nào đó xem nó có thỏa mãn những điều kiện sau haykhông:

 Đáp ứng các yêu cầu hướng dẫn thiết kế và phát triển của nó

 Hoạt động như mong đợi

 Có thể thực hiện với các đặc điểm giống nhau

 Đáp ứng được các yêu cầu của các bên liên quan

1.3 Mục tiêu của kiểm thử phần mềm

1.3.1 Mục tiêu trực tiếp

o Phát hiện và xác định càng nhiều lỗi càng tốt ở các phần mềm được kiểm thử

o Tiến hành sửa lỗi ở các phần mềm được kiểm thử và kiểm thử lại chođến khi đạt một mức độ chất lượng phần mềm chấp nhận được

2

Trang 11

o Thực thi những trường hợp kiểm thử một cách hiệu quả trong một giớihạn ngân sách và lịch trình cho phép.

1.3.2 Mục tiêu gián tiếp

o Để biên dịch một tài liệu về các lỗi phần mềm thường gặp nhằm mụcđích ngăn ngừa và sửa chữa lỗi

1.4 Các nguyên tắc cơ bản của kiểm thử phần mềm

Có bảy nguyên tắc cơ bản cần chú ý khi kiểm thử phần mềm, các nguyên tắc

- Không thể kiểm thử vét cạn: Việc kiểm thử không thể thực hiện

được cho tất mọi trường hợp kiểm thử Do vậy thay vì kiểm thử mọi khía cạnh, taphải tập trung vào kiểm thử những yếu tố quan trọng và nhiều rủi do

- Kiểm thử sớm: Các hoạt động kiểm thử nên bắt đầu càng sớm càng

tốt trong vòng đời phát triển phần mềm, và nên tập trung và những mục tiêu kiểmthử nhất định

- Phân cụm lỗi: Một số lượng nhỏ các mô-đun phần mềm có thể chứa

hầu hết các lỗi được phát hiện ra trong suốt quá trình kiểm thử hoặc tập trung hầuhết các lỗi vận hành

2

Trang 12

- Kiểm thử ngược: Nếu một phương pháp kiểm thử được lặp đi lặp lại

nhiều lần, các trường hợp kiểm thử giống nhau sẽ không phát hiện được triệt để lỗimới Để khắc phục điều này ta có thể sử dụng nguyên tắc "kiểm thử ngược", cáctrường hợp kiểm thử cần phải được xem xét và duyệt lại một cách đều đặn, và việckiểm thử mới cần phải được viết lại để thực thi những phần khác của phần mềmhay hệ thống để tìm ra những lỗi tiềm ẩn

- Kiểm thử phụ thuộc vào ngữ cảnh: Việc kiểm thử được thực hiện

trong những hoàn cảnh khác nhau thì khác nhau

- Sai lầm về việc không có lỗi: Tìm kiếm và sửa lỗi không thể giúp

được gì nếu hệ thống không dùng được hoặc không đáp ứng được yêu cầu và sựmong đợi của khách hàng

1.5 Qui trình kiểm thử phần mềm

Tùy vào từng tổ chức, hệ thống, ngữ cảnh, mức độ rủi ro của phần mềm màqui trình kiểm thử phần mềm có thể gồm nhiều bước khác nhau Mục đích của kiểmthử là thiết kế một chuỗi các trường hợp kiểm thử mà có khả năng phát hiện lỗi cao Đểcho việc kiểm thử đạt kết quả tốt cần có sự chuẩn bị về kế hoạch kiểm thử, thiết kế cáctrường hợp kiểm thử và các dữ liệu kiểm thử cho các trường hợp Đây chính là đầu vàocho các giai đoạn kiểm thử Và sản phẩm công việc của giai đoạn kiểm thử chính là

“báo cáo kiểm thử” mà tài liệu hóa tất cả các trường hợp kiểm thử đã chạy, dữ liệu đầuvào, đầu ra mong đợi, đầu ra thực tế và mục đích kiểm thử, … Nhưng nhìn chung mọiqui trình kiểm thử đều có những bước cơ bản như qui trình dưới đây:

2

Trang 13

Hình 1 : Quy trình kiểm thử phần mềm

Theo đó một qui trình kiểm thử phần mềm cơ bản gồm các giai đoạn sau:

- Lập kế hoạch kiểm thử : Nhiệm vụ quan trọng trong phần lập kế

hoạch kiểm thử là xác định được các yếu tố sau:

Các giai đoạn kiểm thử áp dụng cho dự án

Mốc bàn giao các tài liệu kiểm thử

- Chuẩn bị kiểm thử : Nhiệm vụ chiến lược của giai đoạn này là:

2

Trang 14

Tìm hiểu nghiệp vụ của hệ thống phải kiểm thử

 Xây dựng kịch bản kiểm thử, phát triển các thủ tục và các kịch bản kiểmthử tự động (trong trường hợp kiểm thử tự động)

 Chuẩn bị dữ liệu kiểm thử

- Thực thi kiểm thử :

Thực hiện kiểm thử dựa trên các kịch bản kiểm thử,test script, thủ tục, dữliệu có sẵn từ bước chuẩn bị kiểm thử

Tham gia quá trình quản lý lỗi: báo lỗi, sửa lỗi

- Báo cáo và phân tích dữ liệu kiểm thử :

Báo cáo kiểm thử

Phân tích nguyên nhân và đề xuất các hành động khắc phục

 Xem xét phê duyệt các tài liệu kiểm thử

Trang 15

- Kỹ thuật kiểm thử hộp đen xem chương trình như là một “hộp đen”, trong

đó người kiểm thử không quan tâm đến cấu trúc bên trong của chương trình mà chỉquan tâm tới dữ liệu đầu vào và đầu ra sau khi được xử lý

- Mục đích của chiến lược này là tìm kiếm các trường hợp mà chương trìnhkhông thực hiện theo các đặc tả của nó

- Ưu, nhược điểm: Kiểm thử hộp đen có ưu điểm là có thể đánh giá phầnmềm một cách khách quan, người kiểm thử có thể không hiểu biết về mã lệnh và cóthể tìm ra các lỗi mà nhân viên phát triển không tìm ra Song kiểm thử hộp đen lại

có nhược điểm là thăm dò mù, do nhân viên kiểm thử không biết các chương trìnhthực sự được xây dựng như thế nào, dẫn đến trường hợp nếu kiểm thử hộp đen phảiviết rất nhiều trường hợp kiểm thử trong khi chỉ cần viết một ca kiểm thử duy nhất

để có thể kiểm tra được

1.6.2 Kiểm thử hộp trắng

- Kỹ thuật kiểm thử hộp trắng hay còn gọi là “kiểm thử cấu trúc” là kỹ thuậtkiểm thử cho phép khảo sát kiến trúc bên trong của chương trình Kiểm thử hộptrắng là chiến lược được thực hiện trên ba trong sáu loại kiểm thử cơ bản trong cácgiai đoạn kiểm thử phần mềm là: kiểm thử đơn vị, kiểm thử tích hợp và kiểm thửhồi quy Mục tiêu của kiểm thử hộp trắng là kiểm thử bao phủ nhiều nhất các câulệnh, điểm quyết định và các rẽ nhánh trong mã nguồn nếu có thể

1.6.3 Kiểm thử hộp xám

Kiểm thử hộp xám là kỹ thuật kiểm thử có sự kết hợp giữa kiểm thửhộp đen và kiểm thử hộp trắng Trong đó ta cũng quan tâm đến dữ liệu đầu vào vàđầu ra giống như trong kiểm thử hộp đen, song lại đòi hỏi có sự truy cập đến cấutrúc dữ liệu và giải thuật để thiết kế các trường hợp kiểm thử

2

Trang 16

1.7 Các giai đoạn kiểm thử phần mềm

 Kiểm thử phần mềm gồm 4 giai đoạn chính:

 Đơn vị: Là thành phần nhỏ nhất của phần mềm có thể kiểm thử được

Ví dụ: Các hàm, lớp, thủ tục, phương thức Đơn vị thường có kích thước nhỏ, chứcnăng hoạt động đơn giản, không gây nhiều khó khăn trong việc kiểm thử, ghi nhận

và phân tích kết quả do đó nếu phát hiện lỗi việc tìm kiếm nguyên nhân và sửa lỗi

Hình 2 : Các giai đoạn kiểm thử phần mềm

2

Trang 17

cũng đơn giản và tốn ít chi phí hơn Một nguyên lý đúc kết từ thực tiễn là thời giandành cho kiểm thử đơn vị sẽ được đền bù bằng việc tiết kiệm được khá nhiều thờigian và chi phí cho việc kiểm thử và sửa lỗi ở các mức độ kiểm thử sau đó.

 Mục đích: Đảm bảo thông tin được xử lý đúng và có đầu ra chính xáctrong mối tương quan giữa dữ liệu nhập và chức năng của đơn vị

 Người thực hiện: Do việc kiểm thử đơn vị đòi hỏi phải kiểm tra từngnhánh lệnh, nên đòi hỏi người kiểm thử có kiến thức về lập trình cũng như về thiết

kế của hệ thống nên người thực hiện thường là lập trình viên

 Kiểm thử tích hợp chỉ nên thực hiện trên từng đơn vị đã được kiểm

2

Trang 18

tra cẩn thận trước đó bằng kiểm thử đơn vị, và tất cả các lỗi mức đơn vị đã được sửachữa.

 Nên tích hợp dần từng đơn vị: Một đơn vị nên được tích hợp vào mộtnhóm các đơn vị khác đã được tích hợp và hoàn thành kiểm thử tích hợp trước đó vìkhi đó chỉ cần kiếm tra giao tiếp giữa đơn vị mới được thêm vào với nhóm các đơn

vị đã được tích hợp trước đó

1.7.3 Kiểm thử hệ thống

 Kiểm thử hệ thống bắt đầu khi tất cả các đơn vị của hệ thống đượctích hợp thành công Đây là công đoạn kiểm thử tốn nhiều công sức và thời gianhơn cả Và đặc biệt, công đoạn này thường đòi hỏi được thực hiện bởi một nhómnhân viên tách biệt với nhóm phát triển, có chuyên môn và kinh nghiệm kiểm thử

 Kiểm thử hệ thống gồm nhiều loại kiểm thử khác nhau, trong số đó,các mục tiêu kiểm thử quan trọng nhất là:

 Kiểm thử chức năng

 Kiểm thử hiệu năng

 Kiểm thử an toàn thông tin

 Mục đích: kiểm tra xem hệ thống được làm ra có thỏa mãn yêu cầuhay không về nhiều khía cạnh: hoạt động, độ tin cậy, hiệu năng của hệ thống

 Người thực hiện: Nhóm nhân viên kiểm thử

 Lưu ý:

2

Trang 19

 Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn bắtđầu dự án.

Phần tiếp theo sẽ đi sâu vào phân tích các bước kiểm thử quan trọng nhất,được coi là không thể bỏ qua khi tiến hành kiểm thử bất cứ hệ thống nào

1.7.3.1 Kiểm thử chức năng

Việc kiểm thử chức năng chú trọng đến 2 phần chính là kiểm thử giao diệnngười dùng (User interface) và kiểm thử luồng nghiệp vụ (Bussiness Flow Testing)

a) Kiểm thử giao diện người sử dụng

Kiểm thử giao diện người sử dụng gọi tắt kiểm thử giao diện là việc kiểm tracác tương tác của người dùng với phần mềm Mục tiêu của kiểm thử giao diện là đểđảm bảo rằng giao diện người dùng cung cấp cho người sử dụng cách truy cập và sửdụng các chức năng của hệ thống một cách thích hợp Ngoài ra, kiểm thử giao diệncòn để đảm bảo rằng các đối tượng trên giao diện giống như thiết kế và phù hợp với

- Các đối tượng và thuộc tính màn hình như menus, size,position, state

Cách thực

hiện:

- Tạo ra và chỉnh sửa kịch bản kiểm thử cho mỗi màn hình đểkiểm tra việc sử dụng đúng cách và tình trạng các đối tượng chomỗi màn hình và đối tượng của ứng dụng

Điều kiện hoàn

Bảng 1.1: Kiểm thử giao diện người sử dụng

2

Trang 20

b) Kiểm thử luồng nghiệp vụ

Mục đích của kiểm thử luồng nghiệp vụ là kiểm tra các yêu cầu chức năng

và nghiệp vụ của hệ thống bao gồm các hoạt động để kiểm tra tính đúng đắn của dữliệu, qui trình, báo cáo và việc thực hiện đúng những qui tắc nghiệp vụ Kiểu kiểmthử này dựa vào kỹ thuật kiểm thử hộp đen, tức là kiểm tra ứng dụng và các xử lýbên trong ứng dụng bằng cách tương tác với ứng dụng thông qua giao diện người

sử dụng và phân tích các kết quả hoặc đầu ra Bảng sau liệt kê một số gợi ý đối vớimỗi ứng dụng:

Mục đích kiểm

thử:

Đảm bảo mục tiêu kiểm thử đúng đắn của chức năng, bao gồm

dữ liệu đầu vào, xử lý dữ liệu và dữ liệu nhận được Kiểm thửchức năng đảm bảo các yêu cầu sau:

- Nhập dữ liệu hợp lệ thì chương trình phải cho nhập

- Kết quả mong đợi với dữ liệu hợp lệ

- Lỗi thích hợp hoặc thông báo hiển thị khi dữ liệu khônghợp lệ

thành:

- Toàn bộ kế hoạch kiểm thử đã được thực hiện

- Toàn bộ các lỗi phát hiện ra đã được ghi nhận

Các vấn đề đặc

biệt:

- Xác định hoặc mô tả các vấn đề (nội bộ hoặc bênngoài) ảnh hưởng đến việc kiểm thử chức năng

Bảng 1.2: Kiểm thử luồng nghiệp vụ

1.7.3.2 Kiểm thử hiệu năng

Mục đích của kiểm thử hiệu năng là kiểm tra các yêu cầu về hiệu năng cóđạt được hay không

2

Trang 21

Mục đích kiểm

thử:

Kiểm tra các biểu hiện về hiệu năng cho các giao dịch hoặcchức năng nghiệp vụ theo những điều kiện sau:

- Khối lượng công việc bình thường đã biết trước

- Khối lượng công việc xấu đã biết trước

Cách thực

hiện:

- Sử dụng các thủ tục cho kiểm thử luồng nghiệp vụ

- Chỉnh sửa file dữ liệu để tăng số lượng các giao dịchhoặc scripts để tăng số tương tác xảy ra trong mỗi giao dịch

- Scripts phải được chạy trên một máy (trường hợp tốtnhất để đánh giá người dùng đơn lẻ, giao dịch đơn lẻ) vàphải lặp lại trên nhiều máy trạm

thành:

- Giao dịch đơn lẻ hoặc người dùng đơn lẻ: Thực hiệnthành công test script không có lỗi và trong phạm vi mongđợi hoặc thời gian phản hồi cho mỗi giao dịch

- Nhiều giao dịch hoặc nhiều người dùng: Thựchiện thành công test script không có lỗi và trong thời gianchấp nhận được

Các vấn đề đặc

biệt:

Bảng 1.3: Kiểm thử hiệu năng

1.7.3.3 Kiểm thử an toàn thông tin

Kiểm thử an toàn thông tin tập trung vào hai lĩnh vực bảo mật chính:

 Bảo mật ở mức ứng dụng: bao gồm truy cập dữ liệu và các chức năngnghiệp vụ

 Bảo mật ở mức hệ thống: bao gồm truy cập vào hệ thống hoặc truy cập

từ xa

Bảo mật mức ứng dụng đảm bảo rằng, dựa trên bảo mật đã yêu cầu, người

2

Trang 22

dùng bị hạn chế sử dụng một số chức năng hoặc tình huống sử dụng, hoặc bị hạnchế trong giới hạn dữ liệu phù hợp với họ Ví dụ, người dùng có thể được phépnhập dữ liệu để tạo account nhưng chỉ có người quản lý có thể xóa chúng Nếu làbảo mật ở mức dữ liệu, việc kiểm thử đảm bảo rằng “người dùng nhóm 1” có thểnhìn thấy các thông tin khách hàng, bao gồm dữ liệu tài chính, tuy nhiên “ngườidùng nhóm 2” chỉ nhìn thấy các thông tin chung chung cho cùng một khách hàng.

Bảo mật mức hệ thống đảm bảo rằng chỉ những người dùng được cho quyềntruy cập vào hệ thống mới có khả năng truy cập vào ứng dụng và chỉ bằng các cổngthích hợp

Mục đích kiểm thử:

- Bảo mật mức ứng dụng: Đảm bảo rằng mộtngười dùng chỉ có thể truy cập vào những chức nănghoặc dữ liệu mà nhóm người dùng đó được phép

- Bảo mật mức hệ thống: Đảm bảo rằng chỉnhững người được phép truy cập hệ thống và ứngdụng được phép truy cập chúng

- Sửa lại nhóm người dùng và chạy lại tìnhhuống kiểm thử cho cùng những người dùng Với mỗitrường hợp, kiểm tra các chức năng thêm vào hoặc dữliệu có đúng không hay bị từ chối

Điều kiện hoàn thành: - Với mỗi nhóm người dùng đều có các chức năng

hoặc dữ liệu thích hợp, và toàn bộ các chức năng giaodịch đều như dự kiến và chạy trong các kiểm thử chứcnăng ứng dụng trước đó

2

Trang 23

Các vấn đề đặc biệt: - Truy cập vào hệ thống phải được xem xét hoặc

thảo luận với quản trị hệ thống hoặc quản trị mạng,

có thể không cần nếu nó là chức năng của quản trịmạng hoặc quản trị hệ thống

Bảng 1.4: Kiểm thử an toàn thông tin

- Kiểm tra lỗi SQL Injection

 Mô tả: Lỗi SQL Injection xảy ra khi các biến do người dùng truyềnlên (GET, POST) được đưa thẳng vào các câu truy vấn cơ sở dữ liệu mà không qua

xử lý, khi đó kẻ tấn công có thể truyền các kí tự đặc biệt mang ngữ nghĩa SQLtruyền vào câu truy vấn để thực hiện các thao tác độc hại như thêm, xóa hay sửa các

dữ liệu trên cơ sở dữ liệu và thực hiện các biện pháp tấn công leo thang khác

 Hướng dẫn kiểm tra lỗi: Các lỗi SQL Injection thường xuất hiện tạicác chức năng của ứng dụng có tương tác với cơ sở dữ liệu, trong đó có một sốbiến được truyền vào ứng dụng từ trình duyệt Các biến GET thường tồn tại dướidạng các ký tự mang ngữ nghĩa SQL, để kiểm tra lỗi SQL Injection, ta thử bằngcách:

o Truyền các kí tự đặc biệt mang ngữ nghĩa SQL như ' vào các biến dạng sốtrên URL hoặc chuỗi tổ hợp các ký tự đặc biệt vào các form Nếu ứng dụng xuất lỗi

500, hoặc trên trình duyệt in ra câu truy vấn SQL lỗi hay đăng nhập thành công, khi

đó có thể xác định ứng dụng đã bị mắc lỗi SQL Injection

 Ví dụ: Truyền vào form đăng nhập chuỗi ký tự đặc biệt: test' or '1'='1

Hình 3: Kiểm tra lỗi SQL Injection

2

Trang 24

Nếu hệ thống cho phép đăng nhập thành công thì hệ thống đã bị lỗi SQLInjection:

- Kiểm tra lỗi XSS

Hình 4 : Lỗi SQL Injection

2

Trang 25

 Cách kiểm tra: Nhập vào chuỗi kí tự <script>alert(“XSS”)</script>vào các form hay trên URL, nếu ứng dụng lưu lại và cho phép thực thi script thì trêntrình duyệt sẽ xuất hiện cửa sổ có dòng chữ “XSS”, khi đó ứng dụng bị mắc lỗiXSS.

 Ví dụ 1: Truyền ký chuỗi ký tự <script>alert(“XSS”)</script> vàobiến user của trang http://192.168.174.96:9999/index.php?user=<script>alert(“XSS”)</script>

- Ứng dụng sẽ trả về lỗi như hình dưới, như vậy ứng dụng đã bị lỗi XSS

Ví dụ 2: Nhập chuỗi ký tự <script>alert(“XSS”)</script> vào form:

Hình 6 : Kiểm tra Lỗi XSS_2

Trang 26

- Kiểm tra lỗ hổng CSRF (Cross-site request forgery)

 Mô tả: Khi gặp lỗi này kẻ tấn công có thể thực hiện mượn tay của người

có quyền trên hệ thống thực thi tác vụ mà kẻ tấn công mong muốn mà không ngườithực hiện không hề biết

 Hướng dẫn kiểm tra lỗi: Để kiểm tra lỗi này ta thực hiện như sau:

o Sử dụng một user

o Trên trình quyệt, mở hai TAB để đăng nhập vào ứng dụng

o Đăng nhập theo thứ tự: đăng nhập vào ứng dụng trên TAB1 rồi TAB2

o Quay về TAB1 thực hiện các tác vụ cần thiết như thêm, xóa, sửa

o Sang TAB2 mô phỏng tác vụ giống hệt bên TAB1 nếu vẫn thực hiện đượcthì ứng dụng bị lỗi CSRF

o Ngoài ra, sử dụng thêm FireBug (Add-ons của Firefox) kiểm tra ứng dụng

có dùng biến token hay không

2

Trang 27

Hình 8 : Kiểm tra lỗ hổng CFRS_1

Sau khi Save hoặc Delete, kiển tra ứng dụng có sử dụng biến token hay không?

- Kiểm tra lỗi Path Traversal

Mô tả: Lỗi Path Traversal xảy ra khi các biến do người dùng truyền lên(GET, POST) được đưa thẳng vào các hàm mở file, do nload file mà không qua xử

lý Khi đó, kẻ tấn công có thể truyền vào các kí tự đặc biệt như /, \ để nhảy thư

2

Trang 28

mục, hoặc truyền vào đường dẫn tuyệt đối của 1 file như /etc/pass d, từ đó có thểtruy cập các thông tin nhạy cảm của ứng dụng và hệ điều hành và tấn công leothang để chiếm quyền điều khiển ứng dụng và hệ điều hành.

Hướng dẫn kiểm tra lỗi:

o Lỗi Path Traversal thường xuất hiện ở các chức năng cho phép xemfile trên máy chủ hay chức năng do nload file, nếu các biến GET, POST có kiểu giátrị như tên file, tên thư mục thì nhiều khả năng chức năng này bị mắc lỗi PathTraversal

o Có thể kiểm tra bằng cách truyền vào chuỗi kí tự /, \ hoặc đường dẫntuyệt đối của 1 file thuộc hệ điều hành như /etc/pass d, và theo dõi hồi đáp từ phíaserver, trong trường hợp tấn công thành công có thể lấy được nội dung file

o Ví dụ minh họa

Trong ứng dụng trên, chức năng get-files sử dụng 1 biến GET có dạng đườngdẫn đến file, ta có thể thử bằng cách truyền vào các giá trị đường dẫn đến các filecủa hệ điều hành và ứng dụng, nếu có thể get được các file đó thì ứng dụng bị mắclỗi Path Traversal

 Ví dụ:

http://some_site.com.br/get- files?file= / / / /some dir/some file

Hoặcttp://some_site.com.br/ / / / /etc/shadow http://some_site.com.br/get- files?/etc/passwd

Hình 11 : Kiểm tra lỗi Path Traversal_1

2

Trang 29

Kẻ tấn công lấy file omcat- users.xml để có thông tin về user/pass củatomcat http://192.168.174.96:9999/RDWF_3/download!actionDownload.do?filename=/ / / / /conf/tomcat-users.xml

Thông tin user/pass tomcat

- Kiểm tra lỗi xác thực/phân quyền

 Mô tả: Trong ứng dụng, đôi khi việc thực hiện xác thực và phân quyền

2

Trang 30

không đầy đủ, có khi chỉ dựa trên việc che dấu các link hay không hiển thị các nútchức năng đối với người dùng thông thường Tuy nhiên, nếu người dùng thôngthường biết được các link, nút đó thì có thể tạo các request trực tiếp tới server màkhông cần click vào link, nút, để thực hiện thao tác Khi đó, cơ chế xác thực/phânquyền của ứng dụng hoàn toàn bị phá vỡ.

 Hướng dẫn kiểm tra lỗi: Để k iểm tra lỗi này có thể sử dụng hai account,trong đó có một account có quyền thấp và một account có quyền cao hơn Khi sửdụng account có quyền cao truy cập vào các chức năng dành riêng ta ghi lại cácđường dẫn trên URL, sau đó đăng nhập vào bằng account quyền thấp và thử truycập vào link đó Nếu ứng dụng cho phép account truy cập thì cơ chế xác thực phânquyền của ứng dụng không có tác dụng

 Ví dụ:

Trong ví dụ trên, ta dùng account viettel_cp1 để truy cập vào chức năng thống

kê doanh thu của dịch vụ Thông thường, khi truy cập vào account Admin trên bảngđiều khiển có 1 nút “Thống kê” để thống kê doanh thu, còn khi truy cập bằngaccount viettel_cp1 thì không có nút này Tuy nhiên, nhìn trên thanh URL ta có thểthấy đường dẫn để truy cập vào chức năng này, ta sao chép lại, sau đó đăng nhậpbằng account viettel_cp và thử truy cập thì thấy thành công Từ đó có thể kết luậnchức năng xác thực, phân quyền của ứng dụng không có tác dụng

- Kiểm tra lỗi User enumeration

Hình 15 : Kiểm tra lỗi xác thực phân quyền

2

Trang 31

Đăng nhập vào ứng dụng (cố tình nhập tên đăng nhập hoặc mật khẩu sai) Nếuứng dụng trả về câu thông báo cụ thể là “sai mật khẩu” hoặc “sai tên đăng nhập” thìứng dụng mắc lỗi Còn nếu trả về câu thông báo chung ví dụ “Tên đăng nhập hoặcmật khẩu không đúng” thì không bắt lỗi.

- Kiểm tra lỗi Session fixation

 Mô tả: Lỗi này xảy ra khi session- id trước và sau khi đăng nhập vào ứngdụng không thay đổi Kẻ tấn công có thể lợi dụng lỗ hổng này để đăng nhập màkhông cần user/pass

 Hướng dẫn kiểm tra lỗi:

o Cài và bật Add-ons FireBug cho trình duyệt Firefox

o Đăng nhập vào ứng dụng, và kiểm tra Cookie trước và sau khi đăngnhập

o So sánh Cookie trước và sau đăng nhập Nếu giống nhau thì bị lỗi

o Ví dụ:

Trang 32

- Lỗi HTTP Only Cookie

 Cài và chạy Add-ons Firecookie và FireBug cho FireFox

 Đăng nhập vào ứng dụng đồng thời kiểm tra HTTP Only trong FireBug

 Ví dụ:

2

Trang 33

Hình 17 : Lỗi HTTP Only Cookie

- Kiểm tra lỗi lỗ hổng cho phép dò đoán mật khẩu để thu thập danh sách, thông tin người dùng

Mô tả: 1 số ứng dụng không có cơ chế bảo vệ đăng nhập như đăng nhập saiquá số lần quy định cần yêu cầu người dùng nhập các kí tự từ 1 bức ảnh (captcha),hoặc tạm thời khóa account trong 1 khoảng thời gian nhất định Khi đó, kẻ tấn công

có thể tiến hành tấn công bằng cách thử các mật khẩu có trong 1 từ điển (tấn côngdạng từ điển), hoặc thử tất cả các khả năng của mật khẩu (bruteforce), với các mậtkhẩu đơn giản có thể dễ dàng bị tìm ra Ngoài ra, với các ứng dụng có cung cấp cáctính năng tìm kiếm, tra cứu thông tin người dùng mà không có biện pháp kiểm soátthì kẻ tấn công có thể sử dụng các script để tự động hóa quá trình truy vấn và thuthập được thông tin của người dùng hoặc ứng dụng

Hướng dẫn kiểm tra lỗi: Các ứng dụng không có cơ chế bảo vệ sử dụngcaptcha, lock account khi đăng nhập sai quá số lần quy định đều bị mắc lỗi này

2

Trang 34

1.7.4 Kiểm thử chấp nhận

- Mục đích: Kiểm thử chấp nhận còn gọi là kiểm thử nghiệm thu nhằm mục

đích chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng

đã chấp nhận sản phẩm

- Người thực hiện: Khách hàng.

- Có 2 phương pháp kiểm thử chấp nhận: K iểm thử alpha và kiểm thử bêta.

1.7.4.1 Kiểm thử alpha

- Người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm dưới sự

hỗ trợ của nhân viên kiểm thử, nhân viên kiểm thử sẽ ghi nhận các lỗi hoặc phảnhồi của khách hàng và báo lại với đơn vị phát triển phần mềm để lên kế hoạch sửachữa

1.7.4.2 Kiểm thử Bêta

- Phần mềm sẽ được gửi tới cho người dùng để kiểm thử trong môi trườngthực, lỗi hoặc phản hồi cũng sẽ gửi lại cho đơn vị phát triển phần mềm để lên kếhoạch sửa chữa

1.7.5 Kiểm thử hồi qui

Kiểm thử hồi qui là một hoạt động cấn thiết để chỉ ra rằng việc thay đổi mã nguồnkhông gây ra những ảnh hưởng bất lợi đến hệ thống nói chung

Mục đích kiểm thử: - Kiểm thử hồi qui dùng để kiểm tra các phần được sửa

chữa và các phần liên quan đến các phần sửa chữa trongphần mềm, để đảm bảo rằng những sự thay đổi đó khônggây ra lỗi trong những phần khác

2

Trang 35

Cách thực hiện: - Tái sử dụng các kịch bản kiểm thử từ những phần

kiểm thử trước để kiểm thử các mô-đun đã được sửachữa

- Sử dụng công cụ kiểm thử tự động: Tạo một sốtest script về chức năng

- Xây dựng một chương trình phân tích sơ sở hạtầng Chúng ta dựng một cơ sở hạ tầng có thể mở rộngđược để thực hiện và đánh giá chương trình phân tích.Dựa vào kết quả phân tích chúng ta xác định phạm vi cầnkiểm thử hồi qui

thành:

- Toàn bộ các trường hợp kiểm thử đã chọn đượcthực hiện và đạt yêu cầu

Bảng 1.5: Kiểm thử hồi qui

2

Trang 36

1.8 Kiểm thử tự động

1.8.1 Khái quát kiểm thử tự động

Ngày nay tự động hóa được ứng dụng ở rất nhiều lĩnh vực, mục đích thườngrất đa dạng và tùy theo nhu cầu đặc thù của từng lĩnh vực, tuy nhiên điểm chungnhất vẫn là giảm nhân lực, thời gian và sai sót Ngành Công nghệ Thông tin mà cụthể là phát triển phần mềm cũng không ngoại lệ Như vậy, để tạo ra sản phẩm Côngnghệ Thông tin hay phần mềm có chất lượng thì hoạt động kiểm thử phần mềm(KTPM) đó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 đó, nhu cầu tựđộng hoá qui trình KTPM cũng đượ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ànhcông cho hoạt động KTPM KTTĐ giúp giảm bớt công sức thực hiện, tăng độ tincậ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

Việc phát triển KTTĐ cũng tuân theo các bước phát triển phần mềm, chúng taphải xem việc phát triển KTTĐ giống như phát triển một dự án Hình 1.7 cho thấymối tương quan giữa KTTĐ và toàn bộ chu trình kiểm thử phần mềm

Hình 18 : Mối tương quan giữa KTTĐ và chu trình kiểm thử

Giống như phát triển phần mềm, để thành công trong KTTĐ chúng ta nên thựchiện các bước cơ bản sau:

2

Trang 37

Thu thập các đặc tả yêu cầu hoặc tình huống kiểm thử (test case); lựa chọnnhững phần cần thực hiện KTTĐ.

Phân tích và thiết kế mô hình phát triển KTTĐ

Phát triển lệnh đặc tả (script) cho KTTĐ

Kiểm tra và theo dõi lỗi trong script của KTTĐ

Áp dụng KTTĐ vào kiểm thử phần mềm cũng sẽ gặp phải những thuận lợi

và khó khăn sau:

Thuận lợi

 KTPM không cần can thiệp của kiểm thử viên

 Giảm chi phí khi thực hiện kiểm thử số lượng lớn test case hoặc test case lặplại nhiều lần

 Giả lập tình huống khó có thể thực hiện bằng tay

Khó khăn

Mất chi phí tạo các script để thực hiện KTTĐ

Tốn chi phí dành cho bảo trì các kịch bản

Đòi hỏi kiểm thử viên phải có kỹ năng tạo script KTTĐ

Không áp dụng được trong việc tìm lỗi mới của PM

1 Tạo test script Giai đoạn này chúng ta sẽ dùng test tool để ghi

lại các thao tác lên phần mềm cần kiểm thử và tự động sinh ra test script.

2 Chỉnh sửa test script Chỉnh sửa để test script thực hiện kiểm thử theo

đúng yêu cầu đặt ra, cụ thể là làm theo test case cần thực hiện.

3 Chạy test script để KTTĐ Giám sát hoạt động kiểm thử phần mềm của test

script.

4 Đánh giá kết quả Kiểm tra kết quả thông báo sau khi thực hiện

KTTĐ Sau đó bổ sung, chỉnh sửa những sai sót.

Bảng 1.6: Các bước thực hiện KTTĐ

1.8.2 Tại sao dùng công cụ kiểm thử phần mềm?

Công cụ kiểm thử (Test Tool) trong lĩnh vực phát triển phần mềm là công cụgiúp thực hiện việc kiểm thử phần mềm một cách tự động Tuy nhiên không phảimọi việc kiểm thử đều có thể tự động hóa, câu hỏi đặt ra là trong điều kiện hoặc tình

2

Trang 38

huống nào dùng công cụ kiểm thử là thích hợp? Việc dùng công cụ kiểm thử thườngđược xem xét trong một số tình huống sau:

Không đủ tài nguyên

Khi số lượng tình huống kiểm thử quá nhiều mà các kiểm thử viên không thểhoàn tất bằng tay trong thời gian cụ thể nào đó

Có thể lấy một dẫn chứng là khi thực hiện kiểm thử chức năng của mộtwebsite Website này sẽ được kiểm thử với sáu môi trường gồm ba trình duyệt vàhai hệ điều hành

Tình huống này đòi hỏi số lần kiểm thử tăng lên và lặp lại sáu lần so với việckiểm thử cho một môi trường cụ thể

Kiểm tra hồi quy

Trong quá trình phát triển phần mềm, nhóm lập trình thường đưa ra nhiềuphiên bản phần mềm liên tiếp để kiểm thử Thực tế cho thấy việc đưa ra các phiênbản phần mềm có thể là hàng ngày, mỗi phiên bản bao gồm những tính năng mới,hoặc tính năng cũ được sửa lỗi hay nâng cấp Việc bổ sung hoặc sửa lỗi code chonhững tính năng ở phiên bản mới có thể làm cho những tính năng khác đã kiểm thửtốt chạy sai mặc dù phần code của nó không hề chỉnh sửa Để khắc phục điều này,đối với từng phiên bản, kiểm thử viên không chỉ kiểm thử chức năng mới hoặc đượcsửa, mà phải kiểm thử lại tất cả những tính năng đã kiểm thử tốt trước đó Điều nàykhó khả thi về mặt thời gian nếu kiểm thử thủ công

Kiểm tra khả năng vận hành phần mềm trong môi trường đặc biệt

Đây là kiểm thử nhằm đánh giá xem vận hành của phần mềm có thỏa mãn yêucầu đặt ra hay không Thông qua đó kiểm thử viên có thể xác định được các yếu tố

về phần cứng, phần mềm ảnh hưởng đến khả năng vận hành của phần mềm Có thểliệt kê một số tình huống kiểm thử tiêu biểu thuộc loại này như sau:

Đo tốc độ trung bình xử lý một yêu cầu của web server

Thiết lập 1000 yêu cầu, đồng thời gửi đến web server, kiểm thử tình huống

1000 người dùng truy xuất web cùng lúc

2

Trang 39

Xác định số yêu cầu tối đa được xử lý bởi web server hoặc xác định cấu hìnhmáy thấp nhất mà tốc độ xử lý của phần mềm vẫn có thể hoạt động ở mức cho phép.

Việc kiểm thử thủ công cho những tình huống trên là cực khó, thậm chí “vôphương”

Cần lưu ý là hoạt động KTTĐ nhằm mục đích kiểm thử, phát hiện những lỗicủa phần mềm trong những trường hợp đoán trước Điều này cũng có nghĩa là nóthường được thực hiện sau khi đã thiết kế xong các tình huống (test case) Tuynhiên, như đã nói, không phải mọi trường hợp kiểm thử đều có thể hoặc cần thiếtphải tự động hóa, trong tất cả test case thì kiểm thử viên phải đánh giá và chọn ranhững test case nào phù hợp hoặc cần thiết để áp dụng KTTĐ dựa trên những tiêuchí đã đề cập bên trên

1.8.3 Phân loại một số công cụ kiểm thử tự động

Vì kiểm thử phần mềm thường chiếm tới 40% tất cả các nỗ lực dành cho một

dự án xây dựng phần mềm, nên công cụ có thể làm giảm thời gian kiểm thử sẽ rất

có giá trị Thừa nhận lợi ích tiềm năng này, các nhà nghiên cứu và người thực hành

đã phát triển một số thế hệ các công cụ kiểm thử tự động:

Bộ phân tích tĩnh: Các hệ thống phân tích chương trình này hỗ trợ cho việcchứng minh các lý lẽ tĩnh - những mệnh đề yếu kém về cấu trúc và định dạng củachương trình

Bộ thanh tra mã nguồn: Những bộ lọc chuyên dụng này được dùng để kiểm trachất lượng của phần mềm để đảm bảo rằng nó đáp ứng các chuẩn mã hoá tối thiểu

Bộ xử lý khẳng định: Những hệ thống tiền xử lý/hậu xử lý này được sử dụng

để cho biết liệu những phát biểu do người lập trình nêu, được gọi là các khẳng định,

về hành vi của chương trình có thực sự được đáp ứng trong việc thực hiện chươngtrình thực hay không

Bộ sinh trường hợp kiểm thử: Những bộ xử lý này sinh ra, và điền các giá trị

đã xác định vào các trường hợp kiểm thử cho chương trình đang được kiểm thử

Bộ sinh dữ liệu kiểm thử: Những hệ thống phân tích tự động này hỗ trợ chongười dùng trong việc chọn dữ liệu kiểm thử làm cho chương trình hành xử theomột cách đặc biệt

2

Trang 40

Bộ kiểm chứng kiểm thử: Những công cụ này đo mức bao quát kiểm thử bêntrong, thường được diễn tả dưới dạng có liên quan tới cấu trúc điều khiển của sự vậtkiểm thử, và báo cáo về giá trị bao quát cho chuyên gia đảm bảo chất lượng.

Dụng cụ kiểm thử: Lớp các công cụ này hỗ trợ cho việc xử lý các phép kiểm thử

Bộ so sánh kết quả đầu ra: Công cụ này làm cho người ta có thể so sánh một tập kếtquả đầu ra từ một chương trình này với một tập kết quả khác (đã được lưu giữtrước) để xác định sự khác biệt giữa chúng

Hệ thống thực hiện ký hiệu (symbolic execution system): Công cụ này thựchiện việc kiểm thử chương trình bằng cách dùng “dữ liệu vào” đại số, thay vì giá trị

dữ liệu số Phần mềm được kiểm thử xuất hiện để kiểm thử các lớp dữ liệu, thay vìchỉ là một trường hợp kiểm thử đặc biệt “Dữ liệu ra” là đại số và có thể được sosánh với kết quả trông đợi cũng được xác định dưới dạng đại số

Bộ mô phỏng môi trường: Công cụ này là một hệ thống dựa trên máy tínhgiúp người kiểm thử mô hình hoá môi trường bên ngoài của phần mềm thời gianthực và rồi mô phỏng các điều kiện vận hành thực tại một cách động

Bộ phân tích luồng dữ liệu: Công cụ này theo dõi dấu vết luồng dữ liệu điqua hệ thống và cố gắng tìm ra những tham khảo dữ liệu không xác định, đặt chỉ sốsai và các lỗi khác có liên quan tới dữ liệu

1.8.4 Chi phí thực hiện kiểm thử hiệu năng

Thực hiện kiểm tra hiệu năng thường tốn chi phí rất lớn Các chi phí liênquan kiểm tra hiệu suất có thể được phân loại là như sau:

Đầu tư để sản xuất các công cụ kiểm thử hiệu năng

Thời gian tiêu tốn trong việc chuẩn bị dữ liệu kiểm thử

Thực hiện kiểm thử tải trọng cơ sở hạ tầng, môi trường cài đặt nên càng cóthể gần các môi trường sản xuất

Trong trường hợp của các tổ chức hành chính, mua lại các khoản cần thiết làmột tẻ nhạt quá trình, từ các bài kiểm tra thường đòi hỏi nhiều quyền hành chính

2

Định dạng
Số trang	111
Dung lượng	5,48 MB