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) Теперь нам необходимо модифицировать метод btnEqual_Click (который вызывается при нажатии на кнопку «Равно») таким образом, чтобы он перехватывал исключения: try Если теперь в тестируемом приложении попытаться в качестве делителя указать ноль и выполнить операцию деления, в приложении возникнет исключение, которое будет перехвачено, и все действия, выполненные с момента загрузки формы, будут сохранены в бинарном формате в файле C:\trdata1.bin. Теперь откроем TestComplete, создадим новый проект и выберем пункт меню File – Import – TestRecorder Data – Record Script и в открывшемся диалогом окне выберем файл C:\trdata1.bin. В результате в редакторе TestComplete мы увидим вполне удобочитаемый и понятный скрипт: function Test1() Из этого скрипта сразу видно, какие действия были выполнены в тестируемом приложении. Если же скрипт окажется слишком длинным для разбора, можно просто запустить его на выполнение, щелкнув правой кнопкой мыши в любом месте тела функции и выбрав пункт меню Run Current Routine. Как видно, подобный подход не требует особых усилий со стороны разработчиков и тестировщиков, однако может оказаться полезным для воспроизведения серьёзных ошибок в приложении. Естественно, в реальном приложении будет слишком накладно вставлять обработчики исключений в каждый метод и нужно использовать глобальный перехват необрабатываемых исключений. Например, для приложений .NET необходимо подписаться на 2 события (Application.ThreadException и AppDomain.CurrentDomain.UnhandledException) и описанным выше способом обрабатывать эти исключения. Подобные же подходы используются и для других типов приложений. |