Abstract: Methods, systems, apparatuses, and computer program products are described herein that enable detecting anomalies in time series. An anomaly detection technique is selected from a plurality of detection techniques, and is applied to a first time-series data set (having a first set of dimensions). In response to detecting an anomaly in the time-series data set, the anomaly detection technique is applied to a second time-series data set that is a subset of the first time-series data set. The first time-series data set includes the first set of dimensions plus one or more additional dimensions.

Abstract: A system includes: at least one processor running instances of two or more services. Instances of a first service are dependent upon instances of a second service. A fault-injection manager, based on data in a service directory indicative of dependencies of services of the system, determines a fault-inducing condition to inject into the system and injects the fault-inducing condition into the system. A health monitoring manager detects failures in the system and identifies the first service as vulnerable to the fault-inducing condition when the fault-inducing condition causes an instance of the second service to fail.

Abstract: A system determines a topology of a distributed system and determines, based on the topology, one or more injection points in the distributed system to inject failure scenarios. Each failure scenario including one or more faults and parameters for each of the faults. The system prioritizes the failure scenarios and injects a failure scenario from the prioritized failure scenarios into the distributed system via the one or more injection points. The system determines whether the injected failure scenario causes a response of the distributed system to fall below a predetermined level. The system determines resiliency of the distributed system to one or more faults in the injected failure scenario based on whether the injected failure scenario causes the response of the distributed system to fall below the predetermined level.

Abstract: A method and system for assessing resiliency of a system is provided. A fault injection system may, for each of a plurality of dimensions of a fault profile, access an indication of possible values for the dimension, which may be specified by a user. The fault injection system may, for each of a plurality of fault profiles, automatically create the fault profile by, for each of the plurality of dimensions, selecting by the computing system a possible value for that dimension. For at least some of the fault profiles, the fault injection system injects a fault based on the fault profile into the system and determines whether a failure was detected while the fault was injected.

Abstract: Methods, systems, apparatuses, and computer program products are described herein that enable detecting anomalies in time series. An anomaly detection technique is selected from a plurality of detection techniques, and is applied to a first time-series data set (having a first set of dimensions). In response to detecting an anomaly in the time-series data set, the anomaly detection technique is applied to a second time-series data set that is a subset of the first time-series data set. The first time-series data set includes the first set of dimensions plus one or more additional dimensions.

Abstract: A system determines a topology of a distributed system and determines, based on the topology, one or more injection points in the distributed system to inject failure scenarios. Each failure scenario including one or more faults and parameters for each of the faults. The system prioritizes the failure scenarios and injects a failure scenario from the prioritized failure scenarios into the distributed system via the one or more injection points. The system determines whether the injected failure scenario causes a response of the distributed system to fall below a predetermined level. The system determines resiliency of the distributed system to one or more faults in the injected failure scenario based on whether the injected failure scenario causes the response of the distributed system to fall below the predetermined level.

Abstract: A method and system for assessing resiliency of a system is provided. A fault injection system may, for each of a plurality of dimensions of a fault profile, access an indication of possible values for the dimension, which may be specified by a user. The fault injection system may, for each of a plurality of fault profiles, automatically create the fault profile by, for each of the plurality of dimensions, selecting by the computing system a possible value for that dimension. For at least some of the fault profiles, the fault injection system injects a fault based on the fault profile into the system and determines whether a failure was detected while the fault was injected.

Abstract: A system includes: at least one processor running instances of two or more services. Instances of a first service are dependent upon instances of a second service. A fault-injection manager, based on data in a service directory indicative of dependencies of services of the system, determines a fault-inducing condition to inject into the system and injects the fault-inducing condition into the system. A health monitoring manager detects failures in the system and identifies the first service as vulnerable to the fault-inducing condition when the fault-inducing condition causes an instance of the second service to fail.

Abstract: Systems and methods disclosed herein are directed to creating a service directory of dependencies for services running on a system, wherein instances of a first service are dependent upon instances of a second service. The directory of dependencies comprises metadata associated with connections between the services. The system injects faults targeting all levels of the dependencies. The system is monitored to detect failures created by the faults. The injected faults are selected from transport layer faults, memory pressure, processor pressure, storage pressure, virtual machine restart, and virtual machine shut down. A domain name service is monitored to identify names that are resolved for the services. The service directory is then updated continuously with additional dependencies using information about the resolved names. The faults may be injected in a guided manner, wherein the scope of the faults is increased in steps over time to identify a failure point in the system.

Abstract: Systems and methods disclosed herein are directed to creating a service directory of dependencies for services running on a system, wherein instances of a first service are dependent upon instances of a second service. The directory of dependencies comprises metadata associated with connections between the services. The system injects faults targeting all levels of the dependencies. The system is monitored to detect failures created by the faults. The injected faults are selected from transport layer faults, memory pressure, processor pressure, storage pressure, virtual machine restart, and virtual machine shut down. A domain name service is monitored to identify names that are resolved for the services. The service directory is then updated continuously with additional dependencies using information about the resolved names. The faults may be injected in a guided manner, wherein the scope of the faults is increased in steps over time to identify a failure point in the system.

Abstract: A generated object model engine abstracts actions, used in test cases, in a manner to produce new object model types that are independent of an underlying code implementation. The generated object model engine analyzes action classes to aggregate a set of actions having similarly-related class types. Action classes having similarly-related class types are then used to form a new object model type. The new object model type may be used in a test case to hide the action's code implementation from the test case.

Abstract: A test case can be run with actions from the test case being executed in multiple execution paths. This can be done with the aid of an action broker. For example, the broker may identify available automation implementations for the actions and use a priority list to select between available automation implementations for executing an action from the test case. The broker may also perform conversions of results of actions for use by implementations executing other actions in different execution paths, as well as passing results between implementations in different execution paths.

Abstract: User interface elements are identified and cataloged into a user interface inventory database keyed on a global user interface element identifier. Information is collected for user interface elements activated in an executing application or applications. Scenario information is collected and is used to update the user interface inventory database. Scenario information includes information concerning user interface element usage, state changes, etc. in time. The described information can be collected over a period of time and from a number of different computer systems. The information can be analyzed to determine and quantify usage and testing of user interface elements. The analyzed information can be used to determine how thoroughly a user interface element has been tested, how often the user interface element works as expected, most commonly used user interface elements and other information. The collected information can be used to track, quantify and identify ownership of user interface elements.

Abstract: A generated object model engine abstracts actions, used in test cases, in a manner to produce new object model types that are independent of an underlying code implementation. The generated object model engine analyzes action classes to aggregate a set of actions having similarly-related class types. Action classes having similarly-related class types are then used to form a new object model type. The new object model type may be used in a test case to hide the action's code implementation from the test case.

Abstract: Recording of functional steps resulting from actions in an application is desirable for performing functional testing or user interface automation of an application. However, certain events that may result from actions occurring in an application are often difficult to record, which may lead to playback failure. Further, a user's intent when performing an action is difficult to determine. In order to obtain effective playback, a reliable and efficient recording of an application's functional steps needs to occur. Injecting wrapper functions into an application and monitoring an event generator's state before and after an action has occurred may yield more reliable and effective results.

Abstract: A test case can be run with actions from the test case being executed in multiple execution paths. This can be done with the aid of an action broker. For example, the broker may identify available automation implementations for the actions and use a priority list to select between available automation implementations for executing an action from the test case. The broker may also perform conversions of results of actions for use by implementations executing other actions in different execution paths, as well as passing results between implementations in different execution paths.

Abstract: User interface elements are identified and cataloged into a user interface inventory database keyed on a global user interface element identifier. Information is collected for user interface elements activated in an executing application or applications. Scenario information is collected and is used to update the user interface inventory database. Scenario information includes information concerning user interface element usage, state changes, etc. in time. The described information can be collected over a period of time and from a number of different computer systems. The information can be analyzed to determine and quantify usage and testing of user interface elements. The analyzed information can be used to determine how thoroughly a user interface element has been tested, how often the user interface element works as expected, most commonly used user interface elements and other information. The collected information can be used to track, quantify and identify ownership of user interface elements.

Abstract: Techniques and tools are described for recording input from user actions in a user interface (UI) and replicating the UI activity on a computing device. When recording and replicating UI activity, these techniques and tools improve the readability of the recorded input data and the reliability of playback. The techniques and tools may be used in combination or separately. For example, a recording tool uses a set of filters, which aggregates recorded data into basic, readable primitive methods. The recording tool converts the aggregated data into playback code by converting the playback primitive methods into corresponding computer language instructions. A playback tool may then replicate the initial recorded UI activity by playing back the computer language instructions.

Abstract: Recording of functional steps resulting from actions in an application is desirable for performing functional testing or user interface automation of an application. However, certain events that may result from actions occurring in an application are often difficult to record, which may lead to playback failure. Further, a user's intent when performing an action is difficult to determine. In order to obtain effective playback, a reliable and efficient recording of an application's functional steps needs to occur. Injecting wrapper functions into an application and monitoring an event generator's state before and after an action has occurred may yield more reliable and effective results.

Abstract: Various new and non-obvious apparatus and methods for ensuring a user interface element is visible within an automated user interface test environment are disclosed. One of the disclosed embodiments is a method for locating a parent element of the user interface element and then making the user interface object visible using top-down scrolling, bottom-up scrolling, expanding, or a combination of all three. Top-down scrolling scrolls the parent element until the user interface element becomes visible. Bottom-up scrolling first locates a grandparent element. The parent element then scrolls until the user interface element is within the parent object. The grandparent element is then scrolled until the parent element is visible within the grandparent element, the parent object is then scrolled until the user interface element is visible within the grandparent element.