Test Design Guidelines for Reusability
Last Updated: JAN.10.2008
From: http://safsdev.sourceforge.net/sqabasic2000/TestDesignGuidelines.htm
- Purpose
- App Map and Test Table UTF-8 File Encodings
- App Map Chaining
- App Map Resolving Embedded Variables
- Designing Tests for NLS
- A Complete Dynamic Text Example Support NLS
Purpose
This document provides a set of guidelines that enable a tester to plan the development of test designs and related assets to maximize reuse. The intended context for this reuse is to maximize the potential for effective system\application configuration testing and localization testing, also known as NLS testing. Throughout this document we will refer primarily to NLS testing, but the concepts apply equally well to configuration testing and other forms of testing requiring reconfigurable text values.
The App Map features referenced here as App Map Chaining and App Map Resolving Embedded Variables are only available in versions of SAFS dated on or after Aug, 2006.
It is important to recognize that the single most important notion for making test designs reusable for NLS and configuration testing is that no localizable or configuration-specific text must exist in the test designs or test actions--the test tables. All such text must be managed in separate text resource files, which in the SAFS world means separate App Maps. The test designs and test actions will reference the text via variable references which will be retrieved from the App Maps opened for the target language or configuration.
App Map and Test Table UTF-8 File Encodings
(Need to respecify the following statement based on most recent experiences with Rational Robot and Rational Functional Tester evaluations.)
In order to properly represent mixed character data (some single-byte and some multi-byte) the UTF-8 character encoding format is supported by RRAFS and SAFS. All App Maps and Test Tables intended to be used for NLS testing should be encoded in the proper format required by the tools in use.
App Map Chaining
Note: App Map Chaining by default is not enabled in order to maintain backwards compatibility with existing tests. You must use the 'AppMapChaining' Driver Command to enable this feature.
C, AppMapChaining, ON
App Map Chaining is the process by which multiple App Maps can be opened and searched for referenced values. App Maps opened with chaining enabled are searched in Last-In-First-Out (LIFO) order. This allows the opening of scenario-specific maps--language or configuration, etc.--to be opened in addition to generic and shared maps. Maps opened later can have values that override or supercede maps opened earlier. In addition, shared maps can contain embedded variables (see below) that can be satisfied by the scenario-specific maps. For example, a shared map may reference an embedded variable containing localizable text that will be found in another open App Map--the one specific to the language being tested.
Example:
C, SetApplicationMap, FMStudio_NLS
C, SetApplicationMap, FMStudio_MAP
This design snippet shows two maps being opened. The first opened map (FMStudio_NLS) would contain the localized text specific to the language being tested. All entries in this map would be in the default [ApplicationConstants] section so that they could be retrieved as variables. The second map (FMStudio_MAP) would be the shared map used in all testing no matter what the language or configuration. The entries in this shared map would contain embedded variables whose values would be found in the localized map. Since the maps are read in LIFO order due to App Map Chaining, values will first be sought in the FMStudio_MAP. Embedded variables or other values not satisfied by that map will then be sought in the FMStudio_NLS map.
App Map Resolving Embedded Variables
Note: Resolving embedded variables in App Maps is not enabled by default in order to maintain backwards compatibility with existing tests. You must use the 'AppMapResolve' Driver Command to enable this feature.
C, AppMapResolve, ON
An App Map entry can contain references to variables whose values will be resolved to complete the entry. See Resolving DDVariables for Dynamic Recognition for more information on this capability. Essentially, the idea to keep in mind is that the shared maps will contain largely static text that does not need to be localized or changed for subsequent testing. Where some portion of an App Map entry does need to contain localized text that portion will be represented as an embedded variable and the ultimate value of that variable will be retrieved from a locale-specific App Map that is opened in addition to the shared App Map.
Example:
FMStudio_NLS_en (known as FMStudio_NLS):
----------------------------------------
[ApplicationConstants]
nlsHello="Hello!"
FMStudio_NLS_es (known as FMStudio_NLS):
----------------------------------------
[ApplicationConstants]
nlsHello="¡Hola!"
FMStudio_MAP:
-------------
HelloLink="Type=HTMLLink;HTMLText={^nlsHello}"
Now, let us assume that the test is run first in English and then later in Spanish. The first time the test is run the FMStudio_NLS_en (English) map is loaded along with the FMStudio_MAP. When the test goes to retrieve the value for the HelloLink component it will find the embedded ^nlsHello variable reference which must be retrieved. The ^nlsHello variable does not exist in the shared map so App Map Chaining will go look for the value in the English map. The value retrieved for ^nlsHello is "Hello!" and the resulting HelloLink value will be:
HelloLink="Type=HTMLLink;HTMLText=Hello!"
The second time the test is run the FMStudio_NLS_es Spanish map is loaded along with the FMStudio_MAP. This time the value retrieved for ^nlsHello is "¡Hola!" and the resulting HelloLink value will be:
HelloLink="Type=HTMLLink;HTMLText=¡Hola!"
As you can see, App Map Chaining with Embedded Variables is a powerful combination that enables us to deliver tests that can readily be migrated for NLS testing. However, to accomplish that it requires the Test Designers to design the tests and these assets with the goal of NLS reuse in mind.
Designing Tests for NLS and Other Forms of Reuse
Just as special design consideration must be given during software development to make an application support Internationalization, Localization, and Globalization, so too must our test designs receive this same level of design consideration. If the tests are not designed from the very beginning with this goal in mind then the process of going back and making the tests NLS-ready can be very difficult and time consuming.
The App Map processing features mentioned above allow us to use the same common practice used by software developers when developing software. That is, we must design our tests for NLS by separating textual data and other environment-dependent resources out of the tests themselves and into separate resource files. This means we want all environment-dependent text stored in environment-specific App Maps. Other environment-dependent resources like image files should be referenced through environment-specific entries in those same App Maps. In this way, the tests themselves do not change no matter which environment is being tested. When we go to test in a new environment we just make sure we use the appropriate App Map(s) and resources targetted for that environment.
It takes vigilance and attentive awareness to design a test that is truly NLS-ready. All environment-specific text and resources must be kept out of the design and moved into the resource files (App Maps). The designs will merely contain variable references that will ultimately be satisfied by lookups into the environment-specific App Maps. This not only includes language-specific text that might appear in object recognition strings, but also any language-specific string that might be evaluated or verified--such as an object property value, displayed text, or image benchmarks whose image may contain environment-specific text, legends, or formats.
An example of this might be a Label on a dialog box that informs the user that a certain process either succeeded or failed. The recognition string for the label may not require special handling as its Name or ID may be common across all environments as shown below:
StatusLabel="Type=Label;Name=lblStatus"
However, when we wish to verify the status displayed to the user in the Label we are going to be dealing with literal text that will likely be localized and needs to be stored separately in our NLS resource files or App Maps.
Problem:
T, StatusDialog, StatusLabel, VerifyProperty, "Text", "Success!"
Solution:
T, StatusDialog, StatusLabel, VerifyProperty, "Text", ^nlsSuccess
To make sure our tests are NLS-ready we are tasked to verify a few things:
- The Name of the Label does not change in other environments so it does not need to be localized.
- The name of the Text property does not change in other environments so it does not need to be localized.
- The displayed text in the Label will change in other environments so it does need to be localized.
Thus, our NLS-ready App Maps need to hold this localizable text so that the proper values are found at runtime:
FMStudio_NLS_en (known as FMStudio_NLS):
----------------------------------------
[ApplicationConstants]
nlsHello="Hello!"
nlsSuccess="Success!"
nlsFailed="Failed!"
FMStudio_NLS_es (known as FMStudio_NLS):
----------------------------------------
[ApplicationConstants]
nlsHello="¡Hola!"
nlsSuccess="¡Éxito!"
nlsFailed="¡Fallado!"
As you can see, it takes special attention and vigilance to carefully design our tests so that they are NLS-ready! The same level of care must be taken for all forms of displayed text, text to be input from the user that might be language-specific, and other resources containing environment-specific data like locale-specific currency, time, and date formats.
A Complete Dynamic Text Example Supporting NLS
- The Scenario:
- You wish to create a highly reusable step table (action) that will close any window in your application and then check the application state. We'll call this the "CloseAppWindow" table.
This can serve a number of purposes, including:
- High value test assets with reduced maintenance
- Supports dynamic features of the AUT
- Supports growing automated coverage of the AUT
- Existing automated tests are suitable for NLS testing
The Problem:For maximum reusability, CloseAppWindow must be able to recognize different windows according to their any-language Caption, so no part of CloseAppWindow, or any of the tables that call it, can contain language-specific text.
The Solution:Use App Map Chaining, App Map Embedded Variables, and Application Constants.
1. A few examples calling CloseAppWindow with the Caption parameter using Application Constants:
T CloseAppWindow ^Caption=^ReportsCaption T CloseAppWindow ^Caption=^HelpCaption
T CloseAppWindow ^Caption=^AboutCaptionThere is no localizable text calling CloseAppWindow
- .
2. The implementation of the CloseAppWindow step table:
T AnyWindow AnyWindow CloseWindow
...followed by important status and error checks There is no localizable text in CloseAppWindow.
3. The Primary App Map using App Map Embedded Variables:
MyApp.map:
----------
...
[AnyWindow]
AnyWindow="Type=Window;Caption={^Caption}"
... There is no localizable text in the primary App Map.
4. The NLS App Maps for App Map Chaining for Application Constants:
4a. MyApp_NLS_en (known as MyApp_NLS):
--------------------------------------
[ApplicationConstants]
ReportsCaption="Reports"
HelpCaption="Help"
AboutCaption="About" All localizable text is confined to the NLS App Map. 4b. MyApp_NLS_es (known as MyApp_NLS):
--------------------------------------
[ApplicationConstants]
ReportsCaption="Informes"
HelpCaption="Ayuda"
AboutCaption="Sobre"
This sample design shows maximum reusability. The same test used to automatically test the English translation of the application can be used to test all other localizations. And the amount of localization necessary for each translation has been minimized to a single NLS App Map file.
Test Design Guidelines for Reusability的更多相关文章
- Database Design Guidelines
Database Design Guidelines Principles Support popular databases Name Style Table Name Style: Pascal ...
- [书籍]重温《Framework Design Guidelines》
1. 前言 最近重温了<Framework Design Guidelines>. <Framework Design Guidelines>中文名称为<.NET设计规范 ...
- Dynamic Library Design Guidelines
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100 ...
- SAP成都C4C小李探花:浅谈Fiori Design Guidelines
Jerry: 我和周帅认识不久,自去年7月SAP成都研究院Cloud for Customer(以下简称为C4C)开发团队组建至今,根据这段时间和周帅愉快的合作经历,我觉得如果把周帅比作我读过的小说里 ...
- Three Sources of a Solid Object-Oriented Design
pingback :http://java.sys-con.com/node/84633?page=0,1 Object-oriented design is like an alloy consis ...
- Android Programming: Pushing the Limits -- Chapter 4: Android User Experience and Interface Design
User Stories Android UI Design 附加资源 User Stories: @.通过写故事来设计应用. @.每个故事只关注一件事. @.不同的故事可能使用相同的组件,因此尽早地 ...
- The design of a distributed variant of Plato framework to support collaborated editing
A first thought system architecture (pulling mode) is one that the server doesn't keep client inform ...
- 【android design】android常用设计资源
一.概述 大部分程序员擅长开发,但是对于设计却知之甚少.这直接导致,程序员在初期开发出来的应用(大多为兴趣或实用导向)中看不中用.因此,有必要搜集整合一些设计资源,这样既能减轻程序员在设计上所耗费的时 ...
- API Design
REST API Design Guidelines V 1.0.201208 Draft 5 Last Updated: 08/31/2012 1 简介 本文档旨在规范REST API的 ...
随机推荐
- linux c++循环缓冲区模板类
一:概述 实际学习和工作中,我们经常会遇到读写大量数据的情况,这个时候我们可能就用到了循环缓冲区. 循环缓冲区在处理大量数据的时候有很大的优点,循环缓冲区在一些竞争问题上提供了一种免锁的机制,免锁的前 ...
- Python 性能优化——对象绑定
不同函数调用方式对应不同的绑定次数: import profile class A: def f(self): pass def foo(): a = A() for i in range(10000 ...
- IIS服务的命令行方式重启命令
打开IIS配置窗口的CMD命令:开始---运行---CMD----输入inetmgr 直接使用CMD我们可以操作很多事情,比如启动IIS,重启IIS,停止IIS 重启IIS服务器,开始->运行- ...
- invalidate()和postInvalidate()的使用与区别
Android提供了Invalidate方法实现界面刷新,但是Invalidate不能直接在线程中调用,因为他是违背了单线程模型: Android UI操作并不是线程安全的,并且这些操作必须在UI线程 ...
- Linq学习工具及Lamada表达式
好东西.转载一个.以备学习 Linq学习工具: http://www.linqpad.net/ Lamada表达式: Func<int, int, int> IntPow = (x ...
- tar.xz文件解压
原文:http://blog.csdn.net/rheostat/article/details/7614451 感谢CSDN的<帝都码农> ======================= ...
- listView后面加控件,防止被挤
<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=&quo ...
- Java学习笔记(五)
作业1:将指定目录下的所有文件显示到列表框(JList)组件中. 代码如下: import java.awt.; import java.awt.event.; import javax.swing. ...
- 解剖SQLSERVER 第十二篇 OrcaMDF 行压缩支持(译)
解剖SQLSERVER 第十二篇 OrcaMDF 行压缩支持(译) http://improve.dk/orcamdf-row-compression-support/ 在这两个月的断断续续的开发 ...
- android precelable和Serialization序列化数据传输
一 序列化原因: 1.永久性保存对象,保存对象的字节序列到本地文件中:2.通过序列化对象在网络中传递对象:3.通过序列化在进程间传递对象. 二 至于选取哪种可参考下面的原则: 1.在使用内存的时候,P ...