Geum.ru

Тесты и их классификация 3 Лекция №3 от 29. 09. 08 4

Вид материалаТесты

Содержание


Лекция №4 от 03.10.2008
Процедура тестирования
Лекция №5 от 10.10.08
Подобный материал:
1   2   3   4   5   6   7   8

Лекция №4 от 03.10.2008

  1. План тестирования
  2. Разработка и хранение системы тестов
  3. Создание среды тестирования
  4. Выполнение тестов
  5. Составление отчетов по результатам тестирования


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

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

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

При создании среды тестирования определяется:
  1. Все варианты состава вычислительного комплекса, включая сетевое оборудование.
  2. Все варианты операционной среды, в которой может работать ПП
  3. Средства для документирования и автоматизации тестирования


Следует подчеркнуть, что для создания среды тестирования могут понадобиться значительные аппаратные и программные средства. Это необходимо для имитации всех условий применения ПП. Так, для тестирования Web-приложений необходимо предусмотреть возможность работы всех, указанных в ТЗ операционных систем, с используемыми программными средствами браузерами, имитацию работы раличных web-серверов и, если необходимо, proxy-серверов.

Одним из важных вариантов тестирования является проверка на так называемой virgin-машине, т.е. на компьютере осуществляется полная очистка жесткого диска, путем форматирования или копирования образа системы с эталонного носителя. Затем устанавливается операционная среда и программы, необходимые для эксплуатации тестируемого ПП. Это требуется в частности для обнаружения ошибок, которые проявляются только при первом и при инсталляции ПП. Крое того, к минимальному сводится влияние других программ, что позволяет сосредоточиться на исследовании данного ПП.

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


Собственно процедура тестирования состоит из следующих действий:
  1. Прогон тестовых случаев
  2. Сравнение результатов прогона с ожидаемыми (эталонными)
  3. Фиксация обнаруженных ошибок
  4. Проверка исправления обнаруженных ошибок, путем повторного прогона всех или некоторых (регрессионных) тестовых случаев.


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

Для автоматизации тестов существуют специальные инструментальные средства. Программы, написанные с их помощью, могут предусматривать определения состояния экрана тестируемого ПП (окна, диалоги, строки, текстовые поля), и, в зависимости от него, эмуляцию того или иного пользовательского воздействия со стороны клавиатуры и мыши. При программировании тестов можно предусмотреть проверку условий, организацию циклов, модификацию данных, сравнение результатов тестируемой программы с ожидаемыми в циклическом режиме. Становятся возможными длительные многократные проверки, немыслимые при ручном тестировании.

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

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

Кроме того, для каждой ошибки в БД помещается ее краткое описание, а также действие, которое привело к ее появлению. Обычно занесенные в БД ошибки группируются по признаку тестируемого объекта (ошибки сервера, ошибки клиента и т.д.).

Лекция №5 от 10.10.08


Начало пропущено!!!

Тестовый случай (test case) описывается:
  1. Набором входных данных
  2. Условием его выполнения
  3. Действиями по его выполнению
  4. Ожиданием результата

Если после прогона теста (отлаженного) фактические результаты совпадают с ожидаемыми, то считается, что пользовательское приложение проверку по данному тестовому случаю прошло, иначе регистрируется ошибка.

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

Тестовые случаи объединяются в тесты. Тест формируется по принципу: каждому требованию ТЗ на разработку программного продукта, по крайней мере, один тест. Если для тестирования программного продукта на соответствует какому-либо пункту ТЗ требуется большое количество тестовых случаев, то данный тест разделяют на несколько тестов. Разделение на тестовые случаи проводится по проверяемым пунктам, собранным в данном пункте ТЗ. Требования ТЗ обычно объединяются в группы по формальным признакам, поэтому тесты предназначены для проверки реализации данных требований, требования могут объединять в аналогичные группы – набор тестов. Совокупность всех наборов тестов, созданных для данного программного продукта, образует систему тестов продукта.

Качество(полнота тестового случая)

П: тестируется однооконный текстовый редактор неформатированных текстовых файлов. Система тестов:
  • Набор 1

Тесты инсталляции / деинсталляции / автообновления
  • Набор 2

Тесты запуска/ завершения программы
  • Набор 3.1

Тесты меню/file
  • Набор 3. 2

Тесты меню/edit
  • Набор 3.3

Тесты меню/search
  • Набор 3.4

Тесты меню/help
  • Набор 3.5

Тесты функций реализуемых клавиатурой
  • Набор 3.6

Тесты функций реализуемых мышью
  • Набор 4

Тесты взаимодействия с другими пользовательскими приложениями и ОС.

В свою очередь набор 3.1 содержать множество отдельных тестов по каждой функции вызываемой этим пунктом меню:
  • Test create
  • Test open
  • Test save
  • Test save as
  • Test page layout
  • Test exit

Для Test open возможны тестовые случаи:
  1. Открыть существующий файл
  2. Открыть несуществующий файл
  3. Открыть файл, открытый другой программой
  4. Открыть файл на сетевом устройстве
  5. Открыть файл с носителя притом, что носителя нет
  6. Открыть файл на носителе, предназначенном только для чтения