Software Test and Analysis in a Nutshell

Transcription

IGL601 – Hiver 2015
Tests combinatoires
Libre adaptation du chapitre 11 de
manuel ‘Software Testing And
Analysis’ par Pezzè and Young
Jonathan Guay
Département d’informatique
Faculté des sciences
[email protected]
http://igl601-jg.espaceweb.usherbrooke.ca/
Objectifs d’apprentissage
 Comprendre le but et l’approche systématique aux tests
combinatoires
 Apprendre à appliquer certaines approches
combinatoires.
 Tests patitionnels à l’aide de catégories (Category-partition
testing)
 Tests combinatoires par paires (Pairwise combination testing)
 Tests basé sur un catalogue (Catalog-based testing) (bref
survol)
 Comprendre les différences et similitudes de ces
approches.
 et leur domaines d’application
Test combinatoire: l’idée
 Identifier des attributs distincts qui peuvent varier.
 Parmi les données, l’environnement ou la configuration
 Exemple: navigateur “IE” ou “Firefox”, OS “Vista”, “XP”,
ou “OSX”
 Générer systématiquement les combinaisons à être
testées.
 Exemple: IE et Vista, IE et XP, Firefox et Vista, Firefox et
OSX, ...
 Explication: Les cas de test doivent être variés et
doivent inclure les cas limites
Approches combinatoires
clés
 Tests paritionnels basés sur la catégorie (Categorypartition testing)
 Sépare l’identification (manuelle) des valeurs qui caractérisent les
entrées possibles de tests DE la génération (automatique) des
combinaisons pour les cas de tests.
 Tests par paires (Pairwise testing)
 Test de manière systématique les interactions entre les attributs
de l’espace des valeurs d’entrées possibles avec un nombre
restreint de cas de tests.
 Tests basés sur un catalogue (Catalog-based testing)
 Tient compte de l’expérience du designer de tests dans un
domaine d’application pour aider à identifier les valeurs des
attributs.
Partition par catégorie
(étapes manuelles)
1.
Décompose les spécifications en caractéristiques
testables
–
–
2.
•
paramètres
•
les éléments de l’environnement
pour chaque paramètre et élément de l’environnement
identifier les catégories
Identifier les valeurs utiles
–
3.
pour chaque caractéristique identifier
pour chaque catégorie, identifier la classe de valeurs
•
valeurs normales
•
valeurs aux limites
•
valeurs spéciales
•
valeurs d’erreurs
Introduire les contraintes
Exemple
 Considérer un système qui permet à un internaute de
‘construire son ordinateur’ à l’aide d’une multitude
d’options (choix du modèle, de la carte vidéo, du OS,
de la mémoire, etc).
 Les prochaines diapositives décrivent comment
appliquer les tests combinatoires par catégorie à un
programme qui vérifie les combinaisons possibles de
composantes.
An informal specification:
check configuration
Check Configuration
 Check the validity of a computer configuration
 The parameters of check-configuration are:
 Model
 Set of components
(c) 2007 Mauro Pezzè & Michal Young
An informal specification:
parameter model
Model
 A model identifies a specific product and determines a
set of constraints on available components. Models are
characterized by logical slots for components, which may
or may not be implemented by physical slots on a bus.
Slots may be required or optional. Required slots must be
assigned with a suitable component to obtain a legal
configuration, while optional slots may be left empty or
filled depending on the customers' needs
Example:
The required “slots” of the Chipmunk C20 laptop
computer include a screen, a processor, a hard disk,
memory, and an operating system. (Of these, only the
hard disk and memory are implemented using actual
hardware slots on a bus.) The optional slots include
external storage devices such as a CD/DVD writer.
An informal specification of
parameter set of components
Set of Components

A set of (slot, component) pairs, corresponding to the required and
optional slots of the model. A component is a choice that can be
varied within a model, and which is not designed to be replaced by
the end user. Available components and a default for each slot is
determined by the model. The special value empty is allowed (and
may be the default selection) for optional slots. In addition to being
compatible or incompatible with a particular model and slot,
individual components may be compatible or incompatible with
each other.
Example:
The default configuration of the Chipmunk C20 includes 20 gigabytes
of hard disk; 30 and 40 gigabyte disks are also available. (Since the
hard disk is a required slot, empty is not an allowed choice.) The
default operating system is RodentOS 3.2, personal edition, but
RodentOS 3.2 mobile server edition may also be selected. The mobile
server edition requires at least 30 gigabytes of hard disk.
Étape 1: Identifier les unités et
catégories pouvant être testées
de manière indépendante
 Choix des catégories
 pas de règles strictes et rapides
 pas simple!
 Les catégories reflètent le jugement du designer de tests
 classes de valeurs pouvant être traitées de manières
différentes par une implémentation
 Le bon choix des catégories requirent de l’expérience et
des connaissances
 du domaine d’application et de l’architecture du produit. Le
designer de test doit être capable de lire entre les lignes des
spécifications et en déduire les caractéristiques cachées
Step 1: Identify independently testable units
Parameter Model
 Model number
 Number of required slots for selected model (#SMRS)
 Number of optional slots for selected model (#SMOS)
Parameter Components
 Correspondence of selection with model slots
 Number of required components with selection  empty
 Required component selection
 Number of optional components with selection  empty
 Optional component selection
Environment element: Product database
 Number of models in database (#DBM)
 Number of components in database (#DBC)
Étape 2: Identifier les valeurs
pertinentes
 Identifier (lister) les classes de valeurs représentatives
pour à chaque catégorie
 Ignorer les interactions entre les valeurs de différentes
catégories (considéré à la prochaine étape)
 Les valeurs représentatives peuvent être identifiées en
appliquant
 Tests au limites
 Sélectionner les valeurs extrêmes d’une classe
 Sélectionner les valeurs tout juste à l’extérieur d’une classe.
 Sélectionner les valeurs typiques à l’intérieur de la classe
 Conditions de tests erronées
 Sélectionner les valeurs à l’extérieur du domaine
d’application normal du programme.
Step 2: Identify relevant
values: Model
Model number
Malformed
Not in database
Valid
Number of required slots for selected model (#SMRS)
0
1
Many
Number of optional slots for selected model (#SMOS)
0
1
Many
Step 2: Identify relevant values: Component
Correspondence of selection with model slots
Omitted slots
Number of optional components with
non empty selection
Extra slots
0
Mismatched slots
< #SMOS
Complete correspondence
= #SMOS
Number of required components with non
empty selection
0
< number required slots
= number required slots
Required component selection
Some defaults
All valid
 1 incompatible with slots
 1 incompatible with another selection
 1 incompatible with model
 1 not in database
Optional component selection
Some defaults
All valid
 1 incompatible with another
selection
Step 2: Identify relevant values:
Database
Number of models in database (#DBM)
0
1
Many
Number of components in database (#DBC)
0
1
Many
Note 0 and 1 are unusual (special) values. They might
cause unanticipated behavior alone or in combination
with particular values of other parameters.
Étape 3: Introduire les
contraintes
 Une combinaison de valeurs pour chaque catégorie
correspond à une spécification de cas de test
 Dans l’exemple, nous havons 314 928 cas de tests
 Plusieurs sont impossibles!
 exemple
zero slots et least one incompatible slot
 Introduire les contraintes pour
 Exclure les combinaisons impossibles
 Réduire la taille de la suite de tests (lorsque trop grande)
Étape 3: la contrainte
‘erreur’
[error] indique une valeur d’une classe qui
 correspond à des valeurs erronées
 a besoin d’être testée une seule fois.
Example
Model number: Malformed and Not in database
error value classes
 No need to test all possible combinations of errors
 One test is enough (we assume that handling an error
case bypasses other program logic)
Example - Step 3: error
constraint
Model number
Malformed
Not in database
Valid
[error]
[error]
Correspondence of selection with model slots
Omitted slots
[error]
Extra slots
[error]
Mismatched slots
[error]
Number of required comp. with non empty selection
0
[error]
< number of required slots [error]
Required comp. selection
[error]
0
[error]
0
[error]
Error constraints
reduce test suite
from 314 928 to
2 711 test cases
Step 3: property constraints
constraint [property] [if-property] rule out invalid
combinations of values
[property] groups values of a single parameter to
identify subsets of values with common properties
[if-property] bounds the choices of values for a
category that can be combined with a particular
value selected for a different category
Example
combine
Number of required comp. with non empty selection = number required slots [if
RSMANY]
only with
Number of required slots for selected model (#SMRS) = Many
[Many]
Example - Step 3: property
constraints
1
[property RSNE]
Many
[property RSNE] [property RSMANY]
1
[property OSNE]
Many
[property OSNE] [property OSMANY]
Number of required comp. with non empty selection
0
[if RSNE] [error]
[if RSNE] [error]
[if RSMANY]
Number of optional comp. with non empty selection
[if OSNE]
[if OSMANY]
from 2 711 to
908 test cases
Step 3 (cont): single
constraints
[single] indicates a value class that test designers choose to
test only once to reduce the number of test cases
Example
value some default for required component
selection and optional component selection
may be tested only once despite not being
an erroneous condition
note -
single and error have the same effect but
differ in rationale. Keeping them distinct is
important for documentation and regression
testing
Example - Step 3: single
constraints
0
[single]
1
[property RSNE] [single]
0
[single]
1
[single] [property OSNE]
Some default
[single]
Some default
[single]
1
[single]
1
[single]
from 908 to
69 test cases
Check configuration – Summary
Parameter Model
 Model number





Parameter Component
 Correspondence of selection with model slots
Malformed
[error]
Not in database [error]
Valid

Number of required slots for selected model
(#SMRS)



0
1
Many
[single]
[property RSNE] [single]
[property RSNE] [property RSMANY]



0
1
Many
[single]
[property OSNE] [single]
[property OSNE] [property OSMANY]

Number of optional slots for selected model
(#SMOS)

Environment Product data base
 Number of models in database (#DBM)




0
1
Many
[error]
[single]



0
1
Many
[error]
[single]





Omitted slots
[error]
Extra slots
[error]
Mismatched slots
[error]
# of required components (selection  empty)
 0
[if RSNE] [error]
 < number required slots
[if RSNE] [error]
 = number required slots
[if RSMANY]






Some defaults
[single]
All valid
 1 not in database [error]
# of optional components (selection  empty)
 0
 < #SMOS
 = #SMOS
[if OSNE]
[if OSMANY]






Some defaults
[single]
All valid
 1 not in database [error]
Ensuite ...
 Tests partitionnels par catégorie nous donne
 Une approche systématique: Identifier les
caractéristiques et valeurs (étape créative), générer les
combinaisons (étape mécanique)
 Mais ...
 La suite de test grossis très rapidement avec le nombre
de catégories. Pouvons-nous utiliser une approche non
exhaustive?
 Tests par paires (triples, etc…)
 Combine les valeurs de manières systématiques mais non
exhaustives
 Explication: La plupart des interaction non planifiées le
sont en combinant 2 ou quelques paramètres ou
caractéristiques
Tests combinatoires par paire
 Le partitionnement par catégorie fonctionne bien lorsque des
contraintes intuitives nous permettent de réduire significativement le
nombre de cas de tests
 Sans ces contraintes, le nombre de combinaisons à tester n’est pas
gérable.
 Combinaison par paire (au lieu des tests exhaustifs)
 Générer les combinaisons qui couvrent de manière efficace toutes les
paires (triples, …) de classes
 Explication: la plupart des fautes sont révélées par une valeur unique ou
une combinaisons de quelques valeurs. En couvrant principalement les
paires (triples,…) on réduit le nombre de cas de tests mais on révèlent la
plupart des fautes.
Example: Display Control
No constraints reduce the total number of
combinations 432 (3x4x3x4x3) test cases
if we consider all combinations
Display Mode
Language
Fonts
Color
full-graphics
English
Minimal
Monochrome Hand-held
text-only
French
Standard
Color-map
Laptop
limitedbandwidth
Spanish
Documentloaded
16-bit
Full-size
Portuguese
Screen size
True-color
Ch 11, slide 26
Pairwise combinations: 17 test cases
Language
Color
Display Mode
Fonts
Screen Size
English
Monochrome
Full-graphics
Minimal
Hand-held
English
Color-map
Text-only
Standard
Full-size
English
16-bit
Limited-bandwidth
-
Full-size
English
True-color
Text-only
Document-loaded
Laptop
French
Monochrome
Limited-bandwidth
Standard
Laptop
French
Color-map
Full-graphics
Document-loaded
Full-size
French
16-bit
Text-only
Minimal
-
French
True-color
-
-
Hand-held
Spanish
Monochrome
-
Document-loaded
Full-size
Spanish
Color-map
Limited-bandwidth
Minimal
Hand-held
Spanish
16-bit
Full-graphics
Standard
Laptop
Spanish
True-color
Text-only
-
Hand-held
Portuguese
-
-
Monochrome
Text-only
Portuguese
Color-map
-
Minimal
Laptop
Portuguese
16-bit
Limited-bandwidth
Document-loaded
Hand-held
Portuguese
True-color
Full-graphics
Minimal
Full-size
Limited-bandwidth
Standard
Portuguese
True-color
Hand-held
Ch 11, slide 27
Ajouter les contraintes
 Contraintes simples
example: color monochrome not compatible with
screen laptop and full size
can be handled by considering the case in separate
tables
Example: Monochrome only with handheld
Display Mode
Language
Fonts
Color
Screen size
full-graphics
English
Minimal
Monochrome
Hand-held
text-only
French
Standard
Color-map
limitedbandwidth
Spanish
Documentloaded
16-bit
Portuguese
True-color
Display Mode
Language
Fonts
Color
Screen size
full-graphics
English
Minimal
text-only
French
Standard
Color-map
Laptop
limitedbandwidth
Spanish
Documentloaded
16-bit
Full-size
Portuguese
True-color
Ensuite ...
 L’approche partitionnelle par catégorie nous donne …
 La séparation manuelle entre l’identification des
caractéristiques des paramètres et leurs valeurs et la
génération de cas de tests automatiques qui les combine.
 Contraintes pour réduire le nombre de combinaisons
 Les tests par paires (triples, …) nous donnent ...
 Des jeux de test beaucoup plus petit, même sans
contraintes
 (mais nous pouvons toujours utiliser des contraintes)
 Nous avons toujours besoin ...
 D’aide pour rendre l’étape manuelle plus systématique
Tests basés sur un catalogue
 L’élaboration des classes de valeurs requiert un jugement
 Obtenir de l’expérience dans une collection systématique
peut :
 Accélérer le processus de conception des tests
 Systématiser plusieurs décisions de routines, ou mieux diriger l’effort
des ressources humaines
 Accélérer la formation et réduire les erreurs humaines
 Les catalogues capturent l’expérience des designers de tests
en listant les cas important pour chaque type de variables
possibles.
 Exemple: Si un calcul utilise un entier, un catalogue peut indiquer les
cas pertinents suivants
 L’élément immédiatement avant la limite inférieure
 L’élément de la limite intérieure
 Un élément à l’intérieur des limites
 L’élément de la limite supérieure
 L’élément immédiatement après la limite supérieure
Processus de test basé sur un
catalogue
Étape 1:
Analyse initiale des spécifications pour identifier les éléments
de bases:
 Préconditions
 Poste-conditions
 Définitions
 Variables
 Opérations
Étape 2:
Dériver un premier cas de spécification de test des
préconditions, poste-conditions et définitions.
Étape 3:
Compléter le jeu de spécification de test à l’aide de
catalogue.
Exemple d’un catalogue simple (partie 1)
 Boolean
 True
in/out
 False
in/out
 Enumeration
 Each enumerated value
in/out
 Some value outside the enumerated set
in
 Range L ... U
 L-1
in
 L
in/out
 A value between L and U
in/out
 U
in/out
 U+1
in
 Numeric Constant C
 C
in/out
 C –1
in
 C+1
in
 Any other constant compatible with C
in
Exemple d’un catalogue simple (partie 1)
 Non-Numeric Constant C
in/out
 C
 Any other constant compatible with C
in
 Some other compatible value
in
 Sequence
 Empty
in/out
 A single element
in/out
 More than one element
in/out
 Maximum length (if bounded) or very long
in/out
 Longer than maximum length (if bounded) in
 Incorrectly terminated
in
 Scan with action on elements P
 P occurs at beginning of sequence
in
 P occurs in interior of sequence
in
 P occurs at end of sequence
in
 PP occurs contiguously
in
 P does not occur in sequence
 pP where p is a proper prefix of P
in
in
 Proper prefix p occurs at end of sequence
in
Qu’avons nous?
 Test partitionnel par catégorie:
 Une étape manuelle d’identification des categories et
des valeurs, avec les contraintes, et une étape
automatique de génération les combinaisons.
 Test basé sur des catalogues:
 Améliore l’étape manuelle en utilisant des patrons
standards pour l’identification de valeurs pertinentes
 Test par paires:
 Génération systématique de jeux de tests plus petits
 Ces idées peuvent être combinées
Sommaire
 Typiquement, les spécifications de requis sont initialement
élaborées à l’aide de phrase simples en langage naturel
 L’expression et la flexibilité d’un langage naturel sont des
obstacles à l’analyse automatisée.
 Les approches combinatoires aux tests fonctionnels
consistent à :
 Une étape manuelle de structuration des spécifications en jeu de
propriétés
 Une étape automatisable du choix des combinaisons
 La synthèse des cas de tests en employant ‘la force brute’
est difficile et source d’erreur
 Les approches combinatoires remplacent le travail fait par
‘la force brute’ en étapes incrémentales en séparant les
activités d’analyse et de synthèse pouvant être quantifiées et
surveillées, et supportées en partie par des outils.

Software Test and Analysis in a Nutshell

Transcription

Documents pareils

iwork 9027

Platinum 7532 – 17"

Platinum 7505 – 17"

Platinum 7730 – 17 - Passion Packard Bell

Platinum 7502 – 17 - Passion Packard Bell

Platinum 7602 – 17 - Passion Packard Bell

Platinum 400v² - Passion Packard Bell

Platinum 5500k - Passion Packard Bell

Platinum 45Ok - Passion Packard Bell

Club 300xi