De Tai

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

i

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

-----------------

Đề tài:

CÁC PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM Tiểu luận sau đại học

Thầy hướng dẫn: TS. Nguyễn Văn Vỵ Người thực hiện: Nghiêm Văn Triệu

Hà nội, 12/ 2006

CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1. Kiểm thử phần mềm

Kiểm thử phần mềm là quá trình phân tích một hạng mục phần mềm để phát hiện sự khác nhau giữa các điều kiện tồn tại và điều kiện yêu cầu để đánh giá các đặc trưng của các hạng mục phần mềm (IEEE, 1986; IEEE, 1990). Kiểm thử phần mềm là một hoạt động được thực hiện xuyên suốt toàn bộ quá trình phát triển phần mềm Kiểm thử phần mềm là một trong số các hoạt động kiểm tra và thẩm định phần mềm - verification and validation software practices. Kiểm tra là quá trình đánh giá hệ thống hay thành phần để xác định kết quả của một pha phát triển có thỏa mãn điều kiện đưa ra tại bước khởi đầu pha. Hoạt động kiểm tra bao gồm kiểm thử và kiểm duyệt. Thẩm định là quá trình đánh giá hệ thống hay thành phần trong suốt hay ở giai đoạn cuối của quá trình phát triển để xác định việc thỏa mãn các yêu cầu xác định. Trong bước cuối của sự phát triển hoạt động thẩm định được sử dụng để đánh giá các đặc trưng đã được xây dựng có thỏa mãn các yêu cầu khách hàng và có thể mô tả rõ được các yêu cầu của khách hàng. Boehm đã xác định hoạt động kiểm tra và thẩm định như sau: Kiểm tra: thông qua việc kiểm tra, chúng ta đảm bảo sản phẩm hoạt động đúng như cách mà chúng ta mong đợi Thẩm định: thông qua việc thẩm định, chúng ta kiểm tra để đảm bảo rằng ở đâu đó trong quá trình, việc thẩm định một lỗi luôn liên quan tới việc đối chiếu lại với yêu cầu 2. Lịch sử kiểm thử phần mềm

Việc tách gỡ rỗi từ kiểm thử ban đầu được đưa ra bởi Glenford J. Myers năm 1979. Mặc dù sự quan tâm của ông là dựa trên việc phá vỡ kiểm thử nó đã giải thích mong muốn của cộng đồng kĩ nghệ phần mềm chia tách các hoạt động phát triển cơ bản riêng rẽ, như là tách gỡ rối khỏi kiểm tra. Tiến sĩ Dave Gelperin và William C. Hetzel năm 1988 đã phân loại các pha và các mục tiêu trong kiểm thử phần mềm như sau: Cho tới năm 1956 vẫn là khoảng thời gian gỡ rối hướng đối tượng, ở đó kiểm thử thường được kết hợp với gỡ rối. Không có sự khác biệt rõ ràng giữa kiểm thử và gỡ

rối. Từ năm 1957 đến 1978 có thời kì định hướng biểu hiện ở đó việc gỡ rối và kiểm thử được phân biệt – trong thời kì đó nó được chỉ ra rằng phần mềm thỏa mãn các yêu cầu. Thời kì giữa năm 1979 đến 1982 được thông báo như là thời kì định hướng phá vỡ kiến trúc, ở đó mục tiêu là tìm ra lỗi. Từ năm 1983 đến năm 1987 được phân loại như là thời kì định hướng đánh giá: sự quan tâm ở đây là trong suốt vòng đời phần mềm, việc đánh giá một sản phẩm được cung cấp và đo chất lượng. Từ năm 1988 được xem như là thời kì định hướng ngăn cản ở đó việc kiểm thử là để xác định phần mềm thỏa mãn các chi tiết kĩ thuật của nó, để tìm ra lỗi và ngăn chặn lỗi. 3. Vai trò của kiểm thử phần mềm

Trong việc phát triển phần mềm, có những giá trị kết hợp với việc kiểm thử chương trình. Chúng ta cần đưa ra kế hoạch kiểm thử và các ca kiểm thử, thiết lập các trang bị phù hợp, thực thi các ca kiểm thử một cách có hệ thống, chúng ta cần tiếp tục những vấn đề đã được xác định và cần loại bỏ hầu hết các lỗi mà chúng ta tìm thấy. Thực ra đôi khi chúng ta tìm thấy các lỗi ưu tiên thấp trong mã nguồn và quyết định rằng nó quá đắt để cố định lỗi bởi cần phải thiết kế lại, mã hóa lại hay loại bỏ lỗi. Các lỗi đó có thể vẫn còn tiềm ẩn trong sản phẩm qua các phát hành sau đó hay có thể là mãi mãi. Với các lỗi mà chưa được phát hiện và loại bỏ trước khi phần mềm được phát hành , có nhiều chi phí. Một số trong đó là tiền và một số có thể là quan trong trong những cách ít xác thực hơn. Khách hàng có thể mất niềm tin trong việc kinh doanh của chúng ta và có thể rất tức giận. Họ cũng có thể mất một thỏa thuận lớn về tiền nếu hệ thống của họ không hoạt động vì các khiếm khuyết. Và tổ chức phát triển phần mềm sẽ phải dành một lượng tiền lớn để thu được những thông tin xác định về các vấn đề của khách hàng và để tìm và cố định nguyên nhân gây ra lỗi. Đôi khi lập trình viên phải đến tận nơi với khách hàng để làm việc trực tiếp về vấn đề này. Các chuyến đi đó sẽ rất tốn kém cho tổ chức phát triển và khách hàng có thể không còn hào hứng với công việc khi lập trình viên đến. Khi mà chúng ta nghĩ về cái giá cho việc kiểm thử, chúng ta cúng phải nghĩ sự tốn kém nếu không thực hiện kiểm thử. Chúng ta cần xem xét các rủi ro liên quan kết hợp với một thất bại phụ thuộc vào loại dự án chúng ta làm việc. Chất lượng là rất quan trọng cho các phần mềm đòi hỏi sự tin cậy và an toàn cao. Do đó chúng ta phải cân đối giữa giá trị kiểm thử và giá trị

thất bại phần mềm. Một thực tế quan trọng là phần mềm đòi hỏi độ tin cậy và an toàn cao sẽ tốn gấp 3 đến 5 lần so với việc kiểm thử các phần mềm khác. Để tối thiểu chi phí kết hợp với việc kiểm thử và với thất bại phần mềm, một mục tiêu của kiểm thử là để không bao quát được các khiếm khuyết có thể với số ca kiểm thử ít nhất có thể. Nói cách khác, chúng ta muốn viết các ca kiểm thử không có khả năng bao phủ lỗi cao mà có vẻ được quan sát như là lỗi thường gặp. Có thể đơn giản để kiểm thử mọi sự kết hợp đầu vào và đầu ra của hệ thống, có quá nhiều sự hoán vị và kết hợp đơn giản. Khi người kiểm thử cần xem xét tính kinh tế của kiểm thử và cố gắng viết các ca kiểm thử sẽ không bao phủ nhiều lỗi trong một số ít các ca kiểm thử có thể. In software development, there are costs associated with testing our programs. We need to write out test plan and our test cases, we need to set up the proper equipment, we need to systematically execute the test cases, we need to follow up on problems that are identified, and we need to remove most of the faults we find. Actually, sometimes we can find low-priority faults in our code and decide that it is too expensive to fix the fault because of the need to redesign, recode, or otherwise remove the fault. These faults can remain latent in the product through a follow-on release or perhaps forever.

For faults that are not discovered and removed before the software has been shipped, there are costs. Some of these costs are monetary, and some could be significant in less tangible ways. Customers can lose faith in our business and can get very angry. They can also lose a great deal of money if their system goes down because of our defects. (Think of the effect on a grocery store that can’t check out the shoppers because of its “down” point-of-sale system.) And, software development organizations have to spend a great deal of money to obtain specific information about customer problems and to find and fix the cause of their failures. Sometimes, programmers have to travel to customer locations to work directly on the problem. These trips are costly to the development organization, and the customers might not be overly cheerful to work with when the programmer arrives. When we think about how expensive it is to test, we must also consider how expensive it is to not test – including these intangible costs as well as the more obvious direct costs. We also need to consider the relative risk associated with a failure depending upon the

type of project we work on. Quality is much more important for safety- or missioncritical software, like aviation software, than it is for video games. Therefore, when we balance the cost of testing versus the cost of software failures, we will test aviation software more than we will test video games. As a matter of fact, safety-critical software can spend as much as three to five times as much on testing as all other software engineering steps combined (Pressman, 2001)! To minimize the costs associated with testing and with software failures, a goal of testing must be to uncover as many defects as possible with as little testing as possible. In other words, we want to write test cases that have a high likelihood of uncovering the faults that are the most likely to be observed as a failure in normal use. It is simply impossible to test every possible input-output combination of the system; there are simply too many permutations and combinations. As testers, we need to consider the economics of testing and strive to write test cases that will uncover as many faults in as few test cases as possible. In this chapter, we provide you with disciplined strategies for creating efficient sets of test cases – those that will find more faults with less effort and time. 4. Các phương pháp kiểm thử

Có 2 phương pháp kiểm thử phần mềm phương pháp kiểm thử hộp trắng và kiểm thử hộp đen. Nội dung chi tiết từng phương pháp này sẽ được trình bày chi tiết trong các chương sau. 5. Các loại hình kiểm thử

-

Kiểm thử đơn vị: việc kiểm thử từng thành phần riêng lẻ, từng môđun trong chương trình để đảm bảo các thành phần riêng lẻ làm việc đúng đắn. Một đơn vị là một phần có thể kiểm thử nhỏ nhất của một ứng dụng. Trong lập trình thủ tục, một đơn vị có thể là chương trình riêng rẽ, một hàm, thủ tục. Trong lập trình hướng đối tượng, một đơn vị nhỏ nhất luôn là một lớp, có thể là lớp cơ sở, lớp trừu tượng hay lớp dẫn xuất.

-

Kiểm thử tích hợp: là kiểm thử trong đó các module riêng lẻ được kết hợp và kiểm thử như là một nhóm. Kiểm thử tích hợp nhận đầu vào là các module đã được kiểm thử đơn vị, kết hợp chúng lại trong một kế hoạch kiểm thử tích hợp và cung cấp như là đầu ra là một hệ thống tích hợp sẵn sàng cho kiểm thử hệ thống.

-

Kiểm thử hệ thống: là cách thức kiểm thử trên một hệ thống hoàn thiện, tích hợp để đánh giá sự tương thích của hệ thống với các yêu cầu xác định của nó.Kiểm thử hệ thống lấy đầu vào là tất cả các thành phần phần mềm đã được

kiểm thử tích hợp và cũng như các hệ thống phần mềm đã thích hợp với bất kì hệ thống phần cứng tương thích nào. Mục đích là phát hiện ra sự không tích hợp giữa các đơn vị phần mềm được tích hợp gọi là một nhóm hay giữa các nhóm và phần cứng. Kiểm thử hệ thống là loại kiểm thử giới hạn hơn. Nó phát hiện các lỗi trong nhóm và cả trong hệ thống như là một tổng thể. Kiểm thử hệ thống bao gồm: o Kiểm thử phục hồi o Kiểm thử áp lực o Kiểm thử thi hành o Kiểm thử an ninh -

Kiểm thử chấp nhận được: Khi phần mềm được xây dựng cho một khách hàng, các kiểm thử chấp nhận được thực thi để đảm bảo cho khách hàng thẩm định tất cả các yêu cầu phần mềm. Việc kiểm thử được thực hiện bởi người dùng cuối hơn là người phát triển hệ thống. Trên thực tế, việc kiểm thử chấp nhận được có thể thực thi trong khoảng vài tuần hoặc vài tháng. Do đó các lỗi tích lũy chưa được bao phủ có thể làm giảm hệ thống theo thời gian. Kiểm thử chấp nhận được bao gồm: o Kiểm thử alpha o Kiểm thử beta

6. Các chiến lược kiểm thử

Với mỗi loại kiểm thử thường sử dụng các phương pháp và chiến lược kiểm thử thích hợp. Có một số chiến lược kiểm thử sau: -

Kiểm thử từ trên xuống/dưới lên (tích hợp)

-

Kiểm thử vụ nổ lớn (bigbang- tích hợp)

-

Kiểm thử hồi quy (quá trình tích hơp)

-

Kiểm thử luồn sợi (hệ thời gian thực)

CHƯƠNG 2. KĨ THUẬTPHƯƠNG PHÁP KIỂM THỬ HỘP TRẮNG 1. Khái niệm

Kýỹ thuật kiểm thử hộp trắng là kĩ thuật thẩm định kiểm tra mà kĩ sư phần mềm có thể sử dụng để kiểm tra xem mã nguồn có hoạt động đúng như mong đợimã nguồn về mức độ hoạt động theo các kết quả mong đợi. Kiểm thử hộp trắng là kỹ thuật kiểm thử mà đi vào cấu trúc bên trong của hệ thống hay thành phần. Kiểm thử hộp trắng cũng được biết đến như là kiểm thử cấu trúc “structural”, kiểm thử hộp sáng “clear box” vàhay kiểm thử hộp gương “glass box”. Ý nghĩa của hộp sáng “clear box” và hộp gương “glass box” ngụ ý chỉ ra rằng bạn có thể có cái nhìn đầy đủ về công việc bên trong của phần mềm, đặc biệt cấu trúc và lôgic của mã nguồn. Sử dụng kĩ thuật hộp trắng , kĩ sư phần mềm có thể thiết kế được các ca kiểm thử mà thực thi các đường dẫn độc lập trong phạm vi module hay đơn vị, thực thi các quyết định lôgic trên cả hai khía cạnh đúng sai, , thực thicác vòng lặp tại đường giá trị biên và trong phạm vi cận toán tử của chúng và thi thivà cấu trúc dữ liệu bên trong. để đảm bảo việc thẩm định chúng. Có 6 loại kiểm thử cơ bản: kiểm thử đơn vị, tích hợp, chức năng/hệ thống, chấp nhận được, hồi quy và bêta. Kiểm thử hộp trắng được sử dụng cho 3 trong 6 loại đó: -

Kiểm thử đơn vị: là kiểm thử các đơn vị phần mềm, hay phần cứng riêng rẽ hay nhóm các đơn vị liên quan. Một đơn vị là một thành phần phần mềm mà không thể chia nhỏ thành các đơn vị khác nữa. Kĩ sư phần mềm viết cCác ca kiểm thử hộp trắng được viết để kiểm tra xem mức độ đúng đắn mã nguồn củacác các đơn vị được viết mã đúng. Kiểm thử đơn vị quan trọng trong việc đảm bảo rằng mã nguồn là một khối trước khi nó được tích hợp với các đoạn mã khác. Ngay khi mã nguồn được tích hợp vào nền mã nguồn, nguyên nhân của một thất bại được tìm ra sẽ khó khăn hơn. Cũng bởi vì kĩ sư phần mềm tự viết và chạy kiểm thử đơn vị, công ty thường không lưu trữ các thất bại kiểm thử đơn vị đã được quan sát – tạo ra các loại khiếm khuyết đó đối với hầu hết các cá nhân kĩ sư phần mềm. Chúng ta muốn tìm ra được các lỗi và có cơ hội

để cố định chúng mà không cần biết những thứ khác. Khoảng 65% các lõi lỗi có thể được bắtphát hiện bởi kiểm thử đơn vị. -

Kiểm thử tích hợp: là kiểm thử trong đó các thành phần phần mềm, thành phần phần cứng hay cả hai được kết hợp lại và kiểm thử để đánh giá sự tương tác giữa chúng. Các ca kiểm thử được viết để kiểm tra rõ ràng giao diệngiao tiếp giữa các đơn vị khác nhau. Các ca kiểm thử này có thể là kiểm thử hộp đen ở đó các tester hiểu được rằng một ca kiểm thử yêu cầu giao tiếp các đơn vị đa chương trình, để giao tiếp. Hhoặc các ca kiểm thử hộp trắng được viết để kiểm tra rõ ràng các giao diện được biết cho các tester.

-

Kiểm thử hồi quy: là sự kiểm thử lại dựa trên tuyển chọn của một hệ thống hay thành phần để kiểm tra rằng việc sửa đổi không gây ra những ảnh hưởng không mong muốn đợi và hệ thống đó hay thành phần vẫn tuân theo các yêu cầu xác định của nó. Cũng như là với kiểm thử tích hợp, kiểm thử hồi quy có thể được thực hiện thông qua kiểm thử hộp đen hay kiểm thử hộp trắng hoặc kết hợp cả hai. Kiểm thử tích hợp và đơn vị hộp trắng có thể được lưu trữ và chạy lại như là một phần của kiểm thử hồi quy.

2. Kiểm thử hộp trắng bởi stubs và drivers

Với kKĩ thuật kiểm thử hộp trắng, bạn yêu cầu phải chạy mã nguồn với đầu vào xác định và kiểm tra để đảm bảo rằng mã nguồn sinh ra kết quả sinh ra được đúng như mong đợi. Các lập trình viên thường viết các cuống “stub” và bộ phận điều khiển “driver” cho kiểm thử hộp trắng. Một “driver” là một module phần mềm được sử dụng để dẫngọi chứng tớitới một module dưới kiểm thử và thường cung cấp các đầu vào kiểm thử, điều khiển và , quản lí thực thi và báo cáo kết quả kiểm thử hay đơn giản nhất là một dòng mã mà gọi tới một phương thức và đi quatruyền cho phương thức đó một giá trị. Chẳng hạn nếu bạn muốn di chuyển một cầu thủ trên sân, mã driver có thể là movePlayer( Player, diceRoll). ; Mã driver này gần như có thể được gọi từ hàm main. Một ca kiểm thử hộp trắng sẽ thực thi dòng mã driver này và kiểm tra Player.getPosition() để đảm bảo cầu thủ hiện đang ở một ô mong đợi trên sân.

Một cuống “stub” là một câu lệnh thay thể cho một đoạn của module phần mềm mà có thể được xác định ở đâu đó, hay là một thành phần giả hay một đối tượng được sử dụng để mô phỏng ứng xử của một thành phần thực cho tới tận khi thành phần đó được phát triển. Ví dụ nếu phương thức movePlayer vẫn chưa được viết, một cuống như dưới đây có thể được viết để dùng tạm – mà di chuyển một cầu thủ bất kì tới vị trí 1: Public void movePlayer( Player player, int diceValue){ player.setPosition (1); } Cuối cùng, phương thức giả được thực hiệnhoàn thành với logic chương trình chính xácđúng. Dẫu sao vViệc phát sử dụng triển cuống cho phép lập trình viên gọi một phương thức trong mã sẽ được phát triển, thậm chí nếu phương thức đó vẫn chưa có các ứng xử mong muốn. 3. Thiết kế các ca kiểm thử

Trong mục dưới đây, chúng ta sẽ thảo luận về các phương pháp khác nhau cho việc thiết kế một cách đầy đủ nhất các ca kiểm thử hộp trắng. Chúng ta sẽ đề cập tới ví dụ Monopoly để giải thích cho các phương pháp được thảo luận ở dưới. Những phương pháp này có thể phục vụ như là hươóng dẫn cho việc thiết kế các ca kiểm thử. Thậm chí có thể như là rất nhiều các công việc để sử dụng các phương pháp đó, thống kê chỉ ra rằng cá hành động thiết kế kiểm thử cẩn thận, toàn diện, đối xứng sẽ gặp nhiều lỗi như là hoạt động kiểm thử. Quá trình thiết kế các ca kiểm thử tại tất cả các cấp độ ít nhất hiệu quả trong việc tìm lỗi banừg việc chạy các ca kiểm thử được thiết kế bởi quá trình đó. Mỗi lần viết một module, bạn nên viết các ca kiểm thử cho nó dựa trên nguyên tắc đó. Một ngoại lệ có thể dối với gợi ý này là các phương thức truy cập của dự án của bạn. Bạn nên tập trung vào nỗ lực kiểm thử của bạn dựa trên mã nguồn đó mà có thể dễ bị phá vỡ. Nói chung phương pháp truy cập sẽ được viết tự do lỗi.. 3.1. Kiểm thử đường dẫn cơ bản Kiểm thử đường dẫn cơ bản là một phương tiện cho việc đảm bảo rằng tất cả đường dẫn độc lập thông qua module mã nguồn đều được kiểm thử. Một đường dẫn độc lập

là đường dẫn bất kì đi qua mã nguồn mà sinh ra ít nhất một tập các câu lệnh quá trình mới hay một điều kiện mới. Kiểm thử đường dẫn cơ bản cung cấp số ca kiểm thử tối thiểu hay cận dưới số ca sẽ được viết. Để đưa ra giới thiệu phương pháp đường dẫn cơ bản, chúng ta sẽ vẽ một luồng đồ họa của các đoạn mã nguồn. Ngay sau kKhi bạnđã hiểu về kiểm thử đường dẫn cơ bản, có thể không cần thiết vẽ ra luồng đồ hoạ mặc dù bạn có thể luôn luôn tìm thấycó một trợ giúp mở rộng hữu ích nào đó. Nếu bạn kiểm thử tăng thêmmở rộng và các module bạn kiểm thử là đủ nhỏ, bạn có thể xem xét có một bức tranh tưởng tượng về luồng đồ họa. Như bạn sẽ thấy, mục tiêu chính là để xác định số lượng các điểm quyết định trong module và bạn có thể xác định chúng mà không cần viết các biểu diễn. Ta hãy xét một luồng đồ họa để mô tả yêu cầu sau: nếu một cầu thủ muốn mua nhà, anh ta xác định một ô tài sản chưa thuộc sở hữu và phải đủ tiền để mua. Nếu vậy, tiền của người chơi sẽ giảm theo giá mua bán.

Trong luồng đồ thị đơn giản bên, hình chữ nhật chỉ ra một chuỗi các bước tiến trình. Hình thoi biểu diễn các tính chất hay điều kiện logic. Một số ví dụ về điều kiện logic là if – then, if – then – else, lựa chọn hay vòng lặp. Hướng mũi tên chỉ ra luồng điều khiển. Với một hình chữ nhật sẽ có một mũi tên hướng ra. Với một tính chất sẽ có hai mũi tên hướng ra, một cho kết quả đúng/dương và một cho kết quả sai/âm. Sử dụng đồ thị luồng, chúng ta có thể tính toán số lượng đường dẫn độc lập qua đoạn mã nguồn. Chúng ta sẽ thực hiện điều này sử dụng một số “cyclomatic” dựa trên đồ thị luồng. Cách dễ nhất để tính toán số cyclomatic là đếm các điều kiện/thuộc tính (hình thoi) và cộng thêm 1. Trong ví dụ trên, có 4 điều kiện. Do đó số cyclomatic là

5 và chúng ta có 5 đường dẫn độc lập qua mã nguồn. Chúng ta có thể đánh số chúng như sau: 1-2-7-8, 1-2-7-9, 1-2-3-4-5-6, 1-2-3, 1-2-3-4. Chúng ta muốn viết các ca kiểm thử để đảm bảo rằng mỗi đường dẫn đó được kiểm thử ít nhất một lần. Như đã nói ở trên, số cyclomatic là cận dưới của số các ca kiểm thử sẽ được viết. Các ca kiểm thử được xác định theo cách này là những ca mà chúng ta sử dụng trong kiểm thử đường dẫn cơ bản 3.2. Phân hoạch tương đương/phân tích giá trị biên Phân hoạch tương đương (EP) và phân tích giá trị biên (BVA) cung cấp một chiến lược cho việc viết các ca kiểm thử trắng. Khi bạn bắt gặp bất kì kiểu số lượng hay giới hạn trong một yêu cầu, bạn sẽ được cảnh báo về vấn đề EP/BVA. Chẳng hạn một người muốn mua nhà nhưng có thể không có đủ tiền. Xem xét EP/BVA, chúng ta muốn đảm bảo rằng các ca kiểm thử của chúng ta bao gồm các vấn đề sau: 1. Ngôi nhà trị giá $100, có $200 (lớp tương đương “có đủ tiền”) 2. Ngôi nhà trị giá $100, có $50 (lớp tương đương “không có đủ tiền”) 3. Ngôi nhà trị giá $100, có $100 (giá trị biên) 4. Ngôi nhà trị giá $100, có $99 (giá trị biên) 5. Ngôi nhà trị giá $100, có $101 (giá trị biên) Với vòng lặp lập trình (chẳng hạn như vòng lặp while), hãy xem xét EP và xử lí vòng lặp ở giá trị trung tâm của gianh giới toán tử của nó. Với BVA, bạn muốn đảm bảo rằng bạn thực thi vòng lặp tại các giá trị trên, dưới và tại điều kiện biên của chúng. 4. Kiểm thử bao phủ/luồng điều khiển

Một cách khác để đưa ra một tập các ca kiểm thử hộp trắng tốt là xem xét các luồng điều khiển của chương trình. Luồng điều khiển của chương trình được biểu diễn theo một đồ thị luồng. Chúng ta xem xét các khía cạnh khác nhau của đồ thị luồng để đảm bảo có một tập tương đối đầy đủ các ca kiểm thử. Tính đầy đủ của các ca kiểm thử thường được đo bởi độ bao phủ. Độ bao phủ là độ đo của mức độ hoàn thiện của một tập các ca kiểm thử. Để giải thích cho các loại độ bao phủ khác nhau,

chúng ta sẽ sử dụng ví dụ sau như là nền tảng cho việc thảo luận mà chúng ta sẽ đưa ra trong 5 mục tiếp theo.

Nắm bắt được kĩ thuật kiểm thử chính xác, chúng ta viết các phương thức để đảm bảo rằng chúng có thể kiểm thử được một cách đơn giản bởi phương thức có một giá trị trả về. Một kĩ thuật kiểm thử khác là sử dụng tập các đầu vào đơn giản có thể được thực hiện cho kiểm thử - tốt nhất là các giá trị không phải là giá trị đầu vào mà gây ra các tính toán thiên về lỗi phức tạp khi bạn xác định trước giá trị. Chúng ta sẽ giải thích nguyên lí này khi chúng ta xem xét các hạng mục tiếp theo. 4.1. Bao phủ phương thức Bao phủ phương thức là một độ đo tỉ lệ phần trăm các phương thức được gọi bởi các ca kiểm thử. Rõ ràng các ca kiểm thử của bạn sẽ gọi 100% các phương thức của bạn. Có vẻ như là vô trách nhiệm khi thực hiện các phương thức trong sản phẩm khi việc kiểm thử của bạn không bao giờ sử dụng các phương pháp đó. Như là kết quả, cần phải đảm bảo bao phủ phương thức 100%. Như trong mã nguồn được chỉ ra trong hình trên, chúng ta đạt được 100% độ bao phủ phương thức bởi việc gọi phương thức foo. Xem xét ca kiểm thử 1: phương thức gọi phương thức foo(0,0,0,0,0) mong đợi trả về giá trị 0. Nếu bạn xem lại mã nguồn bạn sẽ thấy rằng nếu a có giá trị 0, giá trị trả về sẽ không bị ảnh hưởng bởi giá trị

của các tham số khác – bởi vậy sẽ dễ dàng hơn và gán cho chúng giá trị 0. Thông qua việc gọi phương thức này, bao phủ phương thức là 100%. 4.2. Bao phủ câu lệnh Bao phủ câu lệnh là một độ đo tỉ lệ phần trăm các câu lệnh chương trình được thực thi khi tiến hành các ca kiểm thử. Mục tiêu là đạt được 100% độ bao phủ câu lệnh trong các ca kiểm thử. Có thể thực hiện được điều đó thông qua việc xác định số cyclomatic và thực thi một tập tối thiểu các ca kiểm thử. Trong ca kiểm thử 1, chúng ta thực thi câu lệnh trên dòng 1-5 của 12 dòng mã lệnh. Khi đó, bao phủ câu lệnh là 42% (5/12 ) qua ca kiểm thử này. Chúng ta có thể thu được độ bao phủ câu lệnh 100% bởi một ca kiểm thử mở rộng, ca kiểm thử 2: phương thức gọi foo(1,1,1,1,1), trả về giá trị mong đợi là 1. Với việc gọi phương thức này, độ bao phủ câu lệnh là 100% bởi vì đã thực thi câu lệnh chương trình trong dòng 6-12. 4.3. Độ bao nhánh/quyết định Độ bao phủ nhánh hay quyết định là một độ đo của tỉ lệ biểu diễn logíc của chương trình sẽ được thực thi trong cả 2 khía cạnh đúng và sai trong kiểm thử. Chương trình trên có 3 điểm quyết định – một trên dòng 3 và một trên dòng 7. 3. if(a==0){} 7. if((a==b) or ((c==d)and bug(a))){} Với độ bao phủ nhánh/cây quyết định chúng ta sẽ đánh giá toàn bộ công thức logic như là một tính chất đúng-sai thậm chí nếu nó chứa nhiều các toán tử logic and/or như trong dòng 7. Chúng ta cần đảm bảo rằng mỗi tính chất đó (phức hợp hay đơn) được kiểm thử trên cả 2 khía cạnh đúng/sai. Bảng dưới đây chỉ ra quá trình của chúng ta.

Do đó, hiện tại chúng ta đã thực thi 3 trong 4 điều kiện cần thiết; chúng ta đạt 75% độ bao phủ nhánh. Ta thêm ca kiểm thử 3 để đạt được độ bao phủ nhánh là 100%: foo(1,2,1,2,1). Khi nhìn vào mã nguồn để tính toán giá trị trả về, ta thấy rằng ca kiểm thử này chưa bao quát vấn đề chia bởi 0 ở dòng 10. Ngay sau đó chúng ta sẽ chuyển tới dòng 10 và tránh lỗi như vậy. Điều này giải thích giá trị của kế hoạch kiểm thử. Thông qua ca kiểm thử, chúgn ta đạt được 100% độ bao phủ nhánh. Trong nhiều trường hợp, mục tiêu là đạt được 100% độ bao phủ nhánh trong việc kiểm thử, thông qua hệ thống lớn chỉ khoảng 75-85% được thực thi. Chỉ 50% độ bao phủ nhánh được thực thi trong hệ thống rất lớn của hơn 10 triệu dòng mã lệnh. 4.4. Độ bao phủ điều kiện Độ bao phủ điều kiện đưa ra kết quả đúng sai của mỗi biểu diễn logic của thuộc tính phức hợp. Chú ý rằng trong dòng 7 có 3 biểu diễn logic con đối với các câu lệnh lớn hơn (a==b), (c==d) và bug(a). Độ bao phủ điều kiện đo kết quả của mỗi biểu diễn logic độc lập với các biểu diễn con khác. Độ bao phủ điều kiện đảm bảo rằng mỗi biểu diễn logic con đó được kiểm tra độc lập trên cả hai mặt đúng và sai. Chúng ta sẽ xem xét quá trình của chúng ta trong bảng dưới.

Tại điểm này, độ bao phủ của chúng ta chỉ là 50%. Điều kiện đúng (c==d) không bao giờ được kiểm thử. Thêm vào đó logic vòng ngắn đã ngăn cản phương thức bug(int) được thực thi. Chúng ta xác định thông tin sẵn sàng của chúng ta trong phương thức bug và xác định xem nên trả về một giá trị đúng khi truyền cho a giá trị 1. Chúng ta viết ca kiểm thử 4 với điều kiện c==d là đúng: foo(1,2,1,1,1), giá trị trả về là 1. Dẫu sao khi chúng ta thực thi các ca kiểm thử, hàm bug(a) thực tế trả về giá trị false nên giá trị trả về thực tế (chia bởi 0) không phù hợp với giá trị mong đợi trả về. Điều này cho phép chúng ta phát hiện ra các lỗi trong phương thức bug. Nếu không mở rộng độ bao phủ điều kiện, lỗi này không thể được phát hiện.

Để hoàn thành độ bao phủ điều kiện, ta buộc bug(a) giá trị false. Chúng ta kiểm tra lại lần nữa thông tin bug() mà thông tin cho chúng ta rằng phương thức bug nên trả về giá trị false với việc cung cấp số nguyên bất kì lớn hơn 1. Bởi vậy chúng ta tạo ra ca kiểm thử 5, foo(3,2,1,1,1), giá trị trả về mong đợi “chia bởi lỗi”. Độ bao phủ điều kiện do đó như bảng dưới đây.

5. Kiểm thử luồng dữ liệu

Trong kiểm thử dựa trên luồng dữ liệu, đồ thị luồng điều khiển được giải thích với thông tin về cách thức mà các biến chương trình được xác định và sử dụng. Tiêu chuẩn khác nhau thực thi với cấp bậc khác nhau của độ chính xác cách thức mà một nhau. Sự giải thích khác nhau là một cặp sử dụng – định nghĩa, mà là một bộ 3 (d,u,V) trong đó V là biến, d là một kí hiệu trong đó V được xác định, và u là một điểm mà ở đó V được sử dụng. Tồn tại một đường dẫn giữa d và u trong đó định nghĩa của V trong d được sử dụng trong u.

CHƯƠNG 3. PHƯƠNG PHÁP KIỂM THỬ HỘP ĐEN 1. Khái niệm

CHƯƠNG 3. KĨ THUẬT KIỂM THỬ HỘP ĐEN Kiểm thử hộp đen tập trung vào các yêu cầu chức năng của phần mềm. Nghĩa là kiểm thử hộp đen cho phép các kĩ sư phần mềm xuất phát từ tập các điều kiện vào mà sẽ sử dụng tất cả các yêu cầu chức năng cho chương trình. Kiểm thử hộp đen cố gắng tìm ra các lỗi trong các hạng mục sau đây: lỗi hoặc thiếu các chức năng, các lỗi giao diện, cá lỗi trong cấu trúc dữ liệu hay truy cập dữ liệu ngoài, các lỗi thực thi và các lỗi khởi đầu, kết thúc. Không như kiểm thử hộp trắng, ở đó nó được thực hiện sớm trong quá trình kiểm thử, kiểm thử hộp đen có khuynh hướng được áp dụng trong suốt giai đoạn sau của việc kiểm thử. Bởi vì kiểm thử hộp đen không chú ý đến cấu trúc điều khiển một cách có mục đích, sự quan tâm chỉ tập trung vào miền thông tin. Các kiểm thử được thiết kế để trả lời cho câu hỏi sau: Việc thẩm định chức năng được kiểm thử như thế nào Các lớp dữ liệu vào nào sẽ tạo các ca kiểm thử tốt Hệ thống có ảnh hưởng nhất định với các giá trị đầu vào nhất định Giá trị biên của một lớp dữ liệu bị cô lập như thế nào Tốc độ dữ liệu và khối lượng dữ liệu mà hệ thống có thể chấp nhận Tác động nào sẽ có trong việc kết hợp dữ liệu với sự vận hành hệ thống Bằng việc áp dụng kĩ thuật kiểm thử hộp đen, chúng ta sẽ đưa ra một tập các ca kiểm thử thỏa mãn các điều kiện dưới đây:

Kiểm thử hộp đen tập trung vào các yêu cầu chức năng của phần mềm. Nó Ccho phép thiết kế tập các điều kiện đầu vào để thực thi tất cả các yêu cầu chức năng của chương trình. Kiểm thử hộp đen không phải là sự luân phiênphần bù cho của kiểm thử hộp trắng. Đúng hơn, đĐó là kĩ thuật kiểm thử bổ sung màcho kiểm thử hộp trắng với độ bao phủ các lớp lỗi ít hơn hầu như không bao phủ hết các lớp lỗi hơn là phương pháp hộp trắng.. Kĩ thuật kiểm thử hộp đen cố gắng tìm ra các lỗi theo các hạng mục sausau: Các lỗi hay các hàm bị mấtcác hàm bị lỗi hay mất, lỗi giao diện, lỗi trong cấu trúc dữ liệu hay truy cập dựa trên dữ liệu ngoài, lỗi thực thi và các lỗi khởi đầu và kết thúc. Không như kĩ thuật kiểm thử hộp trắng được thực thi trong giai đoạn sớm của quá trình kiểm thử, kiểm thử hộp đen được thực hiện trong giai đoạn sau của quá trình kiểm thử. kKiểm thử hộp đen chủ yếukhông quan tâm tới tập trung vào cấu trúc điều khiển mà tập trung vào , miền thông tin. Kiểm thử được thiết kế để trả lời các câu hỏi sau: -

Giá trị (căn cứ) chức năng được kiểm thử như thế nào;

-

Các lớp đầu vào nào sẽ tạo racho các ca kiểm thử tốt;.

-

Hệ thống có bị ảnh hưởng bởi những giá trị đầu vào nhất định;.

-

Giá trị biên của các lớp dữ liệu được cô lậpphân tách như thế nào;

-

Tốc độTỷ lệ và lượng dữ liệu mà hệ thống có thể chịu được;

-

Việc kết hợp dữ liệu xác định có ảnh hưởng gì trong việc vận hành hệ thống

2. Bởi áp dụng kĩ thuật kiểm thử hộp đen, chúng ta có thể thiết kế một tập các ca kiểm thử thỏa mãn các điều kiện sau đây: Các ca kiểm thử giảm sẽ tốt hơn là các ca kiểm thử mở rộng để đạt được các ca kiểm thử hợp lí. Và các ca kiểm thử sẽ cho chúng ta biết việc có hay vắng mặt các lớp lỗi hơn là các lỗi được kết hợp chỉ với việc kiểm thử xác định bằng tay. 3. Các phương pháp kiểm thử dựa trên đồ thị

Bước đầu tiên trong kiểm thử hộp đen là để hiểunắm được các đối tượng mà được mô hình hóa trong phần mềm và các mối quan hệ liên kết cácgiữa đối tượng. Sau khi hoàn thành, bước tTiếp theo là xác định chuỗi các ca kiểm thử mà kiểm tra tất cả các đối tượng có những quan hệ với các đối tượng khác. Nói cách khác, việc kiểm thử phần mềm bắt đầu bởi việc tạo ra một đồ thị của các đối tượng quan trọng và

các mối quan hệ giữa chúng và sau đó thiết kế chuỗi ccác ca kiểm thử bao phủ đố thị cốt để các đối tượng và các mối quan hệ được thực thi và các lỗi được phát hiện lỗi. Để hoàn thànhthực hiện điều này các bước này, chúng ta sẽ bắt đầukhởi đầu là bởi việc ttạo ra một đồ thị - một tập các nốt biểu diễn các đối tượng, các liên kết biểu diễn mối quan hệ giữa các đối tượng. Trọng số các nốt mô tả tính chất một nốt như giá trị dữ liệu hay ứng xử trạng thái và trọng số liên kết mô tả các đặc tính của liên kết. Việc biểu diễn dưới dạng các kí hiệu của đồ thị được chỉ ra trong hình dưới. Các nốt biều diễn bởi các đường tròn được kết nối bởi các đường liên kết trong một số dạng khác nhau. Liên kết trực tiếpcó hướng (được biểu diễn bởi một mũi tên) chỉ ra mỗi quan hệ chỉ theo một hướng. Liên kết hai chiều cũng được gọi là liên kết đối xứng ngụ ý rắng mối chỉ ra mối quan hệ là theo hai hướng. Liên kết song song được sử dụng khi có một só mối quan hệ khác nhau được thiết lập giữa các nốt của đồ thị.

Đối tượng 1

Liên kết có hướng

Liên kết không có hướng

Đối tượng 2

Liên kết song song

Đối tượng 3

Ta hãy xem xét một phần đồ thị cho ứng dụng xử lí từ. Như đã chỉ ra trong hình vẽ dưới, một menu select trong file new tạo ra một cửa sổ tài liệu. Trọng số nốt của cửa sổ tài liệu cung cấp một danh sách các thuộc tính cửa sổ. Trọng số liên kết chỉ ra rằng cửa sổ phải được tạo ra dưới 10 giây. Liên kết gián tiếp thiết lập một mối quan hệ đối xứng giữa new file menu select và document text. Liên kết song song chỉ ra mỗi quan hệ giữa document window và document text. Trên thực tế, ta phải tạo ra

đồ thị chi tiết hơn trước khi thiết kế các ca kiểm thử. Các kĩ sư phần mềm sau đó thiết kế các ca kiểm thử bởi việc duyệt đồ thị và bao phủ mỗi mối quan hệ được xác định. Các ca kiểm thử đó được thiết kế trong một cố gắng tìm ra các lỗi trong bất kì mối quan hệ nào.

Menu select generates New file

Generate time < 1s

Documen t window

Allows editing of Is presented as

Contains

Documen t text

Beizer mô tả mótố phương pháp kiểm thử cư xử mà có thể sử dụng đồ thị: Mô hình luồng thực hiện. Các nốt biều diễn các bước trong một số thực hiện( chẳng hạn các bước được yêu cầu để tạo ra một sự đặt vé hàng không trong dịch vụ trực tuyến) và các đường liên kết biểu diễn các liên kết lôgic giữa các bước( chẳng hạn

flight.information.input được tiếp sau quá trình validation/availability). Sơ đồ dòng dữ liệu có thể được sử dụng để trợ giúp cho việc tạo ra đồ thị loại này. Mô hình trạng thái hữu hạn.Các nốt biểu diễn các trạng thái có thể thấy được bởi người dùng khác nhau của phần mềm (chẳng hạn mỗi màn hình xuất hiện khi thư kí nhập hóa đơn tạp một đơn điện thoại) và các liên kết biểu diễn các thực hiện được xảy ra để chuyển từ trạng thái này sang trạng thái kia ( chẳng hạn order-information được thẩm định trong suốt inventory-availability-look-up được theo sau bởi customer-billing-information-input). Lược đồ chuyển trạng thái có thể được sử dụng để trợ giúp cho việc tạo ra đồ thị loại này. Mô hình luồng dữ liệu: Các nốt là các đối tượng dữ liệu, và các đường liên kết là các chuyển dịch xảy ra để dịch chuyển một đối tượng dữ liệu thành đối tượng dữ liệu khác (chẳng hạn nốt FICA.tax.withheld (FTW) được tính toán từ gross.wages (GW)sử dụng mối quan hệ, FTW=0.062xGW) Mô hình quyết định thời gian: Các nốt là các đối tượng chương trình và các đường liên kết là các kết nối tuần tự giữa các đối tượng đó. Trọng số liên kết được sử dụng để xác định thời gian thực thi yêu cầu khi thực thi chương trình. Việc kiểm thử dựa trên đồ thị bắt đầu bởi việc xác định tất cả các nốt và trọng số nốt. Nghĩa là các đối tượng và các thuộc tính được xác định. Mô hình dữ liệu có thể được sử dụng như là điểm khởi đầu. Nhưng rất quan trọng cho nốt mà nhiều nốt có thể là đối tượng chương trình (không được biểu diễn rõ ràng trong mô hình dữ liệu). Để cung cấp một ứng cử cho điểm bắt đầu và điểm kết thúc cho đồ thị, sẽ rất hữu ích khi xác định các nốt vào và nốt ra. Ngay sau khi các nốt đã được xác định, các liên kết và trọng số liên kết cũng được thiết lập. Nói chung các liên kết cần được đổi tên mặc dù các liên kết biểu diễn luồng điều khiển giữa các đối tượng không cần thiết phải đổi tên. Trong nhiều trường hợp, mô hình đồ thị có thể có vòng lặp (chẳng hạn đường dẫn qua đồ thị mà có thể có một hoặc nhiều nốt bắt gặp nhiều hơn một lần). Kiểm thử vòng lặp có thể được áp dụng tại cấp độ ứng xử. Đồ thị sẽ trợ giúp trong việc xác định các vòng lặp như vậy mà cần thiết được kiểm thử. Mỗi mối quan hệ được nghiên cứu một cách riêng rẽ cốt để các ca kiểm thử có thể được đưa ra. Việc chuyển các mối quan hệ tuần tự được nghiên cứu để xác định tác

động như thế nào của các mối liên hệ truyền qua các đối tượng xác định trong đồ thị. Việc chuyển có thể được minh họa bởi việc xem xét 3 đối tượng X,Y,Z. Xem xét các mối liên hệ sau: X được yêu cầu để tính toán Y Y được yêu cầu để tính toán Z. Do đó một mối quan hệ chuyển tiếp thể được thiết lập giữa X và Z: X được yêu cầu để tính toán Z. Dựa trên mối quan hệ chuyển tiếp, việc kiểm thử để tìm ra lỗi trong việc tính toán của Z phải được xem xét những giá trị thay đổi của cả X và Y. Tính đối xứng của các mối quan hệ (liên kết đồ thị) là một hướng dẫn quan trọng để thiết kế các ca kiểm thử. Nếu một liên kết quả thực là hai chiều (đối xứng), sẽ rất quan trọng trong việc kiểm thử đặc tính này. Thuộc tính UNDO trong nhiều ứng dụng thực thi đối xứng giới hạn. Đó là UNDO cho phép một hành động được phủ định sau khi nó được hoàn thành. Điều này cần được kiểm thử một cách kĩ càng và tất cả các ngoại lệ cần được chú ý. Cuối cùng mọi nốt trong đồ thị cần có mối quan hệ mà liên kết với chính nó. Về thực chất đó là vòng lặp không có một hành động hay vòng lặp hành động rỗng. Các mối quan hệ phản chiếu đó cũng cần được kiểm thử. Khi bắt đầu thiết kế các ca kiểm thử, mục tiêu đầu tiên là đạt được bao phủ nốt. Bởi điều này chúng ta ngụ ý rằng việc kiểm thử nên được giải thích để chứng minh rằng không có nốt nào bị bỏ sót và trọng số các nốt là đúng. Tiếp theo, bao phủ liên kết được xác định. Mỗi mối quan hệ được kiểm thử dựa trên thuộc tính của chúng. Chẳng hạn, mối quan hệ đối xứng được kiểm thử để chứng minh rằng chúng là hai chiều. Mỗi quan hệ chuyển tiếp được kiểm thử để chứng minh rằng việc chuyển tiếp là đang được xem xét. Mối quan hệ phản chiếu được kiểm thử để đảm bảo rằng vòng lặp rỗng đang được xem xét. Khi trọng số liên kết được xác định, việc kiểm thử được đưa ra để chứng minh rằng các trọng số đó là đúng. Cuối cùng kiểm thử vòng lặp được thực thi.

4. Phân hoạch tương đương

Phân hoạch tương đương là phương pháp kiểm thử hộp đen chia miền dữ liệu vào thành các lớp từ đó có thể thực hiện các ca kiểm thử. Phân hoạch tương đương cố gắng xác định các ca kiểm thử mà không bao phủ các lớp lỗi, do đó giảm tổng số các kiểm thử sẽ được phát triển. Thiết kế các ca kiểm thử cho phân hoạch tương đương dựa trên việc đánh giá của các lớp tương đương cho một điều kiện đầu vào. Sử dụng khái niệm được đưa ra trong mục trước, nếu một tập các đối tượng có thể liên kết bởi các mối quan hệ đối xứng, chuyển tiếp và phản xạ, một lớp tương đương được biểu diễn. Một lớp tương đương biểu diễn một tập các trạng thái phù hợp hay không cho các điều kiện đầu vào.Điển hình, một điều kiện đầu vào hoặc là một giá trị số xác định, một miền giá trị, một tập các giá trị liên quan hay một điều kiện logíc. Lớp tương đương có thể được xác định dựa theo các yếu tố sau: -

Nếu điều kiện đầu vào xác định một miền, một lớp tương đương đúng và hai lớp tương đương sai được xác định.

-

Nếu một điều kiện đầu vào yêu cầu một giá trị xác định, một lớp tương đương đúng và hai lớp tương đương sai được xác định

-

Nếu một điều kiện đầu vào xác định một phần tử của một tập, một lớp tương đương đúng và một lớp tương đương sai được xác định.

-

Nếu một điều kiện đầu vào là một giá trị logic, một lớp tương đương đúng và một lớp tương đương sai được xác định

Ví dụ: xem xét dữ liệu được duy trì như là một phần của ứng dụng ngân hàng tự động. Người dùng có thể quay số tới ngân hàng sử dụng máy tính, cung cấp mật khẩu 6 kí tự và sau đó với một chuỗi các câu lệnh từ khóa bắt đầu các hàm banking đa dạng. Phần mềm được cung cấp cho ứng dụng ngân hàng chấp nhận dữ liệu theo các dạng sau: -

mã vùng: số trống hoặc 3 kí tự

-

Tiền tố: số 3 kí tự không bắt đầu bởi 0 và 1

-

Hậu tố: số 4 kí tự

-

Mật khẩu: gồm 6 kí tự

-

Câu lệnh: check, deposit, bill pay…

Điều kiện đầu vào kết hợp với mỗi phần tử dữ liệu cho ứng dụng ngân hàng có thể được xác định như là: -

mã vùng: điều kiện vào, boolean- mã vùng có thể có hay không được biểu diễn; điều kiện vào là miền, giá trị được xác định trong khoảng 200 đến 999 với các ngoại lệ xác định

-

Tiền tố: điều kiện vào, miền, giá trị >200 và không có số 0

-

Hậu tố: điều kiện vào, giá trị, dộ dài 4 kí tự số

-

Mật khẩu: điều kiện vào, boolean, mật khẩu có thể có hay không; điều kiện vào, giá trị, chuỗi 6 kí tự

-

Câu lệnh: điều kiện vào, tập, chứa các câu lệnh ghi chú ở trên

Áp dụng các chỉ dẫn trên cho việc thiết kế các lớp tương đương, các ca kiểm thử cho mỗi miền dữ liệu có thể được phát triển và thực thi. Các ca kiểm thử được lựa chọn cốt để số lượng lớn nhất các thuộc tính của một lớp tương đương được thực thi một lần. 5. Phân tích giá trị biên

Với những lí do không rõ ràng, một số lớn các lỗi có khuynh hướng xảy ra tại giá trị biên của miền dữ liệu vào hơn là các giá trị trung tâm. Vì lí do này, việc phân tích giá trị biên được phát triển như là một kĩ thuật kiểm thử. Việc phân tích giá trị biên dẫn đến sự lựa chọn một tập các ca kiểm thử thực thi các giá trị biên. Việc phân tích giá trị biên là kĩ thuật thiết kế các ca kiểm thử bổ sung cho phân hoạch tương đương. Đúng hơn là việc lựa chọn bất kì phần tử nào của một lớp tương đương BVA dẫn đến việc lựa chọn các ca kiểm thử tại “bờ” của lớp. Đúng hơn là chỉ tập trung vào các điều kiện đầu vào, VBA đưa ra các ca kiểm thử từ miền đầu ra Hướng dẫn sau cho BVA tương tự trong một số khía cạnh cho các hướng dẫn được đưa ra trong phân hoạch tương đương: -

Nếu một điều kiện đầu vào xác định một miền biên bởi giá trị a và b, các ca kiểm thử cần được thiết kế với giá trị của a và b, giá trị trên a và dưới b.

-

Nếu một điều kiện đầu vào xác định một số giá trị, các ca kiểm thử cần được thiết kế mà thực thi các số lớn nhất và nhở nhất. Các giá trị trên và dưới các giá trị nhở nhất và lớn nhất cũng được kiểm thử.

-

Hướng dẫn 1 và 2 được áp dụng cho các điều kiện đầu ra.. Chẳng hạn, giả sử rằng một bảng nhiệt độ và áp suất được yêu cầu như là một đầu ra từ chương trình phân tích kĩ nghệ.Các ca kiểm thử cần được thiết kế để tạo ra một báo cáo đầu ra mà đưa ra số tối đa (tối thiểu) cho phép của danh mục bảng.

-

Nếu một cấu trúc dữ liệu chương trình trong quy định giá trị biên ( chẳng hạn một mảng có một giới hạn xác định của 100 phần tử) có thể chắc chắn để thiết kế một tập các ca kiểm thử để thực thi cấu trúc dữ liệu tại giá trị biên của nó.

Hầu hết các kĩ sư phần mềm đều thực thi bằng trực giác một số cấp độ. Bằng việc áp dụng các hướng dẫn ở trên, việc kiểm thử biên có thể được hoàn thành nhiều hơn, do đó có thể có khả năng cao hơn trong việc phát hiện lỗi 6. Kiểm thử so sánh

Có một vài tình huống (chẳng hạn điện tử hàng không, điều khiển nhà máy điện hạt nhân) ở đó độ tin cậy phần mềm là tuyệt đối then chốt. Trong những ứng dụng như vậy, phần cứng và phần mềm cần thiết thường được tối thiểu hóa khả năng có lỗi. Khi mà các phần mềm cần thiết được phát triển, các nhóm kĩ nghệ phần mềm riêng rẽ phát triển những phiên bản độc lập của ứng dụng cùng các chi tiết kĩ thuật. Trong những tình huống như vậy, mỗi phiên bản có thể được kiểm thử với cùng dữ liệu kiểm thử để đảm bảo rằng tất cả cho ra những kết quả xác định. Sau đó tất cả các phiên bản được thực thi song song với việc so sánh các kết quả thời gian thực để đảm bảo sự nhất quán. Sử dụng những bài học đã học được từ các hệ thống cần thiết, các nhà nghiên cứu gợi ý rằng các phiên bản phần mềm độc lập cho những ứng dụng tới hạn. Thậm chí chỉ có phiên bản đơn được sử dụng trong hệ thống dựa trên máy tính được phân phát. Những phiên bản độc lập đó tạo thành nền tảng của kĩ thuật kiểm thử hộp đen được gọi là kiểm thử so sánh hay kiểm thử back - to – back. Khi các đa thực thi của cùng các chi tiết kĩ thuật được tạo ra, các ca kiểm thử được thiết kế sử dụng kĩ thuật kiểm thử hộp đen (chẳng hạn phân hoạch tương đương)

được đề nghị như là đầu vào cho mỗi phiên bản phần mềm. Nếu đầu ra của các phiên bản là giống nhau, ta thừa nhận rằng tất cả các thực thi là đúng. Nếu đầu ra là khác nhau, mỗi ứng dụng được điều tra để xác định xem là một khiếm khuyết trong một hay nhiều phiên bản là tương ứng với sự khác nhau đó. Trong hầu hết các trường hợp, việc so sánh đầu ra có thể được thực hiện bởi một công cụ tự động. Kiểm thử so sánh là rất rõ ràng. Nếu các chi tiết kĩ thuật từ tất cả các phiên bản được phát triển bị lỗi, tất cả các phiên bản sẽ hầu như phản chiếu lỗi. Thêm vào đó, nếu mỗi phiên bản độc lập sinh ra giống nhau nhưng không đúng, kết quản, kiểm thử điều kiện sẽ thất bại phát hiện ra lỗi.