Skip to main content
summaryrefslogtreecommitdiffstats
blob: 8d40d4d81eb8853328ea20dec80e987fc17ae437 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
% $Id: objectmapping.tex 8161 2009-04-06 14:07:39Z alexandra $
% Local Variables:
% ispell-check-comments: nil
% Local IspellDict: american
% End:
% --------------------------------------------------------
% User documentation
% copyright by BREDEX GmbH 2004
% --------------------------------------------------------
\index{Object Mapping}
\index{Component!Names}
\index{Technical Names}
\index{Names!Component}
\index{Names!Technical}
\index{Import!Object Mapping}
\index{Object Mapping!Import}
\index{Export!Object Mapping}
\index{Object Mapping!Export}
\index{Maintainability}
\label{objectmapping1}

Object mapping is the process which joins your \bxname{component names} from your \gdsteps{} to the actual \bxname{technical names} for the components in the \gdaut{}. 
Because object mapping can be the last step before execution, you can start specifying tests before the software is even available. 

Object mapping consists of two steps:
\begin{enumerate}
\item Collecting the technical names for the components from the \gdaut{}.
\item Assigning these technical names to the component names you used in your \gdsteps{}. 
\end{enumerate}
 
\bxtipp{Object mapping is bound to the \gdaut{}, not to a \gdsuite{}. All 
\gdsuites{} which use the same \gdaut{} share an object map. }

\subsection{Component names}
When you specify \gdsteps{}, you specify component names for the components you want to test. When you add \gdcases{} to a \gdsuite{}, all component names used in the \gdcases{} are collected by the \gdomeditor{}. You can then collect the technical names from the \gdaut{}. 

\subsection{Technical names}
You do not need to consult the developers to collect technical names; you use the running \gdaut{} to collect the names. If the developers have named the components, this name will be collected. If the developers have not named the component, \app{} generates a name. 

\bxtipp{\app{} addresses high-level components in the mapping mode. You will not be able to map individual menu entries or tree nodes, for example. Instead, you map the tree component, and specify which entry/node to select/check as a parameter for the action. }

\subsection{Assigning technical names to component names}
Once you have collected the technical names from the \gdaut{}, you can ''assign'' them to the component names using drag-and-drop. In this way, you are telling \app{} which real component you are referring to in each \gdstep{}. 

The fact that the object map is separate from the specification means that any changes that need to be made to update a test only need to be made once. 

\subsection{Locating components during test execution}
 The component recognition system used by \app{} uses various details about mapped components to find the right component during the test. The location of the component in the \gdaut{} hierarchy, the components near to it and the name of the component all play a role in component recognition. For each possible component, \app{} calculates the similarity to the originally mapped component. The component with the highest result is selected. 

This method makes object mapping generally resilient to changes in the \gdaut{}. 
 


Back to the top