В поиске решения

В очередной раз пытаюсь найти решение, связанное автоматизацией регрессионного тестирования. Главная проблема состоит в том, что у нас Flash-приложение. Селениум тут пассует сходу - он не видит флеш от слова "совсем", для него это просто черная дыра (или же я чего-то не знаю о Селениуме), TestComplete тоже сказал что он конечно может нам наклацать по заданным координатам, но ребята, вы же понимаете, да?.. Чуть лучше оказался Sikuli и я было воодушевилась, но все оказалось тоже не так просто - слишком много завязано на графику, а чуть только меняется цвет/масштаб/задержка, все летит в тартарары и приходится переписывать тест. Написание оного, между тем, даже самого простого, с отладкой и корректировкой задержек, занимает никак не менее получаса. В общем, я опять выкусила и плюнула. Теперь у меня очередной виток - жутко надоело проклацывать одно и тоже в то время, когда новые функции проверены только в рамках позитивных тестов. Нет времени поэкспериментировать, покрутить как хочется. Начала снова рыть (я не скажу вам куда меня посылали гугль и яндекс по запросу "автоматизация тестирования flash"), но нигде конкретной информации на эту тему не нашла, увы. Пошла на форум по автоматизации, мучаю теперь старожилов. Посоветовали Роботекс (Robotex), но кроме забавной рекламы в нем я не нашла ничего. С запуском сего шедевра у меня комп начал тормозить так, будто я ему запустила 8 ослов и каждую с флешем. Ну и даже в таком режиме он что-то честно попытался записать, но увы и ах: еле-еле передавал инфу дальше своих нужд. Закрытие окна в игре длилось не меньше минуты. В общем, не подошел. Теперь на форуме разгребаю другие, более трудоемкие решения. Удивляюсь как до сих пор нет готовых решений для столь распространенной ситуации - флешевых игр в соцсетях тьма, неужели их все тестируют руками?
P.S. Если разберусь с этим зверем и найду решение - обязуюсь написать статью по этому вопросу.

Теоретика и рабочие моменты

Во-первых, нашла наконец приличные учебные материалы, а не просто "как я тестировал то-то" и спешу поделиться. Это - материалы подготовки к сертификации ISTQB. Вот тут материалы подготовки по всем уровням, для базового - есть на русском языке, в т.ч. есть глоссарий - там выписаны все определения, каноничноЪ. Это, повторюсь, первый встреченный мною нормальный учебный (именно учебный, практически учебник) материал. Как преподаватель говорю :) Это не значит, что публикации корифеев читать не нужно и бесполезно - вовсе нет - чужой опыт ценен, а если вы сможете адаптировать его к собственным нуждам - бесценен. Но экзамен (или сертификацию) вы по нему не сдадите. Что касается сертификации тестировщиков как таковой, то мое отношение к ней такое же, как и к любой другой бумажке с курсов - это иногда помогает пустить пыль в глаза недалеким людям, но сам по себе сертификат особо ничего не значит. Он значит лишь то, что вы знаете теорию, а об умении применять ее на практике там практически ни слова, так, пара тестов. Где-то я вычитала фразу, что сертфикация в общем нужна лишь тебе самому - проверить свои сил, знания. И с этим я более чем согласна, но бывает человеку это и не надо. Я пока еще думаю буду ли я сдавать на нее, но скорее да - потому что у нас компания заинтересована в сертифицированных тестировщиках. На черта, правда, не знаю, но если начальство говорит: "Лягушка" - то надо прыгать :) Опять же - не нужно понимать эту фразу буквально - разумеется, требования начальства необходимо выполнять в разумных пределах, до тех пор, пока это не ущемляет какие-то личные права/свободы. Расползаюсь что-то, но в любом случае, я полагаю небесполезной будет информация о том, как это проходит. Даже если вы не собираетесь сдавать - рекомендуется к ознакомлению.
А теперь о рабочих моментах, в частности - о баг-репортах. И нет, не о их составлении. А, любите Родину, мать вашу! - об их чтении! Я понимаю, что данная ситуация не показатель вообще, конец пятницы, мы все устали - но бывает вот такое. Составленный четче некуда баг-репорт (не мной даже, начальник клепал давно, решили повысить приоритет после жалобы в FAQ'е) и вопросы от программиста: а что, а как, а так где мне это делать? Где?! В гнезде!!! Мы все знаем, что у нас игра (программа), так ГДЕ ты должен это воспроизводить? В баг-репорте важно _каждое_ слово, это документ (конечно, бывает я делаю спецом забавные опечатки - чтоб чуток развеять официоз), тут ничего не пишется просто так. Но нет, Коля молодец, он взял последний абзац (не вникая в описание), который как раз относился непосредственно к описанной ситуации - и говорит - не, у меня все работает! Это слава яйцам, мы сидим в одной комнате, я могу подойти, ткнуть пальцем и показать что именно он пропустил. А если бы это было "программист тут, тестер - там"? Мы бы запинали этот тикет до посинения и взаимной ненависти. В общем, я что хочу сказать - иногда если программист не понимает баг-репорта, это не обязательно значит, что тестировщик его плохо написал. Просто программисты тоже люди и могут что-то в описании - одно слово! - прошляпить. А это одно слово может быть определяющим. Так что учитесь сами писать верно и учите верно читать.

Савин+Тамре. Генерация тестовых случаев

Савин.
Методы генерации тестов:
1. Черновик-чистовик. Локальный мозговой штурм. Цикличен.
2. Матричная раскладка.
Этапы: набросок элементов и комбинация элементов.
В примере рассматривалось тестирование полей ввода индекса:

3. Блок-схемы.
Методы отбора тестов.
1. Оценка рисков. Какие из тестов будут исполнятся в первую очередь исходя из ситуации, оценку должны производить профессионалы, т.к. "на первый взгляд логично..." очень часто приводит к противоположенным результатам без знания нюансов.
2. Эквивалентные классы.
3. Граничные значения (возможно, как частный случай эквивалентных классов).
Тамре.
Я уже писала подробно, выпишу ещё раз вкратце.
Категории тестов.
• нет данных
• повторный ввод данных
• верные данные (значения внутри диапазона)
• неверные данные (граничное значение +/- 1)
• сброс/отмена/дисконект ~ стрессовое тестирование
• создание напряжений в системе ~ нагрузочное
• тестирование характеристик ~ функциональное
Знать как отченаш.

Савин-3

Цикл разработки ПО, модель "Водопад" (Waterfall)
1. Идея - маркетинг, описание цели.
2. Разработка дизайна и создание спецификации - путь к цели.
Must be спецификации:
• акцент на деталях и их чёткое определение
• недопущение неверного толкования (предельная чёткость формулировок)
• непротиворечивость
• логическая взаимосвязь компонентов
• полнота охвата предмета
• соответствие нормативным актам
• соответствие деловой практике/этике
Стадии: Черновик --> Ожидает подтверждения --> Утверждён
макеты с иллюстрациями спецификаций
3. Кодирование.
Внутренний дизайн кода
Причины возникновения багов:
• некачественная или изменяющаяся спецификация
• личные качества программиста
• отсутствие опыта
• пренебрежение стандартами кодирования
• сложность системы
• баги в ПО сторонних лиц
• отсутствие юнит-тестирования
• сжатые сроки разработки
Причины ликвидации соответствующие.
Требования к юнит-тестированию: юнит-тесты планируются ДО написания кода; требования к ним должны быть сформулированы в стандартах.
4. Исполнение тестирвоания и ремонт багов.
Приоритет:
-тестирование новых компонентов
-регрессионное
5. Релиз.
Виды: релиз, дополнительные релиз, пач-релиз
Бранчи.
А вот почему "водопад":

Савин-2. Виды тестирования.

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

Конспект Савина

Вряд ли, к сожалению, мне поможет Selenium - по крайней мере IDE не записывает действия во флеше.
И как бы я не не любила Савина, читать придётся. Ибо эбо.
Итак, тест кейсы по Савину. Я уж не буду снисходить до уровня детсада как это делает Савин и пудрить мозги тупыми конкретными примерами, воспользуюсь определением с простестниг'а: Тест-кейс (тестовый случай) - это прописанная совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. В виде таблицы представляется полями Действие (Action), Ожидаемый Результат (Expected Result) и Фактический Результат (Result). На практике (моей) используется поле с фактическим результатом, а отметку о том пройден тест кейс или провален ставят в чек-листе (check list). Так же необходимыми атрибутами тест кейса являются поля с предусловием (состояние системы на начало выполнения тест кейса, по Савину "SETUP and ADDITIONAL INFO"), кратким описанием (summary или IDEA по Савину) и уникальным номером - ID. Так же в тест кейсе может быть указан его приоритет (по Савину), однако чаще всего приоритет фигурирует в баг репорте (Bag Report) - отчёте о найденом баге (проваленном тест кейсе). О нём я ещё буду писать. Так же Савин предлагает вести историю изменений тест кейсов (я бы уточнила - тест сьюитов (test suite) как комплекта тест кейсов), это кажется разумным. В целом, я бы оформляла тест кейсы примерно так. На первой - краткие описания с ID, на отдельных страницах - сами кейсы со всеми атрибутами. Бывает, если кейсы оформлены в док документе, приходится часто листать туда-сюда для того, чтобы найти нужный, для этого лучше реализовать список с кратким описанием и удобной навигацией по сьюиту.
Тест кейс считается пройденным (passed), если ожидаемый результат совпадает с фактическим. Соответственно, проваленным (failed), если фактический результат оказался отличным от ожидаемого. Так же у тест кейса может быть состояние заблокирован (blocked), оно возникает если невозможно выполнить какое-либо условие из Действия (Action).
У Савина так же описан такой функционал, как поддерживаемость тест кейсов. Поскольку мы тест кейсы пишем не для одного раза и планируем ими пользоваться регулярно, а в программе может что-то меняться, нужно максимально продумать их дальнейшее сопровождение. Для этого тест кейсы должны быть: a) максимально независимы друг от друга и b) минимально конкретизированы - т.е. мы должны избегать отсылки к конкретным полям/товарам/атрибутам, поскольку они могут меняться с течением времени. Пример: в "добавьте товар "мишка плюшевый" в корзину" следует опустить имя товара, т.к. мишки на складе могут закончится и воспроизвести тестовый случай будет невозможно. Я считаю это разумно, но слишком общее описание будет занимать больше времени на разбор содержания, поэтому тут нужно найти золоту середину - и чтобы избежать излишней детализации, и чтобы не удариться в пространные описания.
Так же Савин уточняет, что ОР (ожидаемых результатов) в одном тест кейсе может быть и два. К примеру, если мы проверяем функционал добавления товара в корзину и смотрим, чтобы он корректно отобразился в корзине и одновременно в базе данных (т.н. "проверка внутри" (front end) - проверка интерфейса пользователя и "проверка изнутри" (back end) - проверка в базе). Ещё раз подчеркну, что нужно избегать зависимости тест кейсов, т.к. при "выпадении" одного может получится блокировка другого вследствии нарушения целостности ссылок сцелочная ссылочность. Так же важным параметром "хорошести" тест кейсов служит то, что их сможет выполнить другой человек - т.е. кто-то, кроме составителя.
Удалять выпавшие тест кейсы не рекомендуется несмотря на их независимость друг от друга, во-первых потому что ВНЕЗАПНО может оказаться, что удалять не нужно было, а во-вторых, он может понадобиться в качестве базы для создания нового. Савин рекомендует переносить удалённые тест кейсы в специальный раздел.

Форсаж

Ссылки для Selenium'а:
оглавление статей: http://automated-testing.info/knowledgebase/avtomatizaciya-funkcionalnogo-testirovaniya/selenium
список с общими компонентами и их описанием: http://automated-testing.info/knowledgebase/article/chto-takoe-selenium-i-s-chem-ego-edyat
Selenium Core: http://automated-testing.info/knowledgebase/article/selenium-core-obshchie-ponyatiya
расширение под IDE и комманды: http://automated-testing.info/knowledgebase/article/selenium-ide-flowcontrol-primery-ispolzovaniya