Презентация на тему «Тестирование небольших приложений»

Тестирование небольших приложений

Test Cases.

Процесс тестирования небольших приложений (проектов) в рамках учебного процесса.

Оглавление

Что такое тестирование? Понятия. С чего начать, когда начать. Разработка приложения Анализ требований Тестирование базы данных Разработка Test Cases. Test Cases для приложения. Определения и виды. Завершение проекта Если проект- Web-приложение. Примеры Test Cases

Тестирование

Понятия.

Тестирование- это процесс анализа ПО и обнаружения ошибок. Ошибка (Bug)- Несоответствие требованиям или функциональным спецификациям. Это любое несоответствие ожиданиям пользователя от приложения.

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

Статическое тестирование- тестирование любой части готового продукта-

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

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

С чего начать

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

Разработка приложения

Разработка учебного проекта, как правило, состоит из следующих стадий: Постановка требований Разработка бизнес-логики приложения Разработка базы данных приложения Дизайн и кодирование

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

«Правильная» схема разработки

Постановка требований Тестирование требований Разработка бизнес-логики приложения Анализ бизнес-логики приложения Разработка базы данных приложения Тестирование базы данных приложения Дизайн и кодирование Основное тестирование

Поэтому, Предыдущие стадии можно представить в следующем виде:

С момента постановки задачи (выдачи задания), начинается процесс

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

Какими бывают требования

Функциональными- это то, что программа должна делать Не функциональными- дополнительные поведенческие свойства ПО, определенные командой и/или руководителем, преподавателем, и т.д.

Какими требования должны быть

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

Что же дальше

Роль тестировщика- еще на этапе формирования требований найти и уведомить группу о любых несоответствиях в требованиях Что же дальше? Когда требования протестированы и можно приступать к проектированию приложения?.. -бизнес-логика приложения.

Анализ бизнес-логики приложения

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

Тестирование базы данных

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

Тестирование базы данных состоит из:

Проверки типов полей в соответствии с требованиями Проверки целостности связей таблиц Проверки структуры базы данных в соответствии с требованиями Проверки триггеров, процедур, функций, если таковые имеются, на работоспособность и правильность Поиск Добавление дублирующейся информации Добавление/Модификация/Удаление

Для существующей базы данных:

Структура базы данных должна соответствовать предъявляемым требованиям Поля в таблицах должны быть проверены на правильность типов (например, ФИО не может быть числовым) Целостность связей не должна быть нарушена. (При изменений значений в одной из связных таблиц, в другой изменения должны также присутствовать) Результаты работ Триггеров, процедур, функций должны соответствовать ожидаемым результатам Должно осуществляться Добавление/Модификация/Удаление Должен осуществляться Поиск

Отдых? Временное затишье

После разработки базы данных и до первого билда- деятельность тестировщика временно прекращается. Да, кстати, Билд – Build- это промежуточная версия продукта, выпускаемая разработчиками для тестирования. Для небольших проектов, таких как учебный проект, билдов, как правило много не бывает. Если вообще бывает ?

Test cases, понятие и разработка

После того, как у тестировщика на руках окажется приложение, возникают следующие задачи- написание Test Cases и поиск ошибок. Test Case- набор входных данных, условий, и ожидаемых результатов, направленный на изучение приложения на соответствие требованиям и отсутствие ошибок

Как это пишется

Типичный Test Case состоит из: Заголовка ID Номера требований (если существует) Исходных требований и данных, необходимых для тестирования Тестируемой области приложения Шагов Ожидаемых результатов Пройден или нет

Пример Test Case

Не все Test Cases одинаковы, но примерный вид у всех схож.

ID

Исходные требования

Шаги

Ожидаемый результат

Заголовок

Номер требований

Пройден или нет

Зачем писать Test Cases для малого проекта

Написание Test Cases облегчает тестирование и делает его более структурированным Тестирование требований или базы данных может быть проведено до тестирования приложения. Отслеживание графика работ И, наконец, для отчетности ?

Чтобы было удобно

Тестирование учебного проекта состоит из нескольких частей, поэтому, для удобства написания Test Cases проще всего будет начинать с оформления упорядоченной структуры и внешнего вида Test Case.

Еще один пример

Разные вкладки- для тестирования разных частей проекта: требований, базы данных, самого приложения. Так удобней и понятней.

Эту- Database Testing

Здесь могла бы быть Ваша реклама ?

Эту вкладку можно назвать Requirements Testing

Эту- Application Testing

Для каждой области- свой набор Test Cases

Не сбивайте все Test Cases в одну кучу. Смысловыми наборами тестировать проще.

Этот подзаголовок обозначает набор Test Cases для панели Country

А этот- для следующей тестируемой панели компонентов

Test Cases для приложения

Определения и виды.

Test Cases для небольших приложений можно разделить на виды: Smoke Test- основной Test Case, без которого нельзя проводить остальные виды. Это небольшой тест из последовательных шагов, каждый последующий из которых зависит от предыдущего. Тест на основную функциональность приложения. Critical Path Test- То, что не вошло в Smoke Test+ негативные Test Cases. Extended Test-все остальные виды негативных Test Cases; такие, какие и не пришли бы в голову рядовому пользователю. Позитивное тестирование- тестирует приложение на предмет выполнения основных функций. То, что приложение делать должно. Негативное тестирование- тестирование дополнительных функций приложения (например ввод спец. Символов в числ. И текст. Поля), тестирование всего того, что может ввести пользователь.

Хороший тон

Написание Test Cases Для приложения стоит начинать с написания Smoke Test, и только потом переходить к написанию остальных видов Test Cases. Писать Test Cases лучше простым языком и использовать точные названия панелей, заголовков и полей. Не стоит объяснять базовую функциональность Windows. Одна проверка- в одном Test Case. Выделяйте заголовки цветом. Записывайте вопросы, которые возникают в процессе создания Test Cases. Обновляйте Test Cases с получением нового Build’а

Делитесь

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

Поиск ошибок

Ни одно приложение не обходится без ошибок. Во время написания Test Cases тестировщики, как правило, находят некоторые из них, но для наилучшего результата следует проводить поиск ошибок по Test Case’ам с каждым изменением или дополнением функциональности. Ошибки следует искать на всех стадиях разработки проекта.

Завершение проекта

Когда окончательная версия приложения разработана, для тестировщика начинается основная работа: доделать то, что было упущено на предыдущих стадиях и найти оставшиеся ошибки, какие только возможно. Качество готового проекта зависит в большой мере от тестировщика. Он ответственен за то, чтобы при сдаче проекта не было найдено ошибок.

Если проект- Web-приложение

Ключевые области тестирования Web- приложения: Тестирование элементов управления пользовательского интерфейса Навигационное тестирование Обработка ошибок

Тестирование элементов управления пользовательским интерфейсом

включает в себя тестирование:

Текстовых/числовых/денежных полей и полей даты Радио-кнопок Чек боксов Выпадающих меню Командных кнопок

Тестирование навигации

Тестирование навигации- это тестирование способности легко перемещаться по приложению из одной области в другую. Перемещения по приложению должны быть интуитивно понятными и простыми.

Обработка ошибок

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

Extended Tests

Для Web- приложения, например, таковы: Несколько пользователей работающие с приложением одновременно с разных удаленных компьютеров Несколько пользователей, работающих одновременно и затрагивающих разные области приложения Большое число удаленных пользователей И др.

Critical Test cases

Для текстовых полей: Оставить пустым Ввести 1 или несколько символом Пробелы вначале Пробелы в конце Пробелы в середине Только пробелы Максимальное количество символов Максимальное количество символов+1 Другой регистр Специальные символы Другой язык

Для числовых полей: Оставить пустым Минимальное значение Минимальное значение-1 Максимальное значение Максимальное значение+1 Специальные символы Среднее значение из допустимого интервала Несколько чисел Отрицательное значение Ноль вначале Пробелы вначале или в конце Ноль после разделяющего символа для десятичных значений

Для даты

Оставить пустым Минимальное значение Минимальное значение-1 Максимальное значение Максимальное значение+1 Специальные символы Текст Числовые значения Нулевые значения Другой разделитель даты Февраль, 28,29,30 Нули перед значениями (01/02/2007)

Smoke-test

Шаги Smoke-теста должны быть последовательны, например: Открыть Файл Изменить файл Сохранить файл Закрыть файл Открыть измененный файл Проверить наличие сохраненных изменений