Microsoft Technology Licensing, LLC

Microsoft Corporation

Dmitri A Klementiev

Varun Jain

Michail Zervos

Dhruv Gakkhar

Dinko Papak

LeninaDevi Thangavel

Scott M Louvau

Eric I Maino

Ryan J Cavanaugh

Chetan Pentam Raghavendra

Kristopher Makey

Igor Sakhnov

Lenina Devi Thangavel

Xuechun Li

Satya Sudha Kolluru

Jason Anthony Grieves

David Michael Sauntry

Kevin T Damour

Paul James Reid

Brett Humphrey

Moshe Vainer

Peter Gregg Miller

S Neeraja Reddy

Shiva Shankar Thangadurai

Bhawandeep Singh Panesar

Howard Brian Herdeg, Iii

Richard Gregory Endean, Jr

Donald Gary Funk

Vidhya Sriram

Kateryna Boikovska

Glenn Edgar Murphy, Iii

Methods, systems, apparatuses, and computer-readable storage mediums are described for bridging brokers of messages from Internet of Things (IoT) devices. In an example system, a first message broker receives a message and an associated topic from an IoT device. A bridging coordinator accesses a topic-to-broker map that indicates, for a second broker, a list of topic filters for which the second message broker has at least one subscriber. The bridging coordinator determines whether the list of topics includes the associated topic. In response to a determination that the list of topic filters in the topic-to-broker map includes the associated topic, the bridging coordinator forward the message to the second message broker. In response to a determination that the list of topic filters does not include the associated topic, the bridging coordinator prevents forwarding of the message to the second message broker.

Efficient forwarding of messages through brokers by topic

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.

Combination of techniques to detect anomalies in multi-dimensional time series

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.

Service directory and fault injection management systems and methods

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.

Scenarios based fault injection

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.

Distributed system resiliency assessment using faults

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.

Resilience as a service

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.

Generated object model for test automation

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.

Multi-path brokered test automation execution

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.

User interface inventory

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.

Event set recording

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.

Recording/playback tools for UI-based applications

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. This exemplary embodiment further confirms that the user element interface made visible can be selected by ensuring that the window where the user interface element resides is ready for user input and is not covered by another object.

System and method for making a user interface element visible

Described is the use of query identifiers that provide computer users a method of 'bookmarking' (uniquely identifying) any user interface (UI) element in any UI framework. This is useful for testing programs, assistive technologies, and teaching activities. The unique query element identifier is identified for a target UI element to locate within a hierarchy of UI elements. For example, the element's Name, ClassName, Instance, AccessibleName, Role, ControlId and AutomationId may be used to develop the unique query element identifier. From the query elements in the hierarchy of UI elements, a query identifier is generated for the target UI element. The query identifier includes the query element identifier and possibly ancestor query element identifiers, with each ancestor query element identifier corresponding to a higher-level ancestor element relative to the target element in the hierarchy. The query identifier may be used to locate the target element for testing versions of application programs.

Growing community of inventors

Redmond, WA, United States of America

Dmitri A Klementiev