SlideShare une entreprise Scribd logo
1  sur  19
TAP
    тестирование
          и
тестирование в PERL
Тестирование
–это деятельность, которая позволяет выявить, насколько
 поведение программного продукта соответствует
 ожидаемому при различных условиях, входных данных и
 окружении.

            Условие и окружение




      входные данные              программа   ожидаемый результат
ЗАЧЕМ ?
Тестируя продукты, разработчик максимально снижает
вероятность возникновения ошибок при вводе продукта в
эксплуатацию.




                                       ошибки
        тесты
ВРЕМЯ — ДЕНЬГИ — ДРЕБЕДЕНЬГИ
Проекты бывают разные и затраты по ресурсам могут сильно отличаться.
    Категоричной оценки, заранее сделать невозможно, можно только
                           предположить.

                                   Но !
 Если поразмыслить то в идеале при написании тестов затраты на начальном
этапе разработки сильно возрастут (см. 'Графики затрат'). С развитием проекта,
затраты на поддержку такого проекта будет гораздо меньше чем у
развившегося проекта без покрытия тестами, на поддержку которого затраты
будут возрастать примерно линейно, особенно если проект очень часто меняет
разработчиков (платите людям деньги, не будет текучки и будет счастье).
Так как тесты отлично дополняют документацию (которую так не любят писать
многие прогеры), понять, что именно должно произойти будет легче.
'Графики затрат'

            Без тестов                           С тестами

       Затраты                                  Затраты
    на поддержку                             на поддержку
    и разработку                             и разработку




                     Развитие проекта                       Развитие проекта



                              Внимание!
Приведенные графики не стоит воспринимать как точные — это всего лишь личный опыт.
хороший тон разработки
— написание тестов до написания рабочего программного кода.


Таким образом мы точно знаем за что должен отвечать тот или иной модуль
             и та или иная процедура (функция, метод и т.п.),
            т.е. у программиста на руках точное тех-задание,
              а не то что в тикете, где порой пишут фразы,
        которые невозможно понять без телепатического шлема...
Ложка говн, т.е. дегтя:
                      Да, тесты это все хорошо,
                                 но
               иногда на них все же не хватает времени
                                 и
они дописываются, парой, не теми кто разрабатывал. Прогер может не
точно понимать для чего была написана функция, да к тому же только
тогда, когда приперло и не понятно, почему же эта сволоч не работает,
вед по коду же все правильно, а тем временем злой менагер с метлой и
криками бежит к тебе, показать свое недовольство.
   На постоянно быстроизменяющихся проектах написание тестов —
                        неблагодарное дело.
Но если проект постоянно и быстро изменяется — то все ли правильно в
                           этом проекте ?
Модульное тестирование
                                 (unit testing)
- процесс в программировании, позволяющий проверить на корректность отдельные модули
                              исходного кода программы.


    Скрипт использующий модули

                                                     Тест модуля
      use Module1                                    Module1
      use Module2
      use Module3                                    Тест модуля
                                                     Module2



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


                             ??                                !!!

                   Ручная                           Автомат
                   работа                           ически




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



                          ИЛИ ПРОСТО


  единый формат вывода результатов
           тестирования
TAP+ PERL =
TAP не привязан к определенному языку программирования, однако, чаще всего используется
           Perl-програмистами. http://search.cpan.org/~petdance/TAP-1.00/TAP.pm
Основной формат TAP:

1..N
ok 1 Description
....
ok 47 Description
ok 48 Description
more tests....


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


1..4
ok 1 - Input file opened
not ok 2 - First line of the input valid
ok 3 - Read the rest of the file
not ok 4 - Summarized correctly # TODO Not written yet
Использование TAP позволяет отделить программу-тест, от программы, которая автоматически
запускает тестовые скрипты, получает и обрабатывает результаты, анализирует их.
Преимущества подобного подхода:

  • возможность писать тесты на разных языках программирования, которые будут пересылать
   результаты общему обработчику для анализа и формирования отчетов;
  • использование единых правил для вывода результатов тестирования:
      1.программисту не нужно беспокоиться о формате вывода отчетов, их внешнем виде,
        создании удобного интерфейса взаимодействия с тестом.
      2.результаты выполнения всех тестов передаются общему обработчику, который
        отвечает за стандартный внешний вид и формат отчетов.
  • после написания очередного теста, программист вносит в код обработчика ссылку на
   новый файл. При поступлении соответствующей команды, обработчик автоматически
   запускает на выполнение все ранее указанные тестирующие скрипты. Соответственно,
   программист освобождается от необходимости вручную запускать на выполнение каждый
   тест (если тестовых файлов больше 20, и тесты проводятся регулярно - появляется
   значительная экономия времени.)
Тестирование в Perl
        Для создания тестовых программ в Perl наиболее часто используются модули:


                             Test::Simple
                              Test::More
                            TAP::Harness
(до TAP::Harness использовался Test::Harness но он устарел и на CPAN для написания тестов
рекомендуют использавть TAP::Harness). Эти модули работают в соответствии с протоколом
TAP.
Test::More
                                          и
                                Test::Simple
позволяют программисту создавать скрипты, которые тестируют поведение заданных модулей,
                              компонентов программ и пр.


   Вывод информации об итогах тестирования осуществляется в очень компактном виде, в
                                    формате TAP.
TAP::Harness
в свою очередь, предоставляет возможность упорядочить управление созданными тестовыми
скриптами (очень важно, если скриптов больше 50, 100, 1000...). Позволяет написать
программу, которая будет запускать группы тестовых скриптов на выполнение, принимать от
них, суммировать и анализировать полученные результаты. А также, выводить их
пользователю в удобном формате.




Начиная с версии 5.8, модули Test::More и Test::Harness являются частью ядра Perl. Для более
ранних версий Perl, эти модули доступны в CPAN.
use PERL or die(«$!»);

Contenu connexe

Tendances

Регулярное использование статического анализа кода в командной разработке
Регулярное использование статического анализа кода в командной разработкеРегулярное использование статического анализа кода в командной разработке
Регулярное использование статического анализа кода в командной разработкеTatyanazaxarova
 
Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...
Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...
Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...Tatyanazaxarova
 
Mva stf module 2 - rus
Mva stf module 2 - rusMva stf module 2 - rus
Mva stf module 2 - rusMaxim Shaptala
 
Mva stf module 5 - rus
Mva stf module 5 - rusMva stf module 5 - rus
Mva stf module 5 - rusMaxim Shaptala
 
(Seleniumcamp) Selenium IDE как артефакт пикника на обочине
(Seleniumcamp) Selenium IDE как артефакт пикника на обочине(Seleniumcamp) Selenium IDE как артефакт пикника на обочине
(Seleniumcamp) Selenium IDE как артефакт пикника на обочинеAlexei Lupan
 
VivaMP - инструмент для OpenMP
VivaMP - инструмент для OpenMPVivaMP - инструмент для OpenMP
VivaMP - инструмент для OpenMPTatyanazaxarova
 
Mva stf module 6 - rus
Mva stf module 6 - rusMva stf module 6 - rus
Mva stf module 6 - rusMaxim Shaptala
 
Benefits of unit-testing and inversion of controll
Benefits of unit-testing and inversion of controllBenefits of unit-testing and inversion of controll
Benefits of unit-testing and inversion of controllMykyta Hopkalo
 
Рефакторинг и второе рождение проекта на примере Zend Framework 2.0
Рефакторинг и второе рождение проекта на примере Zend Framework 2.0Рефакторинг и второе рождение проекта на примере Zend Framework 2.0
Рефакторинг и второе рождение проекта на примере Zend Framework 2.0AlexeyParhomenko
 
Трудности сравнения анализаторов кода или не забывайте об удобстве использования
Трудности сравнения анализаторов кода или не забывайте об удобстве использованияТрудности сравнения анализаторов кода или не забывайте об удобстве использования
Трудности сравнения анализаторов кода или не забывайте об удобстве использованияTatyanazaxarova
 
ук 03.007.02 2011
ук 03.007.02 2011ук 03.007.02 2011
ук 03.007.02 2011etyumentcev
 
C# Desktop. Занятие 17.
C# Desktop. Занятие 17.C# Desktop. Занятие 17.
C# Desktop. Занятие 17.Igor Shkulipa
 
сергей андреев
сергей андреевсергей андреев
сергей андреевAlexei Lupan
 
Инструментальный подход к разработке протоколов
Инструментальный подход к разработке протоколовИнструментальный подход к разработке протоколов
Инструментальный подход к разработке протоколовfurj
 
Test Automation as a way of Natural Evolution of a Project
Test Automation as a way of Natural Evolution of a ProjectTest Automation as a way of Natural Evolution of a Project
Test Automation as a way of Natural Evolution of a ProjectKateryna Nesmyelova
 
Continious integration-Automated Testing-Solid-Agile
Continious integration-Automated Testing-Solid-AgileContinious integration-Automated Testing-Solid-Agile
Continious integration-Automated Testing-Solid-AgileKairat Yussupov
 
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
 
ClubQA #2. Unit testing and TDD
ClubQA #2. Unit testing and TDDClubQA #2. Unit testing and TDD
ClubQA #2. Unit testing and TDDClub QA Kostroma
 

Tendances (20)

Регулярное использование статического анализа кода в командной разработке
Регулярное использование статического анализа кода в командной разработкеРегулярное использование статического анализа кода в командной разработке
Регулярное использование статического анализа кода в командной разработке
 
Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...
Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...
Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...
 
Mva stf module 2 - rus
Mva stf module 2 - rusMva stf module 2 - rus
Mva stf module 2 - rus
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
 
Mva stf module 5 - rus
Mva stf module 5 - rusMva stf module 5 - rus
Mva stf module 5 - rus
 
(Seleniumcamp) Selenium IDE как артефакт пикника на обочине
(Seleniumcamp) Selenium IDE как артефакт пикника на обочине(Seleniumcamp) Selenium IDE как артефакт пикника на обочине
(Seleniumcamp) Selenium IDE как артефакт пикника на обочине
 
VivaMP - инструмент для OpenMP
VivaMP - инструмент для OpenMPVivaMP - инструмент для OpenMP
VivaMP - инструмент для OpenMP
 
Mva stf module 6 - rus
Mva stf module 6 - rusMva stf module 6 - rus
Mva stf module 6 - rus
 
Benefits of unit-testing and inversion of controll
Benefits of unit-testing and inversion of controllBenefits of unit-testing and inversion of controll
Benefits of unit-testing and inversion of controll
 
Team workflow
Team workflowTeam workflow
Team workflow
 
Рефакторинг и второе рождение проекта на примере Zend Framework 2.0
Рефакторинг и второе рождение проекта на примере Zend Framework 2.0Рефакторинг и второе рождение проекта на примере Zend Framework 2.0
Рефакторинг и второе рождение проекта на примере Zend Framework 2.0
 
Трудности сравнения анализаторов кода или не забывайте об удобстве использования
Трудности сравнения анализаторов кода или не забывайте об удобстве использованияТрудности сравнения анализаторов кода или не забывайте об удобстве использования
Трудности сравнения анализаторов кода или не забывайте об удобстве использования
 
ук 03.007.02 2011
ук 03.007.02 2011ук 03.007.02 2011
ук 03.007.02 2011
 
C# Desktop. Занятие 17.
C# Desktop. Занятие 17.C# Desktop. Занятие 17.
C# Desktop. Занятие 17.
 
сергей андреев
сергей андреевсергей андреев
сергей андреев
 
Инструментальный подход к разработке протоколов
Инструментальный подход к разработке протоколовИнструментальный подход к разработке протоколов
Инструментальный подход к разработке протоколов
 
Test Automation as a way of Natural Evolution of a Project
Test Automation as a way of Natural Evolution of a ProjectTest Automation as a way of Natural Evolution of a Project
Test Automation as a way of Natural Evolution of a Project
 
Continious integration-Automated Testing-Solid-Agile
Continious integration-Automated Testing-Solid-AgileContinious integration-Automated Testing-Solid-Agile
Continious integration-Automated Testing-Solid-Agile
 
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
 
ClubQA #2. Unit testing and TDD
ClubQA #2. Unit testing and TDDClubQA #2. Unit testing and TDD
ClubQA #2. Unit testing and TDD
 

En vedette

написание текстов
написание текстовнаписание текстов
написание текстовDPR
 
Мастер класс по переговорам
Мастер класс по переговорамМастер класс по переговорам
Мастер класс по переговорамDPR
 
Go ielts партнёры блоги
Go ielts партнёры блогиGo ielts партнёры блоги
Go ielts партнёры блогиMariia Borovyk
 
Международные экзамены
Международные экзаменыМеждународные экзамены
Международные экзаменыLyudmilaM
 
Ielts writing collection 2015
Ielts writing collection 2015Ielts writing collection 2015
Ielts writing collection 2015Nguyễn Nhương
 

En vedette (8)

написание текстов
написание текстовнаписание текстов
написание текстов
 
Мастер класс по переговорам
Мастер класс по переговорамМастер класс по переговорам
Мастер класс по переговорам
 
IELTS или TOEFL?
IELTS или TOEFL?IELTS или TOEFL?
IELTS или TOEFL?
 
Go ielts партнёры блоги
Go ielts партнёры блогиGo ielts партнёры блоги
Go ielts партнёры блоги
 
Международные экзамены
Международные экзаменыМеждународные экзамены
Международные экзамены
 
Ket extra book
Ket extra bookKet extra book
Ket extra book
 
Ielts writing collection 2015
Ielts writing collection 2015Ielts writing collection 2015
Ielts writing collection 2015
 
Ielts essays
Ielts essaysIelts essays
Ielts essays
 

Similaire à TAP

Mva stf module 1 - rus
Mva stf module 1 - rusMva stf module 1 - rus
Mva stf module 1 - rusMaxim Shaptala
 
Unit tests ru
Unit tests ruUnit tests ru
Unit tests ruISsoft
 
QA Fes 2016. Анастасия Асеева. Роль тестирования в Devops
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQA Fes 2016. Анастасия Асеева. Роль тестирования в Devops
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
 
Тестирование ПО
Тестирование ПОТестирование ПО
Тестирование ПОseleznev_stas
 
Роман Петров - юнит-тестирование мобильных приложений на примере платформы iOS
Роман Петров - юнит-тестирование мобильных приложений на примере платформы iOSРоман Петров - юнит-тестирование мобильных приложений на примере платформы iOS
Роман Петров - юнит-тестирование мобильных приложений на примере платформы iOSProvectus
 
Сергей Ревко
Сергей РевкоСергей Ревко
Сергей РевкоSQALab
 
Технологический цикл и соблюдение фаз производства.
Технологический цикл и соблюдение фаз производства.Технологический цикл и соблюдение фаз производства.
Технологический цикл и соблюдение фаз производства.Сергей Сторожев
 
Jubula – TDD UI QA Automation Tool
Jubula – TDD UI QA Automation ToolJubula – TDD UI QA Automation Tool
Jubula – TDD UI QA Automation ToolCOMAQA.BY
 
Роман Кокин «Организация тестирования в больших командах»
Роман Кокин «Организация тестирования в больших командах»Роман Кокин «Организация тестирования в больших командах»
Роман Кокин «Организация тестирования в больших командах»DataArt
 
Unit testing and TDD
Unit testing and TDDUnit testing and TDD
Unit testing and TDDIosif Itkin
 
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17OdessaFrontend
 
Реклама PVS-Studio - статический анализ кода на языке Си и Си++
Реклама PVS-Studio - статический анализ кода на языке Си и Си++Реклама PVS-Studio - статический анализ кода на языке Си и Си++
Реклама PVS-Studio - статический анализ кода на языке Си и Си++Andrey Karpov
 
Как сейчас тесты в Android пишут, Денис Неклюдов, Google Dev Expert, Москва
 Как сейчас тесты в Android пишут, Денис Неклюдов, Google Dev Expert, Москва  Как сейчас тесты в Android пишут, Денис Неклюдов, Google Dev Expert, Москва
Как сейчас тесты в Android пишут, Денис Неклюдов, Google Dev Expert, Москва it-people
 
Модуль 8. Лекция 37-38. Управление качеством проекта
Модуль 8. Лекция 37-38. Управление качеством проектаМодуль 8. Лекция 37-38. Управление качеством проекта
Модуль 8. Лекция 37-38. Управление качеством проектаYana Brodetski
 
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...solit
 

Similaire à TAP (18)

Mva stf module 1 - rus
Mva stf module 1 - rusMva stf module 1 - rus
Mva stf module 1 - rus
 
Unit tests ru
Unit tests ruUnit tests ru
Unit tests ru
 
QA Fes 2016. Анастасия Асеева. Роль тестирования в Devops
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQA Fes 2016. Анастасия Асеева. Роль тестирования в Devops
QA Fes 2016. Анастасия Асеева. Роль тестирования в Devops
 
Тестирование ПО
Тестирование ПОТестирование ПО
Тестирование ПО
 
Роман Петров - юнит-тестирование мобильных приложений на примере платформы iOS
Роман Петров - юнит-тестирование мобильных приложений на примере платформы iOSРоман Петров - юнит-тестирование мобильных приложений на примере платформы iOS
Роман Петров - юнит-тестирование мобильных приложений на примере платформы iOS
 
Сергей Ревко
Сергей РевкоСергей Ревко
Сергей Ревко
 
Технологический цикл и соблюдение фаз производства.
Технологический цикл и соблюдение фаз производства.Технологический цикл и соблюдение фаз производства.
Технологический цикл и соблюдение фаз производства.
 
Jubula – TDD UI QA Automation Tool
Jubula – TDD UI QA Automation ToolJubula – TDD UI QA Automation Tool
Jubula – TDD UI QA Automation Tool
 
Роман Кокин «Организация тестирования в больших командах»
Роман Кокин «Организация тестирования в больших командах»Роман Кокин «Организация тестирования в больших командах»
Роман Кокин «Организация тестирования в больших командах»
 
Unit testing and TDD
Unit testing and TDDUnit testing and TDD
Unit testing and TDD
 
What Tests Are For?
What Tests Are For?What Tests Are For?
What Tests Are For?
 
DevOps guide for awesome quality assurance
DevOps guide for awesome quality assuranceDevOps guide for awesome quality assurance
DevOps guide for awesome quality assurance
 
Lektsia 7
Lektsia 7Lektsia 7
Lektsia 7
 
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
 
Реклама PVS-Studio - статический анализ кода на языке Си и Си++
Реклама PVS-Studio - статический анализ кода на языке Си и Си++Реклама PVS-Studio - статический анализ кода на языке Си и Си++
Реклама PVS-Studio - статический анализ кода на языке Си и Си++
 
Как сейчас тесты в Android пишут, Денис Неклюдов, Google Dev Expert, Москва
 Как сейчас тесты в Android пишут, Денис Неклюдов, Google Dev Expert, Москва  Как сейчас тесты в Android пишут, Денис Неклюдов, Google Dev Expert, Москва
Как сейчас тесты в Android пишут, Денис Неклюдов, Google Dev Expert, Москва
 
Модуль 8. Лекция 37-38. Управление качеством проекта
Модуль 8. Лекция 37-38. Управление качеством проектаМодуль 8. Лекция 37-38. Управление качеством проекта
Модуль 8. Лекция 37-38. Управление качеством проекта
 
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
Solit 2014, Централизованное управление тестами с помощью TestLink, Зубович В...
 

TAP

  • 1. TAP тестирование и тестирование в PERL
  • 2. Тестирование –это деятельность, которая позволяет выявить, насколько поведение программного продукта соответствует ожидаемому при различных условиях, входных данных и окружении. Условие и окружение входные данные программа ожидаемый результат
  • 3. ЗАЧЕМ ? Тестируя продукты, разработчик максимально снижает вероятность возникновения ошибок при вводе продукта в эксплуатацию. ошибки тесты
  • 4. ВРЕМЯ — ДЕНЬГИ — ДРЕБЕДЕНЬГИ Проекты бывают разные и затраты по ресурсам могут сильно отличаться. Категоричной оценки, заранее сделать невозможно, можно только предположить. Но ! Если поразмыслить то в идеале при написании тестов затраты на начальном этапе разработки сильно возрастут (см. 'Графики затрат'). С развитием проекта, затраты на поддержку такого проекта будет гораздо меньше чем у развившегося проекта без покрытия тестами, на поддержку которого затраты будут возрастать примерно линейно, особенно если проект очень часто меняет разработчиков (платите людям деньги, не будет текучки и будет счастье). Так как тесты отлично дополняют документацию (которую так не любят писать многие прогеры), понять, что именно должно произойти будет легче.
  • 5. 'Графики затрат' Без тестов С тестами Затраты Затраты на поддержку на поддержку и разработку и разработку Развитие проекта Развитие проекта Внимание! Приведенные графики не стоит воспринимать как точные — это всего лишь личный опыт.
  • 6. хороший тон разработки — написание тестов до написания рабочего программного кода. Таким образом мы точно знаем за что должен отвечать тот или иной модуль и та или иная процедура (функция, метод и т.п.), т.е. у программиста на руках точное тех-задание, а не то что в тикете, где порой пишут фразы, которые невозможно понять без телепатического шлема...
  • 7. Ложка говн, т.е. дегтя: Да, тесты это все хорошо, но иногда на них все же не хватает времени и они дописываются, парой, не теми кто разрабатывал. Прогер может не точно понимать для чего была написана функция, да к тому же только тогда, когда приперло и не понятно, почему же эта сволоч не работает, вед по коду же все правильно, а тем временем злой менагер с метлой и криками бежит к тебе, показать свое недовольство. На постоянно быстроизменяющихся проектах написание тестов — неблагодарное дело. Но если проект постоянно и быстро изменяется — то все ли правильно в этом проекте ?
  • 8. Модульное тестирование (unit testing) - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Скрипт использующий модули Тест модуля use Module1 Module1 use Module2 use Module3 Тест модуля Module2 Тест модуля Module3
  • 9. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже написанных и оттестированных местах программы, а также облегчает локализацию и устранение таких ошибок.
  • 10. Тестирование может проводиться как в ручном режиме, так и в автоматическом. В ручном режиме, тестировщик, используя интерфейс продукта, вводит произвольные данные, с ошибками и без, проверяет реакцию ПО на нажатие кнопок и т.д. Однако, если в программу будут внесены изменения, все тестирование прийдется повторить заново. ?? !!! Ручная Автомат работа ически В автоматическом режиме, разработчик создает серию тестов к своему программному продукту, которая эмулирует действия клиента, отправляя некие данные интерфейсу программы, и анализирует его ответ на соответствие ожидаемому. Такие тесты, написанные единожды, можно будет использовать в течении всего цикла жизни программного продукта, а если функционал программы будет дополнен новыми разработками - легко будет проверить, не нарушена ли в процессе разработки функциональность старых компонентов.
  • 11. Test Anything Protocol (TAP) - единый формат передачи результатов тестирования программам, которые интерпретируют результаты, и в зависимости от них, выполняют какие-либо действия. ИЛИ ПРОСТО единый формат вывода результатов тестирования
  • 12. TAP+ PERL = TAP не привязан к определенному языку программирования, однако, чаще всего используется Perl-програмистами. http://search.cpan.org/~petdance/TAP-1.00/TAP.pm
  • 13. Основной формат TAP: 1..N ok 1 Description .... ok 47 Description ok 48 Description more tests.... Например, тестирование чтения данных из файла, могло бы дать такой результат: 1..4 ok 1 - Input file opened not ok 2 - First line of the input valid ok 3 - Read the rest of the file not ok 4 - Summarized correctly # TODO Not written yet
  • 14. Использование TAP позволяет отделить программу-тест, от программы, которая автоматически запускает тестовые скрипты, получает и обрабатывает результаты, анализирует их. Преимущества подобного подхода: • возможность писать тесты на разных языках программирования, которые будут пересылать результаты общему обработчику для анализа и формирования отчетов; • использование единых правил для вывода результатов тестирования: 1.программисту не нужно беспокоиться о формате вывода отчетов, их внешнем виде, создании удобного интерфейса взаимодействия с тестом. 2.результаты выполнения всех тестов передаются общему обработчику, который отвечает за стандартный внешний вид и формат отчетов. • после написания очередного теста, программист вносит в код обработчика ссылку на новый файл. При поступлении соответствующей команды, обработчик автоматически запускает на выполнение все ранее указанные тестирующие скрипты. Соответственно, программист освобождается от необходимости вручную запускать на выполнение каждый тест (если тестовых файлов больше 20, и тесты проводятся регулярно - появляется значительная экономия времени.)
  • 15. Тестирование в Perl Для создания тестовых программ в Perl наиболее часто используются модули: Test::Simple Test::More TAP::Harness (до TAP::Harness использовался Test::Harness но он устарел и на CPAN для написания тестов рекомендуют использавть TAP::Harness). Эти модули работают в соответствии с протоколом TAP.
  • 16. Test::More и Test::Simple позволяют программисту создавать скрипты, которые тестируют поведение заданных модулей, компонентов программ и пр. Вывод информации об итогах тестирования осуществляется в очень компактном виде, в формате TAP.
  • 17. TAP::Harness в свою очередь, предоставляет возможность упорядочить управление созданными тестовыми скриптами (очень важно, если скриптов больше 50, 100, 1000...). Позволяет написать программу, которая будет запускать группы тестовых скриптов на выполнение, принимать от них, суммировать и анализировать полученные результаты. А также, выводить их пользователю в удобном формате. Начиная с версии 5.8, модули Test::More и Test::Harness являются частью ядра Perl. Для более ранних версий Perl, эти модули доступны в CPAN.
  • 18.
  • 19. use PERL or die(«$!»);