Форум Сообщества Аналитиков

×


Автоматизированное тестирование + и -(Прочитано 16349 раз)
Волею случая пришлось мне крепко заняться и погрузиться в процесс тестирования. До этого совершенно не обращал внимания на эту тему. Не то, что полагал ее слишком заумной или наоборот совершенно обычной, просто по роду занятий не было особой нужды сталкиваться.

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

Однако оказалось не все так просто. Для начала с некоторыми элементами тестирования (зная, что мне это предстоит) я начал знакомиться еще на TrainingLabs. Правда сразу попал на тренинг управление рисками тестирования.

В целом мой сегодняшний опыт - 2,5 недели. Получилось так, что сразу начал изучения с инструмента по созданию тестов TestComplete. Обложился кучей книг: Тамре, Канер, Бейзер, Рэшка и т.п. Всего аж 5 книг + статьи, презентации, хелп TestCompleta.

Не знаю много или мало это 2,5 недели, чтобы получить определенные знания и начать работать. Возможно и достаточно для определенных целей.
По крайней мере, имею такой навык:
1. создание довольно гибких скриптов по тестовым сценариям на TestComplete
2. запуск тестовых заданий по расписанию в автоматическом режиме с аккуратной в нужное место записью логов прохождения тестов, посылкой сообщения и даже самого лога по почте
3. понял и настроил тестовый стенд
4. приступил к разработке набора шаблонов документов по тестированию
5. немного разобрался какие тесты бывают, каково назначение тестирование, каково его место в общей системе качества проектных решений, каково место его в процессе разработки
6. понял также, что у большинства окружающих очень скептическое мнение по поводу автоматизированного тетстирования и вообще тестирования в целом
7. понял, что в реальной практике работ часто требуется объем работы, а не его качество. И если ты бьешься целый день над возможностью получить результаты из прохождения теста сразу на почту в аккуратно расфасованном виде и с предварительым интеллектуаьным парсингом, но при этом сделан только один два простеньких теста, то тобою будут не очень довольны :)
8. понял, что тестирования штука столь же сложная как и любой другой этап или дисциплина проектирования
9. услышал множество строго диаметральных мнений: одна группа утверждает, что автоматизированное тестирование лажа, но при этом по сути не имеют сами никакого положительного или отрицательного опыта его использования, другая (это в основном авторы книг) очень положительно отзываются о таком подходе. Бейзер вообще утверждает (у него 40 летний опыт работы в ИТ), что ручное тестирование похоже на всадника бегущего перед мчашимся локомотивом - выглядет смешно и неудобно. Мол тестирование следует сводить у автоматизированному однозначно, все остальное ересь и глупость.

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

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

Общее количество возможных сочетаний параметров велико, правда я затрудняюсь ответить сколько (надо вспонимать наверное математики). Скажем так пусть есть 20 параметров так или иначе влияющих на результат формирования счета. Каждый параметр либо активен либо дезактивен. Какое количестве входных сочетаний должно быть для покрытия всех возможных ситуаций?

В принципе, если удасться сделать один единый скрипт, а только менять входные параметры и сопоставлять выходные результаты с известными и достоверными, то можно все 2000 клиентов прогнать. Правда тут есть трудность: сравнение результатов будет осуществляться сравнением скриншотов или регионов. Т.е. по каждой компании делает снимок счета (из формы перваритьельного просмотра) и при прогонке теста такие скриншоты сравниваются. Тут как вы понимаете трудность именно в получении всех этих 2000 скриншотов. Даже если тратить на сохранение такого скриншота примерно 2 минуты (найти нужного клиента, вызвать его форму его счета, вызвать форму предварительного просмотра, сделать чек-поинт региона, задать имя для региона, сохранить), то очевидно для охвата всех 2000 компаний нужно 4000 минут или 67 часов или примерно 9 рабочих дней, а реально в два раза больше, т.е. три недели как минимум.

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

Зато, конечно, появляется выгода, если в последствии такой скрипт запустят как минимум раз 10. Он гораздо быстрее просканирует задачу, чем бы это делал человек. Это можно выполнить ночью, к примеру. Правда все-таки остаются но.

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

Ясно, что устремленность  на автотестирование только малоперспективна и вряд ли возможна. Кроме того если сейчас я начелен на ГУИ тесты, то ясно, что следует вовлекать более устойчивые к изменению тесты, например сделав некоторые манипуляции в ГУИ, осуществить выборку требуемых данных из БД и сравнить из с контрольными.

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



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

И сейчас остаётся такое мнение. Предвзятое, но массовое.

К нам приезжал в прошлом году наш Главный Босс из Кореи - основатель и владелец компании. (Для справки: в Корее у нас целый Research and Development Center, в котором трудится человек сто. Причём он существует уже лет пятнадцать.) Так когда мы ему показали нашу организационную диаграмму (ну, это звучит слишком гордо для офиса из шести человек), он долго не мог понять, что такое TESTER. Чем этот человек занимается?

Вчера общался с бывшей коллегой. Она проработала восемь лет тестировщиком, а сейчас её типа повысили, руководить QA. Спрашиваю: кто, кроме тебя, занимается тестированием? Ответ: "еще есть студентка Аня, которая работает 30 часов в неделю, еще была Катя (не совсем вменяемая) и ее уволили".

Бейзер вообще утверждает (у него 40 летний опыт работы в ИТ), что ручное тестирование похоже на всадника бегущего перед мчашимся локомотивом - выглядет смешно и неудобно. Мол тестирование следует сводить у автоматизированному однозначно, все остальное ересь и глупость.

Он, наверное, и не подозревает, что есть ещё идиоты, разрабатывающие embedded приложения на голом "С" для экзотических аппаратных архитектур.

Общее количество возможных сочетаний параметров велико, правда я затрудняюсь ответить сколько (надо вспонимать наверное математики). Скажем так пусть есть 20 параметров так или иначе влияющих на результат формирования счета. Каждый параметр либо активен либо дезактивен. Какое количестве входных сочетаний должно быть для покрытия всех возможных ситуаций?

А сколько возможных значений у каждого параметра? Без этого я не могу посчитать точное количество комбинаций. ;)

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

Собственно, это то, к чему мы сейчас пришли (наиболее очевидный подход, который всегда становится очевидным только в конце пути). :) Вместо того чтобы искать формальное покрытие, можно взять несколько (5-10) разных реальных и не тривиальных задач с известными правильными результатами и использовать их в качестве контрольных примеров.

Помнится, когда я ещё служил в лётно-испытательном центре, мне пришлось изучать один талмуд с названием "контрольный пример Главного конструктора". Все испытания комплекса обязательно включали выполнение этого примера - если выходные результаты совпали, значит, есть шанс, что ракета полетит туда, куда нужно, а не туда, куда ей хочется. :)
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Даааа, надо бы наших руководителей отправить на производство сложных агрегатов (машины, самолеты, ракеты ...), чтобы поняли что такое качество.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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



А сколько возможных значений у каждого параметра? Без этого я не могу посчитать точное количество комбинаций. ;)
так или иначе все параметры можно свести к двум значениям - есть или нету :)
скажем период биллинга может быть месяц квартал полугодие или год - тут 4 возможных значения, остальные чаще всего 2, например НДС - брать не брать, Скидка - есть- нету, Кто платит - головная организация или сам, Выставлять счет -  да - нет, Создавать акт да - нет
Кроме того, ряд установленных параметров автоматом дезактивируют некоторые другие. Так что мне бы хотя бы формулу для оценки.

Скажем есть 20 параметров с 2 возможными значениями.
А вообще правила там запутанные + еще и запутанная реализация
« Последнее редактирование: 28 Июля 2008, 22:49:28 от Galogen »



Коллеги с опытом тестирования, особенно автоматизированного, как положительного, так и отрицательного. Отзовитесь, поделитесь чем можете?

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

Делать один достаточно объемный скрипт и подавать на вход большой объем?
Или
Создавать достаточно небольшие скрипты,  решающие мелкие (в идеале атомарные) задачи. А скрипты набирать в некие сценарии или маршруты тестов?

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

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

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

Третье, что мне кажется стоит делать, это чтобы, скрипты как бы пересекались в своих действиях, и таким образом перекрывали задачу.



Re: Автоматизированное тестирование + и - Ответ #6 : 06 Апреля 2009, 15:00:33
Да знакомая мне тема "Автоматизированное тестирование".

Попробую изложить собственный мысли по данной тематике.

Как мне кажется то автоматизированные тесты надо писать на стадии разработки.

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19