Chapter 2: Basic Concepts

of Software Testing
Software Quality Assurance
and Testing Course
Deeply understand the connotation of software quality,
master defect analysis methods, learn the testing
classification system, and cultivate professional testing
mindsets. CHAPTER 2
 Chapter 1 Review

n What Is Software Testing？

n Principles of Software Testing
n What Is Software Quality Assurance
(SQA) ？
n The Relationship Between Software
Testing and SQA ？
 Learning Objectives & Content Overview
Learning Objectives
Deeply understand the connotation and
Comprehensive Analysis of the
standard definitions of software quality; master
Generation, Classification and Cost of
quality concepts in international standards such
Software Defects: Understanding Defect
as ISO and IEEE.
Composition, Root Cause Analysis, and
Master the three-dimensional classification Repair Cost Models
system; systematically classify testing by
level, object, and purpose. Understand testing tasks and professional
requirements at each stage, from Unit
Testing to Acceptance Testing.
Content Structure

2.1 Software Quality 2.2 Software Testing 2.3 Static Testing and 2.4 Active Testing and
and Software Defects Classification System Dynamic Testing Passive Testing

2.5 White-box Testing 2.6 Software Testing 2.7 Test Plan and Test 2.8 Requirements for
and Black-box Testing Levels Cases Professional Testers
2.1 Software Quality and
Software Defects
Definition of Quality: ISO 8492 Standard

“Quality is the set of inherent characteristics

and features of a product or service that meet
the ability to fulfill stated and implied needs.”
——ISO 8492 (1986)

1. Inherent 2. Explicit 3. Implicit

Characteristics Characteristics Characteristics
Characteristics naturally and Specified requirements explicitly Unspoken rules from social customs
permanently belonging to something described in standards or or behavioral conventions (e.g., the
(e.g., hardness of wood, height of a specifications (e.g., computer other 3 legs of a 4-legged table must
table). dimensions, memory, and interfaces). be of the same height).
Software Quality Perspectives (IBM RUP & IEEE)
A comprehensive quality concept that exceeds user requirements

Meeting or exceeding a recognized set of requirements, evaluated using approved

measurement methods and standards, and produced using recognized processes.

1. Meeting and Exceeding 2. Evaluation Methods and 3. Manageable Production

Requirements Standards Processes
• Adopt approved evaluation methods •Apply manageable and reusable
• Exceed user expectations while
and standards to ensure the scientificity processes to ensure the product reaches
meeting their requirements
and objectivity of quality assessment the expected and stable quality level

RUP Emphasis: Quality = Result + Process + Method.

It focuses not only on what to do, but also how to do it and how to prove it.
 Software Quality in ANSI/IEEE Standards
Definition per IEEE STD 729-1983

A software product satisfies all the stated and implied characteristics and features
related to the ability to meet requirements.
The degree to which software
1 product quality meets user The combination degree of
2
various attributes of software
requirements
The comprehensive reflection
3 degree of users on software 4 The degree to which software
meets user requirements during use
products

These characteristics reflect the usability, functionality, effectiveness,

reliability, performance and other aspects of the software system.
Software Quality Definition from the RUP Perspective
Three Dimensions of Software Quality: Functionality, Performance and Reliability
1. Functionality
Definition: The ability to execute
specified use cases in accordance
with the intended purpose and
requirements.

3. Reliability
Definition: The robustness
and dependability of software,
2. Performance code integrity, and technical
Definition: The resource utilization compatibility.
rate and operational characteristics of
the system.
Resource utilization includes CPU
occupancy and memory usage level.
Classic Quality Model: McCall Model
A hierarchical classification framework
for software product quality attributes Product Operation
Correctness, Reliability,
Efficiency, Integrity,
Usability, etc.
Product Focus on user experience
Operation
Product Modification

Maintainability, Flexibility,
Testability, etc.
Product
Modification Focus on software maintainability

Product Transition
Product Portability, Reusability,
Transition Interoperability, etc.
Focus on software
adaptability
International Standard: ISO 9126 Three-layer
Software Quality Model
The three-layer evaluation criteria system:
SQRC • SQDC • SQMC

• ISO 9126 establishes a complete three-layer

quality evaluation system:
• High level: SQRC - Software Quality
Requirements Criteria
• Middle level: SQDC - Software Quality
Design Criteria
• Low level: SQMC - Software Quality
Measurement Criteria
ISO 9126 Core Attributes
Functionality
l The degree to which the functions implemented Usability
by software meet its design specifications and
user requirements. l The degree of effort required for users to learn,
operate, prepare inputs and understand outputs.
Reliability
l The degree to which software can maintain its Compatibility
normal functional operation and performance
level within a specified time and under specified l The ease with which software can be
conditions. transferred from one computer system or
Extensibility environment to another.
l The ease with which new functions can be
功能性关注‘能做什么’，可用性关注‘好用程度’
added and system capabilities expanded in the - 两者共同决定用户体验
future.
Relationship Between Internal Quality, External Quality
and Quality in Use

Internal Quality External Quality Quality in Use

• Requirements traceability
• Functional completeness • User satisfaction
• Software size and complexity
• Performance performance • Actual usage effect
• Code coupling
• Reliability indicators • Business value realization
• Modularity level
• User interface friendliness • Risk control capability
• Naming standardization of variables
Diverse Designations for Software Defects (Bugs)
Software defects have various expressions in different contexts, but they all
point to the same core problem.
English Terms
• Bug - the most vivid designation
• Defect - the formal standard term
• Fault - emphasizing the essence of the error
• Error - a general concept of mistakes
• Failure - a functional-level description
• Problem - a broad expression of issues

Common Point: Violating quality requirements, failing to meet customer needs, and
leading to functional failure.
 Standard Definition of Software Defects
What exactly is a software defect? The essence of defects from a dual perspective

Internal Perspective External Perspective

From the internal view of the product, a From the external view, a software
software defect refers to various problems defect is the failure or violation of a
such as errors and flaws existing in the certain function that the system
development or maintenance process of a needs to implement.
software product.
Software defects ≠ Program crashes
NOTE！！
Software defects = Errors in the development process + Software
behavior not conforming to requirements
Specific Manifestations of Software Defects
p Functions and features are not implemented or
partially implemented
p Unreasonable design with defects
p Inconsistency between actual and expected results
p Runtime errors, including operation interruption,
system crash, and interface disorder
p Incorrect data results and insufficient precision
p Other issues unacceptable to users, such as long
access time and unattractive interface
Specific Manifestations of Software Defects (1)
Common System-level Defect Manifestations
Runtime Errors System Crashes
System operation interruption, abnormal program Complete system unresponsiveness, blue
termination, disordered interface display screen of death, service stop
• Null pointer exception • Operating system crash
• Memory overflow • Forced application shutdown
• Overlapping interface elements • Database connection failure

Incorrect Data Calculation

Incomplete Function Implementation
Incorrect calculation results, loss of numerical Missing expected functions, unavailable
precision, logical operation errors partial features, unmet requirements
• Financial calculation deviations • Abnormal login function
• Inaccurate statistical data • File upload failure
• Algorithm implementation errors • Inaccurate search results
Specific Manifestations of Software Defects (2)
（a）User Interface Defects （c）Document Specification Problems
• Unattractive and inconsistent interface display • Issues with requirement specifications
•Misaligned text display and inconsistent font • Missing certain requirements and unclear
sizes expressions
• Improper color matching and disordered layout • Contradictions and inconsistent logic
（b）Design Rationality Issues （d）Other Issues Unacceptable to Users
•Unreasonable design with defects (e.g., a
• Excessively long access time
computer game can only be played with a
• Inconvenient operation
keyboard instead of a mouse)
• Abnormal functional response
• Operation processes not conforming to user
habits
Causes of Software Defects
① Technical Problems
Algorithm errors, syntax errors, calculation and precision issues, mismatched
interface parameter transmission

② Software Itself
p Document errors, failure to consider user scenarios

p Problems caused by temporal incoordination or inconsistency

p Issues such as system self-recovery, remote data backup and disaster recovery
③ Team Work
Inadequate communication and misunderstandings
 Causes of Software Defects: Technical Problems
Analysis of Technical Challenges and Limitations
（a）Limitations of Development Technology （c）Difficulties in Complexity Management
① Limitations of developers' technical capabilities ① Excessively complex logic that is difficult to handle
perfectly at one time
② Failure of system design to fully balance
functionality, performance and security ② Poor system structure design leading to low performance
③ Mismatch between technical selection and actual ③ Unscientific algorithm selection affecting system
requirements efficiency
（b）Challenges of New Technology Application (d) Interface and Compatibility Problems
① Immature performance in the initial adoption of ① Mismatched transmission caused by excessive
new technologies interface parameters
② Certain functions in requirement specifications
② Insufficient experience in solving and handling problems
cannot be implemented technically
③ Risks brought by the steep learning curve of new
③Insufficient consideration of recovery mechanisms
technologies
after system crashes
Thinking: Which type of technical problem is the most common in your project experience?
Causes of Software Defects: The Software Itself
and Processes
Problems with the Software Itself Inadequate design considerations

Problems with the software itself often stem from the neglect of quality standards and
underestimation of complexity in the development process.
Causes of Software Defects: Team Collaboration
and Communication Quality risk factors at the management level
Team Culture Issues
Weak quality awareness and insufficient emphasis on
software quality; lack of a team culture that prioritizes
quality.
Requirements Communication
Barriers
Deviations in understanding customer requirements;
insufficient clarity in analyzing customer needs during
system analysis; difficulties and misunderstandings in
communication with users.
Information Transmission in the
Development Phase
Team collaboration problems are often more
Inconsistent understanding across phases; deviations in
the design team’s interpretation of requirements analysis difficult to detect and solve than technical
results; insufficient attention paid by programmers to problems, but have a far-reaching impact on
design specifications. product quality.
This data subverts the traditional perception that "testing mainly finds
programming errors"
Why Are Specifications a Defect Prone Area?
Accounting for 41% of software defects
1. Challenges of the Communication Gap
Users are mostly non-technical personnel, with a professional
language gap with the development team, leading to easy
deviations in the understanding of product functions.
2. Limitations of Imaginative Description Specifications are the key
The product has not yet been implemented, and system functions bridge connecting user
are described entirely by imagination, resulting in unclear and requirements and technical
inaccurate descriptions of certain features. implementation, bearing
3. Inconsistency in Requirement Changes the greatest conversion
User requirements change continuously, and the delayed update of
risks.
specifications is prone to contradictions and contextual conflicts.

4. Insufficient Attention and Resource Input

The team does not pay enough attention to specifications,
invests insufficient human and time resources, and lacks
adequate team communication.
2.1.5 Cost of Fixing Software Defects (Cost of
Poor Quality)
NIST Research Findings
• Software defects cause losses of tens of billions to hundreds
of billions of US dollars to the US economy every year.
• The cost of poor quality for most software enterprises
accounts for 40%~50% of the total development cost.
Core Insights
Cost of Poor Quality Includes The earlier a problem
is found, the lower the
• Defect repair workload
solution cost!
• Rework and retesting
• Losses from delayed delivery
• Decline in customer satisfaction
 Exponential Growth Model of Defect Costs
Boehm's Classic Theory (1981)
Core Findings:
• Cost of fixing in the requirements stage = Baseline value 1
• Cost of fixing in the design stage = 3～6 times the baseline
• Cost of fixing in the programming stage = 10 times the baseline
• Internal testing stage = 20～40 times the baseline
• External testing stage = 30～70 times the baseline
• After product release = 40～100 times the baseline
The cost of fixing errors grows exponentially, not
linearly! The earlier a problem is found, the greater the
cost savings.
Enlightenment: Testing must be involved in the project as early as
possible, and early investment brings huge savings in the later stage.
2.2 Software Testing
Classification System
Software Testing Classification System
p Classified by the object or scope of testing (e.g., Unit Testing, Document
Testing, System Testing, etc.)
p Classified by the purpose of testing (e.g., Functional Testing, Regression
Testing, Performance Testing, Reliability Testing, Disaster Recovery
Testing, Security Testing, Compatibility Testing, Installation Testing, etc.)
p Classified by whether the tested software is executed during the testing
process: Static Testing and Dynamic Testing
p Classified by whether the testing is completed based on the internal
structure and specific implementation algorithms of the system: White-box
Testing and Black-box Testing
Multi-dimensional Classification System
Testing Stages/Levels
Acceptance Testing

System Testing

Integration
Testing
Unit Testing

Methods
Performance Testing
Stress Testing White-box Black-box
Testing Testing
Functional Testing

Compatibility Testing
Reliability Testing
Security Testing

Objectives/Characteristics
2.3 Static Testing and
Dynamic Testing
Static Testing and Dynamic Testing
Evolution of the Concept: Generalized Testing vs Narrow Testing

Static Testing Dynamic Testing

Definition: Reviewing the requirement and design
specifications of software products, inspecting program code, Definition: Discovering errors by actually running the program.
and conducting static analysis without actually running the Mechanism: Observing the code running process, obtaining
tested software. information such as system behavior, real-time variable results,
Value: Implement the principle of "early testing", converting memory and stack, or analyzing the program's running status
quality costs from expensive later rework to early defect and discovering defects through input-output relationships.
prevention.

Early testing was limited to the dynamic execution of programs, while modern testing
has expanded to quality assurance activities throughout the development process.
2.3.1 Product Review
According to the definition of IEEE Std 1028—1988, a review is an evaluation method for the
status of software elements or projects to determine whether they are consistent with the
planned results and to drive their improvement.

1. Peer Review 2. Walk-through 3. Inspection

The deliverables completed by Party A

A systematic review method in The most formal form of collective
are inspected by Party B, and the
which others conduct a complete inspection involving multiple
deliverables completed by Party B are
inspection from start to finish. participants.
inspected by Party A.

Advantages: Mutual checks and balances, Advantages: High comprehensiveness, Advantages: High authority,
knowledge sharing. discovering in-depth problems. thorough problem solving.
Core Points of Requirement Review
Inspect the completeness, correctness and clarity of the requirement specifications.
Value of Early Involvement of Testers
Core Review Dimensions ✔ Identify potential risk points from a testing
Completeness Check perspective
• Whether requirements cover all user scenarios ✔ Ensure the testability of requirements
• Whether functional descriptions omit key elements ✔ Lay the foundation for subsequent test design
• Whether non-functional requirements are clearly defined

Correctness Verification
• Whether requirement expressions are accurate and
error-free
• Whether business logic conforms to user expectations
• Whether technical implementation is feasible
The cost of fixing problems found
Clarity Assessment
in the requirement stage is only
• Whether term definitions are consistent
1/100 of that in the later stage.
• Whether descriptive language is easy to understand
• Whether ambiguous expressions are clarified
Design Review and Code Review
Discover potential defects in system design and code implementation through
collaborative reviews.
Design Review Code Review
Check the rationality of system structure Organization of joint review process
- Whether the architectural design conforms to requirements - Programmers explain logic sentence by sentence
- Evaluate the rationality of module division - Team members ask questions and discuss
Analyze testability Key inspection content
- Whether the design facilitates test execution - Correctness of program structure and algorithms
- Completeness of test interfaces - Consistency of coding style
Verify database design - Standardization of global variable usage
- eview using standardization theories Types of problems discovered
- Consistency check of data schemas Logical errors and boundary conditions
Evaluate non-functional requirements Interface problems between modules
- Consideration of performance and security System structure parameter conflicts
- Check of extensibility design Global variable usage issues
 2.3.2 Technical Means of Static Analysis
In-depth analysis technology without running code

Manual Detection Computer-aided Static Analysis

• Inspect or review software entirely by manual work • Conduct feature analysis using static analysis tools
• Focus on checking coding style and algorithm logic • Extract key information from programs
• Discover security and internationalization issues • Check various defects in program logic
• Check code problems such as fault tolerance • Discover suspicious program constructs

Discover logical design errors that are not easily found by computer analysis

Unique Value of Static Analysis: Discover in-depth logical

problems without compilation and operation.
2.3.3 Verification and Validation

Software testing not only verifies

whether the program conforms to the
design, but also verifies whether it
truly meets the customer's business
demands. This is the famous V&V
theory.
The Connotation of Verification
Are we building the product right?
Definition: Verification is the process of checking whether the software has
correctly implemented the system functions and features defined in the product
specification.
• Key Focus Areas:
• Correctness
• Completeness
• Consistency
• Accuracy

Practical Significance: To determine whether each lifecycle activity is complete and whether the next
phase can be initiated.
Connotation of Validation
Are we building the right product?

Definition: Provide evidence to show whether the software truly meets the
actual needs of customers. Because the design specifications themselves
may have understanding deviations, verification alone is insufficient.
Key Characteristics:

1. A series of activities traceable to user requirements

2. Provide evidence that the software truly meets customer needs
3. Realized through various review activities
4. Involve customers in review and testing activities

Practical Significance:
Even if the software fully conforms to the design specifications, if the design specifications themselves
misunderstand the user requirements, the software is still a failure.
Dialectical Relationship Between Verification
and Validation A dual guarantee mechanism in quality assurance
Even if verification is passed, the product may still fail to meet user requirements!

Verification Validation
Are we building the product right?
Are we building the right product?
Inspect whether the software correctly implements
Inspect whether product functions truly meet user
the product specificationsI Both are
requirements
• Focus on internal consistency • Focus on external effectiveness indispensable and
jointly form a
- Conformity between code and design
complete quality
documents - Consistency between functions and user
assurance system.
- Matching between implementation and expectations
specifications - Accuracy of requirement understanding
- Standardization level of the development - Achievement of customer satisfaction
process

Verification ensures "doing things right" ↔ Validation ensures "doing the right things".
2.4 Active Testing and
Passive Testing
 2.4 Active Testing and Passive Testing
Comparison of Testing Methods in Controlled vs Production Environments
Active Testing Passive Testing
Active testing is the most common To solve the limitations of product
method in software testing, which online testing, the passive testing
emphasizes the tester's absolute method came into being. It
control over the testing process and emphasizes "non-intervention" and
the tested object. "real environment".
Definition: Testers actively Definition: The software product runs in
send requests to the tested the actual environment, and testers
object, or drive the behavior passively monitor the operation of the
of the tested object with the product without intervening in it. Obtain
help of data and events, so as the system operation data including input
to verify the response or and output data through certain passive
output results of the tested mechanisms.
object. Key Difference: Active testing emphasizes control, while passive testing
emphasizes observation.
2.5 Black-Box Testing &
White-Box Testing
2.5 White-Box Testing (Structural Testing)
The Testing Philosophy of Seeing Through the Internal Structure of Programs
What is White-Box Testing?？

l White-box testing, also known as structural testing

or logic-driven testing.
l Testers are aware of the internal working process
and computer program structure of the product.
l Verify whether each path works as intended by
checking the internal variable state, logical structure
and operation path.

The essence of white-box testing: Delve into the inside of the

program like a detective, and check every logical branch and
execution path with a magnifying glass.
Basic Principles and Coverage Requirements of
White-Box Testing
Delve into the inside of the program to ensure the sufficiency and effectiveness of testing.

White-box testing follows four core principles:

1. Branch Coverage Priority

Ensure that all branches in the program are covered during test execution.
[Link] Condition Completeness
Complete tests where all logical conditions are evaluated as True and False respectively.
[Link] Path Traversal
For higher quality requirements, ensure that all independent paths in the flow chart are
run at least once.
4. Internal Data Structure Check
Check the internal data structure, pay attention to the impact of context, and ensure
the effectiveness of testing.
Limitations of White-Box Testing
Why is 100% Path Coverage Still Insufficient?
Core Problem: An astronomical number of paths.
Brief explanation that traversing all paths in a reasonably sized system is
mathematically impossible.

[Link] Spot in Detecting [Link] Dangers of [Link] Spots for Data-Related

Violations of Design Specifications Missing Paths Anomalies
The program runs Some business logic Abnormal behavior under
perfectly, but does not branches that should different data states on the
implement the functions exist are completely same path.
the user needs. omitted.
Black-Box Testing (Data-Driven Testing)
What is Black-Box Testing?
Treat the program as an unopenable black box, and conduct testing without considering
the internal structure and internal characteristics of the program at all.

l Requirement Alignment: Verify whether each function

of the product can be used normally and meets user
requirements.
l Integrity: Test the entire tested object (rather than
internal code variables).

Black-box testing does not focus on the internal structure of the software, but on the external user interface
of the program, the input and output of the software, and user requirements, to directly obtain the user
experience.
Types of Defects Commonly Detected by Black-
Box Testing
Identify problems in the external performance of the software from the user's
perspective.
l Functional Defects
1. Defective functions or missing certain functions.
2. Failure to receive input data correctly and output wrong
results.
l User Interface Defects
Black-box testing focuses on the
Distorted, incorrect or unattractive interface display. external performance of the
l Operation Experience Defects software and verifies whether the
Irrational and inconvenient functional operation logic. system meets the requirements of
l System Integration Defects the specification from the user's
1. Problems during the installation process, unclear and perspective.
inflexible installation steps.
2. System initialization issues, etc.
Combination Matrix of Static/Dynamic and
White-Box/Black-Box
White-Box Testing Black-Box Testing

Static white-box testing Static black-box testing

Review of requirement
Static Testing Syntax check, scanning documents and
and review of source code specifications
Dynamic white-box testing Dynamic black-box testing
Result check, verification
Dynamic Testing Data-driven functional
and debugging while
testing of software
running code
[Link] four methods complement each other and are irreplaceable.
[Link] the appropriate combination according to the tested object.
[Link] methods have low costs, while dynamic methods are more
comprehensive.
2.6 Basic Levels of Software
Testing
2.6 Basic Levels of Software Testing
Laying a Solid Foundation for Building a
Reliable System
Functions, user
interface, security,
efficiency, user
Acceptance Testing acceptability

System functions,
System Testing security, robustness,
efficiency

Integration Testing
Interfaces between components
Unit Testing
Component functions,
Implementation (Coding) robustness, efficiency

Tes
t
Unit Testing
Laying a Solid Foundation for Building a Reliable System
Unit testing is a test conducted on the smallest units (classes, functions, modules, components) in a
program system, mainly using white-box testing methods to check the consistency between the
implemented functions and the defined functions.
• What to test? The smallest units in the program system, such as a class, a function or a
component.
• How to test? Mainly use white-box testing methods to delve into the internal code logic and
check for coding errors.
• Who tests? Usually completed by programmers (developers) and testers together, with
programmers playing a leading role.
Integration Testing: Big-Bang Integration and
Incremental Integration
A Comparison of Two Strategies for Finding Unit Interface Problems

What to test? Interface problems after units are assembled together, such as whether data
transmission is lost, whether parameter types match, and whether errors accumulate.

Test each unit separately first, then assemble

all units together for testing, and finally
Big-Bang Integration obtain the required software system.

Test two or three units first, then gradually assemble

these units into a larger system. During the assembly
process, test while connecting to find problems arising
during the connection process, and finally complete
Incremental Integration the integration of all units to construct a complete
software system.
System Testing: Combination of Functional and
Non-Functional Dimensions
What to test? Conduct a comprehensive test on the complete application system,
mainly divided into two parts:
✔ Functional Testing Dimension 🛡 Non-Functional Testing Dimension
From the user's perspective in the Intensively test the system in the
actual or simulated operating actual or simulated operating
environment, test: environment to verify:
[Link] capacity
[Link] interface
[Link]
[Link] operations
[Link] input and output [Link]
[Link] functions [Link] recovery capability after
... crashes...
Acceptance Testing and Alpha/Beta Testing Process
What to test? Demonstrate to future users that the system can work as intended, and verify
whether the software is consistent with the actual user requirements.

• Alpha Testing: Trial use by internal

company personnel in a simulated
real environment.

• Beta Testing: Trial use by typical

external users of the company, who
report anomalies and opinions.
2.7 Test Plans and Test Cases
2.7.1 Software Testing Management Process: Test
Plan
Test Plan = Preparation Work + Dynamic Management

1. Workload 2. Resource and

estimation schedule The Importance of
arrangement Dynamic Adjustment
A test plan is not a static
3. Risk document and needs to be

assessment and 4. Strategy continuously optimized

management formulation according to project

changes.
Core Components of a Test Plan Document
Six Core Elements of a Test Plan:
1. Objectives and Scope: Clarify what we will test and what we will not test.
2. Project Estimation: Calculate the required costs, human resources and
project duration.
3. Risk Plan: Analyze and identify potential risks in testing, and formulate
strategies for risk avoidance, monitoring and management.
4. Schedule Arrangement: Define the tasks to be completed at each stage
(usually presented with a Gantt chart).
5. Resource Allocation: Allocate computers, servers, testing tools and human
resources reasonably.
6. Tracking and Control: Establish processes for bug reporting, repair and
retesting.
2.7.2 Definition of Test Case
What is a Test Case?
A test case is a specific use case or scenario designed for a specific testing purpose,
including test conditions, test data and relevant test procedures. It is the smallest test
execution unit for effectively discovering software defects.
Core Components of a Test Case:
• Test Conditions: Preconditions and environment settings required for test execution.
• Test Data: Specific values of input data and expected output results.
• Test Procedures: Detailed operation steps and verification methods.
• Specific Scenarios: Targeted business scenarios or use cases.

Test Case vs Test Script

Test Case: Test guidelines for manual execution. Test Script: A collection of instructions for automatic
execution by tools.
Functions and Design Process of Test Cases
Four Core Functions of Test Cases Standard Design Process of Test Cases
[Link] important 1. Formulate Strategies: Define the strategies and ideas
reference basis for test for test case design, and record them clearly in the
execution.
test plan.
2.A guarantee for the
implementation of 2. Design Framework: Design the macro framework
efficient testing. and hierarchical structure of test cases.
3. Refine and Deliberate: Refine the structure and
[Link]
gradually design specific test cases (including
accumulation and
continuous improvement. preconditions, input data, execution steps and
expected results).
[Link] for 4. Review and Optimize: Continuously optimize and
regression testing.
improve the test case set through internal or multi-
party reviews of test cases.
2.8 The Responsibilities and
Requirements of Professional
Testers
2.8 Responsibilities and Requirements for
Professional Testers
Core Responsibilities and Value Embodiment of Test Experts
Responsibility 1: Problem Discovery and Responsibility 2: Quality Assessment and
Supervision of Resolution Status Feedback
Discover problems in software programs, Evaluate software quality comprehensively and
systems or products as early and as much objectively, and provide the current quality status
as possible. of the project in a timely manner.
Supervise developers to fix program Continuously provide feedback on the quality of
defects as soon as possible. software products and expose product quality
risks.
Responsibility 3: Professional Responsibility 4: Defect Analysis and
Competence and Efficiency Improvement Prevention Guidance
Be responsible for the quality and efficiency Conduct root cause analysis of defects and abstract
of quality work, and act as the Test Owner. defect patterns.
Become a test expert, continuously improve Help the team do a good job in defect prevention and
testing methods and enhance test efficiency. establish a quality assurance system.
Combination of Testing and Quality Assurance (QA)
Role Expansion from Tester to Quality System Builder

Traditional Testing Responsibilities Expanded Quality Assurance Responsibilities

[Link] Improvement and Collaboration
l Discover software defects and Cooperate closely with marketing, design, development, configuration
supervise their repair. and other departments.
l Evaluate the status of software [Link] Monitoring and Optimization
Track and review the entire product development process.
quality.
[Link] Analysis and Improvement
l Provide quality feedback and risk Analyze the advantages and characteristics of competitors' products.
early warning.
l Be responsible for the quality and Quality Assurance = Defect Prevention + Postinspection
efficiency of testing work. Testing provides data support for QA, and QA guides the
direction of testing.
Technical and Comprehensive Requirements for
Professional Testers
Correct the Misconception that "Testing Has a Low Threshold"
Qualities of an Excellent Test Engineer (1):
Sense of Responsibility and Communication
Sense of Responsibility - Communication Ability -
Guardian of Quality Builder of Bridges
[Link] pursuit of quality. [Link] with users: Understand real needs
[Link] to viewing problems from the and avoid professional terms.
customer's perspective. [Link] with developers: Delve into technical
[Link] not let go of any possible doubts. details and use professional language.
Pay full attention to details and always put [Link] resolution: Focus on the product, not
quality first. individuals.
[Link] schedule pressure to ensure the [Link] skills: Point out errors fairly and
sufficiency of testing work. maintain team harmony.

Only with a high sense of responsibility can the An excellent test engineer can communicate
reliability of testing work be guaranteed. well with both users and developers.
 Qualities of an Excellent Test Engineer (2):
Technical Ability and Self-Confidence
Technical Ability: Self-Confidence: Adhere to Correct
Foundation of R&D Work Views
[Link] and Development Experience [Link] Doubts from Developers
Understand the principles of system architecture Have confidence in the bugs you report, not be easily
design, have code review capabilities, and be able to influenced by others, and maintain the independence
develop test tools and automated scripts. of testing work.
[Link] Technical Knowledge [Link] Design Problems
Master operating system configuration and Dare to challenge the logical problems of
troubleshooting, network technology and database specifications, conduct professional discussions with
management, performance tuning and security product designers, and adhere to the correct
testing. understanding of user requirements.
[Link] of Testing Methods [Link] Resolution
Not limited to black-box testing, combine with Speak based on facts and data, maintain a professional
white-box testing methods to improve test efficiency attitude, and promote the fundamental solution of
and coverage. problems.
Qualities of an Excellent Test Engineer (3):
Patience and Skeptical Mindset
Patience Skeptical Mindset
[Link] in Repeated Execution [Link] All Explanations
The same test case may need to be run dozens or even Developers will try to downplay errors; stay highly alert
hundreds of times and verified repeatedly in different and do not easily accept unreasonable explanations.
test environments. [Link] Judgment Ability
[Link] on Solving Complex Problems Listen to everyone's explanations patiently and make
Spend a lot of time separating and identifying errors, decisions only after personal analysis or testing.
and understand the occurrence rules of errors under [Link] Design Rationality
specific conditions. Maintain a skeptical attitude towards functional design
[Link] with Heavy Workload and implementation, and explore better implementation
Maintain concentration and execution quality when methods.
facing the execution of hundreds of test cases.

The Art of Balance：Maintain a skeptical mindset while avoiding over-skepticism; be

patient when performing repetitive tasks and use automated tools to improve efficiency.
Qualities of an Excellent Test Engineer (4):
Curiosity, Insight and Thinking
1. Moderate Curiosity The Art of Balance:
Explore uncharted territory like an exploration expert groping in a cave —
unexpected discoveries may be made. Keep a balance between completing
test tasks in a timely manner and exploring the root causes of errors;
curiosity should be moderate and not excessive.
Explore the Unknown,
[Link] Insight
Insight into the
Design test cases that cause system boundary errors and use error guessing to
Essence, Think in
design destructive test cases.
Reverse
3. Reverse Thinking and Divergent
Thinking
Consider all possible ways the product may fail and test the system with strict
boundary conditions.
Force the system to handle "impossible" errors and conduct negative testing to
expose problems to the maximum extent.