test development 1

1. Basic concepts of test development

1. What is software testing?

Software testing is the software test engineer to verify whether the software meets the needs of users

2. What is the difference between software testing and software development?

(1) Development: Small breadth, high degree of expertise
Testing: Wide range of skills required, but low degree of expertise

(2) Software testing and software debugging
have different purposes
– the task of testing is to find defects in the program; the task of debugging is to locate and solve problems in the program.
Different roles involved
– testing is mostly performed by testers and developers, black box testing is mostly done by testers, and unit/integration testing is mostly performed by developers. Debugging is done by the developer.
Different stages of execution
– Testing runs throughout the software development life cycle and debugging is generally in the development stage.

3. Why did you choose software testing?

Comprehensive ability: communication ability, learning ability, development ability, writing ability, automated testing technology, ability to write test cases, exploratory thinking,
interested
, bear pressure, take responsibility

4. What is a requirement?

User expectations and conditions and permissions required to meet contractual (documents, rules, standards)

User requirements and software requirements
Software requirements are transformed from user requirements. It is the refinement of
user requirements. User requirements are relatively rough, and direct implementation will be difficult because there are no details. User requirements become a concrete achievable process document.

2. Test development foundation

1. Requirements are the basis for software testing

Verify the requirements to ensure that the requirements are correct and achievable. Refine the requirements and extract test items one by one from the requirements.
Question: How do software testers gain insight into requirements?
Begin to intervene in the understanding of requirements from the stage of requirements analysis, and stand in the perspective of user needs

2. Username and password login test case

2.1 Functional angle:

1. Are usernames and passwords case sensitive?
2. Whether the password box on the page is encrypted and displayed
3. Whether to prompt to change the initial password when the user created by the background system successfully logs in for the first time.
4. Whether the Forgot Username and Forgotten Password functions are available.
5. Whether the front-end page limits the length of username and password according to design requirements
6. If a verification code is required for successful login, click on the verification code picture to see if the verification code can be replaced (updated), and whether the updated verification code is available.
7. Whether refreshing the page will refresh the verification code
8. If the verification code is time-sensitive, it is necessary to verify whether the verification code within the time limit and outside the time limit is valid.
9. If the user logs in successfully, but if the session times out, if the operation continues, it will be redirected to the user login page.
10. Users of different levels, whether the permissions are correct after logging in to the system.
11. Whether the focus of the page login is positioned in the username input box (ease of use)
12. Whether the shortcut keys Tab and Enter keys can be used normally.

2.2 Dimensions of non-functional requirements:

13. Whether the user password backend (database) storage is encrypted.
14. Whether user passwords are encrypted during transmission over the network
15. Whether the password has an expiration date, and whether to prompt you to change the password after the expiration date of the password.
16. In the case of not logging in, directly enter the URL address that can only be accessed after logging in in the browser to verify whether it will be redirected to the user login interface.
17. Whether the password input box does not support copy and paste.
18. Do not check whether the password entered in the password input box is in the page source mode.
19. Enter the typical "SQL injection attack" strings in the input boxes of the username and password respectively to verify whether the behavior of the system has been tampered with.
20. Enter the typical "XSS cross-site scripting attack" string in the input boxes of the username and password respectively to verify whether the behavior of the system has been tampered with.
21. Whether the system will block subsequent attempts to deal with brute force attacks in the case of multiple consecutive login failures.
22. The same user logs in on multiple browsers on the same terminal to verify whether the mutual exclusivity of the login function meets the design expectations.
23. The same user logs in successively on multiple terminal browsers to verify whether the logins are mutually exclusive.

2.3 Performance:

1. Whether the response time of single-user login is less than 3s
2. Whether the response time of user login in high concurrency scenarios is less than 5s.
3. Whether the monitoring indicators on the server side meet expectations in high concurrency scenarios.
4. Whether there is deadlock and unreasonable waiting in high concurrency scenarios.
5. If a large number of users log in and log out continuously for a long time, whether there is a memory leak on the server side.

2.4 Compatibility:

1. Under different browsers, verify the correctness of the display and function of the login page.
2. Different versions of the same browser, verify the correctness of the display and function of the landing page
3. Verify the correctness of the display and function of the landing page under different browsers of different mobile device terminals.
4. Verify the correctness of the display and function of the login page under the interface of different resolutions.

3. Test Cases

A test case is a set of collections initiated to the system under test, including the test environment, test data, test steps, expected results, (importance, priority, operation mode, title, etc.)

Advantages: measure the coverage of requirements; reusability, reference significance; can be used for regression testing; prevent omission of test requirements

4. What is a BUG (software bug)?

A mismatch between the program and the specification is an error if and only if the specification exists and is correct.
When there is no requirements specification, the judgment is based on the end user: a software error occurs when a program does not fulfill the functional requirements reasonably expected by its end user.

5. Development Models (5 Models)

software development life cycle

Requirements Analysis - Planning - Design - Development - Testing - Operation and Maintenance

5.1 Waterfall Model

Features: Strong in stages, each stage is relatively independent; pay attention to the analysis requirements in the early stage and the testing in the later stage.
Disadvantages: The test starts to intervene after coding, which leads to the early detection of problems and the loss of opportunities for early correction.

5.2 Spiral Model

It is suitable for large projects, high risks and high complexity .

Features: Emphasizes the test quality and risk analysis of each iteration, and has strong anti-risk capabilities
.

5.3 Incremental model, iterative model

Incremental is often confused with iteration, but there is a difference between the two.
Increment is the concept of building block by block. For example, to draw a figure painting, we can first draw the head of the person, then the body, and then the hands and feet... And iteration is the concept of repeated refinement . It can be used to draw the overall outline first, then outline the basic prototype, and then refine and color.

Features: Strong anti-risk ability

5.4 Agile Models (IMPORTANT!!!)

Agile Manifesto:
Individuals and interactions over process and tools
Usable software over well-documented
customer collaboration over contract negotiation
Responding to change over following a
plan former.
Features : Light documentation, light process, focus on goals, focus on output, and embrace changes .

5.4.1 The scrum model

Basic process:

Roles in scrum:
Scrum consists of product owner (product manager), scrum master (project manager) and team (R&D team).
The product owner is responsible for organizing user stories, defining their business value, sorting them, formulating release plans, and being responsible for the product.
The scrum master is responsible for holding various meetings, coordinating projects, and serving the R&D team.
The R&D team is composed of members with different skills. Through close coordination, the goal of each iteration is completed and the product is delivered.

(1) The product owner is responsible for sorting out the user story and forming the product backlog on the left.
(2) Release planning meeting : The product owner is responsible for explaining user stories, estimating and sorting them. The output of the release planning meeting is to formulate a list of stories to be completed in this iteration, the sprint backlog.
(3) Iterative planning meeting : The project team decomposes tasks for each story. The criteria for the decomposition is to complete all tasks of the story. Each task has a clear responsible person and completes the initial estimate of the working hours.
(4) Daily meeting : The scrum master holds a standing meeting every day, and the team members answer what they did yesterday and what they plan to do today, and what questions they have.
(5) Demonstration meeting : After the iteration is over, a demonstration meeting will be held, all relevant personnel are invited to participate, and the team is responsible for showing everyone the results of this iteration. During the period, everyone's feedback was recorded and organized by po to form a new story.
(6) Retrospective meeting : The project team summarizes the current iteration, finds deficiencies, formulates an improvement plan, and continues to improve in the next iteration, which has achieved
the effect of continuous improvement.

6. Test the model

6.1v model

Features: Each stage
is highly independent. Each stage on the left is the basis for the testing stage on the right, and corresponds to each testing stage on the right.
Waterfall model variant (disadvantage): Testing begins to intervene after coding, resulting in early-stage problems that are discovered later and lost opportunities for early correction.

6.2 w model

Features of the W model : each stage is highly independent. The test object is not only the program, but also the requirements and design. The testing and development are carried out simultaneously.
Limitations : Requirements, design, coding and other activities are regarded as serial ; testing and development activities also maintain a linear context, and the previous phase is completely completed before the next phase can be officially started . Cannot support agile development mode . For the current complex and changeable situation of software development, the W model cannot relieve the confusion faced by test management.