[Dev Tip] Coded UI test on MTM

image10-33

Did you know you can manage and run CodedUI tests without Visual Studio? In an interview I recently did with .Net Rocks, one topic that came up was how to manage and run CodedUI tests on demand or as part of a nightly test run without using Visual Studio. You can accomplish this using Microsoft Test Manager.

ALM Test Infrastructure

One of the things that isn’t well known about the Microsoft ALM Test Infrastructure, which is part of the Visual Studio ALM tool suite, is the ability to manage your automated tests using the Microsoft Test Manager (MTM). With MTM you can manage your regression suites and run the regression suites straight from the tool. To give you some insight on how this is done, let’s walk through the steps involved to set this up.

First let’s assume you’ve built a larger set of CodedUI tests that exercise your application. Since the test set has become quite large, running all of the tests might take several hours to complete. How can you run the tests required to validate a change without running all of the tests every time? With MTM you have the ability to build a “test plan.” A test plan contains a set of test suites that can be static suites (you pick the tests that are part of the suite), requirement-based suites (you select the requirement that links to the test cases), or query-based suites (you created queries to select the tests that are part of the suite). With query-based suites you can build up suites that target a specific area of your application.

Here’s a scenario I like to use to explain how things play out. Imagine we work at an insurance company that has a web-based application it bought from a vendor. It contains different insurance products and business processes which are managed with the product. Let’s say it has policies for personal liability, car insurance and home insurance. It has different processes such as policy affirmation, claim settlement and adding a policy holder. Now let’s assume the vendor made a change to the claim settlement process. In this case you would like to run a regression set across all products for that particular process to check if something is broken.

Setting up the MTM test cases that relate to the CodedUI tests

Our goal is to create test suites which are tied to the CodedUI tests, and use these sub-selections of tests to complete a test run that validates a specific change made to the system. For this to work there are a couple of things you need to get in place:

  1. You need to have a way to differentiate the tests from each other based on the focus areas you have in your application.
  2. You need to import all the automated tests as MTM test cases so you can manage and run them from MTM.

So let’s look at step one first. You need to name your tests in such a way that you can build regression suites for specific purposes. How can we make this work? Write your CodedUI tests using the page object pattern so you have a good maintainable set of UI tests (you can find more info on this pattern in my course on CodedUI and on my blog here).

Next you need to import those tests into MTM so you can then build out the regression sets.

When you build the test scenarios based on the page objects, you need to ensure you can query on the tests in such a way that you can group tests together based on process or product type. So you need a naming convention. In this particular case it would make sense to say that you have a naming convention where you name the tests as follows:<ProcessName>_<ProductName>_TestScenario. So this would result in names like: PolicyAffirmation_CarInsurance_PersonAgeAbove60and PolicyAffirmation_CarInsurance_PersonAgeBelow20.

This way you can immediately tell which scenario the tests are validating, and at a later stage, build test suites that group tests based on parts of the name.

Once we have written the tests, the next step is to import the tests in MTM. You can do this manually by creating the test cases in MTM, then going over to Visual Studio to link them to the actual CodedUI test, but it’s a very cumbersome process. Luckily there’s an alternative! You can import the tests based on the assembly that is built, then generate the test cases in MTM. For this you need to use the tool called TCM.exe, which is part of the standard Visual Studio installation.

Let’s assume the assembly that contains the CodedUI tests is calledInsuranceRegressionTests.dll. In order to import the tests in Microsoft Test Manager, or better stated, in Team Foundation Server so they show up in Microsoft Test Manager, you need to run the following command line:

>tcm.exe testcase /import /collection:<your TFS Server collection name>  /teamproject:<your team project>  /storage: InsuranceRegressionTests.dll

Optionally, you can filter the test cases that are imported by specifying the /category option, and that will match only tests that have the category attribute specified on top of the test methods or class.

After running this command, you can now run a query in MTM and look at the test cases that were imported. This will look something like shown in the screenshot below:

Structuring your tests

So now that we’ve imported all of our tests into MTM, let’s structure the test now in such a way that we can select a group of tests to validate either a process or product. To do this you first need to create a new test plan:

Now we have a clean new plan that we can start organizing. Add two static test suites at the top level of the plan that dissect the groups created in process and product as shown here below:

The next step is to fill up the process suite with additional query-based suites. Here we are defining the set of tests based on the name in the test containing either the name of the process we need or the product we need. To define a suite that shows all test cases that test the process “Policy Affirmation” we create a query that looks at the title of the test and requires the text “PolicyAffirmation” to be in the title as show below:

And we can do the same for particular products as show below for product, car insurance:

After we have done this for all processes and products, the full regression suite looks like this:

Setting up the Lab Management machines

Now that we have the test plan complete and created nice buckets that focus on specific processes or products, we can now run the tests from MTM. This requires one additional step and that is to set up a lab environment. A lab environment contains the machines that will function as the web client machine running the actual tests. To create the environment, select the “Lab Canagement” tab in MTM.

Now that you’ve created a new environment, select a test machine you have available in your network. In my case the name of the test machine is “TestClient.”

Running your tests from MTM

Now that we have a lab machine available, we can run the tests from MTM. To do this go to the “Test” tab and there you can select the option to run the test.

Now you will get the dialog asking where you would like to run the tests.

This is where you need specify the build the tests are part of (the build containing the CodedUI tests) and the test environment you want to use. In this case, it’s the VSALM test environment we just created. The final thing to note is that the test setting specifies what the diagnostic data collectors will capture during the test run. This is where you can specify to use test settings that contain Intellitrace log capture, video capture and even audio capture on the target machine.

After you start a run, you will get a results view that shows the progress:

And when the run is finished you’ll get a summary of the run and a overall status report on the test plan.

Running the regression suites as part of the daily build process

One thing haven’t mentioned yet is the fact that we can use the existing test plan we created together with a lab management build. This is a build defined in Visual Studio where we can specify the lab environment we want to use (VSALM), the test plane we want to execute, and the build we will use that contains the test assemblies. You can schedule this build to run every night on the latest build of the CodedUI tests, and this way each morning when you get into the office you’ll already see a full summary like one shown above, based on a fully automated regression test that is scheduled and executed.

So with these steps you can manage your CodedUI tests from Microsoft Test Manager. You can create nice functional buckets of test suites by using the query based suites, can run your tests on existing machines just by adding them to the lab environment, and any functional tester can run the regression suites without ever knowing about Visual Studio.

###################################################################################

A coded UI test provides a mechanism to automatically execute and drive the application in much the same manner as a human sitting in front of a computer. It operates at the user interface layer and can be programmed to validate elements of the UI at various points during the test to confirm that the application is behaving properly.

Coded UI tests can be authored in C# or Visual Basic, and Visual Studio 2012 provides tools to help auto-generate much of this required code.

We will start by creating a simple Coded UI Test using the Coded UI Test Builder and adding some validation logic.

 

Setting Up the Sample Application

We will use a simple web application having one web form.
Create a test project

We will need a test project in which to house Coded UI test. Click File -> New -> Project, which will display the New Project dialog box. Select Visual C# -> Test -> Coded UI Test Project. Name the project “CodedUITestProject” and select “Add to solution” in the Solution drop-down. Click OK.
“Generate Code for Coded UI Test” will appear, providing options for generating test.

Choose the first option “Record actions, edit UI map or add assertions”. This option allows recording a Coded UI test from scratch by navigating through the application in the same manner that a user might.

The moment you choose above mentioned option Coded UI Test Builder appears.

Assuming you have launched the web form (calculate.aspx) in browser. Click the record button of the Test Builder. You can now begin recording the Coded UI test by using the application in same manner you would expect a user to. Type 20 in first textbox, then type 30 in second textbox, and click the Add button.

 

You can visually inspect the actions that the Test Builder has captured by clicking on Show recorded steps of the Test Builder.

At this point of time, validation logic can be added to confirm that the result of addition operation is correct. Before adding assertion, performed steps must be converted into source code. Do so by clicking on Generate Code.

A dialog will appear prompting you to name the method you want to create within coded UI test. Type “EnterDataAndClickAdd”; then click Add and Generate to resume building coded UI test.

You can now add assertion logic to validate the properties of one or more controls. The Test Builder allows you to easily select the control you want to validate. Do so by clicking the Add Assert and dragging the crosshair icon from the Test Builder on to the bottommost label next to Result of the form. As you hover over controls, you will notice that they become highlighted to indicate which control you are selecting. Once you have selected the bottommost label of the form, release your mouse button.

The properties for the lblResult label will be displayed.

For this test, we want to confirm that the number 50 (the sum of 20 and 30) is properly displayed in the textbox. In the list of properties for this control, you will see that the InnerText property has a value of 50. Highlight this row, then click Add an Assertion. “Add assertion” dialog will appear, allowing you to define the behavior of your assertion. Click the Comparator drop – down to examine your assertion choices. Accept the default value (AreEqual) for Comparator and the current value (50) for Comparison Value. You can also type message in case assertion fails .Click OK. The Test Builder will display a message indicating that your assertion has been added.

Click Generate Code from within the Test Builder to codify the assertion just added. A dialog will appear to name the method the will correspond to you assertion. Name the method “AddAssert” and click Add and Generate. The Test Builder now converts the assertion you defined into C# and insert this into test project.

Once you are finished, close the Test Builder, which will return you to Visual Studio.

Generated Code

In Solution Explorer, Open CodedUITest1.cs.

This is the main execution harness for the test, and calls all of the action and assertion methods you have defined earlier, as shown here:

[TestMethod]

public void CodedUITestMethod1()

{

  1. this.UIMap.EnterDataAndClickAdd();
  2. this.UIMap.AddAssert();

}

To better understand what each method is actually doing, you can examine the partial class file name UIMap.Desginer.cs. Right click on the EnterDataAndClickAdd method call and select “Go to definition”.

public void EnterDataAndClickAdd()

{

#region Variable Declarations

HtmlEdit uITxtFNoEdit = this.UIHttplocalhost52996CaWindow.UIHttplocalhost52996CaDocument.UITxtFNoEdit;

HtmlEdit uITxtSNoEdit = this.UIHttplocalhost52996CaWindow.UIHttplocalhost52996CaDocument.UITxtSNoEdit;

HtmlInputButton uIAddButton = this.UIHttplocalhost52996CaWindow.UIHttplocalhost52996CaDocument.UIAddButton;

#endregion

// Type ’20’ in ‘txtFNo’ text box

uITxtFNoEdit.Text = this.EnterDataAndClickAddParams.UITxtFNoEditText;

// Type ’30’ in ‘txtSNo’ text box

uITxtSNoEdit.Text = this.EnterDataAndClickAddParams.UITxtSNoEditText;

// Click ‘Add’ button

  1.            Mouse.Click(uIAddButton, new Point(40, 13));

}

This method is responsible for various actions, as defined by the action recorded earlier. It will put values in two textboxes and then click on Add.

Running Test

Launch the form in browser. Open Test Explorer by clicking TEST menu -> Windows -> Test Explorer. You need to build the solution to load all the tests in Test Explorer. Right click on CodedUITestMethod1 and select Run Selected Test.
Avoid using your mouse or keyboard while the text executes. If you have recorded test properly, the values 20 and 30 will be inserted into the textboxes, and Add button will be clicked. When finished, the test results will be displayed as shown

Creating Data-Driven Coded UI Test

Coded UI Test can be data-driven. So that it can be run multiple times with different data sources. Instead of having to implement a number of different tests permutations, we can instead bind the test to a data source and access the current data row for the test.

The different data sources are: CSV, Excel, Test Case, XML and SQL Express.

We will use XML as data source to make the Coded UI Test we created earlier; data-driven. Add an XML file to CodedUITestProject by the name “CalcData.xml” and put following xml in it.

 

xml version=”1.0″ encoding=”utf-8″ ?>

<DataContextData>

<DataContextRow>

<InputValue1>11</InputValue1>

<InputValue2>22</InputValue2>

<ExpectedAddAnswer>33</ExpectedAddAnswer>

</DataContextRow>

<DataContextRow>

<InputValue1>12</InputValue1>

<InputValue2>11</InputValue2>

<ExpectedAddAnswer>23</ExpectedAddAnswer>

</DataContextRow>

</DataContextData>

 

Now open the “CodedUITest1.cs” and add DataSource attribute to CodedUITestMethod1 and modify the code as shown below.

 

[TestMethod]

[DataSource(“Microsoft.VisualStudio.TestTools.DataSource.XML”, “|DataDirectory|\\CalcData.xml”, “DataContextRow”, DataAccessMethod.Sequential)]

public void CodedUITestMethod1()

{

  1. this.UIMap.EnterDataAndClickAddParams.UITxtFNoEditText = TestContext.DataRow[“InputValue1”].ToString();
  2. this.UIMap.EnterDataAndClickAddParams.UITxtSNoEditText = TestContext.DataRow[“InputValue2”].ToString();
  3. this.UIMap.EnterDataAndClickAdd();
  1. this.UIMap.AddAssertExpectedValues.UIItem50PaneInnerText = TestContext.DataRow[“ExpectedAddAnswer”].ToString();
  2. this.UIMap.AddAssert();

}

 

We use TextContext.DataRow to fetch row from the datasource. So this method will run for each row in datasource; putting the values of columns in respective controls along the way.

Now, launch the form in browser and run the test from Test Explorer. If no assertion fails, it should pass for all datarows.

Note: If you encounter error “The unit test adapter failed to connect to the data source or to read the data” during test run; Right click on “CalcData.xml” in Solution Explorer and select Properties and in Copy to Output Directory, choose either Copy always or Copy if newer.

Make some changes to XML file to make the test fail.

 

xml version=”1.0″ encoding=”utf-8″ ?>

<DataContextData>

<DataContextRow>

<InputValue1>11</InputValue1>

<InputValue2>22</InputValue2>

<ExpectedAddAnswer>33</ExpectedAddAnswer>

</DataContextRow>

<DataContextRow>

<InputValue1>12</InputValue1>

<InputValue2>11</InputValue2>

<ExpectedAddAnswer>33</ExpectedAddAnswer>

</DataContextRow>

</DataContextData>

 

Notice we have changed expected value for second row to 33, which is wrong (12 + 11 = 23). Now run the test again.
You can notice the test passed for first row but failed for second row.

Apart from recorded asserts, you can also add assertion logic by writing custom code. Now we will add some code to check that FirstTextbox should not be blank. Open UIMap.cs and add following code.

 

public partial class UIMap

{

public void AssertIfFNoIsBlank()

{

HtmlEdit uITxtFNoEdit = this.UIHttplocalhost52996CaWindow.UIHttplocalhost52996CaDocument.UITxtFNoEdit;

  1. Assert.AreNotEqual(string.Empty, uITxtFNoEdit.Text.Trim(), “First Number cannot be blank.”);

}

}

 

Now add a call to AssertIfFNoIsBlank to CodedUITest1.cs.

 

public void CodedUITestMethod1()

{

  1. this.UIMap.EnterDataAndClickAddParams.UITxtFNoEditText = TestContext.DataRow[“InputValue1”].ToString();
  2. this.UIMap.EnterDataAndClickAddParams.UITxtSNoEditText = TestContext.DataRow[“InputValue2”].ToString();
  3. this.UIMap.EnterDataAndClickAdd();
  1. this.UIMap.AssertIfFNoIsBlank();
  1. this.UIMap.AddAssertExpectedValues.UIItem50PaneInnerText = TestContext.DataRow[“ExpectedAddAnswer”].ToString();
  2. this.UIMap.AddAssert();

}
Again modify the xml file so that first textbox remain blank; to make this test fail.

xml version=”1.0″ encoding=”utf-8″ ?>

<DataContextData>

<DataContextRow>

<InputValue1></InputValue1>

<InputValue2>22</InputValue2>

<ExpectedAddAnswer>33</ExpectedAddAnswer>

</DataContextRow>

<DataContextRow>

<InputValue1>12</InputValue1>

<InputValue2>11</InputValue2>

<ExpectedAddAnswer>23</ExpectedAddAnswer>

</DataContextRow>

</DataContextData>

 

Run the test again.
You can verify the test passed for second row but it failed for first row because we modified the xml for the first value to be blank. Similarly more custom assertion logic can be added to verify the UI elements.

You can now maintain the CalcData.xml file within test project to add new rows of data. Those rows can be used for future test runs.

 

[Discovery] Tìm hiểu về bộ vi xử lý của máy tính

CPU được coi như trái tim của một bộ máy tính. Do đó nó luôn là sản phẩm được cân nhắc nhiều nhất mỗi khi lựa chọn build một bộ máy tính mới. Vậy liệu bạn đã hiểu nhiều về CPU, cũng như những câu chuyện của nó chưa? Hãy cùng khám phá nhé.

Macintosh HD:Users:Ethan:Downloads:amd-intel-processors_678x452.jpg

Giới thiệu sơ lược về CPU và các thuật ngữ

Một dàn máy tính hiện đại có chứa rất nhiều thành phần: CPU/APU, bo mạch chủ, bộ nhớ, GPU, Ổ cứng, Case và nguồn điện. Trong đó thì CPU chính là trung tâm xử lí của máy tính, và cũng là thứ được chú ý nhất trên trong một case máy tính. Mục tiêu của bài viết này sẽ là cung cấp cho người đọc một góc nhìn tổng quan nhất về hiệu năng xử lí của một CPU/APU.

Với mỗi bo mạch chủ, bạn sẽ phải chọn một CPU thích hợp tương ứng (theo socket). Tuy vậy điều mà chúng ta bàn đến hôm nay là hiệu năng xử lí của nó. 2 nhà sản xuất CPU/APU lớn nhất thế giới hiện nay: AMDIntel đều có các tiêu chuẩn riêng đối với sản phẩm của mình. Trong khi phía AMD sở hữu nền tảng FM2 và FM2+ dành cho các APU của mình và nền tảng AM3+ sử dụng cho các CPU thì Intel sử dụng nền tảng socket LGA1150 và LGA2011- thứ sẽ đem lại hiệu suất xử lí cao hơn với một số công nghệ được lấy từ công nghệ của máy trạm của Intel.

Và trước khi chúng ta đi sâu vào phân tích hãy cùng dành một chút thời gian để tìm hiểu qua về các từ viết tắt cũng như các khái niệm. Đầu tiên là CPU -Central Processing Unit, có thể hiểu là thứ thực hiện hầu hết các xử lí tính toán bên trong các cỗ máy tính hiện đại. Trong khi đó APU- Accelerated Processing Unit là một thuật ngữ của AMD dùng để chỉ về bộ xử lí CPU có kết hợp cả GPU(Graphics Processing Unit), trong đó GPU sẽ chia sẻ một phần nhiệm vụ xử lí tính toán từ CPU. Các APU của AMD ngày nay đều đạt khả năng xử lí ít nhất ở DirectX 11, trong khi phía Intel đặt chuẩn xử lí GPU DX11(còn được gọi là bộ vi xử lí đồ hoạ) dành cho các sản phẩm của họ. Và nhìn chung thì, các APU của AMD thường có khả năng xử lí đồ hoạ tốt hơn so với đối thủ của mình.

Macintosh HD:Users:Ethan:Downloads:Haswell-Die-Labeled_575px.jpg

Cấu trúc của vi xử lý Intel’s Haswell GT2

Đó là những kiến thức tổng quan về CPU/APU. Giờ đây chúng ta sẽ đi vào tìm hiểu sâu hơn hiệu năng của chúng qua các con số. Ngày nay thì các bộ vi xử lý không chỉ được sử dụng cho máy tính, mà chúng còn được áp dụng trong rất nhiều ngành công nghiệp khác (Ô tô chẳng hạn). Cho nên sẽ rất khó để đưa ra một sự đánh giá chung hay so sánh đối với các dòng sản phẩm khác nhau sử dụng các bộ vi xử lý này( quá nhiều yếu tố đánh giá khác biệt như: Hiệu năng xử lí, khả năng quản lý năng lượng, ….). Nhưng trong nội dung bài viết chúng ta sẽ chỉ tham khảo các số liệu đến từ các CPU/APU dành cho máy tính.

Ở phía dưới, chúng ta sẽ có 2 bảng so sánh các sản phẩm CPU/APU về hiệu suất xử lí hệ thống và hiệu suất xử lí đồ hoạ. Với Intel, đó là các sản phẩm bộ xử lý Celeron, Pentium, Core i3, Core i5 và Core i7. Với AMD, đó sẽ là các APU A4, A6, A8, và A10, cùng với dòng CPU FX-series của họ (không tích hợp xử lí đồ hoạ). Nếu muốn tìm hiểu sâu hơn về thông số của các sản phẩm cụ thể, bạn có thể ghé qua trang chủ của họ để xem xét kỹ hơn.

Macintosh HD:Users:Ethan:Downloads:66078.png
Macintosh HD:Users:Ethan:Downloads:66079.png

So sánh giữa các bộ vi xử lý và hiệu suất xử lý hệ thống/đồ hoạ của chúng

2 bảng này là kết quả benchmarks từ CPU Bench. Cũng cần phải lưu ý là không phải các bộ vi xử lí này đều đã được Benchmarks theo tất cả các tiêu chuẩn, mà chúng được kiểm tra và chuẩn hoá dựa trên thông số của sản phẩm Core i3-4330(sản phẩm cho kết quả 1000 ở cả 2 bảng so sánh). Lý do là bởi sản phẩm này sẽ đảm bảo khả năng xử lí hệ thống cũng như đồ hoạ ở mức cân bằng nhất, từ đó dễ dàng phân biệt các sản phẩm top trên và dưới của bảng so sánh. Sẽ có rất nhiều thông số được đánh giá trong một bài kiểm tra, và nếu bạn muốn biết sâu hơn thì có thể tìm hiểu qua CPU Bench. Các tiêu chuẩn được sử dụng để so sánh bao gồm khả năng xử lý đơn luồng/đa luồng, các bài kiểm tra hệ thống sử dụng bộ nhớ, các bài kiểm tra đồ hoạ trên 5 trò chơi để tính toán khả năng xử lí của GPU. Và hãy nhìn qua bảng so sánh, chúng ta sẽ thấy Chip Intel vượt trội hơn nhiều về khả năng xử lí hệ thống, trong khi các sản phẩm APU của AMD chiếm nguyên nửa trên của bảng so sánh khả năng xử lí đồ hoạ. Và chúng ta cũng có thể nhận ra các sản phẩm “đầu đàn” của các hãng như Intel Core i7 4790K của Intel hay AMD A10 7850K.

Đi sâu hơn một chút, ở bảng so sánh về hiệu suất xử lí hệ thống, sức mạnh xử lí của Intel tỏ ra đè bẹp đối thủ khi ngoại trừ 2 bộ vi xử lý dòng FX-series (không tích hợp xử lí đồ hoạ) ra thì sản phẩm tốt nhất trong dòng APU của AMD cũng chỉ bằng một nửa so với sản phẩm dẫn đầu của Intel là Core i7 4790K. Đồng thời các dòng sản phẩm i5 trở lên của Intel luôn đạt hiệu năng vượt trội so với các sản phẩm của AMD. Trong khi đó ở bảng so sánh về khả năng xử lí đồ hoạ, các sản phẩm APU lại “đảo chiều” một cách ngoạn mục khi không một sản phẩm nào của AMD đem ra so sánh cho hiệu năng xử lí đồ hoạ kém hơn các CPU của Intel. Điều này cũng dễ hiểu bởi triết lí sản xuất bộ vi xử lý của các 2 nàh sản xuất đã khác nhau từ đầu. Tất nhiên những dòng sản phẩm ở dưới bảng so sánh (yếu hơn so với sản phẩm lấy mốc là Intel Core i3-4330) vẫn đảm bảo được khả năng đáp ứng nhu cầu sử dụng cơ bản của người dùng trong việc lướt web, xem phim, chơi game. Và hầu hết người dùng phổ thông hiếm khi sử dụng tối ưu sức mạnh của các bộ vi xử lý trên trong chiếc máy tính của họ.

Macintosh HD:Users:Ethan:Downloads:Kaveri-Die-Labeled_575px.jpg

Cấu trúc vi xử lý Kaveri của AMD

Tiếp tục bàn về khả năng xử lý đồ hoạ, ngay cả chip xử lí mạnh nhất được đem ra so sánh của Intel là Core i7-4790K (chúng ta sẽ không sử dụng các giải pháp công nghệ HD 5000, Iris và Iris Pro của Intel bởi nó bị giới hạn trong việc áp dụng dành cho các sản phẩm laptop cũng như hệ thống OEM- Original Equipment Manufacturer) cũng không thể cho kết quả tốt hơn vi xử lý A8-5500 của AMD (Xem ở bài viết P1). Mặc dù Intel đã cố gắng thay đổi điều này bằng cách tăng “không gian” dành cho phần đồ hoạ cho các chip mới của mình (Haswell GT3 chẳng hạn), thì nhìn tổng thể diện tích dành cho đồ hoạ của vi xử lý AMD vẫn là lớn hơn nhiều so với Intel. Bạn có thể kiểm chứng điều này qua việc so sánh hình ảnh vi xử lý Haswell GT2 (ở P1) và hình ảnh vi xử lý Kaveri của AMD ở trên.

Tất nhiên cái gì cũng có mặt có lợi/bất lợi riêng cho nó. Việc sử dụng một GPU riêng dành cho máy tính(ví dụ: AMD R7 240 hoặc NVIDIA GT 730) sẽ đem lại hiệu suất xử lí đồ hoạ tốt hơn nhiều so với việc chỉ sử dụng nền tảng GPU bên trong vi xử lý. Thế nhưng ngày nay, khi mà các hoạt động sử dụng đồ hoạ cao cấp đang dần trở nên quan trọng và phổ biến hơn như trong chơi game, thiết kế hay xử lý các video thì tầm quan trọng của hiệu suất xử lí đồ hoạ đang được quan tâm nhiều hơn – đó chính là cái đích mà AMD ngắm tới. Bởi suy cho cùng, khả năng xử lí tính toán của GPU kết hợp trong vi xử lý không thể nào sánh được với các vi xử lý “thuần chủng”.

Giờ thì chúng ta sẽ bàn đến vấn đề giá cả.

Macintosh HD:Users:Ethan:Downloads:66080.png
Macintosh HD:Users:Ethan:Downloads:66081.png

So sánh hiệu suất theo tỉ lệ giá cả

Đầu tiên cần phải lưu ý là các bài kiểm tra ở đây được thực hiện ở nước ngoài, do đó giá cả ở đây sẽ được hiểu là hiệu suất tính theo mỗi Dollar bỏ ra để mua sản phẩm. Và một sự thực có thể dễ nhận ra đó là thứ mạnh mẽ nhất đương nhiên không phải là thứ tiết kiệm nhất. Intel có thể là nhà sản xuất sở hữu những con chip có khả năng xử lí vượt trội nhất, nhưng nó có đem lại hiệu quả tốt nhất theo chi phí bỏ ra hay không thì lại là câu chuyện khác. Chúng ta cũng sẽ không bàn tới việc nó đắt “vì nó khoẻ hơn”, chúng ta sẽ chỉ xét hiệu quả của số tiền bạn bỏ ra dành cho khả năng xử lý của sản phẩm. Và một điều không quá ngạc nhiên lắm là các sản phẩm ở tầm trung sẽ vượt trội hơn ở các bảng so sánh này.

Giờ thì hãy nhìn tổng thể chi phí phải bỏ ra để hiểu rõ hơn. Nếu bạn mua kết hợp bo mạch chủ, RAM, ổ cứng, Case và PSU thì chi phí bỏ ra sẽ vào 350-510 USD (khoảng 7 đến 11 triệu đồng) dành cho một cấu hình khá ổn. Ngoại trừ các thành phần khác thì chúng ta sẽ quan tâm đến bo mạch chủ – thứ kết nối trực tiếp với các bộ vi xử lí. Kết quả là giá cả dành cho các nền tảng vi xử lý khác nhau sẽ như sau (giá cả quốc tế): 75 USD dành cho chuẩn FM2/FM2+, 80 USD dành cho chuẩn AM3+, 100 USD dành cho chuẩn LGA1155, 90 USD dành cho chuẩn LGA1150 và 225 USD dành cho chuẩn LGA2011. Chắc chắn không ai giới hạn số tiền bạn có thể bỏ ra các các sản phẩm linh kiện đắt tiền hơn, nhưng đây là con số với các linh kiện cơ bản. Và kết hợp các con số đó chúng ta sẽ thấy kết quả: Bạn sẽ mất khoảng 425 USD cho đến 500 USD dành cho một bộ máy sử dụng các CPU trung bình và các APU, 600 USD dành cho một cỗ máy sử dụng các chip cao hơn một chút như Core i5-4690K, 670-705 USD dành cho cỗ máy sửa dụng chip Core i7- LGA1150 và mức giá có phần “ấn tượng” 1559 USD dành cho một cỗ máy trang bị Core i7-4960X. Và khi so sánh hiệu suất giá cả dành cho cả hệ thống (Đã tích hợp một GPU với giá khoảng 50 USD đối với nền tảng AM3+ và LGA2011), chúng ta sẽ có bảng so sánh như sau:

Macintosh HD:Users:Ethan:Downloads:66082.png
Macintosh HD:Users:Ethan:Downloads:66083.png

Một điều dễ nhận thấy là Intel lại quay trở lại vị trí dẫn đầu của mình trên bảng so sánh hiệu năng xử lý/giá cả của hệ thống. Tuy nhiên sự cách biệt giữa các dòng sản phẩm đã không còn quá chênh lệch như trước. Trong khi đó, AMD vẫn tỏ rõ ưu thế của mình với top trên các sản phẩm cho hiệu suất xử lý đồ hoạ/giá cả tốt nhất. Một vấn đề khác đó là các sản phẩm APU mới nhất của AMD (Trinity, Richland, hoặc Kaveri) và các CPU mới nhất của Intel (Ivy Bridge và Haswell) đều có sử dụng tính năng tiết kiệm năng lượng tiêu thụ, do đó sự chênh lệch trong quá trình so sánh hao tốn năng lượng là không quá đáng kể.

Vậy là, các sản phẩm của AMD và Intel đều có ưu thế vượt trội của riêng mình. Trong khi các APU của AMD là sự lựa chọn tốt cho bạn nếu yêu cầu xử lí đồ hoạ là thứu bạn quan tâm nhất thì hiệu suất xử lí/giá cả hợp lý là điểm mạnh khó có thể bàn cãi của các sản phẩm đến từ Intel. Nếu bạn là một người yêu thích vi xử lý của Intel, và túi tiền của bạn trong việc đầu tư cỗ máy tính cho mình là dư giả, hãy chọn Core i7-4790 và i5-4690 – độ đôi CPU Haswell mới nhất của Intel làm người bạn đồng hành của bạn. Đó thực sự là bộ đôi vượt trội về sức mạnh xử lí cũng như “hiệu quả trên từng đồng tiền bỏ ra”. Còn nếu AMD là hãng sản xuất yêu thích của bạn, FX-8320 sẽ là một sự lựa chọn tuyệt vời với khả năng xử lí mạnh mẽ (Nó sở hữu 4 modules với 8 lõi xử lý trong khi APU mạnh nhất chỉ sở hữu 2 modules với 4 lõi xử lý). Tuy vậy, nếu bạn muốn sử dụng các APU tích hợp đồ hoạ, bạn có thể hướng sự chú ý của mình đến Kaveri hoặc Richland APU của AMD. Bộ vi xử lý A8-7600 có lẽ là APU cân bằng nhất và tốt nhất về hiệu suất và giá cả, nhưng bạn có thể đầu tư hơn một chút để có khả năng xử lý đồ hoạ tốt hơn với A10-7800 và A10-7850K.

Sẽ vẫn là cuộc chiến trường kỳ trong việc sản xuất ra các sản phẩm tốt hơn đến từ cả Intel và AMD. Tuy vậy ở vị thế người dùng, hãy cân nhắc nhu cầu sử dụng để có thể lựa chọn một sản phẩm phù hợp nhất dành cho mình. Chúc các bạn sẽ có được một cỗ máy ưng ý đồng hành trong công việc và giải trí.

Tham khảo: Anandtech.com