Предисловие

Сразу скажу к чему открыл топик. Я по жизни разработчик, тестированием как таковым я не занимаюсь. Но вот тут поворот судьбы и мне пришлось поработать над системой тестирования.

Я работаю в одной телекоммуникационной компании, это оператор сотовой связи. У нас есть своя разработка различных там коммерческих предложений и есть тестирование этой самой разработки. Как вы уже поняли разработка специфичная и тестирование соответственно тоже своеобразное.

У нас уже были свои методы автоматизации тестов. Это и генераторы учетных записей абонентских вызовов, это и эмуляторы коммутационных железок, это и дикие выборки по базе данных биллинга. Много всего.

У руководства появилась идея несколько стандартизировать этот процесс путем введения в наши процессы некоторого средства, зарекомендовавшего себя в мире. Ну долгая история. Выбрали мы продукты IBM Rational.

Меня сюда привлекли с той целью, чтобы я попробовал внедрить эту систему нам и самое главное интегрировал ее с биллингом.

Честно скажу, что с системой я не знаком и многие вещи познавал, так сказать, с нуля. Мне интересно обрисовать свой путь, чтобы облегчить жизнь другим — это раз, два — это чтобы мне дали обратную связь опытные товарищи. А три — это мой маленький бунт. Я решил, что тестировать с помощью IR мы не будем, а будем использовать эту штуку исключительно для организации тестов.

Разработка тестов

Итак, коллеги из IBM предлагают нам пройти пять шагов: планирование, проектирование, реализация, исполнение, анализ.

Это определение требований к объекту тестирования, декларация так называемых TestInputs. Для проверки требований создаются TestCases, которые в свою очередь храняться в TestFolders, расположенных в TestPlans.

Когда у нас есть тестовые случаи и требования, мы можем построить между ними ассоциации. Тем самым мы определяем покрытие требований к объекту тестирования. На выходе будет картинка, из которой будет видно что мы хотели протестировать, что протестировали, что прошло удачно, что нет, а что мы даже не пытались тестировать.

Определение всей этой структуры и есть планирование и проектирование. Между этими двумя этапами нет особой практической разницы. Планирование выстраивание этой структуры, а проектирование это добавление к этой структуре особого смысла в рамках области знаний, в которой находится объект тестирования.

Сами тестовые случаи имеют реализацию. Реализация может быть ручная (Manual) или автоматическая (Automatic). Ручная это перечень действий, который будет видеть тестировщик. Он человек, он читает что надо сделать и/или проверить, видит критерий корректности. И все это проделывает как может. Автоматическая это вызов скрипта. Вот это любопытно, но вернемся к этому чуть позже.

Это мы реализовали тесты. Теперь их надо запустить. Для запуска теста, для определения параметров прогона испытаний создается костюм (смайлы ставить нельзя), я хотел сказать Сьюит (Suite). Сьюит включает в себя кейсы и условия их выполнения. Там еще можно много чего настроить. Во общем сделали сьюит, запустили его. Система прогонит скрипты и/или покажет тестировщику картинки с указаниями к действию.

Когда все заканчивается система покажет нам лог с красивыми пометками предупреждений, неудач и успехов. Все это дело можно красиво увидеть в многочисленных отчетах или художественно обработать в своем отчете. Свои отчеты можно создавать при помощи Crystal Reports. Это собственно оценка результатов. По сути результат может быть использован как постановка требований, то есть отсюда мы можем снова перейти в к первому шагу.

Картинка из документации.

Вот мы прошли пять шагов. Так выглядят тесты в этой системе. Так я их увидел.

Автоматизация

В IR есть кучу скриптовых средств. Здесь можно писать скрипты на GUIScript, VisualBasic, VUScript, Java, командная строка и еще что-то. Пусть слово скрипты вас не пугает, в IR это вполне определенный термин, он мало относится к языкам программирования, это просто сущность, которая обозначает метод реализации кейса.

Два встроенных языка GUIScript и VUScript это по сути костяк автоматизации в IR. По сути вся автоматизация здесь делиться на две больших группы: GUI и VU. Тестирование GUI говорит само за себя, это автоматическое истыкивание кнопок в графических интерфесах. Тестирование с привлечением VU, лихая формулировка отражает аббревиатуру VU — Virtual User. Технология VU позволяет имитировать работу нескольких пользователей, нескольких, это сотен, тысяч и т.д. По сути это уже реализация нагрузочных тестов.

GUI тестирование требует рабочий стол, то есть на одном рабочем столе на одной машине может проходить ни более одного испытания одновременно. Для VU такого ограничения нет, но есть лицензионное ограничение на виртуального пользователя. Их надо закупать штуками.

Язык GUI это по сути Visual Basic, для VU это C, у IR свой транслятор и компилятор C-синтаксиса. Остальные скриптовые средства, которые я приводил, это реализация VU. Виртуальные пользователи посредством особого расширения TSS (Test Script Service) могут прогонять код, написанный на другом языке.

Меня как программиста Java заинтересовала Java-реализация. Ну во общем назрело. Описание скриптов автоматизации мне видится каким-то таким «прищепочным» что ли. Что-то на коленках пописывается там. Требуется какое-то большое красивое универсальное средство. И еще меня волнует вопрос лицензий. По ряду обстоятельств (вполне объективных на тот момент времени), наша компания не купила лицензии на VU. Но в комплекте есть лицензия на одного VU, этакий маркетинг.

CALCUTTA

Мои воззрения выразились в написании каркаса для разработки средств автоматизации. Название я ему дал CALCUTTA.

Что собой представляет все это дело? Это маленькие скрипты, код на Java, которые из окружения IR умеют по HTTP разговаривать с некоторым сервером приложений. А все тестирование крутиться там. В IR мы планируем, проектируем, реализуем, исполняем и анализируем. Исполняем причем только часть постановки задачи в сервер приложений и часть получения результата. Каждый прогон теста в IR будет происходить не дольше минуты. А само тестирование в любое количество параллелей, на любом сервере крутиться так как нам это надо. Целая банда тестировщиков могут пользоваться всего 5-ю виртуальными пользователям. А то и одним, если группа небольшая. В один момент времени возможно только одному человеку потребуется запустить тест или снять с него результат.

CALCUTTA дает нам должный уровень абстракции при разработки средств автоматизации тестирования. Программист должен задуматься только об объекте тестирования. Само по себе средство, это инструмент, некий инструмент, который умеет выполнять то или иное действие.

В роли сервера приложений у меня выступает Apache Tomcat.

Можно долго размышлять. Я вам лучше сразу код покажу. Итак срипты и инструменты.

Вот реализация теста по проверке пингуется ли машина. В инструменте вы увидите бессмысленный (с точки зрения задачи по пингованию) цикл, это просто чтобы создать мнимую паузу, этакий длительный процесс.

Скрипт.


 
        package ru.megafonvolga.calcutta.tss.sandbox;
 
        import ru.megafonvolga.calcutta.network.Message;
        import ru.megafonvolga.calcutta.tss.env.CalcuttaScriptException;
        import ru.megafonvolga.calcutta.tss.env.Script;
        import ru.megafonvolga.calcutta.tss.utils.Calcutta;
 
        public class HostReachableChecker extends Script {
 
                @Override
                public void execute(String[] args) throws CalcuttaScriptException {
                        if (Calcutta.createTool("ping", "ru.megafonvolga.calcutta.tools.sandbox.t2.HostReachableChecker") || Calcutta.isSessionMarkedToRepeat()) {
                                Calcutta.setToolProperty("ping", "host", getScriptOption("host"));
                                Calcutta.executeTool("ping", false);
                                throw new CalcuttaScriptException("tool \"ping\" is executing...",
                                                "run me again to know result",
                                                CalcuttaScriptException.EL_WARNING);
                        } else {
                                Message inMsg = Calcutta.getToolStatus("ping");
                                int code = inMsg.getIntParameter("currentStateCode");
                                String message = inMsg.getStringParameter("currentStateMessage");
                                double percent = inMsg.getDoubleParameter("currentProgressPercent");
                                if (code > 0)
                                        throw new CalcuttaScriptException("tool is still executing...",
                                                        "code=" + code + ", message=" + message + ", done for "
                                                                        + percent + "%",
                                                        CalcuttaScriptException.EL_WARNING);
                                else if (code < 0)
                                        throw new CalcuttaScriptException("test failed",
                                                        "code=" + code + ", message=" + message,
                                                        CalcuttaScriptException.EL_ERROR);
                        }
                }
 
        }

Инструмент.


 
        package ru.megafonvolga.calcutta.tools.sandbox.t2;
 
        import java.net.InetAddress;
 
        import ru.megafonvolga.calcutta.controller.CalcuttaSession;
        import ru.megafonvolga.calcutta.controller.CalcuttaToolException;
        import ru.megafonvolga.calcutta.tools.Tool;
 
        public class HostReachableChecker extends Tool {
 
                private String host = "";
 
                public HostReachableChecker(CalcuttaSession session, String toolInstaceName) {
                        super(session, toolInstaceName);
                }
 
                @Override
                public void execute() throws CalcuttaToolException {
                        setCurrentStateCode(1);
                        setCurrentStateMessage("waiting...");
                        setCurrentProgressPercent(0.0);
                        try {
                                if (!InetAddress.getByName(getHost()).isReachable(3000)) {
                                        setCurrentStateCode(-1);
                                        setCurrentStateMessage("host is unreachable");
                                }
                                for (int f = 0; f < 10; f++) {
                                        Thread.sleep(1000);
                                        setCurrentStateCode(f + 1);
                                        setCurrentStateMessage("waiting...[" + f + "]");
                                        setCurrentProgressPercent(f * 10.0);
                                }
                        } catch (Exception e) {
                                throw new CalcuttaToolException(e);
                        } finally {
                                setCurrentStateMessage("done");
                                setCurrentStateCode(0);
                                setCurrentProgressPercent(100.0);
                        }
                }
 
                public String getHost() {
                        return host;
                }
 
                public void setHost(String host) {
                        this.host = host;
                }
        }

Вот так это выглядит в IR.

Сьюит.

Лог первого выполнения.

Веб-представления процесса исполнения инструментов.

Лог после исполнения теста когда инструемент закончил выполнение.

В целом вот. Я еще хочу в дальшем написать как склеить Java с Rational, так сходу он не склеивается. Причем об этом не очень много информации я нашел в сети. И если тема окажется интересной, то также опубликую более подробную статью о CALCUTTA.

Информация в основном черпалась из документации IBM Rational TestManager.

Еще один способ применить для своих задач тестирования IBM Rational TestManager/Robot