MỞ ĐẦU Vào khoảng đầu những năm 60 nhu cầu sử dụng các hệ thống phần mềm, giải phóng sức lao động trí tuệ trong các hoạt động kinh doanh, quản lý, giải trí và một số lĩnh vực khoa học xã hội tăng cao. Tuy nhiên các yêu cầu về nghiệp vụ phức tạp trong các hệ thống này dẫn đến các hệ thống phần mềm tương ứng cũng ngày càng trở nên phức tạp, cồng kềnh và khó kiểm soát. Rất nhiều yêu cầu nghiệp vụ đòi hỏi xử lý các vấn đề liên quan đến dữ liệu phân tán, xử lý các thông tin khác nhau do nhiều tổ chức nắm giữ. Đã có nhiều kiến trúc phần mềm được đưa ra nhưng chưa đủ mạnh để đáp ứng được nhu cầu thực tế dẫn đến sự khủng hoảng phần mềm.
Trong thời kỳ này, một số dự án phần mềm điển hình đã thất bại như: Hệ thống điều khiển hàng không; Các hệ thống phần mềm phục vụ cho ngành viễn thông, y tế,. Theo sự phân tích thực tế, các hệ thống phần mềm rơi vào tình trạng này bởi các nguyên nhân khác nhau như[19]: Khả năng xây dựng phần mềm cho phần cứng không theo kịp sự phát triển của phần cứng. Khả năng xây dựng phần mềm chưa đáp ứng được nhu cầu thực tế. Sự cạnh tranh giữa các hệ thống phần mềm về chất lượng và độ tin cậy ngày càng cao.
Nguồn nhân lực không đủ so với nhu cầu thực tế. Ngoài những nguyên nhân cơ bản trên, còn có những nguyên nhân xuất phát từ điểm yếu của hệ thống phầm mềm như: Không có đơn vị dữ liệu chuẩn để đánh giá hệ thống. Không xác định chính xác được chi phí xây dựng hệ thống. Các công cụ hỗ trợ lập kế hoạch và đánh giá tự động không phù hợp.
Kế hoạch phát triển hệ thống không hợp lý tạo sức ép lớn cho người thực hiện Quá trình quản lý tiến trình thực hiện và sự cố phát sinh không phù hợp. z 2 Thiếu khả năng kiểm duyệt thiết kế và quản lý mã lệnh của hệ thống phần mềm. Để khắc phục và hạn chế được những điểm yếu này đòi hỏi dự án phần mềm phải có những quy trình nhất định, giúp chúng ta kiểm soát được tiến trình thực hiện dự án cũng như hiệu quả công việc, kết quả và hướng phát triển của dự án. Sau khi hoàn thành hệ thống phần mềm của dự án và trước khi đưa vào ứng dụng trong thực tế, hệ thống này cần phải được kiểm tra, đánh giá tính chính xác và khả năng đáp ứng yêu cầu thực tế - thuật ngữ “Kiểm thử phần mềm” bắt nguồn từ đây[9,18].
Kiểm thử phần mềm là một phương pháp kiểm soát quá trình thử nghiệm, thực hiện các chức năng trong hệ thống phần mềm theo một tập hợp các điều kiện đặt ra với mục đích tìm ra lỗi của hệ thống. Kết quả của kiểm thử phần mềm là tư liệu chứng minh hệ thống có thể đáp ứng được các yêu cầu đặt ra và ứng dụng được trong thực tế hay không? Kiểm thử phần mềm có thể nói là một phần không thể thiếu trong việc xây dựng và phát triển phần mềm. Nó cho chúng ta biết một phần mềm khi xây dựng và sử dụng có đúng với các yêu cầu mà chúng ta đặt ra hay không. Ở nước ta hiện nay ngành Công nghệ phần mềm đang phát triển mạnh mẽ, việc kiểm thử phần mềm chưa thực sự được quan tâm nhiều hoặc quan tâm nhưng không đúng cách.
Việc áp dụng các công cụ tự động cho việc kiểm thử hầu như không có. Trong khi đó theo thống kê chúng ta có thể tốn 40% đến 60% thời gian dành cho việc kiểm thử. Phần lớn các công ty thường không có các tester thực sự, một số công ty có những người chuyên về kiểm thử nhưng thường làm thủ công. Vì vậy việc xây dựng các công cụ hỗ trợ kiểm thử cho chúng ta các lợi ích sau.
Mất ít thời gian hơn. Tránh được các lỗi do con người gây ra do kiểm thử thủ công Với thực tế và các lợi ích trên tôi nhận thấy việc nghiên cứu và xây dựng đề tài này là cần thiết, phù hợp với tình hình hiện tại. z 3 Cấu trúc của luận văn bao gồm: Chƣơng 1 Đưa ra một số kỹ thuật kiểm thử phần mềm, tìm hiểu một số ưu nhược điểm của mỗi kỹ thuật kiểm thử. Lựa chọn các kỹ thuật kiểm thử phần mềm.
Chƣơng 2 Đưa ra cái nhìn tổng quát về công nghệ Web Service, tìm hiểu về các thành phần chuẩn được sử dụng trong công nghệ Web Service, kiến trúc Web Service và quy trình hoạt động của một Web Service. Tìm hiểu về ứng dụng web và xu hướng phát triển các ứng dụng. Chƣơng 3 Đưa ra một số vấn đề và cách giải quyết các vấn đề trong việc viết một công cụ hỗ trợ kiểm thử trong .Net của các ứng dụng web. Nghiên cứu các phương pháp kiểm thử web services.
Chƣơng 4 Giới thiệu một bài toán Travel-Agent, mục tiêu, yêu cầu của bài toán. Xây dựng công cụ hỗ trợ kiểm thử cho bài toán. z 4 Chƣơng 1 - CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM Hai kỹ thuật thường hay sử dụng để kiểm thử phần mềm: Kiểm thử hộp trắng (WBT – White Box Testing). Kiểm thử hộp đen (BBT – Black Box Testing).
Kiểm thử hộp trắng (WBT) WBT liên quan đến việc xem xét cấu trúc của mã lệnh. Khi biết được cấu trúc của sản phẩm, kiểm thử có thể kiểm soát được một cách chắc chắn bản chất thao tác thực hiện có theo đặc tả kỹ thuật không? Và các thành phần có được thực hiện hợp lý không? WBT có khuynh hướng bao trùm các sự kiện của các chi tiết kỹ thuật trong mã lệnh, bao gồm các kỹ thuật sau[20]: Phân đoạn sự kiện: mỗi phân đoạn của cấu trúc điều khiển mã lệnh được thi hành theo sự phân đoạn nhỏ nhất Phân nhánh sự kiện hoặc kiểm thử nút: mỗi nhánh trong mã lệnh được thực hiện theo mỗi hướng có thể thực hiện được theo mức nhỏ nhất. Sự kiện điều kiện ghép: Khi có nhiều điều kiện, chúng ta không cần kiểm thử từng hướng (từng điều kiện) nhưng phải kết hợp các hướng có thể thực hiện được của điều kiện, cách thường dùng là bảng chân lý (chân trị). Kiểm thử đường đi cơ bản: Mỗi đường đi độc lập từ đầu đến cuối trong mã lệnh trong trình tự đã được xác định trước.
Kiểm thử theo luồng dữ liệu (DFT - Data Flow Testing): phương pháp này thực hiện kiểm tra các biến đặc trưng trong mỗi tính toán có thể được thực thi, như vậy hạn chế thiết lập các đường trung gian từ đầu đến cuối mã lệnh, … đây là cơ sở trên mỗi mảnh của mã lệnh để chọn và kiểm tra. Kiểm thử đường đi: kiểm thử đường đi là kiểm thử kiểm thử tất cả các đường đi có thể thực hiện được từ đầu đến cuối mã lệnh được định nghĩa và chuyển đổi. Kiểm thử này rất phức tạp và tốn thời gian. z 5 Kiểm thử vòng lặp: bổ sung đơn vị đo lường lớn nhất, đó là chiến lược kiểm thử căn bản trong kiểm thử vòng lặp.
Chiến lược này hướng tới việc kiểm thử các vòng lặp đơn, các vòng lặp ràng buộc nhau, và các vòng lặp lồng nhau. Chúng ta làm gì với WBT WBT sử dụng cấu trúc điều khiển của thiết kế các thủ tục để đưa ra các tình huống kiểm thử. Người kiểm thử có thể sử dụng phương thức WBT để đưa ra các tình huống kiểm thử mà: Đảm bảo tất cả các đường đi độc lập trong module được thực thi ít nhất một lần. Sử dụng tất cả các quyết định logic trong các giá trị của nó (đúng hoặc sai).
Thực thi được tất cả các vòng lặp. Sử dụng các cấu trúc dữ liệu của nó để đảm bảo giá trị của chúng. WBT còn được gọi là kiểm thử hộp kính hoặc kiểm thử cấu trúc. Tại sao dùng WBT? Chúng ta dùng WBT vì BBT không chắc đã phát hiện được nhiều lỗ hổng của các nhược điểm trong lập trình như: Các lỗi logic và các giả định không đúng bị đảo ngược.
Lỗi này xuất hiện khi thiết kế và thực thi các hàm chức năng, các điều kiện hoặc các điều khiển. Luồng logic của chương trình có những khác thường, nghĩa là giả định của chúng ta về luồng của điều khiển và dữ liệu có thể tạo ra các lỗi thiết kế mà nó chỉ có thể phát hiện được khi dùng kiểm thừ đường đi. Lỗi sinh các giá trị ngẫu nhiên. Kỹ năng yêu cầu Về lý thuyết thì chúng ta cần làm trong WBT là định nghĩa tất cả các đường logic, mở rộng các tình huống kiểm thử để thực thi và đánh giá kết quả trả về… nói chung là các tình huống kiểm thử thực thi được tất cả các vấn đề trong chương trình.
z 6 Để thực hiện được điều này chúng ta phải nắm được chương trình, đặc tả kỹ thuật và mã lệnh được kiểm thử. Công cụ sử dụng cho WBT Một vài công cụ kiểm thử tự động cung cấp WBT như: Công cụ dò tìm lỗ hổng bộ nhớ và lỗi run-time. Công cụ ghi lại chính xác thời gian sử dụng ứng dụng trong khối nhất định của mã lệnh cho mục đích tìm kiếm những đoạn mã không hiệu quả. Công cụ xác định các vùng của ứng dụng được hoặc không được thực thi.
Kiểm thử hộp đen (BBT) Với kiểm thử hộp đen, người kiểm thử không cần biết đến cấu trúc hoặc cơ chế làm việc bên trong hộp đen mà cái cần quan tâm là chức năng của nó[16,20]. Kỹ thuật kiểm thử nền tảng đồ thị Kiểm thử phần mềm bắt đầu bằng việc tạo ra đồ thị của các đối tượng quan trọng và các mối liên quan tới nó, sau đó đưa ra một chuỗi các kiểm thử mà nó bao hàm được đồ thị để thực thi được các đối tượng và các quan hệ của đối tượng để phát hiện lỗi. Kỹ thuật phỏng đoán lỗi Phỏng đoán lỗi được hình thành qua kinh nghiệm kỹ thuật và dự án. Không có công cụ và công nghệ giành cho kỹ thuật này, nhưng chúng ta có thể dựng các tình huống kiểm thử dựa vào trạng thái làm việc của hàm chức năng.
Kỹ thuật phân tích giá trị đƣờng biên Phân tích giá trị đường biên (BVA - Boundary Value Analysis) là kỹ thuật lựa chọn dữ liệu kiểm thử (kỹ thuật kiểm thử chức năng) với các giá trị đường biên. Giá trị đường biên bao gồm: cực đại, cực tiểu. giá trị sát trong/ sát ngoài đường biên, các giá trị đặc biệt và các giá trị lỗi.