Black box test

• Black-Box Testing (Black-box testing, also known as functional testing or data-driven testing) is the test object as a black box. When using the Black box test method for dynamic testing, it is necessary to test the function of the SOFTWARE product without testing the internal structure and process of the SOFTWARE PRODUCT.
  
  The methods of designing test cases using black box technology are: Equivalence class division, boundary value analysis, error inference, causality diagram and comprehensive strategy.
  
  Black-Box testing focuses on the functional requirements of testing software, or black-box testing, which enables software engineers to derive input criteria for all functional requirements of the program. Black-Box testing is not a substitute for white-box testing, but is used to assist white-box testing to find other types of errors.
  
  The black box test attempts to discover the following types of errors:
  
  1) function error or omission;
  2) interface error;
  3) data structure or external database access error;
  4) Performance error;
  5) initialization and termination errors.
  
  Test case design method of black box test
  
  • Equivalence class Partitioning method
  • Boundary value Analysis method
  • Error-guessing methods
  • Causality Diagram method
  • Decision table Driven analysis method
  • Orthogonal experimental Design method
  • Function Diagram Analysis method
  
  Equivalence class Partitioning:
  
  is to divide all possible input data, that is, the input fields of the program into sections (subsets), and then select a few representative data from each subset as test cases. This method is an important and common black box test case design method.
  
  1) Division equivalence class: An equivalence class is a subset of an input field. In this sub-collection, each input data is equivalent to an error in the disclosure program. and reasonably assume that the test of the representative value of an equivalence class is equal to the other value of this class. Therefore, all the input data can be reasonably divided into some equivalence classes, In each equivalence class to take a data as the test input criteria, you can use a small number of representative test data. Good test results are obtained. Equivalence class partitioning can have two different situations: valid equivalence class and invalid equivalence class.
  
  Valid equivalence class: Refers to a set of meaningful input data that is reasonable for the specification of the program. The effective equivalence class can be used to verify whether the program implements the functions and performance specified in the specification.
  
  Invalid equivalence class: the definition of a valid equivalence class happens to be the opposite.
  
  When designing test cases, consider both of these equivalence classes. Because the software is not only able to receive reasonable data, but also to withstand the unexpected test. Such tests ensure that the software is more reliable.
  
  2) methods of dividing equivalence classes: The following gives six principles for determining equivalence classes.
  
  ① a valid equivalence class and two invalid equivalence classes can be established if the input condition specifies the range of values or the number of values.
  
  ② a valid equivalence class and an invalid equivalence class can be established if the input condition specifies a set of input values or a condition that specifies "what must be".
  
  ③ a valid equivalence class and an invalid equivalence class can be determined in the case where the input condition is a Boolean quantity.
  
  ④ establishes a set of values for the input data (assuming n), and the program has to handle each input value separately, it can establish n valid equivalence class and an invalid equivalence class.
  
  ⑤ a valid equivalence class (conforming to a rule) and several invalid equivalence classes (violating rules from different angles) can be established in the case of rules that must be followed by the input data.
  
  ⑥ the equivalence class is divided into smaller equivalence classes, the equivalent classes should be further subdivided in the case that the elements in the program process are different in the known equivalence class.
  
  3) Design The test case: After the equivalence class is established, an equivalence class table can be established, listing all the classified equivalence classes:
  
  Invalid equivalence class for valid equivalence class of input condition
  
  ... ... ...
  
  ... ... ...
  
  The test cases are then designed from the divided equivalence class according to the following three principles:
  
  ① provides a unique number for each equivalence class.
  
  ② Design a new test case to overwrite as much of the valid equivalence class as it has yet to be overwritten, repeating this step. Until all valid equivalence classes are overwritten.
  
  ③ Design a new test case to overwrite only one invalid equivalence class that has not yet been overwritten, repeating this step. Until all invalid equivalence classes are overwritten.
  
  Boundary Value Analysis method
  
  The boundary value analysis method complements the equivalence class partitioning method.
  
  (1) Consideration of boundary value analysis method:
  
  Long-term testing experience tells us that a large number of errors occur on the boundary of the input or output range, rather than on the inside of the input and output range. Therefore, to design test cases for various boundary conditions, more errors can be detected.
  
  Using the Boundary value analysis method to design the test case, the boundary condition should be determined first. The boundary of the input and output equivalence classes is usually the boundary of the test. You should choose a value that is exactly equal to, just above or below the boundary as the test data, rather than selecting a typical value or any value from the equivalent class as the test data.
  
  (2) The principle of selecting test cases based on the boundary value analysis method:
  
  1) If the input condition specifies the range of values, then the value of the boundary that has just reached this range should be taken, as well as the value just beyond the bounds of this range as the test input data.
  
  2) If the input conditions specify the number of values, then the maximum number, the minimum number, less than the minimum number of one, than the maximum number of Taichi as the test data.
  
  3) According to each output condition of the specification, use the preceding principle 1).
  
  4) According to each output condition of the specification, apply the preceding principle 2).
  
  5) If the program's specification indicates that the input field or output field is an ordered set, then the first and last element of the collection should be selected as the test case.
  
  6) If an internal data structure is used in the program, the value on the boundary of the internal data structure should be selected as the test case.
  
  7) Analyze specifications and identify other possible boundary conditions.
  
  Error-guessing method
  
  Error-Guessing method: A method of designing test cases based on experience and intuition to speculate on all possible errors in the program.
  
  The basic idea of the error-guessing method is to enumerate all possible errors in the program and special cases prone to errors, according to which they choose test cases. For example, many of the errors that were common in the module were listed during unit testing. Previous product testing has found errors, etc., these are the summary of experience. Also, the input data and output data are 0 cases. The input table is a space or the input table has only one row. These are all situations that are prone to errors. Examples of these cases can be selected as test cases.
  
  Causality Diagram method
  
  The equivalence class partitioning method and boundary value analysis method described above are focused on the input conditions, but the relation between the input conditions is not considered, and the combination of each other. Considering the combination of input criteria, some new situations may arise. But it is not easy to check the combination of the input criteria, even if all the input conditions are divided into equivalent classes, the combination of them is quite a lot. It is therefore important to consider designing test cases in a form that is suitable for describing a combination of conditions and generating multiple actions accordingly. This requires the use of causality diagrams (logical models).
  
  The final result of the causality diagram method is the decision table. It is suitable for checking the various combinations of program input conditions.
  
  The basic steps for generating test cases using causality diagrams:
  
  (1) Analysis software Specification Description, those are the reason (that is, the input condition or the equivalence class of the input condition), those are the results (that is, the output condition), and give each cause and result assigned an identifier.
  
  (2) Analyze the semantics in the description of the software specification. Identify the relationship between the cause and the result, the reason and the reason. According to these relationships, draw a causal diagram.
  
  (3) Due to grammatical or environmental constraints, there are some reasons and reasons, the combination of cause and result is not impossible to appear. In order to show these special cases, some marks are used to indicate constraints or constraints on the causal diagram.
  
  (4) Convert the causality diagram into a decision table.
  
  (5) Each column of the decision table is taken out as the basis for the design of test cases.
  
  The test cases (local, combined relationships) generated from the causality diagram include the fact that all input data is true and false, and the number of test cases is minimized, and the number of test cases increases linearly with the number of input data.
  
  The decision table is already used in the preceding causality diagram method. The decision table (decision table) is a tool for analyzing and expressing different operations under multiple logic conditions. In the early stages of the development of programming, The decision table has been used as a tool for writing programs. Because it can express the complex logic relation and the condition of the combination of the various conditions is both concrete and definite.
  
  A decision table is usually made up of four parts.
  
  Conditional pile (Condition Stub): Lists all the conditions for the problem. The order of the listed conditions is generally considered to be irrelevant.
  
  Action stub: Lists the actions that may be taken by the problem rule. The order of these operations is not constrained.
  
  Condition Item (Condition Entry): Lists the values that are for its left column condition. The true and false values in all possible cases.
  
  Action Item (Action Entry): Lists the actions that should be taken in case of various values of the condition item.
  
  Rule: The specific value of any combination of conditions and the corresponding action to be taken. A column that runs through the condition and action items in a decision table is a rule. Obviously, how many sets of criteria are listed in the decision table, and how many rules are there, and how many columns are there for both conditional and action items.
  
  Steps to establish the decision table: (according to the software specification)
  
  ① determines the number of rules. If there are n conditions. Each condition has two values (0,1), so there is a rule.
  
  ② Lists all the condition piles and action piles.
  
  ③ fill in the condition.
  
  ④ fill in the action item. Wait until the initial decision table.
  
  ⑤ simplification. Merge similar rules (same action).
  
  B. Beizer points out the criteria for designing test cases with a decision table:
  
  The ① specification is given in the form of a decision table or easily converted into a decision table.
  
  The order of ② conditions does not and does not affect which operations are performed.
  
  The order of ③ rules does not and does not affect which operations are performed.
  
  ④ you do not have to test other rules whenever the conditions of a rule have been met and the action you want to perform is determined.
  
  ⑤ If a rule is satisfied to perform multiple operations, the order of execution of these operations does not matter.
  
  Advantages of black Box testing
  
  1. Basically does not have the personnel management, if the program stops running normally is the test procedure crash
  2. After the design of the test example, the work is cool, of course, the more depressed is to determine the cause of crash
  
  Disadvantages of black Box testing
  
  1. The result depends on the design of the test example, the design part of the test example comes from experience, OUSPG is worth learning
  2. There is no concept of a state transition, and some of the successful examples are mostly for PDUs, and there is no state transition for the program being tested.
  3. In the absence of a State concept test, it is troublesome to find and determine the test case that caused the program crash, and it is necessary to confirm the possible test cases in the surrounding area separately. In the case of stateful testing, it is even more troublesome, especially if it is not a single testcase problem. These are more prominent in the heap problem.
  
  
  Selection of black box test (functional test) tools
  
  So, how do you perform functional testing efficiently? Choosing a suitable functional testing tool and training a highly qualified tool to use the team is undoubtedly essential. Although there are a few software service companies that do not use any functional testing tools, they engage in functional testing outsourcing projects. In the short term, this kind of enterprise profitability is fair, but for a long time, they are likely to be replaced by highly automated software services companies.
  
  Currently, there are many tools for functional testing, and tools for different architectures are constantly evolving. One of the more typical automated testing tools, the Mercury Company's WinRunner, is highlighted here.
  
  WinRunner is an enterprise-class software functional testing tool for verifying that an application can run as expected. By automatically capturing, detecting, and simulating user interactions, WinRunner can identify the vast majority of software functional flaws, ensuring that applications that span multiple function points and databases are released with minimal functional failure.
  
  WinRunner is characterized by: compared with the traditional manual test, it can complete the function point test quickly and in batches; The same action can be performed for the same test script, thus eliminating the error of comprehension caused by the manual test; In addition, it can perform the same action repeatedly, the most boring part of the test work can be done by the machine; It supports the program style test script, a high-quality test engineer can use it to complete the process of extremely complex testing, by using wildcards, macros, conditional statements, loop statements, etc., but also better to complete the test script reuse; It provides a better integration and support environment for most programming languages and Windows technologies, which facilitates the implementation of functional testing for Windows platform-based applications.
  
  The WinRunner workflow can be broadly divided into the following six steps:
  
  1. Application-Aware GUI
  
  In WinRunner, we can use GUI spy to identify various GUI objects, and after recognition, WinRunner will store them in the GUI Map file. It provides two GUI map file modes: Global GUI map file and GUI map file per Test. The biggest difference is that the latter for each test script produced a GUI file, it can automatically build, store, load, recommended for beginners to choose this mode. However, this mode is not easy to describe the object changes, it is less efficient, so for an experienced tester, the former is a better choice, it only produces a shared GUI file, which makes test scripts easier to maintain, and more efficient.
  
  2. Create a test script
  
  When you create a test script, you typically record it, and then manually add the required TSL (a test scripting language similar to the C language) to the recorded script. There are two modes of recording scripts: Context sensitive and analog, depending on whether the mouse trajectory is simulated, the analog is generally chosen when playback is required. During recording, these two modes can be switched to each other via the F2 key.
  
  Just look at the size of modern software and functional points can be understood, functional testing has already crossed the single-tap keyboard, click the mouse can complete the stage. Performance testing is an effective method to control the performance of the system, and it plays an important role in software capability verification, capability planning, performance tuning, defect repairing and so on.
  
  3. Debugging a test script (debug)
  
  There is a dedicated debug toolbar in WinRunner to test the script for debugging. You can use step, pause, breakpoint, and so on to control and track test scripts and view various variable values.
  
  4. Execute the test script in the new application
  
  When a new version of the application is released, we test the various features of the application including what's new, and it's certainly not possible to re-record and write all of the test scripts. We can use existing scripts to run these test scripts in batches to test whether the old feature points are working correctly. You can use a call command to load each test script. You can also add a variety of TSL scripts to the call command to increase batch capacity.
  
  5. Analyze test results
  
  Analysis of test results is most important throughout the testing process and can be used to identify various functional flaws in the application. When a test script is run, a test report is generated, from which we can discover the functional flaws of the application, see the difference between actual and expected results, and the various dialog boxes generated during the test.
  
  6. Return defects (defect)
  
  After analyzing the test report, follow the test process to return the application's various defects, and then send these defects to the designated person for modification and maintenance.
  
  Common methods of functional testing
  
  Functional testing is to verify the function of the product, according to the function test case, test it by item, check whether the product meets the user's requirement function. The common test methods are as follows:
  1. Page link check: Each link has a corresponding page, and the page between the correct switch.
  2. Correlation check: the deletion/addition of an item will have an impact on other items, and if so, whether the effects are correct.
  3. Check the function of the button is correct: such as update, Cancel, delete, save and other functions are correct.
  4. String length check: Enter the length of the string beyond what is required, and see if the system checks the length of the string for errors.
  5. Character type check: Enter other types of content where the content of the specified type should be entered (for example, enter a different character type where the integer type should be entered) to see if the system checks the character type and whether it will error.
  6. Punctuation check: The input includes various punctuation marks, especially spaces, various quotes, and enter. See if the system is working correctly.
  7. Chinese characters processing: In the system can input Chinese language, see if there will be garbled or error.
  8. Check the integrity of the information that is brought out: when viewing the information and update information, check that the information you have filled out is not all taken out., bring out the information and add the consistency
  9. Information duplication: In some need to name, and the name should be the only information to enter a duplicate name or ID, see if the system has been processed, will be error, the name includes whether it is case-sensitive, and the input before and after the input space, the system to make the correct processing.
  10. Check the deletion function: In some places can delete more than one message at a time, do not select any information, press "delete" to see how the system processing, will be wrong; then select one and more information, to delete, to see if the correct processing.
  11. Check that additions and modifications are consistent: Check that the requirements for adding and modifying information are consistent, such as adding required items, modifications should also be required, adding items that are defined as integral types, and modifications must be integral.
  12. Check the name of the change: The changes can not duplicate the name of the item to the existing content, to see whether the processing, error. At the same time, also pay attention to, will be reported and their name of the wrong.
  13. Repeat the form: A record that has been successfully submitted, and then submit it back to see if the system has been processed.
  14. Check the use of the back key in the situation: in the place where you have to return to the original page, and then to repeat, to see if there are any errors.
  Search Check: Enter the contents of the system where there is a search function, and see if the search results are correct. If you can enter multiple search conditions, you can add both reasonable and unreasonable conditions to see if the system is working correctly.
  16. Enter the information location: note When you enter information where the cursor is resting, the cursor and the information you enter will be skipped elsewhere.
  17. Upload the download file check: Upload the download file function is implemented, upload file can open. What is the format of the uploaded file, whether the system has the explanation information, and check whether the system can do it.
  18. Required fields check: Should fill in the item is not filled out when the system has been processed, the required fields are prompted for information, such as the required fields before adding *
  19. Shortcut key check: whether to support common shortcut keys, such as CTRL + V BACKSPACE, etc., for some fields that do not allow the input of information, such as the selection of people, the choice of the date to the shortcut is also limited.
  20. Enter Check: Press ENTER after the end of the input to see how the system processing, will be error.

  09-02-18 | Add a Comment

• 0

  66089

  Black-Box Testing (Black-box testing, also known as functional testing or data-driven testing) is the test object as a black box. When using the Black box test method for dynamic testing, it is necessary to test the function of the SOFTWARE product without testing the internal structure and process of the SOFTWARE PRODUCT.
  
  The methods of designing test cases using black box technology are: Equivalence class division, boundary value analysis, error inference, causality diagram and comprehensive strategy.
  
  Black-Box testing focuses on the functional requirements of testing software, or black-box testing, which enables software engineers to derive input criteria for all functional requirements of the program. Black-Box testing is not a substitute for white-box testing, but is used to assist white-box testing to find other types of errors.
  
  The black box test attempts to discover the following types of errors:
  
  1) function error or omission;
  2) interface error;
  3) data structure or external database access error;
  4) Performance error;
  5) initialization and termination errors.
  
  Test case design method of black box test
  
  • Equivalence class Partitioning method
  • Boundary value Analysis method
  • Error-guessing methods
  • Causality Diagram method
  • Decision table Driven analysis method
  • Orthogonal experimental Design method
  • Function Diagram Analysis method
  
  Equivalence class Partitioning:
  
  is to divide all possible input data, that is, the input fields of the program into sections (subsets), and then select a few representative data from each subset as test cases. This method is an important and common black box test case design method.
  
  1) Division equivalence class: An equivalence class is a subset of an input field. In this sub-collection, each input data is equivalent to an error in the disclosure program. and reasonably assume that the test of the representative value of an equivalence class is equal to the other value of this class. Therefore, all the input data can be reasonably divided into some equivalence classes, In each equivalence class to take a data as the test input criteria, you can use a small number of representative test data. Good test results are obtained. Equivalence class partitioning can have two different situations: valid equivalence class and invalid equivalence class.
  
  Valid equivalence class: Refers to a set of meaningful input data that is reasonable for the specification of the program. The effective equivalence class can be used to verify whether the program implements the functions and performance specified in the specification.
  
  Invalid equivalence class: the definition of a valid equivalence class happens to be the opposite.
  
  When designing test cases, consider both of these equivalence classes. Because the software is not only able to receive reasonable data, but also to withstand the unexpected test. Such tests ensure that the software is more reliable.
  
  2) methods of dividing equivalence classes: The following gives six principles for determining equivalence classes.
  
  ① a valid equivalence class and two invalid equivalence classes can be established if the input condition specifies the range of values or the number of values.
  
  ② a valid equivalence class and an invalid equivalence class can be established if the input condition specifies a set of input values or a condition that specifies "what must be".
  
  ③ a valid equivalence class and an invalid equivalence class can be determined in the case where the input condition is a Boolean quantity.
  
  ④ establishes a set of values for the input data (assuming n), and the program has to handle each input value separately, it can establish n valid equivalence class and an invalid equivalence class.
  
  ⑤ a valid equivalence class (conforming to a rule) and several invalid equivalence classes (violating rules from different angles) can be established in the case of rules that must be followed by the input data.
  
  ⑥ the equivalence class is divided into smaller equivalence classes, the equivalent classes should be further subdivided in the case that the elements in the program process are different in the known equivalence class.
  
  3) Design The test case: After the equivalence class is established, an equivalence class table can be established, listing all the classified equivalence classes:
  
  Invalid equivalence class for valid equivalence class of input condition
  
  ... ... ...
  
  ... ... ...
  
  The test cases are then designed from the divided equivalence class according to the following three principles:
  
  ① provides a unique number for each equivalence class.
  
  ② Design a new test case to overwrite as much of the valid equivalence class as it has yet to be overwritten, repeating this step. Until all valid equivalence classes are overwritten.
  
  ③ Design a new test case to overwrite only one invalid equivalence class that has not yet been overwritten, repeating this step. Until all invalid equivalence classes are overwritten.
  
  Boundary Value Analysis method
  
  The boundary value analysis method complements the equivalence class partitioning method.
  
  (1) Consideration of boundary value analysis method:
  
  Long-term testing experience tells us that a large number of errors occur on the boundary of the input or output range, rather than on the inside of the input and output range. Therefore, to design test cases for various boundary conditions, more errors can be detected.
  
  Using the Boundary value analysis method to design the test case, the boundary condition should be determined first. The boundary of the input and output equivalence classes is usually the boundary of the test. You should choose a value that is exactly equal to, just above or below the boundary as the test data, rather than selecting a typical value or any value from the equivalent class as the test data.
  
  (2) The principle of selecting test cases based on the boundary value analysis method:
  
  1) If the input condition specifies the range of values, then the value of the boundary that has just reached this range should be taken, as well as the value just beyond the bounds of this range as the test input data.
  
  2) If the input conditions specify the number of values, then the maximum number, the minimum number, less than the minimum number of one, than the maximum number of Taichi as the test data.
  
  3) According to each output condition of the specification, use the preceding principle 1).
  
  4) According to each output condition of the specification, apply the preceding principle 2).
  
  5) If the program's specification indicates that the input field or output field is an ordered set, then the first and last element of the collection should be selected as the test case.
  
  6) If an internal data structure is used in the program, the value on the boundary of the internal data structure should be selected as the test case.
  
  7) Analyze specifications and identify other possible boundary conditions.
  
  Error-guessing method
  
  Error-Guessing method: A method of designing test cases based on experience and intuition to speculate on all possible errors in the program.
  
  The basic idea of the error-guessing method is to enumerate all possible errors in the program and special cases prone to errors, according to which they choose test cases. For example, many of the errors that were common in the module were listed during unit testing. Previous product testing has found errors, etc., these are the summary of experience. Also, the input data and output data are 0 cases. The input table is a space or the input table has only one row. These are all situations that are prone to errors. Examples of these cases can be selected as test cases.
  
  Causality Diagram method
  
  The equivalence class partitioning method and boundary value analysis method described above are focused on the input conditions, but the relation between the input conditions is not considered, and the combination of each other. Considering the combination of input criteria, some new situations may arise. But it is not easy to check the combination of the input criteria, even if all the input conditions are divided into equivalent classes, the combination of them is quite a lot. It is therefore important to consider designing test cases in a form that is suitable for describing a combination of conditions and generating multiple actions accordingly. This requires the use of causality diagrams (logical models).
  
  The final result of the causality diagram method is the decision table. It is suitable for checking the various combinations of program input conditions.
  
  The basic steps for generating test cases using causality diagrams:
  
  (1) Analysis software Specification Description, those are the reason (that is, the input condition or the equivalence class of the input condition), those are the results (that is, the output condition), and give each cause and result assigned an identifier.
  
  (2) Analyze the semantics in the description of the software specification. Identify the relationship between the cause and the result, the reason and the reason. According to these relationships, draw a causal diagram.
  
  (3) Due to grammatical or environmental constraints, there are some reasons and reasons, the combination of cause and result is not impossible to appear. In order to show these special cases, some marks are used to indicate constraints or constraints on the causal diagram.
  
  (4) Convert the causality diagram into a decision table.
  
  (5) Each column of the decision table is taken out as the basis for the design of test cases.
  
  The test cases (local, combined relationships) generated from the causality diagram include the fact that all input data is true and false, and the number of test cases is minimized, and the number of test cases increases linearly with the number of input data.
  
  The decision table is already used in the preceding causality diagram method. The decision table (decision table) is a tool for analyzing and expressing different operations under multiple logic conditions. In the early stages of the development of programming, The decision table has been used as a tool for writing programs. Because it can express the complex logic relation and the condition of the combination of the various conditions is both concrete and definite.
  
  A decision table is usually made up of four parts.
  
  Conditional pile (Condition Stub): Lists all the conditions for the problem. The order of the listed conditions is generally considered to be irrelevant.
  
  Action stub: Lists the actions that may be taken by the problem rule. The order of these operations is not constrained.
  
  Condition Item (Condition Entry): Lists the values that are for its left column condition. The true and false values in all possible cases.
  
  Action Item (Action Entry): Lists the actions that should be taken in case of various values of the condition item.
  
  Rule: The specific value of any combination of conditions and the corresponding action to be taken. A column that runs through the condition and action items in a decision table is a rule. Obviously, how many sets of criteria are listed in the decision table, and how many rules are there, and how many columns are there for both conditional and action items.
  
  Steps to establish the decision table: (according to the software specification)
  
  ① determines the number of rules. If there are n conditions. Each condition has two values (0,1), so there is a rule.
  
  ② Lists all the condition piles and action piles.
  
  ③ fill in the condition.
  
  ④ fill in the action item. Wait until the initial decision table.
  
  ⑤ simplification. Merge similar rules (same action).
  
  B. Beizer points out the criteria for designing test cases with a decision table:
  
  The ① specification is given in the form of a decision table or easily converted into a decision table.
  
  The order of ② conditions does not and does not affect which operations are performed.
  
  The order of ③ rules does not and does not affect which operations are performed.
  
  ④ you do not have to test other rules whenever the conditions of a rule have been met and the action you want to perform is determined.
  
  ⑤ If a rule is satisfied to perform multiple operations, the order of execution of these operations does not matter.
  
  Advantages of black Box testing
  
  1. Basically does not have the personnel management, if the program stops running normally is the test procedure crash
  2. After the design of the test example, the work is cool, of course, the more depressed is to determine the cause of crash
  
  Disadvantages of black Box testing
  
  1. The result depends on the design of the test example, the design part of the test example comes from experience, OUSPG is worth learning
  2. There is no concept of a state transition, and some of the successful examples are mostly for PDUs, and there is no state transition for the program being tested.
  3. In the absence of a State concept test, it is troublesome to find and determine the test case that caused the program crash, and it is necessary to confirm the possible test cases in the surrounding area separately. In the case of stateful testing, it is even more troublesome, especially if it is not a single testcase problem. These are more prominent in the heap problem.

Black box test