Basic theory-IBM model of software testing

Basic theory of software Testing (1) IBM Production Model 1 bibliography

"ibm-from rookie to test architect-a growth diary for a test engineer"

• Publishing house: Electronic Industry publishing house
• Impressions: June 2013
• IBM Principal Engineer

2 Important Reminders

Warning

IBM's business nature is to do large enterprise IT solutions, still belong to the relatively good traditional enterprises. Therefore, the traditional software enterprises have a relatively large reference significance, but for the internet and other emerging enterprises practitioners, or adopt a reserved attitude, take its essence can.

3 time background of test generation

The 1968 NATO conference proposed a "software crisis":

• Fragile
• Unreliable
• Lack of security
• Performance degradation
• Error
• Difficult to upgrade
• 73% of software projects are delayed/over-funded/canceled or failed

4 Software testing purposes-IBM

• Ensure software Quality
• Reduce the quality problem to the enterprise and the user brings the hidden danger

5 Status of the test

The theory and practice of testing have been perfected gradually, but the methods and systems of testing are not discussed in completeness.

6 Test classification

• Test classification

  1. Installation test
  2. Build Tests
  3. White box test
  4. Black box test
  5. Performance testing
  6. Migration test

• Objective

  Determine the stability and robustness of the software from installation to use and later maintenance.

7 Getting Started with beginners

• Testing is a rigorous, comprehensive and methodical process

• Test need to have focus 2/8 principles)

  In addition to small projects, it is not feasible to perform complete tests (combinations of various inputs and preconditions). Risk analysis and test prioritization of different system functions are needed to determine the focus of the test and thus replace exhaustive testing.

8 Unit Test

Definition: The developer tests the correctness of the program module (the smallest unit of software design).

• Unit testing is the closest test to development

• Written by developers. The developer writes the unit test case and executes it to verify that the unit module is producing the expected results

• Unit testing is a software test with minimal granularity

  • Procedural programming: Single program, function, process
  • Object-based programming: Methods, base classes, abstract classes, derived classes

• Subsystems are integrated into large systems only after unit testing

9 White Box test

Definition: A test in which a tester can directly access internal data results, algorithms, and their code implementations.

A common approach:

• Interface Test
• Code Coverage Testing
• Defect Injection Method

10 difference between "unit test" and "White Box test"

1. Different test items

   • "White" is the overall logic of the test program
   • "Single" is a separate module in the test program.

2. Different executive Staff

   • White box is usually done by a special white box tester
   • Unit tests are usually done by the programmer himself

11 Functional Test (black box test)

Definition: Testing of functional issues that exist after code integration is discovered through black box mode.

• The focus is on the function of the system
• Test cases can be executed automatically or manually

and unit tests : different granularity.

• Unit testing is concerned with minimal code snippets
• Functional testing is concerned with a complete business function

12 Performance Testing

• Focus on

  Testing the non-functional requirements of the software

• Responding to complex and demanding user scenarios

  • Throughput rate
  • Stability
  • Reliability

• Main means

  Simulate scenarios where real users are accessing concurrently through automated methods

• Ultimate Purpose

  • Verifying system performance metrics or discovering their performance bottlenecks
  • Fundamentally ensure user experience and long-term benefits

13 Manual Test Features

• Advantages

  • Convenient and flexible
  • Low initial input Cost
  • Low personnel quality requirements

• Disadvantages

  • Low efficiency
  • Large repetition overhead
  • Difficult to emulate complex usage scenarios, such as: concurrent or continuous transactions

14 Automatic test features

• Advantages

  • High efficiency, providing a strong productivity
  • Small recurring activity overhead
  • Basically can simulate any complex usage scenarios, except Turing test
  • Weakening the impact of individual differences in software testers

• Disadvantages

  • High initial cost of investment
  • High cost of change
  • High quality of personnel requirements

15 Automation vs Manual testing (1)

• Form good complementarity, 2/8 principles

• Local conditions Test ROI ratio. ROI algorithm

  • Stable, continuous iterative, incremental development, process hardening (current mainstream Internet mode), suitable for automation-based
  • Demand instability, one-time project tasks (traditional software industry mainstream model), suitable for manual-based

• Creative work deliverables for people to do, repetitive work delivery machines to do

• Large projects for automated testing, small projects for manual testing

16 Automation vs Manual testing (2)

Estimating the need for automated scripting development:

• Automated test cost = Script Development cost + (average Debug script cost + average execution script cost) x number of test executions
• Manual Test cost = Average manual effort x number of test executions
• roi= Automated test cost/manual test cost

17 Automation vs Manual testing (3)

Small-scale project cost comparison chart:

Analysis:

• Small-scale testing is basically manual and automatic and can be applied
• At a very small scale, the cost of manual is a big advantage
• As the number of regression increases, the cost of manual increases linearly, and automation costs tend to stabilize.

18 Automation vs Manual testing (4)

Large-scale project cost comparison chart:

Analysis:

• Software projects are prone to snowball effects as they grow in size
• Manual testing quickly encounters ceilings, which can be a barrier to cost and operability, with input costs increasing much higher than development cost increases
• Automation will become mainstream, the growth of basic costs and development of the cost of investment is quite

19 Waterfall mode and agile mode

• Waterfall mode

  • Process Strict Partitioning: Requirements analysis/design/implementation/testing/integration/Maintenance
  • The Division of labor is clear, but the spirit is poor, project failure risk is big

• Agile Mode (development)

  • Iterative development (iterative development)
  • Incremental development (Incremental development)
  • Dividing the complete process into multiple iterations with shorter durations
  • Enables continuous integration
  • Good project risk control and project continuous production capacity

20 Software Process automation

• Build automation

  Automation is assembled from the source code of each module into a complete product

• Test automation

  Automatically complete the appropriate test work before building

• Deployment automation

  Automated deployment to production servers for finished product testing with built-in products tested

21 Automatic occasions Selection

• Try to automate stable objects, such as API interfaces
• GUI is not recommended to use automation, return on investment is too low, change big

22 Automation Scale

• The development of automation scripts is not as early as possible, but should be based on a stable test environment and test plan.

• Experienced test engineers will find a balance between efficiency and quality, concentrating on the most problematic points.

• Automation scale

  • Automated Test selection for API testing 40%~60%
  • Automated Test selection for GUI testing about 30%

23 controversial notions of reservations

1. Documentation is as important as the SOFTWARE PRODUCT itself

   This is different from the idea that "the best document is the code of the product itself".

2. Full TDD is not suitable for most companies. After all, testing is part of the superstructure, built on existing development products.

Author:	Harmo ha mo
Author Introduction:	Https://zhengwh.github.io
Qq:	1295351490
Time:	2015-08-24
Copyright Notice:	Unlawful transmission for commercial purposes is prohibited without permission
To contact or reward:	Http://zhengwh.github.io/contact-donate.html

Basic theory-IBM model of software testing