Test Studio Run-time edition does not deploy the TestAdapter.dll with its installation.
Thus Test Studio tests cannot be executed with the VSTestConsole.exe in a Azure DevOps (VSTS) pipeline.
The TestAdapter.dll for VS 2017 and VS 2019 is being deployed to the Test Studio installation folder (for Ultimate or Dev Edition installations) along with the respective *.vsix package. Until the misbehavior is fixed, the vsix package can be copied to the agent machine and installed with double click. Then refer the dll from the respective location.
Ability to record a test step and then change the Element with an existing Element. Here is the workflow: I record a step and edit the Element. Then every time I record on the same UI object, Test Studio creates a new element. Since it creates a new element, I have to manually edit every duplicate element to exactly match the first element in order for them to merge. I would like the ability to change the element the step is using to an existing element.
When you schedule and run a test list you get the following entries in the Scheduling server log: [05/06 19:32:52,Telerik.TestStudio.ExecutionManagerService.exe(4344:12),Execution] JobBroker.ScheduleJobAsync() : Job satisfied all preconditions, id = eae7a94a-c7b8-408f-9021-3a315eeb1042 [05/06 19:32:52,Telerik.TestStudio.ExecutionManagerService.exe(4344:12),Execution] JobBroker.ScheduleJobAsync() : Job sent to scheduler, id = eae7a94a-c7b8-408f-9021-3a315eeb1042 [05/06 19:32:52,Telerik.TestStudio.ExecutionManagerService.exe(4344:12),Execution] JobsController.CreateNewJob() : Accepted new job, Id = eae7a94a-c7b8-408f-9021-3a315eeb1042 [05/06 19:33:28,Telerik.TestStudio.ExecutionManagerService.exe(4344:40),Execution] JobRunner.RunJobAsync() : TestList loaded for job ID = eae7a94a-c7b8-408f-9021-3a315eeb1042 [05/06 19:33:28,Telerik.TestStudio.ExecutionManagerService.exe(4344:40),Execution] JobRunner.RunJobAsync() : Job started, ID = eae7a94a-c7b8-408f-9021-3a315eeb1042 [05/06 19:34:10,Telerik.TestStudio.ExecutionManagerService.exe(4344:12),Execution] JobRunner.<CleanupTestRunsStatus>b__12() : TestList finished; updating dispatch group header job Id = eae7a94a-c7b8-408f-9021-3a315eeb1042 [05/06 19:34:10,Telerik.TestStudio.ExecutionManagerService.exe(4344:12),Execution] JobRunner.<CleanupTestRunsStatus>b__12() : TestList finished; sending notifications [05/06 19:39:10,Telerik.TestStudio.ExecutionManagerService.exe(4344:28)] First trace message from pool unnamed thread (managed ID = 28, native ID = 12868). [05/06 19:39:10,Telerik.TestStudio.ExecutionManagerService.exe(4344:28),Execution] JobRunner.<CleanupTestRunsStatus>b__12() : TestList execution status expired- removing from list job id=eae7a94a-c7b8-408f-9021-3a315eeb1042 What's missing is which execution server the test list was sent to. This can be important information in a setup that has multiple execution servers.
The size of failure information field in the verification builder is only two rows and cannot be resized. We should copy the text somewhere outside of Test Studio in order to see it. Steps to reproduce: 1. Create a test with a verification step. 2. With an attached recorded right click on the verification step and choose Edit. 3. The Sentence Verification Builder appears and if the validation fails the information field is really small and unreadable. See the attached screen shot.
I have this idea in mind but not sure how to start with. How to add a custom option(control like a button or check box) in the UI?
From ticket 869169 In the attached screen shot is an example of an ASP.NET partial page update. It includes a URL with a dynamically changing query string. The application needs that query string echoed back in the next GET. Currently Test Studio load tests do not parse "text/plain" responses for dynamic targets. As a result this scenario is not currently supported.
Currently when a test step is set to SimulateRealClick or SimulateRealTyping, the target element is unconditionally scrolled to the top of the browser window, even in cases where the element is already visible. It would be more efficient to test if the target element is already fully visible and only scroll when needed.
Currently when Test Studio wants to scroll an element to make it visible (such as when SimulateRealClick or SimulateRealTyping is enabled) Test Studio will always, and unconditionally, scroll the element to the top. This causes problems for a few applications that have a static UI element, the target element ends up being scrolled underneath this static UI element. It would be helpful to have a global setting which controls whether the target element is scrolled to the top or the bottom of the browser window. The parameter is available in the API, just need to expose it as a step setting, or a global setting so that customers aren't forced to convert the step to code and override the default behavior, which can be time consuming when there are lots of steps that this must be done on.
I like the new user interface of test studio and its tabbing options. But I do not like the static location of the Project, Elements Explorer, Properties, and Step Builders. Provide the ability to customize the location of the listed items to other areas. For instance, in test studio, the properties windows has unused space. So I would make the window in the lower right hand side instead of the entire right side. Also in test studio, the element explorer takes up the whole left side. The step builder is closely related to the element explorer and I would like it together
Web Services has become one of the key software endpoints that demand thorough testing. While load testing for web services is already avaialble, I would like to propose making testing of web services for functional requirements also available from within Test Studio. Support for REST, SOAP and OData Services should be made available.
A lot of new apps use web services (WSDL or REST based). Test Studio should provide for API testing. Fiddler already has some great components that can be reused: 1. Composer (with header addition/modification) 2. Response Formatter (with header response etc) All that is needed is simple validation screen based on RegEx for the response.
Looking at the test results one gets an error message only, which doesn't help much in general. Instead we should provide an easy way to take the remote execution log from the execution machine to troubleshoot the actual failure.
ISSUE: Editing an existing scheduled event does not remember any of the properties set beside the email. Agents must be reselected and alert preferences must be set again (send email, attach excell, etc). REQUEST: Test Studio should retain the settings, including the execution servers.
We have an HTTP Rest API that uses some JSON/XML http requests, that are easily created and send through Fiddler or Rest Console (Chrome plugin). Then we verify the response and use it to form our next request. This process is simple and effective in our manual testing. For automation testing though we need a tool that can do those requests and also response verifications and variable usage for those HTTP requests (POST, GET, DELETE, etc.). Of course, that needs to come with a lot more functionalities (data driven testing, random generation of variables, loops, etc.) It will be great if this feature can be used side-to-side with the Web UI testing capabilities of Test Studio.
Currently after a user logs off of an execution server, its status will change to 'dead'. Such a feature would force our executable to keep running even when the user logs off.
Customer has a problem with an Element in his test; when he customises the xpath it continues to work, but when he also adds a data-driven identifier, the xpath locator becomes corrupted which has two major impacts: 1: The test run fails, because an Invalid expression exception is thrown when the test tries to find the element. 2: The Edit Element window fails to open, because an exception is thrown in BuildFindExpression. Steps to reproduce: 1: The overall plan is to define a data-driven element, which can match any of the links in a table column (see attached screenshot 1). 2: At first, use the element recorder to record a Verify Exists step with the default locator (screenshot 2). 3: Edit the element, adding an xpath locator (screenshot 3); note that this xpath does not identify a single link, but identifies all the links in the table. 4: With the edited element, run the test again; it passes. This confirms that, at this stage, the xpath is not causing any problems. 5: Edit the element a second time, this time replacing the hard-coded TextContent with a data-driven field (screenshot 4). The xpath is unchanged. 6: Run the test; this time it fails. But it doesn't fail to find the element, in the normal way; instead it throws an exception when it tries to apply the find logic (attachment 5 has the full results log with the exception callstack), based on only part of the xpath: Exception thrown while finding elements for the following descriptor 'Verify Exists 'UnassignedTable_SubmissionIDLink_datadriven''. Exception 'System.ArgumentException: Invalid expression ' 'rowUnAlloc')]/td/a' 7: Try to edit the element again; the edit window does not open, instead test studio shows a dialog with another exception (screenshot 6): at ArtOfTest.Common.Design.ProjectModel.Elements.FindExpressionElement.BuildFindExpression(String fes) at ArtOfTest.Common.Design.ProjectModel.Elements.FindExpressionElement.get_DataBoundFindExpressions() at ArtOfTest.WebAii.Design.UI.FindElementModel.BuildSentencesFromCurrentExpression() at ArtOfTest.WebAii.Design.UI.FindElementModel.set_IsDataDriven(Boolean value) When it gets to this state, the test step and the element are unusable; the only way to proceed is to delete the step, delete the element, and start again from scratch. Variations This fault does not always manifest itself in the same way. Sometimes the term 'xpath' goes missing from the identifier, also resulting in a find failure at runtime, but not preventing the element editor window from opening (screenshot 7). Sometimes the fault emerges after the first time I edit the element; sometimes only after subsequent edits, as described above. Sometimes, the introduction of the xpath identifier causes runtime identification failures, even though the overall identifier does not seem to be corrupted and the xpath should be successful. The screenshots and the sample test are attached in the internal description.
When you click "Reload from server" in the Results tab, any results from a remotely run performance test list are not automatically copied to the local machine. You have to manually copy them or configure the performance test to use a UNC path.