Ngày nay cùng 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 các công cụ tiên tiến, yê
Trang 1MỤC LỤC
MỤC LỤC 1
LỜI MỞ ĐẦU 3
CHƯƠNG I:TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM 5
1.1 Công Nghệ Phần Mềm là gì? 5
1.2 Các lĩnh vực của Công Nghệ Phần Mềm 5
1.2.1 Các yêu cầu phần mềm (Software requirements) 6
1.2.2 Thiết kế phần mềm (Software design) 7
1.2.3 Xây dựng phần mềm (software construction) 8
1.2.4 Kiểm Thử Phần Mềm (software testing) 8
1.2.5 Bảo trì phần mềm (Software maintenance) 8
1.2.6 Quản lí cấu hình phần mềm (Software Configuration Management – SCM): 9 1.2.7 Quản lí Công Nghệ Phần Mềm (Software Engineering Management) 9 1.2.8 Quy trình Công Nghệ Phần Mềm (Software engineering process) 10
1.2.9 Các phương thức và công cụ trong Công Nghệ Phần Mềm 10
1.2.10 Chất lượng phần mềm 10
CHƯƠNG 2: VẤN ĐỀ CHẤT LƯỢNG PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM 12
2.1 Sản phẩm phần mềm và vấn đề kiểm thử phần mềm 12
2.1.1 Sản phẩm phần mềm là gì? 12
2.1.2 Thế nào là lỗi phần mềm? 13
2.1.3 Tại sao lỗi phần mềm xuất hiện? 14
2.1.4 Chi phí cho việc sữa lỗi 15
2.1.5 Kiểm thử phần mềm là gì? 16
2.2 Chất lượng phần mềm 17
2.3 Qui trình kiểm thử phần mềm 19
CHƯƠNG 3: CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM 22
3.1 Nguyên tắc cơ bản kiểm thử phần mềm 23
3.1.1 Mục tiêu kiểm thử 23
3.1.2 Luồng thông tin kiểm thử 23
Trang 23.1.3 Thiết kế trường hợp kiểm thử 24
3.2 Kỹ thuật kiểm thử hộp trắng (White-Box Testing) 26
3.2.1 Kiểm thử đường dẫn cơ sở (Basic Path Testing) 28
3.2.2 Kiểm thử cấu trúc điều khiển 31
3.3 Kỹ thuật kiểm thử hộp đen (Black-Box Testing) 38
3.3.1 Phân hoạch tương đương 39
3.3.2 Phân tích giá trị biên (BVA - Boundary Value Analysis) 42
3.3.3 Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph) 43
3.4 Kiểm thử đơn vị 44
3.4.1 Các lý do của kiểm thử đơn vị 45
3.4.2 Các thủ tục kiểm thử đơn vị 47
3.5 Kiểm thử tích hợp 48
3.5.1 Kiểm thử tích hợp từ trên xuống (Top-Down Integration) 49
3.5.2 Chiến lược kiểm thử từ dưới lên (Bottom-Up Testing) 51
3.5.3 Kiểm thử hồi qui 52
3.5.4 Các ghi chú trên kiểm thử tích hợp 53
3.6 Kiểm thử tính hợp lệ 55
3.6.1 Điều kiện kiểm thử tính hợp lệ 55
3.6.2 Duyệt lại cấu hình 56
3.6.3 Kiểm thử Alpha và Beta 56
3.7 Kiểm thử hệ thống 57
3.7.1 Kiểm thử khôi phục 58
3.7.2 Kiểm thử bảo mật 58
3.7.3 Kiểm thử ứng suất 59
3.7.4 Kiểm thử khả năng thực hiện 60
CHƯƠNG 4: ỨNG DỤNG 61
KẾT LUẬN 69
DANH MỤC HÌNH 70
TÀI LIỆU THAM KHẢO 71
Trang 3LỜI MỞ ĐẦU
Hàng ngày chúng ta vẫn thường được nghe những câu chuyện về sự cố phần mềm máy tính hay một lỗ hổng trong bảo mật và an toàn thông tin như: Một ngân hàng đưa ra thông báo sai lệch về sự cân bằng thu chi cho một tài khoản, trên sao Hỏa một vệ tinh dò đường đột ngột biến mất, một cửa hàng nhỏ
in hóa đơn sai cho khách hàng hay một tin tặc đã đột nhập và lấy cắp hàng triệu
số thẻ tín dụng Tại sao những sự cố này xảy ra? Phải chăng những người lập trình viên không thể tạo ra được các chương trình làm việc rõ ràng và không lỗi? Ngày nay cùng 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 các công cụ tiên tiến, yêu cầu của khách hàng về chức năng của chương trình nhiều, sự liên kết, trao đổi, xử lí thông tin chéo giữa các chương trình ngày càng cao, cộng với những giới hạn về thời gian và chi phí khiến cho các chương trình ngày càng phức tạp và việc đảm bảo một chương trình chạy không bị lỗi dường như là điều không thể Đó cũng là lí do chính để “Kiểm Thử Phần Mềm” (Software Testing) ra đời
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ẽ
Đề tài tập trung nghiên cứu, tìm hiểu, đánh giá các kỹ thuật dùng trong Kiểm Thử Phần Mềm, vị trí của Kiểm Thử Phần Mềm trong Công Nghệ Phần Mềm và thiết kế một chương trình tự động kiểm tra các liên kết của một website
Trang 4Đề tài được chia làm 4 chương:
Chương 1 là tổng quan về Công Nghệ Phần Mềm
Chương 2 là vấn đề chất lượng phần mềm và kiểm thử phần mềm
Chương 3 là phần chính của đề tài, tập trung vào phân tích đánh giá các
kỹ thuật kiểm định phần mềm
Cuối cùng là chương 4 thiết kế một chương trình kiểm thử
Trang 5CHƯƠNG I:TỔNG QUAN VỀ CÔNG NGHỆ PHẦN
MỀM
Trong chương I này trình bày những vấn đề cơ bản của các lĩnh vực của Công Nghệ Phần Mềm theo cách thống nhất của Viện Kĩ thuật Điện và điện Tử IEEE, vai trò, phạm vi của từng lĩnh vực để thấy vị trí của Kiểm Thử Phần Mềm trong ngành Công Nghệ Phần Mềm
1.1 Công Nghệ Phần Mềm là gì?
Đã có rất nhiều định nghĩa về Công Nghệ Phần Mềm, theo Ian Sommerville [8]: Công Nghệ Phần Mềm là các hoạt động bao gồm: đặc tả, phát triển, đưa vào hoạt động, bảo trì và loại bỏ phần mềm một cách có hệ thống Các
kỹ sư phần mềm được cung cấp các kỹ thuật và công cụ để phát triển các hệ thống phần mềm
Theo Stephen R Schach [9]: Công Nghệ Phần Mềm là các hoạt động nhằm đảm bảo chất lượng phần mềm, hoàn thành sản phầm đúng thời hạn trong điều kiện giới hạn về ngân sách và làm hài lòng khách hàng
Và theo từ điển tin học IEEE [10], Công Nghệ Phần Mềm là việc áp dụng một cách có hệ thống các nguyên tắc, các tiêu chuẩn đảm bảo chất lượng để phát triển, đưa vào hoạt động và bảo trì một sản phẩm phần mềm
Như vậy, Công Nghệ Phần Mềm là một lĩnh vực nghiên cứu của tin học, nhằm đưa ra các nguyên lí, phương pháp, công cụ, cách tiếp cận và phương tiện phục vụ cho việc thiết kế, cài đặt và bảo trì các sản phẩm phần mềm, đảm bảo các tiêu chuẩn về chất lượng
1.2 Các lĩnh vực của Công Nghệ Phần Mềm
Với các mục đích: đưa ra một cái nhìn tổng quan về Công Nghệ Phần Mềm thống nhất trên toàn thế giới; Tạo ranh giới để phân biệt Công Nghệ Phần Mềm với các lĩnh vực khác trong ngành Công nghệ thông tin như Khoa học máy tính, Quản lí dự án, Công nghệ máy tính hay Toán học; Miêu tả các vấn đề cơ
Trang 6nền tảng đại cương cho các chương trình phát triển, hệ thống chứng chỉ và bản quyền Viện Kỹ thuật Điện và Điện Tử (IEEE) đã chia Công Nghệ Phần Mềm thành 10 lĩnh vực [7] theo hình 1.1
Hình 1.1: Các lĩnh vực trong Công Nghệ Phần Mềm
Trong phần tiếp theo đề tài trình bày khái quát về chức năng, vai trò và phạm vi của những lĩnh vực con của Công Nghệ Phần Mềm
1.2.1 Các yêu cầu phần mềm (Software requirements)
Một yêu cầu phần mềm [7] là một thuộc tính được thể hiện đúng khi phần mềm được tạo ra để giải quyết một vấn đề nào đó Ví như tự động hóa một khâu nào đó của người sử dụng, hỗ trợ doanh nghiệp ra quyết định hay điều khiển thiết
bị Cũng có thể xem yêu cầu như một chức năng phải tồn tại trên hệ thống Chức năng của con người, các quy trình của doanh nghiệp và các thiết bị trong mỗi hệ thống là khác nhau vì thế nên các yêu cầu phần mềm có thể được định nghĩa là tổng hợp các yêu cầu của người sử dụng tại mỗi bộ phận khác nhau của tổ chức
và từ môi trường nơi phần mềm sẽ được sử dụng Cần phân biệt một số loại yêu cầu:
Trang 7+ Yêu cầu chức năng và yêu cầu không chức năng: Yêu cầu chức năng là các yêu cầu về dịch vụ mà hệ thống phải đáp ứng; Yêu cầu không chức năng là các ràng buộc mà hệ thống phải tuân theo
+ Yêu cầu hệ thống và yêu cầu phần mềm: Hệ thống là sự phối hợp hoạt động của các thành phần nhằm thực hiện một mục đích định trước, bao gồm các thành phần như: phần cứng, phần mềm, con người, thông tin, kỹ thuật, dịch vụ … Yêu cầu hệ thống là các yêu cầu cho toàn hệ thống Khi một hệ thống chứa các thành phần phần mềm thì các yêu cầu phần mềm chính là các yêu cầu hệ thống
1.2.2 Thiết kế phần mềm (Software design)
Thiết kế phần mềm [7] là một quy trình của việc định nghĩa kiến trúc, các thành phần, giao diện và các đặc tính khác của hệ thống hay thành phần của hệ thống và kết quả của quy trình đó
Cơ bản về thiết kế phần mềm: Cung cấp các khái niệm cơ bản làm rõ vai trò và phạm vi của thiết kế phần mềm Đó là những phái niệm chung, ngữ cảnh, quy trình và các kỹ thuật sử dụng trong thiết kế phần mềm
Một số đặc trưng trong thiết kế phần mềm: Đó là sự trùng lặp, điều khiển
và thao tác sự kiện, sự phân tán của các thành phần, lỗi và khả năng chịu lỗi, tương tác và biểu diễn và cuối cùng là tính đồng nhất dữ liệu
Kiến trúc và cấu trúc phần mềm: Kiến trúc phần mềm là sự miêu tả các hệ thống con và các thành phần của một hệ thống phần mềm và mối liên hệ giữa chúng Một số đặc tính của kiến trúc phần mềm đó là: điểm nhìn, phong cách thiết kế, thiết kế mẫu và tập hợp các chương trình sử dụng lại
Các chú thích thiết kế phần mềm: Bao gồm các quy định, các chuẩn dùng
để miêu tả, giải thích trên các thiết kế
Các phương pháp và chiến lược thiết kế: Phương pháp thiết kế đầu tiên phải được đến đó là miêu tả, sau đó là các phương pháp thiết kế hướng chức năng, phương pháp thiết kế hướng đối tượng, thiết kế cấu trúc dữ liệu trung tâm
và thiết kế hướng thành phần
Trang 81.2.3 Xây dựng phần mềm (software construction)
Xây dựng phần mềm [7] là những việc làm trực tiếp để tạo ra sản phẩm phần mềm bao gồm các hoạt động như viết mã chương trình, kiểm tra, kiểm thử đơn vị, kiểm thử tích hợp và gỡ lỗi Xây dựng phần mềm bao gồm 3 lĩnh vực nhỏ:
Cơ bản về xây dựng phần mềm: 4 nguyên lí cơ bản trong xây dựng phần mềm đó là: Giảm tới mức tối thiểu độ phức tạp; Dự đoán trước sự thay đổi; Tạo các đầu mối để kiểm tra và cuối cùng là tuân thủ theo các chuẩn
Quản lí xây dựng phần mềm: Quản lí xây dựng phần mềm bao gồm các chủ đề nhỏ là các mô hình xây dựng, kế hoạch xây dựng và đo lường xây dựng Các khía cạnh thực hành trong xây dựng phần mềm: đó là thiết kế xây dựng, các ngôn ngữ xây dựng, lập trình, kiểm thử, tái sử dụng, chất lượng xây dựng và tích hợp
1.2.4 Kiểm Thử Phần Mềm (software testing)
Các khái niệm, vai trò và các kỹ thuật Kiểm Thử Phần Mềm sẽ được trình này chi tiết trong Chương II của đề tài
1.2.5 Bảo trì phần mềm (Software maintenance)
Trong quá trình hoạt động một số khuyết điểm bộc lộ, môi trường hoạt động thay đổi và những yêu cầu mới của người dùng phát sinh do đó đòi hỏi phải
có một quá trình bảo trì phần mềm [7] Quá trình bảo trì phần mềm bắt đầu khi thời gian bảo hành phần mềm kết thúc hay các hỗ trợ sau cài đặt được chuyển giao, nhưng các hoạt động bảo trì phần mềm thực sự thì xuất hiện sớm hơn Bảo trì phần mềm được định nghĩa như là các hoạt động để đảm bảo hỗ trợ sản phẩm phần mềm hoạt động tốt nhất Các hoạt động được thực hiện cả trước và sau khi chuyển giao phần mềm, bao gồm: Lập kế hoạch cho các hoạt động sau khi chuyển giao, cho các hoạt động bảo trì và yêu cầu hậu cần cho các hoạt động
Trang 9chuyển giao Các hành động bảo trì phần mềm sau khi chuyển giao bao gồm việc sửa chữa phần mềm, đào tạo và tạo kênh thông tin trao đổi và hỗ trợ
1.2.6 Quản lí cấu hình phần mềm (Software Configuration Management – SCM):
Một hệ thống là một tập các thành phần được tổ chức để thực hiện một chức năng hay một tập các chức năng Cấu hình của một hệ thống [7] là các đặc tính vật lí hay thuộc chức năng của phần cứng, phần mềm hay tổng hợp của phần mềm và phần cứng Những thuộc tính này phối hợp với nhau theo một thủ tục, một cách nào đó để phục vụ cho một mục đích định trước Quản lí cấu hình là lĩnh vực áp dụng các kỹ thuật, sự trực tiếp quản lí và theo dõi hệ thống để xác định và ghi nhận các đặc tính vật lí và chức năng cấu hình của một thành phần nào đó trong hệ thống, điều khiển thay đổi những đặc tính đó, ghi nhận và thông báo quá trình thay đổi và trạng thái cài đặt, kiểm tra đảm bảo thỏa mãn với các yêu cầu định trước
1.2.7 Quản lí Công Nghệ Phần Mềm (Software Engineering Management)
Quản lí Công Nghệ Phần Mềm [7] được định nghĩa như một ứng dụng quản lí các hoạt động lập kế hoạch, phối hợp hoạt động, đo lường, giám sát, điều khiển và thông báo để đảm bảo sự phát triển và bảo trì của phần mềm một cách
có hệ thống và đảm bảo chất lượng Quản lí Công Nghệ Phần Mềm phân thành 6 lĩnh vực nhỏ, phân thành hai hướng chính là quản lí và đánh giá Công Nghệ Phần Mềm
Khởi tạo và xác đinh phạm vi: bao gồm một số công việc như xác định và cân đối các yêu cầu, phân tích khả năng và tạo quy trình cho việc kiểm tra, xét lại các yêu cầu
Lập kế hoạch dự án phần mềm: Bao gồm việc tạo các quy trình, xác định khả năng chuyển giao, ảnh hưởng, lên kế hoạch và ước lượng chi phí, cấp phát tài nguyên, quản lí rủi ro, quản lí chất lượng…
Trang 10Công bố dự án phần mềm: Đó là sự thực thi các kế hoạch, quản lí hợp đồng cung cấp, thực thi các quy trình đo lường, quy trình quản lí, quy trình điều khiển và thông báo
Kiểm tra và đánh giá: Xác định mức độ thỏa mãn các yêu cầu, kiểm tra và đánh giá hiệu năng
Kết thúc: Xác đinh thời điểm kết thúc và các hành động kết thúc
Đánh giá Công Nghệ Phần Mềm: Bao gồm việc khởi tạo và giữ vững những cam kết đánh giá, lập kế hoạch đánh giá, thực hiện kế hoạch và đanh giá
1.2.8 Quy trình Công Nghệ Phần Mềm (Software engineering process)
Quy trình Công Nghệ Phần Mềm [7] phân thành hai mức, mức thứ nhất bao gồm các kĩ thuật và hành động của người quản trị được sử dụng và thực hiện trong các quy trình vòng đời phần mềm, trong các quá trình phát triển, bảo trì và thu hồi Mức thứ hai tập trung vào việc định nghĩa, cài đặt, quản lí, đánh giá, thay đổi và cải tiến của các quy trình vòng đời phần mềm
1.2.9 Các phương thức và công cụ trong Công Nghệ Phần Mềm
Các công cụ phát triển phần mềm [7] là các sản phẩm, công cụ được sử dụng để trợ giúp các quy trình vòng đời phần mềm, hệ thống hóa Công Nghệ Phần Mềm
Các phương thức Công Nghệ Phần Mềm [7] đảm bảo các hoạt động được thực hiện đúng và thực hiện một cách có hệ thống, đảm bảo sự thành công
1.2.10 Chất lượng phần mềm
Có rất nhiều các định nghĩa khác nhau về chất lượng phần mềm [7] , Phil Crosby -1979 [33] định nghĩa chất lượng phần mềm là sự làm đúng theo yêu cầu của người sử dụng, IBM hướng tới thị trường, coi chất lượng phần mềm là sự hài lòng của khách hàng Mới đây nhất chất lượng phần mềm được định nghĩa theo
Trang 11yêu cầu của người dùng Viện Kĩ thuật Điện và Điện Tử IEEE chia chất lượng phần mềm thành 3 lĩnh vực nhỏ hơn:
Quy trình quản lí chất lượng phần mềm: Quản lí chất lượng phần mềm áp dụng tới tất cả các khía cạnh của các quy trình phần mềm, sản phẩm, người quản
lí quy trình và những yêu cầu, đánh giá và phản hồi từ các quy trình đó Hai công việc cơ bản trong quản lí chất lượng phần mềm là: Đưa ra các yêu cầu của sản phẩm và các đặc tính chất lượng của nó, và lên kế hoạch các quy trình để thỏa mãn những đặc tính chất lượng đó Một số các quy trình quản lí phần mềm được IEEE đưa ra là:
+ Quy trình đảm bảo chất lượng + Quy trình kiểm tra
+ Quy trình thẩm định + Quy trình tái kiểm tra + Quy trình kiểm toán Trong chương I, luận văn đã trình bày những vấn đề cơ bản của các lĩnh trong Công Nghệ Phần Mềm theo cách thống nhất của Viện Kĩ thuật Điện và điện Tử IEEE, vai trò, phạm vi của từng lĩnh vực để thấy vị trí của Kiểm Thử Phần Mềm trong ngành Công Nghệ Phần Mềm Trong chương tiếp theo, đề tài sẽ trình bày chi tiết về Kiểm Thử Phần Mềm, các kĩ thuật trong Kiểm Thử và so sánh các kĩ thuật đó
Trang 12Việc tạo ra một sản phẩm phần mềm phải trải qua nhiều giai đoạn, người ta gọi là qui trình phát triển phần mềm, bắt đầu từ khi bắt đầu có ý tưởng cho đến khi đưa ra sản phẩm phần mềm thực thi Khối lượng công việc trong từng giai đoạn của quá trình sản xuất phần mềm cũng thay đổi theo thời gian Bảng 2.1 minh họa cụ thể hơn về điều này
Bảng 2.1 - Tỉ lệ công việc của các giai đoạn phát triển phần mềm
Giai đoạn Phân tích yêu cầu Thiết kế sơ bộ Thiết kế chi tiết kiểm thử đơn vị Lập trình và Tích hợp và kiểm thử tích hợp Kiểm thử hệ thống
Các giai đoạn phát triển
Phân tích yêu cầu 3%
Trang 13lỗi không chỉ xảy ra trong khi lập trình mà còn xảy ra cao hơn trong các công đoạn khác của qui trình phát triển một sản phẩm phần mềm Việc kiểm thử cũng
vì thế phải được tiến hành trong tất cả các phần tạo nên một sản phẩm phần mềm
Hình 2.1 – Sản phẩm phần mềm
2.1.2 Thế nào là lỗi phần mềm?
Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng tựu chung, có
thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa chương
Duyệt lại sản phẩm
Tài liệu thiết kế
Tài liệu kiểm thử
Lịch biểu
Phản hồi
từ phiên bản cũ
Thông tin cạnh tranh
Khảo sát khách hàng
Dữ liệu
Kiến trúc phần mềm
Sản phẩm cuối cùng
Setup, Help Files, Samples asn Examples, Readme files, Error Messages, Icons and Arts, User Manuals, Product Support Information, …
Trang 14 Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm được xây dựng
Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả Cũng
có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi
Một hình thức khác nữa cũng được xem là lỗi, đó là phần mềm khó hiểu, khó sử dụng, chậm hoặc dễ gây cảm nhận rằng phần mềm họat động không đúng
2.1.3 Tại sao lỗi phần mềm xuất hiện?
Khác với sự cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải do lập trình Nhiều nghiên cứu đã được thực hiện trong các dự án từ rất nhỏ đến các
dự án rất lớn và kết quả luôn giống nhau Số lỗi do đặc tả gây ra là nhiều nhất, chiếm khoảng 80% Có một số nguyên nhân làm cho đặc tả tạo ra nhiều lỗi nhất Trong nhiều trường hợp, đặc tả không được viết ra Các nguyên nhân khác có thể
do đặc tả không đủ cẩn thận, nó hay thay đổi, hoặc do chưa phối hợp tốt trong toàn nhóm phát triển Sự thay đổi yêu cầu của khách hàng cũng là nguyên nhân
dễ gây ra lỗi phần mềm Khách hàng thay đổi yêu cầu không cần quan tâm đến những tác động sau khi thay đổi yêu cầu như phải thiết kế lại, lập lại kế hoạch, làm lại những việc đã hoàn thành Nếu có nhiều sự thay đổi, rất khó nhận biết hết được phần nào của dự án phụ thuộc và phần nào không phụ thuộc vào sự thay đổi Nếu không giữ được vết thay đổi rất dễ phát sinh ra lỗi
Hình 2.2 – Các nguyên nhân gây ra lỗi phần mềm
Nguồn gây ra lỗi lớn thứ hai là thiết kế Đó là nền tảng mà lập trình viên
Đặc tả
Nguyên nhân khác Lập trình
Thiết kế
Trang 15Lỗi do lập trình gây ra cũng khá dễ hiểu Ai cũng có thể mắc lỗi khi lập trình Thời kì đầu, phát triển phần mềm có nghĩa là lập trình, công việc lập trình thì nặng nhọc, do đó lỗi do lập trình gây ra là chủ yếu Ngày nay, công việc lập trình chỉ là một phần việc của quá trình phát triển phần mềm, cộng với sự hỗ trợ của 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, mặc dù
độ phức tạp phần mềm lớn hơn rất nhiều Do đó, lỗi do lập trình gây ra cũng ít hơn Tuy nhiên, nguyên nhân để lập trình tạo ra lỗi lại nhiều hơn Dó là do độ phức tạp của phần mềm, do tài liệu nghèo nàn, do sức ép thời gian hoặc chỉ đơn giản là những lỗi “không nói lên được” Một điều cũng hiển nhiên là nhiều lỗi xuất hiện trên bề mặt lập trình nhưng thực ra lại do lỗi của đặc tả hoặc thiết kế
Một nguyên nhân khác tạo ra lỗi là do bản thân các công cụ phát triển phần mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch,…
2.1.4 Chi phí cho việc sữa lỗi
Theo tài liệu trích dẫn của Martin và McCable [12], bảo trì là phần chi phí chính của phần mềm và kiểm thử là hoạt động chi phí đắt thứ hai, ước tính khoảng 40% (15/33) chi phí trong quá trình phát triển ban đầu của sản phẩm phần mềm Kiểm thử cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hành kiểm thử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu người dùng
Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phần mềm Tuy nhiên chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể trong quá trình phát triển
Sự thay đổi một tài liệu yêu cầu khi duyệt lại lần đầu tiên là không đắt nếu không nói là không đáng kể Chi phí sẽ tăng lên nhiều hơn nếu các yêu cầu thay đổi sau khi đã lập trình Thay đổi yêu cầu lúc đó đồng nghĩa với việc viết lại chương trình
Trang 16Việc sửa lỗi sẽ không còn đáng kể nếu người lập trình tự phát hiện lỗi của mình Không có sự liên quan đến chi phí khác Họ không phải giải thích lỗi cho bất kỳ người nào Họ cũng không phải nhập lại lỗi đó vào cơ sở dữ liệu lỗi và lưu vết lỗi Người kiểm thử và người quản lý không phải phải duyệt lại tình trạng lỗi
Và lỗi đó không ảnh hưởng đến công việc của người khác trong nhóm dự án
Sửa một lỗi trước khi phát hành một phần mềm rẻ hơn rất nhiều so với việc khắc phục nó sau khi đã phát hành
Trong tài liệu Boehm [4], có trích dẫn kết quả nghiên cứu của IBM, GTE và TRW, tổng kết rằng lỗi được phát hiện càng muộn thì chi phí cho việc sữa lỗi càng lớn Chi phí tăng theo hàm mũ như hình sau
Hình 2.3 – Chi phí sửa lỗi theo thời gian phát hiện lỗi
Chúng ta đã từng chứng kiến sự cố máy tính năm 2000 Từ một giải pháp tiết kiệm bộ nhớ là biểu diễn năm có bốn chữ số thành năm có hai chữ số cuối vào đầu những năm 70 của thế kỷ trước dẫn đến việc 25 năm sau làm cả thế giới
lo sợ và phải bỏ ra nhiều tỉ đô la để khắc phục
2.1.5 Kiểm thử phần mềm là gì?
Kiểm thử phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được phát hiện Tuy nhiên, có nhiều bối cảnh kiểm thử không bộc lộ ra lỗi Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó
Trang 17có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay không
Trên thực tế, hệ thống đang thực hiện khác biệt với việc duyệt lại mã nguồn Thông thường, người phát triển thực hiện việc đọc lại và phân tích mã nguồn Nói cách khác, kiểm thử đòi hỏi một hệ thống chạy được Đặc tả là căn cứ chủ yếu hỗ trợ cho việc kiểm thử Nó xác định những hành vi đúng và làm cho dễ dàng hơn trong việc xác định những hành vi không đúng Mỗi hành vi không đúng chính là một lỗi phần mềm Nói chung, người phát triển phải tự chẩn đoán nguyên nhân sinh lỗi trong mã nguồn
Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm một cách sớm nhất có thể và đảm bảo rằng lỗi đã được sửa, mà kiểm thử phần mềm không làm công việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện
và sửa lỗi Chúng ta sẽ nghiên cứu kĩ hơn vấn đề này ở những phần tiếp theo
Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có
hệ thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian, công sức và chi phí
2.2 Chất lượng phần mềm
Chất lượng phần mềm là một khái niệm đa chiều, không dễ định nghĩa đơn
giản theo cách chung cho các sản phẩm là: “Sản phẩm được phát triển phù hợp
với đặc tả của nó.” (Ian Samerville [13] trích dẫn định nghĩa của Crosby) Có
một số vấn đề khó trong hệ thống phần mềm, đó là:
Đặc tả phải định hướng theo những đòi hỏi về chất lượng của khách hàng (như tính hiệu quả, độ tin cậy, tính dễ hiểu, tính bảo mật,…) và những yêu cầu của chính tổ chức phát triển phần mềm vốn không có trong đặc tả (như các yêu cầu về khả năng bảo trì, tính sử dụng lại, )
Trang 18 Một số yêu cầu về chất lượng cũng rất khó chỉ ra một cách rõ ràng (như tính bảo trì)
Những đặc tả phần mềm thường không đầy đủ và hay mâu thuẫn
Vì thế phải có sự thỏa hiệp về chất lượng:
Chúng ta không thể đợi các đặc tả hoàn thiện trước khi chú ý đến quản lý chất lượng
Chúng ta phải sắp xếp các thủ tục để hoàn thiện chất lượng mặc dù đặc tả chưa hoàn thiện
Quản lý chất lượng không chỉ quan tâm đến việc làm hạn chế tối thiểu những khiếm khuyết của sản phẩm và đảm bảo tuân theo đặc tả, mà còn phải quan tâm đến những thuộc tính chất lượng khác của sản phẩm
Hình 2.4 - Kiểm thử phần mềm trong một số ngữ cảnh
Trên quan điểm qui trình, kiểm thử phần mềm là một phần của xác minh và thẩm định phần mềm Xác minh và thẩm định nằm trong công nghệ phần mềm, công nghệ phần mềm lại là một phần của công nghệ hệ thống (Hình 2.4a) Nhìn
từ ngữ cảnh chất lượng (Hình 2.4b), kiểm thử phần mềm cũng là một phần phần của xác minh và thẩm định phần mềm, nên cũng có thể xem như là một phần của đảm bảo chất lượng phần mềm Nếu phần mềm là thành phần của hệ thống lớn hơn thì kiểm thử phần mềm cũng được xem như là một phần của quản lý và đảm
Công nghệ hệ thống
Công nghệ phần mềm
Xác minh và thẩm định
phần mềm Kiểm thử phần mềm
Quản lý và đảm bảo chất lượng Đảm bảo chất lượng phần mềm Xác minh và thẩm định phần mềm Kiểm thử phần mềm
Trang 19bảo chất lượng Và để đạt phần mềm chất lượng cao, thì kiểm thử có thể coi là một thành phần chủ yếu của hoạt động đảm bảo chất lượng phần mềm
2.3 Qui trình kiểm thử phần mềm
Mục đích của kiểm thử là thiết kế một chuỗi các trường hợp kiểm thử mà có khả năng phát hiện lỗi cao Để cho việc kiểm thử đạt được kết quả tốt cần có sự chuẩn bị về kế hoạch kiểm thử, thiết kế các trường hợp kiểm thử và các dữ liệu kiểm thử cho các trường hợp Đây chính là đầu vào cho giai đoạn kiểm thử Và sản phẩm công việc của giai đoạn kiểm thử chính là “báo cáo kiểm thử” mà tài liệu hóa tất cả các trường hợp kiểm thử dã chạy, dữ liệu đầu vào, đầu ra mong đợi, đầu ra thực tế và mục đích của kiểm thử,… (như Hình 2.5)
Hình 2.5 – Giai đoạn kiểm thử trong xử lý phần mềm
Qui trình kiểm thử bao gồm một số giai đoạn:
Lập kế hoạch kiểm thử Bước đầu tiên là lập kế hoạch cho tất cả các hoạt động sẽ được thực hiện và các phương pháp được sử dụng Các chuẩn IEEE 1012-1986 bao gồm các thông tin về tác giả chuẩn bị kế hoạch, danh sách liệt kê của kế hoạch kiểm thử Vấn đề quan trọng nhất đối với kế hoạch kiểm thử[IEEE86]:
+ Mục đích: Qui định về phạm vi, phương pháp, tài nguuyên và lịch biểu của các hoạt động kiểm thử
+ Các tài liệu tham khảo
+ Các định nghĩa
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ử
Trang 20+ Khái quát về xác minh và thẩm định (V&V): tổ chức, tài nguyên, trách nhiệm, các công cụ, kỹ thuật và các phương pháp luận.
+ Vòng đời của V&V: các nhiệm vụ, các dữ liệu vào và các kết quả ra trên một giai đoạn vòng đời
+ Báo cáo xác minh và thẩm định(V&V) phần mềm: mô tả nội dung, định dạng và thời gian cho tất cả các báo cáo V&V
+ Các thủ tục quản lý V&V bao gồm các chính sách, thủ tục, các chuẩn, thực nghiệm và các 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 một cách độc lập và các nhóm độc lập có trách nhiệm tiến hành các họat động kiểm thử, gọi là các nhóm kiểm thử
Thiết kế các trường hợp kiểm thử Các trường hợp kiểm thử là các đặc tả đầu vào cho kiểm thử và đầu ra mong đợi của hệ thống cùng với các câu lệnh được kiểm thử Có một vài phương pháp thiết kế trường hợp kiểm thử
và các qui tắc từ các nhà thiết kế kiểm thử có kinh nghiệm Tuy nhiên, có hai chiến lược kiểm thử cơ bản
Các phương pháp hộp đen để kiểm thử dựa trên chức năng
Các phương pháp hộp trắng để kiểm thử dựa vào cấu trúc bên trong
Xử lý đo lường kiểm thử bằng cách thu thập dữ liệu Ở đây, người kiểm thử không thể trực tiếp cải tiến chương trình mà họ chỉ có thể đánh giá nó
Đánh giá sản phẩm phần mềm để xác nhận sản phẩm có thể sẵn sàng phát hành được chưa?
Mô hình chung của qui trình kiểm thử phần mềm được thể hiện trong hình 2.6
Trang 21Hình 2.6 – Qui trình kiểm thử phần mềm
Kết quả kiểm thử
Thiết kế các
trường hợp
kiểm thử
Chuẩn bị dữ liệu kiểm thử
Chạy chương trình với dữ liệu kiểm thử
So sánh các kết quả với các trường hợp kiểm thử
Các trường hợp kiểm thử
Dữ liệu kiểm thử
Kết quả kiểm thử
Trang 22CHƯƠNG 3: CÁC KỸ THUẬT KIỂM THỬ PHẦN
MỀM
Có thể sử dụng một số kỹ thuật trong quá trình kiểm thử nhằm tăng hiệu quả của họat động này Mc Gregor (2001) mô tả các kỹ thuật kiểm thử như những công cụ được thiết kế để đảm bảo rằng tất cả các khía cạnh của sản phẩm đều được khảo sát Mặt khác, các kỹ thuật kiểm thử là những công cụ để dễ dàng đạt được hiệu quả kiểm thử
Có thể chia các kỹ thuật kiểm thử phần mềm thành hai loại: các kỹ thuật kiểm thử hộp đen (black-box testing) và kỹ thuật kiểm thử hộp trắng (white-box testing) Các kỹ thuật kiểm thử hộp đen nhận được các kiểm thử từ đặc tả thiết kế chức năng không cần quan tâm cấu trúc chương trình bên trong (Kit, 1995) Người kiểm thử đưa ra các đầu vào cho thành phần hoặc hệ thống và xem xét đầu
ra tương ứng Nếu các đầu ra thực tế phù hợp với các đầu ra mong muốn thì kiểm thử xác nhận rằng chức năng được kiểm thử như mong muốn Nếu các đầu ra là không đúng các dự đoán của chúng thì kiểm thử đã thành công trong việc phát hiện được lỗi phần mềm (Sommerville, 2001) Kiểm thử sử dụng kỹ thuật hộp đen thường được gọi đơn giản là các kiểm thử black-box Các kiểm thử black-box tìm các lỗi như thiếu các chức năng, khả năng sử dụng và các yêu cầu phi chức năng
Các kỹ thuật kiểm thử white-box yêu cầu hiểu biết về cấu trúc chương trình bên trong và các kiểm thử nhận được từ đặc tả thiết kế bên trong hoặc từ mã (Kit, 1995) Phân tích mức độ phủ là kỹ thuật kiểm thử hộp trắng – nó phát hiện những phần nào của mã sẽ được thực hiện trong khi kiểm thử Thực hiện kiểm thử hộp trắng có thể làm sáng tỏ các lỗi tìm thấy trong kiểm thử hộp đen bởi vì chúng xem xét phần mềm thông qua việc nghiên cứu cấu trúc của nó
Trang 233.1 Nguyên tắc cơ bản kiểm thử phần mềm
Trong lúc kiểm thử, công nghệ phần mềm phát sinh một chuỗi các trường hợp kiểm thử được sử dụng để “tách từng phần” phần mềm Kiểm thử là một bước trong qui trình phần mềm mà có thể được xem xét bởi đội ngũ phát triển bằng cách phá vỡ thay vì xây dựng Các kỹ sư phần mềm chính là những người xây dựng và việc kiểm thử yêu cầu họ vượt qua các khái niệm cho trước về độ chính xác và giải quyết mâu thuẫn khi các lỗi được xác định
3.1.1 Mục tiêu kiểm thử
Các nguyên tắc được xem như mục tiêu kiểm thử là:
Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi
Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng cao việc tìm thấy các lỗi chưa từng được phát hiện
Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được phát hiện
3.1.2 Luồng thông tin kiểm thử
Luồng thông tin cho kiểm thử được biểu diễn bởi mô hình trong hình 3.1 Hai kiểu của đầu vào được truyền cho quá trình kiểm thử:
Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã nguồn
Cấu hình kiểm thử: gồm có kế hoạch kiểm thử, các thủ tục, trường hợp kiểm thử, và các công cụ kiểm thử
Kiểm thử được thực hiện và tất cả các kết quả được xem xét, kết quả kiểm thử được so sánh với kết quả mong đợi Khi dữ liệu không đúng được nhận biết, lỗi được bao hàm và việc gỡ rối bắt đầu Thủ tục gỡ rối là thành phần khó dự đoán nhất của thủ tục kiểm thử Một “lỗi” với sự khác nhau 0.01% giữa các kết
Trang 24và hiệu chỉnh Sự không chắc trong gỡ rối mà kiểm thử gây nên sẽ là khó lập lịch biểu độ tin cậy
Hình 3.1 - Luồng thông tin kiểm thử
3.1.3 Thiết kế trường hợp kiểm thử
Thiết kế kiểm thử phần mềm có thể là một quá trình thu thập, phân tích và thực hiện yêu cầu Tuy nhiên, các kỹ sư phần mềm thường xem kiểm thử như một giai đoạn cuối cùng, sau giai đoạn lập trình Các trường hợp kiểm thử được hoạch định có thể tạo ra cảm giác đúng nhưng ít được đảm bảo là chúng sẽ hoàn thành Mục tiêu của kiểm thử là phải thiết kế các trường hợp kiểm thử có khả năng cao nhất trong việc phát hiện nhiều lỗi nhất với thời gian và công sức tối thiểu Một số lượng lớn các phương pháp thiết kế trường hợp kiểm thử đã được phát triển, cung cấp cho đội ngũ phát triển cách tiếp cận có hệ thống cho việc kiểm thử Các phương pháp thường cung cấp một cách tiếp cận đảm bảo tính đầy
đủ của kiểm thử và cung cấp khả năng cao nhất để phát hiện các lỗi của phần mềm
Như vậy, vấn đề quan trọng nhất trong kiểm thử phần mềm là thiết kế và tạo ra các trường hợp kiểm thử có hiệu quả Lý do về tầm quan trọng của việc thiết kế các trường hợp kiểm thử xuất phát từ thực tế: Kiểm thử “vét cạn” là điều
Cấu hình phần mềm
Kiểm
thử
đánh giá
Gỡ rối
Mô hình tin cậy Cấu hình kiểm thử Kết quả mong đợi
Trang 25thể vét cạn (tức kiểm thử không thể đảm bảo rằng chương trình không còn lỗi nào) Vấn đề quan trọng là cố gắng làm giảm sự “không thể vét cạn” nhiều nhất
có thể
Kiểm thử phần mềm còn có các ràng buộc về thời gian, chi phí, … Chìa
khoá của kiểm thử là trả lời của câu hỏi: “Tập con của tất cả các trường hợp
kiểm thử có thể có xác suất phát hiện lỗi cao nhất là gì?” Việc nghiên cứu các
phương pháp thiết kế trường hợp kiểm thử sẽ cung cấp câu trả lời cho câu hỏi này
Bất kỳ sản phẩm công nghệ nào có thể được kiểm thử trong hai cách:
Biết về các chức năng cụ thể mà sản phẩm đã được thiết kế để thực hiện, các kiểm thử có thể được thực hiện để chứng tỏ mỗi chức năng được thực hiện đầy đủ, tại một thời điểm nào đó tìm kiếm các lỗi trong mỗi chức năng;
Biết cách hoạt động bên trong của sản phẩm, kiểm thử có thể được thực hiện để đảm bảo rằng “tất cả các thành phần ăn khớp nhau”, tức là, hoạt động bên trong thực hiện theo đặc tả và tất cả các thành phần bên trong đã được thực hiện một cách thoả đáng
Cách tiếp cận kiểm thử đầu tiên được gọi là kiểm thử hộp đen và cách thứ hai là kiểm thử hộp trắng
Khi phần mềm máy tính được xem xét, kiểm thử hộp đen ám chỉ các kiểm thử mà được thực hiện trên giao diện phần mềm Mặc dù chúng được thiết kế để phát hiện các lỗi, các kiểm thử hộp đen được sử dụng để chứng tỏ các chức năng phần mềm là hoạt động; rằng đầu vào được chấp nhận một cách hợp lý và đầu ra được sinh ra phù hợp; và duy trì tính toàn vẹn của thông tin bên ngoài (chẳng hạn, các tập tin dữ liệu) Kiểm thử hộp đen xem xét một vài khía cạnh cơ bản của
hệ thống với sự quan sát cấu trúc logic bên trong của phần mềm
Kiểm thử hộp trắng của phần mềm được căn cứ vào việc xem xét cẩn thận chi tiết thủ tục Các đường dẫn logic xuyên suốt phần mềm được kiểm thử bằng
Trang 26cách cung cấp các trường hợp kiểm thử thực hiện các tập xác định điều kiện và/hoặc vòng lặp “Trạng thái của chương trình” có thể được xem xét tại các điểm khác nhau để xác định các trạng thái mong đợi hoặc được khẳng định có tương ứng với các trạng thái thực tế không
3.2 Kỹ thuật kiểm thử hộp trắng (White-Box Testing)
Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra cấu trúc bên trong của phần mềm với mục đích đảm bảo rằng tất cả các câu lệnh
và điều kiện sẽ được thực hiện ít nhất một lần Trong kỹ thuật này người kiểm thử lấy dữ liệu xuất phát từ việc kiểm tra logic của chương trình (bỏ qua đặc tả)
Hộp trắng đúng nghĩa phải gọi là hộp trong suốt Chính vì vậy, kỹ thuật này còn có một số tên khác là kiểm thử hộp thuỷ tinh (Glass-Box Testing), hay kiểm thử hộp trong suốt (Clear-Box Testing) Người kiểm thử truy nhập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử (có nghĩa là người kiểm thử có thể nhìn thấy bên trong hộp) Dựa vào những
gì thấy được, người kiểm thử có thể xác định được các số liệu cụ thể và hướng việc kiểm thử theo những thông tin đó
Tương tự như vấn đề kiểm thử đầu vào trong kỹ thuật kiểm thử hộp đen, đó
là vấn đề kiểm thử các đường dẫn lệnh trong kỹ thuật hộp trắng Nếu phải thực hiện tất cả các đường dẫn của lưu trình điều khiển trong chương trình thông qua việc chạy tất cả các trường hợp kiểm thử thì có thể nói rằng chương trình đã được kiểm thử triệt để Tuy nhiên điều đó không thể thực hiện được vì số đường dẫn logic khác nhau trong một chương trình là cực kỳ lớn Ví dụ trong hình 3.2, sơ đồ khối của một chu trình điều khiển Sơ đồ biểu diễn một vòng lặp từ 1 đến 20 lần Trong thân của vòng lặp có một tập các lệnh điều kiện rẽ nhánh lồng nhau Số đường dẫn trong vòng lặp là 5 Như vậy, tổng số đường dẫn có thể là (5 + 52 + 53+ … + 520) khoảng xấp xỉ 1014 Giả sử một bộ xử lý có thể phát triển một trường hợp kiểm thử, thực thi và đánh giá các kết quả trong một mili giây (ms), thì sẽ
Trang 27phải làm việc khoảng 3170 năm để kiểm thử toàn diện tất cả các đường dẫn trong chương trình
Tất nhiên, trong thực tế, mọi quyết định của một chương trình là không độc lập với quyết định khác, có nghĩa là số đường dẫn thực hiện có thể bé hơn Tuy vậy, các chương trình trong thực tế có thể lớn hơn rất nhiều ví dụ vừa trình bày
Vì vậy, không thể kiểm thử được hết các đường dẫn
Ngoài những điều bất khả thi như trên, chương trình cũng có thể còn nhiều lỗi do các nguyên nhân khác Đây chính là nhược điểm của kỹ thuật kiểm thử hộp trắng
Việc kiểm thử bằng kỹ thuật hộp trắng không thể đảm bảo rằng chương trình đã tuân theo đặc tả Chẳng hạn như việc một lập trình viên được yêu cầu viết một thủ tục sắp xếp chữ Tiếng Việt theo thứ tự từ điển với
mã chuẩn Unicode, ký tự dựng sẵn (TCVN 6909:2001), nhưng do nhầm lẫn anh ta lại viết một thủ tục sắp xếp theo chuẩn TCVN3 (hoặc theo Unicode ký tự tổ hợp) Đây là một chương trình sai, không đúng theo đặc
Nguyên tắc của kỹ thuật kiểm thử hộp trắng là:
Thực hiện mọi đường dẫn độc lập ít nhất một lần
Trang 28 Thực hiện mọi điều kiện logic (if-then-else) trên các giá trị true và false của chúng
Thực hiện mọi vòng lặp (các vòng lặp for, while-do) tại các biên và trong phạm vi hoạt động của chúng
Thực hiện mọi cấu trúc dữ liệu bên trong để đảm bảo tính hợp lệ của chúng
Hình 3.2- Ví dụ chu trình điều khiển
3.2.1 Kiểm thử đường dẫn cơ sở (Basic Path Testing)
Kiểm thử đường dẫn cơ sở là một kỹ thuật kiểm thử hộp trắng do Tom McCabe đề xuất Phương pháp đường dẫn cơ sở cho phép người thiết kế trường hợp kiểm thử thực hiện phép đo độ phức tạp logic của thiết kế thủ tục và sử dụng phép đo này như một chỉ dẫn cho việc thiết kế một tập cơ sở các đường dẫn thực hiện Những trường hợp kiểm thử được suy diễn để thực hiện tập cơ sở Các trường hợp kiểm thử đó được đảm bảo để thực hiện mỗi lệnh trong chương trình
ít nhất một lần trong quá trình kiểm thử
Trong thực tế, phương pháp đường dẫn cơ sở có thể được dùng không cần
sử dụng đồ thị lưu trình Tuy nhiên, đồ thị lưu trình là một công cụ hữu ích để hiểu lưu trình điều khiển và minh hoạ phương pháp tiếp cận Phần này sẽ trình bày một số ký hiệu đơn giản của lưu trình điều khiển, được gọi là đồ thị lưu trình
lặp <20 lần
Trang 29sử dụng một số ký hiệu được minh hoạ như hình 3.3 Mỗi cấu trúc điều khiển có một ký hiệu đồ thị lưu trình tương ứng
Đồ thị lưu trình gồm có:
Mỗi hình tròn gọi là đỉnh, biểu diễn một hoặc nhiều lệnh thủ tục
Con trỏ được gọi là cung hoặc liên kết biểu diễn lưu trình điều khiển
Một cung cần phải kết thúc tại một đỉnh, cho dù đỉnh đó không biểu diễn cho một lệnh thủ tục nào
Mỗi đỉnh có chứa điều kiện gọi là đỉnh điều kiện
Phần được bao bởi các cung và các đỉnh gọi là vùng Phần bên ngoài đồ
thị cũng được coi như một vùng
Bất kỳ một thiết kế thủ tục nào đều có thể chuyển được sang đồ thị lưu trình Các biểu thức Bool tổ hợp trong các kiểm thử có thể tạo ra ít nhất hai đỉnh điều kiện và các cung bổ sung
Hình 3.3- Ký hiệu đồ thị lưu trình
Độ phức tạp cyclomat là một thước đo phần mềm, cung cấp phép đo định lượng độ phức tạp của chương trình Khi được sử dụng trong ngữ cảnh của phương pháp đường dẫn cơ sở, giá trị được xác định cho độ phức tạp cyclomat cho biết số lượng đường dẫn độc lập trong một tập cơ sở của chương trình và cung cấp cho chúng ta một giới hạn trên số lượng kiểm thử bắt buộc để đảm bảo
Tuần tự Rẽ nhánh Lựa chọn Lặp While Lặp Until
Trang 30Một đường dẫn độc lập là một đường dẫn bất kỳ trong chương trình đưa ra
ít nhất một tập lệnh xử lý hoặc điều kiện mới (tức là một cung mới) Phát biểu dưới dạng đồ thị lưu trình, một đường dẫn độc lập phải được di chuyển dọc theo
ít nhất một cung mà nó chưa đi qua trước khi đường dẫn được xác định
Một số nghiên cứu công nghiệp đã chỉ rằng độ phức tạp Cyclomat càng cao, xác suất hoặc lỗi càng cao
Hình 3.4 - Độ phức tạp Cyclomat
Việc tính toán độ phức tạp cyclomat sẽ cho chúng ta biết có bao nhiêu đường dẫn cần tìm
3.2.1.3 Phát sinh các trường hợp kiểm thử theo đường dẫn cơ sở
Phương pháp kiểm thử đường dẫn cơ sở có thể được áp dụng để thiết kế thủ tục chi tiết hoặc cho mã nguồn Kiểm thử đường dẫn cơ sở có thể được xem như một tập các bước
Bước 1: Sử dụng thiết kế hoặc mã nguồn như là căn cứ để vẽ đồ thị lưu
trình tương ứng
Bước 2: Xác định độ phức tạp Cyclomat của đồ thị lưu trình kết quả
Bước 3: Xác định tập cơ sở các đường dẫn độc lập tuyến tính
Bước 4: Chuẩn bị các trường hợp kiểm thử có khả năng thực hiện mỗi
đường dẫn trong tập cơ sở
Dữ liệu sẽ được chọn để các điều kiện tại các nút điều kiện được kiểm thử
modules
Các module trong vùng này dễ xảy ra nhiều lỗi
V(G)
Trang 31Một khi tất cả các kiểm thử đã được hoàn thành, người kiểm thử có thể chắc chắn rằng tất cả các câu lệnh trong chương trình đã được thực hiện ít nhất một lần
3.2.2 Kiểm thử cấu trúc điều khiển
Phương pháp kiểm thử đường dẫn cơ sở là phương pháp đơn giản và hiệu quả, nhưng nó vẫn chưa đủ Chúng ta sẽ xem xét các biến thể trên kiểm thử cấu trúc điều khiển mà phủ kiểm thử mở rộng và hoàn thiện chất lượng của kỹ thuật kiểm thử hộp trắng
3.2.2.1 Kiểm thử điều kiện
Kiểm thử điều kiện là phương pháp thiết kế trường hợp kiểm thử thực thi các điều kiện logic trong module chương trình
Một số định nghĩa:
Điều kiện đơn: là một biến logic hoặc một biểu thức quan hệ, có thể có toán tử NOT (!) đứng trước, ví dụ, NOT (a>b)
Biểu thức quan hệ: là một biểu thức có dạng E1 <op> E2, trong đó E1,
E2 là các biểu thức số học và <op> là toán tử quan hệ có thể là một trong
các dạng sau: <, <=, >, >=, = =, !=, ví dụ, a > b+1
Điều kiện phức: gồm hai hay nhiều điều kiện đơn, toán tử logic AND
(&&) hoặc OR (||) hoặc NOT (!) và các dấu ngoặc đơn ‘(‘ và ‘)’, ví dụ, (a
> b + 1) AND (a <= max)
Vì vậy, các thành phần trong một điều kiện có thể gồm phép toán logic, biến logic, cặp dấu ngoặc logic (bao một điều kiện đơn hoặc phức), phép toán quan hệ, hoặc biểu thức tóan học
Nếu một điều kiện là sai, thì ít nhất một phần tử của điều kiện sai Vì vậy, các lỗi điều kiện có thể xảy ra bởi:
Trang 32+ Lỗi toán tử logic (sai, thừa hoặc thiếu toán tử logic, ví dụ:AND thay vì OR)
+ Lỗi toán tử quan hệ (ví dụ: >= thay vì >)
+ Lỗi biến logic (sử dụng biến sai)
+ Lỗi dấu ngoặc đơn (thừa hoặc thiếu cặp dấu ngoặc đơn hoặc đặt sai dấu ngoặc đơn)
+ Lỗi biểu thức số học (ví dụ: j+k thay vì j-k)
Phương pháp kiểm thử điều kiện tập trung vào kiểm thử mỗi một điều kiện trong chương trình Các chiến lược kiểm thử điều kiện có hai ưu điểm chung Thứ nhất, việc đo mức độ phủ điều kiện của kiểm thử là đơn giản Thứ hai, mức
độ phủ các điều kiện của kiểm thử trong chương trình cung cấp các hướng dẫn để phát sinh các kiểm thử bổ sung cho chương trình
Mục đích của kiểm thử điều kiện là để xác định không chỉ các lỗi điều kiện
mà cả các lỗi khác trong chương trình Nếu một tập kiểm thử cho một chương
trình P là hiệu quả để phát hiện lỗi trong các điều kiện của P thì có khả năng nó cũng là tập kiểm thử hiệu quả để tìm những lỗi khác trong P
Có một số phương pháp kiểm thử điều kiện được đề xuất:
Kiểm thử nhánh (Branch Testing): là phương pháp kiểm thử điều kiện
đơn giản nhất Đối với điều kiện phức C, các nhánh đúng và sai của C và
mọi điều kiện đơn trong C cần được thực hiện ít nhất một lần
Kiểm thử miền (Domain Testing): cần 3 hoặc 4 kiểm thử cho biểu thức
quan hệ Với một biểu thức quan hệ có dạng E1 <op> E2, cần có 3 kiểm thử được thiết kế cho E1= = E2, E1 > E2, E1 < E2 Ví dụ, điều kiện (x >
5), cần 3 trường hợp kiểm thử x=5, x = 3 < 5, và x = 8 >5
Với một biểu thức logic có n biến logic, có tất cả 2n kiểm thử có thể được yêu cầu Phương pháp này có thể tìm các lỗi toán tử, biến logic và dấu ngoặc đơn
Trang 33nhưng nó chỉ có thể thực hiện nếu n nhỏ Ví dụ: C = ( B1 && B2) || (B3 && B4), cần 16 trường hợp kiểm thử cho tất cả các tổ hợp của B1, B2, B3, B4
Kiểm thử nhánh và toán tử quan hệ (Branch and Relational Operator –
BRO): Kiểm thử miền với 2n kiểm thử là không khả thi nếu số biến logic
n là lớn Kỹ thuật BRO giảm bớt số trường hợp kiểm thử Kỹ thuật BRO này sử dụng các ràng buộc điều kiện cho một điều kiện C Một ràng buộc điều kiện cho C với n điều kiện đơn được định nghĩa là (D1, D2, …, Dn) trong đó Di (0 < i ≤ n) là một ký hiệu xác định ràng buộc hệ quả của điều kiện đơn thứ i trong điều kiện C Một ràng buộc D cho điều kiện C gọi là được phủ bằng việc thực hiện điều kiện C nếu trong quá trình thực hiện của C, hệ quả của mỗi điều kiện đơn trong C thoả mãn ràng buộc tương ứng trong D
Cho một biến logic B, chúng ta đưa ra một ràng buộc theo hệ quả của B B phải là đúng (true) hoặc sai (false) Tương tự, với một biểu thức quan hệ, các ký hiệu >, =, < được sử dụng để chỉ ra những ràng buộc theo hệ quả của biểu thức
Ví dụ : Cho điều kiện C1 = B1 AND B2, trong đó B1, B2 là các biến logic
+ Điều kiện ràng buộc dạng (D1, D2), với D1 và D2 có thể là true hoặc false Giá trị (true, false) là một ràng buộc điều kiện cho C1 và được phủ thông qua việc kiểm thử với cặp giá trị của B1 là true và giá trị của B2 là false
+ Tập ràng buộc được yêu cầu phủ bằng việc thực hiện C1 là { (true, true), (true, false), (false, true) } (false, false) là không cần thiết, bởi vì nếu B1, B2 và/hoặc toán tử AND sai, một trong 3 kiểm thử trong tập ràng buộc trên
sẽ sai Tóm lại, ta sẽ phải thiết kế 3 trường hợp kiểm thử tương ứng với 3 thành viên trong tập ràng buộc
3.2.2.2 Kiểm thử luồng dữ liệu
Phương pháp kiểm thử luồng dữ liệu lựa chọn các đường dẫn kiểm thử của
chương trình dựa vào vị trí khai báo và sử dụng các biến trong chương trình Với
Trang 34kiểm thử luồng dữ liệu mỗi câu lệnh trong chương trình được gán số hiệu lệnh duy nhất và mỗi hàm không thay đổi tham số của nó và biến toàn cục Cho một lệnh với S là số hiệu câu lệnh Ta định nghĩa,
DEF(S) = là tập các biến được khai báo trong S
USE(S) = là tập các biến được sử dụng trong S
Ví dụ: Cho câu lệnh S như sau:
Nếu câu lệnh S là lệnh điều kiện if hoặc vòng lặp thì tập DEF của nó là rỗng
và tập USE của nó được tìm thấy trên điều kiện của lệnh S Việc khai báo biến X trong lệnh S được gọi là trú trong lệnh S’ nếu tồn tại đường dẫn từ câu lệnh S đến lệnh S’ mà không chứa một khai báo khác của X
Một chuỗi khai báo - sử dụng (DU) của biến X là có dạng [X, S, S’] trong
đó S, S’ là các số hiệu lệnh, X có trong tập DEF(S)và tập USE(S’), và khai báo của X trong câu lệnh S trú trong lệnh S’
Một chiến lược kiểm thử luồng dữ liệu cơ bản là chiến lược mà mỗi chuỗi
DU được phủ ít nhất một lần Chiến lược này được gọi là chiến lược kiểm thử
DU Kiểm thử DU không đảm bảo phủ hết tất cả các nhánh của một chương trình Tuy nhiên, một nhánh không đảm bảo được phủ bởi kiểm thử DU chỉ trong
rất ít tình huống như cấu trúc if-then-else mà trong đó phần then không có một khai báo biến nào và có dạng khuyết (không tồn tại phần else) Trong tình huống
đó, nhánh else của lệnh if là không cần thiết phải phủ bằng kiểm thử DU
Trang 35Chiến lược kiểm thử luồng dữ liệu là rất hữu ích cho việc lựa chọn các đường dẫn kiểm thử của chương trình có chứa các lệnh if hoặc vòng lặp lồng nhau Để minh họa điều này, chúng ta xem xét ứng dụng của kiểm thử DU để chọn các đường dẫn kiểm thử cho PDL dưới đây, trong đó x là tên thủ tục (khối), B1 B5 là các khối chương trình, C1 C3 là các biểu thức điều kiện
Proc x
B1;
do while C1
if C2 then
if C4
then B4;
else B5;
endif else
Để áp dụng chiến lược kiểm thử DU lựa chọn các đường dẫn kiểm thử của
sơ đồ lưu trình điều khiển, chúng ta cần biết các khai báo và sử dụng các biến trong mỗi điều kiện hoặc mỗi khối trong PDL Giả thiết rằng biến X được khai báo trong câu lệnh cuối cùng của các khối B1, B2, B3, B4, và B5 và được sử dụng trong câu lệnh đầu tiên của các khối B2, B3, B4, B5 và B6 Chiến lược
kiểm thử DU yêu cầu thực hiện đường dẫn ngắn nhất từ mỗi khối B i , 0 < i ≤ 5,
đến mỗi B j , 1 < j ≤ 6 (Kiểm thử như vậy cũng sẽ phủ việc sử dụng biến X bất kỳ
trong các điều kiện C1, C2, C3 và C4) Mặc dù có 25 chuỗi DU của biến X, chúng ta chỉ cần 5 đường dẫn để phủ các chuỗi DU này Lý do là 5 đường dẫn
cần để phủ chuỗi DU của X từ B i , 0 < i ≤ 5, đến B6, và các chuỗi DU khác có thể
được phủ bằng bằng cách tạo 5 đường dẫn chứa các vòng lặp
Vì các lệnh trong chương trình là liên quan với mỗi lệnh khác theo các khai báo và sử dụng biến, phương pháp kiểm thử luồng dữ liệu là hiệu quả cho việc
