No. Currently not supported.
Yes. Refer to built-in functions document.
Yes. Use callScript() or callScriptUpto(). Refer to Chaining Scripts document.
Yes. A provision to substitute data at runtime will allow this type of testing.
Yes. Refer to handling exceptions document.
Yes. Use invokeApplication() or invokeApplicationInThread(). Refer to built-in functions document.
Yes. Use the Settings tab to set maximum time limit to wait for response.
This tool records from and plays entirely inside the browser.
No. Currently not supported.
Xquery is a useful query language which is designed to query XML data and it is very useful in making changes to query. Its subset is Xpath. This XQuery is formed from the experts of w3c. This facilitates extraction of data from many different databases. This can be rightly said that in future it will be used as SQL.
Some of the features which are present in XQuery language are as follows: -
1) Logical and physical data independence
3) High level
4) Side effect free
5) Strongly typed language
During the process of XML validation two processes are followed which are 1) Reference validation and 2) Signature validation Record digest value is used to verify digital signature. In signature validation a process called Canonicalization is used, in this key info is used to verify the signature.
Often it happens that documents are identical in many different ways either logical of statistical. It becomes a major problem when you try to sign a digital signature on two identical documents, to eliminate this problem you have to use Canonicalization which helps people in identifying two similar documents with similar digital signature. Similar documents use Canonicalization to identify similar patterns and signature.
An interpreting version of XSLT.
This is the oldest form of format for XML is DTD. The full form for DTD is document type definition and it is inherited from SGML. It can be said that inclusion of DTD has increased the popularity of XML but DTD has its share of limitations.
With TestComplete you can access internal objects of Flex applications. To do this, you should compile your Flex application with the Generate accessible SWF file option enabled and make TestComplete recognize Flash elements as MSAA objects (see instructions in the previous answer). After you prepared your Flex application and the TestComplete project, switch to the Object Browser panel. The available application objects will be displayed under the '...Window("Internet Explorer_Server").Window("MacromediaFlashPlayerActiveX")' node in the Object Browser. These objects are exposed by TestComplete's MSAA Open Applications plug-in. Note that TestComplete can only access those controls that implement the IAccessible interface. By default, not all objects in Flex applications implement this interface.
Most likely the script addresses web page elements by their index. TestComplete uses indexes if the element does not contain the Id or Name attribute (if any of these attributes are specified, TestComplete uses the attribute value to address the element). Using Id or Name is more reliable than using the indexes since the indexes can change from one test run to another. To work around the problem, use any of the following approaches: • In the source code of the tested web page, specify the Name or Id attribute for all controls that you need to work with from scripts. Upon doing this, you will be able to address the controls using the specified identifiers. • Use the Page(…).NativeWebObject.Find method to search for the desired control by values of its properties and attributes (innerText, innerHTML, href, src and so on).
Add the IEXPLORE.EXE application and specify the name and path of the desired HTML page as a command-line argument.
When opening some pages, you may see a Login dialog where you should enter the user name and password in order to access the page or the browser may display the Information bar asking for your permission to perform certain actions requested by the page. If you test these type of pages, you need to write code that will:
► Open the page.
► Close the the Login dialog or the Information bar by simulating user actions over them.
► Wait until the page is loaded. Note that the Page.ToUrl method, which is used to open pages, does not return the execution control to the script until the specified page is loaded. In other words, it does not return the execution control until the Login dialog or Information bar is closed. To close the dialog and informative message you should simulate user actions that will close the dialog and the bar. However, you cannot do this since the ToUrl method does not return the control until the dialog and the bar are closed. To work around the problem, you can use any of the following approaches:
► Enter the page's URL into the Address bar or into the File | Open dialog of your web browser (for example, using the Keys method).
► Use the Navigate or Navigate2 methods of the page object (this is only valid for pages displayed in Internet Explorer or a WebBrowser control).
► Call the Page.ToUrl method using the Runner.CallObjectMethodAsync method.
estComplete provides you with access to methods and properties of web page elements, so you can search all web page elements and find the desired text in the element properties. To perform the search, you can use the Page object's Find method. This method uses three parameters: Page.NativeWebObject.Find(PropertyName, KeyValue, TagName)
► PropertyName - Name of the property, whose value is checked by the method. Typically, the element's text is accessible through the innerHTML or innerText property.
► KeyValue - The sought-for text (you can use the * and ? wildcards to specify the search masks).
► TagName - This parameter is optional. You can use it to specify tag names that you would like to search in. Note that since the name of the Find method coincides with the name of the Find method added to all tested objects by TestComplete, the Page object's method resides in the NativeWebObject namespace, that is, in your script you should call Page.NativeWebObject.Find rather than Page.Find. For code examples, see the Searching for Web Page Element Containing Specific Text blog on our AQCommunity site or the “Searching for the Element Containing the Desired Text” help topic.
You can obtain the page's text using the document.body.innerText property and search for the desired text in it. For more information and code examples, see the “Checking if a Page Contains Specific Text” help topic.
To find an image within a web page, you can use one of the following approaches:
► Search for the IMG element whose SRC attribute contains the file name of the desired image. To perform the search, use the Page.NativeWebObject.Find method (see the method's description above).
► Use TestComplete's image-search capabilities. You can call the Picture method of the web browser window to obtain a Picture object holding the window image, and then use the Find method of this object to search for the desired image. This method returns a rectangle that specifies coordinates of the image within the web browser window. To obtain the scripting object corresponding to the found image, you can use the Sys.ObjectFromPoint method. Both approaches are equally valid, however, finding the image by name works much faster. For more information and code examples, see the TestComplete Tips: Finding an Image on a Web Page blog on our AQCommunity site or the “Finding an Image on a Web Page” help topic.
There are several types of whitespace characters that can be used in HTML pages: “usual” spaces (with ASCII code 32), non-breaking spaces ( , code 160), end spaces ( , code 8194) and others. For more information on these characters, see the Whitespace and Formatting Characters article. The Utilities.Trim function only removes the “usual” spaces from the string. To remove other whitespaces, you can use the Utilities.StringReplace function to replace them with empty strings. For example, the code snippet below demonstrates how to remove non-breaking spaces from a string
Your internal QA department has done all it can to ensure that your software functions as designed. The light is shining at the end of the development tunnel; your product is nearing completion, and the release deadline is rapidly approaching. You know that the application functions on all of your in-house computers. What about the myriad of computer systems of your target users? Nothing upsets your customers more than breaking open that shrink-wrap (or downloading the software from your site) only to find that a conflict exists with the software or hardware they have installed on their computer, rendering your product inoperable. Compatibility testing can help you avoid that dangerous and expensive pitfall
Third-party testing labs will conduct the compatibility testing. Exactly what will be tested will differ from application to application, but generally, testing will cover the following:
► How the application interacts with core phone functionality. For example, how the application handles scenarios such as an instant message or other system alerts being pushed to the device while the user is in another application.
► Core application stability over time. Numerous events will be sent into the event queue to see how the application handles them and to look for instability (i.e. crashes), memory usage (i.e. leaks), etc.
► Major application functionality. Testing will be conducted to make sure the major functionality you claim for your application actually is in the application. Qualcomm will not test this functionality for "correctness" from an end-user perspective.
► A standard set of tests for each area of BREW functionality used by the application. For example, we will use a standard file system test suite if the application uses the BREW file system calls. Similarly, if an application uses the BREW networking calls, we will test this with a standard networking test suite.
► Any operator or manufacturer-specific look and feel requirements.
► Compatibility with the target device(s).
► Interaction with required accessories.
If installation fails:
o Make sure that the "Geotrust CA for UTI" root certificate can be found (Tools -> Settings -> Security -> Certif. Management).
o Check that the date and time are correct.
o Make sure that the Subscriber Identity Module (SIM) card is in the device.
If installation fails: o Make sure that the "Geotrust CA for UTI" root certificate can be found (Tools -> Settings -> Security -> Certif. Management). o Check that the date and time are correct. o Make sure that the Subscriber Identity Module (SIM) card is in the device.
If your application is Symbian Signed and the installation fails, check that
o Symbian B root certificate can be found (S60 device: Tools -> Settings -> Security -> Certif. Management) .
o Date and time are correct o SIM card is in place
There shouldn't be any problem with the installation itself. However, if the application has only been tested with one device, there's no guarantee that it will work in other devices. Therefore, retesting with other target devices is recommended. Also, be aware that applications developed for S60 1st and 2nd Editions cannot be installed to an S60 3rd Edition device as such. At minimum, it will be necessary to recompile the application with the corresponding SDK.
There shouldn't be any problem with the installation itself. However, if the application has only been tested with one device, there's no guarantee that it will work in other devices. Therefore, retesting at least with target lead devices is recommended. Java Verified supported devices can be found at www.javaverified.com -> Table of supported devices.
Because signing is mandatory in S60 3rd Edition, all applications must be signed with a certificate to be able to install the application to a device. If the application doesn't need any capabilities, it can be signed with a self-created certificate, which can be created with the S60 3rd Edition SDK. If capabilities are needed, a Symbian developer certificate is required in the testing and development phase to be able to test the application on a real device. For final applications, some capabilities are granted only through Symbian Signed, so the application must be Symbian Signed to gain access to certain capabilities. Also, Symbian Signed may be a requirement for getting the application to a manufacturer or operator sales channels, for example.
Yes, signing is mandatory. Be aware that signing is not the same as certification, which is NOT mandatory in S60 3rd Edition. An application can be signed with a self-created certificate, which you can make with the SDK. Or, if you want to get your application tested and certified by a common testing program, you can submit your application to Symbian Signed.
Accessibility testing for web sites is a service that can provide much more than the standard point-by-point testing techniques of most automated services.
TC Trustcenter Publisher ID is valid for one year. Developer certificate is valid for six months. When requesting developer certificate, check that your Publisher ID is valid. When signing an application with developer certificate, Publisher ID (.key) and developer certificate (.cer) must both be valid. You can check the certificate expiration date by double-clicking the .cer file in Windows explorer.
The Nokia VID is used to protect sensitive areas of the System. These areas may affect the type approval of the device. That is the reason why Nokia VID use cannot be granted to anyone.
The Help documentation in the S60 3rd Edition SDKs provides general guidance on which platform security capabilities are required for various APIs. The capabilities that an application requires can be confirmed in the S60 emulator. When the option "Enable EPOCWIND,OUT Logging" is selected in the emulator and the PlatSecDiagnostics is set ON in epoc.ini, a log file is created in the Windows "temp" folder called epocwind.out that includes information about the capabilities required. The information is a warning message indicating that a capability is needed.
Yes it is. This functionality is allowed only for certified applications.
The Unique Identifier (UID) is a unique identification for the binary (EXE or DLL) within the system. Its purpose is to prevent executables from interfering with each other. For S60 3rd Edition applications UIDs have to be reapplied.
Yes. Symbian has introduced a model for freeware applications. Detailed information can be search at google.
Test houses have their own prices for Symbian Signed testing. You can check the prices by searching over the internet.
TC Trustcenter Publisher ID is needed if you want to get your application Symbian Signed (freeware developers excluded). Publisher ID identifies you as the source of the application. Before submitting the application to Symbian Signed, you need to sign it with a Publisher ID. The test house checks the signature and verifies that the application hasn't been tampered with on the way to Symbian signing and that the application is coming from you.