BL_AKN
Regular Visitor
Joined 9 years ago
User Profile
User Widgets
Contributions
Setting CBT credentials programatically
I am running my web tests using the CrossBrowserTesting (CBT) platform. This is working fine. But I would like to specify the CBT credentials differently than via the project properties. At the moment, I set the CBT credentials in the project properties as described here: https://support.smartbear.com/testcomplete/docs/working-with/managing-projects/properties/open-apps/web-testing/crossbrowsertesting.html?sbsearch=CBT The problem is that the project's mds file will be put into our source code management system, which means that everyone could see my user name and password/authkey. Anyone could run the tests in my name, which is not what we want. It is also cumbersome to remove the info everytime before the file is being committed to SCM. My idea: Provide an alternative option to specify the CBT credentials during runtime (e.g. by reading the info from a secrets file in the test script) for example by referring to project variables.259Views0likes0CommentsProfile multiple processes
We often have the problem that we want to profile executables, which are started indirectly by another executable, for example: A.EXE is starting B.EXE and B.EXE is the process, which shall be profiled. By using AQtime, it is only possible to profile A.EXE directly. I have seen this workaround in the forum: https://support.smartbear.com/viewarticle/43332/ But this solution is not feasible for us, because modifying the registry for this purpose is very cumbersome. An easier solution would be highly appreciated.2.2KViews2likes0CommentsIcons in Modules Tree
Add a module (dll or exe) to the "Modules" tree. Select "View by... Source Files" in the ComboBox on the top. When I expand the module, I see different icons in the tree - some having an arrow pointing down, some don't have the icon. Can anybody tell me what the meaning of the two types of icons is? Thanks!3.2KViews0likes0CommentsSupport references to NameMappings of other projects
We are dealing with many different executables, which are interacting with each other in our tests. What we would like is to do is to have distinct responsible persons to maintain the NameMapping and the tests for each of the individual applications. In the "main" test project, we like to reference the "subprojects" and plug them together to obtain the integration test suite. This is working fine for script files (where you can add a reference to an "external" file, which is part of another project). But this does not work for the NameMapping file. It is only possible to have one monolithic NameMapping file in the main project. The only way at the moment is to "merge" all the NameMappings of the subprojects to the main project's NameMapping, which is error prone and cumbersome. It would be great if the NameMapping of the main project could somehow "include" or "reference" other NameMapping files from other projects, which are part of the project suite.12KViews23likes7CommentsLight Coverage Results: Merge routing results regardsless of the template parameter
The results of the "Light Coverage" profiler should merge the results of all routines with different template parameters. Let's say, you have code like the example below. When you profile the application with AQtime (Light Coverage Profiler), you will get two lines in the results output: one for the template parameter "int", and one for the template parameter "double". None of the two routines are marked fully covered, whereas the combined/merged coverage for all template parameters would be 100%. We have lots of code like in this example, and we are only interested in the total coverage of "silly_function", regardless of the used template parameter. Would it be possible to implement this "merge" feature into a future version of AQtime? Code Example ------------ #include <iostream> template <typename T> T silly_function(const T arg) { if (arg < 5) return (arg + 1); else return (arg - 1); } int main(int argc, char* argv[]) { std::cout << silly_function(4) << std::endl; std::cout << silly_function(6.0) << std::endl; } Light Coverage result: ---------------------- Routine Name % Covered main 100 silly_function<double> 66.6666666666667 silly_function<int> 66.66666666666672.2KViews3likes0CommentsIgnore unreachable code in code coverage reports
We are using the "Light Coverage Profiler" with "collect info about lines: on" for creating coverage reports of our unit tests. Let's say, you have C++ code like this: Header: __declspec(noreturn) void throw_bad_cast(); Source: __declspec(noreturn) void throw_bad_cast() { throw bad_any_cast{}; } And let's assume that the function is hit when the main program is executed. However, AQtime will mark the last line of the function "throw_bad_cast" as "not covered" (the line with the closing brace). The (invisible) return statement of the function will never be reached, so the resulting report gives the impression that the code coverage is incomplete. Thus, it would be nice if unreachable code like this would be ignored in the coverage results so that the function is marked with "coverage 100%".3.8KViews2likes1Comment