Guru99 Flashcards
What is software testing?
an activity to check whether the actual results match the expected results and to ensure that the software system is Defect free.
AUT
Application Under Test
In simple terms, Software Testing means Verification of Application Under Test (AUT).
3 categories of software testing
- Functional testing (unit testing, integration testing, etc.)
- Non-functional testing (performance, endurance, load, usability, etc.)
- Maintenance (regression, maintenance)
The 7 testing principles
1) Exhaustive testing is not possible
2) Defect Clustering
3) Pesticide Paradox
4) Testing shows a presence of defects
5) Absence of Error - fallacy
6) Early Testing
7) Testing is context dependent
Principle: Exhaustive testing is not possible
We can’t test every test case, so we need the optimal amount of testing based on the risk assessment of the application.
Principle: Defect Clustering
a small number of modules contain most of the defects detected
Principle: Pesticide Paradox
If the same tests are repeated over and over again, eventually the same test cases will no longer find new bugs.
Principle: Testing shows a presence of defects
Software testing talks about the presence of defects and doesn’t talk about the absence of defects.
Principle: Absence of Error - fallacy
It is possible that software which is 99% bug-free is still unusable. It must also fulfill customer requirements.
Principle: Early Testing
Testing should start as early as possible in the Software Development Life Cycle. Defects in requirements or design are captured early, too.
Principle: Testing is context dependent
Different types of software need to perform different types of testing.
SDLC
Software Development Life Cycle
STLC
Software Testing Life Cycle
The V model
Requirement analysis System testing
High level design Integration testing
Low level design Unit testing
Coding
Phases of STLC
Requirements analysis Test planning Test case development Test environment setup Test execution Test cycle closure
Types of testing that could be manual or automated
Black Box Testing White Box Testing Unit Testing System Testing Integration Testing Acceptance Testing
Unit testing
Unit Tests isolate a section of code and verify its correctness. A unit may be an individual function, method, procedure, module, or object. Developers write unit tests during the coding phase.
Unit testing advantages
Allows for refactoring at a later date.
New developers can learn functionality of the code.
Can test parts without waiting for others to complete.
Find and fix errors faster than in integration testing, where errors are hard to trace down.
Integration testing
A type of testing where software modules are integrated logically and tested as a group.
Data transfer between modules is tested thoroughly.
Big-bang integration testing
Wait for all modules to be developed before beginning testing. Convenient for small systems.
Disadvantage: time consuming waiting for developers, difficult to trace root cause of defects, and high-risk modules are not prioritized
Incremental integration testing
Testing is done by joining two or more modules that are logically related. Then the other related modules are added and tested as they are available.
Top-down (higher layers first): create stubs.
Bottom-up: create drivers
The focus is mainly on the interfaces & flow of data/information between the modules. Priority is to be given for the integrating links rather than the unit functions which are already tested.
Stub
Is called by the Module under Test
Driver
Calls the Module to be tested
System testing
System testing is a level of testing that validates the complete and fully integrated software product. The purpose of a system test is to evaluate the end-to-end system specifications.
Includes usability testing, load testing, regression testing, recovery testing, migration testing, functional testing, hardware/software testing, etc.
Compiler vs. Interpreter
A compiler transforms source language into object language (machine language, binary code).
Generates output program (in the form of exe) which can be run independently from the original program.
Ex: C, C++, C#, Java
An interpreter converts the program one line at a time, it does not produce any intermediate object code, and compilation and execution happen simultaneously.
Ex: Python, Matlab
Compiler vs interpreter programming steps
Compiler:
- Create the program.
- Compile will parse or analyses all of the language statements for its correctness. If incorrect, throws an error
- If no error, the compiler will convert source code to machine code.
- It links different code files into a runnable program (know as exe)
- Run the Program
Interpreter:
- Create the Program
- No linking of files or machine code generation
- Source statements executed line by line DURING Execution
Linker
In the compiler, the linker links several object (and library) files to generate an executable.
Building a complete program involves writing source code for the program in either assembly or a higher level language like C++. The source code is assembled (for assembly code) or compiled (for higher level languages) to object code, and individual modules are linked together to become the machine code for the final program. In the case of very simple programs the linking step may not be needed. In other cases, such as with an IDE (integrated development environment) the linker and compiler may be invoked together.
Machine code
binary (1’s and 0’s) code that can be executed directly by the CPU
Object code
A portion of machine code that hasn’t yet been linked into a complete program. It’s the machine code for one particular library or module that will make up the completed product.
An object file is the simplest binary file which comes from the compilation of a single translation unit (TU) into executable code. Usual extensions: .o or .obj (MSVC).
Assembly code
Assembly code is plain-text and (somewhat) human read-able source code that mostly has a direct 1:1 analog with machine instructions. This is accomplished using mnemonics for the actual instructions, registers, or other resources. Examples include JMP and MULT for the CPU’s jump and multiplication instructions.
Header file
Contains C++ source code and they are mostly used to make declarations, i.e., they contain the stubs that tell the compiler about the “things” that exists (somewhere). Usual extensions: .hpp, .h, or .hxx.
Source file
Contains C++ source code and they are exclusively used for definitions, i.e., the actual implementation of the “things” that make up the program or library. Usual extensions: .cpp, .C, or .cxx (normally, .c is reserved for C source files, not C++).
An example of how a source file is organized: it first includes its corresponding header, then any other header it needs, and finally, the definitions of each of the declared elements of its corresponding header.
Translation unit (TU)
A technical term for a source file, once the compiler has looked at all #include statements and substituted them for the header files they refer to.
Once the pre-processor has finished, we can say that a translation unit (TU) has been fully formed from a source file with all its included headers fetched and copied into it, all its MACROs found-and-replaced, and all its conditional compilation blocks resolved.
Static library (or static-link library)
A binary file which is very similar to an object file but is larger and usually the product of many object files combined into one file for convenience. The GNU stack refers to static libraries as archives, i.e., collections of object files. Usual extensions: .a or .lib (MSVC).
Dynamic library (or dynamic-link library or shared object)
A binary file also created from a set of object files, but they are packaged as a standalone executable library (not a program). Usual extensions: .so (POSIX) or .dll (Windows).
Executable program
This is a type of binary file that can be started and executed, i.e., it has an execution entry-point. In short, this is a program you can run. Usual extensions: (POSIX) or .exe (Windows).
Pre-processor
Looks for # commands. The pre-processor is mostly a glorified find-and-replace tool. The step before compiling.
Compiler static analysis
Between pre-processing and code generation, the compiler does some steps that involve terms like lexical analysis, syntax analysis, context-dependent grammars, semantic analysis, etc… Suffice it to say, broadly speaking, the compiler builds up an Abstract Syntax Tree (AST) and a symbol table.
Build
Compiling is the act of turning source code into object code. Linking is the act of combining object code with libraries into a raw executable. Building is the sequence composed of compiling and linking, with possibly other tasks such as installer creation.
Smoke Testing
Smoke Testing is performed after software build to ascertain that the critical functionalities of the program are working fine. It is executed before any detailed functional or regression tests.
For Example, a typical smoke test would be - Verify that the application launches successfully, Check that the GUI is responsive … etc.
Sanity testing
Sanity testing is performed after receiving a software build with minor changes in code to ascertain that the bugs have been fixed and no further issues are introduced. The goal is to determine that it works roughly as expected.
For instance, if your calculator gives the result of 2 + 2 =5, then, there is no point testing the advanced functionalities like sin 30 + cos 50.
Smoke test vs. Sanity test
Smoke Testing has a goal to verify “stability” whereas Sanity Testing has a goal to verify “rationality”.
Smoke Testing verifies the critical functionalities of the system whereas Sanity Testing verifies the new functionality like bug fixes.
Smoke testing is a subset of acceptance testing whereas Sanity testing is a subset of Regression Testing.
Smoke testing is documented or scripted whereas Sanity testing isn’t.
Smoke testing verifies the entire system from end to end whereas Sanity Testing verifies only a particular component.
Build VerificationTest
Smoke testing performed on a particular build is also known as a build verification test.
Smoke tests can be functional tests or unit tests. Functional tests exercise the complete program with various inputs. Unit tests exercise individual functions, subroutines, or object methods.
Regression testing
This testing is done to make sure that new code changes should not have side effects on the existing functionalities. It ensures that the old code still works once the latest code changes are done.
Non-functional testing
A type of Software testing to check non-functional aspects (performance, usability, reliability, etc) of a software application. It is designed to test the readiness of a system as per nonfunctional parameters which are never addressed by functional testing.
Non-functional testing parameters: security, reliability, survivability, availability, usability, scalability, interoperability, efficiency, flexibility, portability, re-usability
Requirements Traceability Matrix (RTM)
Requirement Traceability Matrix (RTM) is a document that maps and traces user requirement with test cases. The main purpose is to validate that all requirements are checked via test cases such that no functionality is unchecked during Software testing.
