How To Define Dynamic Insights: Path Testing & Static Techniques

This method is the oldest structural testing technique. It is based on the control structure of the path testing program. Based on the control structure. a flow graph is prepared and all the possible paths can be covered and executed during testing. This method is useful for detecting more errors.

However, if a program contains loops may have an infinite number of possible paths and it is not practical to test all the paths. Hence some criteria should be devised such that selected paths are executed for maximum coverage of logic. The effectiveness of path testing gets reduced with the increase in size of software under test.

Steps for effectiveness of path testing:

“C:\Users\91762\Downloads\adbwinapi.zip”

This is a path.
  1. Draw the flow graph based on program structure.

Flow graph can be prepared as directed graph using the following notations:

  • Node: It represents one or more procedural statements. It is denoted by a circle with label or number.
  • Edges or links: They represent the flow of control in a program. It is denoted by arrow and it must terminate at the node.

Decision node :

 A node with more than one arrow leaving it is called a decision node.

Junction node:

A node with more than one arrow entering it is called a junction node

Regions: area bounded by edges and nodes are called regions. When counting the regions, the area outside the graph is also considered a region.

Path A path is a sequence of instructions or statements that starts at an entry. junction or decision node and ends at another or possibly the same, junction, decision or exit. It may go through several junctions, processes Or decisions, one or more times.

Statement: A single process that lies between two nodes(junction-process-junction. junction-process-decision,deCIS1On -process-junction, decision-process-decision) The smallest segment is a link.

Path segment: A path segment Sa session or consecutive links that belong to some path.

Length of path: It is measured by number of links in a path and not by the number of instructions or statements executed along the path. Or number of nodes traversed in a Path is known as length of path.

Independent path: It is any path through the graph that introduces at least one new of processing statement or new condition. It must more along at least one edge that has not been traversed before the path is defined.

Sequential statements having no conditions or loops can be merged in a single node, hence the flow graph is also known as decision-to-decision-graph or DD graph.

  1. Determine the cyclomatic complexity of the flow graph.

McCabe has given a measure for the logical(cyclomatic) complexity of a program by considering the number of paths in the control flow graph by considering independent paths only.

The number of independent paths is given by where n is the number of nodes and is the number of edges(arcs). It may be possible that the graph is not strongly connected, in that case one more edge is added from the last node to the first node of the graph, therefore, the number of We can calculate the cyclomatic number only by knowing the number of choice points (decision nodes) d in the program. It is given by This is also kwon as Miller’s theorem. We assume that K-way decision point contributes for k-l choice points.

The program may contain several procedures also and represented as separate flow graphs. If is the number of graphs and and n are referred to as the whole graph, the cyclomatic number of the whole graph is then given by Cyclomatic complexity number can be derived through any of the following three formulae:

path testing and static path

 Static Testing:

Static testing techniques don’t execute the software and don’t require the bulk of test cases. This type of testing is also known as non-computer based testing or human testing. It reveals errors which are not shown by dynamic testing. It can be applied for most of the verification activities.

It is done to avoid errors at an early stage of development as it is easier to find sources of failures then failures themselves. It checks the software product at each SDLC stage for conformance with the required specifications or standards.

Some of the advantages of it are:

  • It detects bugs with the exact location of a bug and fixed, hence the quality of the product increases,
  • ore technically correct base is available for each new phase of development. Overall software life cycle cost is lower. As bugs are found at early stage, less time requires testing product.

Types of static testing:

 Software Inspection:

Software inspections were first introduced at lBM by Fagan in the early 1970. It can be used to tackle software quality problem because they allow the detection and removal of defects after each phase of the software development process.

It may be applied to any product or partial product of the software development process, including requirements, design and code, project management plan, SQA plan, software configuration plan, risk management plan, test cases, user manual etc.

This process doesn’t require executable code or test cases. It means it doesn’t execute the code. So it is machine-independent, requires no target system resources or changes to the program’s operational behaviour and can be used much before the target hardware is available for dynamic testing purpose.

It is a more formal process. This process is carried out by a group of peers. The group peers first inspect the product at the individual level, then they discuss the potential defects of the product observed in a formal meeting.

i.e. Formal peer evaluation of a software element whose objective is to verify that the software element satisfies its specifications and conforms to standards.

For the inspection process minimum of the following team members are required as Inspection Team.

Author/Owner/Producer:

A programmer or designer responsible for producing the program or document. He /She is also responsible for fixing defects discovered during the inspection process.

  • Inspector: A peer member of the team, that is, He She is not a manager or supervisor nor direct related to the product under inspection. He /She finds errors, omissions an inconsistencies in program and documents.
  • Moderator: A team member who is a key person or responsible for successful planning, execution and who manages the whole inspection process.

Who is also responsible for the following activities:

Scheduling meeting venue & time, leads & controls the inspection process. Checking for the product availability for inspection. Selecting inspection team & assign their role Distributing inspection material as to be tested

  • Recorder: A member who records all results of the meeting. Inspection Process stages/steps:

1) Planning: It includes the following activities:

The product to be inspected is identified. A moderator is assigned. Objectives are defined like to detect defect or else, what kind of defects to be detected(requirements/ design/code) etc.

During this phase moderator performs the following activities:

Assures that the product is ready for inspection Selects the inspection team and assigns their roles Schedules the meeting venue and time. Distributes the inspection material such as the item to be inspected and checklists.

2) Overview:

Define or explain the objectives/purpose of the meeting to team members with the background information. The author presents the rational for the product, its relationship to the rest of the products being developed, its functions and intended use, and the approach used to develop it.

3) Individual preparation:

After the overview, the reviewers individually prepare themselves for the process of inspection by studying the given documents. They find defects with the help of checklist & record them in a log form & finally submit that log to moderator.

Moderator checks whether the reviewers have done work adequately or not. If yes, then moderator checks for defects that may need extra attention during inspection and compiles different logs files & submit to author. If not done then, moderator reschedules the meeting.

4) Inspection meeting:

In this stage author starts meeting by discussing every issue reported in compiled log Every activity of the meeting should be constructive so that more & more defects can be discovered. At the end of meeting, moderator prepares a summary report.

5) Rework:

The summary list of the bugs that arise during the inception meeting needs to be reworked by the author & all bugs should be fixed & reported back to moderator.

6) Follow-up:

It is the responsibility of the moderator to check that the bugs detected in last meeting have been addressed & fixed. Then document is approved for release. If not then another inspection meeting is schedule.

Advantages of Inspection Process:

Bug reduction and prevention from previous experience of inspection. As it is done early, reduced cost of finding bugs & increases productivity. It gives real-time feedback to developers.

Resource requirement is reduced as bugs are detected & fixed at their correct place. hence dynamic testing efforts is reduced. It improves quality. It is useful for monitoring project progress. Coupling& Cohesion can be checked easily Team members learn some point like various types of defects, why they occur etc. through the meeting & discussion.

(2) Structured Walkthrough:

The idea of structured walkthrough was proposed by Yourdon. It is less formal meeting & less rigorous. i.e. doesn’t required preparation. It has fewer steps.

It doesn’t use a checklist to guide or a written report to document the team’s work. In this, tester comes with a small set of paper test cases during the meeting. Test cases have inputs & expected outputs, and each test case is mentally executed.

i.e. test data is walkthrough the logic of a program. It should have a follow-up process similar to the described in the inspection process.

The steps of a walkthrough process are show in below given figure

  • A type structured walkthrough team consists following members with their role:
  • Coordinator: Organizes, moderates and follow up walkthrough activities
  • Presenter/Developer (Optional): Introduces the item to be inspected.
  • Recorder: Note down the detects sound & suggestions proposed by members
  • Reviewer/Tester: Finds the defects in the item
  • Maintenance Oracle: Focuses on long term implication and future maintenance of the project.
  • Standard Bearer: Assesses adherence to standards
  • User Representative/Accreditation Agent: Reflects the needs and concerns of the user.

(3) Technical Review:

Technical review is intended to evaluate the software in the light of development standards, guidelines and specifications & to show that the development process is being carried out according to the stated objectives.

A review is similar to walkthrough and inspection, except that the review team also includes peers & technical expert with management; hence it is high level technique compare to walkthrough & inspection.

A review team is generally comprised of management-level & project management. The purpose is to evaluate the system relative to specifications and standards and recoding defects and deficiencies.

In this process, a moderator should gather and distribute the documentation to all team members for examination before the review. He/ She should also prepare a set of review.

4) indicators to measure:

Appropriateness of the problem definition & requirements.

  • Adequacy of all underlying assumption
  • Adherence to standards
  • Consistency
  • Completeness
  • Documentation

Moderator may also prepare a checklist to help the team focus only on the key points. At the end a report should be prepared which includes deficiencies identifies & reviewer’s recommendations.

Last Post White box testing

follow on twitter

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *