WIXLIB

MỤC LỤCix7.2.1Ý tưởng về kiểm thử dựa trên lát cắt . . . . . . . . . . 1797.2.2Ví dụ áp dụng . . . . . . . . . . . . . . . . . . . . . . . 1827.2.3Một số lưu ý với kiểm thử dựa trên lát cắt . . . . . . . 1887.3Tổng kết . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917.4Bài tập . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1928 Kiểm thử dựa trên mô hình1978.1Khái niệm về kiểm thử dựa trên mô hình . . . . . . . . . . . . 1978.2Các phương pháp đặc tả mô hình . . . . . . . . . . . . . . . . 1988.2.1Máy hữu hạn trạng thái . . . . . . . . . . . . . . . . . 1988.2.2Ôtômat đơn định hữu hạn trạng thái . . . . . . . . . . 2008.2.3Biểu đồ trạng thái . . . . . . . . . . . . . . . . . . . . 2018.2.4Máy trạng thái UML . . . . . . . . . . . . . . . . . . . 2018.2.5Các phương pháp đặc tả khác . . . . . . . . . . . . . . 2038.3Sinh các ca kiểm thử từ mô hình . . . . . . . . . . . . . . . . 2038.4Sinh đầu ra mong muốn cho các ca kiểm thử . . . . . . . . . . 2058.5Thực hiện các ca kiểm thử . . . . . . . . . . . . . . . . . . . . 2058.6Ví dụ minh họa . . . . . . . . . . . . . . . . . . . . . . . . . . 2068.6.1Đặc tả hệ thống . . . . . . . . . . . . . . . . . . . . . . 2068.6.2Sinh các ca kiểm thử . . . . . . . . . . . . . . . . . . . 2088.6.3Thực hiện các ca kiểm thử . . . . . . . . . . . . . . . . 2098.7Thuận lợi và khó khăn của kiểm thử dựa trên mô hình . . . . 2108.8Một số công cụ kiểm thử dựa trên mô hình . . . . . . . . . . . 2128.8.1AGEDIS . . . . . . . . . . . . . . . . . . . . . . . . . . 2128.8.2Spec Explorer . . . . . . . . . . . . . . . . . . . . . . . 2138.8.3Conformiq Qtronic . . . . . . . . . . . . . . . . . . . . 2148.8.4JCrasher . . . . . . . . . . . . . . . . . . . . . . . . . . 214

xMỤC LỤC8.98.8.5Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . 2158.8.6SoapUI . . . . . . . . . . . . . . . . . . . . . . . . . . . 2158.8.7W3af . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Tổng kết . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2168.10 Bài tập . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2179 Kiểm thử tự động và công cụ hỗ trợ2199.1Tổng quan về kiểm thử tự động . . . . . . . . . . . . . . . . . 2199.2Kiến trúc của một bộ công cụ kiểm thử tự động . . . . . . . . 2219.3Một số công cụ kiểm thử tự động . . . . . . . . . . . . . . . . 2239.3.1CFT4CUnit . . . . . . . . . . . . . . . . . . . . . . . . 2239.3.2JDFT . . . . . . . . . . . . . . . . . . . . . . . . . . . 2249.3.3JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . 2269.3.4QuickTest Professional . . . . . . . . . . . . . . . . . . 2279.3.5Apache JMeter . . . . . . . . . . . . . . . . . . . . . . 2289.3.6Load Runner . . . . . . . . . . . . . . . . . . . . . . . 2289.4Tổng kết . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2289.5Bài tập . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22910 Kiểm thử tích hợp23110.1 Giới thiệu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23110.2 Các loại giao diện và lỗi giao diện . . . . . . . . . . . . . . . . 23210.3 Tích hợp dựa trên cấu trúc mô-đun . . . . . . . . . . . . . . . 23410.3.1 Tích hợp từ trên xuống . . . . . . . . . . . . . . . . . . 23510.3.2 Tích hợp từ dưới lên . . . . . . . . . . . . . . . . . . . 23610.3.3 Tích hợp bánh kẹp . . . . . . . . . . . . . . . . . . . . 23710.4 Tích hợp dựa trên đồ thị gọi hàm . . . . . . . . . . . . . . . . 23810.4.1 Tích hợp đôi một . . . . . . . . . . . . . . . . . . . . . 238

MỤC LỤCxi10.4.2 Tích hợp láng giềng . . . . . . . . . . . . . . . . . . . . 23910.5 Bài tập . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23911 Kiểm thử hệ thống, chấp nhận và hồi quy24111.1 Tổng quan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24111.2 Kiểm thử hệ thống . . . . . . . . . . . . . . . . . . . . . . . . 24311.2.1 Kiểm thử tính dễ dùng . . . . . . . . . . . . . . . . . . 24611.2.2 Kiểm thử giao diện người dùng . . . . . . . . . . . . . 25011.2.3 Kiểm thử hiệu năng. . . . . . . . . . . . . . . . . . . 25011.2.3.1 Khái niệm . . . . . . . . . . . . . . . . . . . . 25011.2.3.2 Kiểm thử hiệu năng liên quan . . . . . . . . . 25111.3 Kiểm thử chấp nhận . . . . . . . . . . . . . . . . . . . . . . . 25311.4 Kiểm thử hồi quy . . . . . . . . . . . . . . . . . . . . . . . . . 25511.4.1 Tổng quan . . . . . . . . . . . . . . . . . . . . . . . . . 25511.4.2 Kỹ thuật kiểm thử hồi quy . . . . . . . . . . . . . . . . 25611.5 Bài tập . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

xiiMỤC LỤC

Lời nói đầuChúng ta đã và đang chứng kiến sự tăng trưởng đáng kinh ngạc của ngànhcông nghiệp phần mềm trong vài thập kỷ qua. Nếu như trước đây phần mềmmáy tính chỉ được sử dụng để tính toán khoa học kỹ thuật và xử lý dữ liệuthì ngày nay nó đã được ứng dụng vào mọi mặt của của đời sống hàng ngàycủa con người, từ các ứng dụng nhỏ để điều khiển các thiết bị dùng tronggia đình như các thiết bị nghe nhìn, điện thoại, máy giặt, lò vi sóng, nồi cơmđiện, đến các ứng dụng lớn hơn như trợ giúp điều khiển các phương tiện vàhệ thống giao thông, trả tiền cho các hoá đơn, quản lý và thanh toán về tàichính, vân vân. Vì thế con người ngày càng phụ thuộc chặt chẽ vào các sảnphẩm phần mềm và do vậy đòi hỏi về chất lượng của các sản phẩm phầnmềm ngày càng cao, tức là các phần mềm phải được sản xuất với giá thànhhạ, dễ dùng, an toàn và tin cậy được. Kiểm thử có phương pháp là một hoạtđộng không thể thiếu trong quy trình sản xuất phần mềm để đảm bảo cácyếu tố chất lượng nêu trên của các sản phẩm phần mềm.Theo thống kê thì việc kiểm thử tiêu tốn khoảng 50% thời gian và hơn50% giá thành của các dự án phát triển phần mềm. Tăng năng suất kiểm thửlà một nhu cầu thiết yếu để tăng chất lượng phần mềm. Vì thế nghiên cứuđể phát triển các kỹ thuật, công cụ kiểm thử hữu hiệu và đào tạo đội ngũkiểm thử có kỹ năng và kinh nghiệm là các đóng góp thiết thực nhất để tăngcường chất lượng của các sản phẩm phần mềm. Từ yêu cầu thực tế này, ngàynay rất nhiều trường đại học trong nước và quốc tế đã đưa môn “Kiểm thửvà đảm bảo chất lượng Phần mềm” thành một môn giáo dục chuyên ngànhcủa công nghệ phần mềm ở cả bậc đại học và cao học. Chúng tôi thấy rằngcác học viên cao học và sinh viên cần được đào tạo bài bản về cơ sở của kiểmthử phần mềm, bao gồm cả các kiến thức hàn lâm cơ bản lẫn các kỹ thuậtthực hành trong ngành công nghiệp phần mềm để có thể đáp ứng công việccủa cả nghiên cứu viên lẫn kiểm thử viên. Chúng tôi viết cuốn giáo trình nàyxiii

xivMỤC LỤCkhông ngoài mục đích nhằm đáp ứng yêu cầu thiết yếu đó. Cuốn giáo trìnhnày sẽ cung cấp cho sinh viên, học viên cao học và giảng viên những chấtliệu cơ bản bao phủ những nét chính về những phát triển lý thuyết cơ sở củaviệc kiểm thử phần mềm và các thực hành kiểm thử chung trong ngành côngnghiệp phần mềm. Vì các khái niệm về chất lượng phần mềm là quá rộng,chúng tôi chỉ định giới thiệu những nét chung nhất và cái nhìn tồng thể vềkiểm thử và đảm bảo chất lượng phần mềm mà thôi. Thực ra thì phần mềmcó rất nhiều loại khác nhau, với nhiều miền ứng dụng khác nhau. Ở mỗi loạivà mỗi miền ứng dụng riêng biệt lại có các đặc thù riêng và cần được bổ trợbởi các kỹ thuật kiểm thử riêng cho chúng. Chúng tôi không có tham vọngđi vào các chi tiết như vậy mà chỉ giới thiệu lý thuyết và thực hành kiểm thửchung và cơ bản nhất nhằm trang bị cho sinh viên những kỹ năng cơ bảnđể có thể hiểu và tự phát triển các kỹ thuật kiểm thử thích hợp cho các hệthống phức tạp và chuyên dụng hơn trong thực tiễn sau này.Giáo trình này được viết dựa vào kinh nghiệm giảng dạy môn kiểm thửvà đảm bảo chất lượng phần mềm của chúng tôi trong vài năm năm qua tạiKhoa Công nghệ Thông tin, Trường Đại học Công nghệ, Đại học Quốc giaHà Nội và hàng chục năm kinh nghiệm của chúng tôi trong thực tế phát triểnphần mềm. Để viết giáo trình này, chúng tôi đã tham khảo nhiều cuốn sáchđược dùng phổ biến trên thế giới về kiểm thử và đảm bảo chất lượng phầnmềm. Chúng tôi cũng sử dụng thêm các tài liệu nghiên cứu gần đây để cậpnhật các phương pháp và kết quả nghiên cứu hiện nay về lĩnh vực này nhưđược nêu trong phần tài liệu tham khảo ở cuối cuốn tài liệu này.Các chủ đề chính được trình bày trong cuốn tài liệu này bao gồm: Cơ sở toán học cho kiểm thử phần mềm Các khái niệm cơ bản về kiểm thử phần mềm Các phương pháp phân tích và khảo sát đặc tả và mã nguồn Các phương pháp kiểm thử hàm (hay còn gọi là kiểm thử chức năng) Các phương pháp kiểm thử hộp trắng hay kiểm thử cấu trúc Các phương pháp và quy trình 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 và kiểm thử hồi quy Các phương pháp kiểm thử dựa trên mô hình, kiểm thử tự động và cáccông cụ hỗ trợ

MỤC LỤCxvĐể hoàn thành cuốn giáo trình này, chúng tôi đã nhận được sự giúp đỡtận tình, ý kiến đóng góp quí báu và sự và động viên chân thành từ các đồngnghiệp, các nghiên cứu sinh, học viên cao học và sinh viên Khoa Công nghệThông tin của Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội. Nhiềuđồng nghiệp và sinh viên đã dành thời gian đọc cẩn thận, “kiểm thử” đếntừng chi tiết nhằm giúp chúng tôi nâng cao chất lượng của cuốn giáo trìnhnày, đặc biệt là PGS. TS. Nguyễn Việt Hà, PGS. TS. Trương Ninh Thuận,TS. Trần Thị Minh Châu (Trường Đại học Công nghệ) và PGS. TS. ĐặngVăn Đức (Viện Công nghệ Thông tin, Viện hàm lâm Khoa học Việt Nam).Chúng tôi xin chân thành cảm ơn các đồng nghiệp, các bạn nghiên cứu sinh,học viên cao học và sinh viên vì những đóng góp to lớn đó.Mặc dù chúng tôi đã rất nỗ lực nhưng vì thời gian và trình độ còn hạnchế, cuốn tài liệu này không tránh khỏi các thiếu sót. Chúng tôi rất mongcuốn giáo trình sẽ được bạn đọc đón nhận, thông cảm và góp ý. Chúng tôixin trân trọng cám ơn.Hà Nội, Tháng 11 năm 2013Các tác giả.

xviMỤC LỤC

Chương 1Tổng quan về kiểm thửKiểm thử nhằm đánh giá chất lượng hoặc tính chấp nhận được của sản phẩm.Kiểm thử cũng nhằm phát hiện lỗi hoặc bất cứ vấn đề gì về sản phẩm. Chúngta cần kiểm thử vì biết rằng con người luôn có thể mắc sai lầm. Điều này đặcbiệt đúng trong lĩnh vực phát triển phần mềm và các hệ thống điều khiểnbởi phần mềm. Chương này nhằm phác họa một bức tranh tổng thể về kiểmthử phần mềm. Các chương còn lại sẽ nằm trong khuôn khổ của bức tranhnày và ở mức chi tiết hơn.1.1Các thuật ngữ và định nghĩa cơ bản vềkiểm thửKỹ nghệ kiểm thử đã phát triển và tiến hoá hàng mấy chục năm nên cácthuật ngữ trong các tài liệu khác nhau thường không thống nhất và thiếutương thích. Các thuật ngữ được trình bày trong cuốn sách này dựa vào cácthuật ngữ chuẩn được phát triển bởi IEEE (Viện Kỹ nghệ điện và điện tử)với việc chọn lọc cẩn thận các thuật ngữ tiếng Việt tương ứng.Lỗi (Error): Lỗi là những vấn đề mà con người mắc phải trong quá trìnhphát triển các sản phẩm phần mềm. Trong thực tế, con người luôn có thểphạm lỗi. Khi lập trình viên phạm lỗi trong lập trình, ta gọi các lỗi đó làbug (con bọ). Lỗi có thể phát tán. Chẳng hạn, một lỗi về xác định yêu cầu1

2CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬcó thể dẫn đến sai lầm về thiết kế và càng sai khi lập trình theo thiết kế này.Lỗi là nguyên nhân dẫn đến sai.Sai (Fault): Sai là kết quả của lỗi, hay nói khác đi, lỗi sẽ dẫn đến sai.Cũng có thể nói sai là một biểu diễn của lỗi dưới dạng một biểu thức, chẳnghạn chương trình, văn bản, sơ đồ dòng dữ liệu, biểu đồ lớp,. Sai lầm có thểkhó bị phát hiện. Khi nhà thiết kế mắc lỗi bỏ sót trong quá trình thiết kế,sai kết quả từ lỗi đó là thiếu mất cái gì đó mà lẽ ra cần phải có. Sai về nhiệmvụ xuất hiện khi vào sai thông tin, còn sai về bỏ quên xuất hiện khi khôngvào đủ thông tin. Loại sai thứ hai khó phát hiện và khó sửa hơn loại sai thứnhất.Thất bại (Failure): Thất bại xuất hiện khi một lỗi được thực thi. Cóhai điều cần lưu ý ở đây. Một là thất bại chỉ xuất hiện dưới dạng có thểchạy được mà thông thường là mã nguồn. Hai là các thất bại chỉ liên kếtvới các lỗi về nhiệm vụ. Còn các thất bại tương ứng với các lỗi về bỏ quênthì xử lý thế nào? Những cái lỗi không bao giờ được tiến hành, hoặc khôngđược tiến hành trong khoảng thời gian dài cần được xử lý thế nào? VirusMichaelangelo là một ví dụ về lỗi loại này. Nó chỉ được tiến hành vào ngàysinh của Michaelangelo, tức ngày 6/3 mà thôi. Việc khảo sát có thể ngănchặn nhiều thất bại bằng cách tìm ra các lỗi thuộc cả hai loại.Sự cố (Incident): Khi thất bại xuất hiện, nó có thể hiển thị hoặc không,tức là rõ ràng hoặc không rõ ràng đối với người dùng hoặc người kiểm thử.Sự cố là triệu chứng liên kết với một thất bại và thể hiện cho người dùnghoặc người kiểm thử về sự xuất hiện của thất bại này.Yêu cầu của khách hàng và đặc tả của phần mềm: Phần mềm đượcviết để thực hiện các nhu cầu của khách hàng. Các nhu cầu của khách hàngđược thu thập, phân tích và khảo cứu và là cơ sở để quyết định chính xáccác đặc trưng cần thiết mà sản phẩm phần mềm cần phải có. Dựa trên yêucầu của khách hàng và các yêu cầu bắt buộc khác, đặc tả được xây dựng đểmô tả chính xác các yêu cầu mà sản phẩm phần mềm cần đáp ứng, và cógiao diện thế nào. Tài liệu đặc tả là cơ sở để đội ngũ phát triển phần mềmxây dựng sản phẩm phần mềm. Khi nói đến thất bại trên đây là nói đến việcsản phẩm phần mềm không hoạt động đúng như đặc tả. Lỗi một khi được

1.1. CÁC THUẬT NGỮ VÀ ĐỊNH NGHĨA CƠ BẢN VỀ KIỂM THỬ3tiến hành có thể dẫn đến thất bại. Do đó, lỗi về bỏ quên được coi là tươngứng với các lỗi khi xây dựng đặc tả.Kiểm chứng và thẩm định: Kiểm chứng (verification) và thẩm định(validation) hay được dùng lẫn lộn, nhưng thực ra chúng có ý nghĩa khácnhau. Kiểm chứng là quá trình để đảm bảo rằng một sản phẩm phần mềmthỏa mãn đặc tả của nó. Còn thẩm định là quá trình để đảm bảo rằngsản phẩm đáp ứng được yêu cầu của người dùng (khách hàng). Trong thựctế, chúng ta cần thực hiện kiểm chứng trước khi thực hiện việc thẩm địnhsản phẩm phần mềm. Vì vậy, chúng ta có thuật ngữ V&V (Verification &Validation). Lý do của việc này là chúng ta cần đảm bảo sản phẩm đúng vớiđặc tả trước. Nếu thực hiện việc thẩm định trước, một khi phát hiện ra lỗi,chúng ta không thể xác định được lỗi này do đặc tả sai hay do lập trình saiso với đặc tả.Chất lượng và độ tin cậy của phần mềm: Theo từ điển, chất lượngcủa một sản phẩm được thể hiện bằng các đặc trưng phù hợp với đặc tả củanó. Theo cách hiểu này, chất lượng của một sản phẩm phần mềm là sự đápứng các yêu cầu về chức năng (tức là các hàm cần được tính toán), sự hoànthiện và các chuẩn đã được đặc tả, cùng các đặc trưng mong chờ từ mọi sảnphẩm phần mềm chuyên nghiệp. Chất lượng phần mềm đặc trưng cho “độtốt, độ tuyệt hảo” của phần mềm, và gồm có các yếu tố về chất lượng như:tính đúng đắn (hành vi đúng như đặc tả), tính hiệu quả (tiết kiệm thời gianvà tiền bạc), độ tin cậy, tính khả kiểm thử (kiểm thử được và dễ), dễ học, dễsử dụng, dễ bảo trì . Như vậy, độ tin cậy chỉ là một yếu tố để đánh giá chấtlượng phầm mềm. Người kiểm thử hay nhầm lẫn độ tin cậy với chất lượng.Khi kiểm thử đạt tới mức phần mềm chạy ổn định, có thể phụ thuộc vào nó,người kiểm thử thường cho rằng phần mềm đã đạt chất lượng cao. Các yếutố về mặt chất lượng mà liên quan trực tiếp đến việc phát triển phần mềmđược gọi là các tiêu chuẩn chất lượng như tính có cấu trúc, tính đơn thể,tính khả kiểm thử, .Độ tin cậy của phần mềm là xác suất để phần mềm chạy không có thấtbại trong một khoảng thời gian nhất định. Nó được xem là một yếu tố quantrọng của chất lượng phần mềm. Ngoài ra, thời gian trung bình cho việc khắcphục một sự cố cũng là một thông số quan trọng trong việc đánh giá độ tincậy của sản phẩm phần mềm.

4CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬKiểm thử: Rõ ràng việc kiểm thử liên quan đến các khái niệm trên: lỗi,sai, thất bại và sự cố. Có hai mục đích chính của một phép thử: tìm thất bạihoặc chứng tỏ việc tiến hành của phần mềm là đúng đắn.Vai trò của kiểm thử phần mềm: Kiểm thử phần mềm đóng vai tròquan trọng trong việc đánh giá và thu được chất lượng cao của sản phẩmphần mềm trong quá trình phát triển. Thông qua chu trình “kiểm thử - tìmlỗi - sửa lỗi”, ta hy vọng chất lượng của sản phẩm phần mềm sẽ được cảitiến. Mặt khác, thông qua việc tiến hành kiểm thử mức hệ thống trước khicho lưu hành sản phẩm, ta biết được sản phẩm của ta tốt ở mức nào. Vìthế, nhiều tác giả đã mô tả việc kiểm thử phần mềm là một quy trình kiểmchứng để đánh giá và tăng cường chất lượng của sản phẩm phần mềm. Quytrình này gồm hai công việc chính là phân tích tĩnh và phân tích động. Phân tích tĩnh: Việc phân tích tĩnh được tiến hành dựa trên việc khảosát các tài liệu được xây dựng trong quá trình phát triển sản phẩm nhưtài liệu đặc tả nhu cầu người dùng, mô hình phần mềm, hồ sơ thiếtkế và mã nguồn phần mềm. Các phương pháp phân tích tĩnh truyềnthống bao gồm việc khảo sát đặc tả và mã nguồn cùng các tài liệu thiếtkế. Các kỹ thuật khảo sát này sẽ được giới thiệu trong chương 4. Ngườita cũng có thể dùng các kỹ thuật phân tích hình thức như kiểm chứngmô hình (model checking) và chứng minh định lý (theorem proving)để chứng minh tính đúng đắn của thiết kế và mã nguồn. Các kỹ thuậtnày tương đối phức tạp và nằm ngoài khuôn khổ của cuốn giáo trìnhnày. Công việc này không động đến việc thực thi chương trình mà chỉduyệt, lý giải về tất cả các hành vi có thể của chương trình khi đượcthực thi. Tối ưu hóa các chương trình dịch là các ví dụ về phân tíchtĩnh. Phân tích động: Phân tích động liên quan đến việc thực thi chươngtrình để phát hiện những thất bại có thể có của chương trình, hoặcquan sát các tính chất nào đó về hành vi và hiệu quả (performance).Vì gần như không thể thực thi chương trình trên tất cả các dữ liệu đầuvào có thể, ta chỉ có thể chọn một tập con các dữ liệu đầu vào để thựcthi, gọi là các “ca kiểm thử”. Chọn như thế nào để được các bộ dữ liệuđầu vào hiệu quả (tức là các bộ dữ liệu có xác suất phát hiện thất bại(nếu có) cao hơn là công việc cần suy nghĩ và là nội dung chính củacác giáo trình này.

1.1. CÁC THUẬT NGỮ VÀ ĐỊNH NGHĨA CƠ BẢN VỀ KIỂM THỬ5Bằng việc phân tích tĩnh và động, người kiểm thử muốn phát hiện nhiềulỗi nhất có thể được để chúng có thể được sửa ở giai đoạn sớm nhất trongquá trình phát triển phần mềm. Phân tích tĩnh và động là hai kỹ thuật bổsung cho nhau và cần được làm lặp đi lặp lại nhiều trong quá trình kiểm thử.Ca kiểm thử: Mỗi ca kiểm thử có một tên và được liên kết với một hànhvi của chương trình. Ca kiểm thử gồm một tập các dữ liệu đầu vào và mộtxâu các giá trị đầu ra mong đợi đối với phần mềm.Hình 1.1: Một vòng đời của việc kiểm thử.Hình 1.1 mô tả vòng đời của việc kiểm thử ứng với mô hình thác nước.Lưu ý rằng trong giai đoạn phát triển phần mềm, lỗi có thể được đưa vàotại các gia đoạn đặc tả yêu cầu, thiết kế và lập trình. Các lỗi này có thể tạora những sai lan truyền sang các phần còn lại của quá trình phát triển. Mộtnhà kiểm thử lỗi lạc đã tóm tắt vòng đời này như sau: Ba giai đoạn đầu là“đưa lỗi vào”, giai đoạn kiểm thử là để tìm lỗi, và ba giai đoạn cuối là “khữlỗi đi” [Pos90]. Bước sửa sai là cơ hội mới cho việc đưa vào lỗi (và các saimới). Vì vậy, việc sửa sai này có thể làm cho phần mềm từ đúng trở thànhsai. Trong trường hợp này, việc sửa sai là không đầy đủ. Kiểm thử hồi quy(sẽ được giới thiệu trong chương 11) là giải pháp tốt để giải quyết vấn đềnày.

6CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬCác thuật ngữ trên đây cho thấy các ca kiểm thử chiếm vị trí trung tâmtrong việc kiểm thử dựa trên phân tích động. Quá trình kiểm thử dựa trênphân tích động được chia thành các buớc sau: lập kế hoạch kiểm thử, pháttriển ca kiểm thử, chạy các ca kiểm thử và đánh giá kết quả kiểm thử. Tiêuđiểm của cuốn giáo trình này là việc xác định tập hữu ích các ca kiểm thử,tức là các ca kiểm thứ giúp ta cải tiến tốt hơn chất lượng của sản phẩm.1.2Ca kiểm thửCốt lõi của kiểm thử phần mềm dựa trên phân tích động là việc xác địnhtập các ca kiểm thử sao cho chúng có khả năng phát hiện nhiều nhất các lỗi(có thể có) của hệ thống cần kiểm thử. Vậy cái gì cần đưa vào các ca kiểmthử? Rõ ràng thông tin đầu tiên là đầu vào. Đầu vào có hai kiểu: tiền điềukiện (pre-condition) - tức là điều kiện cần thỏa mãn trước khi tiến hành cakiểm thử - và dữ liệu đầu vào thực sự được xác định bởi phương pháp kiểmthử. Thông tin tiếp theo cần đưa vào là đầu ra mong đợi. Cũng có hai loạiđầu ra: hậu điều kiện (post-condition) và dữ liệu đầu ra thực sự. Phần đầura của ca kiểm thử thường hay bị bỏ quên vì nó là phần khó xác định. Giả sửta cần kiểm thử phần mềm tìm đường đi tối ưu cho máy bay khi cho trướccác ràng buộc về hành lang bay và dữ liệu về thời tiết trong ngày của chuyếnbay. Đường đi tối ưu của máy bay thực sự là gì? Có nhiều câu trả lời chocâ

GIÁO TRÌNH KIỂM THỬ PHẦN MỀM Phạm Ngọc Hùng, Trương Anh Hoàng và Đặng Văn Hưng Tháng 1 năm 2014