Ошибки передачи или интерпретации данных
Один модуль может передавать данные другому или даже другой про грамме. Некоторые данные могут передаваться между модулями множество раз, и на каком-то этапе они могут быть разрушены или неверно интерпретированы. Изменения, внесенные одной из частей программы, могут потеряться или достичь не всех частей системы, где они важны.
• Неправильная интерпретация данных. Программа передает подпрограмме значение температуры по шкале Цельсия, а та интерпретирует его как температуру по Фаренгейту.
• Неадекватная информация об ошибке. Столкнувшись с ошибкой, программа не установила ее флаг. Или же она выдала сигнал ошибки без сопутствующей информации, в результате чего вызывающая программа не знает, как ее обрабатывать.
• Затирание кода другого процесса. Может произойти, если два процесса имеют доступ к одной и той же области памяти.
• Не сохранены введенные данные. Программа запрашивает у пользователя данные и не сохраняет их. Причиной может быть недоступность файла, в котором должна была быть сохранена эта информация.
Ситуация гонок
Классическая ситуация гонок описывается так. Предположим, в системе ожидаются два события, А и Б. Первым может произойти любое из них. Но если первым произойдет событие А, выполнение программы продолжится, а если первым наступит событие Б, то в работе программы произойдет сбой. Программист полагал, что первым всегда должно быть событие А, и не ожидал, что Б может выиграть гонки. Тестировать ситуации гонок довольно сложно. Наиболее типичны они для систем, где параллельно выполняются взаимодействующие процессы и потоки, а также для многопользовательских систем реального времени. Ошибки в таких системах трудно воспроизвести, и на их выявление обычно требуется очень много времени.
|
|
|
• Гонки при обновлении данных. Клиент банка получил $500 и потратил $100, до этого на его счете было $1000. Первая процедура считала с диска остаток в $1000 и вычла из него $100. До того, как она записала результат на диск, вторая процедура считала остаток и добавила к нему $500. Затем первая процедура записала свой результат, а вторая — свой. В результате вместо $1400 остаток получился равным $1500.
• Предположение, что одно задание завершится до начала другого.
• Сообщения приходят одновременно или не в том порядке, в котором они были отправлены.
Перегрузки
Программа может не справляться с повышенными нагрузками. Например, она может не выдерживать интенсивной и длительной эксплуатации или не справляться со слишком большими объемами данных. Кроме того, сбои могут происходить из-за нехватки памяти или отсутствия других необходимых ресурсов. У каждой программы свои пределы. Вопрос в том, соответствуют ли реальные возможности и требования программы к ресурсам ее спецификации и как программа себя поведет при перегрузках.
|
|
|
• Требуемый ресурс недоступен (диск полон, стек полон, очередь печати заполнена, в принтере нет ленты, ...)
• Потеря информации о нажатых клавишах изза недостаточного размера буфера ввода или очереди.
Аппаратное обеспечение
Программы могут посылать устройствам неверные данные, игнорировать их сообщения об ошибках, пытаться использовать устройства, которые заняты или вообще отсутствуют. Даже если нужное устройство просто сломано, программа должна понять это, а не сбоить при попытке к нему обратиться.
• Неверный адрес устройства.
• Устройство недоступно.
• Данной программе или устройству доступ к устройству запрещен.
Контроль версий
Бывает, что старые ошибки вдруг всплывают снова из-за того, что программа скомпонована с устаревшей версией одной из подпрограмм. Поэтому версии всех составляющих проекта обязательно должны централизованно контролироваться. Кроме того, следует убедиться, что правильны все появляющиеся на экране сообщения об авторских правах, названии и номере версии программного продукта. Обязательной проверке подлежат десятки мелких деталей. Обычно контроль программы и ее исходного кода осуществляется группой контроля качества.
|
|
|
• В программе появляются старые ошибки, ранее исправлявшиеся (программист скомпоновал старую версию одной программы с новыми версиями остальных).
• Ошибка, исправленная в одном месте программы может быть обнаружена в другом (Программист использовал один и тот же код в разных программных модулях.Изменив его в одном месте, программист мог забыть изменить его в остальных местах (копиях этого кода)).
• Неверный номер версии программы в заголовке экрана.
• Неверная информация об авторских правах.
Документация
Документация считается частью программного продукта. И если она плохо написана, пользователь может подумать, что и сама программа работает некорректно.
Ошибки тестирования
Если программист допускает по полторы ошибки на каждую строку программного кода, то сколько их допускает тестировщик на каждый тест? Обнаружение ошибок, допущенных тестировщиками, — дело обычное. Конечно, если таких ошибок будет слишком много, вы быстро потеряете доверие остальных членов команды. Но нужно иметь в виду, что иногда ошибки тестировщика отражают проблемы пользовательского интерфейса: если программа заставляет пользователя делать ошибки, значит, с ней что- то не так. Конечно, многие ошибки тестирования вызваны просто неверными тестовыми данными.
|
|
|
• Пропущены ошибки в программе. После обнаружения пропущенной ошибки нужно усовершенствовать процедуру тестирования.
• Не документирована проблема (тестировщика просили больше не документировать подобные проблемы).
• Не выполнен запланированный тест (тестовые материалы и записи плохо организованы, тесты перепутаны).
• Проигнорированы предложения программистов - программист знает, какие функции кодировались слишком быстро, какие тесты выявили больше важных ошибок и где в программе могут встречаться подобные ошибки.
• Документирование ошибки, которой нет на самом деле. Может оказаться, что проблема связана с неправильными действиями тестировщика, его непониманием программы: “После залогинивания в системе в браузере IE, в браузере FireFoxавторизационные данные не вводятся автоматически”.
• Ошибка выявлена и забыта. После документирования ошибки нужно отслеживать ее исправление.
Терминология
Ниже в таблице будет указана терминология, использующаяся в материале урока.
| Название термина | Описание |
| ПО | Программное обеспечение, программа |
| Программа | Программный продукт, разрабатываемый программистами и тестируемый тестировщиками |
| Пользователь | Конечный потребитель программного продукта |
| Отладка | Процесс исправления ошибок в коде |
| Ошибка, дефект, баг, BUG | Изъян в программе, который вызывает несоответствие ожидаемых результатов выполнения программы и фактически полученных результатов |
| Сбой | Внезапная остановка работающей программы |
| Проектирование | Деятельность по созданию. Проектирование системы: выстраивание архитектуры системы. Проектирование тестов: Создание тестовой документации,тест-кейсов. |
| Спецификация | Документ, описывающий требования к разработке той или иной части программного продукта, описание функционала, дизайна, назначения и целей. Описание того, как должно работать ПО. |
| ТЗ | Техническое задание, исходный документ для разработки и испытания ПО. Как правило, ТЗ для ИТ-проектов пишется в соответствии со стандартами ГОСТ 19, ГОСТ 34. |
Практика
Домашнее задание
Задание 1
Необходимо описать шаги для всестороннего тестирования какого-нибудь предмета (напр., кубик Рубика, кот, будильник). Для подсказки можно пользоваться описаниями типов ошибок в методичке к этому уроку.
Итак, возьмем кубик Рубика. Что мы можем проверить в нем?
• Внешний вид: Цвет уникальный на каждой стороне? Форма квадратная? Какой размер?
• Какой вес?
• Состояние: новый или б/у?
• Пригоден для использования? Все стороны крутятся?
• Удобно держать в руке?
• Разваливается при использовании?
• Пачкает руки?
• Острые углы имеются? Можно ли пораниться об него?
• Есть ли неприятный запах?
• Уронить на пол: Прочный ли? Сломался?
• Можно ли физически разобрать на детальки и собрать снова?
• ...и т.д.
Задание 2
Протестировать страницу авторизации в электронной почте. Для этого, предварительно нужно создать тестовый аккаунт (можно использовать свой). Далее, опираясь на описание категорий ошибок в методичке, выписать в таблицу действия, которые можно совершить пытаясь войти в почту. Цель - придумать проверки, понимать какой ждем результат проверки.
| № | Действие | Результат |
| 1 | ||
| 2 | ||
| ... |
Задание 3
В приложенной картинке найти 3 ошибки.
Задание 4
*Найти и описать ошибки на предложенной форме. При выполнении задания руководствоваться описанием ошибок пользовательского интерфейса.
Домашнее задание прислать на почтуtestgile.post@gmail.comв отдельном файле word в формате .doc (не .docx и не .docm !!!)
В заголовке письма указать следующее : Задание 1 – Фамилия Имя – ник (если есть)
Дата добавления: 2018-08-06; просмотров: 1705; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!