You can use the above technique to automate a customized set of regression tests with the BVT specific to your environment and testing policies. Sed s:+++:”QuickStart”:g QuickStart-bvt.txtĪfter sed is run against the template file. Template File (used to generate specific BVT commands that can be cut/pasted into the command line or, any or all can be added to a script) Script to generate the group of XML files: – use a similar script to generate the BVT command files.įinally, generate a text file that houses the BVT command groups (pre, post, compare results) for each XML file, and therefore each catalog tree. Sed -i s:+++:”QuickStart”:g QuickStart.xml Generic XML template: notice “+++”, “-“ used as strings for substitution targets from a script of sed commands Output of the runcat.sh (report option) – captures the catalog tree… i.e a set of BVT commands generated for each catalog area. Generate a test file that has groups of the three BVT commands (pre, post, compare results) specific to each catalog tree or other logical division based on your specific testing strategy.
Generate an XML file from the BVT that will serve as a template for many XML files to be generated each with a specific catalog area that can be a stand-alone test. Run the Catalog Manager to generate a file with all the catalog elements listed. (prerequisite – generate an XML “template” with the BVT that will be used to seed the generation of XML files specific to catalog trees or groups of components) Here is an example of what we employ in our regression testing projects:
#Obiee runcat commands manual
If all done by hand –absolutely! However, using the catalog manager and some clever Linux command line tools (also available on Windows ), you can generate much of this automatically and negate the need for lots of manual editing of XML. You can certainly point to the top of your catalog and collect everything, however this can be cumbersome, especially with large catalogs, or catalogs that encompass large, disparate subject areas and owning organizations.Īnother way to integrate BVT into your regression strategy without lots of hand editing, or forcing collection over more of the catalog than you may need for a particular test or migration, is to use many XML files, each specific to a subject area, owning organization or other logical division, however on the surface this seems to multiply the effort and time required. One limitation of the BVT is that all tests and catalog items selected for a test must be hand entered into the XML file that governs a BVT run. Finally the third run compares the details from the first two runs and generates a set of reports that are used to determine what has been added, deleted or changed from the baseline to the modified instance. What specifically is collected and where it’s stored is based on configuration parameters in the XML file that is referred to from a command line parameter.
Both of these two runs collect detailed information from their respective instances. lifecycle promoted, patched or migrated). The second run is against the “new” version of the OBIEE (e.g. The first run is against a running system (OBIEE Instance) that is used as the baseline. Briefly, this tool is run three times in succession in a typical scenario –with command line parameters determining the type of run. This is a command line tool that is governed by an XML config file to enable you to create a baseline of the catalog and constituent components from any OBIEE system (11.1.1.7.1 forward). This is the Baseline Validation Tool (BVT).
#Obiee runcat commands verification
Oracle came out with an awesome tool for regressing testing and verification of OBIEE lifecycle and migration.
0 kommentar(er)
