Daylight saving Time (DST) test

Daylight saving time testing is a relatively small test, mainly for software that is used in countries with daylight savings, and if you are exposed to this test, you are earning money abroad:). Not much to say, first to introduce what is daylight saving time: Daylight saving, Summer season (daylight saving Time:dst), also known as "Daylight Saver" and "Daylight Time", is a system for saving energy and artificially set the local timing, the unified time used during the implementation of the system is called " Daylight Saving Time ". What we call daylight saving time actually consists of two categories: Daylight and Winter

• Daylight Saving Time (9:00am-AM)
  • Dial back one hours and change directly from 1 to 3, which means we have a meeting with the Yankees one hours ahead of the original.
• Winter Time (9:00am-i)
  • One hours ahead, two 1 points, one hours later than usual.

From these two types, our test focus is on time-related operations (time display, comparison) to detect whether the system is functioning correctly. Let's take a look at each of the points of interest in daylight saving time testing:

• White box test
  • The code goes through to find the modules associated with the time operation, making a reasonable time conversion (local time to UTC time). The focus here is on time-related parts, which can be ignored if the module is only related to dates.
  • Not all time-related modules are converted to UTC time, which is determined by business decisions (such as printing log and interface time, which requires local time, not UTC)

• UI Test
  • Time input: For controls that need to enter a start time, you need to be aware of the input checks on daylight savings day, such as no 2:00am on the day. (For winter, if you choose AM to represent the first point)
  • Time display (output): The display rule for the product time is consistent with the local time. For sections that need to be displayed, note that daylight saving time is not 2:00am, and winter time includes a second 1:00am
  • Report display: The first most of the data from the report is from the database, and the database is generally saved in UTC time, so need to convert to local time display, when the report may appear on the situation is: Some have the starting time of the item end time < start time, if there is no special requirements, The results of this report are acceptable, but be careful to check the accuracy of the time conversion.

• Data storage
  • File storage: This is divided into log and data files
    • Log files need to be stored in local time, mainly to ask for convenient viewing.
    • Data files need to be stored in UTC or timestamp to prevent inaccurate data.
  • Database
    • It needs to be stored in UTC time or timestamp.
    • Perform a query operation to see if the correct result is returned
    • Perform data table operations near daylight saving time conversion points, check data times display (UTC or timestamp)
    • For tasks in the database that need to be scheduled regularly, pay extra attention to the execution time on the day of daylight savings.

• Functional Testing
  • Tasks across time periods
    • There are often some tasks that span the time period, for example: a job schedule execution time is 2:00am, on daylight saving Day because no 2:00am,job will be executed? Or in the winter time 1:59am execution, the second 1:00am execution, job will not error? The following time periods are required for special attention in our testing capabilities, which are guided by these time periods and can be used to cover most scenarios.

• • • Points to note:
• 1. 1. Daylight Saving Time no 2:00am
     2. Task consumption time interval It is important to note that if a task is performed 1:50 to 3:10, it actually takes only 20 minutes instead of 1 hours and 20 minutes
     3. In winter, there are two points, the pre-planned task of 1:00AM, referring to the first 1:00am
     4. In winter, there are more typical time periods in Figure 5, which require special attention.

• Interacting with other modules

• • Interactions between modules need to follow consistent rules, preferably with UTC or timestamp
  • If other modules do not follow the rules, conversion checks are required for incoming and outgoing time

Summarize:

The focus of the DST test is more about daylight saving time, the day of the winter when the processing logic, which requires us to define which time period is prone to problems, and then combined with our usual use cases, it will be easier to do the DST test.

Daylight saving Time (DST) test