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

В статье предполагается что у вас уже созданы билдагенты и настроен Version Control Settings

Для начала следует создать темплейт в тимсити для вашей конфигурации

1) Для этого нужно перейти в раздел Администрирования

2) Заполнить имя и нажать «Создать»

3) Приаттачить VCS Root и Выбрать билд агент в Agent Requirements

4)Заполнить General Settings и Build Step (создать 2 степа на ребилд проекта и на запуск)


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

Читать дальше →

QA (Quality Assurance) — это совокупность мероприятий, охватывающих все этапы разработки ПО включая эксплуатацию и релиз, которые предпринимаются на разных статиях жизненного цикла ПО, главной целью которого является обеспечение качества выпускаемого продукта. QC — одно из мероприятий в QA.



QC (Quality Control) — это совокупность мероприятий, которые проводятся в процессе разработки ПО, для получения исчерпывающей информации о соответствии тестироемого продукта поставленным изначально требованиям. В QC входят Test Management, Test Analysis, Test Design и другие.

Перед тем как приниматься к тестированию веб приложения, тестировщику следует понять какие виды тестирования следует провести над этим приложением. В большинстве случаев сам заказчик выбирает и просит тестировщиков провести типы тестирования, которые его интересуют и на которые он может выделить деньги. Но если такого решения от заказчика или продакт овнера не поступило, то как высококвалифицированные тестровщики мы должны сами определить какие виды тестирования выполнять над приложением.

Как самостоятельно определить какие виды тестирования провести?

Существуют различные типы веб приложений, такие как банковские клиенты, системы по подсчету статистики, интернет магазины, ресурсы по обучению. Для каждого из типов приложений всегда есть критические модули и юз кейсы, которые используют большинство пользователей. Для банковского приложения тестирование секьюрити будет намного более критично чем для какого-нибудь приложения опросника. Для второго скорее всего секьюрити тестирование проводится даже и не будет. Более важный приоритет здесь в точности подсчетов и понятности интерфейса.

В какой очередности по видам тестирования следует проводить тестирование веб приложения?

Здесь все просто и логично. Допустим после долгих переговоров с продакт овнером был выделен бюджет на проведение трех видов тестирования над веб приложением таких как Функциональное (Functional testing), Юзабилити (Usability testing) и Секьюрити (Security testing)

Что следует проводить первым?

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

Читать дальше →

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



Статистический этап предусматривает процедуру обнаружения дефектов тестируемого продукта без непосредственной проверки ее работоспособности на машине. Тестирование предусматривает выполнение следующих действий: выявления и рассмотрения тех требований, которые предъявляются к тестируемой системе (изучение проектов, сопутствующей документации, а также определение главных функциональных требований к программному продукту в целом); разработка хода испытаний (определение со стратегией тестирования, содержанием тестируемой системы, утверждение плана исследований); проектирование тестов (выявление цели тестов, их конфигурации, изучение методики проведения, формирование тестовых кейсов).

Читать дальше →

Тестирование кроссбраузерности — вид тестирования, направленный на поддержку и правильное полное отображение программного продукта в разных браузерах, мобильных устройствах, планшетах, экранах различного размера.
Кроссбраузерное тестирование (cross-browser testing) — важный этап при разработке любой программы. Ведь внешний вид сайта и его корректное отображение на любом современном устройстве играет определяющую роль для заказчика.

Особенности кроссбраузерного тестирования

Cross-browser testing сайта начинается с выбора браузеров. Заказчик сам определяет, с какими именно веб-обозревателями будет работать его приложение. Но задача разработчика и тестировщика — подсказать клиенту, какой браузер будет главным, следует изучить статистику заходов подобных приложений, определить какими браузерами пользуется такая аудитория.
Как правило, рассматривают самые популярные браузеры: Google Chrome, Mozilla Firefox, Internet Explorer, Opera.

Основные моменты для тестирования: вёрстка (цвет, шрифты, расположение графических картинок и динамических элементов) и JavaScript.
Следует отметить, что кроссбраузерное тестирование необходимо выполнять когда система стабильна и весь функционал отлажен, иначе будут возникать ошибки, которые не являются кроссбраузерными. Это чревато лишними финансовыми затратами.

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

Многим тестировщикам известны случаи незавершенного (неполного) тестирования сайтов, что практически всегда приводит к немалым финансовым затратам, недовольству заказчиков, и, в конце концов, к повторной разработке портала.
Для организации качественного тестирования web-ресурса рекомендуем придерживаться специальной методикию

Подготовительная фаза тестирования сайта

Специалист–тестировщик на основании полученной документации, составляет тест-план (Test Plan).

Функциональное тестирование

Самая трудоемкая часть опробования ресурса. На этом этапе тестируются все функциональные требования программного продукта, работа ссылок, поиск нерабочих гиперссылок. Идет проверка подгрузки файлов на сервер, работы счётчиков на страницах портала, пользовательских форм (к примеру, контакты, обратная связь, подписка, добавление сообщений и т.д.). Проверяется, соответствует ли содержимое страниц сайта исходнику.

Тестирование верстки

При испытании верстки проверяем в строгой последовательности:

• расположение элементов, соответствуют ли они своим макетам,
• оптимизацию графических изображений,
• валидность кода,
• кроссбраузерность (как работает веб-площадка в различных браузерах).

Usability Testing

Другими словами, степень удобства работы пользователя с программным продуктом. Usability тестирование основывается на привлечении в качестве тестировщиков пользователей, анализируются все результаты и мнения.

Тестирование безопасности

На этом этапе тестировщик занимается проверкой защиты всех закрытых страниц.
Performance Testing (Тестирование производительности)
Задача — определить скорость работы сайта при заданной нагрузке. Здесь применяют нагрузочное тестирование (Load Testing) и тестирование быстродействия.

Читать дальше →

Mutation Testing предполагает запуск незначительно поврежденных версий разрабатываемой программы.
Мутационное тестирование включает в себя изменение исходного кода программы или внесение в программу мелких ошибок-мутантов. Вносимые ошибки настолько незначительны, что на общие цели программы они не влияют. Затем целевая программа и программы-мутанты тестируются одними тестами.



Набор тестов, который не обнаружил и не отклонил мутировавший код, считается бракованным.
Цель Mutation Testing состоит в том, чтобы помочь тестеру разрабатывать эффективные тесты или найти слабые места в тестовых данных, используемых для программы.

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

Преимущества мутационного тестирования ПО:

• этот метод позволяет охватить всю исходную программу,
• всесторонне тестируются программы-мутанты,
• тестирование раскрывает все неясности в исходном коде.

Из недостатков отметим:

• мутационное тестирование — чрезвычайно дорогостоящий и трудоемкий процесс, поскольку все программы-мутанты, которые должны быть сгенерированы,
• этот вид тестирования должен быть автоматизирован,
• поскольку этот способ предполагает изменения в исходном коде, это не применимо для тестирования черного ящика.

Итак, Mutation Testing — наиболее универсальный метод тестирования программного продукта.

Необходимость в тестировании мобильных приложений стремительно растет, но в этой сфере еще немало сложностей и вопросов. От стандартного тестирования ПО Testing Mobile Technologies отличается рядом определенных требований. Тестирование мобильных приложений подразумевает тестирование:

• самого мобильного устройства
• специальных приложений
• мобильных web-приложений.

В чем специфика функционирования мобильных приложений?

Во-первых, мобильные сервисы должны правильно работать в любом месте, в любых условиях. Они должны поддерживать различные мультимедийные технологии, функции управления голосом, жестами, время их работы зависит от батареи, отличаются операционными системами, размером экрана. Наконец, функционируют в беспроводных сетях Wi-Fi, 2G, 3G, 4G, WiMax.

Что тестировать в мобильных приложениях?

• тестирование функциональности приложения (дается оценка сервисных функций, пользовательских интерфейсов),
• испытание QoS — выполняется проверка нагрузки на систему, производительности, пропускной способности,
• тестирование пользовательского интерфейса, позволяет опробовать мультимедийный контент, графику, функцию распознавания голоса, жестов,
• проверка способности системы работать в разных условиях, браузерах, беспроводной среде,
• тестирование безопасности (соблюдение конфиденциальности при идентификации пользователей, сохранность сведений),
• тестирование мобильности, подразумевает исследование функций географического положения клиента, его профиля и АРІ. К примеру, это информация о авиа-, ж/д рейсах, карты местности и т.д.
• тестирование совместимости (проверка соединения между пользователем и сервером, подключение к Интернет, работа в беспроводных сетях).

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

Главным заданием тестировщика программного обеспечения является поиск и документирование ошибок с последующим процессом их устранения для дальнейшей более качественной работы тестируемого продукта.

В том случае если программная продукция генерируется по заказу определенного потребителя, который может непосредственно принимать участие в его проектировании, вопрос о качестве готового продукта определяется уровнем его соответствия спецификации, указанной самим заказчиком.



Вместе с тем, грамотных в отношении спецификации тестируемого приложения клиентов практически не бывает, поэтому тестировщики должны ориентироваться в первую очередь на то, будет ли доволен заказчик готовым продуктом.
Другим критерием качества тестирования является надежность тестируемого объекта, которая определяется частотой происходящих сбоев в работе программы. Несмотря на важность данного критерия, заказчики даже при высоких показателях надежности не будут довольны программным продуктом в случае невозможности выполнения с его помощью важных именно для них операций.

Таким образом, качество тестируемой программы наиболее рационально определять, ссылаясь на следующие маркеры:

• преимущества, благодаря которым она понравится заказчику и потенциальным потребителям;
• недостатки, наличие которых обусловит ситуацию отказа клиента от этой программы и приобретение другой.
• полное выполнение требований заданных заказчиком в спецификации

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

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

Первый вопрос, на который следует ответить беспристрастно и непредвзято звучит так: «Насколько целесообразно использование автоматизированного тестирования для данного программного продукта». При положительном ответе на поставленный вопрос, нужно определить выдвигаемые к проекту требования и спланировать шаги по разработке тестов для автоматизации проверок.



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

Какие модули и места следует подвергать автоматизации?

1. Участки кода, исполнение которых трудно визуализировать и получить осязаемую информацию о протекающих процессах (back-end процессы, занесение в базу данных, занесение логов в файл).
2. Функциональность продукта, которая будет использоваться наиболее часто и возникновение ошибок которой связано с достаточно высоким риском. Автоматизированное тестирование узловых моментов функциональности потребует меньше времени для поиска ошибок. И соответственно, сократит время на их устранение.
3. Типовые часто выполняемые операции, которые обычно связаны с обработкой данных. Например – формы, в которых количество заполняемых граф и полей довольно значительное. Цель – автоматизировать занесение требуемых данных в нужное поле и проверить правильность выполнения задачи после сохранения результата.
4. Сообщения об ошибках. Требуется автоматизация разнесения некорректных данных по соответствующим полям и тестирование корректности проверки правильности данных и сообщений об ошибках.
5. Комплексная проверка поведения всей системы, как целостного объекта (end-to-end testing).
6. Проверка числовых массивов, нужных для достоверных математических операций.
7. Тестирование корректности отображаемых результатов поиска в ответ на запрос по нужным данным.
8. Предложенный список только ориентировочный. Всё зависит от предъявляемых к проверяемой системе требований, возможностей, которые позволяет реализовать выбранный для автоматического тестирования инструмент.

Читать дальше →