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 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70  % $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} \app{} then uses this information to locate components when the test is running. 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{}. %% \subsection{Changes in the user interface} %% \label{abstractcomps1} %% If a component moves in the user interface (either on the surface or in the hierarchy, \app{}'s component recognition method should find the component again. If the component changes type, then the recognition will depend on how large the change is. For example, changing a text field to a text pane should not alter the test, since both of these components are actually part of the same component in \app{}. %% A larger change may result in having to remap the component. You can make maintenance easier by specifying your \gdsteps{} using abstract components, which can be mapped to a larger range of real components. %% \subsection{Importing and exporting object mapping} %% An additional feature of the \gdomeditor{} is the ability to export and import %% the object mapping as an XML file (.map) for a \gdsuite{}. This %% contributes to the reusability aspect of \app{}, since another %% \gdproject{} using the same \gdaut{} can make use of this object mapping.