Kiểm thử và một số kỹ thuật trong kiểm thử phần mềm

Với sự phát triển như vũ bão của công nghệ thông tin nói chung và công nghệ phần mềm nói riêng, việc phát triển phần mềm ngày càng được hỗ trợ bởi nhiều công cụ tiên tiến, giúp cho việc xây dựng phần mềm đỡ mệt nhọc và hiệu quả hơn. Tuy nhiên, vì độ phức tạp của phần mềm và những giới hạn về thời gian và chi phí, cho dù các hoạt động đảm bảo chất lượng phần mềm nói chung và kiểm thử nói riêng ngày càng chặt chẽ và khoa học, vẫn không đảm bảo được rằng các sản phẩm phần mềm đang được ứng dụng không có lỗi. Lỗi vẫn luôn tiềm ẩn trong mọi sản phẩm phần mềm và cũng có thể gây những thiệt hại khôn lường. Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng. Các kỹ thuật kiểm thử phần mềm đã, đang được nghiên cứu, và việc kiểm thử phần mềm đã trở thành qui trình bắt buộc trong các dự án phát triển phần mềm trên thế giới. Kiểm thử phần mềm là một hoạt động rất tốn kém, mất thời gian, và khó phát hiện được hết lỗi. Vì vậy, việc kiểm thử phần mềm đòi hỏi phải có chiến lược phù hợp, một kế hoạch hợp lý và việc thực hiện được quản lí chặt chẽ.

MỞ ĐẦU Lý chọn đề tài Với phát triển vũ bão công nghệ thông tin nói chung cơng nghệ phần mềm nói riêng, việc phát triển phần mềm ngày hỗ trợ nhiều công cụ tiên tiến, giúp cho việc xây dựng phần mềm đỡ mệt nhọc hiệu Tuy nhiên, độ phức tạp phần mềm giới hạn thời gian chi phí, cho dù hoạt động đảm bảo chất lượng phần mềm nói chung kiểm thử nói riêng ngày chặt chẽ khoa học, không đảm bảo sản phẩm phần mềm ứng dụng khơng có lỗi Lỗi tiềm ẩn sản phẩm phần mềm gây thiệt hại khơn lường Kiểm thử phần mềm q trình liên tục, xuyên suốt giai đoạn phát triển phần mềm để đảm bảo phần mềm thoả mãn yêu cầu thiết kế yêu cầu đáp ứng nhu cầu người dùng Các kỹ thuật kiểm thử phần mềm đã, nghiên cứu, việc kiểm thử phần mềm trở thành qui trình bắt buộc dự án phát triển phần mềm giới Kiểm thử phần mềm hoạt động tốn kém, thời gian, khó phát hết lỗi Vì vậy, việc kiểm thử phần mềm đòi hỏi phải có chiến lược phù hợp, kế hoạch hợp lý việc thực quản lí chặt chẽ Ở Việt Nam, thời gian qua việc kiểm thử phần mềm bị xem nhẹ, với công cụ lập trình đại, người ta cảm tính cho khơng kiểm thử khơng sao, nên chưa có nhiều quan tâm, nghiên cứu Những năm gần đây, số tổ chức nghiên cứu phát triển phần mềm bắt đầu có quan tâm đến vấn đề kiểm thử phần mềm Tuy nhiên, vấn đề kiểm thử phần mềm chưa đầu tư quan tâm mức Nước ta q trình xây dựng ngành cơng nghiệp phần mềm khơng thể xem nhẹ việc kiểm thử phần mềm xác suất thất bại cao, nữa, hầu hết cơng ty phần mềm có uy tín đặt yêu cầu nghiêm ngặt phần mềm khơng có tài liệu kiểm thử kèm khơng chấp nhận Mục tiêu nhiệm vụ nghiên cứu - Luận văn tập trung nghiên cứu, tìm hiểu, đánh giá nguyên lý, chiến lược kỹ thuật kiểm thử phần mềm - Thiết kế trường hợp kiểm thử áp dụng cho vài chương trình cụ thể Đối tƣợng phạm vi nghiên cứu − Qui trình chất kỹ thuật kiểm thử hộp đen kiểm thử hộp trắng − Chiến lược kiểm thử phần mềm − Đặc tả thiết kế kiểm thử Phƣơng pháp nghiên cứu - Nghiên cứu, tìm hiểu kỹ thuật, chiến lược kiểm thử phần mềm - Sử dụng phương pháp kiểm thử nghiên cứu, thiết kế test cho chương trình cụ thể Đưa tài liệu kế hoạch kiểm thử đặc tả kiểm thử; xây dựng chương trình thực thi kiểm thử Dự kiến kết - Thiết kế trường hợp kiểm thử cho số chương trình cụ thể - Tạo tài liệu kiểm thử (đặc tả trường hợp kiểm thử kết kiểm thử.) - Xây dựng chương trình kiểm thử Ý nghĩa khoa học thực tiễn Luận văn Kết nghiên cứu làm tài liệu tham khảo cho sở tiến tới đưa qui trình kiểm thử phần mềm thành qui trình bắt buộc dự án phát triển phần mềm họ Đặt tên đề tài “Một số kỹ thuật kiểm thử phần mềm.” Bố cục Luận văn Toàn nội dung Luận văn chia thành chương sau: Chƣơng 1: Vấn đề chất lượng phần mềm kiểm thử phần mềm Chƣơng 2: Các kỹ thuật kiểm thử phần mềm Chƣơng 3: Chiến lược kiểm thử phần mềm Chƣơng 4: Một số ứng dụng cụ thể (của qui trình kiểm thử) CHƢƠNG VẤN ĐỀ CHẤT LƢỢNG PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM 1.1 Sản phẩm phần mềm vấn đề kiểm thử phần mềm 1.1.1 Sản phẩm phần mềm gì? Phần mềm (bộ) chương trình cài đặt máy tính nhằm thực nhiệm vụ tương đối độc lập nhằm phục vụ cho ứng dụng cụ thể việc quản lý họat động máy tính áp dụng máy tính họat động kinh tế, quốc phòng, văn hóa, giáo dục, giải trí,… Việc tạo sản phẩm phần mềm phải trải qua nhiều giai đoạn, người ta gọi qui trình phát triển phần mềm, bắt đầu có ý tưởng đưa sản phẩm phần mềm thực thi Khối lượng công việc giai đoạn trình sản xuất phần mềm thay đổi theo thời gian Bảng 1.1 minh họa cụ thể điều Bảng 1.1 - Tỉ lệ công việc giai đoạn phát triển phần mềm Giai đoạn Phân tích yêu cầu Hai thập kỉ 1960 - 1970 Thiết kế chi tiết Lập trình kiểm thử đơn vị 10% Thập kỉ 1980 Thập kỉ 1990 Thiết kế sơ 80% 20% 40% Tích hợp kiểm thử tích hợp 10% 60% 30% Kiểm thử hệ thống 20% 30% Theo tài liệu khác [5], chi phí liên quan giai đoạn vòng đời phần mềm sau: Các giai đoạn phát triển Giai đoạn sản phẩm Phân tích yêu cầu 3% Đặc tả 3% Thiết kế 5% Lập trình 7% Vận hành bảo trì 67% Kiểm thử 15% Như vậy, sản phẩm phần mềm không đơn giản đoạn mã chương trình mà nhiều phần ẩn đằng sau (Hình 1.1) Vì vậy, việc mắc lỗi khơng xảy lập trình mà xảy cao công đoạn khác qui trình phát triển sản phẩm phần mềm Việc kiểm thử phải tiến hành tất phần tạo nên sản phẩm phần mềm Đặc tả sản phẩm Duyệt lại sản phẩm Phản hồi từ phiên cũ Error! Tài liệu thiết kế Thông tin cạnh tranhkhách Kiến trúc phần mềm Tài liệu kiểm thử Khảo sát hàng Lịch biểu Dữ liệu Mã nguồn Sản phẩm cuối Setup, Help Files, Samples asn Examples, Readme files, Error Messages, Icons and Arts, User Manuals, Product Support Information, … Hình 1.1 – Sản phẩm phần mềm 1.1.2 Thế lỗi phần mềm? Có nhiều định nghĩa khác lỗi phần mềm, tựu chung, phát biểu cách tổng quát: “Lỗi phần mềm khơng khớp chương trình đặc tả nó.” [7] Dựa vào định nghĩa, thấy lỗi phần mềm xuất theo ba dạng sau:  Sai: Sản phẩm xây dựng khác với đặc tả  Thiếu: Một yêu cầu đặc tả lại khơng có sản phẩm xây dựng  Thừa: Một yêu cầu đưa vào sản phẩm mà khơng có đặc tả Cũng có trường hợp yêu cầu thuộc tính người dùng chấp nhận khác với đặc tả nên coi có lỗi Một hình thức khác xem lỗi, phần mềm khó hiểu, khó sử dụng, chậm dễ gây cảm nhận phần mềm họat động không 1.1.3 Tại lỗi phần mềm xuất hiện? Khác với cảm nhận thông thường, lỗi xuất nhiều khơng phải lập trình Nhiều nghiên cứu thực dự án từ nhỏ đến dự án lớn kết giống Số lỗi đặc tả gây nhiều nhất, chiếm khoảng 80% Có số nguyên nhân làm cho đặc tả tạo nhiều lỗi Trong nhiều trường hợp, đặc tả không viết Các nguyên nhân khác đặc tả khơng đủ cẩn thận, hay thay đổi, chưa phối hợp tốt tồn nhóm phát triển Sự thay đổi yêu cầu khách hàng nguyên nhân dễ gây lỗi phần mềm Khách hàng thay đổi yêu cầu không cần quan tâm đến tác động sau thay đổi yêu cầu phải thiết kế lại, lập lại kế hoạch, làm lại việc hồn thành Nếu có nhiều thay đổi, khó nhận biết hết phần dự án phụ thuộc phần không phụ thuộc vào thay đổi Nếu không giữ vết thay đổi dễ phát sinh lỗi Nguyên nhân khác Lập trình Thiết kế Đặc tả Hình 1.2 – Các nguyên nhân gây lỗi phần mềm Nguồn gây lỗi lớn thứ hai thiết kế Đó tảng mà lập trình viên dựa vào để nỗ lực thực kế hoạch cho phần mềm Lỗi lập trình gây dễ hiểu Ai mắc lỗi lập trình Thời kì đầu, phát triển phần mềm có nghĩa lập trình, cơng việc lập trình nặng nhọc, lỗi lập trình gây chủ yếu Ngày nay, công việc lập trình phần việc trình phát triển phần mềm, cộng với hỗ trợ nhiều cơng cụ lập trình cao cấp, việc lập trình trở nên nhẹ nhàng hơn, độ phức tạp phần mềm lớn nhiều Do đó, lỗi lập trình gây Tuy nhiên, ngun nhân để lập trình tạo lỗi lại nhiều Đó độ phức tạp phần mềm, tài liệu nghèo nàn, sức ép thời gian đơn giản lỗi “khơng nói lên được” Một điều hiển nhiên nhiều lỗi xuất bề mặt lập trình thực lại lỗi đặc tả thiết kế Một nguyên nhân khác tạo lỗi thân công cụ phát triển phần mềm có lỗi cơng cụ trực quan, thư viện lớp, biên dịch,… 1.1.4 Chi phí cho việc sửa lỗi Theo tài liệu trích dẫn Martin McCable [7], bảo trì phần chi phí phần mềm kiểm thử hoạt động chi phí đắt thứ hai, ước tính khoảng 40% (15/33) chi phí q trình phát triển ban đầu sản phẩm phần mềm Kiểm thử phần chi phí giai đoạn bảo trì phải tiến hành kiểm thử lại thay đổi trình sửa lỗi đáp ứng yêu cầu người dùng Kiểm thử sửa lỗi thực giai đoạn vòng đời phần mềm Tuy nhiên chi phí cho việc tìm sửa lỗi tăng cách đáng kể trình phát triển Trong tài liệu Boehm [5], có trích dẫn kết nghiên cứu IBM, GTE TRW, tổng kết lỗi phát muộn chi phí cho việc sữa lỗi lớn Chi phí tăng theo hàm mũ hình sau Chi phí để sữa lỗi Đặc tả Thiết kế lập trình Kiểm thử Phát hành Hình 1.3 – Chi phí sửa lỗi theo thời gian phát lỗi 1.1.5 Kiểm thử phần mềm gì? Kiểm thử phần mềm thường đồng nghĩa với việc tìm lỗi chưa phát Tuy nhiên, có nhiều bối cảnh kiểm thử không bộc lộ lỗi Kiểm thử phần mềm trình thực thi hệ thống phần mềm để xác định xem phần mềm có với đặc tả khơng thực mơi trường mong đợi hay khơng Mục đích kiểm thử phần mềm tìm lỗi chưa phát hiện, tìm cách sớm đảm bảo lỗi sửa, mà kiểm thử phần mềm khơng làm cơng việc chẩn đốn ngun nhân gây lỗi phát sửa lỗi Mục tiêu kiểm thử phần mềm thiết kế tài liệu kiểm thử cách có hệ thống thực cho có hiệu quả, tiết kiệm thời gian, cơng sức chi phí 1.2 Chất lƣợng phần mềm Chất lượng phần mềm khái niệm đa chiều, không dễ định nghĩa đơn giản theo cách chung cho sản phẩm là: “Sản phẩm phát triển phù hợp với đặc tả nó.” [8] Có số vấn đề khó hệ thống phần mềm, là:  Đặc tả phải định hướng theo đòi hỏi chất lượng khách hàng (như tính hiệu quả, độ tin cậy, tính dễ hiểu, tính bảo mật,…) yêu cầu tổ chức phát triển phần mềm vốn khơng có đặc tả (như u cầu khả bảo trì, tính sử dụng lại, )  Một số yêu cầu chất lượng khó cách rõ ràng  Những đặc tả phần mềm thường không đầy đủ hay mâu thuẫn Công nghệ hệ thống Quản lý đảm bảo chất lượng Công nghệ phần mềm Đảm bảo chất lượng phần mềm mềm Xác minh thẩm định phần mềm Kiểm thử phần mềm Kiểm thử phần mềm Xác minh thẩm định phần (a) Ngữ cảnh quy trình (b) Ngữ cảnh chất lượng Hình 1.4 - Kiểm thử phần mềm số ngữ cảnh Trên quan điểm qui trình, kiểm thử phần mềm phần xác minh thẩm định phần mềm Xác minh thẩm định nằm công nghệ phần mềm, công nghệ phần mềm lại phần cơng nghệ hệ thống (Hình 1.4a) Nhìn từ ngữ cảnh chất lượng (Hình 1.4b), kiểm thử phần mềm phần xác minh thẩm định phần mềm, nên xem phần đảm bảo chất lượng phần mềm Nếu phần mềm thành phần hệ thống lớn kiểm thử phần mềm xem phần quản lý đảm bảo chất lượng Và để đạt phần mềm chất lượng cao, kiểm thử coi thành phần chủ yếu hoạt động đảm bảo chất lượng phần mềm 1.3 Qui trình kiểm thử phần mềm Mục đích kiểm thử thiết kế chuỗi trường hợp kiểm thử mà có khả phát lỗi cao Để cho việc kiểm thử đạt kết tốt cần có chuẩn bị kế hoạch kiểm thử, thiết kế trường hợp kiểm thử liệu kiểm thử cho trường hợp Đây đầu vào cho giai đoạn kiểm thử Và sản phẩm công việc giai đoạn kiểm thử “báo cáo kiểm thử” mà tài liệu hóa tất trường hợp kiểm thử chạy, liệu đầu vào, đầu mong đợi, đầu thực tế mục đích kiểm thử,… (như Hình 1.5) Phân tích Thiết kế Mã hóa KIỂM THỬ Bàn giao SP Kế hoạch kiểm thử Các trường hợp kiểm thử Dữ liệu kiểm thử Các báo cáo kiểm thử Hình 1.5 – Giai đoạn kiểm thử xử lý phần mềm Qui trình kiểm thử bao gồm số giai đoạn:  Lập kế hoạch kiểm thử Bước lập kế hoạch cho tất hoạt động thực phương pháp sử dụng Các chuẩn IEEE bao gồm thông tin tác giả chuẩn bị kế hoạch, danh sách liệt kê kế hoạch kiểm thử Vấn đề quan trọng kế hoạch kiểm thử [6,7]: + Mục đích: Qui định phạm vi, phương pháp, tài nguyên lịch biểu hoạt động kiểm thử + Các tài liệu tham khảo + Các định nghĩa + Khái quát xác minh thẩm định (V&V): tổ chức, tài nguyên, trách nhiệm, công cụ, kỹ thuật phương pháp luận + Vòng đời V&V: nhiệm vụ, liệu vào kết giai đoạn vòng đời + Báo cáo xác minh thẩm định(V&V) phần mềm: mô tả nội dung, định dạng thời gian cho tất báo cáo V&V + Các thủ tục quản lý V&V bao gồm sách, thủ tục, chuẩn, thực nghiệm qui ước  Giai đoạn bố trí nhân viên kiểm thử Việc kiểm thử thường phải tiến hành cách độc lập nhóm độc lập có trách nhiệm tiến hành họat động kiểm thử, gọi nhóm kiểm thử  Thiết kế trường hợp kiểm thử Các trường hợp kiểm thử đặc tả đầu vào cho kiểm thử đầu mong đợi hệ thống với câu lệnh kiểm thử + Các phương pháp hộp đen để kiểm thử dựa chức 10 nhiên, kiểm thử beta ứng dụng “sống” phần mềm môi trường không điều khiển người phát triển 3.6 Kiểm thử hệ thống Phần mềm thành phần hệ thống lớn dựa máy tính Cuối cùng, phần mềm kết hợp chặt chẽ với thành phần khác hệ thống (như phần cứng, người, thông tin, ) dãy kiểm thử tích hợp tính hợp lệ hệ thống thực Kiểm thử hệ thống thực tế tập kiểm thử khác với mục đích thực đầy đủ hệ thống dựa máy tính Mặc dù kiểm thử có mục đích khác nhau, tất công việc nhằm kiểm tra tất thành phần hệ thống tích hợp cách hợp lý thực chức xác định 3.6.1 Kiểm thử khôi phục Nhiều hệ thống dựa máy tính cần khơi phục sai sót tiếp tục q trình xử lý khoảng thời gian xác định trước Kiểm thử khôi phục kiểm thử hệ thống có tác động đến phần mềm bị lỗi theo nhiều cách khác kiểm tra khôi phục thực hợp lý Nếu việc khôi phục tự động (được thực hệ thống) việc khởi tạo lại, kỹ thuật điểm kiểm sốt, khơi phục liệu bắt đầu lại ước lượng cho xác Nếu việc khơi phục u cầu can thiệp người, thời gian trung bình để khôi phục ước lượng để xác định giới hạn chấp nhận 3.6.2 Kiểm thử bảo mật Bất kỳ hệ thống dựa máy tính có quản lý thông tin nhạy cảm dẫn đến hoạt động có khả gây thiệt hại (hoặc lợi ích) khơng cách cho cá nhân mục tiêu cho việc thâm nhập không bất hợp pháp Kiểm thử tính bảo mật cố gắng kiểm tra kỹ thuật bảo vệ xây dựng hệ thống bảo vệ khỏi việc truy nhập bất hợp pháp 53 3.6.3 Kiểm thử ứng suất Trong suốt trình kiểm thử phần mềm trước, kỹ thuật hộp trắng hộp đen dẫn đến ước lượng triệt để chức khả thực chương trình chuẩn tắc Kiểm thử ứng suất thiết kế để đối chiếu chương trình với trạng thái không chuẩn tắc Kiểm thử ứng suất thực hệ thống với mục đich tìm giới hạn hệ thống thất bại yêu cầu tài nguyên với chất lượng, tần suất, số lượng không bình thường, chẳng hạn: − Các kiểm thử cụ thể thiết kế cho trường hợp tỷ lệ ngắt cao bình thường −Tốc độ liệu đầu vào tăng cường độ để xác định chức đáp ứng đầu vào −Thực trường hợp kiểm thử mà yêu cầu nhớ tối đa tài nguyên khác −Thiết kế trường hợp kiểm thử gây nên thất bại hệ điều hành ảo −Thực trường hợp kiểm thử gây nên tìm kiếm mức cho liệu đĩa 3.6.4 Kiểm thử khả thực Với hệ thống nhúng thời gian thực, phần mềm cung cấp chức yêu cầu không tuân theo yêu cầu khả thực không chấp nhận Các kiểm thử khả thực thường kết hợp với kiểm thử ứng suất thường yêu cầu trang bị phần cứng phần mềm Bằng việc cung cấp hệ thống, người kiểm thử phát trạng thái mà dẫn đến suy giảm thất bại hệ thống 54 CHƢƠNG MỘT SỐ ỨNG DỤNG CỤ THỂ CỦA QUI TRÌNH KIỂM THỬ 4.1 Mục tiêu Phần vào tìm hiểu số toán cụ thể nghiên cứu xây dựng liệu kiểm thử cho tốn chương trình kiểm thử tự động 4.2 Phƣơng pháp luận 4.2.1 Tổng quan phƣơng pháp Các chức hành vi hệ thống phần mềm phần xác định hệ thống không bị thay đổi khơng bị ngược lại có thay đổi mã nguồn Vì vậy, với mục đích đảm bảo chương trình khơng bị ngược lại, cần thiết phải thực việc kiểm thử hồi qui Có hai kiểu kiểm thử thường gọi kiểm thử hồi qui − Các kiểm thử chức kiểm tra tồn hệ thống có thoả mãn yêu cầu mục đích thực − Kiểm thử đơn vị tạo người lập trình để kiểm tra mặt thành phần hệ thống lớp module hành vi mong đợi Việc thực kiểm thử hồi qui có nghĩa thực nhiều trường hợp kiểm thử khác thực chúng thường xun Vì khơng thể chấp nhận việc thực thủ cơng, thời gian khơng tin cậy Do đó, cần thiết thực cách tự động 4.2.2 Phạm vi giải Có nhiều phương pháp xếp khác nghiên cứu phát triển Mỗi phương pháp có ưu nhược điểm riêng độ phức tạp tính tốn thời gian thực Vì vậy, để lấy ví dụ tốt cho việc kiểm thử khả thực hiện, chúng 55 ta chọn hai nhóm thuật tốn sau để thực kiểm thử hộp đen so sánh kết thực − Độ phức tạp O(n^2): Insertion Sort, Selection Sort, Shell Sort, Bubble Sort − Độ phức tạp O(n log n): Heap Sort, Quick Sort, Merge Sort Việc kiểm thử đơn vị mođun thuật toán sử dụng phương pháp kiểm thử hộp trắng (phương pháp đường dẫn sở) Và để minh hoạ cho qui trình kiểm thử tích hợp thử lấy module MergeSort để thiết kế kiểm thử 4.2.3 Phân loại kiểu kiểm thử Vấn đề kiểm thử phần mềm, ngồi mục đich phát lỗi nhằm để đảm bảo chất lượng phần mềm Do đó, chọn thuật tốn xếp làm ví dụ qui trình kiểm thử, ngồi lý nêu trên, việc lựa chọn nhằm kiểm tra khả thực phần mềm (mỗi thuật tốn có ưu nhược điểm khác nhớ, thời gian, ) Phát biểu cho toán xếp sau: −Với P chương trình xếp − S bảng đặc tả cho P sau: + P nhận đầu vào với số nguyên N (N > 0) dãy N số nguyên gọi phần tử dãy ≤ K ≤ e -1 với e + K phần tử dãy + Chương trình P xếp dãy theo thứ tự tăng dần xuất dãy xếp − P xem với đặc tả S nếu: với đầu vào hợp lệ, đầu P tương ứng với đặc tả S 56 4.2.4 Tổ chức giao diện kiểm thử Để thực trường hợp kiểm thử, cần thiết kế cho chương trình trình giao diện để kiểm thử Có nhiều cách thiết kế giao diện khác − Các kiểm thử hướng lơ: giao diện cho chương trình dòng lệnh, kiểm thử tự động thực hiện, bắt đầu chương trình với tham số cho xem xét đầu ra, tập tin tạo − Kiểm thử dựa luồng: Cách bao gồm hầu hết phương pháp kiểm thử − Kiểm thử GUI: giao diện người dùng đồ hoạ cho việc kiểm thử có vài vấn đề Mặc dù có cơng cụ cho giao diện đồ hoạ kiểm thử cách làm lại hành động ghi lại trước giống kiện phím bấm chuột hình so sánh, chúng khơng thể đối phó tốt với cải biên thay đổi nhiều thành phần giao diện Vì thế, trường hợp kiểm thử cần ghi lại sau thay đổi giao diện người dùng − Các giao diện mã kiểm thử nhúng: Trong trường hợp kiểm thử lưu trình hướng lơ đơn giản giao diện ứng dụng giao diện khơng cung cấp đủ truy cập GUI cần kiểm thử, tập hợp thành phần sử dụng không cung cấp giao diện kiểm thử thích hợp, giao diện kiểm thử nhúng ứng dụng hữu ích Giao diện người dùng Lệnh Giao diện kiểm thử liệu nhúng Bộ kiểm thử Ứng dụng Các kết Hình 4.1– Giao diện kiểm thử nhúng 57 4.3 Phát sinh trƣờng hợp kiểm thử 4.3.1 Chiến lƣợc kiểm thử Việc kiểm thử thuật toán xếp thực theo nhiều mức khác nhau: − Mức cao: bao gồm việc kiểm thử chức năng, kiểm thử khả thực − Mức thấp: bao gồm việc kiểm thử đơn vị kiểm thử tích hợp thành phần Với việc kiểm thử mức cao cho thuật toán xếp, thiết kế trường hợp kiểm thử nhằm kiểm tra khả tối đa phần tử dãy hiệu thuật toán Vì vậy, mức sử dụng phương pháp hộp đen để sinh liệu đầu vào kiểm tra kết đầu theo đặc tả thuật toán Ở mức thấp, để thực kiểm thử cho thuật toán cần thiết kế trường hợp kiểm thử với mục đích tìm lỗi mã lệnh Vì vậy, cần thâm nhập vào mã lệnh thuật toán áp dụng phương pháp hộp trắng để phát sinh trường hợp kiểm thử, xây dựng liệu kiểm thử tương ứng 4.3.2 Kiểm thử đơn vị Trong kiểm thử hộp trắng, giao diện người dùng bỏ qua Các đầu vào đầu kiểm thử trực tiếp mức mã kết so sánh theo đặc tả  Module Merge Sort Hình 4.2 – Minh hoạ thuật toán xếp MergeSort 58 Module MergeSort có cấu trúc sau: − Merge: Module nối hai mảng xếp, miền kề sát mảng thành mảng đơn, mảng xếp Sau vùng hai miền ghi đè mảng xếp Vì cần cung cấp khơng gian tạm thời tham số cho hàm − Split : Hàm tách nhận vào miền chia thành hai nửa, gọi đệ qui cho nửa, chứa nhiều phần tử sau nối hai nửa kề sát hàm nối − MergeSort:Module giao diện người dùng cuối cho chức xếp Trong nhớ tạm thời cấp phát sau hàm tách gọi với tham số khởi tạo MergeSort Chúng ta khó để kiểm thử ba chức cách độc lập, đề xuất gọi phụ thuộc áp dụng kiểm Split thử tích hợp chức cách tích hợp từ xuống tích hợp từ lên Để dễ phát sinh trường Merge hợp kiểm thử quan sát 4.3.2.1 Xác định trường hợp kiểm thử thiết kế kiểm thử Các trường hợp kiểm thử sinh từ mô tả chức đơn vị Có phương pháp luận kiểm thử với vài cách tiếp cận để phát sinh trường hợp kiểm thử, đơi cần suy đốn để tìm trường hợp kiểm thử có khả phát lỗi Để thiết kế trường hợp kiểm thử cho module mergesort áp dụng phương pháp kiểm thử đường dẫn sở  Các trường hợp kiểm thử cho chức merge Áp dụng phương pháp đường dẫn sở, xây dựng đồ thị lưu trình sau: −Vẽ đồ thị lưu trình cho hàm merge 59 R6 R3 R1 R4 R2 10 R5 11 12 Hình 4.3 - Đồ thị lƣu trình chức merge − Đối chiếu hình 4.2, xác định độ phức tạp cyclomat V(G) theo công thức: V(G) = số vùng = V(G) = số cạnh - số đỉnh + = 16 -12 + = V(G) = Số đỉnh điều kiện + = (Các đỉnh 2, 3, 4, 8, 10 đỉnh điều kiện) Vậy độ phức tạp cyclomat tính V(G) = − Xác định tập sở đường dẫn độc lập + Đường dẫn : ⇒ ⇒ ⇒ 10 ⇒ 12 + Đường dẫn 2: → → → 10 ⇒ 11 ⇒ 10 →… + Đường dẫn 3: → → ⇒ ⇒ → … + Đường dẫn 4: → ⇒ ⇒ → … + Đường dẫn 5: → → ⇒ ⇒ ⇒ ⇒ → … + Đường dẫn 6: → → → ⇒ ⇒ → → … Các dấu chấm lửng (…) phía sau đưòng dẫn có nghĩa đường dẫn qua phần lại cấu trúc chấp nhận − Chuẩn bị trường hợp kiểm thử để đường dẫn tập sở thực Dữ liệu nên chọn cho điều kiện đỉnh điều kiện tập thích hợp cho đường dẫn 60 + Trường hợp (ứng với đường dẫn 1): ⇒ ⇒ ⇒ 10 ⇒12 Dữ liệu cần xếp (Data): Các tham số (left, mid, right): 4 Kết mong đợi (Data): + Trường hợp (ứng với đường dẫn 2): → → → 10 ⇒ 11 ⇒ 10→ Dữ liệu xếp (Data): Các tham số (left, mid, right): 4 Kết mong đợi (data): + Trường hợp (ứng với đường dẫn 3): → → ⇒ ⇒ → … + Trường hợp (ứng với đường dẫn 4): → ⇒ ⇒ → … Dữ liệu xếp (Data): Các tham số (left, mid, right): Kết mong đợi (Data): + Trường hợp (ứng với đường dẫn 5): 1→ 2→ 3⇒ 4⇒ ⇒ ⇒ → … Dữ liệu xếp (Data): Các tham số (left, mid, right): Kết mong đợi (Data): + Trường hợp (ứng với đường dẫn 6) → →3→4⇒ 6⇒ 7→2→… Dữ liệu xếp (Data): Các tham số (left, mid, right): Kết mong đợi (Data): 61 Bảng 4.1 - Bảng trƣờng hợp kiểm thử cho module Merge Số hiệu Tên kiểm Kiểu kiểm thử thử 1.1 Merge1 Basic-Path 1.2 Merge2 Basic-Path 1.4 Merge4 Basic-Path 1.5 Merge5 Basic-Path 1.6 Merge6 Basic-Path Đặc tả Đầu vào Data: Các tham số : 4 Data: Các tham số : 4 Data: Các tham số :4 Data: Các tham số : Data: Các tham số : Kết mong đợi 1327562 1327562 3274651 13416728 132574823  Các trường hợp kiểm thử cho chức split Với chức split để chia mảng thành hai nửa, mảng có nhiều phần tử Cứ gọi đệ qui cho hai nửa Sau nối hai nửa thành mảng xếp Với chức áp dụng phương pháp kiểm thử điều kiện để phát sinh trường hợp kiểm thử Trong chức split lệnh thực ứng với điều kiện có dạng: C = E1 > E2 E1 ứng với left E2 ứng với right Điều kiện ràng buộc cho C có dạng (D1, D2) với D1 D2 >, = < Vậy trường hợp kiểm thử cho split phát sinh sau: −Trường hợp 1: left > right −Trường hợp 2: left = right −Trường hợp 3: left < right Trong left >= 0, right < số phần tử dãy cần tách 62 Bảng 4.2 – Các trƣờng hợp kiểm thử cho module Split Số hiệu Tên kiểm Đặc tả Kiểu kiểm thử thử Đầu vào 2.1 Split Condition 2.2 Split Condition 2.3 Split Condition Data: Các tham số : Data: Các tham số : 1 Data: Các tham số : Kết mong đợi 15243 31415 24569 Data dãy số cần xếp Các tham số vị trí bắt đầu kết thúc dãy cần tách  Các trường hợp kiểm thử cho chức MergeSort Chức gọi thực Split kiểm thử cuối cùng, khả xảy lỗi module khó xảy Tuy nhiên, cần thiết kế trường hợp kiểm thử cho module để thực việc kiểm thử thích hợp module tích hợp lại thành module MergeSort Với lớp liệu đầu vào tổ chức thành lớp tương đương sau: − Dữ liệu đầu vào ngẫu nhiên − Dữ liệu đầu vào có thứ tự − Dữ liệu đầu vào xếp theo thứ tự ngược Mảng xếp gồm K phần tử ( ≤ K ≤ N, N= 32000) Do miền liệu đầu vào phân hoạch thành lớp tương đương: − Lớp tương đương hợp lệ: có K phần tử với < K < 32000 − Lớp tương đương không hợp lệ: có K phần tử với K > 32000 − Lớp tương đương khơng hợp lệ: có K phần tử với K < 63 Áp dụng phương pháp phân tích giá trị biên, có trường hợp kiểm thử giá trị biên lớp phân hoạch −Trường hợp mảng có phần tử −Trường hợp mảng có phần tử −Trường hợp mảng có 32000 phần tử −Trường hợp mảng có 32001 phần tử Từ việc phân tích trường hợp hợp lệ khơng hợp lệ trên, tổng kết bảng trường hợp kiểm thử cho MergeSort sau Số hiệu Tên kiểm thử Đầu vào 3.1 MergeSort Partition 3.2 MergeSort Partition 3.3 MergeSort Partition 3.4 MergeSort Partition 3.5 MergeSort 3.6 MergeSort VBA 3.7 MergeSort VBA 64 Đặc tả Kiểu kiểm thử Data: Các tham số : Data: Các tham số : Data: Các tham số : Data: [] Các tham số: Partition- Data: …2 VBA Các tham số: 32000 Data: Các tham số: Data: Các tham số: 32001 Kết mong đợi 12345 12345 12345 [] 12347… 122678… 4.3.2.2 Bộ điều khiển kiểm thử Sau xác định giao diện cho module trường hợp kiểm thử, bắt đầu mã hoá điều khiển kiểm thử, mà sau sử dụng để liên lạc kiểm thử mã thực Chương trình đọc tất tham số vào mảng gọi thực hàm cụ thể với tham số Sau đó, mảng kết xuất để kiểm tra với kiểm thử 4.3.2.3.Kết kiểm thử Việc kiểm thử phát vài lỗi mã, kết kiểm thử ứng với trường hợp kiểm thử cần phải ghi lại vào tập tin log việc thực kiểm thử Hình 4.4 – Giao diện điều khiển kiểm thử thuật tốn MergeSort Hình 4.5 - Kết đƣợc ghi fileLog 65 4.3.3 Kiểm thử khả thực Sau thuật toán xếp cài đặt kiểm thử đơn vị để phát lỗi, cần thực việc kiểm thử hiệu thuật toán, để kiểm tra thời gian thực thi thuật toán, số thông tin khác số phép so sánh thực hiện, số lần hoán vị thủ tục có gọi đệ qui đếm số lần thủ tục gọi Hình 4.6 – Giao diện điều khiển kiểm thử khả thực thuật toán xếp 66 KẾT LUẬN VÀ KIẾN NGHỊ Kiểm thử phần mềm hoạt động quan trọng nhằm đảm bảo chất lượng phần mềm Vấn đề đề tài mẻ Việt Nam Việc nghiên cứu lựa chọn kỹ thuật chiến lược kiểm thử phần mềm phù hợp giúp cho việc kiểm thử có hiệu quả, giảm chi phí thời gian Việc xây dựng tài liệu kiểm thử phần mềm hợp lý giúp cho việc tổ chức, quản lý thực kiểm thử có hiệu Trong khn khổ luận văn thạc sĩ, học viên nghiên cứu kĩ thuật chiến lược kiểm thử, từ áp dụng để thiết kế kiểm thử cho vài chương trình cụ thể Hiện vấn đề kiểm thử phần mềm chưa đầu tư quan tâm mức Và Việt Nam trình xây dựng ngành cơng nghiệp phần mềm khơng thể xem nhẹ việc kiểm thử phần mềm xác suất thất bại cao, nữa, hầu hết cơng ty phần mềm có uy tín đặt yêu cầu nghiêm ngặt phần mềm tài liệu kiểm thử kèm khơng chấp nhận Kết nghiên cứu áp dụng thực tế cho đề tài dự án phát triển phần mềm, làm tài liệu tham khảo cho sở tiến tới đưa qui trình kiểm thử phần mềm thành qui trình bắt buộc dự án phát triển phần mềm họ ... Chƣơng 2: Các kỹ thuật kiểm thử phần mềm Chƣơng 3: Chiến lược kiểm thử phần mềm Chƣơng 4: Một số ứng dụng cụ thể (của qui trình kiểm thử) CHƢƠNG VẤN ĐỀ CHẤT LƢỢNG PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM 1.1... – Qui trình kiểm thử phần mềm 11 Kết kiểm thử CHƢƠNG CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM Có thể sử dụng số kỹ thuật trình kiểm thử nhằm tăng hiệu họat động Mc Gregor mô tả kỹ thuật kiểm thử công cụ... Mặt khác, kỹ thuật kiểm thử công cụ để dễ dàng đạt hiệu kiểm thử Có thể chia kỹ thuật kiểm thử phần mềm thành hai loại: kỹ thuật kiểm thử hộp đen (black-box testing) kỹ thuật kiểm thử hộp trắng