Use example, design test case
Author: Belts
Concept and definition
Incomplete, it is not completely fatal defects for software testing, and any program can only perform a small amount and limited testing. Test cases are generated in this case, and it is also a software test systemized, engineered product. The design of test cases has always been the focus and difficulties of software testing.
What is test case?
A small amount of test data is carefully designed to achieve the best test effect or highly expose hidden mistakes, called test cases. We cannot perform exhaustion tests, in order to save time and resources, improve test efficiency, must be carefully selected from a large number of available test data to test data with representative or specialty test data.
What kind of use case is a good case?
A good test case is that it can discover unrecognized errors so far.
Benefits using test cases
Designing test cases before starting the test, you can avoid blind testing and improve test efficiency. The use of the test case is highlighted by the implementation of the software test, and the purpose is clear.
After the software version is updated, only a small number of test examples can expand the test work, reduce the work intensity, and shorten the project cycle.
The common and reuse of the function module makes the software easy to develop, and the generalization and reuse of the test cases relative to the function module will make the software test easy to carry, and the efficiency of the test case is constantly rising.
Design test case
u Black box test:
Equivalent classification method
Boundary value analysis
Error speculation
Caudity
u White box test:
Logical overlay
Basic path test method
Design process of test case
The test designer (analyzer) designs this stage test case based on test plans, design models and implementation models in different phases.
The test designer is a high-level test engineer with rich test experience or software analysis design capabilities. If there is no test designer, you can use the analyst designer instead.
For white boxes, there should be drivers and pile modules.
Determination of the test point
u ISO quality system:
In summary design or detailed design, you should clearly indicate the test points, indicators, and methods of each unit module.
u cmm quality system:
In the system's use case model, the priority and use case workflow of each use case model should be clearly indicated, each use case model is a test point, and each test requirement in the case model should have at least two test cases.
Understanding misunderstandings
The test case should be developed by the test designer or analytical designer, not an ordinary tester.
The test point should be established by the analysis designer and has nothing to do with the tester.
After the test work is expanded to the project, not the code development is completed.
Test objects are more than just source code, but also include demand analysis, demand specifications, summary design, profile design, detailed design, detailed design manual, and manuals.
Using the definition of an example
The use of an example is the process determined by describing the path flowing through the use case, which begins to end from the use case to the end traversing all of the basic streams and alternative flows.
Why is the introduction of a case scene
The current software is almost all controlled by the event, and the scene when the event triggered has formed a scene, while the same event different trigger order and processing result form an event stream. This idea of software design can also be introduced into software testing, vividly depicting the situation of event triggering, facilitating testing designer design test cases, while testing examples are more easier to understand and execute.
This kind of test thinking is Rational Company, which has a detailed explanation and application in the RUP2000 Chinese version, with an example scenario.
Active scenario
Each of the different paths through the following figure reflects the basic stream and alternative flow, and it is represented by an arrow. Basic flow direct black lines are represented by the easiest path to the use case. Each alternate stream begins with the basic stream, and the alternative flow will be executed under certain conditions. Alternative flows may re-join the basic stream (alternative flows 1 and 3), it is also possible to originate from another alternative stream (alternative stream 2), or terminate the use case without re-add a stream (alternative flow 2 and 4) Figure 1-1 Test case flow
Follow the possible paths performed in the above figure, you can determine a different case scene. Starting from the basic stream, combining basic flow and alternative streams, it can determine the following use case scene:
Scenario 1 basic flow
Scene 2 basic flow alternative flow 1
Scene 3 basic flow alternative flow 1 alternative stream 2
Scene 4 basic flow alternative flow 3
Scene 5 basic flow alternative flow 3 alternative flow 1
Scene 6 basic flow alternative flow 3 alternative flow 1 alternative stream 2
Scene 7 basic flow alternative stream 4
Scene 8 basic flow alternative flow 3 alternative stream 4
Note: For convenience, the scenes 5, 6, and 8 only describe the cyclic execution of alternative stream 3 indications.
The test case that generates each scene is done by determining a particular condition, which will result in execution of a particular example site.
Test case example
Assuming the use case described above for the alternative stream 3 is as follows:
"If the dollar input entered in the above step 2 'Enter the withdrawal amount" exceeds the current account balance, this event stream will appear. The system will display a warning message, then re-join the basic stream, then perform the above step 2' input The amount of the amount is ", the bank customer can enter new withdrawal amount."
According to this, it is possible to begin to determine how to use test cases that need to perform alternative stream 3:
Table 1-1 Test cases of alternative flow 3
Test case ID
Scenes
condition
expected results
TC X
Scenario 4
Step 2 - Withdrawal amount> Account balance
Re-join the basic stream at step 2
TC Y
Scenario 4
Step 2 - Withdrawal amount Do not perform alternative stream 3, perform basic flow TC Z Scenario 4 Step 2 - Withdrawal amount = Account balance Do not perform alternative stream 3, perform basic flow Note: Since there is no other information, the above-shown test cases are very simple. The test case is very simple. Below is an example of more conforming to the actual situation by the use case. Figure 1-2 Example The protagonist and use case of an ATM machine. The following table contains the basic streams of the above-drawn withdrawal case and some alternate streams: Table 1-2 withdrawal test case Basic stream The beginning of this use case is that the ATM is in ready state. Prepare withdrawal - Customer Inserts a bank card into the ATM card reader. Verify that the bank card -ATM machine reads the account code from the bank card's magnetic strip and checks if it belongs to the bank card that can be received. Enter PIN - ATM Require Customer Enter PIN Code (4 Bit) Verify Account Codes and PIN - Verify Account Codes and PIN to determine if the account is valid And the input PIN is correct for this account. For this event stream, the account is valid and the PIN is correct for this account. ATM Options -ATM Displays the various options available on this unit. In this event stream, bank customers usually choose "withdraws". Enter the amount - the amount you want to extract from the ATM. For this event stream, the customer needs to choose a preset amount ($ 10, $ 20, $ 50 or $ 100). Authorization -ATM activates the verification process by sending the card ID, PIN, the amount, and account information as a transaction to the banking system. For this event stream, the banking system is in a online state, and the authorization request is given, and the payment process is approved, and the account balance is updated accordingly. Banknotes - provide cash. Return to the bank card - bank card is returned. Receipt - Print the receipt and provide customers. ATM also updates internal records accordingly. At the end of the use case, the ATM returns to the ready state. Alternative stream 1 - bank card is invalid In the basic stream step 2 - Verify the bank card, if the card is invalid, the card is returned and the relevant message will be notified. Alternative stream 2 - ATM has no cash In the basic stream step 5 - ATM option, the option will not be used. If there is no cash within ATM, "withdraw money" Checkstream 3 - Insufficient cash in ATM In the basic stream step 6 - input amount, if the amount of the ATM machine is less than the amount of request extracted, a suitable message will be displayed, and the fundamental stream is re-added at step 6 - input amount. Selective 4 - PIN incorrect In the basic stream step 4 - verify the account and PIN, the customer has three opportunities to enter the PIN. If the PIN input is incorrect, the ATM will display the appropriate message; if there is also an input chance, this event stream is re-joined the basic stream at step 3 - Enter the PIN. If the last attempt is still an error, the card will be retained by the ATM machine while the ATM returns to the ready state, and this use case is terminated. Select stream 5 - account does not exist In the basic stream step 4 - Verify the account and PIN, if the code returned by the bank system indicates that the account is not found or prohibited from withdrawn from the account, ATM displays the appropriate message and step 9 - Return to the bank card to re-join Basic stream. Selecting a flow 6 - insufficient book amount In the basic stream step 7 - Authorization, the bank system return code indicates that the account balance is less than the amount input by the basic stream step 6 - input amount, then the ATM displays the appropriate message and re-enters the basic stream at step 6 - input. Selective 7 - reach the daily maximum withdrawal amount In the basic stream step 7-authorization, the code returned by the bank system indicates that the client has or will exceed the maximum amount that allows the extracted amount over 24 hours, then ATM displays the appropriate message and in step 6 - input The amount is re-added to the basic stream. Selective X - Record error If in the basic stream step 10 - receipt, the record cannot be updated, then ATM enters "security mode", and all functions will be suspended in this mode. At the same time, a proper alarm message to the banking system indicates that ATM has been suspended. Selecting y - quit Customers can terminate trading at any time (exit). The trading is terminated, the bank card is exited. Select stream Z - "Towy" ATM includes a large number of sensors to monitor various functions, such as power detectors, pressure detectors at different doors and entrances, and action detectors. At any time, if a sensor is activated, the alarm signal will be sent to the police and the ATM enters "security mode", and all functions are paused in this mode until appropriate reboot / reinitialization. In the first iteration, according to the iterative plan, we need to verify the use of funds has been implemented correctly. At this time, the entire use case has been implemented, only the following event stream is implemented: Basic Flow - Extract presets ($ 10, $ 20, $ 50, $ 100) Alternative stream 2 - ATM has no cash Alternative stream 3 - ATM insufficient cash Alternative stream 4 - PIN is incorrect Alternative stream 5 - account does not exist / account type incorrect Alternative stream 6 - insufficient book amount Generate the following scene from this use case Scenario 1 - successful withdrawal Basic stream Scene 2 - There is no cash basic stream in ATM Alternative stream 2 Scene 3 - Insufficient cash in ATM Basic stream Alternative stream 3 Scene 4 - PIN incorrect (also have input opportunities) Basic stream Alternative stream 4 Scene 5 - PIN incorrect (no more input opportunities) Basic stream Alternative stream 4 Scene 6 - Account does not exist / account type incorrect Basic stream Alternative stream 5 Scene 7 - Insufficient account balance Basic stream Alternative stream 6 Table 1-3 withdrawal scene Note: For convenience, alternative streams 3 and 6 (scenes 3 and 7) are not included in the table. Test cases are required for each scenario in these 7 scenes. You can use a matrix or decision form to determine and manage test cases. A general format is shown below, where each line represents each test case, and each column represents the information of the test case. In this example, for each test case, there is a test case ID, condition (or description), all data elements involved in the test example (as input or already existing in the database) and expected results. The matrix is constructed by starting the data element required to perform the execution usage scenarios. Then, for each scenario, at least the test case is to be determined to include the appropriate conditions required to perform the scene. For example, in the following matrix, V (valid) is used to indicate that this condition must be Valid to perform basic streams, and i (invalid) is used to indicate that the required current will be activated under this condition. "N / A" (not applicable) used in the table below indicates that this condition does not apply to test cases. Table 1-4 Table of the case matrix TC (test case) ID number Scenario / condition Pin account number Enter amount (or choose gold amount) Book Amount The amount in the ATM expected results CW1. Scenario 1 - successful withdrawal V V V V V Successful withdrawal. CW2. Scene 2 - There is no cash within ATM V V V V I Withdrawal options are not available, the use case ends CW3. Scene 3 - Insufficient cash in ATM V V V V I Warning message, return basic stream step 6 - input amount CW4. Scene 4 -PIN incorrect (more than one input chance) I V N / a V V Warning message, returning to basic stream step 4, type PIN CW5. Scene 4 -PIN incorrect (there is an opportunity to enter) I V N / a V V Warning message, returning to basic stream step 4, type PIN CW6. Scene 4 -PIN is incorrect (no more input opportunities) I V N / a V V Warning message, card is reserved, the use case ends In the above matrix, six test cases have implemented four scenes. For basic flow, the above test case CW1 is called a front test case. It has been performed along the basic stream path of the use case, and no deviation has occurred. The comprehensive test of the basic stream must include negative test cases to ensure that basic streams are performed only in the case of eligible conditions. These negative test examples are represented by CW2 to 6 (the shadow cell indicates that alternative flows are required under this condition). Although CW2 to 6 is negative test cases for basic flow, they are positive test cases relative to alternative streams 2 to 4. Moreover, there is at least one negative test case (CW1 - basic stream) for each of these alternative streams. Each scenario has only a positive test case and a negative test case, and the scene 4 is this example. To fully test the scene 4 - PIN incorrect, at least three frontal test cases (to activate scene 4): Enter the wrong PIN, but there is still an input opportunity, this optional flow re-joins the basic stream step 3 - Enter the PIN. Entered the wrong PIN, and no longer have input opportunities, this preparation stream will retain the bank card and terminate the use case. In the last input, "correct" PIN is entered. Alternative streams are re-incorporated in step 5 - input amount. Note: In the above matrix, there is no need to enter any actual value for conditions (data). One advantage of creating a test case matrix in this way is that it is easy to see what conditions are tested. Since only needs to view V and I (or the shadow cells used here), this method is also easy to determine if adequate test cases have been determined. From the above table, there are several conditions that do not have a shadow cell, indicating that the test case is not complete, such as scene 6 - The account / account type incorrectly and scene 7 - The account balance is lack of test cases. Once all test cases have been identified, these use cases should be reviewed and verified to ensure accurate and moderate, and eliminate excess or equivalent test cases. The test case can be determined, the actual data value (in the test case implementation matrix) can be determined and the test data is set. Table 1-5 Actual use case TC (test case) ID number Scenario / condition Pin account number Enter amount or Selected amount Book amount The amount in the ATM expected results CW1. Scenario 1 - successful withdrawal 4987 809 - 498 50.00 500.00 2,000 Successful withdrawal. account The balance is updated to 450.00 CW2. Scene 2 - There is no cash within ATM 4987 809 - 498 100.00 500.00 0.00 Withdrawal options are not available, the use case ends CW3. Scene 3 - Insufficient cash in ATM 4987 809 - 498 100.00 500.00 70.00 Warning message, return basic stream step 6-input amount CW4. Scene 4 - PIN incorrect (more than one input chance) 4978 809 - 498 N / a 500.00 2,000 Warning message, returning to basic stream step 4, type PIN CW5. Scene 4 - PIN is incorrect (there is an opportunity to enter) 4978 809 - 498 N / a 500.00 2,000 Warning message, returning to basic stream step 4, type PIN CW6. Scene 4 - PIN incorrect (no more input opportunities) 4978 809 - 498 N / a 500.00 2,000 Warning message, card is reserved, the use case ends The above test cases are only required to verify a part of test cases for verifying the usage example in this iteration. Other test examples required include: Scenario 6 - Account does not exist / account type incorrect: Did not find an account or account is not available Scenario 6 - Account does not exist / account type incorrect: Prohibition from this account Scene 7 - Account balance: The amount requested beyond the book amount In future iterations, when other event streams are implemented, test cases will be required in the following cases: An invalid card (the card is the lane, the card, non-adhered bank card, magnetic strip damage, etc.). Unable to read the card (card reader, offline, or malfunction). Account has been consumed, freezes or cannot be used due to other reasons. Insufficient cash in ATM or cannot provide the requested amount (unlike CW3, just a currency value in CW3, rather than all currency values). Unable to contact the banking system to obtain recognition. Bank networks are interrupted from the line or transaction process.
