A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1. Basic Concepts
Software is a computer program that can run on a computer, such as operating system windows, Office software Office, chat QQ, mobile games, and so on. The link between software and our lives and work is getting closer.
1.2 Software Testing
The classic definition of software testing is to operate the program under prescribed conditions to discover bugs, measure software quality, and evaluate whether it meets design requirements.
Software testing is a realistic definition of: Software testing is the entire software development lifecycle, the software products (including phased products) to verify and confirm the activities of the process, the purpose is to quickly discover in the software products in the various problems-and user needs, predefined inconsistencies.
1.3 Methods of testing
Software testing is generally divided into white box test and black box test.
Black box test
Black-Box testing, one of the main methods of software testing, can also be called functional testing, data-driven testing, or testing based on specifications. Test the functionality of an application, not its internal structure or operation. Testers do not need expertise in the code, internal structure, and programming language of the application. Testers only need to know what the system should do, that is, when typing a specific input, you can get a certain output, this is from the user's point of view for the software interface, function and external structure testing, regardless of the internal logic structure of the program. Test cases are the functions that the application system should perform, designed according to specifications, specifications or requirements. The tester chooses valid input and invalid input to verify the correct output. This test method can be suitable for most software tests, such as unit testing, integration testing (integration testing), and system testing (systems testing).
White box test
White-Box testing (also known as transparent box testing, structural testing, etc.) is a method of testing the software to test the internal structure or operation of the application, rather than testing the functionality of the application (i.e. black-box testing). Design test cases in the context of a programming language in the White box test. The tester enters data to validate the path of the data flow in the program and determines the appropriate output, similar to the node in the test circuit.
White box testing can be applied to unit testing, integration testing, and system software testing processes, testing the path between each unit in the integration process, or testing in the main system and subsystem. Although this method of testing can detect many errors or problems, it may not be able to detect unused portions of the specification.
1.4 Types of tests
According to the functional division of the test software to conduct a structured test, in the functional testing part to ensure that the test items cover all functions and a variety of functional conditions combination.
For a more detailed description, see "Black box test."
For a complete software to test the user's point of view, system testing and functional testing, the difference is that the system test all the test data and test methods to simulate and the user's actual use of the environment is exactly the same, testing software is the system integration after the complete software system, Instead of the executable program that is built after each feature module that is used in the functional testing phase is compiled separately.
Limit value test
The software in a variety of special conditions, special circumstances can be normal operation and software performance testing.
Special conditions generally refer to the maximum value, minimum value, and test under the maximum and small value of the software.
The special environment generally refers to the software running machine is in the CPU high load, or network high load state of the test, according to the different software, special environment has also been different.
Performance testing is the evaluation of software performance. Simply put, software performance measures the responsiveness and timeliness of software. Therefore, performance testing is a way to evaluate the timeliness of software response by means of testing. Depending on the different types of software, the focus of performance testing is different.
Pressure test, establish a test method of system stability, and it is widely used in the fields of software engineering and financial risk management. Usually outside the normal operating range of the system to investigate its functional limits and hidden dangers.
The difference between stress test and performance test
Stress testing is often confused with performance testing. The main difference is that stress tests require tests that exceed the specified performance targets. For example, a website design capacity of 100 people click at the same time, the stress test is to use 120 simultaneous click of the condition test.
1.5 Phase of the test
Unit test is to test the Software component unit, the aim is to check the correctness of the basic unit of software, the object is the smallest unit---module of software design. Unit tests are typically done by developers.
Integration test, also known as Assembly test, is to assemble the program module with proper integration strategy, and to test the correctness of the interface and the function after integration. The main purpose is to check whether the interface between the software units is correct, and the object of the integration test is the module that has been tested by the unit.
The practice shows that sometimes the modules can work alone, but they are not guaranteed to be assembled or worked at the same time.
System testing mainly includes function test, interface test, reliability test, usability test and performance test. Functional testing is mainly aimed at including functional availability, functional implementation (function flow & business process, data processing & Business processing).
Regression testing is a test activity performed to detect errors introduced by code modifications. Regression testing is an important work in the software testing phase, and research shows that the cost of regression testing is more than 1/3 of the total costs of the software life cycle.
Unlike a normal test, when the regression testing process begins, the tester has a complete set of test cases to use, therefore, how to reuse the existing test case set according to the code modification is an important direction of regression testing, in addition, the research direction of regression testing involves automation tools, Object-oriented regression test, test case priority, regression test case supplement generation, etc.
The alpha test is usually initiated after a phased development, and continues until the stage before entering the beta test phase. The alpha test is a validation test that runs with simulated data in a simulated environment.
In this phase, it is usually in the development unit that the developer and test testers are tested in a simulated or hands-on manner.
Alpha testing is usually performed in system tests to verify that the information system meets the needs of the user and the design requirements. When the alpha phase is complete, the development process enters the beta phase; the stage of the test by the public participation. Beta testing can be called validation testing, in a real environment with the actual data to run the test to confirm performance, system operation efficiency, system undo and backup operation is normal, through testing so that the information system can later
The difference between a beta test and a black box test
A common misconception about alpha and beta testing is "beta testing = black box testing." In fact, alpha and beta tests correspond to the alpha and beta phases prior to the release of the software product, while the white box, black box, and gray-box test techniques are described in terms of the techniques and methodologies that are being tested and should not be confused with these two parts of the concept.
Acceptance test is the process that the system is deployed to the user environment, the user runs the system, and investigates whether the system satisfies the user's requirement. Acceptance tests are user-led, and users may hire experts to help with acceptance testing.
1.6 Effects of software testing
1. Complete evaluation of product quality, provide information for software product release (e.g. acceptance test), software system deployment (e.g. performance planning test), Software PRODUCT identification (third party independent testing) and entrusted party dispute arbitration (third party independent Test) and other decision making;
2. Through continuous testing (including requirements review, design review, code review, etc.) can provide continuous, rapid feedback on product quality, thereby continuously and timely improve the quality of products throughout the development process, and reduce various rework, reduce the cost of software development;
3. Through the test found that the products to be delivered defects, especially as far as possible to find a variety of serious defects, reduce or eliminate product quality risk, improve customer satisfaction, expand market share, improve customer loyalty.
4. Through the analysis of defects to identify the root causes of defects (software process problems, including the wrong way of behaving) or to summarize the SOFTWARE Product defect mode, to avoid the same error or produce similar product problems, to achieve the purpose of prevention of defects
2. Primary software Test Engineer main work
2.1 Writing functional Test Cases
1 Test Case Design Steps
When designing a test case, you need to have a clear idea of the test, what to test, what order to test, and what needs to cover. Test case writers should not only master the technology and process of software testing, but also have a thorough understanding of the software design, functional specifications, user trial scenarios and the structure of the program/module. Test case design typically includes the following steps:
1. Test requirement Analysis
From the software requirements document, identify the requirements of the software/module to be tested, through their own analysis, understanding, collation into the test requirements, clear what the test object has the function. Test requirements are characterized by the inclusion of software requirements and testability.
Test requirements should be summarized, classified or subdivided on the basis of software requirements to facilitate test case design. The relationship between a test set and a test requirement in a test case is a many-to-many relationship, where one or more test case sets correspond to a test requirement.
2, Business process analysis
Software testing is not simply a function-based black-box test, but also requires the internal processing logic of the software to be tested. In order not to omit test points, it is necessary to have a clear understanding of the business process of the SOFTWARE PRODUCT. It is recommended that you draw the business process of the software before you do a complex test case design. If you already have a business process design in your design document, you can complement the existing process from a test perspective. If the business process cannot be obtained from the design, the test engineer should communicate with the developer by reading the design document and eventually drawing the business flowchart. The business process diagram helps to understand the processing logic and data flow of the software, thus directing the design of test cases.
From the business process, you should get the following information:
A, what is the main process
B, what is the conditional alternative process
C, what is the data flow
D, what is the key condition of judgment
3. Test Case Design
After completing the test requirement analysis and software process analysis, we started to design test cases. The types of test case designs include functional testing, boundary testing, anomaly testing, performance testing, stress testing, and more. In the use case design, in addition to the function test with exception, should consider the boundary, the exception, the performance situation as far as possible, in order to discover more hidden problem.
The test case design methods of black box test are: Equivalence class division, Boundary value Division, causal graph analysis and error guessing, and white box test test case design methods include: statement coverage, decision coverage, condition coverage, decision/condition coverage, multiple condition coverage. The black box test is mainly discussed here. When designing test cases, you can use software test case design methods, combined with the previous requirements analysis and software process analysis to design:
Functional testing: Test whether a function satisfies the definition of requirements, function is correct, complete.
Appropriate technology: Functional testing, equivalence class partitioning, derived from business requirements and design specifications
Boundary test: Tests the boundary condition of a feature.
Appropriate technology: Boundary value Division
Exception testing: For some features, the boundary situation is not simple to understand or some operations are not entirely correct but it is possible, similar to the case need to write the relevant exception test.
Appropriate technologies: Special business processes, error guessing, boundary value analysis, internal boundary value testing, and the export of business requirements and designs
Performance test: Check the system to meet the requirements required by the performance, performance mainly include understanding the internal and external performance factors of the program. Internal performance factors include the configuration of test environment, system resource usage, external factors including response time, throughput and so on.
Appropriate technology: testing of business requirements and design notes export
Stress tests: Stress tests are also called strength tests, it is mainly to check the operating environment of the system under the limit of the ability to run the software, for example, to a considerable load or network traffic to the application software Compatibility test: Test software products in different platforms, different tools, the same tools in different versions of the compatibility of features.
4. Test Case Review
After the test case design is completed, the test case needs to be reviewed in order to confirm the correctness of the test procedure and method and whether there are any missing test points.
Test case reviews are typically arranged by test leader, and participants include: test case designer, test leader, project manager, development engineer, other related development test engineer. After the test case review, the test engineer modifies the test case according to the result of the review and records the change log.
5. Perfect test Case Update
After the test case writing needs to be perfected continuously, after the SOFTWARE PRODUCT new function or the renewal request, the test case must complete the revision update, the testing procedure discovery when the design test case is not considered, needs to revise the test case to be perfect; the software flaw that the customer feedback after the software delivers uses, But the flaw is caused by the flaw of the test case, also need to perfect the test case. Generally small modifications can be modified on the original test case document, but the document must have a change record. The version of the software is updated, and the test cases should generally be updated with the upgrade version. Test cases are "live", constantly updated and perfected in the lifecycle of the software.
2 Test Case Design method
The test case design methods of black box test are: Equivalence class division, Boundary value Division, causal graph analysis and error guessing, and white box test test case design methods include: statement coverage, decision coverage, condition coverage, decision/condition coverage, multiple condition coverage. Here, the main discussion is the black box test test case design method.
Classification of equivalence classes
The equivalent column partitioning design method is to divide all the possible input data into several parts (subsets), and then select a small number of representative data from each subset as a test case, and testing the representative value of an equivalence class is equal to the test of this class of other values.
There are two main steps in designing test cases using the equivalence class partitioning method: (1) determining equivalence classes and (2) generating test cases.
1. Dividing equivalence class
There are two different cases of equivalence class division: Valid equivalence class represents incorrect input value for program and invalid equivalence class, and both equivalence classes are considered in design. The following are the principles for determining equivalence classes:
(1) A valid equivalence class (within the range of values) and two invalid equivalence classes (less than the range of values and greater than the range of values) may be established if the input condition stipulates a range of values. For example: When using mobile phone to send text messages, SMS content length must be within 70 characters, then valid equivalence class: Short message content length in 70 characters, invalid equivalence class: SMS content length is 0, short message content length is greater than 70.
(2) When the input conditions specify the number of values, you can establish a valid equivalence class (within the range of values) and two invalid equivalent classes (less than the number of values and greater than the number of values). For example: A student can take one to five courses a semester, the valid equivalence class is: 1<= students elective courses <=5, invalid equivalence class: No elective courses, elective course is greater than 5
(3) A valid equivalence class and an invalid equivalence class can be established if the input condition sets the set of input values. For example: The encoding of the text to send the value range is 0, 3, 4, 8, 15 or 16, the valid equivalence class is: SMS encoding is 0 or 3 or 4 or 8 or 15 or 16, invalid equivalence class is: SMS encoding is not 0 or 3 or 4 or 8 or 15 or 16 of any of them.
(4) A valid equivalence class and an invalid equivalence class can be established if the conditions under which "must be" are specified in the input condition. For example: The name of a variable, such as starting with an uppercase letter, the valid equivalence class is: The variable name begins with an uppercase letter, and the invalid equivalence class is: The variable begins with a letter that begins with an answer.
(5) A valid equivalence class and an invalid equivalence class can be established when the input condition is a Boolean quantity. For example: In the case of Shenzhou mobile phone number withholding fee is successful, allow the user to send SMS, the valid equivalence class is: Shenzhou Bank withholding fee is successful, invalid equivalence class for the Shenzhou bank withholding fee failure.
(6) In the case of a set of values (assuming n) of the input data, and if the program wants to treat each input value separately, n valid equivalence classes and an invalid equivalence class can be established.
(7) A valid equivalence class (conforming to rules) and several invalid equivalence classes (which violate the rules from different angles) may be established in cases where the rules to which input data must be complied are specified.
(8) The equivalence class should be further divided into smaller equivalence classes in the case that the elements in the identified equivalence class are in different ways in program processing.
2. Generate Test Cases
After the equivalence class has been established, an equivalence class table can be established, listing all the classes of equivalence that are divided, and the process is:
(1) Specify a unique number for each equivalence class.
(2) Design a new test case so that it overwrites as many valid equivalence classes as are not yet covered, repeating this step until all valid equivalence classes are overwritten.
(3) Design a new test case to overwrite only an invalid equivalent class that has not been overwritten, repeat this step until all invalid equivalence classes are overwritten.
Two, boundary value analysis method
Boundary condition refers to the state where the input and the input equivalence class are just at the boundary, or exceeds the boundary or less than the boundary, the boundary value analysis method is used to design the test case, then the boundary condition should be determined, and then the value which is exactly equal to, just greater than or just less than the boundary
The principle of selecting test cases based on boundary value analysis method:
(1) If the input conditions specify the range of values, you should take the boundary value just reached this range to design an effective test case, and just over the scope of the boundary value for the design of invalid test cases. For example: the effective length of short message content is 70 Chinese characters, the effective test cases: SMS content length of 1, SMS content length of 70 Chinese characters, invalid test cases: Short message content length of 0, short message content length of 71 Chinese characters.
(2) If the input conditions specify the number of values, you should take the maximum number, the smallest number, less than the minimum number of one, the maximum number of Do Yi as a test input data. For example: SMS effective encoding for 1~255, you should take 0, 1, 255, 256 design boundary value test cases.
(3) According to the specification of each output condition, use the preceding principle 1.
(4) According to the specification of each output condition, use the preceding principle 2.
(5) If the input or output of a program is an ordered collection, you should select the first element of the collection and the last element to design the test case.
(6) If an internal data structure is used in the program, the value of the internal data structure boundary should be selected to design the test case.
(7) Analyze the specification and find out other possible boundary conditions.
Third, causal diagram method
Causality diagram method is a kind of test case design method which is suitable to describe the combination of many kinds of conditions and produce multiple actions accordingly.
The steps for generating test cases using causal graphs are:
(1) Decompose the specification statement into an executable fragment.
(2) Determine the causal relationship in the specification. Analysis software Specification Description Those are the reasons, those are the results, and give each reason and result an identifier.
(3) Analyze the semantics of the description of the software specification, find out the relationship between the cause and the result, the reason and the reason, and convert it into a causal diagram.
(4) Add the annotation symbol to the causality diagram, and use some marks to indicate the constraint or restriction condition.
(5) The state change in the tracking diagram, the causal diagram is converted to the decision table.
(6) Take each column of the decision table as the basis, design the test case.
Four, False conjecture method
The method of error inference is to design the test case in a specific way based on the experience and intuition of all the possible errors in the program.
The basic idea of false inference is to enumerate all the possible errors and errors in the program, to design the test cases according to the checklist, and to design the test cases by reading the specifications which are easily overlooked by the programmer.
The error inference method is a very effective test case design method, which requires the tester to have rich experience in testing and familiar with the processing of the business. For example, when sending text messages, if a message is sent, the other gateway has no response or timeout response or no response status report, the program how to deal with it.
Test Case Design
How to write an effective test case
2.2 Perform functional testing
Test the test results and submit the discovered bugs during the test according to the test plan and test case. Report the day test to the test leader or Test manager before leaving work.
2.3 Submitting A Bug
2.2.1Bug Basic Concepts
Start building with 50+ products and up to 12 months usage for Elastic Compute Service