Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Describes the tests needed to validate the Audit Trail functionality. This includes test of both the Audit trail service and the audit trail service functionality on the contributing components.


The AuditTrail service should have been running for enough time for the collector to have collected audittrail events from the components prior to the test.

WebGUI

  • First verify that audittrail events has been collected. All audittrail events should be requested via the web interface.
    • The returned list should contain entries from all the different components expected to deliver audit trail information.
  • Test the different filters
    • Dates:
      • Filter on a valid date range
        • Only audit trail events from the date range should be present in the list of audit trail events.
      • Filter on an invalid date range (the start date being after the end date)
        • No change should happen to the list of events
      • Filter only on a start date
        • Only events from the start date and forward should be present in the event list
      • Filter only on a end date
        • Only event prior and up to the end date should be present in the event list
    • Filter on a known fileID
      • Only events related to the specified fileID should be present in the event list.
    • Filter on an unknown fileID
      • No events should be present in the event list
    • Filter on a known component
      • Only events from the specified component should be present in the event list
    • Filter on an unknown component
      • No events should be present in the event list
    • Filter on a known actor
      • Only events related to the specified actor should be present in the event list
    • Filter on an unknown actor
      • No events should be present in the event list
    • Filter on the different action types
      • Only actions from the specified type should be present. "ALL" being the exception, as it should allow for any type.
    • Filter a couple of collections and verify only audit trails for the selected collection is listed.
    • Change the number of listed event and verify the number of listed event changes accordingly.

Audit trail preservation

This test is rather cumbersome, and should only be run in case of changes to the code affecting the audit trail preservation

  1. Configure the audit trail preservation to run every 10 minutes and set the log level to debug. Also configure the audit trail collect grace period so the collection never starts.

     <AuditTrailServiceSettings>
        ...
        <GracePeriod>99999999999</GracePeriod>
        <AuditTrailPreservation>
          <AuditTrailPreservationInterval>6000</AuditTrailPreservationInterval>
          ....
        </AuditTrailPreservation>
  2. Clear the (audit trail service) database.
  3. Restart the tomcat
  4. Look in the audit trail service log to verify that:
    1. The audit trail preservation is scheduled to run every minute
    2. The first preservation run should start quickly.
    3. The preservation should finish quickly packing 0 audit trails (no audits have been collected yet).
    4. All collections are preserved
  5. Start the collection of audit trails.
  6. Look in the audit trail service log to verify that:
    1. Some audit trail have been collected prior to the preserver running.
    2. The preserver start as scheduled.
    3. A number of audit trail are packed and ingested.
    4. The contents of the packed  

key priority summary type created fixversion

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  • No labels