Abstract: A framework and a method for ad-hoc batch testing of APIs are provided, where batches of API calls are dynamically generated directly through the framework according inputs identifying the required tests and the sources of the test data, rather than through execution of prewritten test scripts that explicitly write out the test API calls in preset sequences. When performing the validation for an API test, a test payload is generated for the test, an endpoint is called using the test payload to obtain the response used for validation, where generating the test payload includes determining an API reference corresponding to the test, obtaining relevant data from the test data according to a reference key in the test, generating input assignment operations for one or more input parameters in the API reference according to the relevant data, and generating an API call based on the API reference.

Abstract: Operations may include obtaining a buggy code snippet from a question included in a post of a discussion forum, the buggy code snippet including an error and a plurality of lines of code. The operations may further include obtaining text from an answer to the question and identifying keywords from the text. In addition, the operations may include marking a particular line from the plurality of lines as being related to the error based on one or more of the keywords corresponding to one or more elements of the particular line. Moreover, the operations may include performing one or more software program repair operations based on the marking of the particular line.

Abstract: Techniques are described herein for implementing a testing and evaluation pipeline. The techniques include receiving testing specifications for validating an XR application executing on XR capable devices and mapping individual testing specifications to a corresponding XR capable device including the XR application. Upon mapping the individual testing specifications, testing configurations for an evaluation pipeline is determined. The evaluation pipeline may include one or more computing instances that execute one or more validation tests for the XR application executing on the corresponding XR capable device according to the individual testing specifications and the testing configurations. The one or more computing instances may operate in parallel to perform the one or more validation tests concurrently. Based at least on test results generated from the one or more computing instances and one or more evaluation criteria, the XR application executing on the corresponding XR capable device may be validated.

Abstract: A service testing system is disclosed to enable consistent replay of stateful requests on a service whose output depends on the service's execution state prior to the requests. In embodiments, the service implements a compute engine that executes service requests and a storage subsystem that maintains execution states during the execution of stateful requests. When a stateful request is received during testing, the storage subsystem creates an in-memory test copy of the execution state to support execution of the request, and provides the test copy to the compute engine. In embodiments, the storage subsystem will create a separate instance of execution state for each individual test run. The disclosed techniques enable mock execution states to be easily created for testing of stateful requests, in a manner that is transparent to the compute engine and does not impact production execution data maintained by the service.

Abstract: A script debugging method, a device, and a computer storage medium. The method includes: obtaining, by a device, a debugging instruction, where the debugging instruction carries a to-be-debugged target line breakpoint, and the target line breakpoint includes at least line information used to indicate a line of code in which a breakpoint location is located in a script file requested to be debugged; and displaying a debugging result when determining that a breakpoint debugging condition is met, where the debugging result includes information obtained by the debugger when the device performs breakpoint processing on the line of code corresponding to the target line breakpoint, and the breakpoint debugging condition includes at least that identification information corresponding to a target interface breakpoint is consistent with identification information corresponding to a target local variable.

Abstract: A method and system for deploying a function in a polyglot serverless elastic runtime execution environment includes receiving function code via a development environment, combining the function code with middleware layers for polyglot serverless elastic runtime execution environment to form an executable function for the polyglot serverless elastic runtime execution environment, and deploying the executable function to the polyglot serverless elastic runtime execution environment.

Abstract: In some examples, a server may retrieve and parse test results associated with testing a software package. The server may determine a weighted sum of a software feature index associated with a quality of the plurality of features, a defect index associated with the defects identified by the test cases, a test coverage index indicating a pass rate of the plurality of test cases, a release release reliability index associated with results of executing regression test cases included in the test cases, and an operational quality index associated with resources and an environment associated with the software package. The server may use a machine learning algorithm, such as a time series forecasting algorithm, to forecast a release status of the software package. The server may determine, based on the release status, whether the software package is to progress from a current phase to a next phase of a development cycle.

Abstract: An instrumentation overhead regulation technique regulates an amount of work performed by a client library of an investigative platform used to monitor, diagnose and solve errors associated with application development and production. The client library calculates processing resources utilized during its runtime activity to enable adjustment of the amount of work it performs based on the measured activity. An agent may determine the overhead activity impact to user application performance by monitoring processing resource metrics of the user application. The agent analyzes the calculated overhead and processing resource metrics to render decisions to automatically regulate the capture fidelity of the client library. Regulation of the capture fidelity may be implemented by modifying parameters of a dynamic configuration.

Abstract: Monitoring and troubleshooting tools provide the capability to visualize different levels of a client's application that is deployed as a suite of independent but cooperating services (e.g., an application that includes a monolithic application and a microservices-based application), collect values of monitored or tracked metrics at those different levels, and visualize values of the metrics at those levels. For example, metrics values can be generated for components of the monolithic application and/or for components of a microservice of the microservice-based application.

Abstract: Continuous integration pipelines can be automatically generated. For example, a system of the present disclosure can receive an event notification indicating an event involving source code for a software project being submitted to a repository. The system can determine that the event does not have a corresponding continuous-integration pipeline. In response to (i) receiving the event notification and (ii) determining that the event does not have a corresponding continuous-integration pipeline, the system can generate a continuous integration pipeline based on information included in the event notification. The system can then apply the continuous integration pipeline to the source code. After applying the continuous integration pipeline to the source code, the system may delete the continuous integration pipeline.

Abstract: A computer receives a log file, where the log file comprises records associated with the instructions in a source code. The computer loads, using a debugger, the log file and the source code. The computer receives a loading address from the log file. The computer updates a debugging data format (DWARF) with the one or more records of the log file, where the DWARF is accessed using the loading address and comprises one or more data structure entries. The computer identifies a calling address from the log file and identifies the one or more data structure entries associated with the calling address.

Abstract: Approaches presented herein enable domain knowledge-based software defect prediction. More specifically, a cost function configured to train a machine learning model to predict a defect in a software version is obtained. A domain knowledge penalty metric is then determined for a software development team associated with the software version. A linear combination of the determined domain knowledge penalty metric is then applied to the obtained cost function to create a domain knowledge-modified cost function. Using this domain knowledge-modified cost function, the machine learning model is then trained based on a minimization of the domain knowledge-modified cost function. Once trained, the machine learning model is used to report a set of predicted values based on the domain knowledge-modified cost function trained machine learning model.

Abstract: A method for predicting software failure characteristics is discussed. The method includes accessing failure data and context data related to a failed software call into a software stack. The failure data indicates software call information. The context data indicates characteristics including functionality of the failed software call. The method includes accessing cluster data on previous software failures. The cluster data includes analyzed failure data and analyzed context data on software call traces. The analyzed failure data is provided by first and second failure tools. The cluster data for software calls is generated through respective instances of the software stack for each software call trace. The method also includes correlating the failed software call trace to a particular software call trace of the cluster data. The correlating is based at least on analysis of clusters indicated by the cluster data, the failure data, and the context data.

Abstract: An application development environment providing system which provides a development environment for an application program via a network, the application development environment providing system includes a program developer configured to generate the application program on the basis of an input from a terminal connected to the development environment, and to visually display the generated application program, and a communicator configured to provide a communication function among a plurality of users who use the development environment, to copy a part or all of the application program generated by the program developer in the development environment used by a first user to be available in the development environment used by a second user, and to visually display the part or all of the application program.

Abstract: A method of performing data recovery of a first virtual machine (VM) hosted on a first hypervisor to a second hypervisor that is different from the first hypervisor is provided. The method identifies information indicating format of a first virtual disk in a backup of the first VM, and creates a second virtual disk using the information indicating format of the first virtual disk. The method also accesses information indicating configuration of the first VM and metadata of the first virtual disk, and creates a second VM hosted on the second hypervisor using the information indicating configuration of the first VM and the metadata of the first virtual disk. The method further attaches the second virtual disk to the second VM.

Abstract: Systems, computer program products, and methods are described herein for intelligent code update for a test automation engine. The present invention is configured to receive, from a test automation engine, one or more exceptions associated with one or more automated test scripts; initiate an execution one or more machine learning algorithms on the one or more exceptions; classify the one or more exceptions into one or more exception types; generate an exception handling routine based on at least classifying the one or more exceptions into the one or more exception types; initiate an execution of the exception handling routine on the automated test script, wherein the exception handling routine comprises computer instructions for updating a source code of the one or more automated test scripts; and initiate an execution of the one or more updated automated test scripts on the test automation engine.

Abstract: Various embodiments discussed herein enable unique identifiers or hash values to be generated that uniquely identify performance issues and associated call stack units, which may be attributed to a user or team of users. A performance issue for a currently running process can be detected. A particular location within a call stack of the process indicating where the performance issue was detected can be determined. A quantity of call stack frames within the particular location that account for a threshold proportion of the performance issue can be determined. A hash value that uniquely identifies the performance issued can be generated based at least in part on the particular location and the quantity of call stack frames within the particular location that account for the threshold proportion of the performance issue.

Abstract: Expressly turning tracing on and off at each juncture between code that a developer wants to have traced and other code may reduce trace file size but adds computational cost. Described technologies support selectively tracing a process's execution, with some extra tracing done beyond the code the developer wanted traced, but with significantly reduced computational cost, by reducing the number of trace enablement and disablement operations. A trace controller uses a tracing disablement distance variable whose values indicate the computational distance from trace disablement. A distance variable modifier automatically moves the distance variable closer to a stop-tracing value as the process executes. The amount of extra tracing is balanced against the reduction in trace enablement/disablement operations by tuning thresholds, based on information about routine size and computational cost.

Abstract: Computer systems and methods for: (1) analyzing electronic correspondence associated with a data subject (e.g., the emails within one or more email in-boxes associated with the data subject); (2) based on the analysis, identifying at least one entity that that the data subject does not actively do business with (e.g., as evidenced by the fact that the data subject no longer opens emails from the entity, and/or has set up a rule to automatically delete emails received from the entity); and (3) in response to identifying the entity as an entity that the data subject no longer does business with, at least substantially automatically populating and/or submitting a data subject access request to the entity (e.g., to delete all personal information being processed by the entity).

Abstract: A method includes generating first metric data by executing a test suite on a first version of a software model; generating second metric data by executing the test suite on a second version of the software model; generating first and second version principal components that represent the first and second metric data by executing a dimension reduction technique on the first and second metric data; determining at least one control limit based on at least one of the first version principal components; determining a mean value of one of the second version principal components; determining whether the second version of the software model performs within at least one control limit by comparing the mean value to the at least one control limit; and notifying a user of the results of the determining whether the second version of the software model performs within the at least one control limit.