You can get the tool from here - https://visualstudiogallery.msdn.microsoft.com/45208924-e7b0-45df-8cff-165b505a38d7

In fact, unlike the previous versions, Visual Studio now supports multiple Unit Tests Frameworks apart from just MSTEST. It's got built in support for nUnit & xUnit.

You can read up more from here - https://msdn.microsoft.com/en-us/library/hh704261(v=vs.110).aspx

Cyclomatic Complexity is a formula for determining the varying logical paths that can be taken though a piece of code, thus determining a quantitative value for the code’s complexity. A higher Cyclomatic Complexity score means that there are a lot of code paths and/or factors that affect the logic with the code. One way to think about it is this: to fully unit test a method, you should have one unit test for each logic path – thus a score of 10 would result in as many unit tests. Wikipedia entry: https://en.wikipedia.org/wiki/Cyclomatic_complexity

Martin Fowler in his BLOG mentions how to approach reading the metrics and act most effectively - https://martinfowler.com/articles/useOfMetrics.html

Also, I find this as a great read too - https://www.wrightfully.com/thoughts-on-cyclomatic-complexity/

There are also some great publications on MSDN - https://msdn.microsoft.com/en-us/library/bb385914.aspx

A few MSDN BLOGS worth reading  -

1. https://blogs.msdn.com/b/codeanalysis/archive/2007/11/28/positioning-code-metrics-to-management.aspx
2. https://blogs.msdn.com/b/zainnab/archive/2011/05/17/code-metrics-cyclomatic-complexity.aspx
3. https://blogs.msdn.com/b/codeanalysis/archive/2007/10/03/new-for-visual-studio-2008-code-metrics.aspx

 With VS2013 Update 2, we added two brand new tools:CPU Usage & Memory Usage

We also enhanced the .NET memory dump analysis feature so you can now inspect values of objects from the dump file.

It’s also worth highlighting here the addition of the JSON Debugger Visualizer to Update 2.

If you see the warning you may ignore and move ahead with the install.

It's expected. The SQL Team says, they support minimum SP1 of SQL 2008 R2 and hence the warning. Once complete, apply at least SP1.

 Refer https://support.microsoft.com/kb/2681562

Couple of links I find worth keeping handy on FIDDLER & HTTP debugging:

    https://www.west-wind.com/weblog/posts/2009/Jan/14/Monitoring-HTTP-Output-with-Fiddler-in-NET-HTTP-Clients-and-WCF-Proxies

    Informative Writeup on using FIDDLER.

    The following link talks about how to get around monitoring Local traffic 

    https://fiddler2.com/documentation/Configure-Fiddler/Tasks/MonitorLocalTraffic

   There is also a registry hack that you could do. I would be posting that in due course

This BLOG from the creator himself also comes very handy https://blogs.msdn.com/b/fiddler/

Further investigation into the causes of the crash revealed -

UPDATE 1 for VS 2012 updates  the Microsoft.VisualStudio.QualityTools.WebTestFramework.dll in the GAC .

Since that version of the DLL is not compatible with VS2010, it crashes each time you want to record or replay a Webtest.

Note:

At the time of writing post, there isn't a fix available. However, MS would have a one available soon.

In one of our Performance Labs we had a requirement to collect the Performance Counter Logs across more than 15 Application & DB Servers..

Doing them manually each time was not easy and often times error prone. I got the batch Files created which had the Logman commands that triggered the remote collection and then copied them over to a shared network path. That simplified the process greatly. However, We were still running these batch files manually before and after every Load Tests. It wasn't that bad but hey if you could automate it further then why not.

I thought it might just be more convenient to have the process baked into the Load Tests itself leveraging the Load Test Extensibility Points.

Below is the Load Test Plug-in code that did the job for me.

namespace OnePlugins
{
    public class LoadTestInitCleanup : ILoadTestPlugin
    {
        LoadTest thisLoadTest;
        const string startPerfmonCmdFileLocation = @"<<pathname>>\CreateResultsDir_Start_Perfmon.CMD";
        const string endPerfmonCmdFileLocation = @"<<pathname>>\PerfMon_Stop_and_CollectResults.CMD";
        public void Initialize(LoadTest loadTest)
        {
            thisLoadTest = loadTest;
            thisLoadTest.LoadTestStarting += new EventHandler(LoadTestStarting);
            thisLoadTest.LoadTestFinished += new
                EventHandler(LoadTestFinished);
        }
        void LoadTestStarting(object sender, EventArgs e)
        {
            ProcessStartInfo procInfoCreateResultsDirectoryStartPerfmon = new ProcessStartInfo()
            {
                FileName = startPerfmonCmdFileLocation,
                RedirectStandardError = true,
                RedirectStandardOutput = true,
                UseShellExecute = false,
                CreateNoWindow = false
            };
            using (Process processResultsDirectory = new Process() { StartInfo = procInfoCreateResultsDirectoryStartPerfmon })
            {
                processResultsDirectory.Start();
                processResultsDirectory.WaitForExit();
            }
        }
        void LoadTestFinished(object sender, EventArgs e)
        {
             ProcessStartInfo procInfoStopCounterAndCollectResults = new ProcessStartInfo()
            {
                FileName = endPerfmonCmdFileLocation,
                RedirectStandardError = true,
                RedirectStandardOutput = true,
                UseShellExecute = false,
                CreateNoWindow = false
            };
             using (Process processResultsDirectory = new Process() { StartInfo = procInfoStopCounterAndCollectResults })
             {
                 processResultsDirectory.Start();
                 processResultsDirectory.WaitForExit();
             }
        }
    }
}

Hence just before starting the test we started Netmon on all the machines and saved the CAP files generated with names identifying each of the machines

High-level Objective

We have the task to validate the following:

Traffic going out from 10.52.1.106 is always going either to the 10.52.6.5 m/c or the 10.52.6.6 m/c and we should never be seeing any of the traffic to 10.52.1.104, 10.52.1.111 or 10.52.1.110.

However, the purpose of this BLOG is not to get into the details on how we investigated the pattern.
The purpose is to walk through a basic approach on how to read Netmon trace files when the reader himself is not a Network specialist himself.

I show in a few screen captures of the popular Tools like Netmon and Wireshark how you could mine the data you are looking for.

Opening the Netmon trace in WireShark
We have the Netmon trace Files captured during a Test Run. These capture files OR .CAP Files can be opened in WireShark as well. In fact, you could also use LogParser to query the .cap file and get your numbers.

The WireShark Window with the .cap file opened

From the “Statistics” drop down menu click “Conversations”

Since we are interested in only the TCP traffic, hence click the TCP Tab

All the column headers in the Display are very much self-explanatory. We were looking for traffic or packets specific to Groove hence that’s the port we needed to filter on

After quickly eye balling, we zeroed into two rows of data that had the outgoing port as 2492 and the IP as 10.52.1.106

Now we needed to validate, the sum of the outgoing bytes to both the destination IP’s - 10.52.6.5 & 10.52.6.6 was equal OR nearly equal to the total incoming bytes on these two machines.
Hence this view is makes the analysis a lot easier. Infact, you could further click the “Copy” button and paste the content to a EXCEL Spreadsheet and do the rest of your analysis from the spreadsheet.

If you unchecked the “Name Resolution” check Box you would notice the actual groove Port on which is communication is going on

Writing custom Query Filters

Writing Filters in Netmon and WireShark is fairly straightforward

For example:

We want to see all TCP traffic from 10.52.1.106 to 10.52.6.5 which were from TCP port 2492 to the destination TCP Port 2492

       ipv4.SourceAddress == 10.52.1.106 and ipv4.DestinationAddress == 10.52.6.5 and tcp.SrcPort == 2492 and tcp.DstPort== 2492

Make sure to select “All Traffic” The match will pop up in the window below

Query to do the similar thing in WireShark would be

     ip.src==10.52.1.106 and ip.dst==10.52.6.5 and tcp.srcport eq 2492 and tcp.dstport eq 2492

Logparser

Log parser is a great tool which can come very handy when you are dealing with different Log formats and you need to mine important data out of these Logs. It can read IIS Logs, Event Viewer Logs and also Netmon Capture Logs.

Find more information on Log Parser from here
https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=24659
Known issues on Windows 7
If you are trying to parse the Netmon trace File through Logparser, the SrcIP and the DstIP fields might appear to be blank. This is a known issue with Win 7. However parsing should work just fine on a XP or a Win 8 machine.

An object, in JSON terminology, is an unordered set of name/value pairs. An object begins with { (left brace) and ends with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated by , (comma).

VSTS is able to record and playback Ajax/JSON requests. However, there's no built-in support for doing things like Validating the contents of a JSON Response or extracting values if needed.

In the above XML DOM structure, the this is the JSON text.

Inside the Extract method, read the innertext property for the XML Node that contains the JSON instance, load the text to an XML Document Object, and then further using XPATH expression to reach the particular *Keys* , parse out the values for the same.

You can further learn about writing custom extraction Rules

 Approach for parameterizing.

To parameterize the UserName from the above json text

Approach to parameterize “UserName”

Create a Context parameter in the WebTest which hold the value. In this case I created a Context parameter for UserName.

Given the complexity of the WebTest and it's sheer length with all the dependant requests that it has for each of the requests I was indeed having a tough time doing a request to request match between my Webtest run and the corresponding Fiddler run. I was getting nowhere. Probably all I needed was a little more patience :-)

But anyways a small & a simple trick did all that I needed at that moment.

I could make a guess which request in my Webtest could be making the incorrect HTTP Requests that was making the tests to fail. I wanted only that selected bunch of requests to show up in FIDDLER when I ran the webtest. If I had that, then I could actually compare that request with the one that Fiddler actually captured when i manually stepped through the steps.

I wrote up a simple Pre-Request Plug-In to do this for me.