First understanding of software testing (common software development model)

---

Software Testing Concepts

1. Frequently asked questions about software testing

1) What is software testing?

The most common saying is that software testing is to find bugs and find software defects, and software testing is to verify whether software products meet the needs of users.

2) What is the difference between debugging and testing?

• different purpose
  • Debugging: finding and fixing bugs in software
  • Testing: finding bugs in software
• Participate in different roles
  • Debug: Developer
  • Testing: testers, developers
  • Unit/integration testing is mostly done by developers
  • Black box testing, etc. are mainly done by testing
• Execution phases are different
  • Testing: Testing runs through the entire life cycle of the software
  • Debugging: usually in the coding stage

3) What qualities do testers need to possess?

• Comprehensive quality
  • quick learning ability
  • Communication skills
  • writing ability
  • Development ability
• Master automated testing technology (project testing + technical affairs)
• Excellent ability to write test cases
• exploratory thinking
• interest in testing
• Necessary sense of responsibility and pressure (be prepared for danger in times of peace)

2. Explanation of common terms in software testing

1) demand

Requirements: meet user expectations or formally specify the conditions and capabilities of documents (contracts, standards, specifications), including user needs and software requirements

IEEE defines software requirements as :
(1) Functions and conditions that users need to solve a certain problem or achieve a certain goal; (
2) These conditions and functional requirements must be satisfied by the system, and at the same time, relevant contracts must be satisfied , standards, specifications, or other formal mandatory documents. It should be pointed out that the software requirements to be processed are dynamic, that is, the performance of the system is constantly evolving.

• User needs : It can be simply understood as the demand put forward by Party A. If there is no Party A, then it is the task that end users must complete when using the product. For example, a certain game does not have Party A. After the game is developed, it will be launched directly For the public to use, this requirement is generally relatively simple . Party A is simply expressing their needs.
• Software requirements : Software requirements, also called functional requirements, describe in detail the software functions that developers must implement .

Why can't user needs be directly used as the basis for the work of developers and testers?

Because the needs of users are diverse, the company needs to analyze the needs of users from the aspects of market feasibility and technical feasibility, such as whether it can be realized technically, and is it difficult to achieve technically? Whether the manpower and cost invested are far greater than the market profit, etc., all need to be considered.

Requirements are the basis for testers to carry out software testing work , and testers should be involved in the project from the requirements analysis stage (testing should run through the entire life cycle of the software)

Take user registration and login as an example:

2) Software errors (bugs)

The origin of the bug (360 Encyclopedia):

Bug translated into Chinese actually means bugs. Grace Murray Hopper, a computer expert working for the U.S. Navy, was one of the first to incorporate human language into computer programs. After she programmed 17,000 relays in the Harvard Mark in 1947, the machine stopped working shortly after it was running. So they climbed up the machine to find out why, and found a bug between the contacts of the relay inside the huge computer, apparently because the moth was attracted by the light and heat, flew to the contacts, and was killed by the high voltage. So in the report, Heber used adhesive strips to stick moths, and used "bug" to mean "an error in a computer program", and the term "Bug" has been used to this day.

The concept of bugs :

1. A mismatch between a program and a specification is an error if and only if the specification exists and is correct
2. When the function is not mentioned in the requirements specification, the judgment standard is based on the end user: when the program does not realize the functional requirements reasonably expected by the end user , it is a software error.

3) Test cases

Test case : It is a set of sets provided to the system under test for the purpose of implementing the test . This set includes: test environment, operation steps, test data, expected results and other elements

Suppose you want to test Netease mailbox registration:

• test environment

  • win10
  • Google Chrome Version 113.0.5672.93 (Official Release)

• Test Data:

  • email address
  • password
  • Phone number
  • verification code

• Test steps:

  • Open Google browser, enter Netease mailbox registration address
  • Enter the email address, password, mobile phone number, obtain the verification code, and check the user agreement

• Desired result

  • Display the successful registration result page, and use the account to log in normally

Why design test cases?

Designing test cases around software requirements solves the problem of repeated testing. The principle of designing test cases is to avoid throwing away after use .

3. Software life cycle

The software life cycle refers to the time from the conception of a software product to the end when the software is no longer used. If software is regarded as a living thing
, then the life cycle of software can be divided into 6 stages, namely, requirements analysis, planning, design, coding, testing, operation and maintenance.

1. demand analysis
   • Analyze whether the user is reasonable (market analysis, technical analysis)
   • specify software requirements document
2. plan
   • specify demand execution plan
   • How long to execute, when to start and when to end
3. design
   • Refine the requirements into tasks one by one, and carry out technical design (which interfaces to design, which technologies to use)
   • Produce design documents
4. coding
   • Developers code according to requirements documents and design documents
5. test
   • Testers refer to test cases for testing
6. Operation and Maintenance
   • Online maintenance of the product after the project goes online
   • Corrective maintenance: repairing undiscovered problems in the project
   • Perfection maintenance: improve the function
   • Preventive maintenance (be prepared for danger in times of peace): In order to avoid some other problems on the product line, carry out some preventive measures.

4. Development model

1) Waterfall model

Waterfall model is the basic framework for other models

• Features:
  • Linear development process, emphasizing the stage of development, emphasizing early planning and demand investigation
• defect:
  • The test is placed backwards, and the next step is only started after the previous one is completed
  • Risks are often not revealed until later in testing, thus missing opportunities for early correction
  • Not enough time is reserved for testing activities, otherwise it will lead to insufficient testing, thus leaving defects directly to users
  • The biggest flaw of the waterfall model is that the product that can run can be seen very late. Suppose there is a problem in the design of the software requirements document, which is discovered during the testing phase. The test tells the development about the problem, and the development says it has nothing to do with me. Just tell the design side about this problem, and it has been passed on to the upper level in this way, resulting in a large-scale rework of the entire project. This will cause the project to be delayed, or be preempted by the peers and cause greater losses.

So the usage scenario of the waterfall model: small projects with fixed requirements , because it cannot cope with changes in requirements.

2) Spiral model

The spiral model introduces the risk analysis of the whole process, and a new model will be generated after each analysis is completed .

The spiral model is divided into 4 quadrants. Each turn will go through the steps of designated plan, risk analysis, implementation project, and customer evaluation, and each turn will form a new version, which will be realized after rounds of improvements. finished product. That is to say, the test should be iterated along with the development iteration.

The advantages of the spiral model : the introduction of the whole process of risk management, emphasizing the quality of the software in the development stage, with the whole process of risk assessment to determine whether to continue in the next step.

The flaw of the spiral model is that it introduces very strict risk analysis, which prolongs the timeline of the project, and the risk analysis requires some professionals, which also increases the cost of manpower and capital.

The usage scenario of the spiral model: projects with uncertain requirements in the early stage, large-scale, high-complexity, and high-risk projects .

3) Incremental model and iterative model

incremental model

Suppose the user has three functional requirements $A,B,C...$ , if you use the spiral model or the waterfall model, you need to complete these three functions before going online, but theincremental modelis different, it develops the three functions separately, and completes one Get one online. After developing$A$ direct click allows users to use, and the development of the three functions does not affect each other.

The incremental model can reduce project risk, but in this model each iteration means updating the version of the software, testing has to be done frequently and development has to work closely.

iterative model

The iterative model is relatively simple, assuming that the user has $A,B,C$ three requirements. If you use an iterative model model, put$The\; realization\; of\; the\; basic\; functions\; of\; the\; three\; requirements\; of\; A,B,\; andC$ , that is, a relatively crude version, cannot meet the requirements of users, and then iteratively optimize these functions. Applicable to projects whose requirements cannot be fully determined in the early stage

4) Agile model

Manifesto for agile software development:

1. Individuals and interactions over processes and tools
2. Working software over exhaustive documentation
3. Customer cooperation is higher than contract negotiation
4. Responding to change is more than following a plan

That is, while the latter has its value, we place more value on the former.

• The first point of the Agile Manifesto emphasizes efficient face-to-face communication between people (light process)
• The second point shows that more emphasis is placed on output (light documentation)
• The fourth point reflects that the change is greater than the plan, because the user's needs will change suddenly.

The characteristics of the agile model are summarized through the agile manifesto:

• light process
• light document
• heavy target
• Heavy output (deliverable software)

However, the agile model is only a general direction, there is a very common agile development model scrum

There are three roles and five meetings in scrum

Three roles:

• Product manager: the needs of mobile phone users, writing requirements documents, and the person responsible for the product
• Project Manager: Responsible for holding various meetings, coordinating projects, and serving the R&D team
• R&D team: developers, testers, $ui$ designers etc.

Five sessions:

The product manager is responsible for sorting out the requirements and sorting them to form a list of requirements,

• Release planning meeting: The product owner is responsible for explaining user needs, estimating and sorting them, and the output of the release planning meeting is to customize the list of requirements to be completed in this iteration, and output which user needs need to be completed in one cycle .
• Iterative planning meeting: The project team then decomposes the tasks of each requirement. The standard of decomposition is to complete all the tasks of the requirement, each task has a clear leader, and a preliminary estimate of the time to complete the task
• Daily meeting: The project manager calls a standing meeting every day, and the team answers what they did yesterday and what they plan to do today, and what questions they have
• Demonstration meeting: After the iteration meeting is over, a demonstration meeting is held, and relevant personnel are invited to participate, and the team leader will show everyone the results of this iteration. During this period, everyone's feedback was recorded and sorted out by the product manager to form new requirements.
• Review meeting: The project team summarizes the current iteration, finds deficiencies, specifies an improvement plan, and continues to improve in the next iteration, achieving the effect of continuous improvement.

---