Test Strum 2

Added a group about soft test, where the group master is a work of more than 10 years of soft testing engineers, will be on the weekend to explain to us some of the knowledge of testing. I learned a lot from it, and now I will sort it out as follows.

1. API testing and UI testing

API testing As with other tests, the first thing to do is to set up the test environment, all the necessary configuration files are ready, before starting the test to ensure that the program on the server is measurable (if necessary, can seek research and development assistance).
The API test also tests the interface in addition to testing the functionality. An API or function can be used as a unit to unit test the unit, you can use the black box method, you can also use the white box method. The black box method is to not look at the implementation code of this unit, only according to the function description of the unit to design test cases and test. When testing, you may need to write a simple code to prepare the data, and then call the interface that needs to be tested, and generally need to write some code to receive or verify that the output of the unit being measured is correct; the White box test method is that you analyze the code of the unit being tested Test cases are designed and tested according to different test strategies, such as Branch overrides or logical overrides. The requirements of the platform products are many from the website, in short, platform products provide API for website development and use. What we need to measure is these exposed APIs that make sure that these APIs are functionally free of defects. Attached URL http://www.cnblogs.com/hehaiyang/p/4458245.html

User interface Test in English named the user interface testing, referred to as UI testing, testing the layout of the functional modules of the interface is reasonable, the overall style is consistent and the placement of the controls are consistent with customer usage habits, more importantly, to comply with the operation is convenient, easy to understand the navigation, The text in the interface is correct, the name is unified, whether the page is beautiful, the text, the picture combination is perfect and so on.

Some test projects, after testing the UI, the developer changed the code, and then have to re-test the UI, so repeated, very troublesome, so the group master drew this diagram

Do the API test first, then do the UI test.

API is the bottom, the UI is higher, once the API has changed, the UI is changed, and the more efficient is to start from the bottom and start testing from the API.

2. bug life cycle

This is the life cycle of the bug, the picture is I look for from the net, the bug also has the priority, not all problems all need to solve, some may not matter, does not need to fix, some does not call the bug, can ignore.

3. Level of testing

This group of owners said that in the interview more dominant, the interviewer asked you this question, you can answer:

Priority

P0 is a grade, 1 2 3. E.g. Test paper cups

P1-positive Heat resistant?

P2-negative with fire

p3-Performance pressure test

Test Case Prioritization

P1: The basic function of the system, the number of cases should be controlled according to: The use case execution failure, will lead to a number of important functions are not available; High probability of occurrence, frequently used features this class of use cases need to be executed in each release test
P2: The important function of the system, the number of cases is more divided according to: a variety of applications, the use of high frequency of normal functions. Functional interaction. All important functions of the system must be implemented in the non-regression system test version.
P3: The general function of the system, the number of case is more divided according to: Use frequency is lower than P2, such as super-long string, boundary value, things integrity and other non-regression system test version does not have to be verified, in the middle and late of the system test does not necessarily validate each version
P4: Optional partition basis: More uncommon input, the use of very low frequency function in the version test, there are some normal reasons, after and the product manager to communicate to confirm can not be executed

4. Test Engineer's work This is my privately asked a question, I said the software Test engineer is not hard to please, the group owner immediately corrected, he said in fact, the test engineer than the pressure of the development engineer is smaller, the development engineer project does not come out will be crazy overtime. Some of them complained that the developers despised them for testing, and that the situation arose because they did not understand the code being developed. This is not the case in the group master, for the simple reason that the group owner is Daniel, (づ￣3￣) old a lot of code and implementation, the group owner is stronger than the developer. This matter tells us, does not understand the code is to be despised! (Full of Tears ...) So the ability of the tester itself needs to be enhanced.

Test Strum 2