По тесту легко понять правильно ли повела себя программа
Nbsp; Разработка тест-кейсов Определение и структура тест-кейсов. Характеристики хорошего теста. Аксиомы тестирования. Поддерживаемость тест-кейсов. Системы менеджмента качества. Тест-комплекты. Чек-листы. Подготовка тестовых Характеристики хорошего теста Тест должен выявлять ошибки Набор тестов не должен быть избыточным Тест должен быть наилучшим в своей категории Тест не слишком простой или сложный По тесту легко понять правильно ли повела себя программа Нет зависимостей между тестами Аксиомы тестирования Тестирование показывает наличие дефектов Исчерпывающее тестирование невозможно Раннее тестирование Скопление дефектов Парадокс пестицидов Тестирование зависит от контекста Заблуждение об отсутствии ошибок Тест-кейс Стандартные атрибуты тест-кейса Преимущества и недостатки тест-кейсов Тест кейсы набором входных данных Тест-кейс с несколькими результатами Ожидаемый результат на каждый шаг Несколько проверок после одного сценария Области применения Стандартные ошибки при оформлении тест-кейсов Тест-комплекты Чек-листы Что такое чек-лист? Стандартные атрибуты чек-листа Подходы к использованию чек-листов Структуризатор Незабыватор Тесткейсозаменитель Статусопоказатель Окруженияучитыватель Тестирование исследовательское и по сценариям Чит-листы Что такое чит-листы? Что дают чит-листы? Подготовка тестовых данных Практика Домашнее задание Дополнительные материалы Используемая литература
|
|
|
Характеристики хорошего теста
Тест (от слова англ. test — «испытание», «проверка») или испытание — способ изучения глубинных процессов деятельности системы, посредством помещения системы в разные ситуации и отслеживание доступных наблюдению изменений в ней [Википедия].
Тестирование ПО является процессом исследования и имеет две цели:
1. Определить, что программа соответствует требованиям
2. Выявить ситуации, когда ПО ведет себя нежелательным или не соответствующим образом. Хороший тест должен удовлетворять нижеперечисленным критериям.
Тест должен выявлять ошибки
Задачей тестирования является поиск ошибок в ПО. Поэтому, придумывая тесты нужно проанализировать все возможные варианты сбоя программы или ее неправильного поведения. Если в программе может произойти определенная ошибка, нужно подумать, как ее поймать.
|
|
|
Например, при тестировании программы, которая открывает файлы определенного формата и что-то с ними делает. Как нам проверить функцию открытия файла? Достаточно часто бывает, что у программ проблемы с восприятием русских названий или пробелов в пути к файлу. Т.к. это проблема распространена, то есть вероятность, что и наша программа подвержена такой же ошибке. Поэтому можно провести два теста, на открытие файлов:
● «C:\файл.txt» - русское название файла
● «C:\Мой файл.txt» - название файла с пробелом
● «C:\Папка\temp.txt» - русское название папки в пути до файла
● «C:\Моя папка\temp.txt» - в названии папки в пути до файла есть пробелы
Набор тестов не должен быть избыточным
Есть два теста, предназначены для выявления одной и той же ошибки, зачем выполнять их оба? Например, если у нас есть несколько файлов, с русским названием папок в пути:
● «C:\Папка\temp.txt»
● «C:\Папка\temp1.txt»
● «C:\Папка\Папка1\temp.txt»
● «C:\Папка\Папка1\Папка3\temp.txt»
Для проверки того, как программа работает с названием русских папок в пути достаточно открыть один из файлов.
Тест должен быть наилучшим в своей категории
В группе похожих тестов одни могут быть эффективнее других. Поэтому, выбирая тест, нужно взять тот, который с наибольшей вероятностью выявит ошибку. Наиболее часто ошибки встречаются на граничных условиях диапазона значений, чем на средних значениях того же диапазона. Поэтому для тестов больше подходят граничные условия.
|
|
|
Тест не слишком простой или сложный
Тест не должен быть слишком простым или слишком сложным. Иногда из-за лени или оптимизации процесса тестировщику хочется объединить две проверки в один тест, что может сэкономить время на их выполнении. Однако нужно не переусердствовать – огромный и сложный тест трудно понять, трудно выполнить и долго создавать. Поэтому лучше всего придерживаться золотой середины, разрабатывая простые, но все же не совсем элементарные тестовые примеры.
Кроме трудоемкости сложных тестов есть и более серьезный недостаток. Скомбинировав несколько неверных входных значений, нельзя сказать наверняка, как программа интерпретирует каждое из них. После первого же недопустимого значения поведение программы может выйти из под контроля, например, она может просто отказаться приниматься все остальные данные. Такие примеры иногда строятся намеренно – если необходимо проверить, как программа реагирует на серию недопустимых значений. Однако для начала лучше протестировать их по отдельности, проверив работу блока обработки каждой из ошибок.
|
|
|
По тесту легко понять правильно ли повела себя программа
Как узнать, прошла ли программа тест? Ответ на этот вопрос не так очевиден, как может показаться на первый взгляд. Тут есть над чем подумать. Даже неверные выходные данные на экране или на бумаге тестировщик может пропустить, не говоря уже о том, что результат ошибки может оказаться скрытым.
Разрабатывая тест, подробно опишите ожидаемые выходные данные или реакцию программы. Выполняя его, сверяйтесь со своими записями.
Постарайтесь разрабатывать тесты так, чтобы объем выходных данных был минимальным. В километровой распечатке или огромном файле едва ли легко будет найти неправильную цифру.
Дата добавления: 2018-08-06; просмотров: 683; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!