3.3 Black box test techniques – Kỹ thuật hộp đen

Black Box test design and measurement techniques – Kỹ thuật thiết kế test và đo lường hộp đen

3.3.1 Equivalence partitioning (EP) – Phân vùng tương đương (EP)

• Divide (partition) the inputs, outputs, etc. into areas which are expected to exhibit similar behavior (equivalent) so they are likely to be processed in the same way. – Chia các vùng dựa vào đầu vào, đầu ra, vv thành các khu vực mà kết quả mong đợi là giống nhau(tương đương) vì thế chúng được xử lý theo 1 cách giống nhau
• Assumption: if one value works, all will work – Giả định: nếu một trong những giá trị làm đúng, tất cả các giá trị bên trong vùng đó sẽ làm đúng
• One from each partition better than all from one – Lấy một TH từ mỗi phân vùng tốt hơn so với lấy tất cả các TH
• Tests can be designed to cover all valid and invalid partitions. Equivalence partitioning is applicable at all levels of testing. – Test case được thiết kế để bao phủ tất cả các TH valid và invalid. EP được áp dụng ở tất cả các level test

3.3.2 Boundary value analysis (BVA)- Phân tích giá trị biên (BVA)

• Behavior at the edge of each equivalence partition is more likely to be incorrect than behavior within the partition, so boundaries are an area where testing is likely to yield defects – Lỗi có xu hướng ẩn nấp gần ranh giới
• The maximum and minimum values of a partition are its boundary values – Giá trị lớn nhất và nhỏ nhất trong 1 phân vùng là giá trị biên
• Tests can be designed to cover both valid and invalid boundary val – Test được thiết kế để cover các giá trih biên valid và invalid
• Boundary value analysis can be applied at all test levels. It is relatively easy to apply and its defect- finding capability is high. – Phân tích giá trị biên được áp dụng ở tất cả các level test. Nó khá dễ dàng áp dụng để tìm ra lỗi.
• Detailed specifications are helpful in determining the interesting boundaries. – Đặc tả chi tiết sẽ giúp cho xác định được các giá trị biên này

 

3.3 Specification-based or Black-box Techniques (K3)

3.3.3 Decision tables – bảng quyết định

• Explore combinations of inputs, situations or events

Khám phá sự kết hợp của các yếu tố đầu vào, tình huống hoặc sự kiện

• It is very easy to overlook specific combinations of input

Rất dễ dàng để bỏ qua sự kết hợp cụ thể của đầu vào

• Start by expressing the input conditions of interest so that they are TRUE or FALSE

Bắt đầu bằng cách diễn đạt các điều kiện đầu vào để họ có TRUE hoặc FALSE

Example: Student access – Phân quyền sinh viên

An university computer system allows students an allocation of disc space depending on their projects. – Một hệ thống máy tính của trường đại học cho phép sinh viên phân bổ không gian đĩa phụ thuộc vào các dự án của họ.

If they have used all their allotted space, they are only allowed restricted access, i.e. to delete files, not to create them. This is assuming they have logged on with a valid username and password. – Nếu họ đã sử dụng tất cả các không gian được phân bổ của họ, họ chỉ được phép truy cập hạn chế, tức là để xóa các tập tin, không được tạo ra chúng. Đây là giả định họ đã đăng nhập với tên người dùng và mật khẩu hợp lệ.

Extending decision tables – Mở rộng của bảng ra quyết định

• Entries can be more than just ‘true’ or ‘false’ – Giá trị nhập vào có thể có nhiều hơn chỉ là ‘đúng’ hay ‘sai’
  • Completing table needs to be done carefully – Hoàn thành bảng cần phải được thực hiện một cách cẩn thận
  • Rationalizing becomes more important – Hợp lý hoá trở nên quan trọng hơn

3.3.4 State transition testing – Test chuyển đổi trạng thái

• A system may exhibit a different response depending on current conditions or previous history (its state)
• Một hệ thống có thể biểu hiện một phản ứng khác nhau tùy thuộc vào điều kiện hiện tại hoặc tiền sử
• It allow the tester to view the software in terms of its states, transitions between states, the inputs or events that trigger state changes (transitions) and the states and inputs, and can highlight possible transitions that are invalid.
• Nó cho phép test để xem các phần mềm về trạng thái của nó, chuyển đổi giữa các trạng thái, các yếu tố đầu vào hoặc sự việc gây ra những thay đổi trạng thái (chuyển tiếp) và các lệnh và các đầu vào, và có thể làm nổi bật quá trình chuyển đổi hoặc có thể là không hợp lệ.
• Example: State diagram for PIN entry – Ví dụ: sơ đồ nhà nước cho nhập PIN

Switch:

• 0-Switch: single transition
• 1-Switch: couple transitions
• 2- Switch: triple transitions

A state transition model has four basic parts – Một mô hình chuyển trạng thái có bốn phần cơ bản::

• The states that the software may occupy (open/ closed or funded/ insufficient funds) – Các trạng thái mà phần mềm có thể thực hiện (mở / đóng cửa hoặc rút tiền / không đủ tiền)
• The transitions from one state to another (not all transitions are allowed) – Việc chuyển đổi từ một trạng thái khác (không phải tất cả các quá trình chuyển đổi được cho phép)
• The events that cause a transition ( closing a file or withdrawing money) – Các sự kiện đã gây ra một quá trình chuyển đổi (đóng một tập tin hoặc rút tiền)
• The actions that result from a transition ( an error message or being giving your cash) – Các hành động đó là kết quả của một quá trình chuyển đổi (một thông báo lỗi hoặc trả tiền cho bạn)

Note: One event can cause only one action, but that the same event – from a different state – may cause a different action and a different end state. – Lưu ý: 3Một sự kiện có thể gây ra chỉ có một hành động, nhưng là cùng một sự kiện – từ một trạng thái khác nhau – có thể gây ra một hành động khác nhau và một trạng thái kết thúc khác nhau.

• Test can be designed to cover a typical sequence of states, to cover every state, to exercise every transitions, to exercise specific sequences of transitions or to test invalid transitions – Test có thể được thiết kế để bao gồm một trình tự đặc trưng của các trạng thái, bao quát mọi giao dịch, thực hiện mỗi chuyển tiếp, để thực hiện trình tự cụ thể của quá trình chuyển đổi hoặc để kiểm tra quá trình chuyển đổi không hợp lệ
• When designing test case, we should start with a typical scenario (a normal situation) then increase the coverage (every states/ every transitions) – Khi thiết kế trường hợp thử nghiệm, chúng ta nên bắt đầu với một kịch bản điển hình (một tình huống bình thường) sau đó tăng vùng phủ sóng (mỗi trạng thái / mỗi chuyển tiếp)
• One of the advantages of the state transition technique is that the model can be as detailed or as abstract as you need it to be. – Một trong những ưu điểm của kỹ thuật chuyển đổi trạng thái là mô hình có thể được chi tiết hoặc là trừu tượng như bạn cần nó làm.
• State transition testing is much used within the embedded software industry and technical automation in general – Thử nghiệm chuyển đổi trạng thái được sử dụng nhiều trong các ngành công nghiệp phần mềm nhúng và tự động hóa kỹ thuật nói chung.
• However, the technique is also suitable for modeling a business object having specific states or testing screen-dialog flows – Tuy nhiên, kỹ thuật này cũng là phù hợp với mô hình một đối tượng kinh doanh có các trạng thái cụ thể hoặc thử nghiệm các dòng màn hình-thoại

States table – Bảng trạng thái

In order to see the total number of combinations of states and transitions, both valid and invalid, a state table can be used. – Để xem tổng số kết hợp của trạng thái và quá trình chuyển đổi, hợp lệ và không hợp lệ, một bảng trạng thái có thể được sử dụng.

The table lists all the states down one side of the table and all the events that cause transitions along the top. Each cell then represents a state-event pair. The content of each cell indicates which state the system will move to. – Bảng liệt kê tất cả các trạng thái xuống một bên của bảng và tất cả các sự kiện gây ra quá trình chuyển đổi ở đầu trang. Mỗi ô sau đó đại diện cho một cặp trạng thái-sự kiện. Các nội dung của mỗi ô chỉ ra trạng thái hệ thống sẽ chuyển sang

3.3.5 Use case testing- Trường hợp sử dụng

• Use case testing is a technique that helps us identify test cases that exercise the whole system on a transaction by transaction basis from start to finish

Sử dụng các trường hợp thử nghiệm là một kỹ thuật giúp chúng ta xác định các trường hợp kiểm tra quyền thực hiện toàn bộ hệ thống trên cơ sở của giao dịch từ đầu đến cuối

• Use cases are a sequence of steps that describe the interactions between the actor (system or user) and the system

Sử dụng các trường hợp là một chuỗi các bước mô tả sự tương tác giữa các đối tượng sử dụng (hệ thống hay người dùng) và hệ thống

• Use cases may be described at the abstract level (business use case, technology-free, business process level) or at the system level (system use case on the system functionality level)

Sử dụng các trường hợp có thể được mô tả ở mức độ trừu tượng (trường hợp sử dụng kinh doanh, công nghệ miễn phí, mức độ quá trình kinh doanh) hoặc ở cấp độ hệ thống ( trường hợp sử dụng ở cấp độ hệ thống chức năng)

• Each use case has preconditions which need to be met for a use case to work successfully

Mỗi trường hợp sử dụng có điều kiện tiên quyết mà cần phải được đáp ứng cho một trường hợp sử dụng để làm việc thành công

• Each use case terminates with post conditions which are the observable results and final state of the system after the use case has been completed.

Mỗi trường hợp sử dụng chấm dứt với điều kiện trước đó là những kết quả quan sát được và trạng thái cuối cùng của hệ thống sau khi các trường hợp sử dụng đã được hoàn thành.

• Each use case usually has a mainstream (or most likely) scenario and alternative paths.

Mỗi trường hợp sử dụng thường có (hoặc có thể) kịch bản chính và đường dẫn thay thế.

• Use cases describe the “process flows” through a system based on its actual likely use, so the test case derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system

Sử dụng các trường hợp mô tả quá trình “chảy” qua một hệ thống dựa trên khả năng sử dụng thực tế của nó, vì vậy các trường hợp thử nghiệm xuất phát từ trường hợp sử dụng hữu ích nhất trong việc phát hiện các khiếm khuyết trong quá trình chạy qua khi sử dụng thực tế của hệ thống

• Use case testing also helps uncover integration defects caused by interaction and interference of different components, which individual component testing would not see

Sử dụng các trường hợp thử nghiệm cũng giúp các khuyết tật hội nhập việc khám phá ra có vỏ bằng cách tương tác và giao thoa của các thành phần khác nhau, trong đó kiểm tra thành phần cá nhân sẽ không nhìn thấy

• Designing test cases from use cases may be combined with other specification-based techniques

Thiết kế trường hợp thử nghiệm từ trường hợp sử dụng có thể được kết hợp với các kỹ thuật dựa trên đặc điểm khác.

Example:

The below example explains the way to build a test case from Cash Withdrawal use case. Cash Withdraw is a function of ATM (Auto Teller Machine)

Basic Flow	This Use Case begins with the ATM in the Ready State. Initiate Withdraw – Customer inserts bank card in the card reader on the ATM machine Verify Bank Card – The ATM reads the account code from the magnetic strip on the bank card and checks if it is an acceptable bank card. Enter PIN – The ATM asks for the customer’s PIN code (4 digits) Verify account code and PIN – The account code and PIN are verified to determine if the account is valid and if the PIN entered is the correct PIN for the account. For this flow, the account is a valid account and the PIN is the correct PIN associated with this account. ATM Options – The ATM displays the different alternatives available at this ATM.  In this flow, the bank customer always selects “Cash Withdraw.” Enter Amount – The ATM the amount to withdraw. For this flow the customer selects a pre-set amount ($10, $20, $50, or $100). Authorization – The ATM initiates the verification process with the Banking System by sending the Card ID, PIN, Amount, and Account information as a transaction.  For this flow, the Banking System is online and replies with the authorization to complete the cash withdrawal successfully and updates the account balance accordingly. Dispense – The Money is dispensed. Return Card – The Bank Card is returned. Receipt – The receipt is printed and dispensed.  The ATM                                                                           also updates the internal log accordingly. Use Case ends with the ATM in the Ready State.
Alternate Flow 1 – Not a valid Card	In Basic Flow Step 2 – Verify Bank Card, if the card is not valid, it is ejected with an appropriate message.
Alternate Flow 2 – ATM out of Money	At Basic Flow Step 5 – ATM Options, if the ATM is out of money, the “Cash Withdraw” option will not be available.
Alternate Flow 3 – Insufficient funds in ATM	At Basic Flow Step 6 – Enter Amount, if the ATM contains insufficient funds to dispense the requested amount, an appropriate message will be displayed, and rejoins the basic flow at Step 6 – Enter Amount.
Alternate Flow 4 – Incorrect PIN	At Basic Flow Step 4 – Verify Account and PIN, the customer has three tries to enter the correct PIN. If an incorrect PIN is entered, the ATM displays the appropriate message and if there are still tries remaining, this flow rejoins Basic Flow at Step 3 – Enter PIN. If, on the final try the entered PIN number is incorrect, the card is retained, ATM returns to Ready State, and this use case terminates.
Alternate Flow 5 – No Account	At Basic Flow Step 4 – Verify Account and PIN, if the Banking system returns a code indicating the account could not be found or is not an account which allows withdrawals, the ATM displays the appropriate message and rejoins the Basic Flow at Step 9 – Return Card.
Alternate Flow 6 – Insufficient Funds in Account	At Basic Flow Step 7 – Authorization, the Banking system returns a code indicating the account balance is less than the amount entered in Basic Flow Step 6 – Enter Amount, the ATM displays the appropriate message and rejoins the Basic Flow at Step 6 – Enter Amount.
Alternate Flow 7 – Daily maximum withdrawal amount reached	At Basic Flow Step 6 – Authorization, the Banking system returns a code indicating that, including this request for withdrawal, the customer has or will have exceeded the maximum amount allowed in a 24 hour period, the ATM displays the appropriate message and rejoins the Basic Flow at Step 6 – Enter Amount.
Alternate Flow x – Log Error	If at the Basic Flow Step 10 – Receipt, the log cannot be updated, the ATM enters the “secure mode” in which all functions are suspended. An appropriate alarm is sent to the Bank System to indicate the ATM has suspended operation.
Alternate Flow y – Quit	The customer can, at any time, decide to terminate the transaction (quit). The transaction is stopped and the card ejected.
Alternate Flow z – “Tilt”	The ATM contains numerous sensors, which monitor different functions, such as power, pressure, exerted on the various doors and gates, and motion detectors.  If at any time a sensor is activated, an alarm signal is sent to the Police and the ATM enters a “secure mode” in which all functions are suspended until the appropriate re-start / re-initialize actions are taken.
In the first iteration, according to the iteration plan, we need to verify that the Cash Withdrawal use case has been implemented correctly. The whole use case has not yet been implemented, only the following flows have been implemented: Basic Flow – Withdrawal of a pre-set amount ($10, $20, $50, $100) Alternate Flow 2 – ATM out of Money Alternate Flow 3 – Insufficient funds in ATM Alternate Flow 4 – Incorrect PIN Alternate Flow 5 – No Account / Incorrect Account Type Alternate Flow 6 – Insufficient funds in Account

In the table below, “n/a” indicates that this condition is not applicable to the test case.

TC ID#	Scenario / Condition	PIN	Account #	Amount Entered	Amount in Account	Amount in ATM	Expected Result
CW1.	Scenario 1 – Successful Cash Withdraw	V	V	V	V	V	Successful cash withdrawal.
CW2.	Scenario 2 – ATM out of Money	V	V	V	V	I	Cash Withdraw option unavailable, end of use case
CW3.	Scenario 3 – Insufficient funds in ATM	V	V	V	V	I	Warning message, return to Basic Flow Step 6 – Enter Amount
CW4.	Scenario 4 – Incorrect PIN (> 1 left)	I	V	N/a	V	V	Warning message, return to Basic Flow Step 4, Enter PIN
CW5.	Scenario 4 – Incorrect PIN (= 1 try left)	I	V	N/a	V	V	Warning message, return to Basic Flow Step 4, Enter PIN
CW6.	Scenario 4 – Incorrect PIN (= 0 tries left)	I	V	N/a	V	V	Warning message, card retained, end of use case

 

Upon approval of the test cases, the actual data values can be identified (in the test case implementation matrix) and the test data built.

TC ID#	Scenario / Condition	PIN	Account #	Amount Entered	Amount in Account	Amount in ATM	Expected Result
CW1.	Scenario 1 – Successful Cash Withdraw	4987	809 – 498	50.00	500.00	2,000	Successful cash withdrawal. Account balance updated to 450.00
CW2.	Scenario 2 – ATM out of Money	4987	809 – 498	100.00	500.00	0.00	Cash Withdraw option unavailable, end of use case
CW3.	Scenario 3 – Insufficient funds in ATM	4987	809 – 498	100.00	500.00	70.00	Warning message, return to Basic Flow Step 6 – Enter Amount
CW4.	Scenario 4 – Incorrect PIN (> 1 left)	4978	809 – 498	N/a	500.00	2,000	Warning message, return to Basic Flow Step 4, Enter PIN
CW5.	Scenario 4 – Incorrect PIN (= 1 try left)	4978	809 – 498	N/a	500.00	2,000	Warning message, return to Basic Flow Step 4, Enter PIN
CW6.	Scenario 4 – Incorrect PIN (= 0 tries left)	4978	809 – 498	N/a	500.00	2,000	Warning message, card retained, end of use case

 

3.4  While Box test design

3.4.1 While Box test design and measurement techniques – Kỹ thuật thiết kế test case và độ bao phủ Hộp trắng

• Structure-based techniques serve two purposes: test coverage measurement and structural test case design.- Kỹ thuật dựa trên kết cấu phục vụ hai mục đích: đo độ bao phủ của thử nghiệm và thiết kế trường hợp thử nghiệm theo cấu trúc
• Structure-based test design techniques are a good way of generating additional test cases that are different from existing test to ensure all parts of software are exercised (point of view of the items being covered) – Kỹ thuật thiết kế kiểm tra dựa trên cấu trúc là một cách tốt để tạo ra các trường hợp thử nghiệm bổ sung để đảm bảo tất cả các phần của phần mềm đều được thực hiện test.

3.4.2 The Test coverage – Độ bao phủ test

• The basic coverage measure is: tested items divide total items

Tested coverage = Số TC (pass, fail)/ Tổng số TC

Tested successful coverage = Số TC pass/ Tổng số TC test – N/A

Statements coverage = Số dòng code được test đến/ tổng số dòng code trong software

• Coverage item: whatever we have been able to count and see whether a test has exercised or used this item – Yếu tố được bao phủ: bất cứ điều gì chúng ta đã có thể đếm và xem xem liệu một thử nghiệm đã thực hiện hay kiểm tra đến item này hay chưa

 

3.4.3 Statement coverage – Độ bao phủ dòng lệnh

• Percentage of executable statements exercised by a test suite – Phần tram sô dòng code được thực hiện kiểm tra bởi 1 bộ test
  • Formula = number of statements exercised / Total number of statements
• Example:
  • Program has 100 statements
  • Test exercise 87 statements
  • Statement coverage =87%
• Statement coverage is normally measured by a software tool. – Độ bao phủ code thường được đo bằng một công cụ phần mềm.
• Typical ad hoc testing achieves 60-75% – Thông thường các dự án chỉ đạt được 60- 75%

Example of statement coverage

Read (a)

If a>6 then

A=b

endif

We need only 1 test case a=7 to have 100% statement coverage

3.4.4 Decision coverage (Branch coverage) – Độ bao phủ của quyết định

• Percentage of decision outcomes exercised by a test suite – Tỷ lệ các kết quả quyết định được thực hiện bởi một bộ kiểm tra

Formula = number of decisions outcomes exercised / total number of decision outcomes

• Typical ad hoc testing achieves 40- 60% – Tỷ lệ thông thường 40-60%
• Decision testing is a form of control flow testing
• 100% decision coverage => 100% statement coverage

3.4.5 Path coverage- Độ bao phủ đường dẫn

 

 

3.5 Experience_base techniques (K2)

• Experience-based testing is where tests are derived from the tester’s skill and intuition and their experience with similar applications and technologies. – Test dựa trên kinh nghiệm để dẫn ra các test dựa vào kỹ năng, trực giác và kinh nghiệm của tester với các ứng dụng và kỹ thuật tương tự.
• These techniques can be useful in identifying special tests not easily captured by formal techniques – Kỹ thuật này rất hữu ích để xác định các test case đặc biệt mà ko dễ tạo đc bởi kỹ thuật chính thức
• Can find some faults that systematic techniques can miss – Có thể tìm thấy một số lỗi kỹ thuật mà hệ thống có thể bỏ lỡ
• Supplements systematic techniques – Bổ sung các kỹ thuật có hệ thống
• After systematic techniques have been used – Sau khi có hệ thống kỹ thuật đã được sử dụng
• Not a good approach to start testing with – Không phải là một phương pháp tốt khi mới bắt đầu test
• Degrees of effectiveness depending on the testers’ experience.- Mức độ hiệu quả phụ thuộc vào kinh nghiệm của tester

3.5.1 Exploratory testing – Test khám phá

 

• Exploratory testing is concurrent test design, test execution, test logging and learning, based on a test charter containing test objectives, and carried out within time-boxes. – Khám phá cùng lúc trong giai đoạn test design, test execution, test log, và học hỏi dựa vào điều kiện kiểm tra chứa mục tiêu test và được đưa ra trong 1 khung thời gian
• It is an approach that is most useful where there are few or inadequate specifications and severe time pressure, or in order to augment or complement other, more formal testing. – Là 1 hướng tiếp cận rất hữu ích nếu tài liệu quá ít hoặc ko đầy đủ, áp lực thời gian và hoàn thiện cho các kỹ thuật chính thức khác
• It can serve as a check on the test process, to help ensure that the most serious defects are found.- Giúp cho việc kiểm tra các nghiệp vụ test và để chắc chắn là hầu hết các lỗi nghiêm trọng đã được tìm thấy

3.5.2 Error guessing – Dự đoán lỗi còn gọi là fault attack

• Non-systematic test techniques – Kỹ thuật kiểm tra không có hệ thống
• Deriving test cases that attack Past failures – Dự đoán lỗi dựa vào các lỗi cũ để dẫn ra test case
• These defect and failure lists can be built based on experience, available defect and failure data, and from common knowledge about why software fails. – Danh sách các lỗi và thất bại có thể được đưa ra dựa vào kinh nghiệm, các lỗi đã có, dữ liệu failure và từ những hiểu biết chung về tại sao PM bị lỗi

Summary: Key Points

• Test techniques are ‘best practice’: help to find faults – Kỹ thuật test là “thực hành tốt nhất”: giúp để tìm lỗi
• Black box techniques are based on behavior – Kỹ thuật hộp đen được dựa trên hành vi
• White box techniques are based on structure – Kỹ thuật hộp trắng được dựa trên cấu trúc
• Error guessing supplements systematic techniques – Lỗi đoán bổ sung các kỹ thuật hệ thống