Разделы портала

Онлайн-тренинги

.
TestRecorder, или польза обезьяньего тестирования
09.11.2012 16:52

Автор: Геннадий Алпаев

За последние несколько лет было написано и переведено столько статей по тестированию и качеству, что практически никто уже не сомневается: тестирование – это систематический процесс, у которого есть подходы, критерии и законы. Так называемое «обезьянье тестирование» (monkey testing) если когда-то и существовало, то уже давно вымерло. Сегодня к тестировщикам предъявляются высокие требования, вплоть до умения программировать, и простое «кликанье» по приложению уже никому не нужно.

Однако так ли это на самом деле?

Насколько часто вы сталкивались с ситуацией, когда приложение «падало» после совершенно невинных действий, а потом воспроизвести эту ситуацию больше не удавалось? Как часто вы сталкивались с ситуациями, когда одна и та же проблема воспроизводится нестабильно, заставляя программиста возвращать вам дефект в статусе «не воспроизводится», а вас – снова и снова открывать дефект с тем же описанием, потому что у вас он воспроизводится стабильно? Любой, кто работал в тестировании или техподдержке, может подтвердить, что такие ситуации случаются регулярно, и решить их зачастую бывает весьма непросто.

Все эти проблемы можно решить с помощью инструмента TestRecorder от компании SmartBear.

 

TestRecorder – это набор библиотек для большинства современных сред разработки (Visual C++, .NET, Java, Delphi), которые можно добавить в тестируемое приложение и которые позволяют записывать все действия пользователя с последующей возможностью преобразовать записанные действия в скрипт, который можно либо просто проанализировать вручную, либо запустить из TestComplete и воспроизвести последовательность действий в реальном времени на любом компьютере.

Чем хорош TestRecorder – это тем, что он не влияет ни на само приложение, ни на взаимодействие с ним извне (например, на автоматизацию тестирования), а может служить лишь дополнением к уже существующим подходам тестирования.

В качестве примера возьмём простое .NET приложение с тремя полями и кнопкой. При нажатии на кнопку «=» в третье поле помещается результат от деления числа в первом поле на число из второго поля.

В окне Visual Studio выберем пункт меню Tools – Choose Toolbox Items, перейдем на вкладку COM Components и выберем элемент TestRecorder Class. Теперь среди инструментов в окне Toolbox у нас появился новый элемент TestRecorder Class, который мы и поместим на нашу форму.

И модифицируем метод загрузки формы Form1_Load таким образом, чтобы Recorder запускался автоматически при загрузке формы:

private void Form1_Load(object sender, EventArgs e)
{
this.axTestRecorder1.Start(false);
}

Теперь нам необходимо модифицировать метод btnEqual_Click (который вызывается при нажатии на кнопку «Равно») таким образом, чтобы он перехватывал исключения:

try
{
int n1 = Convert.ToInt32(this.num1.Text);
int n2 = Convert.ToInt32(this.num2.Text);
this.res.Text = (n1 / n2).ToString();
}
catch (Exception ex)
{
MessageBox.Show(ex.Message + "\n\n" + @"Script is saved to 'c:\trdata1.bin'", "Exception");
this.axTestRecorder1.Stop();
this.axTestRecorder1.SaveDataToFile(@"c:\trdata1.bin");
}

Если теперь в тестируемом приложении попытаться в качестве делителя указать ноль и выполнить операцию деления, в приложении возникнет исключение, которое будет перехвачено, и все действия, выполненные с момента загрузки формы, будут сохранены в бинарном формате в файле C:\trdata1.bin.


Теперь откроем TestComplete, создадим новый проект и выберем пункт меню File – Import – TestRecorder Data – Record Script и в открывшемся диалогом окне выберем файл C:\trdata1.bin.

В результате в редакторе TestComplete мы увидим вполне удобочитаемый и понятный скрипт:

function Test1()
{
var testRecorderDemo;
var form1;
var textBox;
testRecorderDemo = Aliases.TestRecorderDemo;
form1 = testRecorderDemo.Form1;
form1.num1.SetText("3");
textBox = form1.num2;
textBox.Click(36, 10);
textBox.SetText("0");
form1.btnEqual.ClickButton();
testRecorderDemo.dlgException.btnOK.ClickButton();
}

Из этого скрипта сразу видно, какие действия были выполнены в тестируемом приложении. Если же скрипт окажется слишком длинным для разбора, можно просто запустить его на выполнение, щелкнув правой кнопкой мыши в любом месте тела функции и выбрав пункт меню Run Current Routine.

Как видно, подобный подход не требует особых усилий со стороны разработчиков и тестировщиков, однако может оказаться полезным для воспроизведения серьёзных ошибок в приложении. Естественно, в реальном приложении будет слишком накладно вставлять обработчики исключений в каждый метод и нужно использовать глобальный перехват необрабатываемых исключений. Например, для приложений .NET необходимо подписаться на 2 события (Application.ThreadException и AppDomain.CurrentDomain.UnhandledException) и описанным выше способом обрабатывать эти исключения. Подобные же подходы используются и для других типов приложений.