23
pdfcrowd.com ope n in br owser PRO v ers ion Are you a developer? Try out the HTML to PDF API Home About Careers Clients Consulting Training Support Articles Blog Automated Regression Testing for OBIEE January 23rd, 2014 by Robi n M offatt In the first article of this series  I explored what regression testing is, why it matters, and by breaking down the OBIEE stack into its constituent parts where it is pos sible to do it for OBI EE. I n this pos ting, I explore some ap proaches that lend themselves wel l to automation for testing that existing analyses and dashb oards are not affected by RPD changes. Easy Automated RPD regression testing – it’s all about the numbers “Bring me solutions not problems”  goes the mantra, and in the first artic le all I did was rain on the parade of the de fa cto regress ion testing approach, looking at the front end using functional testing tools s uch as Seleni um. So if not at t he front end, then where should we focus our automated regres sion tes ting of OBIEE? A nswer: the data. The data shoul d arguably be what is mos t important to our users . If it’s wrong, that’s bad, and if it’s right, hopefully th ey’re going to be h appy. Obv iously, there are other fac tors in m aking us ers hap py not least performance and the visual appearance of the data. But a system that gives use rs wrong data, or no data, is fundam entally a f ailed one. Looking at the following diagram o f a request/respons e through the OBI EE stack we can see that so far as data is concerned, it is the BI Server doing all the work, handling both logical and physical SQL and data sets : Search the blog Recent Posts  Analytics w ith K ibana and Elasticsearc h through Hadoop – part 3 – Vis ualising the data in Kibana  Analytics w ith Kibana and Elasticsearch through Hadoop – part 2 – Getting data into Elasticsearch  Analytics w ith Kibana and Elasticsearch through Hadoop – part 1 – Introduc tion UKOUG Partner of the Year  Aw ards Oracle BI Cloud Service for SaaS  Applicati on R eporting Part 1: Integrating BICS to Salesfor ce.c om using RE ST API s  

Www Rittmanmead Com 2014 01 Automated Regression Testing For

Embed Size (px)

Citation preview

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 1/23

pdfcrowd comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

Home About Careers Clients Consulting Training Support Articles Blog

Automated Regression Testing for OBIEEJanuary 23rd, 2014 by Robin M offatt

In the first article of this series I explored what regression testing is, why it matters, and by breaking down the OBIEE stack

into its constituent parts where it is pos sible to do it for OBIEE. In this pos ting, I explore some approaches that lend

themselves wel l to automation for testing that existing analyses and dashboards are not affected by RPD changes.

Easy Automated RPD regression testing – it’s all about thenumbers“Bring me solutions not problems”  goes the mantra, and in the first article all I did was rain on the parade of the de facto

regress ion testing approach, looking at the front end using functional testing tools such as Selenium. So if not at the frontend, then where should we focus our automated regres sion tes ting of OBIEE? Answer: the data.

The data should arguably be what is mos t important to our users . If it’s wrong, that’s bad, and if it’s right, hopefully they’re

going to be happy. Obviously, there are other factors in m aking users happy not least performance and the visual

appearance of the data. But a system that gives users wrong data, or no data, is fundam entally a failed one.

Looking at the following diagram o f a request/response through the OBIEE stack we can see that so far as data is

concerned, it is the BI Server doing all the work, handling both logical and physical SQL and data sets :

Search the blog

Recent Posts

 Analytics w ith Kibana andElasticsearch through Hadoop –

part 3 – Visualising the data inKibana

 Analytics w ith Kibana and

Elasticsearch through Hadoop –part 2 – Getting data into

Elasticsearch

 Analytics w ith Kibana and

Elasticsearch through Hadoop –part 1 – Introduction

UKOUG Partner of the Year  Aw ards

Oracle BI Cloud Service for SaaS Application Reporting Part 1:Integrating BICS toSalesforce.com using REST APIs

 

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 2/23

pdfcrowd comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

The data that it passes back up to Presentation Services for rendering in the us er’s web browser is the raw data that feeds

into what the user will see. Obviously the data gets processed further in graphs, pivot tables, narrative views, and so on – butthe actual filtering, aggregation and calculation applied to data is all complete by the time that it leaves the BI Server.

How the BI Server responds to data reques ts (in the form o f Logical SQL queries) is governed by the RPD, the metadata

model that abstracts the physical source(s) into a logical Busines s model. Because of this abstraction it means that all

Logical queries (i.e. analysis/dashboard data requests) are compiled into Physical SQL for sending to the data source(s) at

runtime only. Whenever the RPD changes, the way in which any logical query is handled may change.

So if we focus on regress ion testing the impact that changes to the RPD have on the data alone then the available methods

become clearer and easier. We can take the Logical SQL alone that Presentation Services generates for an analysis and

sends to the BI Server, and we can run it di rectly agains t the BI Server ourselves to get the resulting [logical] dataset. This can

be done us ing any ODBC or JDBC client, such as nqcmd (which is s upplied with OBIEE at installation).

op os s

OBIEE 11g Security Week :Managing Application Roles and

Policies, and Managing SecurityMigrations and Deployments

Upgrading OBIEE to 11.1.1.7

OBIEE 11gR1 : Architecture and

Use of WebLogic Server 

OBIEE 11g Security Week :Connecting to Active Directory,

and Obtaining Group Membershipfrom Database Tables

 Analytics w ith Kibana andElasticsearch through Hadoop -

part 3 - Visualising the data inKibana

Random Posts

Oracle BI Apps 11.1.1.7.1 –GoldenGate Integration - Part 4:Initial Load and Replication

End-to-End ODI12c ETL on OracleBig Data Appliance Pt.5 : BulkUnload to Orac le

Simple Hadoop Dataflow s using Apache Pig and CDH4.6

Oracle Endeca InformationDiscovery v3.0 Integration w ith

the OBIEE 11g BI Server 

 Automated RPD Builds w ith OBIEE

Tags11g Big Data Appliance

BIP BI Publisher  dw em12c

 

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 3/23

pdfcrowd comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

Faith in reason

If:

the Logical SQL remains the same (i.e. the analysis has not changed nor Presentation Services binaries changed –

but see caveat below)

the data returned by the BI Server  as a result of the Logical SQL before and after the RPD change is m ade is the same

Then we can reason (through the above illustration of the OBIEE stack) that

the resulting report shown to the user  will remain the same.

Endeca exalyticsextremebi git

goldengatehadoop Hive init.d install

linux MDS XML monitoring

new features nqcmd OBIA

obiee odi odi12c

opatch Oracle Oracle BI

 Applications  oracle dataintegrator  Oracle

Endeca Oracle Endeca

Information Discovery ow b

performance Real Time

Decisions replication

ReportService RTD runReport

sampleapp screen scripting

security startup testingtraining XML

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 4/23

pdfcrowd comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

Using this logic we can strip away the top layer of testing (trying to detect if a web page m atches another) and tes t directly

agains t the data without having to actually run the report itself.

In practice

To use this method in practice, the process is as follows:

1. Obtain the Logical SQL for each analysis in your chosen dashboards

2. Run the Logical SQL through BI Server, save the data3. Make the RPD changes4. Rerun the Logica l SQL through BI Server, save the data5. Compare da ta before & after to detect if any changes occurred

The Logical SQL can be obtained from Usage Tracking, for example:

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 5/23

pdfcrowd comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

or you can take it directly from the nqquery.log. For more than a few analyses , Usage Tracking is definitely the more practical

option.

You can also generate Logical SQL directly from an analysis in the catalog using runcat.sh – see later in this pos t for details.

If you don’t know which dashboards to take the Logical SQL from, ask yourself which are going to cause the most ups et if they stop working, as well as m aking sure that you have a representative sam ple across all usage of your RPD’s Subject

 Areas.

Give the Logical SQL of each analysis an ID and have a log book of which dashboard it is associated with, when it was taken,

etc. Then run it through nqcmd (or alternative) to return the first version of the data.

where:

-d is the BI Server DSN. For remote testing this is de fined as part of the configuration/installation of the client. For testing

local to the s erver it will p robably be AnalyticsWeb  on Linux and coreapplication_OHxxxxxx  on Windows

-u and -p are the credentials of the user under whos e ID the test should be executed

-s specifies the Logical SQL script to run

-o the output file to write the returned da ta to.

SELECT QUERY_TEXT FROM  S_NQ_ACCT WHERE  START_TS > SYSDATE - 7

nqcmd -d AnalyticsWeb -u weblogic -p Password01 -s analysis01.lsql -o analysis01.befo 

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 6/23

pdfcrowd comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

For more information about nqcmd see the manual.

Once you’ve run the initial data sam ple, make your RPD changes, and then rerun the data collection with the sam e

comm and as before (except to a different output file). If the nqcmd command fails then it’s an indication that your RPD hasfailed regress ion testing already (because it means that the actual analysis will pres umably also fail).

 An important point here is that if your underlying source data changes or any time-based filter results change then the test

results will be invalid. If you are running an analysis looking at “Sales for Yesterday”, and the regression test takes several

days then “Yesterday” may change (depending on your init-block approach) and so will the res ults.

 A second im portant poin t to note is that you must take into account the BI Server cache. If enabled, either disable i t during

your testing, or use the DISABLE_CACHE_HIT request variable with your Logical SQL statements.

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 7/23

pdfcrowd comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

Having taken the before and after data collections for each analysis , it’s a s imple matter of comparing the before/after for 

each and reporting any differences. Any differences are typically going to mean a regress ion has occurred, and you can us e

the before/after data files to identify exactly where. On Linux the diff comm and works perfectly well for this

In this case we can s ee that the ‘after’ test failed with a mis sing table error. If both files are iden tical (meaning there is no

difference in the data before and after the RPD change), there is no ou tput from diff:

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 8/23

pdfcrowd comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

Tools like diff are not pretty but in practice you wouldn’t be running all this m anually, it would be scripted, reporting on

exceptions only.

So a typical regress ion test suite for an existing RPD would be a s et of these nqcmd calls to an indexed list of Logical SQL

statements, collecting the results for comparison with the sam e executions once the RPD changes have been made.

Tips

Instead of collecting actual data, you could run the res ults of nqcmd di rectly through md5 and store just the hash of each

resultset, making for faster comparis ons. The drawback of this approach would be that to examine any discrepancies

you’d need to rerun both the before & after tests. There is als o the theoretical risk of a has h collision (where the sam e

hash is generated for two non-matching datasets ) to be aware of.

diff sets a shell return code depending on whether there is a difference in the data (RC=1) or not (RC=0), which makes

it handy for scripting into if/then/else shell script statements

nqcmd uses stdout and stderr, so ins tead of specifying -o for an output file, you can redirect the output of the Logical SQL

for each analysis to a results file (file descriptor 1) and an error file (file descriptor 2), making s potting errors easier:

Taking it one step further 

We can s trip away the layers even further, in two additional s tages:

Instead of examining the data returned by a generated physical SQL query, sim ply compare the generated SQL query

itself, before and after a RPD change. If the query is the same, then therefore the data returned will be the same, and

therefore the report will be the same.

nqcmd -d AnalyticsWeb -u weblogic -p Password01 -s analysis01.lsql 1>analysis01.ou

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 9/23

df d mi b PRO i Are you a developer? Try out the HTML to PDF API

One thing to watch for is that the Physical query logged in Usage Tracking (although not in nqquery.log) has a Sess ion ID

embedded at the front of it which will make direct comparison more di fficult.

The Physical SQL is dependant on the RPD; if the RPD changes then the Physical SQL may change. However, if neither 

the RPD nor inbound Logical SQL has changed and only the underlying data source has changed (for example, a

schema modification or database migration) then we can ignore the OBIEE stack itself  and s imply test the results of the

Physical SQL statement(s) ass ociated with the analysis/dashboard in ques tion and make sure that the same da ta is

being returned before and after the change

The fly in the ointment – Logical SQL generationThis may all sound a bit too good to be true; and there is indeed a catch of which you should be aware.

Presentation Services does not save the Logical SQL of an analysis, but rather regenerates i t at execution time. The

implication of this is that the above nqcmd method could be invalid in certain circums tances where the generated Logical

SQL changes even when the analysis and patch level remain unchanged . If an analysis’ Logical SQL changes then we

cannot use the same be fore/after dataset comparison as described above — because the ‘after’ dataset would not actually

match what would be returned. In reality, if the Logical SQL changes then the corresponding Logical res ultset is als o going to

be different.

Two factors that will caus e Presentation Services to generate different Logical SQL for an analysis without changing the

analysis at all are modifications to an RPD Logical Column’s Sort order column or Descriptor ID column configuration.

 As an example , consider a standard “Month” column. By defaul t, the colum n will be s orted alphabetically, so starting with

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 10/23

df di b PRO i Are you a developer? Try out the HTML to PDF API

 April (not January)

The Logical SQL for this can be seen in the Advanced tab

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 11/23

df di b PRO i A d l ? T t th HTML t PDF API

Now without mod ifying the analysis at all , we change the RPD to add in a Sort order column:

Reload the RPD in Presentation Services (Reload Files and Metadata) and reload the analysis and examine the Logical SQL.

Even though we have not changed the analysis at all, the Logical SQL has changed:

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 12/23df di b PRO i A d l ? T t th HTML t PDF API

When executed, the analysis results are now sorted according to the Month_YYYYMM column, i.e. chronologically:

The same happens wi th the Descriptor ID Column se tting for a Logical Column – the generated Logical SQL will change if 

this is m odified. Changes to Logical Dimens ions can als o affect the Logical SQL that is generated if an analysis is using

hierarchical columns . For example , if the report has a hierarchical colum n expanded down one level, and that level is then

deleted from the logical dim ension in the RPD, the analysis wi ll instead s how the next level down when next run.

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 13/23df di b PRO i

Are you a developer? Try out the HTML to PDF API

Regression Testing Logical SQL generationIt is important that Logical SQL is cons idered as part of regression tes ting if we are using this targeted approach – it is the

price to pay for selectively testing elements of the s tack using reas oning to exclude others. In this case, if the Logical SQL

changes then we cannot compare datasets (because the source query will have changed when the actual analysis is run). In

addition, if the Logical SQL changes then this is a regres sion in itself. Consider the above Sort order column example – if 

that were removed from an RPD where it had been present, users would s ee the effect and quite rightly raise it as a

regression.

There are at least two ways to get the Logical SQL for an analysis programatically : the generateReportSQL web s ervice, and

the Presentation Services Catalog Manager tool. We will look at the latter option here. The Catalog Manager can be run

interactively through a GUI, or from the command line. As a command line utility it offers a rich set of tools for working with

objects in the Presentation Catalog, including generating the Logical SQL for a given analysis. The logical outline for using it

would be as s hown below. If the Logical SQL is not identical, or runcat.sh fails to generate Logical SQL for the analysis after 

the RPD is changed, then a regression has occurred. If the Logical SQL has remained the same then the testing can

proceed to the nqcmd m ethod to compare res ulting datasets.

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 14/23df di b PRO iAre you a developer? Try out the HTML to PDF API

runcat.sh is a powerful utility but a bit of a sensitive soul for syntax. First off, it’s eas iest to call it from its home folder:

To see a ll the things that it can do, run

Or further information for a particular comm and (in our case , we’re using the report command):

cd $FMW_HOME/instance1/bifoundation/OracleBIPresentationServicesComponent/coreapplica

 ./runcat.sh -help

./runcat.sh -cmd report -help

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 15/23df di b PRO iAre you a developer? Try out the HTML to PDF API

So to generate the Logical SQL for a given analysis, call it as follows:

Where you need to replace:

server:port with your BI Server and Managed Server port number (for example, biserver:9704)

creds.txt is a file with your credentials in, see below for further detailsoutput.lsql is the name of the file to which the Logical SQL will be written. Remove the ‘force’ prefix if you want runcat.sh

to abort if the file exists already rather than overwrite it

 /path/to/analysis is the full path to the analysis (!), which you can get from both OBIEE (Catalog -> Object -> Properties)

and from the Catalog Manager in GUI mode (Object -> Properties). In the screenshots here the full path

is /shared/Standard/Analyses /Sales Report

 

./runcat.sh -cmd report -online http://server:port/analytics/saw.dll -credentials cre

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 16/23

Are you a developer? Try out the HTML to PDF API

Having called runcat.sh once, you then make the RPD change, reload the RPD in Presentation Services, and then call

runcat.sh again and compare the generated Logical SQL (e.g. using diff ) - if it’s the same then you can be sure that when the

analysis runs it is going to do so with the same Logical SQL and thus use the nqcmd m ethod above for comparing

before/after datasets .

To call runcat.sh you need the credentials in a flatfile that looks like this:

If the plaintext pass word makes you uneas y then consider the partial workaround that is proposed in a blog pos t that I wrote

last year : Make Use of OBIEE’s Command Line Tools with Reduced Exposure of Plain Text Passwords

Bringing it together Combining both nqcmd and runcat.sh gives us a logic flow as follows.

1. Run Logical SQL through nqcmd to generate initial dataset2. Run analysis to which the Logical SQL corresponds through runcat.sh to generate initial Logical SQL3. Make RPD changes4. Run analysis through runcat.sh again. If it fails, or the Logical SQL doesn ’t match the previous, then regress ion

occurred.

5. Rerun nqcmd, and com pare the before/after datasets. If they don’t match, or nqcmd, fails, then regress ion occurred.

login=weblogicpwd=Password01

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 17/23

pdfcrowd.comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

You may wonder why we have two Logical SQL statements present – that for use with nqcmd, and that from runcat.sh.

The Logical SQL for us e with nqcm d will typically come from actual analysis execution (nqquery.log / Us age Tracking) with

filter values present. To compare generated Logical SQL, the source analysis needs to be us ed.

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 18/23

pdfcrowd.comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

e a ues p ese o co pa e ge e a ed og ca SQ , e sou ce a a ys s eeds o be us ed

SummarySo to summ arise, automated regress ion testing of OBIEE can done us ing just the tools that are shipped with OBIEE (and a

wee bit of scripting to automate them). In this article I’ve dem onstrated how automated regress ion testing of OBIEE can be

done, and s ugges ted how it shou ld be done if the changes are jus t in the RPD. Working directly with the BI Server, Logical

SQL and resultset is much m ore practical and easier to automate at scale. Unders tanding the caveat to this approach – that

it relies on the Logical SQL remaining the sam e – and understanding in what situations this may apply is important. I

demonstrated another automated method that could be used to automatically flag any tests for which the dataset

comparison results would be invalid.

Testing the data that analyses request and receive from the BI Server can be done us ing nqcmd by passing in the raw

Logical SQL, and this Logical SQL we can also programatically validate using the Catalog Manager  tool in command line

mode, runcat.sh.

Looking back at the diagram from the first pos t in this series , you can see the opportunities for regression testing in the

OBIEE stack, with the point being that a clear comprehens ion of this wou ld allow one to accurately target testing, rather than

ass uming that it mus t take place at the front end:

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 19/23

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 20/23

pdfcrowd.comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

I know I’ve not covered Selenium, bu t I’ve included it in the diagram for completeness. The other tool that I plan to cover in a

future posting is the OBIEE Web Services as they also could have a role to play in testing for specific regress ions.

ConclusionTake a step back from the detail, I have shown here a viable and pragmatic approach to regress ion testing OBIEE in a

manner that can actually be imp lemented and automated at scale. It is important to be aware that this is not 100% test

coverage. For example , it omits im portant considerations such as testing for security regress ions (can people now see what

they shouldn’t). However, I would argue that some regres sion tes ting is better than none, and regress ion testing “with one’s

eyes open” to its limitations that can be addressed manually is a sensible approach.

Regress ion testing doesn’ t have to be automated. A sens ible mix of automation and m anual checking is a good idea to try

and maximis e the test coverage, perhaps following an 80/20 rule. The challenges around regress ion testing the front end

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 21/23

pdfcrowd.comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

Tweet 26 2Like

mean that it is sens ible to explore more focuss ed testing further down the stack where possib le. Just because the front end

regress ion testing can’t be automated, it doesn ’t mean that the front end shouldn’t be regress ion tested – but perhaps it is

more viable to spend time visually checking and confirming som ething than investing orders o f magnitude more hours in

building an automated solu tion that will only ever be less accurate and les s flexible.

Regress ion Testing OBIEE is not something that can be solved by throwing software at it. By definition, software must be told

what to do and OBIEE is too flexible, too complex, to be able to be constrained in s uch a manner that a single software

solution will be able to accurately detect all regressions .

Successfully planning and executing regression tes ting for OBIEE is som ething that needs to be not only part of a

project from the outset  but is som ething that the developers m ust take active responsibility for . They have the user interviews,

the functional s pecs, they know what the system should  be doing , and they know what changes they have made to it — and

so they should know what needs testing and in what way. A siloed approach to development where regress ion testing is

“som eone els e’s problem” is never going to be as effectively (in terms of accuracy and time/money) as one in which

developers actively participant in the des ign of regress ion tests for the specific project and development tasks at hand.

Many thanks to Gianni Ceresa for his thoughts and assistance on this subject.

Related Posts:

OBIEE Regression Testing – An Introduction

Visual Regression Testing of OBIEE with PhantomCSS

Built-In OBIEE Load Testing with nqcmd

Tags: diff , logical sql, nqcmd, obiee, odbc, regression, testing

Tags: diff , logical sql, nqcmd, obiee, odbc, regression, testing

Posted in Oracle BI Suite EE, Testing | 1 Comment »

Comments

Share 21

JP Says:

F b 13th 2014 t 11 08

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 22/23

pdfcrowd.comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

February 13th, 2014 at 11:08 am

This Sounds good and I appreciating for the detail explanation. But I have a doubt On generate the Logical SQL with

Dashboard default filters (Like: I have a year Prompt with default value “2014″ …). Normally in analysis the year value m ay

not be 2014.

and one m ore ques tion if we have multiple values in prompt can we generate the logical SQL by applying all the values.

Thanks,

JP

Call us now to talk about your BI project:

+44 (0) 1273 911 268 (UK) or  (888) 631-1410 (USA)

or  +61 3 9596 7186 (Australia & New Zealand) or +91 997 256 7970 (India) or  +32 280 882 11 (Belgium)

Home

About Us> About us

> About our team

> Contact us

> Our clients

Services> Consulting

> Training

> Support

ConsultingServices> Projects

> Expert Services

> OBIEE 11g

> Sustainability

> On Discoverer?> Oracle DW

Training> OBIEE

Bootcamp

> OBIEE End-User 

> Exalytics

> ODI 11g

Bootcamp> Oracle BI Apps

Resources> Articles

> Blog

> OBIEE 11g

Blog Authors> Mark Rittma n

> Venkat J

> Peter Scott

> Borkur S

> Mike Vic kers

> Robin Moffatt> Jon Mead

Rittman Mead Consulting ltd.

Registered Office : Suite B,

First Floor Moore House,

13 Black Lion Street,

Brighton, East Sussex,

BN1 1ND, United Kingdom

Company No. : 6032852 

VAT No. : 900 3839 48 

Rittman Mead America, Inc.

Registered Office : 4550 North Point Parkway

390 Alpharetta, Georgia 30022, USA

Rittman Mead Oceania Pty Ltd.

Registered Office : 12 Moore Street,

Brighton East,

Victoria, 3187, Australia

 Austral ian Company No. : 1 49 458 9 35 

Rittman Mead Consulting Pvt Ltd.

Registered Office : Unit 105 106

8/10/2019 Www Rittmanmead Com 2014 01 Automated Regression Testing For

http://slidepdf.com/reader/full/www-rittmanmead-com-2014-01-automated-regression-testing-for 23/23

pdfcrowd.comopen in browser PRO version Are you a developer? Try out the HTML to PDF API

Website Design & Build: tymedia.co.uk

 

Registered Office : Unit 105-106 

Regent Prime

Whitefield Main Road 

Whitefield 

Bangalore

560066 

Rittman Mead Belgium

Registered Office : Chaussée de Louvain 426 

1380 Lasne

Belgium

 © 2010-2011 Rittm an Mead Cons ulting. | Privacy Policy | E: info@rittm anmead.com