Domanda

I'm curious about how to test reports that seem rather straightforward. I'm supposed to create test cases for an Oracle report(XML Publisher/BI Publisher). So for example, a report is supposed to just return columns(say , 10 columns).

Here is what I thought of so far:

Validate that the  report returns accurate output.
Validate that the all column headers and table values are correctly aligned and there are no run-ons/incorrect formatting
Validate that dates are in the MM/DD/YYYY format
Validate that all currencies are accurate, and contain 2 decimal places.

Here's a sample pic(of what the report produces) :

enter image description here

What would the edge/boundary cases be? If the report takes in parameters, does that make it more demanding of a report?

Thanks

È stato utile?

Soluzione

If you're writing unit tests, you're creating a program to verify that the target code, given a specific set of input, returns a known and expected output. To make unit tests for your reports, you need:

  • A mock database that you run your test reports against.
  • Sufficient mock data to generate reports.
  • Known examples of the output said reports should generate when said mock data in mock database is sent.

Unless you're actually working on development of the Oracle software itself, you don't need to test things like "are dates actually dates" or "does each column have a header." You only need to match your mock input to your mock output, and expand your test suite until you cover all applications needed for usages in production.

OTOH, if you're actually going to test how the report returns items based on your live database, you're writing integration tests and possibly even production checks. (Are you tests going to run each time the report does, or just when a new version of code is pushed to production?)

In all cases, I'd only test that which is either important to the end-user ("is the sales column actually sales?") or otherwise part of your design specification ("UserCancellation Report includes only users marked for cancellation.").

Knowing precisely how many tests to write and what to write requires a lot of domain knowledge, not the least of which is how often these tests are ran and what your test framework is like. (You are using an automated test suite of some kind, either OSS or purchased from a vendor or even home-grown, right?)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top