2008年4月14日星期一

Google BI

reference from: http://www.biguru-online.com/2008/03/28/google-bi/

In a move that turns the heat up on Microsoft Excel, Google is partnering with business intelligence firm Panorama Software to develop a software-as-a-service (SaaS) analytics, reporting and data visualization tool for its free online Google Docs applications suite. The BI firm that handed Microsoft the original OLAP technology that’s now included in SQL Server database management system, is working with Google to push BI and data visualisation capabilities into Google’s Docs applications suite which mimics Microsoft Office with free online word processing, spreadsheet and presentation applications. At the same time rumors are surfacing that Microsoft in experimenting with an online office suite with codename Albany. This in an attempt to fend off competition like Google docs. The Panorama software, which has been released as a beta version this week, is offered as a free desktop gadget that works with Google Spreadsheets. It draws on analysis, reporting, dashboard, visualisation (charting) and data modelling tools that are part of Panorama’s NovaView BI suite. These elements combine to create Panorama Pivot Tables that can be embedded and manipulated in applications like Google Spreadsheets. This Google initiative perfectly fits into one of the BI megatrends for 2008: Integration. We have seen that Business Intelligence continues to integrate with operational processes. The preferred tool of choice in operations is still the spreadsheet (Excel). Microsofts ‘BI for the masses approach’ also boosts excel as their BI frontend. If Google wants to compete with Microsoft (in the BI area) then targeting the spreadsheet sounds like a well thought strategy. But if you compare the installed base of MS Office and Google Docs there is still a long way to go before somebody in Redmond looses sleep over this. Also we have seen a consolidation of BI vendors in 2007. This means that small(er) BI vendors will be looking for partners to survive (or create niche solutions). Again also sound strategy thinking by the guys and girls at Panorama. That they have been in bed with Microsoft before makes it even more exciting. Finally the Vendor consolidation has created an renewed interest in open source software. Clients are afraid to be ‘owned’ by one mega vendor. Google may be perceived as a alternative. In conclusion, we could argue that the BI vendor consolidation has made the BI market more volatile by creating new chances for innovative parties even from a non traditional BI background.

It will take a very long time for Google to improve the Google Spreadsheets not only developing the product but also delivering the product to customer.
I pay a lot of attention for the great things Google is doing. And I am integrating some ideas with Google Spreadsheets.
Look forward the bright future.

2008年4月1日星期二

How to create an automatable custom component?


Creating a delegate class

To instrument custom components with a delegate, you must do the following:

  • Create a delegate class that implements the required interfaces. In most cases, you extend the UIComponentAutomationImpl class. You can instrument any component that implements IUIComponent.
  • Register the delegate class with the AutomationManager.
  • Define the component in a class definitions XML file.

The delegate class is a separate class that is not embedded in the component code. This helps to reduce the component class size and also keeps automated testing code out of the final production SWF file. All Flex controls have their own delegate classes. These classes are in the mx.automation.delegates.* package. The class names follow a pattern of ClassnameAutomationImpl. For example, the delegate class for a Button control is mx.automation.delegates.controls.ButtonAutomationImpl.

To instrument with a delegate class:

  1. Create a delegate class.
  2. Mark the delegate class as a mixin by using the [Mixin] metadata keyword.
  3. Register the delegate with the AutomationManager by calling the AutomationManager.registerDelegateClass() method in the init() method. The following code is a simple example:
    [Mixin]
    public class MyCompDelegate {
    public static init(root:DisplayObject):void {
    // Pass the component and delegate class information.
    AutomationManager.registerDelegateClass(MyComp, MyCompDelegate);
    }
    }

    You pass the custom class and the delegate class to the registerDelegateClass() method.

  4. Add the following code to your delegate class:
    1. Override the getter for the automationName property and define its value. This is the name of the object as it appears in QTP. If you are defining an item renderer, use the automationValue property instead.
    2. Override the getter for the automationValue property and define its value. This is the value of the object in QTP.
    3. In the constructor, add event listeners for events that QTP records.
    4. Override the replayAutomatableEvent() method. The AutomationManager calls this method for replaying events. In this method, return whether the replay was successful. You can use methods of the helper classes to replay common events.

      For examples of delegates, see the source code for the Flex controls in the mx.automation.delegates.* packages.

  5. Link the delegate class with the application SWF file in one of these ways:
    • Add the following includes compiler option and link in the delegate class:

      mxmlc -includes MyCompDelegate -- FlexApp.mxml


    • Build a SWC file for the delegate class by using the compc component compiler:

      compc -source-path+=. -include-classes MyCompDelegate -output MyComp.swc


      Then include this SWC file with your Flex application by using the following include-libraries compiler option:

      mxmlc -include-libraries MyComp.SWC -- FlexApp.mxml


      This approach is useful if you have many components and delegate classes and want to include them as a single file.

  6. After you compile your Flex application with the new delegate class, you must add the new component to QTP's custom class definition XML file.

Using the class definitions file

The TEAFlex.xml file contains information about all instrumented Flex components. This file provides information about the components to QTP, including what events can be recorded and played back, the name of the component, and the properties that can be tested.

The TEAFlex.xml file is located in the "QTP_plugin_install\Flex 2 Plug-in for Mercury QuickTest Pro" directory. QTP recognizes any file in that directory that matches the pattern TEAFlex*.xml, where * can be any string. This directory also contains a TEAFlexCustom.xml file that you can use as a starting point for adding custom component definitions.

The class definitions file describes instrumented components to QTP with the following basic structure:







...



...


The top level tag is . You define a new class that uses the tag, which is a child tag of the tag. The tag has child tags that further define the instrumented classes. The following table describes these tags:

Tag

Description

ClassInfo

Defines the class that is instrumented, for example, FlexButton. This is the name that QTP uses for the Button control.

Attributes of this tag include Name, GenericTypeID, Extends, and SupportsTabularData.

Description

Defines the text that appears in QTP to define the component.

Implementation

Defines the class name, as it is known by the Flex compiler, for example, Button or MyComponent.

TypeInfo

Defines events for this class. Each event is defined in an child tag, which has two child tags:

  • The child tag associates the operation with the actual event.
  • Each operation can also define properties of the event object by using an child tag.

Properties

Defines properties of the class. Each property is defined in a child tag. Inside this tag, you define the property's type, name, and description.

For each Property, if the ForDescription attribute is true, the property is used to uniquely identify a component instance in QTP; for example, the label property of a Button control. QTP lists this property as part of the object in QTP object repository.

If the ForVerfication attribute is true, the property is visible in the properties dialog box in QTP.

If the ForDefaultVerification tag is true, the property appears selected by default in the dialog box in QTP. This results in verification of the property value in the checkpoint.

The following example adds a new component, MyComponent, to the class definition file. This component has one instrumented event, click:


Extends="FlexObject" SupportsTabularData="false">
FlexMyComponent


ExposureLevel="CommonUsed">
Type="click"/>





This is MyComponent.



The name used by QTP to id an object.



To be written.



Developer-assigned ID.



The index relative to its parent.



...

You can edit the class definitions file to add a new recordable event to an existing component. To do this, you insert a new in the control's block. This includes the implementation class of the event, and any arguments that the event might take.

The following example adds a new event, MouseOver, with several arguments to the Button control:


















When you finish editing the class definitions file, you must distribute the new file to QTP users. They must copy this file manually to the "QTP_plugin_install\Flex 2 Plug-in for Mercury QuickTest Pro" directory. When you replace the class definitions file in the QTP environment, you must restart QTP.


2008年3月12日星期三

Functional testing Adobe Flex applications

from IBM developerworks
http://www-1.ibm.com/support/docview.wss?rs=953&context=SSJMXE&dc=DA400&uid=swg27011420&loc=en_US&cs=UTF-8&lang=en&rss=ct953rational


Functional testing Adobe Flex applications

Release notes
Abstract
This article is intended for Adobe Flex application developers and testers. You will find this article useful if you are using IBM® Rational® Functional Tester (RFT) to test your Flex application.

IBM Rational Functional Tester, version 7.0.1 supports testing Adobe Flex applications. You can record and playback scripts against Flex based user interfaces, embedded in HTML page running inside a Web browser and verify that the application functions correctly.

Content
The testing process is based on the tasks Flex developers and testers perform. The process for automating functional tests of Flex applications differs depending on the way developers create the application-under-test.

Introduction

Using IBM Rational Functional Tester, version 7.0.1, you can record and playback test scripts against Flex based user interfaces, embedded in an HTML page running inside a Web browser and verify that the application functions correctly. Automated testing of Flex applications require you to load supporting files. These supporting files can be loaded in the two different stages:
  • At run-time for applications that are not enabled for functional testing
  • At compile-time for applications that are enabled for functional testing

Prerequisites

Before you begin, verify the following software is installed.
Developer
  • Adobe Flex SDK 2.0.1 or later, and Adobe Flex automation framework
  • Adobe Flex Builder
Tester
  • IBM Rational Functional Tester 7.0.1 or later
  • Microsoft® Internet Explorer 6.0 or later
  • Adobe Flash Player ActiveX control version 9.0.28.0 or later

Assumptions

This document includes the following assumptions regarding the testing of Flex application:
  • Testers are not skilled in developing Flex applications.
  • Testers cannot access the Flex application source code, the compiler, or documentation.
  • Flex developers do not know how to use Rational Functional Tester.

Overview

The tasks that you perform in testing Flex applications depend on the application and whether you are a developer or a tester. You can test applications that are enabled for Rational Functional Tester or test applications that are not enabled for Rational Functional Tester. These are the general steps for preparing and testing Flex applications:

Developer

To enable Flex applications for functional testing, perform the following steps:
  1. Enable the Flex application for functional testing.
  2. Create a HTML wrapper that embeds the enabled Flex application (.swf file) using an object tag
  3. Perform one of the following steps:
    • Provide the .swf file and HTML wrapper to the testers.
    • Deploy the Flex application to a Web server that testers can access, and request that the testers test the Flex application from the provided URL.
To enable the RuntimeLoading component for Flex applications that are not enabled for functional testing, perform the following steps:
  1. Configure the RuntimeLoading application.
  2. Deploy the RuntimeLoader files to a Web server. Typically deploy the files to the root directory so that this action is performed only once.
  3. Deploy the Flex application to the Web server.
  4. Provide the complete URL of the RuntimeLoading testing page to the testers.

Software tester

For applications that are enabled for functional testing, perform the following steps:
  1. Get the enabled .swf file and HTML wrapper from the developer.
  2. Perform one of the following steps:
    • Deploy the application to a Web server.
    • Run the Flex application locally for testing.
  3. Open the HTML page in the browser.
  4. Start Rational Functional Tester to test the HTML application that contains the embedded Flex application.
For applications that are not enabled for functional testing, perform the following steps:
  1. Open the RuntimeLoadingTest.html page in browser.
  2. Type the relative path of the Flex application to be tested as a query parameter to the HTML page. For example, in the address field of the Web browser, type the following query:
    http://localhost/RuntimeLoadingTest.html?automationswfurl=applicationtotest.swf
    where applicationtotest.swf is the file name of the Flex application.
  3. Use Functional Tester to test the application.
Note: Testers can also deploy the necessary files such as RuntimeLoader and the .swf file to a Web server, provided that testers can access the server. Although developers might not be familiar with Functional Tester, the developer needs the RuntimeLoader source file and the Functional Tester agent (rft.swc) to enable and deploy the Flex application. Testers need to provide these files to the developer.

Configuring the development environment for enabling Flex applications

To configure the Flex development environment:

  1. Copy the automation_agent.swc file from the flex automation install directory/frameworks/libs directory to flex builder install directory/Flex SDK 2/frameworks/libs directory.
  2. Copy the automation_agent_rb.swc file from the flex automation install directory/frameworks/locale/en_US directory to flex builder install directory/Flex SDK 2/frameworks/locale/en_US directory.
    Important: This path is for en_US locale. If you are using a different locale, replace en_US with that locale.

Enabling flex application for functional testing

Developers can enable Flex applications for functional testing. This section is intended for Flex application developers and explains different ways of enabling the Flex application for functional testing. Enable the Flex applications for testing by building the Flex application with Functional Tester agent (rft.swc) and Flex automation framework libraries.

Developers use the following tools to enable a Flex application for testing:

  • Flex Builder
  • Flex command-line compiler

Using the Flex Builder to enable Flex applications

You can use Flex Builder to make Flex applications ready for functional testing. Flex Builder is useful when you want to develop Flex applications (.swf files) that are ready for functional testing.

To set up Flex Builder to support Flex automation and functional testing:

  1. Start Flex Builder.
  2. Create a new Flex project.
  3. Select the Flex project in the navigator.
  4. Click Select Project > Properties > Flex Compiler.
  5. Enter the following in the Additional compiler arguments field:
    -include-libraries "flex builder install dir\Flex SDK 2\frameworks\libs\automation.swc” “flex builder install dir\Flex SDK 2\frameworks\libs\automation_agent.swc” "flex builder install dir\Flex SDK 2\frameworks\libs\automation_charts.swc" “functional tester dir\Functional Tester\bin\rft.swc”
    Elements in italics are variables and depend on your directory structure.
    Note: The automation_charts.swc file is required only if your application contains charting controls. The include-libraries compiler option is relative to the Flex Builder installation directory. The default Windows location is C:\Program Files\Adobe\Flex Builder 2 .
  6. Click OK to save your changes.
  7. Click OK to close the Properties dialog box.
  8. Compile your Flex application.

Using the command-line to enable Flex applications

You can use the Flex command-line compiler to enable a Flex application for functional testing. Compile the Flex application using the Functional Tester Agent and Flex Automation Libraries by running the following command: At the command line, type the following, and then press Enter:
"flex builder install directory\Flex SDK 2\bin\mxmlc" -include-libraries+= "flex builder install directory\Flex SDK 2\frameworks\libs\automation.swc; flex builder install directory\frameworks\libs\automation_agent.swc; flex builder install directory\Flex SDK 2\frameworks\libs\automation_charts.swc; functional tester directory\FunctionalTester\bin\rft.swc" Test.mxml

The AppName.mxml is the name of your .mxml file.

The default location the flex builder install directory on Windows is C:\Program Files\Adobe\Flex Builder 2 and functional tester directory is C:\Program Files\IBM\SDP70

This command is also available as a batch file buildapplicationwithadaptor.bat with Rational Functional Tester installed. Testers can provide this batch file to the developer to enable the Flex application for testing. Provide the flex application source code filename as the parameter to the batch file.

The batch file is available in functional tester directory\Functional Tester\Flex folder. For example, if your .mxml file is Test.mxml, the command to run the batch file is as follows:
buildapplicationwithadaptor.bat Test.mxml

Creating an HTML wrapper

The developer creates an HTML wrapper after compiling the Flex application with the Functional Tester agent and Flex automation testing libraries. The wrapper embeds the .swf file in an HTML page by using the object and embed tags. You can use the default HTML wrapper file that the compiler in Flex Builder generates along with the Flex application or use the HTML wrapper file in the functional testing application folder.

After creating the HTML wrapper, the developer passes the application and the HTML wrapper to the testers for functional testing. Typically developers deploy the files to a Web server that testers access.

The following example shows how the Flex application Test.swf is embedded in the HTML page:


Configuring the environment for testing Flex applications

Correct environment setup for testing Flex applications helps ensure reliable functional testing results.

To configure the Flex testing environment:

  1. Check the local security setting of the Internet Explorer ActiveX and plug-ins:
    1. Open Internet Explorer.
    2. Click Tools > Internet Options.
    3. Click the Security tab.
    4. Select the appropriate Web content zone.
      For example,
      If the Web server is configured on a remote machine:
      1. Select Local Intranet.
      2. Click Sites > Advanced.
      3. In the Add this Web site to the zone field, type the URL that you want to add to the Web server.
      4. Click Add, and then click OK.

      If the Web server is configured on local host:
      1. Select Local Intranet if the Web server is configured on local host.
    5. Click Custom level.
    6. In the Reset to list, select Medium-low.
    7. Click Custom Level. In the Settings pane, in Initialize and script ActiveX controls not marked as safe, click the Enable radio button.
    8. Click OK.
  2. Open Functional Tester and enable the environments for testing. You must enable the required JRE and set Internet Explorer as the default Web browser.

Testing Flex applications

This section is intended for testers and describes the steps for automating Flex applications with functional tests. You can test a Flex application that has been enabled for functional testing using Flex Builder or Flex command-line compiler. Testers typically work with Flex applications that a Flex developer provides. Developers provide applications in two broad categories:
  • Flex applications that are Functional Tester enabled.
  • Flex applications that are not Functional Tester enabled.

Testing Functional Tester enabled Flex application

Developers provide the application in two ways:
  • On a Web server
  • On a local test computer

Testing Functional Tester enabled Flex application from Web server

You can test a Flex application that has been enabled for functional testing. The developer deploys the Flex application to be tested on a Web server and provides the URL. You can also deploy the files, provided that you can access the Web server and the application files. To test an enabled Flex application:
  1. Get the enabled .swf file and HTML wrapper from the Web server.
  2. Open the HTML page in the browser.
  3. Start Rational Functional Tester for testing the HTML file that contains the embedded Flex application.
  4. Include the Flex application in the Application Configuration Tool.
    1. In Functional Tester, open the Application Configuration Tool by clicking Configure > Configure Applications for Testing.
    2. To add a new application, click the Add button.
    3. Select HTML application and click Next.
    4. Select either Local or URL. If Local, browse to an .htm or .html file. If URL, enter the URL address.
    5. Click Finish. The application will show up in the Applications list in the Application Configuration Tool.
  5. Start recording a test.

Testing enabled Flex application from local test computer

You can test a Flex application that is embedded in an HTML wrapper locally. Before testing a Flex application locally, verify that the .swf file is trusted.

Assigning trust designations for Flex applications

When testing Flex applications on a local computer, adjust settings so that the application is trusted. To run the application locally, the application under test has to be trusted. The paths to individual files or directories can be trusted rendering all the files in each selected directory and any of its subdirectories trusted. You can assign trust designations.

To assign trust designations:

  1. Create a folder FlashPlayerTrust in C:\WINDOWS\system32\Macromed\Flash
  2. Create a file named Flex without any file extension.
  3. Enter the path of the Flex application in the flex file.
  4. Save the file.

Testing Functional Tester enabled Flex application locally
  1. Request the HTML wrapper from the file system.
  2. Open the HTML page in the browser.
  3. Start Rational Functional Tester for testing the HTML application that contains the embedded Flex application.
  4. Start recording a test.

Advantages and limitations of testing RFT enabled Flex applications

Three advantages encourage enabling Flex applications for functional testing:
  • Efficiency: Multiple enabled Flex applications can be embedded in a single HTML page and can be tested simultaneously.
  • Ease: Testing is simplified when different Flex applications communicate with each other. All the related enabled Flex applications can be embedded in a single page and can be tested based on a single scenario.
  • Location: Enabled Flex applications can be tested locally.

Review the following limitations regarding enabled Flex applications:
  • Follow-up requirements: You must remove the references to the Flex Automation framework before deploying the application to the production server. This requirement has a minor impact on deployment.
  • Flexibility: Only the Flex Developer can enable the application for testing.

Testing a non-enabled Flex application from a Web server

You can test a Flex application that is not enabled for functional testing on a Web server. First the developer deploys the application to a Web server and provides the address.

Important: If you encounter problems while the Flex application is loading using the Runtime Loader test page, check the security settings of Internet Explorer ActiveX and plug-ins.

Configuring the Runtime loader
You can prepare a Flex application for testing without modifying and recompiling the application. You can configure the Runtime Loader to enable an application for testing when they do not want to modify the Flex application by adding the references to the Rational Functional Tester Agent and Flex automation framework libraries. To enable the testing of Flex applications that are not compiled using the Functional Tester agent and automation libraries, perform the following steps:
  1. Get the RuntimeLoader.mxml and RuntimeLoadingTest.html files, which are installed with functional testing application, from the functional tester directory\FunctionalTester\Flex directory.
  2. Compile the RuntimeLoader.mxml with Functional Tester agent and Flex automation framework libraries.
  3. Deploy the RuntimeLoadingTest.html, RuntimeLoader.swf and Flex application to test on the Web server.
  4. Provide the URL of RuntimeLoadingTest.html page to the testers, for example,
    http://localhost/RuntimeLoadingTest.html?automationswfurl=applicationtotest.swf
    where, applicationtotest.swf is the name of the Flex application to be tested.

Testing non-enabled Flex application using RuntimeLoader
Testing is performed using the RuntimeLoader component that is available with Rational Functional Tester. To test a non-enabled Flex application, perform these steps:
  1. Copy the compiled RunTimeLoader.swf and the RuntimeLoadingTest.html to the folder that contains the Flex application.
  2. Open the RuntimeLoadingTest.html page in browser.
  3. Pass the relative path of the Flex application to be tested as a query parameter to the HTML page. For example, type:
    http://localhost/RunetimeLoadingTest.html?automationswurl=applicationtotest.swf
    where applicationtotest.swf is the file name of the Flex application.
  4. Start Rational Functional Tester for testing the HTML file that contains the embedded Flex application.
  5. Include the Flex application in the Application Configuration Tool and verify that the correct JRE is enabled and associated with Internet Explorer.
  6. Start recording.

Advantages and limitations of testing non-enabled Flex applications

There are two advantages to testing Flex applications that are not enabled for functional testing:
  • Deployment option: The Flex application can be deployed in a test or production environment.
  • Ease: Testers benefit because many technical complexities are hidden.

Review the following limitations regarding non-enabled Flex applications:
  • Efficiency: Only one Flex application can be tested at a time.
  • Location: The Runtime loader cannot be run locally; you must deploy the Runtime Loader to a Web server.

Troubleshooting

Ensure that your environment and application is configured correctly. This topic describes several common troubleshooting issues. Verify the following conditions:
  • ActiveX debugger version of Flash Player 9 (version 296) is installed.
  • The application was compiled using Flex 2.0.1 with the new frameworks.swc file that supports automated testing.
  • The application is running in Microsoft Internet Explorer 6.0 or later.
  • The application is loaded through an HTML page, with an object tag that has an ID attribute set.
  • The ID attribute of object/embed element that embeds Flex app contains no periods or hyphens.
  • The application is loaded either from a Web server or locally from a trusted .swf file.
  • The Flex plug-in is not installed.
  • Internet Explorer has Active X plug-ins turned off.

2008年3月11日星期二

Xcelsius 5.0 is ready now!

From the announcements of SAP Business Objects, the Xcelsius 5.0( also called Xcelsius 2008) is released finally.

X5 is a very expectant product because there are many exciting new feature. For example new components, embed excel, beautiful user experience and so on.

In the past one year, we work together on X5. Many pain and struggle, also many happiness and achievement, come with us all the times.

Stop here and look forward the future.

2008年3月10日星期一

ExternelInterface.addcallback: A simple Flex application automated functional testing problem.

Dev environment:
FlexBuilder 2 + QTP

Problem:
The QTP cannot get the properties of every component when add some checkpoints.

Solution:
The cause of this problem is that I add a call back function in my flex application with the same name "getProperties" which is registered by QTP also.

ExternelInterface.addcallback("getProperties", functionName);

So avoid this in your code.