Автор: admin

Пирамида тестирования

Автор: Мартин Фаулер

Дата публикации: 1 мая 2012
Оригинал: https://martinfowler.com/bliki/TestPyramid.html

Пирамида тестирования — это концепция того, как различные виды автоматизированных тестов должны использоваться должны использоваться для создания сбалансированного портфеля. Её основная идея заключается в том, что у вас должно быть гораздо больше низкоуровневых модульных тестов (unit tests), чем высокоуровневых сквозных тестов (broad-stack tests), выполняемых через графический интерфейс пользователя.

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

Но такой подход быстро приводил к проблемам, превращаясь в «рожок мороженого» (ice-cream cone). Тестирование через пользовательский интерфейс подобным образом происходит медленно, увеличивая время сборки. Часто это требует установленных лицензий на программное обеспечение для автоматизации тестирования, что означает, что тесты можно запускать только на определённых машинах. Обычно такие тесты невозможно легко запустить в режиме без графического интерфейса (headless mode), управляемом скриптами для включения в правильный пайплайн деплоя.

Что наиболее важно — такие тесты очень хрупкие. Улучшение системы может легко привести к поломке множества таких тестов, которые затем придётся перезаписывать. Вы можете уменьшить эту проблему, отказавшись от инструментов записи-воспроизведения, но это сделает написание тестов более сложным. Даже при соблюдении хороших практик написания, сквозные тесты более подвержены проблемам недетерминированности, что может подорвать доверие к ним. Короче говоря, тесты, которые выполняются сквозным образом через пользовательский интерфейс:

  • хрупкие
  • дорогие в написании
  • требуют много времени для выполнения

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

Пирамида также выступает за промежуточный уровень тестов, которые работают через слой сервисов приложения, что я называю подкожными тестами (subcutaneous tests). Они могут предоставить многие преимущества сквозных тестов, но избежать многих сложностей работы с UI-фреймворками. В веб-приложениях это соответствовало бы тестированию через слой API, в то время как верхняя UI-часть пирамиды соответствовала бы тестам, использующим что-то вроде Selenium или Sahi.

Пирамида тестирования часто всплывает в кругах Agile-тестирования, и хотя её основное послание верно, есть гораздо больше, что можно сказать о построении хорошо сбалансированного портфеля тестов. Распространённая проблема заключается в том, что команды смешивают концепции сквозных тестов, UI-тестов и клиентских тестов. Все это независимые (orthogonal) характеристики. Например, богатый JavaScript UI должен иметь большую часть своего UI-поведения протестированным с помощью модульных JavaScript-тестов, используя что-то вроде Jasmine. Сложный набор бизнес-правил может иметь тесты, представленные в клиентском виде, но выполняться только на соответствующем модуле, как это делают модульные тесты.

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

Дополнительное чтение

Google Testing Blog раскрывает, почему вам не следует полагаться на сквозные тесты.

Adrian Sutton объясняет опыт LMAX, который показывает, что сквозные тесты могут играть большую и ценную роль.

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

Благодарности

Кевин Дишман подал мне идею добавить стрелки стоимости и скорости на иллюстрацию.

Этимология

Большинство людей знают о пирамиде тестирования благодаря Майку Кону (Mike Cohn), который описал её в своей книге 2009 года “Succeeding with Agile”. В книге он называет её “пирамидой автоматизации тестирования” (Test Automation Pyramid), но на практике она обычно называется просто “пирамидой тестирования” (test pyramid). Он впервые нарисовал её в разговоре с Лизой Криспин (Lisa Crispin) в 2003-2004 годах и описал на scrum-встрече в 2004 году. Джейсон Хаггинс (Jason Huggins) независимо пришёл к той же идее около 2006 года.

GIT fatal: inflateInit: out of memory

На одном из серверов при попытке пушнуть взятый под git код возникла ошибка 
Delta compression using up to 24 threads.
fatal: inflateInit: out of memory (no message)

Помогло сокращение трэдов упаковки 

git config --global pack.threads 1

PMBOK 9 Knowledge Areas to 5 Process Group Mapping

Project Management Process Groups
Knowledge Areas Initiating Process Group Planning Process Group Executing Process Group Monitoring & Controlling Process Group Closing Process Group
4. Project Integration Management 4.1 Develop Project Charter 4.2 Develop Project Management Plan 4.3 Direct and Manage Project Execution 4.4 Monitor and Control Project Work
4.5 Perform Integrated Change Control		 4.6 Close Project or Phase
5. Project Scope Management 5.1 Collect Requirements
5.2 Define Scope
5.3 Define WBS		 5.4 Verify Scope
5.5 Control Scope
6. Project Time Management 6.1 Define Activities
6.2 Sequence Activities
6.3 Estimate Activity Resources
6.4 Estimate Activity Durations
6.5 Develop Schedule		 6.6 Control Schedule
7. Project Cost Management 7.1 Estimate costs
7.2 Determine Budget		 7.3 Control Costs
8. Project Quality Management 8.1 Plan Quality 8.2 Perform Quality Assurance 8.3 Perform Quality Control
9. Project Human Resource Management 9.1 Develop Human Resource Plan 9.2 Acquire Project Team
9.3 Develop Project team
9.4 Manage Project team
10. Project Communications Management 10.1 Identify Stakeholders 10.2 Plan Communications 10.3 Distribute Information
10.4 Manage Stakeholder Expectations		 10.5 Report Performance
11. Project Risk Management 11.1 Plan Risk Management
11.2 Identify Risks
11.3 Perform Qualitative Risk Analysis
11.4 Perform Quantitative Risk Analysis
11.5 Plan Risk Responses		 11.6 Monitor and Control Risks
12. Project Procurement Management 12.1 Plan Procurements 12.2 Conduct Procurements 12.3 Administer Procurements 12.4 Close Procurements

Read more from PMBOK, Process Groups

SoapClient не передает заголовки Basic Authentication

Столкнулся на проекте с необычной штукой. SOAP-сервер находился под http-аутентификацией. На development машинах код работал без ошибок. Но при выгрузке на production стал давать при инициализации клиета ошибку:

SOAP-ERROR: Parsing WSDL: Couldn’t find  

 Поставил сниффер на машину с сервером. Оказалось, что  SoapClient, которому в options задавались логин и пароль не передавал заголовок Authentication. Причем было это, как я уже сказал, только на production сервере, где стояла Gentoo. Проблема была решена сменой версии php

5.3.8-pl0-gentoo на 5.3.25-pl0-gentoo

Вероятно, к этой версии баг был пропатчен.

WordPress 2.6.1 под php 5.3

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

Починил пока при помощи sed:

find -name *.php -exec sed -i 's/=&/=/g' {} ;

Осталось  пофиксить ругань на eregi в админке, а так, вроде запустилось. 

Ошибка в меню Joomla

При переходе на php5.3 сайт на старой Joomla стал выкидывать warning.

modMainMenuHelper::buildXML() expected to be a reference, value given

Лечится простым фиксом  в /modules/mod_mainmenu/helper.php. Меняем:

function buildXML(&$params)

на

 function buildXML($params)

Ubuntu rvm

В свой последний приезд Лёня Лукин подкинул книженцию по rails. Вроде как дошли руки ее пощупать, но меня поджидал фэил в самом начале пути.

Установил ruby-rvm на Ubuntu 12.04. Начал инсталлить ruby и gems  согласно инструкции.

rvm install 1.9.2

Фигакс, сообщает мне под конец, что установка не удалась посмотрите log.

ERROR: Error running ‘make ‘, please read /usr/share/ruby-rvm/log/ruby-1.9.2-p180/make.log
ERROR: There has been an error while running make. Halting the installation.

Смотрю log. Обнаруживаю там следующую запись.

ossl_ssl.c:110:1: ошибка: «SSLv2_method» undeclared here (not in a function)
ossl_ssl.c:111:1: ошибка: «SSLv2_server_method» undeclared here (not in a function)
ossl_ssl.c:112:1: ошибка: «SSLv2_client_method» undeclared here (not in a function)
make[1]: *** [ossl_ssl.o] Ошибка 1
make[1]: Выход из каталога `/var/cache/ruby-rvm/src/ruby-1.9.2-p180/ext/openssl’
make: *** [mkmain.sh] Ошибка 1

Как же я ненавижу ваш linux, мелькнуло в голове. Дальнейший алгоритм понятен, ищем в Гугле решение.

 # don’t use ubuntus openssl 
rvm pkg install openssl 
rvm install 1.9.2 –with-openssl-dir=$rvm_path/usr
Вива, Кальман. Фокус удается. 
Оригинал решения здесь.