Анализ. Анализ и автоматизация процесса тестирования программного обеспе. Высшего образования национальный исследовательский университет высшая школа экономики
 Скачать 197.73 Kb.
|
|
Данный тест-кейс содержит следующие обязательные атрибуты: Уникальный идентификатор тест-кейса: PGU-1 Название: ВСВ. Избранные услуги Предусловия: в данном тест-кейсе предусловием является авторизация на портале. Непосредственно к тесту авторизация не относится (авторизацию на портале проверяет отдельный тест-кейс), но без авторизации данная проверка невозможна. Шаги. Ожидаемый результат. Статус кейса. История редактирования: в тест-кейсе указана информация о том, кто проходил тест, в какое время и в рамках какой сборки. Данный тест-кейс отвечает требованиям, изложенным выше. Шаги сформулированы однозначно, содержат необходимую, но не лишнюю информацию, ожидаемый результат четкий и однозначный. Выполнение тест-кейсов Одной из особенностей процесса тестирования является необходимость проведения тестирования программы специалистом, который не является ее автором. Категорически неприемлемо тестирование продукта программистом, создавшим его. Это правило должно быть применимо ко всем, без исключения, формам тестирования, например, как к тестированию целой системы, так и к тестированию отдельных модулей, а также внешних функций. Несомненно, при проведении процесса тестирования не автором программы, он становится более точным и эффективным. Если рассматривать суть процесса тестирования, то становится очевидным, что это процесс деструктивный. С этой его особенностью и связывают представление о тестировании как о сложной работе. Исключительно трудной эта работа представляется для программиста, создавшего продукт, так как проектирование, разработка и написание программы является процессом конструктивным, в отличие от тестирования, в процессе которого специалисту необходим настрой на деструктивный образ мышления. Исходя из этой особенности тестирования, приступать к тщательному и беспристрастному выявлению ошибок сразу же по завершению создания программы представляется трудновыполнимым для ее автора. Например, содержащиеся в модуле дефекты, которые являются следствием ошибок перевода (такие как, к примеру, неверная интерпретация спецификации), с высокой долей вероятности будут присутствовать и в тестах, так как оба процесса будут выполняться одним и тем же специалистом. Также могут обнаружиться в тестах и ошибки, сделанные при понимании и сопряжении других модулей. Однако, не следует делать однозначный вывод, что тестирование программы специалистом ее создавшим невозможно. Большое количество программистов справляются с этой задачей вполне успешно. Но, исходя из вышесказанного, можно прийти к заключению, что выполнение тестирования другим специалистом, не являющимся ее автором, гораздо эффективнее и плодотворнее. Поэтому и создаются группы тестировщиков, специально для проведения процесса тестирования с наиболее оптимальными результатами. Принятие решения о сроках остановки тестирования является одной из сложных проблем при проведении тестирования. Это происходит, потому что невозможно провести процесс испытания всех входных значений или, другими словами, исчерпывающее тестирование. Следовательно, при процессе тестирования техническая сторона проводимых действий входит в противоречие с экономической выгодой, так как возникает вопрос выбора оптимального конечного количества тестов, которое дает максимально возможный результат (вероятность обнаружения ошибок) при определенных затратах. Существует довольно много примеров, когда написанные тесты были малоэффективны, так как их способность обнаружения новых ошибок была крайне низкой. В то же время, хорошие тесты, обнаруживающие ошибки с высокой точностью, могли остаться без внимания специалистов. Таким образом, принимая решение о количестве времени и проводимых тестов с программой, всегда необходимо принимать во внимание уровень риска, как технического, так и бизнес риска, для отдельно взятого продукта и для всего проекта. Более того, нужно учитывать тот факт, что проект обычно имеет ограничения по времени и бюджету. Анализ результатов тестирования Несмотря на существование различных видов тестирования, процессы тестирования достаточно схожи. Разработкой и анализом тестов может заниматься только тестировщик. За выполнение тест-кейсов так же отвечает тестировщик, однако выполнение этих тестов может производиться как вручную, так и в автоматизированном режиме. По результатам выполнения каждого теста, ему присваивается статус (положительный, отрицательный, блокирован). Если тест получает отрицательный статус, то в зависимости от методологии тестирования тестировщик может проводить дополнительную работу для выявления конкретной ошибки, которая была причиной некорректного поведения программы [4]. При использовании методологии черного ящика, анализ результатов теста сводится к выявлению общих закономерностей, ведущих к появлению ошибки. Однако когда используется белый или серый ящики, тестировщик может проводить гораздо более глубокий анализ причин возникновения ошибки. В зависимости от доступных тестировщику данных (база данных, исходный код программы, логи и т.п.), он способен с некоторой точностью определить источник некорректного поведения программы. После того, как максимально точно выявлена причина нежелательного поведения, тестировщик должен описать её вместе со способом воспроизведения ошибки для дальнейшей передачи этой информации разработчикам. Когда источник ошибки точно определен и хорошо описан, разработчикам гораздо проще исправить эту ошибку. Глава 2. Описание и анализ процесса автоматизированного тестирования Данная глава посвящена описанию автоматизированного тестирования, его типам, выявлению достоинств и недостатков в автоматизации тестирования. Более того в этой главе определены критерии эффективности процесса тестирования, описаны формулы для расчёт экономической целесообразности введения автоматизированного тестирования. Описание процесса тестирования Автоматизированное тестирование представляет собой процесс проверки таких функций, как запуск, инициализация, исполнения, анализа и вывода, производимый в автоматическом режиме. Автоматизированное тестирование осуществляется с помощью специального программного обеспечения и вспомогательных инструментов. Этот тип тестирования решает те же задачи что и ручное функциональное тестирования. Автоматизация процесса тестирования программного обеспечения делает возможным повышение качества тестирования и ускоряет процесс его проведения. Автоматизация тестирования начинается с построения процесса ручного тестирования, а именно, с документации, написанной для такого тестирования. Таким образом, для того, чтобы начать процесс автоматизации тестирования, нужно точно знать, что и как должно быть реализовано. Обычно каждый автоматизированный тест базируется на тест-кейсе для ручного тестирования с повышенным уровнем детализации. Выбор тестов для автоматизации. Для того, чтобы определить, что именно нужно автоматизировать, необходимо сначала оценить целесообразность автоматизации тестирования в условиях проекта. Если автоматизация целесообразна, то, принимая во внимание требования к объекту тестирования, необходимо разработать план, согласно которому автоматизированные тесты будут создаваться. При разработке подобного документа, необходимо четко понимать, что нужно автоматизировать и как именно это реализовать. Автоматизация тестирования обычно позволяет ускорить и удешевить процесс тестирования, однако существуют условия, в которых автоматизация особенно эффективна: Функциональность, которая используется довольно часто и в которой риски от ошибок достаточно высоки. Автоматизация проверки критической функциональности поможет быстрее находить ошибки, следовательно, быстрее их решать. Рутинные операции, например проверка форм, в которых необходимо заполнять большое количество полей. Труднодоступные места в системе, такие как запись в базу данных, бекэнд процессы, логирование. Валидационные сообщения (проверка появления валидации при некорректном заполнении поля) Проверка корректного поиска данных Проверки, требующие точных математических расчетов Длинные end-to-end сценарии И многое другое, в зависимости от инструментов тестирования и требований к системе. Можно выделить три основных вида автоматического тестирования: модульное тестирование (unit test), тестирование API и GUI тесты. Модульное тестирование является самым низким уровнем автоматизированного тестирования. Поиск ошибок осуществляется на уровне функций, методов, процедур. Данные тесты обычно пишутся разработчиками. Тестирование API осуществляет проверку взаимодействия нескольких модулей между собой, или проверяет взаимодействие со сторонними сервисами. GUI тесты - тестирование через графический пользовательский интерфейс. С помощью имитации действий пользователя проверяются такие аспекты, как надлежащее функционирование кнопок и полей, правильное появление диагностических сообщений об ошибках и корректная работа приложения в целом. Написанием GUI тестов чаще всего занимаются тестировщики. Сегодня существует множество средств, позволяющих автоматизировать тестирование программного продукта. Однако автоматизация тестирования не всегда востребована, ведь в конечном итоге может оказаться что разработка и сопровождение систем автоматизированного тестирования обойдется компании дороже, чем труд ручных тестировщиков. При анализе целесообразности создания систем автоматизированного тестирования важно оценить: насколько сложно эту работу выполнять “руками” как часто будут выполняться эти тесты необходимо ли увеличивать скорость выполнения тестов если тесты нужно автоматизировать, то нужно ли это делать со всеми тестами, или достаточно автоматизировать лишь некоторые из них. Основные задачи, которые решаются внедрением автоматизированного тестирования - это снижение времени, нужного для тестирования и повышение качества тестирования. Под повышением качества подразумевается, что автоматизированное тестирование обычно позволяет покрыть большее количество функционала, а также позволяет выполнять тесты, которые невозможно осуществлять вручную. Автотесты также дают возможность минимизировать присутствие человеческого фактора при тестировании. Следовательно, можно выделить основные плюсы и минусы автоматизированного тестирования. Преимущества: Сокращение времени, затрачиваемого на исполнение тестов (относительно с ручного тестирования) Возможность проводить тесты, которые невозможно реализовать без использования программных средств автоматизации. Экспертиза становится более независимой, поскольку исключается человеческий фактор. Недостатки: Автоматизация тестирования может потребовать очень значительных трудозатрат Требуется персонал с гораздо более высокой квалификацией Более сложный анализ результатов Повышение трудозатрат на актуализацию автотестов при изменениях в системе Риск появления ошибок в самом автотесте Не все тесты возможно автоматизировать Критерии эффективности процесса тестирования Процесс тестирования должен быть эффективен в первую очередь с точки зрения компании, в которой он протекает. Компании могут быть интересны следующие параметры процесса тестирования: Время, необходимое для разработки тестов Время, которое занимает один цикл тестирования Квалификация персонала, необходимая для разработки и проведения тестов Изменив любой из этих параметров, компания может повлиять на качество тестирования. Однако важно понимать, что любая комбинация этих параметров может быть выражена в денежном эквиваленте, и, как правило, у любого конкретного процесса тестирования есть оптимальная комбинация, при которой достигается достаточный уровень качества тестирования при минимальных денежных затратах. Автоматизируя процесс тестирования, мы, разумеется, меняем процесс тестирования, а вместе с ним поменяется и оптимальная комбинация перечисленных выше параметров. Например, можно ожидать, что увеличится время, необходимое для разработки тестов и повысятся требования к квалификации персонала, при этом сильно понизится, время, занимаемое одним циклом тестирования. Учитывая, что комбинация параметров стала новой, вероятно поменяется и качество тестирования вместе с его стоимостью. Для того чтобы была возможность дать численный эквивалент эффективности процесса тестирования, предлагается зафиксировать параметр качества на определенном уровне. Тогда численной оценкой эффективности определенного способа тестирования будет являться величина инвестиций, необходимая для того, чтобы он обеспечивал некий определенный уровень качества. Оценка целесообразности автоматизации тестирования производится с помощью подсчета затрат на ручное и автоматизированное тестирование и их сравнение [5], [6]. Точно посчитать финансовую целесообразность автоматизации тестов обычно невозможно, поскольку она зависит от параметров, которые в процессе разработки продукта могут быть лишь примерно понятно (например, планируемая длина жизненного цикла системы или точный список тестов, подлежащих автоматизации). Для расчёта инвестиций, необходимых для внедрения и эксплуатации автоматизированных тестов за выделенный период (Ip), используется следующая формула:  I0 - Оценка стартовых инвестиции, которые состоят из затрат на лицензии необходимого программного обеспечения для разработки автотестов, стоимости дополнительных аппаратных средств и.т.п. C0 - Оценка стоимости разработки и отладки библиотеки автоматических тестов, которая рассчитывается как произведение среднего времени, нужного для написания одного автоматизированного теста одним разработчиком тестов (в часах), умноженное на цену его рабочего часа и на общее количество тестов, которые предстоит автоматизировать. k - Это количество планируемых прогонов тестов (циклов тестирования) за всё оставшееся время жизненного цикла продукта. Ce - Оценка стоимости одного прогона всех автоматизированных тестов, которая рассчитывается как время, необходимое для подготовки к выполнению тестирования, сложенное с средним временем выполнения одного теста одним тестировщиком, умножено на цену рабочего часа и на общее количество тестов. В нашем случае эта переменная принята за 0, поскольку подготовка к циклу тестирования не требуется, а само тестирование не требует дополнительного контроля со стороны работника и происходит полностью автономно. Ca - Оценка затрат на анализ результатов одной итерации цикла автоматизированного тестирования, которая вычисляется как оценка доли отрицательных тестов, умноженная на количество тестов, на среднее время, необходимое для анализа причин отрицательной оценки одного теста одним тестировщиком, и на цену одного рабочего часа тестировщика. Cm - Оценка стоимости поддержания автоматизированных тестов в рабочем и актуальном состоянии. Рассчитывается как вероятность появления необходимости изменения одного теста между циклами тестирования, умноженная на количество тестов, на среднее время, необходимое для актуализации одного теста и на цену одного рабочего часа тестировщика. Оценка стоимости ручного тестирования (Gp) представлена в следующей формуле:  G0 - Оценка стоимости разработки базы тест-кейсов для ручного тестирования. k - Это количество планируемых прогонов тестов (циклов тестирования) за всё оставшееся время жизненного цикла продукта. Ge - Оценка стоимости однократного выполнения цикла ручного тестирования, которая рассчитывается как среднее время, затрачиваемое на подготовку к тестированию плюс среднее время, нужное для выполнения одного тест-кейса одним тестировщиком, умноженное на суммарное количество кейсов и на цену одного рабочего часа тестировщика. Ga - Оценка стоимости анализа результатов для одного прогона цикла ручного тестирования. Вычисляется как оценка средней доли отрицательных тестов в прогоне, умноженная на количество тестов, на среднее время, необходимое для анализа причин отрицательной оценки одного теста одним тестировщиком, и на цену одного рабочего часа тестировщика; Gm - Оценка стоимости поддержания ручных тестов в актуальном состоянии. Рассчитывается как вероятность появления необходимости изменения одного теста между циклами тестирования, умноженная на количество тестов, на среднее время, необходимое для актуализации одного теста и на цену одного рабочего часа тестировщика [7]. С помощью этих формул компания может посчитать, будет ли внедрение автоматизированных тестов экономически оправдано. В следующей главе на конкретном примере будет рассчитана экономическая целесообразность внедрения таких тестов. Глава 3. Автоматизация процесса тестирования В этой главе на конкретном примере будет проверяться гипотеза о целесообразности автоматизации тестирования в компании. Также будут написаны автоматизированные тесты для проверки данной гипотезы на реальных данных. Описание компании Для данного исследования мною была выбрана компания АО «РТ Лабс». РТ Лабс является дочерней компанией ОАО «Ростелеком», который в свою очередь представляет собой единственного исполнителя работ в Российской Федерации по развитию электронного правительства. Будучи подрядчиком «Ростелекома» в области развития электронного правительства и национальной облачной платформы, компания РТ Лабс обеспечивает развитие и поддержку портала государственных услуг https://www.gosuslugi.ru/. В компании РТ Лабс есть большой отдел тестирования, состоящий из 25 специалистов. В отделе есть -------, занимающиеся статическим тестированием, тестированием документации, есть ---- занимающийся динамическим тестированием сайта. Каждую неделю в продуктивную среду выпускаеются исправления и улучшения сайта. Перед выпуском релиза в продуктив, на тестовой среде проводится регрессионное тестирование, для того, чтобы убедиться, что основной функционал сайта не поврежден и в продуктив выйдет корректный релиз. На данный момент регрессионное тестирование состоит из 220 проверок, и ни один тест не автоматизирован. Расчёт экономической целесообразности введения автоматизированного тестирования Для проверки гипотезы о целесообразности автоматизации процесса тестирования в компании необходимо посчитать затраты на ручное тестирование и затраты на автоматизацию. Расчеты будут производится исходя из данных, полученных в ходе опроса работников отдела тестирования в компании РТ Лабс. При опросе было выявлено, что регрессионное тестирование, которое проводится каждую неделю, занимает большое количество времени у тестировщиков и именно этот вид тестирования специалисты данного отдела хотели бы автоматизировать. Для расчета целесообразности автоматизации используются формулы, описанные во второй главе. В ходе опроса были получены данные, необходимые для подсчетов. Оплата тестировщика, занимающегося автоматизацией, оценивается в 600 рублей в час, в то время как оплата ручного тестировщика составляет 500 рублей в час. Данный проект рассчитан как минимум еще на три года. Регрессионное тестирование проводится каждую неделю, но часто случается так, что после исправления критичных ошибок, найденных при тестировании, проверки необходимо выполнять заново. И того, примерно 1.5 прогона в неделю. При тестировании используется 220 тестов. На подготовку к циклу у ведущего тестировщика обычно уходит порядка 45 минут, преимущественно это время тратится на распределение задач между тестировщиками и другие организационные задачи. Среднее время, необходимое одному тестировщику на выполнение одного тест-кейса, составляет 10 минут. При каждом прогоне примерно 5% тестов имеют отрицательные результаты. На определение источника ошибки для каждого теста у ручного тестировщика уходит около 10 минут, в то время как при автоматизированном тестировании анализ ошибки занимает 15 минут. При ручном тестировании тестировщик сразу видит, где именно и при каких входных данных произошла ошибка, а при автоматизированном тестировании эту информацию необходимо искать коде. Вероятность появления необходимости изменения одного теста между циклами тестирования оценена в 3%, Среднее время, необходимое для актуализации одного теста около 6 минут. Для актуализации автоматизированного теста потребуется 30 минут. Автоматизация одного теста оценивается в 3 часа Учитывая информацию, полученную в ходе опроса специалистов отдела тестирования, можно произвести расчет затрат на ручное и автоматизированное тестирование. Формула для расчета затрат на автоматизированное тестирование Начальные инвестиции в данном случае равны нолю, поскольку используется бесплатный стек технологий (IDE, Фреймфорки и прочее) и отсутствует необходимость вкладываться в дополнительное оборудование. Стоимость разработки автоматизированных тестов равна 396 000 рублей (220 тестов * 3 часа * 600 руб/час). Планируемое количество циклов тестирования - 234 раз (3года*52недели*1.5раза) Оценка стоимости однократного выполнения цикла автоматизированного тестирования равна нулю, поскольку подготовка к циклу тестирования не требуется, а само тестирование не нуждается в дополнительном контроле со стороны работника и происходит полностью автономно. Оценка стоимости анализа результатов выполненного цикла автоматизированного тестирования равна 1 650 рублей (220тестов * 0.05 * 0.25часа * 600руб/час) Оценка стоимости поддержания автоматизированных тестов в рабочем и актуальном состоянии равна 1 980 рублей (220тестов * 0.03 * 0.5часа * 600руб/час). Таким образом, итоговая стоимость внедрения и эксплуатации системы автоматизированных тестов равна: 0 + 396 000 + 234 * (0 + 1 650 + 1 980) = 1 245 420 рублей. Формула для расчет затрат на ручное тестирование: Оценка стоимости разработки базы тест-кейсов для ручного тестирования равна нулю, поскольку компания уже обладает базой тест-кейсов Оценка стоимости однократного выполнения цикла ручного тестирования равна 19 075 рублей (0.75 + 220 тестов* 0.17) * 500руб/час. Оценка стоимости анализа результатов для одного прогона цикла ручного тестирования равна 935 рублей (220 * 0.05 * 0.17 * 500). Оценка стоимости поддержания ручных тестов в актуальном состоянии равна 330 рублей (220 * 0.03 * 0.1 * 500) . Итоговая стоимость затрат на ручное тестирование равна: 0 + 234 * (19 075 + 935 + 330) = 4 759 560 рублей. Следовательно, можно прийти к заключению, что на данном проекте автоматизация целесообразна. Далее будут разработаны два автоматизированных теста для проверки данной гипотезы на реальных данных. Внедрение автоматизированных тестов Автоматизация функциональных тестов веб-приложений обычно происходит с помощью специальных программных фреймворков, позволяющих симулировать поведение реальных пользователей из программной среды. Эти фреймворки обычно состоят из 2-х частей: программы или надстройки над браузером, которая позволяет управлять браузером и выполнять команды внутри него и программного API, предоставляющего удобные функции для контролирования этой программы. Ниже описаны основные функции, которые предоставляют подобные фреймворки. Общие функции браузера (Открытие новой вкладки или окна и контролирование их размеров). Навигация между веб страницами. Поиск веб элемента на странице с указанными параметрами. Функции ожидания определенных событий (например ожидание полной загрузки страницы или появления на ней определенного элемента). Симуляция действий пользователя, таких как нажатие кнопки мыши на определенный элемент или ввод последовательности символов с клавиатуры. Для более сложных действий предоставляется возможность исполнять JavaScript команды на странице. Автоматизировать ф тесты можно с помощью различных программных фреймворков. Есть большое кол-во инструментов для автоматизации функц тестирования основные из которых Selenium WebDriver, Watij HtmlUnit Jamaleon. Мною был выбран Selenium WebDriver, поскольку он в отличие от других фреймровков позволяет выбрать язык программирования для реализации тестов (большинство остальных фреймворков позволяют использовать только Java), способен работать со всеми браузерами и обладает максимально богатым функционалом с точки зрения функционально тестирования. Из предоставляемых Selenium WebDriver возможных языков программирования для реализации тестов (Java, C#, Ruby, Python) был выбран C#, поскольку на момент написания данной работы мною был накоплен больший опыт использования этого языка чем других. При практическом применении автоматизированных функциональных тестов очень быстро обнаруживается что тестирование каждого отдельного веб приложения обладает своей спецификой. Это подталкивает к созданию дополнительного программного слоя между фреймворком для тестирования и самими автотестами. Такой подход позволяет минимизировать количество повторяющегося кода путем вынесения его в функции этого слоя, что положительно сказывается на скорости создания автотестов, понижает вероятность возникновения ошибок и улучшает удобочитаемость кода. Обычно такие промежуточные API содержат утилиты и классы, позволяющие оперировать более высокоуровневыми сущностями, существующими в контексте конкретного веб приложения. Часто в автотестах может понадобиться протестировать функционал, для которого необходимо авторизоваться, найти типичный для всех страниц приложения элемент, сделать прямой запрос к базе данных чтобы сверить данные с представленными на сайте и т.д. Такие действия будут регулярно выполняться из автотестов, при этом если не вынести их в отдельное API они будут только загромождать код, поскольку занимают много места и не имеют прямого отношения к конкретному тест кейсу. Ниже представлены реальные тест-кейсы для тестирования сайта Госуслуги в компании РтЛабс, описанные в программе TestLink. Данный тест проверяет работу технической поддержки сайта. Для проверки данного функционала необходимо отправить сообщение в службу поддержки сайта и проверить, что отправленное сообщение отображается в личном кабинете. Далее идет проверка на возможность отправить сообщение в службу поддержки со страницы личного кабинета и возможность отправить второе сообщение по ранее созданному. В данном тест-кейсе также есть проверка на корректную работу поиска на странице технческой поддержки в личном кабинете пользователя.
Этот тест проверяет работоспособность всех вкладок на странице «Лента уведомлений» в личном кабинете пользователя, работоспособность фильтра и поиска на странице ленты уведомлений.
Далее представлена реализация описанных выше тестов. Тест, который проверяет отправку сообщения в службу поддержки и отображение данного сообщения в ЛК пользователя. Переход на страницу «Лента уведомлений», вкладка «Техподдержка» WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?type=FEEDBACK"); Ожидание появления элемента «Создать новое сообщение» и последующее нажатие на него WebDriver.Chrome.WaitUntilElementVisible(By.CssSelector("#content>div.ng-scope>div>ng-include>div>fieldset>ul>li.feedback-button.ng-scope>a")).SafeClick(); Заполнение формы обратной связи WebDriver.Chrome.WaitUntilElementVisible(By.Id("_epgu_el2")).SafeClick(); WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"feedbackForm\"]/div/div/div/div[2]/ul/li[4]")).SafeClick(); WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"feedbackForm\"]/div/div/ng-include/epgu-input[1]/div/textarea")).SendKeys("TEST"); WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"feedbackForm\"]/div/div/ng-include/epgu-input[1]/div/textarea")).Submit(); Фиксация время отправки сообщения DateTime time = DateTime.Now; Ожидание появления элемента «Вернуться к списку» и последующее нажатие на него WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/div/div/div[4]/a")).SafeClick(); Ожидание появления сообщения с совпадающим временем отправки и последующее нажатие на него WebDriver.Chrome.RefreshUntil(_ => _.FindElements(By.ClassName("advice-datetime")).Any(a => a.Text.Equals(time.ToString("dd.MM.yyyy HH:mm")))); WebDriver.Chrome.FindElements(By.ClassName("advice-datetime")).First(_ => _.Text.Equals(time.ToString("dd.MM.yyyy HH:mm"))).SafeClick(); Создание уникального сообщения для отправки дополнительного сообщения Guid guid = Guid.N Отправка дополнительного сообщения WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/ng-include/ng-include/div/div[2]/form/div/div[1]/div[1]/textarea")).SendKeys(guid.ToString()); WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/ng-include/ng-include/div/div[2]/form/div/div[1]/div[1]/textarea")).Submit(); Ожидание отображения отправленного сообщения в окне переписки WebDriver.Chrome.WaitUntilElementVisible(By.ClassName("event-text")); Проверка совпадения текста сообщения с отправленным ранее Assert.IsTrue(WebDriver.Chrome.FindElements(By.ClassName("event-text")).Any(_ => _.Text == guid.ToString()), "No message recieved");} Тест, который проверяет функцию поиска на странице техподдержки. Переход на страницу «Лента уведомлений», вкладка «Техподдержка» WebDriver.Chrome.NavigateToUrl("http://lk- dev.test.gosuslugi.ru/notifications?type=FEEDBACK"); Ввод определенного текста в поле фильтрации сообщений string searchText = "отзыв"; WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/ng-include/div/fieldset/ul/li[1]/dl[2]/dd/input")).SendKeys(searchText); Ожидание пока все отсортированные сообщения не будут содержать введенный в фильтр текст WebDriver.Chrome.WaitUntil(_ => _.FindElements(By.ClassName("highlighted")).All(a => a.Text == searchText));} Тест, который проверяет работоспособность всех вкладок Личного кабинета Переход на страницу «Лента уведомлений», вкладка «Все» WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?type=all"); WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item")); Поочередный переход на все вкладки на странице «Лента уведомлений» WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?type=PAYMENT"); WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item")); WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?type=ORDER"); WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item")); WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?type=DRAFT"); WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item")); WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?type=FEEDBACK"); WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item"));"); Переход на вкладку «Все» и ввод в поле фильтрации определенного текста WebDriver.Chrome.NavigateToUrl("http://lk-dev.test.gosuslugi.ru/notifications?type=all WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/ng-include/div/fieldset/ul/li/dl[2]/dd/input")).SendKeys("35"); Ожидание появления результатов фильтрации WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-item")); Проверка правильности фильтрации сообщений Assert.IsTrue(WebDriver.Chrome.FindElements(By.ClassName("highlighted")).All(_ => _.Text == "35")); Очистка поля фильтрации WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/ng-include/div/fieldset/ul/li/dl[2]/dd/input")).Clear(); Фильтрация сообщений по дате WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"_epgu_el1\"]/div[1]")).SafeClick(); WebDriver.Chrome.WaitUntilElementVisible(By.XPath("//*[@id=\"content\"]/div[2]/div/ng-include/div/fieldset/ul/li/dl[1]/dd/div/div[2]/ul/li[5]")).SafeClick(); WebDriver.Chrome.WaitUntilElementExists(By.ClassName("advice-datetime")); Проверка соответствия даты на всех элементах с датой фильтрации Assert.IsTrue(WebDriver.Chrome.FindElements(By.ClassName("advice-datetime")).All(_ => (DateTime.Now - DateTime.Parse(_.Text)).Duration().Days == 0)); После того как были автоматизированы несколько тестов, описанных выше, можно сделать вывод о целесообразности автоматизации в контексте компании РТ Лабс. Разработка автоматизированных тестов состояла из двух этапов: разработка промежуточного слоя между фреймворком для тестирования и самими авто тестами, и разработка автоматизированных тестов. На первый этап ушло около 16 часов рабочего времени, а на второй около 8. При этом было разработано 2 масштабных теста. При расчете затрат на автоматизированное тестирование по данной формуле Используя вышеописанные формулы можно рассчитать величину вложений, нужных для реализации автоматизированного и ручного тестирований. Для автоматизированного тестирования необходимы затраты в 22 122 рублей. Для ручного тестирования - 43 269 рублей. Таким образом, автоматизировав всего 2 теста, была получена выгода почти в два раза, при этом, можно ожидать, что последующая автоматизация тестирования приведет к еще большей разнице в эффективности, поскольку этап разработки промежуточного слоя уже пройден (хотя, однозначно по нему потребуются доработки при использовании в реальной компании). Такая большая разница в эффективности очень показательна, однако нужно понимать, что в зависимости от конкретного проекта и рассматриваемого типа тестирования улучшение эффективности за счет автоматизации может меняться, и в ряде случаев автоматизация может оказаться нецелесообразной. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||