Nghiên cứu kỹ thuật kiểm thử phần mềm và ứng dụng trên môi trường DOT NET

Các công cụ kiểm thử có thể kiểm thử phần mềm với một số cấp độ tự động, qua đó những kiểm thử viên có thể giành thời gian để xem xét và giải quyết những vấn đề thuộc phạm vi có nhiều rủ

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

VŨ MINH HIẾU

NGHIÊN CỨU KỸ THUẬT KIỂM THỬ PHẦN MỀM VÀ ỨNG DỤNG

TRÊN MÔI TRƯỜNG DOT NET

Ngành: Công nghệ Thông tin

LỜI CẢM ƠN

Lời đầu tiên, tôi xin chân thành cảm ơn PGS.TS Đặng Văn Đức, Viện công nghệ thông tin, người đã định hướng đề tài nghiên cứu và tận tình hướng dẫn cho tôi hoàn thành luận văn cao học này

Tôi xin gửi lời cảm ơn chân thành tới Phòng Đào tạo sau đại học & NCKH, các thầy cô giáo trong Khoa Công nghệ - Trường Đại Học Công Nghệ - Đại Học Quốc Gia

Hà Nội đã giảng dạy, truyền đạt và tạo điều kiện học tập tốt nhất cho tôi suốt quá trình học cao học cũng như thời gian thực hiện luận văn cao học

LỜI CAM ĐOAN

Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của riêng

cá nhân, không sao chép lại của người khác Trong toàn bộ nội dung của luận văn, những điều được trình bày hoặc là của cá nhân hoặc được tổng hợp từ nhiều nguồn tài liệu Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn hợp pháp Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình

Hà Nội, ngày 18 tháng 11 năm 2008

Vũ Minh Hiếu

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN 2

MỤC LỤC 3

BẢNG CÁC TỪ VIẾT TẮT, KÝ HIỆU 6

THÔNG TIN HÌNH VẼ 8

THÔNG TIN BẢNG 9

MỞ ĐẦU 10

Đặt vấn đề 10

Nội dung của đề tài 12

Cấu trúc luận văn 12

CHƯƠNG 1: KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM 13

1.1 Tổng quan 13

1.2 Vai trò của kiểm thử phần mềm 13

1.3 Các công cụ kiểm thử phổ biến hiện nay 16

1.4 Những lợi ích của kiểm thử tự động 22

1.4.1 Áp dụng cho mô hình phát triển phần mềm XP 24

1.4.2 Đối với các kiểm thử viên 25

1.5 Phương pháp để kiểm thử tự động 26

1.6 Kiểm thử phần mềm và các ngôn ngữ lập trình 28

1.7 Kịch bản kiểm thử 31

1.8 Kết chương 33

CHƯƠNG 2: PHƯƠNG PHÁP VÀ CÁC THỂ LOẠI KIỂM THỬ PHẦN MỀM 34

2.1 Tổng quan 34

2.2 Các phương pháp kiểm thử 35

2.2.1 Kiểm thử tĩnh – Static testing 35

2.2.2 Kiểm thử động – Dynamic testing 35

2.3 Các chiến lược kiểm thử 35

2.3.1 Kiểm thử hộp đen – Black box testing 35

2.3.2 Kiểm thử hộp trắng – White box testing 37

2.3.3 Kiểm thử hộp xám – Gray box testing 37

2.4 Các cấp độ kiểm thử phần mềm 38

2.4.1 Kiểm thử mức đơn vị - Unit Test 39

2.4.2 Kiểm thử tích hợp - Integration Test 40

2.4.3 Kiểm thử mức hệ thống - System testing 42

2.4.4 Kiểm thử chấp nhận sản phẩm - Acceptance Test 44

2.4.5 Kiểm thử hồi quy - Regression Test 44

2.4.6 Kiểm thử tính đúng – Correctness testing: 45

2.5 Các phương pháp kiểm thử con người 45

2.5.1 Tổng duyệt – Walkthrough 46

2.5.2 Thanh tra mã nguồn – Code Inspection 46

2.6 Kết chương 47

CHƯƠNG 3: NGHIÊN CỨU XÂY DỰNG CÔNG CỤ KIỂM THỬ PHẦN MỀM TỰ ĐỘNG TRÊN MÔI TRƯỜNG NET 48

3.1 Đặt vấn đề 48

3.2 Đặc điểm của môi trường DOT NET và kiểm thử tự động 49

3.2.1 Sử dụng C# trong kiểm thử tự động 53

3.2.2 NET Reflection 58

3.2.3 Spreadsheets và XML 61

3.2.4 Không gian tên NET CodeDom 63

3.3 Phân tích và thiết kế hệ thống 66

3.3.1 Mô hình nghiệp vụ và các yêu cầu của hệ thống 66

3.3.2 Phân tích các trường hợp sử dụng 68

3.3.3 Biểu đồ trình tự 69

3.3.4 Biểu đồ trạng thái 70

3.3.5 Biểu đồ hợp tác 71

3.3.6 Biểu đồ lớp 71

3.3.7 Mô hình dữ liệu 72

3.4 Chạy thử chương trình 73

 Màn hình chính 73

 Lựa chọn hình thức kiểm thử đơn vị (Unit Test) 73

 Lựa chọn các đơn vị trong danh sách để kiểm thử 74

 File chứa dữ liệu kiểm thử 75

 Sinh kịch bản kiểm thử 75

 Thực thi kịch bản kiểm thử 76

3.5 Thử nghiệm và đánh giá 78

TÀI LIỆU THAM KHẢO 81

Common Language Runtime

Dynamic Link Library EXE

Intergrated Development Graphical user interface Environment

Microsoft Intermediate Language

eXtensible Markup Language

Trong môi trường Net, Một gói kết hợp Assembly là sự kết hợp của một hoặc nhiều module, hoặc file (dll, exe, html) cần để ứng dụng hoạt động Ngôn ngữ thời gian thực

Công nghệ thông tin Công nghệ phần mềm

Cơ sở dữ liệu Thư viện liên kết động Định dạng file thực thi của DOS, OpenVMS, Microsoft Windows, Symbian, và hệ điều hành OS/2 Môi trường phát triển tích hợp Giao diện người dùng đồ họa

Khách hàng Kiểm thử viên Kiểm thử tự động Mỗi một module là một file có thể thực thi Mỗi module có thể là một thư viện động (.dll) hoặc là một file thực thi (.exe)

Ngôn ngữ thông dịch của NET

Ngôn ngữ Đánh dấu Mở rộng

Phần mềm Phát triển phần mềm

XP

QTP

JVM

Extreme Programming QuickTest Professional

Java Virtual Machine

Lập trình cực đoan Công cụ kiểm thử phần mềm do hãng Mecury cung cấp

Máy ảo Java

Hình 2.1: Mối tương quan giữa phát triển và kiểm thử phần mềm

Hình 3.1: Mô hình quá trình xử lý tách thông tin

Hình 3.2: Mô hình xử lý sinh kịch bản kiểm thử

Hình 3.10: Cửa sổ giao diện chính

Hình 3.11: Cửa sổ chọn file phân tích

Hình 3.12: Cửa sổ chọn thuộc tính kiểm thử

Hình 3.13: File dữ liệu phân tích thuộc tính

Hình 3.14: Cửa sổ tạo file kịch bản kiểm thử

Hình 3.15: Cửa sổ thực hiện kiểm thử

Hình 3.16: File thông tin kết quả kiểm thử

THÔNG TIN BẢNG

Bảng 3.1: Không gian tên NET System

Bảng 3.2: Mã nguồn để kiểm thử phương thức objAdvancedCalc.Square()

Bảng 3.3: Mã nguồn kiểm thử phương thức objAdvancedCalc.SimpleCalc()

Bảng 3.4: Mã nguồn kiểm thử phương thức objAdvancedCalc.Sum()

Bảng 3.5: Mã nguồn kiểm thử phương thức objAdvancedCalc.GetType()

Bảng 3.6: Một số lớp (class) quan trọng trong không gian tên

System.Reflection

Bảng 3.7: Truy vấn thể loại System.Reflection.Assembly theo tên

Bảng 3.8: Truy vấn thông tin thể loại theo thể hiện của đối tượng

Bảng 3.9: Xác định thông tin thể loại của một tiến trình đang chạy

Bảng 3.10: Làm việc với Excel

Bảng 3.11: Các kiểu cung cấp bởi CodeDom để xây dựng không gian tên

Bảng 3.12: Cấu trúc của Test Script được sinh bởi không gian tên CodeDom

MỞ ĐẦU

Đặt vấn đề

Công nghệ thông tin là một trong những thuật ngữ được nhắc đến nhiều nhất hiện nay, nó xuất hiện trên các mặt báo, các phương tiện truyền thông, trên mạng Internet cho tới những tài liệu cũng như báo cáo chuyên ngành Điều này cũng dễ hiểu vì công nghệ thông tin được coi là một cuộc cách mạng cho sự phát triển của xã hội loài người

Kể từ năm 1981 khi chiếc máy vi tính đầu tiên của IBM được giới thiệu trên thị trường đánh dấu một mốc quan trọng cho sự tiến bộ của khoa học kỹ thuật Cho tới thời điểm hiện tại, trải qua một khoảng thời gian rất ngắn so với chiều dài lịch sử của xã hội loài người, tuy nhiên công nghệ thông tin đã phát triển rất nhanh (còn được diễn tả bằng cụm từ: “bùng nổ”) Công nghệ thông tin đã được ứng dụng trong hầu hết các lĩnh vực của xã hội, và thực tế đã chứng minh được tầm quan trọng của nó

Trong hai thập kỷ qua phần mềm đã trở thành một thành phần của hầu hết các doanh nghiệp Hầu như tất cả các doanh nghiệp hoạt động trong mọi lĩnh vực tại Việt Nam cũng như trên toàn Thế Giới đều sử dụng phần mềm Phần mềm được áp dụng trong việc hỗ trợ phát triển, sản xuất, tiếp thị, và hỗ trợ cho các sản phẩm - dịch vụ của doanh nghiệp

Thúc đẩy sự phát triển của công nghệ thông tin luôn là chính sách được ưu tiên hàng đầu của các quốc gia nhằm làm tiền đề cho sự phát triển của khoa học kỹ thuật và kinh tế - xã hội

Công nghệ thông tin là ngành ứng dụng công nghệ vào quản lý và xử lý thông tin, đặc biệt trong các cơ quan, doanh nghiệp Ở Việt Nam thì khái niệm công nghệ thông tin được hiểu theo nghĩa sau: “Công nghệ thông tin là tập hợp các phương pháp khoa học, các phương tiện và công cụ kỹ thuật hiện đại - chủ yếu là kỹ thuật máy tính

và viễn thông - nhằm tổ chức khai thác và sử dụng có hiệu quả các nguồn tài nguyên thông tin rất phong phú và tiềm năng trong mọi lĩnh vực hoạt động của con người và

xã hội”

Công nghệ thông tin là sự kết hợp của hạ tầng phần cứng và nền tảng phần mềm

Hạ tầng phần cứng sẽ ngày càng mạnh mẽ là tiền đề cho phép phần mềm cũng ngày

càng lớn và phức tạp hơn Chính vì lý do này mà Công nghệ phần mềm (quy trình phát triển phần mềm) đã được chú tâm bàn thảo từ rất sớm nhằm tìm ra những phương pháp

để phát triển phần mềm thuận tiện có chất lượng cao đáp ứng tốt nhu cầu ngày càng đa dạng và phức tạp

Hầu hết các quy trình phát triển phần mềm đều trải qua các bước từ xác định yêu cầu, phân tích, xây dựng, kiểm thử, cho tới triển khai và bảo trì Trong đó kiểm thử phần mềm là một công việc khá phức tạp, tốn nhiều công sức và cũng là điều kiện tiên quyết cho một sản phẩm phần mềm có chất lượng tốt

Bất kỳ sản phẩm phần mềm nào cho dù đã áp dụng kỹ thuật kiểm thử tiên tiến nhất hiện nay đều có phát sinh lỗi Một số lỗi đã được phát hiện và chỉnh sửa trong thời gian lập trình Một số khác được tìm ra và chỉnh sửa trong các hình thức kiểm thử (vd: kiểm thử module) Các doanh nghiệp phần mềm đều nhận ra một thực tế là có nhiều lỗi phần mềm vẫn chưa được phát hiện và một số sẽ được sửa sau đó thông qua những bản vá lỗi hoặc nâng cấp Kiểm thử là điều kiện tiên quyết cho một phần mềm hoàn thiện, tuy nhiên với kỹ thuật kiểm thử hiện nay việc đảm bảo cho một phần mềm hoàn hảo (không có lỗi) là một việc rất khó khăn, tốn thời gian, và tưởng chừng như không thể Theo thống kê của Tassey năm 2002, thì lỗi trong những phần mềm đóng gói gây thiệt hại cho nền kinh tế Mỹ khoảng 59,5 tỷ USD [9]

Kiểm thử chiếm khoảng 25% tới 50% tổng chi phí phát triển một phần mềm Bộ phận kiểm thử thường gồm các kỹ sư với vai trò là kiểm thử viên, người sử dụng công

cụ, và những người phát triển công cụ kiểm thử Ngân sách và con người đều đóng vai trò quan trọng vì một sản phẩm trong quá trình xây dựng phải được kiểm thử một cách tốt nhất và hiệu quả nhất

Vào năm 2008, tổng doanh thu của phần mềm Việt Nam đạt trên 500 triệu USD (tổng doanh thu trên toàn thế giới vào khoảng 519 tỷ USD - theo: http://softwaremag.com) Số lượng các kỹ sư và lập trình viên tại Việt Nam năm 2008 vào khoảng 13.500 người Những con số trên dựa trên tổng kết của Hiệp hội Doanh nghiệp phần mềm Việt Nam (vinasa: http://www.vinasa.org.vn) Giảm chi phí phát triển phần mềm và nâng cao chất lượng phần mềm là mục tiêu quan trọng của các ngành công nghiệp phần mềm Việt Nam Một nghiên cứu tương tự cũng cho biết rằng

các ngành công nghiệp phần mềm bị thiệt hại về kinh tế, vì không có đủ cơ sở hạ tầng cho việc kiểm thử phần mềm

Hiện nay có khá nhiều công cụ kiểm thử được giới thiệu trên thị trường Tuy nhiên, vẫn còn phải xem xét về khả năng đáp ứng được nhu cầu về đảm bảo chất lượng phần mềm xét trên nhiều khía cạnh khác nhau Các công cụ kiểm thử có thể kiểm thử phần mềm với một số cấp độ tự động, qua đó những kiểm thử viên có thể giành thời gian để xem xét và giải quyết những vấn đề thuộc phạm vi có nhiều rủi ro hơn, tuy nhiên, tính tự động của các công cụ mới chỉ dừng ở các kỹ thuật đơn giản và những kịch bản kiểm thử bao gồm chuỗi sự kiện nhấn chuột hoặc bàn phím Kiểm thử viên mong đợi các công cụ kiểm thử hiệu quả và linh hoạt hơn với các tính năng tự động cao để có thể theo kịp sự phát triển rất nhanh trong công nghệ phần mềm hiện nay Mục tiêu của Luận văn là nghiên cứu kỹ thuật phát triển một công cụ kiểm thử tự động, có thể kiểm thử một sản phẩm phần mềm phức tạp một cách hiệu quả với yêu cầu tác động của con người là ít nhất

Nội dung của đề tài

Xuất phát từ việc phân tích và mục tiêu nêu trên, nội dung của đề tài luận văn sẽ bao gồm những vấn đề chính sau:

- Nghiên cứu, tìm hiểu các vấn đề tổng quan về kiểm thử phần mềm

- Nghiên cứu kiến trúc và các thể loại kiểm thử phần mềm

- Nghiên cứu xây dựng công cụ kiểm thử phần mềm tự động trên môi trường Dot Net và thử nghiệm

Cấu trúc luận văn

Luận văn sẽ được chia thành 3 chương chính dựa vào nội dung nêu trên:

- Chương 1: Khái quát về kiểm thử phần mềm

- Chương 2: Phương pháp và các thể loại kiểm thử phần mềm

- Chương 3: Nghiên cứu xây dựng công cụ kiểm thử phần mềm tự động trên môi trường NET

CHƯƠNG 1: KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM

1.1 Tổng quan

Kiểm thử phần mềm là một trong những khâu quan trọng của quy trình phát triển phần mềm nhằm kiểm tra xem phần mềm làm ra có những lỗi gì cần khắc phục Kiểm thử không thể chứng minh được phần mềm là hết lỗi mà nó chỉ giúp cho người viết mã nguồn tìm ra và có biện pháp khắc phục càng nhiều lỗi càng tốt

Bản chất của kiểm thử phần mềm là các cách thức làm việc với máy tính và chương trình, tuy nhiên với những phần mềm lớn, việc kiểm thử cũng yêu cầu có sự phối hợp của nhiều nhóm chuyên môn phụ trách các thành phần riêng biệt, cho nên kiểm thử cũng cần các kĩ năng của con người

Để thực hiện tốt công việc kiểm thử, ngoài nắm vững các kĩ thuật kiểm thử điển hình, kiểm thử viên cũng cần xây dựng kế hoạch kiểm thử, chuẩn bị dữ liệu kiểm thử, tiến hành kiểm thử, viết báo cáo về kết quả kiểm thử, và cần biết quản lí toàn bộ công việc kiểm thử

Kiểm thử cần được nhìn theo nhiều góc độ khác nhau liên quan tới phần mềm: kiểm thử chức năng, kiểm thử hiệu năng, cấu hình, an ninh và liên quan tới qui trình kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận; đồng thời phải thực hiện quản lí toàn bộ quá trình kiểm thử: ghi lại hoàn cảnh lỗi, việc sửa chữa, kiểm thử rà lại

1.2 Vai trò của kiểm thử phần mềm

Các lỗi trong phần mềm không chỉ làm phiền phức và bực mình cho người dùng

mà chúng còn gây tổn thất rất lớn cho nền kinh tế Đơn cử hàng năm nền kinh tế Mỹ thiệt hại khoảng 59,5 tỷ USD do lỗi phần mềm gây ra (thông số được công bố bởi Viện Công nghệ và Tiêu chuẩn quốc gia (NIST) thuộc Bộ Thương mại Mỹ)

Theo Giám đốc Arden Bement của NIST, hiện nay mọi ngành ở Mỹ gần như đều phụ thuộc vào phần mềm để phát triển, từ khâu sản xuất đến khâu phân phối và hỗ trợ khách hàng Bởi thế, các lỗi kỹ thuật phần mềm là vô cùng nguy hiểm

Những người sử dụng phần mềm chịu thiệt hại một nửa và nửa còn lại dành cho các nhà phát triển và kinh doanh phần mềm Nghiên cứu cũng cho thấy, việc kiểm thử

để phát hiện và loại bỏ những khiếm khuyết ngay từ ban đầu có thể giảm mức thiệt hại khoảng 22,2 tỷ USD cho Mỹ trong vòng 1 năm

Hiện nay, có hơn một nửa số lỗi không được phát hiện cho đến khi phần mềm đã được tung ra thị trường Chính vì lý do này mà Viện Hàn lâm Khoa học Mỹ đã đề nghị các nhà lập pháp thông qua điều luật yêu cầu những hãng sản xuất phần mềm phải có trách nhiệm về vấn đề bảo mật và lỗi phần mềm

Theo các số liệu của tạp chí SoftwareMag (softwaremag.com) năm 2007 tổng doanh thu của CNPM trên toàn Thế Giới là 451.8 tỷ USD và tăng 14,7% so với năm

2006 Bên cạnh sự phát triển mạnh mẽ của nghành công nghiệp phần mềm thì những lỗi – khiếm khuyết của phần mềm cũng xảy ra ngày càng thường xuyên, dẫn tới những tổn thất do nó gây ra cũng ngày càng nặng nề hơn Dưới đây là một vài ví dụ điển hình

về sự tổn thất đó

Một trong những lỗi phần mềm điển hình về mức độ thiệt hại là vào tháng 4 năm

1999, một lỗi phần mềm đã gây ra lỗi hệ thống phóng tên lửa Quân sự của Mỹ làm thiệt hại 1.2 tỉ USD Đây có lẽ là một lỗi phần mềm gây thiệt hại kinh tế lớn nhất trong lịch sử công nghiệp phần mềm Chính điều này đã thúc đẩy một cuộc tổng điều tra trong ngành quân sự và nền công nghiệp của Mỹ về vấn đề tích hợp phần mềm và quy trình kiểm thử

Một ví dụ điển hình khác cũng hay được nhắc tới là tai nạn khi phóng Vệ tinh thăm dò thời tiết Sao Hỏa của NASA vào tháng 10 năm 1999 Nguyên nhân của sự việc là do trục trặc trong một bộ phận của phần mềm ở chức năng chuyển đổi chuẩn

độ đo của Anh sang chuẩn độ đo mét Năm 2002, người ta đã phát triển một module dành cho việc kiểm thử dụng cụ Quang học nhằm đảm bảo không có việc lẫn lộn giữa các phép đo Nếu Vệ tinh thăm dò thời tiết của Sao Hỏa được trang bị module này thì

đã không xảy ra tai nạn đáng tiếc trên đây

Đảm bảo chất lượng phần mềm cần được quan tâm một cách đúng mức, và đòi hỏi những người liên quan có kiến thức và đánh giá đúng về vai trò của kiểm thử phần mềm, gồm: các quản trị viên cao cấp, quản lý dự án, nhân viên phát triển phần mềm,

nhân viên kiểm thử phần mềm và người dùng cuối Khi bắt đầu một dự án dựa theo các mô hình phát triển phần mềm, những người dùng cuối, lập trình viên, kiểm thử viên, và quản trị viên cao cấp đều phải nắm được yêu cầu phần mềm, các đặc tả phần mềm và các chiến lược kiểm thử

Trong hầu hết các mô hình phát triển phần mềm thì kiểm thử được lên kế hoạch ngay từ thời điểm bắt đầu dự án và được thực thi song song với vòng đời phát triển của phần mềm Chúng ta sẽ không thể kiểm thử một sản phẩm nếu không có hiểu biết chi tiết về nó Kiểm thử một sản phẩm đang trong giai đoạn được xây dựng sẽ luôn là một trải nghiệm bổ ích cho các kiểm thử viên Thời gian và nỗ lực của kiểm thử viên phụ thuộc vào độ phức tạp của một sản phẩm cũng như kinh nghiệm của anh ta trong lĩnh vực kiểm thử phần mềm

Sẽ rất hữu ích nếu ta sử dụng các công cụ kiểm thử tự động, điều này sẽ hạn chế bớt việc các kiểm thử viên phải giành quá nhiêu thời gian cho công việc nghiên cứu một sản phẩm mới Qua đó họ có thể giành thời gian nhiều hơn tập trung cho những vấn đề, những yếu tố phức tạp và rủi ro cao trong khi vận hành phần mềm

Kiểm thử phần mềm là một tiến trình thử thách, trải nghiệm một ứng dụng để tìm

ra lỗi và để xác định rằng chúng đáp ứng được những yêu cầu nhất định Trong vòng đời phát triển phần mềm, các lập trình viên và kiểm thử viên cùng làm việc để tìm ra lỗi và đảm bảo cho chất lượng của sản phẩm Các sản phẩm phần mềm đã được chuyển giao sẽ phải bao hàm tất cả các chức năng được yêu cầu và phải tương thích với hạ tầng phần cứng của khách hàng

Trong một thời gian dài, kiểm thử phần mềm đã được thực hiện một cách thủ công; có nghĩa là những kiểm thử viên chạy ứng dụng dựa trên những tiến trình đã được định sẵn Kể từ thời điểm ban đầu của nền công nghiệp phần mềm, các kiểm thử viên đã tạo ra những tiến trình kiểm thử tự động khá hiệu quả Nhiều công ty phần mềm danh tiếng đã tạo ra những công cụ kiểm thử phần mềm mà hiện nay đang được chào bán rộng rãi trên thị trường Ngày nay, có nhiều công cụ kiểm thử trên thị trường

đã được dùng để tìm ra lỗi để có biện pháp chỉnh sửa kịp thời trước khi chuyển giao Như đã đề cập ở trên, những công cụ này thực thi một số tác vụ một cách tự động

(thực hiện một vài kế hoạch và sinh ra kịch bản kiểm thử), tuy nhiên nó vẫn tồn tại một số khuyết điểm sau:

 Các kịch bản kiểm thử, tự thân chúng cũng cần được kiểm thử

 Không thể thực hiện tất cả các tiến trình kiểm thử một cách độc lập

 Chúng thực thi các tiến trình có thể không thống nhất hoàn toàn với thiết

kế phần mềm của tổ chức

 Một vài tiến trình được phân tách từ việc tự sinh kịch bản kiểm thử

Trong hầu hết các trường hợp, tạo lập hoặc ghi lại một kịch bản kiểm thử cho mỗi thành phần của một assembly là một công việc phức tạp mà các kiểm thử viên phải thực hiện Tạo và lập tài liệu cho dữ liệu kiểm thử với các công cụ hiện tại đều hoàn toàn sử dụng sức người Do vậy, khả năng tự động của những công cụ kiểm thử

sẽ bị hạn chế

Nội dung của luận văn là nghiên cứu để phát triển một công cụ kiểm thử phần mềm sao cho kiểm thử viên không cần viết các kịch bản kiểm thử bằng tay hoặc phải ghi lại các kịch bản kiểm thử một cách thủ công Tiến trình kiểm thử phần mềm sẽ được thực thi với yêu cầu tương tác trực tiếp từ con người là ít nhất Công cụ được thiết kế để giảm bớt và sát với yêu cầu của hầu hết các sản phẩm phần mềm Đồng thời đây cũng là cách thức để tạo ra các module có thể sử dụng lại để kiểm thử nhiều mã nguồn khác nhau

1.3 Các công cụ kiểm thử phổ biến hiện nay

Trên thị trường hiện nay có nhiều công cụ kiểm thử phần mềm Với các nhà cung cấp như: Rational Software của IBM, Mercury Interactives, Segue Software Hiện có nhiều nhà cung cấp khác và cũng có một số công cụ kiểm thử nguồn mở như Ant, JUnit, và JProbe… Sau đây là một số công cụ kiểm thử phần mềm được sử dụng phổ biến hiện nay:

 Visual Studio Team System Test Edition

Hình 1.1: Mô hình tổ chức Visual Studio Team System 2008 Team Foundation Server

Visual Studio Team System Test Edition bao gồm một bộ công cụ thử nghiệm đã được tích hợp chặt chẽ với Visual Studio Nó không chỉ làm việc trong khuôn khổ của nền tảng kiểm thử, mà còn tham gia vào một nền tảng lớn hơn tham gia vào các khâu khác trong toàn bộ vòng đời của phần mềm

Test Edition cho phép ta tạo, quản lý, chỉnh sửa và chạy công việc kiểm thử, đồng thời cũng nhận được và lưu trữ kết quả kiểm thử Visual Studio tích hợp một vài loại thử nghiệm bao gồm: kiểm thử đơn vị (Unit Test), kiểm thử web (Web Test), kiểm thử chịu tải (Load Test), và các kiểm thử thủ công

Thực hiện kiểm thử bằng cách sử dụng môi trường phát triển tích hợp của Visual Studio (IDE Visual Studio) Ngoài ra, có thể chạy các nhóm thử nghiệm hoặc kiểm tra bất kỳ đơn vị thử nghiệm độc lập nào khác bằng cách sử dụng dòng lệnh (command line)

Do các công cụ thử nghiệm được tích hợp với các thành phần khác của Visual Studio Team System, nên kiểm thử viên có thể lưu trữ kết quả vào cơ sở dữ liệu, tạo ra các hình thức báo cáo khác nhau, so sánh các loại dữ liệu, và xem có bao nhiêu lỗi, là những lỗi nào đã được tìm thấy bởi công cụ kiểm thử

Đây quả là một công cụ mạnh mẽ mà Microsoft trang bị cho bộ sản phẩm Visual Studio của mình Với lợi thế là tích hợp chặt chẽ vào môi trường phát triển phần mềm, công cụ sẽ giảm bớt được nhiều công sức trong quá trình thực hiện các thao tác kiểm

thử, đồng thời việc quản lý nó cũng thống nhất trong suốt quá trình phát triển phần mềm Tuy nhiên để sở hữu được bộ công cụ này thì chúng ta cũng phải bỏ ra một khoản chi phí khá lớn, vào khoảng 5.200 USD Đồng thời chúng ta cũng phải trang bị nền tảng Visual Studio Team System 2008 Team Foundation Server (mức giá tham khảo: 2.500 USD) để có thể tích hợp bộ công cụ này

 QuickTest Professional

Hình 1.2: Giao diện QuickTest Professional

QuickTest Professional (QTP) với phiên bản mới nhất 9.5 của hãng Mercury khá tốt và mạnh, bao gồm nhiều chức năng điển hình của một công cụ kiểm thử tự động QTP là công cụ dùng để kiểm tra chức năng (functional test) và cho phép thực hiện kiểm tra hồi qui (regression test) một cách tự động Đây cũng là công cụ áp dụng phương pháp Keyword-Driven, một kỹ thuật tạo kịch bản kiểm thử (lập trình trong kiểm thử tự động) hiện đại, cho phép kiểm thử viên bổ sung Test Case bằng cách tạo file mô tả cho nó mà không cần phải chỉnh sửa hay bổ sung bất cứ kịch bản nào Nó cũng phù hợp trong tình huống chuyển giao công việc mà người mới tiếp nhận chưa có thời gian hoặc không hiểu kịch bản vẫn có thể thực hiện được

QTP giúp chúng ta kiểm thử phần mềm theo hướng chức năng trên rất nhiều loại chương trình phần mềm khác nhau Tuy nhiên Mercury chỉ hỗ trợ sẵn một số loại

chương trình thông dụng như: Ứng dụng Windows; Ứng dụng web theo chuẩn HTML, XML; Ngôn ngữ lập trình C#, VB NET

Một số loại chương trình khác yêu cầu cài đặt thêm thành phần bổ sung của QTP thì mới thực hiện kiểm tra được, như: NET Framework 1.1, 2.0, 3.5; Các đối tượng chuẩn của NET và các đối tượng khác thừa kế từ các đối tượng chuẩn; Java; Sun JDK;

- Hỗ trợ làm việc theo nhóm thông qua việc chia sẻ thư viện, thống nhất quản lý Object Repository

- Thực tế cho thấy, QTP thực hiện kiểm thử tự động trên nhiều trình duyệt cùng lúc tốt hơn những công cụ khác

- Với chức năng Recovery Scenarios, QTP cho phép xử lý những sự kiện hoặc lỗi không thể đoán trước có thể làm kịch bản bị dừng trong khi đang chạy

- QTP có khả năng hiểu kịch bản kiểm thử của Mercury Winrunner (một công cụ kiểm tra khác của Mercury)

Nhược điểm:

- Chưa hỗ trợ tốt trên nhiều nền tảng công nghệ khác nhau

- Giá thành khá cao: cho một máy 9.000 USD; cho nhiều máy dùng cùng lúc 12.000 USD

 JMeter

Hình 1.3: Logo JMeter

JMeter của Apache Jakarta là công cụ được phát triển bởi ngôn ngữ Java cho phép kiểm tra máy chủ Web và thêm vào đó là khả năng kiểm tra các ứng dụng với các giao thức khách như JDBC, FTP, và LDAP Thực tế, với công cụ mở rộng và cho phép người dùng tạo ra các tình huống giả định thì người dùng có khả năng kiểm tra bất kỳ giao thức nào thông qua Java Với chế độ mặc định nó có thể đưa ra những file CSV

để dễ dàng truyền các tham số vào cơ sở dữ liệu và đưa ra được rất nhiều thông tin hơn CSV Đây là công cụ được rất nhiều người mới vào nghề sử dụng trong vô số các công

cụ khác đang có trên mạng Internet

 JUnit, NUnit

JUnit là một framework đơn giản dùng cho việc tạo các Unit Testing tự động, và chạy các tác vụ kiểm thử có thể lặp đi lặp lại Nó là một phần của họ kiến trúc xUnit cho việc tạo các unit testing JUnit là một chuẩn trên thực tế cho unit testing trong Java JUnit về nguồn gốc được viết bởi 2 tác giả Erich Gamma và Kent Beck Tương

tự, NUnit là phiên bản dùng cho các sản phẩm phát triển trên nền tảng NET, nó có thể tích hợp với Microsoft Visual Studio

Đây là một bộ công cụ giành cho Unit Test rất hiệu quả và hoàn toàn miễn phí Tuy nhiên công cụ mới dừng ở việc kiểm thử thành phần, chưa mở rộng thêm các hình thức kiểm thử khác

 Một số công cụ kiểm thử phổ biến khác

Công cụ kiểm thử thành phần (component hoặc unit test):

- QACenter - Compuware

- PurifyPlus - IBM Rational

- Tau Architect và Tau Developer - Telelogic

- C++ Test, Java Test, Insure++, và Test - Parasoft

Công cụ kiểm thử chức năng (function test):

- WinRunner - Mercury Interactive

- QuickTest Professional - Mercury Interactive

- Astra QuickTest - Mercury Interactive

- QACenter - Compuware

- SilkTest - Segue Software

- Rational Suite TestStudio - IBM Rational

- TauTester - Telelogic

- e-Test suite - Empirix

- Webking - Parasoft

- WetFT - RadView Software

Công cụ kiểm thử chịu tải (performance/load-test):

- LoadRunner - Mercury Interactive

- Astra LoadTest - Mercury Interactive

- QACenter - Compuware

- WebLoad - RadView Software

- Rational Suite TestStudio - IBM Rational

- SilkPerformer - Segue

- e-Test suite - Empirix

- webking - Parasoft

- Test Perspective - Keynote Systems

- LoadPro - Keynote Systems

Công cụ theo dõi thực thi (performance-monitoring):

- Vantage - Compuware

- Topaz - Mercury Interactive

- OneSight - Empirix

- FarSight - Empirix

- Rational Suite TestStudio - IBM Rational

Công cụ quản lý kiểm thử (test-management):

- QA Director - Compuware

- TestDirector - Mercury Interactive

- Rational Suite TestStudio - IBM Rational

- SilkPlan Pro - Segue

Với tư cách là một người làm việc trực tiếp trong lĩnh vực sản xuất phần mềm và

là người nghiên cứu Luận văn này, tôi đã đánh giá cao những khả năng tuyệt vời của các công cụ kiểm thử hiện có, mặc dù tính tự động và hiệu quả của chúng chưa được như mong muốn Những hạn chế trong các công cụ được thương mại hóa gặp phải là thường không theo kịp với các thay đổi của công nghệ và khó thích ứng với quá trình thiết kế mới trong các ngành công nghiệp phần mềm Trong luận văn này, tôi sẽ nghiên cứu đề xuất nâng cấp các cơ sở hạ tầng kiểm thử để tránh được những hạn chế này

1.4 Những lợi ích của kiểm thử tự động

Người ta mong đợi gì ở một công cụ tự động kiểm thử phần mềm? Đó là tiết kiệm thời gian cũng như chi phí, các chuẩn sẽ được tuân theo một cách nghiêm ngặt,

và tất nhiên chất lương phần mềm sẽ được nâng cao

Kiểm thử phần mềm vẫn luôn giữ một vai trò quan trọng trong ngành công nghiệp phần mềm Thường bao hàm việc đào tạo các kiểm thử viên và yêu cầu họ học những kỹ thuật kiểm thử trước khi một dự án được bắt đầu Cùng với khả năng cũng như kinh nghiệm của đội ngũ kiểm thử tăng nên thì tính tự động trong công việc cũng được nâng cao Khi kiểm thử một sản phẩm hoàn toàn mới cũng chính là một quá trình trau dồi kinh nghiệm cho mỗi kiểm thử viên Những hiểu biết sâu sắc về dự án sẽ giúp cho tính tự động trong công việc của họ tăng lên

Về mặt kỹ thuật, rất nhiều tác vụ kiểm thử có thể được thực hiện một cách tự động Tuy nhiên, quản lý khả năng tự động hóa của các tác vụ kiểm thử cũng được coi

như các vấn đề về mặt kỹ thuật và cần được nghiên cứu kỹ càng Quá trình phân tích cần xác định rõ các thông tin sau:

 Ngày nay các dự án phần mềm thường rất phức tạp và được giành để giải quyết các vấn đề phức tạp Các công cụ kiểm thử phần mềm thương mại thường cần nhiều thời gian để tìm hiểu về một vấn đề riêng biệt và để theo kịp công nghệ Để đáp ứng được khung thời gian hạn chế của một dự án, các kiểm thử viên cũng cần tự phát triển một công cụ kiểm thử cho riêng mình để có thể bổ sung khiếm khuyết cho các công cụ kiểm thử thương mại trên thị trường

 Đôi khi các kiểm thử viên cần xác định hoặc là kết hợp kiểm thử tự động vào những dự án đang thực hiện hoặc sẽ kết hợp vào dự án hoàn toàn mới Bước đầu tiên của các tiến trình kiểm thử sẽ luôn liên quan tới kiểm thử bằng tay Các kiểm thử viên sử dụng chúng như là một cách để nghiên cứu

về tiến trình phần mềm Giống như các tiến trình phần mềm, các kiểm thử viên trở nên hiểu biết sâu sắc hơn về sản phẩm và các vấn đề tiềm tàng mà

họ có thể dự đoán trước Các công cụ kiểm thử tự động sau đó có thể được

bổ sung vào để làm việc với từng vấn đề cụ thể

 Các tổ chức đã phát triển một mô hình phát triển phần mềm mang tên “lập trình cực đoan” (Extreme Programming - XP) cho những dự án có rủi ro cao trong do yêu cầu phần mềm không thống nhất Họ không làm rõ được chi tiết các yêu cầu ngay từ đầu Thay vào đó mã nguồn của họ có thể hoàn toàn được chỉnh sửa hoặc cập nhật thường xuyên Các kịch bản kiểm thử là một phần của mã nguồn điều khiển cùng với mã nguồn của chương trình Trên thực tế, kiểm thử tự động khó có thể áp dụng cho mô hình XP

do những kịch bản kiểm thử có thể được chỉnh sửa và trả về với mỗi quá trình phát triển tích hợp

 Hiếm khi một tổ chức có thể không chú ý tới những công cụ kiểm thử tự động Để quản lý chất lượng, việc phát triển một công cụ kiểm thử tự động

là một bước thúc đẩy cho việc phát triển dự án

Vòng đời của một mô hình phát triển phần mềm cũng tác động tới việc mở rộng các tiến trình kiểm thử tự động:

 Thường thì việc thay đổi xảy ra thường xuyên trong giai đoạn bắt đầu dự

án Mục đích của ta là phát triển một công tụ để sinh tự động các kịch bản kiểm thử, nó cần phản ánh được những thay đổi đồng thời đem lại lợi ích

và hiệu quả đối với những sản phẩm không có tính thống nhất hay dễ bị thay đổi

 Những công cụ kiểm thử thương mại có khả năng kiểm thử các thành phần giao diện người dùng (GUI) Trong hầu hết thời gian, những người dùng cần ghi lại một dãy các thao tác click chuột và nhấn bàn phím Dữ liệu của các kịch bản kiểm thử thường bị cứng hóa Đôi khi các kịch bản kiểm thử cũng cần xem xét lại và gỡ lỗi (debug) trước khi được đưa vào thi hành Trên thực tế việc sử dụng và dùng lại những công cụ này trong những sản phẩm không ổn định sẽ là một thảm họa Một công cụ kiểm thử tự động cần có khả năng tự nhận biết và xác minh các thành phần giao diện người dùng và tự sinh ra các dữ liệu dẫn hướng kịch bản kiểm thử

 Cùng với tiến bộ của công nghệ, việc lập trình cũng trở lên dễ dàng hơn Vòng đời phát triển phần mềm cũng ngắn hơn, đồng nghĩa với việc cho phép ít thời gian hơn để kiểm thử Một công cụ kiểm thử tự động sẽ làm nhẹ bớt áp lực cho các kiểm thử viên để họ có nhiều thời gian hơn cho việc nhận diện những vùng rủi ro cao của dự án

1.4.1 Áp dụng cho mô hình phát triển phần mềm XP

Kent Beck tạo ra mô hình XP trong cuốn sách của ông mang tên Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999) Theo định nghĩa

XP là một kỹ thuật nhẹ nhàng tập trung cho việc lập trình những dự án phần mềm có tính rủi ro cao Nó tránh việc định rõ chi tiết các đặc tả và nhìn nhận các tác vụ một cách đơn giản Để thực hiện các vấn đề phức tạp, nó dựa vào dãy các tương tác và giao tiếp giữa lập trình viên, kiểm thử viên, và khách hàng

Quyền ưu tiên đầu tiên của việc quản lý một dự án XP là phải chắc chắn rằng cuối cùng thì tất cả các yêu cầu của KH phải được thỏa mãn Tuy nhiên các nhà phát triển sử dụng mô hình XP tin rằng không cần thiết phải tập trung vào KH để thấy trước được yêu cầu của một sản phẩm Các lập trình viên không phải là thầy bói và cũng

không cần xác định tất cả các yêu cầu trước khi thực hiện công việc lập trình Sẽ hiệu quả hơn nếu cung cấp cho khách hàng những sản phẩm đơn giản ngay khi có thể Sau

đó khách hàng có thể sử dụng thử sản phẩm và thêm hoặc thay đổi yêu cầu của họ Sau cùng lập trình viên sẽ nhận được sản phẩm cuối cùng thông qua việc xem xét lại mã nguồn, tự động kiểm thử, và tiếp tục tích hợp vào sản phẩm

Tự động kiểm thử là một yếu tố chủ đạo tạo nên thành công của mô hình XP Cần kiểm thử khi một dòng mã lệnh mới được thêm vào và khi một phương thức hoặc một dòng mã lệnh được thay đổi hoặc bị xóa Mã lệnh thường thay đổi và tiến hóa liên tục, và đôi khi lập trình viên không nhận thức hết được những thay đổi sẽ diễn tiến ra sao Chỉ có dựa vào dãy tiến trình kiểm thử thì lập trình viên mới nhận ra được thay đổi của mã lệnh đã được xác thực, hay phê chuẩn

Cùng với việc thay đổi các yêu cầu, mô tả, và mã lệnh, kiểm thử cần được tự động để ghi chú lại những thay đổi phá vỡ hệ thống Không giống việc viết mã lệnh trong những mô hình khác, với mô hình XP thì mã lệnh có trạng thái lỏng hơn Có thể được thiết kế lại, xóa, và tự hoàn thành Sau cùng kiểm thử sẽ đảm bảo cho hệ thống vẫn hoạt động Mô hình XP cần một kiểm thử lặp đi lặp lại cho những lớp giao diện (interface) của lớp (class) và thành phần (component) Sự thực thi của hệ thống được thay đổi khi những kiểm thử tự động phê chuẩn hệ thống vẫn đáp ứng được giao kèo của các interface Chỉ sau khi một chức năng mới hoặc một chức năng được thay đổi

đã được phê chuẩn bởi kiểm thử thì nó mới được tích hợp vào hệ thống Mọi thứ có thể gây đổ vỡ phải được kiểm thử trước Công cụ kiểm thử tự động được nghiên cứu thử nghiệm trong Luận văn này sẽ giúp tự động hóa quá trình kiểm thử của mô hình

XP

1.4.2 Đối với các kiểm thử viên

Luận văn tập trung vào việc nghiên cứu để phát triển một công cụ để tự động kiểm thử phần mềm Sự thi hành kết hợp với quan điểm của kiểm thử viên với mục tiêu “kiểm thử để tìm ra lỗi” Với một công cụ kiểm thử tự động có thể sử dụng một sản phẩm từ phối cảnh của người dùng cuối, có yêu cầu về chất lượng, và tỉ mỉ tới mức chi tiết Nó là một công cụ hữu ích cho cả người dùng có hiểu biết về kỹ thuật cũng như chưa có hiểu biết về kỹ thuật Nhiều khi một kiểm thử viên cũng được coi như

một lập trình viên giỏi Công cụ này có thể viết kịch bản kiểm thử tốt như một kiểm thử viên có kinh nghiệm và hiểu biết sâu sắc về quy trình phát triển phần mềm Sau cùng nó sẽ giảm bớt công việc nghiên cứu đề kiểm thử viên có thể tập trung vào những phần dủi do cao hơn Nếu sử dụng mô hình XP, ta sẽ nhận thấy công cụ kiểm thử tự động cực kỳ hữu ích

Ngày nay, thường thì những kiểm thử viên và lập trình viên làm việc chặt chẽ với nhau trong một dự án Một công cụ kiểm thử phần mềm không có đủ khả năng để giải quyết tất cả các vấn đề có thể xảy ra Đối với quản trị viên của dự án sẽ thực sự hữu ích nếu đưa vào sử dụng cả kiểm thử thủ công và kiểm thử tự động trong cùng một dự

án phần mềm

Với việc giao tiếp hiệu quả công việc kiểm thử tự động và thủ công sẽ bổ sung cho nhau và tăng năng lực của nhau Thực tế một quản trị viên có thể muốn có các thành viên trong đội gồm những người đã có nhiều kinh nghiệm trong cả kỹ thuật kiểm thử thủ công và kỹ thuật tự động Một sản phẩm chất lượng được lợi từ đội kiểm thử với những thành viên có những kinh nghiệm kiểm thử khác nhau Vd, một số có thể có kinh nghiệm với những công cụ trên thị trường, một số có thể kiểm thử thủ công những vùng dủi do cao của một sản phẩm, trong khi số khác có thể có kinh nghiệm trong việc sử dụng C#, VFB, C/C++, Java, hoặc những ngôn ngữ lập trình khác

1.5 Phương pháp để kiểm thử tự động

Ngành công nghiệp phần mềm đã làm được rất nhiều việc lớn trong kiểm thử phần mềm Nhiều cuốn sách đã trình bày cách để xây dựng các kế hoạch kiểm thử và các chính sách kiểm thử và cách quản lý kiểm thử tự động một phần mềm với các công

cụ hiện có trên thị trường Các kỹ sư phần mềm đã tích lũy được rất nhiều hiểu biết, và các tổ chức phần mềm đã giúp đỡ những nhóm kiểm thử của họ trong việc theo dõi những tài liệu này

Những ngôn ngữ lập trình bậc cao như Java, C#, và VB.NET là những ngôn ngữ hướng đối tượng nhằm hỗ trợ các lập trình viên có thể xây dựng một loạt ứng dụng một cách nhanh chóng Mục tiêu của những ngôn ngữ này là rút ngắn vòng đời phát triển của phần mềm bằng cách cung cấp Common Language Runtime (CRL), Java Virtual Machine (JVM), hỗ trợ cross-language và cross-platform, và quản lý bộ nhớ tự

động Lập trình viên vẫn có thể theo dõi, kiểm soát những vấn đề cấp thấp, như tính toàn vẹn kiểu (type safety), các thư viện cấp thấp có sẵn, kiểm soát mảng, vv… Thực

tế các lập trình viên thực sự sử dụng thời gian và công sức vào những ứng dụng của họ

và vào lô gíc nghiệp vụ (business logic) Những phương thức kiểm thử truyền thống không thể đáp ứng kịp với tiến triển của kỹ thuật Để đáp ứng được yêu cầu về khung thời gian, cần tìm ra con đường nhanh và tốt hơn để kiểm thử các sản phẩm phẩn mềm Kiểm thử tự động gây được sự chú ý lớn do sự tiến triển của kỹ thuật làm tăng tính phức tạp của những sản phẩm phần mềm

Công cụ kiểm thử phần mềm tự động trong Luận văn này có các tính năng:

 Nghiên cứu assembly dưới hình thức kiểm thử động

 Điều khiển và thực hiện lặp các tác vụ đơn giản một cách động

 Tạo lập những kịch bản kiểm thử và thực thi các kịch bản kiểm thử này bằng từng gói theo lịch trình (schedule manner.)

 Kiểm thử Interface của các đối tượng và những thành phần phần mềm khác (software component) với một tập dữ liệu định sẵn

 Truy cập một CSDL để xác thực kết quả kiểm thử

 Truy cập Window Registry để xác thực kết quả kiểm thử

Dữ liệu kiểm thử và kết quả kiểm thử sẽ được thể hiện dưới dạng XML và MS Excel worksheet Tiến trình kiểm thử tự động có thể được trình bày với 6 bước như Hình 1.4

Hình 1.4: 6 bước của kiểm thử phần mềm tự động [9]

Các công cụ kiểm thử tự động có trên thị trường không đủ khả năng kiểm thử một sản phẩm một cách kỹ lưỡng Khi nảy sinh một tính năng kiểm thử mới thì nhà cung cấp thường hứa hẹn sẽ tích hợp tính năng này vào công cụ trong phiên bản tiếp theo Để đáp ứng được sự đa dạng của phần mềm, công cụ kiểm thử được phát triển trong luận văn này có đủ "các tế bào não" để đáp ứng được một yêu cầu mới

Các kỹ sư kiểm thử đã quá quen và có kinh nghiệm trong việc sử dụng các chức năng chụp màn hình và ghi lại kịch bản kiểm thử khi sử dụng các công cụ trên thị trường, nó sẽ dẫn hướng cho unit test, advance stress test, và capability test Công cụ kiểm thử tự động không yêu cầu thay đổi kỹ thuật lập trình hoặc bất kỳ một hành động ghi thủ công nào khác …

Vì vậy bằng cách sử dụng các công cụ kiểm thử hoàn toàn tự động, các kiểm thử viên sẽ được giải phóng khỏi việc reverse-engineering, viết những kịch bản buồn tẻ, và tạo ra các dữ liệu lưu trữ Họ có thể dành nhiều thời gian hơn để kiểm thử các khu vực

có nguy cơ lỗi cao hơn của phần mềm Hơn nữa, lập trình trong môi trường như MS NET cung cấp cho các kiểm thử viên khả năng phát triển một công cụ cao cấp trong khung thời gian và ngân sách cho phép Đặc điểm này này đúng cho nhiều môi trường

và ngôn ngữ lập trình, chẳng hạn như Eclipsing NET, DotGNU Portable NET, Java, Visual Basic 6.0, C / C + +, C # và Visual Basic NET

1.6 Kiểm thử phần mềm và các ngôn ngữ lập trình

Như đã đề cập ở phần trước, có rất nhiều công cụ kiểm thử phần mềm trên thị trường, và các tổ chức đã gặt hái được nhiều thành công khi áp dụng các công cụ này vào quy trình phát triển phần mềm của mình Một vài công cụ kiểm thử phần mềm viết kịch bản kiểm thử bằng ngôn ngữ Visual Basic 6.0 và thực thi kịch bản trong Visual Studio IDE Đồng thời cũng có nhiều tài liệu hướng dẫn cách viết kịch bản kiểm thử

sử dụng ngôn ngữ Visual Basic 6.0 một cách thủ công Một vài công cụ khác được viết bằng Java, như Junit, và Jprobe Và các công cụ này để viết kịch bản kiểm thử cho những phần mềm chạy trên Unix, Linux, và các nền tảng (platform) khác Trong phạm

vi Luận văn này, tôi sẽ sử dụng C# của môi trường Microsoft Visual Studio NET làm ngôn ngữ lập trình cho cả công cụ và kịch bản kiểm thử

Việc tự động hóa các mục tiêu tập trung chủ yếu vào các vấn đề từ một số khu vực được xác định rõ ràng Những vấn đề và các khu vực đó đã từng xảy ra các lỗi phần mềm trong quá khứ Các công cụ kiểm thử thường viết những kịch bản kiểm thử với một số lặp đi lặp lại các mẫu (parttern) để kiểm thử các phương thức khác nhau trong một lớp (class)

Nhìn chung chúng mô hình kiểm thử gồm các bước sau:

1 Thiết lập các thông số cần thiết

2 Thực thi phương thức cần kiểm thử và bắt lỗi

để hiểu được từng phương thức để có thể viết mã một cách chính xác Mặt khác rất khó khăn cho một công cụ để viết mã khác nhau giữa các phương thức phức tạp Gỡ lỗi luôn luôn cần thiết khi viết kịch bản kiểm thử một cách thủ công Với công cụ kiểm thử tự động các quy trình kiểm thử sẽ trở nên nhanh chóng cho các công việc lặp đi lặp lại và sẽ không cần tới gỡ lỗi (debug) nữa

Chúng ta đã biết về ranh giới của các điều kiện cho từng test case, nhưng chúng

ta thường dành nhiều thời gian triển khai để có thể soạn ra các test case Luận văn giới thiệu 2 giải pháp đơn giản để tự động soạn test case, tiết kiệm thời gian để các kiểm thử viên tập trung vào các khu vực có nguy cơ cao, và để dành nhiều thời gian hơn vào các công việc kiểm thử thủ công Khi cập nhật khả năng tự động hóa cho công cụ, các giải pháp cho vấn đề lặp đi lặp lại cuối cùng sẽ được tự động hóa xử lý Chỉ có những vấn đề mới sẽ được kiểm thử thủ công và tự động hóa về sau

Sử dụng ngôn ngữ nào để viết kịch bản kiểm thử là không quan trọng, kiểm thử viên phải có hiểu biết trong lĩnh vực kiểm thử và có kỹ năng lập trình Các phương thức minh hoạ trong Luận văn này có thể được chuyển qua bất cứ ngôn ngữ và nền tảng nào

Trên thực tế C# đã được tạo ra để phát triển phần mềm, chứ không phải dành cho kiểm thử phần mềm Dễ hiểu rằng một số chuyên gia C# sử dụng các công cụ kiểm thử phần mềm của bên thứ ba để kiểm thử cho các dự án phần mềm của họ Bạn có thể tự hỏi làm thế nào một ngôn ngữ lập trình có thể được sử dụng để phát triển một công cụ kiểm thử Vấn đề này sẽ được sáng tỏ trong nội dung của Luận văn

Trong quá khứ, Visual Basic và Java đã được sử dụng thường xuyên hơn các ngôn ngữ khác để viết kịch bản kiểm thử Ví dụ, công cụ kiểm thử của Rational sử dụng một phương thức reverse-engineering và tạo ra các kịch bản trong Visual Basic

Cuốn sách Visual Basic cho các kiểm thử viên (Sweeney 2001) giới thiệu một số kỹ

thuật của việc tạo ra kịch bản kiểm thử, nhưng nó không bao gồm các kỹ thuật cho tự động hóa kịch bản kiểm thử Lập trình viên Java thường dùng JUnit như một công cụ kiểm thử tự động Sử dụng một ngôn ngữ lập trình như C # làm công cụ kiểm thử là một khái niệm mới Luận văn sẽ không chỉ nghiên cứu cách làm thế nào để viết một kịch bản kiểm thử cho một assembly, mà còn chỉ ra cách làm thế nào để phát triển một công cụ để viết kịch bản kiểm thử một cách tự động Về sau, các tổ chức khác nhau và các dự án phần mềm với chức năng khác nhau có thể sử dụng phương pháp này cho việc phát triển phần mềm Để thực hiện giải pháp sẽ tập trung vào giải quyết các vấn

đề sau đây:

 Làm thế nào để sử dụng những chức năng định trước của một ngôn ngữ (trong trường hợp này là C #) mà lại trả về các thông tin liên quan tới assembly trong quá trình kiểm thử

 Làm thế nào để tạo ra giao diện với những thành phần điều khiển đơn giản

mà có thể thể hiện được thông tin cũng như kết quả kiểm thử

 Làm thế nào để tạo và lưu giữ test case trong cơ sở dữ liệu (trong trường hợp này là MS Excel và XML) để tự động tạo các kịch bản kiểm thử

 Làm thế nào để tạo một bản trình bày các thông tin của một thành phần trong quá trình kiểm thử (trong trường hợp này là sử dụng một bảng tính Excel.)

 Làm thế nào thực hiện một cơ chế để tạo ra tập lệnh kiểm thử để thử nghiệm một lớp (class), một thành phần dữ liệu, và một phương thức (trong trường hợp này là sử dụng NET CodeDom.)

 Làm thế nào để cho phép các kịch bản kiểm thử có thể kiểm thử các tham

số thông qua việc truyền giá trị, truyền tham chiếu (references), và truyền đối tượng

 Làm thế nào để cho phép các kịch bản kiểm thử có thể kiểm thử dựa vào

hệ thống Windows system registry

 Làm thế nào trình bày các kết quả kiểm thử để các nhà phát triển sẽ có thêm nhiều thông tin tốt nhất có thể để sửa chữa lỗi được tìm ra trong quá trình kiểm thử

1.7 Kịch bản kiểm thử

Một kịch bản kiểm thử đóng vai trò như người dùng cuối sử dụng ứng dụng theo một kịch bản định trước, theo đó một sản phẩm phần mềm được kiểm thử tự động Theo truyền thống, một tập lệnh kiểm thử tự động được viết bởi một kiểm thử viên để kiểm thử các phương thức của một assembly Khi các kiểm thử viên viết kịch bản kiểm thử họ phải mất thời gian để xác định và phân tích các yêu cầu Trong quá trình phát triển phần mềm các thông số này cũng thay đổi và kiểm thử viên sẽ phải chỉnh sửa hoặc viết kịch bản kiểm thử Quá trình này sẽ được lặp đi lặp lại cho đến khi sản phẩm ổn định Sau đó, các kịch bản kiểm thử có thể được chạy để thực hiện các dạng kiểm thử: unit test, intergration test (kiểm thử tích hợp), hoặc regression test (kiểm thử hồi quy) Trong toàn bộ quá trình, công việc của đội kiểm thử là cải thiện và gỡ lỗi các kịch bản kiểm thử để đáp ứng và luôn đáp ứng theo những thay đổi của yêu cầu kiểm thử

Để giảm bớt sự nhàm chán và tốn thời gian khi tự viết kịch bản kiểm thử, các công cụ kiểm thử tự động có khả năng phát hiện các thay đổi của phần mềm một cách

tự động Nếu phần mềm có thay đổi thì công cụ sẽ viết một kịch bản kiểm thử mới cho

phù hợp Nếu cấu trúc của phần mềm ổn định trong suốt quá trình phát triển, kịch bản kiểm thử có thể chạy unit test, integration test, và regression test trong suốt quá trình phát triển phần mềm

Nguyên tắc để phát triển một sản phẩm phần mềm tốt là phải phát triển một kịch bản kiểm thử tốt Để tạo ra một kịch bản kiểm thử hiệu quả, các công cụ cần có cơ chế

để phản ánh (reflect) các thông tin chi tiết của dự án cần kiểm thử Một kịch bản kiểm thử được tạo ra bởi công cụ kiểm thử cần có các tính năng sau đây:

 Reusability – Tính sử dụng lại: cần những nỗ lực rất lớn để phát triển

một công cụ kiểm thử, việc tái sử dụng các công cụ cho các dự án trong tương lai là rất cần thiết Tác giả đinh hướng phát triển công cụ để tự động tạo ra những kịch bản có thể sử dụng lại dựa trên ngôn ngữ C# Sửa dụng lại các công cụ kiểm thử và khám phá một tập lệnh đã được biên dịch thông qua các bước thử nghiệm theo tên, lớp, phương thức, và thuộc tính Một thử nghiệm cho các tập lệnh kiểm thử trong một trường hợp có thể được sử dụng để kiểm thử một trường hợp thử nghiệm khác Sau cùng, các công cụ chính nó có thể được tái sử dụng và cập nhật thông qua các dự án

 Readability – Tính dễ đọc: quy tắc đặt tên phải được sử dụng cho các

biến và hằng trong các tập lệnh được tạo ra để kiểm thử Các tập lệnh kiểm thử sẽ kiểm thử chỉ định chính xác các tính năng của một phần mềm Nếu có một số nhu cầu đặc biệt cho một sản phẩm phần mềm, bạn có thể chọn để cập nhật những công cụ kiểm thử tự động đã được sửa đổi để tạo

ra kịch bản Ví dụ, nếu các nhu cầu đặc biệt thường xuyên xảy ra ta cần cập nhật lại những công cụ những công cụ kiểm thử tự động Nó làm cho công cụ kiểm thử được sử dụng dễ dàng hơn cho các dự án trong tương lai Nếu yêu cầu mới không phải là điển hình, kỹ sư kiểm thử có thể quyết định không để cập nhật các công cụ, thay vì thế sẽ sửa đổi các kịch bản kiểm thử

 Maintainability – Khả năng bảo trì: có rất nhiều yêu cầu và hình thức

khác nhau của một sản phẩm phần mềm, mặc dù chúng có thể có những tính năng phổ biến thường sẽ giống nhau Hiện tại thì các công cụ kiểm thử tự động có khá đủ các tính năng đáp ứng cho hầu hết các sản phẩm

phần mềm Khi các tính năng mới được kỳ vọng sẽ phát triển trong tương lai các dự án, các công cụ kiể thử tự động có thể sẽ phải được cập nhật

 Portability – Tính khả chuyển: với một quá trình cài đặt đơn giản, các

công cụ kiểm thử tự động có khả năng thực hiện được yêu cầu nhiệm vụ kiểm thử trên nhiều hệ thống máy tính khác nhau

Cần ghi nhớ một điều rằng sự thành công của dự án phần mềm phụ thuộc vào việc áp dụng các công cụ kiểm thử Không có lập trình viên hoàn hảo, một kiểm thử viên sẽ rất mù mờ trong việc tìm khuyết tật trong mã của người khác Công cụ thử nghiệm phát triển trong luận văn có thể tạo ra một tập lệnh thực thi kiểm thử mà không cần gỡ lỗi, điều này sẽ tiết kiệm được rất nhiều thời gian Tuy nhiên cần phân chia đủ thời gian để gỡ lỗi và kiểm thử các công cụ kiểm thử tự động trong và ngay cả sau khi phát triển các công cụ

ra ngày càng tăng Do đó việc nghiên cứu áp dụng các công cụ kiểm thử tự động được coi là một giải pháp tối ưu cho bài toán này, những lợi ích mà kiểm thử tự động đem lại là rất lớn

Thông qua Chương 1 tác giả đã tiếp cận được các yêu cầu và đặc điểm của các công cụ kiểm thử tự động, về mô hình hoạt động cũng như các thành phần của một công cụ kiểm thử tự động Trong nội dung chương tiếp theo của luận văn, tác giả sẽ đi sâu tìm hiểu kiến trúc và các thể loại kiểm thử phần mềm, trước khi trực tiếp bắt tay vào nghiên cứu xây dựng một công cụ kiểm thử tự động

CHƯƠNG 2: PHƯƠNG PHÁP VÀ CÁC THỂ LOẠI

KIỂM THỬ PHẦN MỀM

2.1 Tổng quan

Kiểm thử phần mềm là một quá trình điều tra tiến hành thực nghiệm để cung cấp cho các bên liên quan thông tin về chất lượng sản phẩm hoặc dịch vụ đã được thử nghiệm, dựa trên bối cảnh hoạt động của sản phẩm Kiểm thử phần mềm cũng là mục tiêu, một đánh giá độc lập cho phép các doanh nghiệp đánh giá và hiểu được những rủi

ro trong khi thực hiện các phần mềm Các kỹ thuật kiểm thử bao gồm, nhưng không giới hạn các quá trình thực thi chương trình hay ứng dụng với mục đích tìm ra lỗi phần mềm

Thử nghiệm phần mềm cũng có thể được xem như quá trình phê chuẩn và xác minh rằng một chương trình phần mềm/ứng dụng/sản phẩm:

1 Đáp ứng các yêu cầu nghiệp vụ và kỹ thuật được mô tả trong thiết kế

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

3 Thực thi một cách thống nhất

Tùy thuộc vào phương pháp xây dựng phần mềm mà kiểm thử phần mềm có thể được thực hiện bất cứ lúc nào trong quá trình phát triển Tuy nhiên, hầu hết các công việc kiểm thử được thực hiện sau khi yêu cầu đã được định nghĩa và quá trình viết mã được hoàn tất Như vậy, các phương pháp thử nghiệm được quản lý bởi các phương pháp phát triển phần mềm

Các mô hình phát triển phần mềm khác nhau sẽ tập trung công việc kiểm thử tại các điểm khác nhau trong quá trình phát triển Trong một mô hình truyền thống, hầu hết các công việc kiểm thử được thực hiện sau quá trình đặc tả yêu cầu và viết mã Các

mô hình phát triển mới hơn, chẳng hạn như Agile hoặc XP, thường được áp dụng phương pháp thử nghiệm hướng phát triển (Test Driven) và sử dụng trước một phần của thử nghiệm trong quá trình phát triển do chính các lập trình viên thực hiện

Việc tách và gỡ lỗi từ kiểm thử được giới thiệu lần đầu tiên bởi Glenford J Myers vào năm 1979 "Một thử nghiệm thành công là một thử nghiệm trong đó tìm

thấy lỗi", điều này minh họa cho các mong muốn của cộng đồng công nghệ phần mềm

là tách biệt các hoạt động phát triển phần mềm và hoạt động gỡ lỗi

2.2 Các phương pháp kiểm thử

Có 2 phương pháp kiểm thử chính là: Kiểm thử tĩnh và Kiểm thử động

2.2.1 Kiểm thử tĩnh – Static testing

Là phương pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy chương trình Kiểu kiểm thử này thường được sử dụng bởi chuyên viên thiết kế người mà viết mã lệnh một mình

Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận tính hợp lệ về cú pháp của chương trình

2.2.2 Kiểm thử động – Dynamic testing

Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình để điều tra trạng thái tác động của chương trình Đó là kiểm thử dựa trên các ca kiểm thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các chương trình Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy Kiểm thử động thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có như mong muốn hay không Các phương pháp kiểm thử động gồm có: Kiểm thử thành phần (Unit Test), Kiểm thử tích hợp (Intergration Test), Kiểm thử hệ thống (System Test),

và Kiểm thử chấp nhận sản phẩm (Acceptance Test)

Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng dữ liệu, hay hướng vào/ra Kiểm thử hộp đen xem chương trình như là một “hộp đen” Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả

Các phương pháp kiểm thử hộp đen:

 Phân lớp tương đương – Equivalence partitioning

 Phân tích giá trị biên – Boundary value analysis

 Kiểm thử mọi cặp – All-pairs testing

 Kiểm thử fuzz – Fuzz testing

 Kiểm thử dựa trên mô hình – Model-based testing

 Ma trận dấu vết – Traceability matrix

 Kiểm thử thăm dò – Exploratory testing

 Kiểm thử dựa trên đặc tả – Specification-base testing

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt

để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn

Ưu, nhược điểm

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi Sử dụng nguyên tắc “ Hãy đòi hỏi

và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên

đã không tìm ra Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là

đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào Đó là lý do mà có nhiều

trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một

số phần của chương trình không được kiểm tra chút nào

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”

2.3.2 Kiểm thử hộp trắng – White box testing

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của chương trình Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng)

Các phương pháp kiểm thử hộp trắng:

 Kiểm thử giao diện lập trình ứng dụng - API testing (application programming interface): là phương pháp kiểm thử của ứng dụng sử dụng các API công khai và riêng tư

 Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiêu chuẩn về bao phủ mã lệnh

 Các phương pháp gán lỗi – Fault injection

 Các phương pháp kiểm thử hoán chuyển – Mutation testing methods

 Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra

2.3.3 Kiểm thử hộp xám – Gray box testing

Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức

người sử dụng hay mức hộp đen Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra

rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử Kiểm thử hộp xám có thể cũng bao gồm cả thiết

kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi

2.4 Các cấp độ kiểm thử phần mềm

Các nhà sản xuất đã phát triển các công cụ để bao hàm được một loạt các nhiệm

vụ kiểm thử Tuy nhiên, sử dụng những công cụ này sẽ làm tăng thêm tính phức tạp của các phần mềm ứng dụng

Ngày nay, các tổ chức phát triển phần mềm thường lồng ghép nhiều kỹ thuật khác nhau, thiết kế và lập trình hướng đối tượng, các loại giao diện, client-server và các ứng dụng phân tán, truyền dữ liệu, và các cơ sở dữ liệu quan hệ lớn, mà tất cả làm cho độ phức tạp của phần mềm tăng theo hàm số mũ Những lập trình viên lập trình công cụ kiểm thử không thể làm tăng gấp đôi tính phức tạp trước khi tiến hành một dự

án, làm thế sẽ gây khó khăn cho họ hoặc giả sẽ không thể giải quyết các vấn đề họ đưa

ra một cách tối ưu

Ngoài ra, các kỹ sư phần mềm vẫn tiếp tục cải thiện công nghệ và tăng thêm tính phức tạp vào các dự án phần mềm Các nhà phát triển công cụ không thể dự đoán trước những cải tiến này, và vì vậy họ cũng phải được xem xét một cách độc lập trên

cơ sở để xác định xem làm thế nào để có thể kiểm thử

Đối với những lý do này, bắt buộc các tổ chức phát triển phần mềm phải tự phát triển công cụ của mình để giải quyết các vấn đề đặc thù của mình Để bảo đảm chất lượng sản phẩm trong một thời gian quy định, các tổ chức phải phát triển một cách hiệu quả thử nghiệm phương pháp tiếp cận với một trong phạm vi tập trung

Xác định một phạm vi kiểm thử là quan trọng cho sự thành công của một dự án phần mềm Do có thời gian ngắn khung và các tương tác của con người liên kết với các công cụ kiểm thử phần mềm có sẵn, nó có thể trở thành khó khăn để kiểm thử tất

cả các thành phần của một ứng dụng theo sự phát triển Đó là luôn luôn mong muốn

các phần mềm để kiểm thử kỹ lưỡng, nhưng không phải lúc nào cũng có thể do thời gian và ngân sách Nếu việc thử nghiệm các công cụ có khả năng thực hiện công việc kiểm thử và kiểm thử các trường hợp soạn với đầy đủ tự động hóa, con người xét nghiệm sẽ có đủ thời gian để tập trung vào các khu vực có nguy cơ cao

Nếu không có công cụ kiểm thử tự động hoàn chỉnh, các kỹ sư kiểm thử thường xác định các yêu cầu quan trọng và các khu vực có nguy cơ cao bằng cách phân tích được các yêu cầu quan trọng nhất đối với khách hàng và các lĩnh vực trong phạm vi ứng dụng được người sử dụng quan tâm nhất Các quyết định thường được đưa ra để làm thử nghiệm không tính tới toàn bộ các trong khu vực không có nguy cơ cao, điều

đó đó có thể gây ra các vấn đề và thậm chí rất nghiêm trọng trong tương lai và biến các vấn đề không nghiêm trọng này thành những vấn đề nghiêm trọng Do đó, phạm vi của một công cụ kiểm thử tự động đầy đủ phải kiểm thử được tất cả các dòng mã, và các dòng mã phải được kiểm thử liên tục cả ngày lẫn đêm cho đến khi hầu hết các lỗi được tìm thấy và sản phẩm được phát hành

Hình 2.1: Mối tương quan giữa phát triển và kiểm thử phần mềm

Sau khi phạm vi thử nghiệm được xác định, bạn thường cần phải lập kế hoạch cho giai đoạn thử nghiệm, bao gồm các loại hình và thời gian của các bài kiểm thử sẽ được thực hiện ở cả trước và postrelease giai đoạn Các công cụ thử nghiệm thương mại sẵn có được sử dụng để thực hiện những loại thử nghiệm dưới đây trong một chu

kỳ hoàn chỉnh:

2.4.1 Kiểm thử mức đơn vị - Unit Test