четверг, 11 февраля 2010 г.

Voxeo, VO

В разработке голосовых приложений недавно обнаружили такую вещь, которую "пропускали" уже много-много раз, и все "прокатывало". Оказывается, если в грамматику "Nuance" передавать некоторые из запрещенных символов, то в какой-то момент и при каких-то условиях могут происходить проблемы с лицензиями. Поэтому, блин, не надо забывать о проверке данных, поступающих из внешних источников, например, ФИО абонентов, по которым затем происходит распознавание.

Стандартное правило: "делать проверку данных поступающих извне Системы".

За что, собственно, поплатились в очередной раз превышением трудозатрат по задачам

суббота, 6 февраля 2010 г.

Словарь ненормативной лексики программиста


Попробуйте узнать в них реальные ситуации из жизни своего проекта. Если вы заметили частое употребление сотрудниками приведенных ниже выражений, в проекте нужно срочно наводить порядок.
  • Ну, не знаю, у меня на машине всё работает.

    Комментарий: это неправда. То есть, конечно, что-то работает - после серии магических пассов, недоступных пользователю и тестировщикам.
  • Да у вас просто "Винды" кривые.

    Комментарий: это не имеет никакого отношения к делу. У большинства пользователей в мире "Винды" - кривые, а прикладные программы все-таки работают.
  • Попробуйте перезапуститься. Думаю, всё заработает.

    Комментарий: это маловероятно, хотя возможно. Но программа должна работать и без перезапуска.
  • Как дела в проекте? Работа ведется!

    Комментарий: "Работаем" - обычный ответ разработчика на вопросы менеджера. Помогает "отбить" две трети, а то и четыре пятых запросов о ходе проекта. Сам по себе этот ответ - не криминал, и на самом деле в разработке бывают периоды упорной работы "от забора до обеда", когда результатов не видно. Но частое повторение этой формулы подозрительно - она может служить и для сокрытия уже обнаружившихся проблем со сроками и трудоемкостью, которые разработчик надеется решить сам, не доводя до начальства.
  • Я уже неделю ночами работаю, а вы меня укоряете за срыв срока.

    Комментарий: ночная работа - это вовсе не доблесть. Скорее всего, просто у программиста сложился такой режим (что часто бывает), а в сутки всё равно выходит 8-10 рабочих часов. Даже если и была бы переработка, то это недостаток организации работ.
  • Нельзя подпускать к проекту этих маркетоидов, которые ничего не понимают в технологиях.

    Комментарий: маркетоиды не дают программировать всякие интересные штуки и вносят слишком много приземленных коммерческих требований.
  • Эти менеджеры опять начнут совещаться, а мне работать нужно.

    Комментарий: действительно, часто совещания не имеют смысла, но совсем без них нельзя. А программисты с удовольствием участвуют в одних совещаниях, где идут обсуждения вообще и придумываются всякие классные идеи, и не любят другие - те, на которых наступает слишком большая ясность относительно состояния дел и выполнения планов.
  • Чего там планировать, я быстрее сделаю и всё уже будет работать.

    Комментарий: это неправда. Скорее всего, будет сделано не совсем то и неработающее. А срок доводки окажется длиной в целый проект.
  • Планировать разработку бессмысленно, жизнь всё равно богаче. Программные проекты всегда срывают сроки, потому что это сложное и творческое дело, вроде научных исследований.

    Комментарий: это миф. При правильном проектировании и планировании сроки разработки ПО возможно выдержать и это нужно делать.
  • Нанимать персонал должен только технический менеджер проекта, потому что ему потом с ними работать.

    Комментарий: это часто приводит к неумолимому срабатыванию Закона Паркинсона - найму по знакомству ненужных, слабых или неконтролируемых сотрудников. Нанимать разработчиков должен высший менеджмент и по возможности через кадровое агентство, а технический менеджер - накладывать вето при необходимости.
  • Если всё сделать общим образом, мы получим не только решение частной задачи, но и готовый программный продукт, который будем продавать другим, и таким образом всё окупим.

    Комментарий: это просто приятные фантазии. Разработка готового продукта стоит примерно в три раза дороже программы для собственных нужд (см. "Мифический человеко-месяц" Фредерика Брукса). Кроме того, никто ведь не изучал рынок на предмет выяснения, а нужен ли такой продукт, и сколько у него сильных конкурентов.
  • К пятнице готово не будет, но в понедельник - точно. Или во вторник.

    Комментарий: скорее всего и во вторник ничего не будет. В лучшем случае будет не готовая версия, а нечто для показа из рук с объяснениями на пальцах, как всё будет потом.
  • К сроку готово не будет, потому что сгорел жесткий диск и пропала работа за неделю (месяц).

    Комментарий: скорее всего, это неправда. Диск действительно сгорел, но причина срыва сроков не в этом. Кроме того, если бы работа ежедневно архивировалась, проблемы бы в любом случае не возникло.
  • Срок сорван - а что вы хотели? С самого начала было ясно, что ресурсов не хватает.

    Комментарий: это точно неправда. В начале проекта никто не поднял тревоги, что мало ресурсов. И в середине проекта - тоже. Это просто самая распространенная "отмазка".
  • Программа хорошо документирована на языке Си.

    Комментарий: программистская шутка "для своих", отражающая тот печальный факт, что никто не писал комментариев и документации к программам и не будет писать, если не заставить твердой рукой.
Игорь Ашманов

воскресенье, 31 мая 2009 г.

Google создал замену чату и электронной почте

На этой неделе корпорация Google в Сан-Франциско анонсировала сервис Google Wave, который призван функционально заменить электронную почту, программы обмена мгновенными сообщениями и системы совместной работы над документами.


Подробнее здесь: http://www.techcrunch.com/2009/05/28/google-wave-drips-with-ambition-can-it-fulfill-googles-grand-web-vision/

А вот здесь обзор по-русски: http://lenta.ru/articles/2009/05/30/wave/

Вот здесь прекрасное видео (демонстрация возможностей): http://googleblog.blogspot.com/2009/05/went-walkabout-brought-back-google-wave.html

Впечатляют встроенные возможности, лично мне очень понравился online-перевод набираемых сообщений - не зря такая овация зрительного зала во время демонстрации

четверг, 12 февраля 2009 г.

Нагрузочное тестирование SQL Server с помощью Visual Studio


Introduction

This article describes how to use Visual Studio 2005 Team Edition for Software Testers to run performance characterization tests for SQL Server 2005 Reporting Services. You can use this article as a guideline for capacity planning or to assess performance before rolling out reports on a production server.

This article contains step-by-step instructions for setting up a project, creating Web page and unit tests, creating and configuring a load test, running the test, and evaluating the results. After you create the tests, you can run them on different server configurations to quantify the improvement in performance when you change hardware components or modify a report definition or query, or specify different rendering formats.

Choosing Reports

This article uses the AdventureWorks sample reports and database to illustrate key concepts. You can use the sample reports if you want to use the sample code and steps provided, or you can work with your own reports and modify the code and steps accordingly. When you perform load tests, the reports must be able to run with no user interaction required. If the report prompts for data-source credentials or parameter values, you must temporarily modify the report to use stored or integrated credentials and default parameters for the purpose of running the tests.

Requirements

This article assumes that you have the following software, samples, and permissions installed on a test server:

  • Visual Studio 2005 Team Edition for Software Testers.
  • SQL Server 2005 Reporting Services.
  • SQL Server Management Studio.
  • AdventureWorks sample database.
  • AdventureWorks sample reports.
  • Permission to access the Database Engine, create databases, and retrieve data from the AdventureWorks database. You must also have role assignments that grant access to the reports.

Visual Studio 2005 Team Edition for Software Testers

You can install a subset of the Visual Studio 2005 components. The following screen shot shows the Team Developer and Tester tools that are used in this exercise. The tools that you will use include Performance Tools, Code Analysis Tools, and Testing Tools.

You must also have a language project installed. The sample code provided in this article is in Microsoft Visual C# 2005, but you can use another language if you want to use your own code.

Click here for larger image

Figure 1. Visual Studio 2005 setup (Click on the image for a larger picture)

AdventureWorks Sample Database and Reports

AdventureWorks is a sample relational database that is included with SQL Server 2005. If you want to use the AdventureWorks sample reports, first make sure that the Reporting Services samples are installed. By default, they are located at <drive>:\Program Files\Microsoft SQL Server\90\Samples. If not they are not installed, you must install them. For instructions on how to install and uninstall the samples, see Installing Samples in SQL Server 2005 Books Online. You can also download the samples from the Microsoft Download Center.

In this exercise, we will use the following single-page and multipage reports:

  • Company Sales
  • Product Catalog
  • Employee Sales Summary

Employee Sales Summary prompts for a parameter value. When you create a unit test, you will specify a parameter value to pass to the report at run time. This allows the report to run unattended.

All of these reports retrieve data from the AdventureWorks sample database, using Microsoft Windows authentication and your credentials to connect to SQL Server 2005.

Before you start, verify that you can access the AdventureWorks sample database and run the reports by starting Report Manager and opening each report.

Setting Up

Firstly, install Visual Studio 2005 Team Edition for Software Testers. Secondly, create a test project, as follows:

  1. Click Start, select Programs, and then select Microsoft Visual Studio 2005.
  2. On the File menu, click New, and then click Project to open the New Project dialog box.
  3. In the New Project dialog box, expand the Visual C# node, and select Test.
  4. Select Test Project, accept the default name TestProject1, and then click OK.

Click here for larger image

Figure 2. Select the Test Project template in Visual C#. (Click on the image for a larger picture)

By default, the newly created test project contains an empty unit test. You can safely ignore it for now; you will add sample code to it later.

Creating a Web Test

A Web test is used to test the functionality of Web applications and to test Web applications under load. Although you can build Web tests manually, it is easier to create them by recording your activities in a browser session.

  1. In Solution Explorer, right-click TestProject1, select Add, and then select Web Test.

     

    Click here for larger image

    Figure 3. Add a Web test to TestProject1. (Click on the image for a larger picture)

    A browser window pops up automatically. It will look similar to Figure 4. You will use this browser window to add URLs for each report that you want to include in the test.

     

    Click here for larger image

    Figure 4. Browser window (Click on the image for a larger picture)

  2. In the Address bar, replace about:blank with the URL address of a report that has been deployed to a report server. Open the report through a direct connection to the report server, and then copy the URL.
  3. Add the &rc:Toolbar=False parameter to the report URL to hide the toolbar at run time. Suppressing the toolbar is necessary to avoid anrsExecutionError error. This error will occur if the session identifier that was current when the test was created differs from the session identifier that is created when the report runs. The toolbar uses session information to track page navigation. By hiding the toolbar, you eliminate the need to retrieve session information when the report is run.

    A report URL to Company Sales that includes the &rc:Toolbar=False parameter looks like the following:

    http://localhost/ReportServer/Pages/ReportViewer.aspx?%2fAdventureWorks+Sample+Reports%2fCompany+Sales&rs:Command=Render&rc:Toolbar=False

  4. Press the Enter key. Keyboard actions and user input are recorded and stored in the test for subsequent playback. When you press Enter, the report is processed and rendered in the browser window. The actions are recorded for subsequent playback when you run the test.

     

    Click here for larger image

    Figure 5. Company Sales sample report (Click on the image for a larger picture)

You can add multiple reports if you want to test several at the same time. To do this, replace the URL with a different report URL and press Enter to record the action.

  1. In the Address bar, enter the report URL for a Product Catalog report, and press the Enter key. You can repeat these steps to add other reports.
  2. After you have added all the reports you want to test, click Stop to stop recording and return to the project.

    You now have a Web test that contains a list of recorded actions.

     

    Click here for larger image

    Figure 6. Recorded actions in the Web test (Click on the image for a larger picture)

    Next, you will run the test. Visual Studio 2005 provides a Run button in the toolbar. On the tab named WebTest1.LoadTest, it is the first button with a green arrow on it.

     

    Click here for larger image

    Figure 7. Run the test. (Click on the image for a larger picture)

  3. Switch to the WebTest1.webtest tab, click the Run button, and then select Run Test to replay the reports. The Test Results window will show whether or not the test was successful.

    If you do not see the Test Results window, on the Test menu, select Windows, and then select Test Results.

     

    Click here for larger image

    Figure 8. View test results. (Click on the image for a larger picture)

    If an error occurs, you can click the Run button again and select Debug Test to diagnose the error.

Creating a Unit Test

Unit tests are programmatic tests that are written in Visual C# (or other programming languages) and used to exercise other source code by directly calling the methods of a class, passing appropriate parameters, and then (if you include Assert statements) testing the values that are produced against expected values.

In this section, you will learn how to create a unit test that calls a single report on a local report server, and run the report with a specific parameter value.

  1. In Solution Explorer, double-click Unit Test1.cs. Delete the existing code, so that the file is empty. The following lines of code should be deleted.
    using System; using System.Text; using System.Collections.Generic; using Microsoft.VisualStudio.TestTools.UnitTesting;  namespace TestProject { ///  /// Summary description for UnitTest1 ///  [TestClass] public class UnitTest1 { public UnitTest1() {             //             // TODO: Add constructor logic here             // }  #region Additional test attributes // // You can use the following additional attributes as you write your tests: // // Use ClassInitialize to run code before running the first test in the class // [ClassInitialize()] // public static void MyClassInitialize(TestContext testContext) { } // // Use ClassCleanup to run code after all tests in a class have run // [ClassCleanup()] // public static void MyClassCleanup() { } // // Use TestInitialize to run code before running each test  // [TestInitialize()] // public void MyTestInitialize() { } // // Use TestCleanup to run code after each test has run // [TestCleanup()] // public void MyTestCleanup() { } // #endregion  [TestMethod] public void TestMethod1() {             //             // TODO: Add test logic   here             // } } } 
  2. Copy the following sample code and paste it into the unit test. You can use the following code as a template and update it to assign different values to the parameter, render multiple reports, and so on.

    This sample code displays the Employee Sales Summary report. The report has a parameter named EmpID, and the code sets the value to 275.

    using System; using System.Collections.Generic; using System.Text; using Microsoft.VisualStudio.TestTools.WebTesting;  namespace RSLoadTest { public class Report : WebTest { protected const string REPORTSERVER = "http://localhost/Reportserver";  // Report's URL address. protected string m_urlName; // EmpID is a Report parameter. protected int m_EmpID; // ThinkTime between each report rendering.  protected int m_thinkTime;  public Report() {             this.PreAuthenticate = true;              // Set Report Name.             m_urlName = "%2fAdventureWorks+Sample+Reports%2fEmployee+Sales+Summary";             // Set value to Parameter EmpID.             m_EmpID = 275;             // Set think time to 35 seconds.              m_thinkTime = 35; }  public override IEnumerator GetRequestEnumerator() {             WebTestRequest request = new WebTestRequest(REPORTSERVER);             WebTestRequestHeaderCollection headers = request.Headers;             // A lot properties are set by default             // Example:              // For each request: Verb = "GET", HTTPVersion = "HTTP/1.1"             // For each header: Accept, Accept-Language, User-Agent, Host are set by default             // We only modify properties that have non-defaults.               // First remove all existing headers.             headers.Clear();              headers.Add("Cookie", "(automatic)");              // Before each request, clear all existing parameters.             request.QueryStringParameters.Clear();              request.QueryStringParameters.Add("", m_urlName, false, false);              request.QueryStringParameters.Add("rc:Toolbar", "False");                     request.QueryStringParameters.Add("EmpID", m_EmpID.ToString());              request.QueryStringParameters.Add("rs:Command", "Render");              // Choose to set Think Time to 30 seconds.              request.ThinkTime = m_thinkTime;              yield return request; } } } 

Extending Web Tests and Unit Tests

In the previous section, you used the sample code in a unit test to learn how to set parameter values programmatically. Although the sample code illustrates basic principles that can help you get started, it has two limitations that you might want to address before you create similar tests for an actual test environment. Namely, the value that is passed to the EmpID parameter is hard-coded, and the output format is always the default HTML-rendering extension. To perform realistic load tests on your reports, you should try a variety of rendering extensions and run reports with different parameter values to get a complete picture of how the report performs when you vary the query parameters.

Testing for Rendering Formats

To specify different rendering formats, consider incorporating URL access into your tests. In Reporting Services, each report can be accessed through its URL. You can specify parameter values on a report URL to vary the rendering extension, test device configuration settings, or specify a data source. The URL must be a fully qualified path to the report. For more information about the URL parameters that are used for accessing SQL Server 2005 reports, see Using URL Access Parameters.

The following code snippets show you how to specify rendering extensions, so that you can run tests for different rendering formats.

  • To render a report in Microsoft Office Excel, use the following code snippet.
    request.QueryStringParameters.Add("rs:Format", "EXCEL"); 
  • To render a report in PDF, use the following code snippet.
    request.QueryStringParameters.Add("rs:Format", "PDF"); 
  • The code snippet should be placed in function.
    public override IEnumerator GetRequestEnumerator() 
  • The following code provides a complete example.
    public override IEnumerator GetRequestEnumerator() {             WebTestRequest request = new WebTestRequest(REPORTSERVER);             WebTestRequestHeaderCollection headers = request.Headers;             // A lot properties are set by default             // Example:              // For each request: Verb = "GET", HTTPVersion = "HTTP/1.1"             // For each header: Accept, Accept-Language, User-Agent, Host are set by default             // We only modify properties that have non-defaults.               // First remove all existing headers.             headers.Clear();              headers.Add("Cookie", "(automatic)");              // Before each request, clear all existing parameters.             request.QueryStringParameters.Clear();              request.QueryStringParameters.Add("", m_urlName, false, false);              request.QueryStringParameters.Add("rc:Toolbar", "False");              request.QueryStringParameters.Add("EmpID", m_EmpID.ToString());                     request.QueryStringParameters.Add("rs:Format", "EXCEL");               request.QueryStringParameters.Add("rs:Command", "Render");              // Choose to set Think Time to 30 seconds.              request.ThinkTime = m_thinkTime;              yield return request; } 

Testing with Dynamic Data

To work with dynamic data, use the data-binding features in Visual Studio 2005 to pass query-parameter values to a report. In the sample for the unit test, the Employee Sales Summary sample report has a parameter named EmpID that is set to an m_EmpID member variable. In most cases, parameter values are stored in a database table (in this example, values for parameter EmpID are from table [AdventureWorks].[HumanResources].[Employee], from the columnEmployeeID). To pull a value for parameter EmpID dynamically from that database table and assign it to parameter EmpID, you can create a data source that connects to table [AdventureWorks].[HumanResources].[Employee] and then bind column EmployeeID to parameter EmpID. For detailed instructions on how to set up data binding in Visual Studio 2005 Team System, see How to: Add Data Binding to a Web Test.

Creating a Load Test

To run the unit test that you just created, you must define a load test that sets the load pattern that you want to use. In this exercise, the primary goal of the load test is to simulate multiple users accessing a server simultaneously. By adding a Web page test or a unit test to a load test, you can simulate multiple users opening connections and making multiple HTTP requests.

In a previous section, you created a unit test. In this section, you will create a load test, and then add the unit test that you created.

  1. In Solution Explorer, right-click TestProject1, select Add, and then select Load Test. This starts the New Load Test Wizard.

     

    Click here for larger image

    Figure 9. Create a load test. (Click on the image for a larger picture)

  2. Click Next on the Welcome page, and then click Next on the Scenario page.
  3. On Load Pattern, in User Count, enter 25 to simulate 25 simultaneous connections to the report server, and then click Next.

     

    Click here for larger image

    Figure 10. Enter the number of simultaneous connections. (Click on the image for a larger picture)

  4. On the Test Mix page, click Add to add the unit test (Report) to the load test.
  5. Select Report (this is the name of the unit test), click the > arrow to add it to the Selected Tests area, and then click OK.

     

    Click here for larger image

    Figure 11. Add the unit test to the load test. (Click on the image for a larger picture)

  6. Click Next to accept the default values on the Browser Mix and Network Mix pages.

    Optionally, on the Counter Sets page, you can specify custom performance counters to use during the test run. This is useful if the reports or queries are run on a remote computer. If they are, you can add counters from the remote computer and monitor them locally when the test runs. If all processing is local, you do not have to specify a counter set. The load-test tool provides access to local performance counters by default.

  7. Click Next to continue to the next page.

     

    Click here for larger image

    Figure 12. Add performance counters. (Click on the image for a larger picture)

  8. On the Run Settings page, enter a value in the Run Duration box and, if applicable, a value in the Warm-up Duration box also.

    Figure 13 shows a run duration of 30 minutes, but you can specify a shorter or longer duration.

  9. Click Finish.

     

    Click here for larger image

    Figure 13. Add run settings. (Click on the image for a larger picture)

Creating a Test Results Database

Before running the load test, you must create a load-test result repository. It stores the result data that is collected during the load-test run.

  1. Start SQL Server Management Studio and connect to the Database Engine.
  2. On the File menu, select Open, and then select File.
  3. Open the loadtestresultsrepository.sql file that is located at %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE.
  4. Click Execute. This creates the database on the current Database Engine instance.
  5. Close SQL Server Management Studio.
  6. In Visual Studio 2005, on the Test menu, click Administer Test Controllers. The Administer Test Controller dialog box appears.
  7. In the Load Test Results Store connection string, click the ... button to edit the Connection Properties dialog box.
  8. Enter the server name that will host the database, and select the database. By default, the database name is LoadTest.
  9. Click OK.

     

    Click here for larger image

    Figure 14. Select the Database Engine instance that has the LoadTest database. (Click on the image for a larger picture)

    Now, you can run the load test exactly as you would if it were a Web test.

  10. Click the Run button and select Run Test.

     

    Click here for larger image

    Figure 15. Run the load test. (Click on the image for a larger picture)

Checking Results

While the load test is running, you will see the results displayed in the Test Results window as In Progress. You can click In Progress to view information about the test as it runs.

Click here for larger image

Figure 16. Monitor the test. (Click on the image for a larger picture)

To monitor server performance, use the Requests/Sec and Avg. Response Time counters. If you added other counters when you create the load test, you can find them in the Counters pane. Double-click them to add them to the graph.

Conclusion

Now that you have a basic understanding of how to use the load-test tool with reports, you can build upon that knowledge by creating and running tests on configurations that are used in your organization.

In most cases, you will want to run a load test on a computer different from the one used to run the report server. Additionally, to mimic actual user activity, configure multiple user sessions across multiple computers. This configuration is called controller-agent configuration, and the computer that runs the load test is the controller. The computers that host the user sessions are created as agents. Controller-agent configurations are beyond the scope of this white paper, but if you want to learn more about controllers, agents, and Visual Studio 2005 Team Edition for Software Testers, see the following links on the MSDN Web site:


А здесь можно скачать Word-документ (from ZdNet.com): http://indigosoft.ru/Portals/33/other/REAL_UsingVSforLoadTestingonSQLServer.doc

суббота, 7 февраля 2009 г.

Про тестинг

Нашел небольшой сайт http://www.protesting.ru/ . Мало информации, но что-то полезное можно выцепить. А может тем и хорошо, что все кратко и лаконично (хотя, возможно, и бесполезно)

Записи докладов на КРИ 2006

Ссылка на сборник записей докладов по управлению проектами: http://kriconf.ru/2006/index.php?type=info&doc=speech_records#projectsmanagement 

И вот конретно доклад Виталия Шутова: 

http://kriconf.ru/2006/rec/ppt/KRI_2006_BusinessDevelopment_09apr_kz_02_Vitalii_Shutov_MistLandYug.ppt

http://kriconf.ru/2006/rec/KRI_2006_BusinessDevelopment_09apr_kz_02_Vitalii_Shutov_MistLandYug.ogg