pi314

Гугл, в данном случае, как почти всегда, прав )) Речь идет о т.н. нефункциональных требованиях, т.е. таких, которые нельзя вот так вот взять, проверить тестом, и убедиться, что "оно работает, как заказывали". Это суть требования качественного характера, предъявляемые к архитектуре в целом, или к отдельным группам функциональных и/или системных требований. Например: "горизонтальное масштабирования хранилища данных не должно влиять на время реакции системы для операций регистрации новых и удаления ранее зарегистрированных пользователей", или, "система должна быть с минимальными затратами переносима на 64-битную архитектуру"... или еще круче: "разрабатываемая система должна обеспечивать легкость сопровождения кода новыми разработчиками".

Термин "Ility" происходит из (ныне устаревшего) ISO/IEC-9126, разросшегося в целое семейство стандартов ISO/IEC-250*, которые перечисляют и классифицируют все мыслимые и немыслимые аспекты качества ПО и даже определяют методику их оценки (SQuaRE)... правда, эта методика настолько туманна, что после ее прочтения растет число самоубийств остается больше вопросов, чем было до него )) В самой же классификации, большинство аспектов верхнего уровня заканчиваются на "ility" - Testability, Reliability, Portability и т.д. - oтсюда и название.

Однако, если есть требование, QA должен хоть извертеться на пупке, но найти возможность проверить/подтвердить, выполнено оно или нет... и такие возможности действительно есть. Только вот "тестированием" назвать их можно весьма условно. Скорее, речь идет о методиках анализа кажущихся на первый взгляд субъективными, характеристик качества ПО на основе его объективных характеристик - от мнений независимых экспертов, проводящих аудит (архитектуры, процессов разработки и системы управления качеством на предприятии), и вплоть до результатов структурного анализа архитектуры и статического/динамического анализа кода (в качестве примера последнего подхода: SQALE).

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

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

Поясню на примере. На Тостере есть функционал, позволяющий использовать некоторые HTML тэги в тексте ответа и комментария. Тесткейс для этого функционала может выглядеть (упрощенно) так:
-----
ID: UI1234
Author: V. Pupkin
Category: UI, manual, validation
Description: HTML тэги в тексте ответа
Precondition: Сервер запущен и доступен, В списке есть хотя бы один вопрос, Пользователь авторизован
Steps: Выбираем вопрос из списка. В поле ответа набираем текст, в котором используем [список] и др. HTML тэги, после чего нажимаем кнопку "Отправить".
Expected: Введенный текст отображается полностью, HTML тэги [разрешенные] отображаются соотв. разметкой, все прочие тэги игнорируются.
Postcondition: Сервер все еще доступен, кол-во вопросов в списке не изменилось, в ЦОД не возник пожар и т.д.
-----
Соответственно, если при исполнении теста что-то не не выполнилось (разметка не отобразилась, сгорел ЦОД или ответ удалось написать без авторизации - не важно, что именно), тест считается проваленным.

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

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

Ну, а тест-план - это вообще из другой оперы. Это документ, в котором подробно и основательно описывается, какие части системы как именно (и почему именно так) мы тестируем, что нам это дает (и что не дает) и обосновывается, почему такой подход обеспечивает требуемое качество продукта. Его обычно составляют совместно архитектор/техлид и ответственный QA в процессе разработки.