Static Testing techniques
Lecture 03
Copyright By PowCoder代写 加微信 powcoder
What is static testing
Static Testing vs Dynamic Testing
Review-based static testing
Informal review
Walkthrough
Technical reviews
inspection
Static analysis and tools
Code standards
Code metrics
Code structure
What are we upto?
Fundamentals of Testing – Test Process, Test Principles…
Testing throughout the software development life cycle – Test Levels, Test types…
Test Types
functionality
reliability
efficiency
portability
Code coverage
Confirmation
Regression
Functional Testing
Structural Testing
Non-Functional Testing
Maintenance Testing
Test Types
functionality
reliability
efficiency
portability
Code coverage
Confirmation
Regression
Functional Testing
Structural Testing
Non-Functional Testing
Maintenance Testing
Functional Testing
Test of functions, Tests “What it does?”
if the functions of component or system is done.
Black-box techniques are useful
Approaches
Requirement-based: the requirements are prioritized depending on the risk criteria and accordingly the tests are prioritized.
Business Process-based: Test based on the scenarios involved in the day-to-day business operations
Non-Functional Testing
Testing of software characteristics
Reliability Testing: tests if system shows consistent performance for a specified period of time
Usability Testing: tests that whether the application or the product built is user-friendly or not
Efficiency Testing: how much resources were consumed how much of these resources were utilized.
Portability Testing: how easy it is to move the software from one environment to another
Recovery Testing: check how fast and better the application can recover after it has gone through any type of crash or hardware failure
Non-Functional Testing continues
Performance Testing: how fast some part of the system performs under a particular workload
Security Testing: checking confidentiality, integrity, authentication, availability, authorization and non-repudiation
Load testing: test to determine a system’s behavior under both normal and at peak conditions
Volume Testing: test how much data size the software can handle
Stress Testing: testing beyond normal operational capacity, often to a breaking point, in order to observe the results.
Test design techniques
Figure from the textbook
static testing
Testing a work product without code being executed.
Objective is to improve the quality of software work products by assisting engineers to recognize and fix their own defects early in the software development process.
How static testing techniques fit into the overall test process?
Static testing improves test quality and productivity.
It should not be replaced with dynamic testing.
Static Techniques include:
Reviews and
Static Analysis
Static analysis
The process of evaluating a component or system without executing it, based on its form structure, content or documentation.
It involves the use of tools to do the analysis also can be termed as tool-driven evaluation of code.
Static vs. dynamic
Dynamic Testing
Concerned with exercising and observing system behaviour to discover defects
Tests the software product by executing the code
Static Testing
Concerned with analysis of the static system representation to discover defects
Tests the software product manually, or with a set of tools, but they are not executed
Static vs. dynamic
Requirements defects – no data: static testing is good since finding defects early is cheaper- e.g inconsistencies, ambiguities etc.
Design defects – static testing is more efficient and more effective e.g. inefficient data structure, algorithm etc.
Code defects – dynamic testing (white-box and black-box) more efficient, e.g. variables declared never used, duplicate code etc.
Security Vulnerabilities, for example buffer overflow susceptibility.
Traceability Problems, such as gaps or lack of coverage etc.
Modularity defects such as poor reusability etc.
In general
Static testing finds 25-50% of an artefact’s defects
Dynamic testing finds 30-60% of defects in code
Static Testing
Not detailed testing, but checks mainly for the sanity of the code, algorithm, or document
Starts early in the development life cycle – from user requirement gathering and design stage
Defects less expensive to fix
Does not need computer as the testing of program is done without executing the program
Work products that can be examined by static testing
Specifications: Business, functional requirements, security requirements etc.
Epics, User stories, and acceptance criteria.
Code. (e.g. dead code, code that will never be executed etc.)
Testware – Test plans, test conditions, test cases, test procedures, automated test scripts.
User guides, help text, wizards etc.
Contracts, project plans, schedules, and budgets.
Models – activity diagrams, or any other to used in Model-based testing (MBT)
Early feedback and increased awareness on quality issues
Rework cost most often relatively low
Development productivity likely to increase
Defects are more efficiently detected and corrected since it is done before dynamic testing.
Defects in future design and code are prevented by uncovering inconsistencies, ambiguities, contradiction, inaccuracies, redundancies etc.
Improved communication within the team.
Types of the defects that are easier to find using the static testing
deviation from standards,
missing requirements,
design defects,
non-maintainable code,
Unreachable (dead) code,
inconsistent interface specifications.
Review Process
A type of static testing during which a work product or process is evaluated by one or more individuals to detect issues and to provide improvements.
Two types of reviews:
Informal Review – without a formal (documented) procedure.
Formal Review – which follows a formally documented output.
Formal Review
Formal reviews follow a formal process.
It is well structured and regulated.
Six main steps;
Steps activities
1.Planning Defining the review criteria.
Selecting the personnel and Allocating roles.
Selecting which parts of documents to review.
2. Kick-off Distributing documents.
Explaining the objectives, process and documents to the participants.
3. Preparation Preparing for the review meeting by reviewing the document(s).
Noting potential defects, questions and comments.
4. Review meeting Discussing or logging, with documented results or minutes.
Noting defects, making recommendations regarding handling the defects, making decisions about the defects.
5. Rework Recording or Fixing defects found (typically done by the author).
6. Follow-up Checking that defects have been addressed.
Formal Review: roles and responsibility
Roles responsibilities
The moderator known as review leader
Schedules the meeting
Coaches other team
Leads the possible discussion
Follow-up on the rework
The author Is the writer of the document under review
Illuminate the unclear areas and understand the defects found
The scribe Records (e.g., logs) the defects found during the review
The reviewers Also known as checkers or inspectors
Check any material for defects, mostly prior to the meeting
The managers Manager decides on the execution of reviews
Allocates time in project schedules and determines whether review process objectives have been met
Review-based Technique
Informal Reviews
Walkthrough
Technical Review
Inspection
Level of formality
Informal reviews
Doesn’t follow any process to find defects in the document
At this stage, only two people team may be sufficient
Conducted many times during the early stages of the development life cycle
Meetings are NOT documented
For example: buddy check, pairing, pair review.
Walkthrough
Led by the author of the document under review
May vary from informal to formal
Use of scribe is mandatory
Use of checklists is optional
Examples: scenarios, dry runs, or simulations.
The main purpose;
Enable learning about the content of the document under review
Help team members gain an understanding of the content of the document
Find defects
Technical Review
Led by a moderator but can also be led by a technical expert
Scribe is mandatory, ideally not the author.
It is often performed as a peer review without management participation
Technical reviews may be quite informal or very formal
The main purpose;
Not limited to discussion but also decision making,
finding defects and evaluation of alternatives, and solving technical problems.
Gaining consensus.
Inspection
The inspection process is the most formal type of review based on rules and checklists
Led by a trained moderator, who is not the author of the code
Preparation before the meeting is essential
It usually involves peer examination of the code and each one has a defined set of roles
The main purpose;
Find defects
An inspection report lists the (defect) findings and process to correcting defects
A formal follow-up process to ensure corrective action is completed in a timely manner.
Evaluating quality and building confidence in the work product.
Review methods
Comparison
Methods Goals Attributes
walkthrough Cost very low
Minimal overhead
Developer training
Quick turnaround
Little/no preparation
No formal process
No measurement
Technical review Cost moderate
Defect discovery
Ambiguity discovery
Some formal process
Wide range of discussion
inspection Cost very high
Defect and remove all defects efficiently and effectively
Preparation is MUST
Very formal process
Measurement and follow-up
What is static testing
Review-based static testing
Informal review
Walkthrough
Technical reviews
inspection
Static analysis and tools
Code standards
Code metrics
Code structure
Static Analysis
Performed on requirement design or code without actually executing the software or before the code is actually run
Goal of static analysis is to find the defects whether or not they may cause failure
Static analysis find defects rather than failures
Static Analysis tools (1)
Checks incorrect usage and checks for non-compliance to coding language conventions or syntax
Code Standards
Checking programming rules, naming conventions, layout specification etc.,
Code Metrics
Checks the depth of nesting, complexity of nesting, number of lines of code
Static Analysis tools (2)
Code Structure
Control flow structure: Addresses the sequence in which the instructions are executed.
Data flow structure: Follows the track of the data item as it is accessed and modified by the code.
Data structure: Refers to the organization of the data itself, independent of the program.
Applying Reviewing Techniques
Ad-hoc Reviewing : Technique carried out by independent reviewers informally, without a structured process.
Checklist-based reviewing: technique guided by a list of questions and required attributes
Scenario-based reviewing: technique where the review is guided by determining the ability of the work product to address specific scenarios.
Role-based reviewing: technique where reviewers evaluate a work product form the perspective of different stakeholder roles.
Perspective-based reviewing: technique whereby reviewers evaluate the work product from different viewpoints.
Success Factors for reviews
Organisational success factors for reviews
Have clear objectives
Pick the right review type and technique
Review materials need to be kept up to date
Limit the scope of the review
It takes time
Management support is critical
People-related success factors for reviews
Pick the right reviewers
Use testers
Each participant does their review work well
Limit the scope of the review and pick things that really count.
Defects found should be welcomed
Review meetings are well- managed
Truth is critical
How you communicate is essential
Follow the rules but keep it simple.
Train participants
Continuously improve process and tools
Just do it!
We covered Chapter 3 of the text book: static techniques
We examined “what is static testing?” and compared it with dynamic testing approach
We examined review-based static testing techniques which includes; Informal Review, Walkthrough, Technical Review, and Inspection
We examined the purpose of the static analysis and tools used for it; complier, code standards, code metrics, code structure
financial stock market graph
.MsftOfcThm_Accent1_Fill {
fill:#4D1434;
.MsftOfcThm_Accent1_Stroke {
stroke:#4D1434;
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com