Разработка и проектирование мультимедийного приложения
Цели, принципы и этапы тестирования.
Тестирование – процесс проверки правильности модели.
Каждому программисту известно, сколько времени и сил уходит на отладку и тестирование программ. На этот этап приходится около 50% общей стоимости разработки мультимедийного программного обеспечения.
Но не каждый из разработчиков программных средств может верно определить цель тестирования. Нередко можно услышать, что тестирование - это процесс выполнения программы с целью обнаружения в ней ошибок. Но эта цель недостижима: ни какое самое тщательное тестирование не дает гарантии, что программа не содержит ошибок.
Основные принципы организации тестирования:
· необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы, чтобы можно было быстро выяснить наличие или отсутствие ошибки в ней;
· следует по возможности избегать тестирования программы ее автором, т.к. кроме объективной сложности тестирования для программистов здесь присутствует и тот фактор, что обнаружение недостатков в своей деятельности противоречит человеческой психологии (однако отладка программы эффективнее всего выполняется именно автором программы);
· по тем же соображениям организация - разработчик мультимедийного программного обеспечения не должна «единолично» его тестировать (должны существовать организации, специализирующиеся на тестировании программных средств);
· должны являться правилом доскональное изучение результатов каждого теста, чтобы не пропустить малозаметную на поверхностный взгляд ошибку в программе;
· необходимо тщательно подбирать тест не только для правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных);
· при анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать;
· следует сохранять использованные тесты ( для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика);
· тестирования не должно планироваться исходя из предположения, что в программе не будут обнаружены ошибки (в частности, следует выделять для тестирования достаточные временные и материальные ресурсы);
· следует учитывать так называемый «принцип скопления ошибок»: вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части;
· следует всегда помнить, что тестирование - творческий процесс, а не относиться к нему как к рутинному занятию.
Существует два основных вида тестирования: функциональное и структурное. При функциональном тестировании программа рассматривается как «черный ящик» (то есть ее текст не используется). Происходит проверка соответствия поведения программы ее внешней спецификации.
Поскольку исчерпывающее функциональное тестирование невозможно, речь может идти о разработки методов, позволяющих подбирать тесты не «вслепую», а с большой вероятностью обнаружения ошибок в программе.
При структурном тестировании программа рассматривается как «белый ящик» (т.е. ее текст открыт для пользования). Происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей на графе передач управления программы (ее управляющем графе). Даже для средних по сложности программ числом таких путей может достигать десятков тысяч. Если ограничиться перебором только линейных не зависимых путей, то и в этом случае исчерпывающее структурное тестирование практически невозможно, т. к. неясно, как подбирать тесты, чтобы обеспечить «покрытие» всех таких путей. Поэтому при структурном тестировании необходимо использовать другие критерии его полноты, позволяющие достаточно просто контролировать их выполнение, но не дающие гарантии полной проверки логики программы.
Но даже если предположить, что удалось достичь полного структурного тестирования некоторой программы, в ней, тем не менее, могут содержаться ошибки, так как:
· программа может не соответствовать своей внешней спецификации, что в частности, может привести к тому, что в ее управляющем графе окажутся пропущенными некоторые необходимые пути;
· не будут обнаружены ошибки, появление которых зависит от обрабатываемых данных (т.е. на одних исходных данных программа работает правильно, а на других - с ошибкой).
Таким образом, ни структурное, ни функциональное тестирование не может быть исчерпывающим.
font-style:italic'>Совместное тестирование модулей.
Известны два подхода к совместному тестированию модулей: пошаговое и монолитное тестирование.
При монолитном тестировании сначала по отдельности тестируются все модули программного комплекса, а затем все они объединяются в рабочую программу для комплексного тестирования.
При пошаговом тестировании каждый модуль для своего тестирования подключается к набору уже проверенных модулей.
В первом случае для автономного тестирования каждого модуля требуется модуль - драйвер (то есть вспомогательный модуль, имитирующий вызов тестируемого модуля) и один или несколько модулей - заглушек (то есть вспомогательных модулей, имитирующих работу модулей, вызываемых из тестируемого). При пошаговом тестировании модули проверяются не изолированно друг от друга, поэтому требуются либо только драйверы, либо только заглушки.
В целом более целесообразным является выбор пошагового тестирования. При его использовании возможны две стратегии подключения модулей: нисходящая и восходящая.
Нисходящее тестирование начинается с главного (или верхнего) модуля программы, а выбор следующего подключаемого модуля происходит из числа модулей, вызываемых из уже протестированных. Одна из основных проблем, возникающих при нисходящем тестировании, - создание заглушек.
Это тривиальная задача, т. к., как правило, недостаточно, чтобы в заглушке выполнялся вывод соответствующего информационного сообщения и возврат всегда одних и тех же значений выходных данных.
Другая проблема, которую необходимо решать при нисходящем тестировании, - форма представления тестов в программе, так как, как правило, главный модуль получает входные данные не непосредственно, а через специальные модули ввода, которые при тестировании в начале заменяются заглушками. Для передачи в главный модуль разных тестов нужно или иметь несколько разных заглушек, или записать эти тесты в файл во внешней памяти и с помощью заглушки считывать их.
Поскольку после тестирования главного модуля процесс проверки может продолжаться по-разному, следует придерживаться следующих правил:
· модули, содержащие операции ввода-вывода, должны подключаться к тестированию как можно раньше;
· критические (т.е. наиболее важные) для программы в целом модули также должны тестироваться в первую очередь.
Основные достоинства нисходящего тестирования: уже на ранней стадии тестирования есть возможность получить работающий вариант разрабатываемой программы; быстро могут быть выявлены ошибки, связанные с организацией взаимодействие с пользователем.
