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