Тестирование. Ю. Б. Попова тестирование и отладка программного
 Скачать 0.6 Mb.
|
|
1 МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ Белорусский национальный технический университет Кафедра «Программное обеспечение информационных систем и технологий» Ю. Б. Попова ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Пособие Рекомендовано УМО по образованию в области информатики и радиоэлектроники для направления специальности 1-40 05 01-04 «Информационные системы и технологии (в обработке и представлении информации)» Минск БНТУ 2020 2 УДК 004.415.53 ББК 32.973-018.2 П58 Рецензенты: кафедра технологий программирования Белорусского государственного университета; канд. техн. наук, зам. директора ОДО «ВирусБлокАда» Г. К. Резников Попова, Ю. Б. Тестирование и отладка программного обеспечения: пособие / Ю. Б. Попова. – Минск : БНТУ, 2020. – 66 с. ISBN 978-985-583-056-7. В пособии рассмотрены основные понятия из области тестирования программного обеспечения, его классификация, виды, роль и место в жизненном цикле разработки программ. Описаны процессы модульного и интеграционного тестирования, их этапы, возможности автоматизации, особенности работы с инструментами автоматизации. Большое внимание уделено планированию и реализации функционального тестирова- ния, процессу поиска и документирования ошибок. Рассмотрен процесс отладки про- граммного обеспечения, основные этапы, методы и рекомендации по его проведению. УДК 004.415.53 ББК 32.973-018.2 ISBN 978-985-583-056-7 © Попова Ю. Б., 2020 © Белорусский национальный технический университет, 2020 П58 3 СОДЕРЖАНИЕ 1. РОЛЬ И МЕСТО ТЕСТИРОВАНИЯ В ЖИЗНЕННОМ ЦИКЛЕ РАЗРАБОТКИ ПРОГРАММ ................................................................. 5 1.1. Определение термина «тестирование программного обеспечения» ........................................................................................... 5 1.2. Тестирование в жизненном цикле разработки программного обеспечения ................................................................... 6 1.3. Виды тестирования программного обеспечения .......................... 8 1.4. Смежные вопросы тестирования ................................................. 10 2. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ПРОДУКТУ ........................................................................................... 11 2.1. Этапы разработки требований к программному продукту ........ 11 2.2. Категории требований к программному продукту ..................... 13 3. МОДУЛЬНОЕ ТЕСТИРОВАНИЕ .................................................. 14 3.1. Модульное тестирование и его задачи ........................................ 14 3.2. Обзоры программного кода .......................................................... 16 3.3. Принципы тестирования структуры программных модулей ......................................................................... 17 3.4. Способы тестирования взаимодействия модулей ...................... 19 3.5. Стратегии выполнения пошагового тестирования ..................... 21 3.6. Особенности объектно-ориентированного тестирования ......... 22 3.7. Автоматизация модульного тестирования .................................. 25 3.7.1. Семейство хUnit ................................................................ 25 3.7.2. Встроенные инструменты для автоматизации модульного тестирования .......................................................... 28 3.7.3. Использование универсальных инструментов автоматизации тестирования .................................................. 29 4. ПЛАНИРОВАНИЕ ФУНКЦИОНАЛЬНОГО ТЕСТИРОВАНИЯ ................................................................................ 31 4.1. Тестовый план ................................................................................ 32 4.2. Разработка тестовых случаев ........................................................ 33 4.3. Эквивалентирование и анализ граничных значений .................. 36 4 5. РЕАЛИЗАЦИЯ ФУНКЦИОНАЛЬНОГО ТЕСТИРОВАНИЯ ...... 37 5.1. Ошибка, свойства ошибки ............................................................ 37 5.2. Правила составления отчетов об ошибках .................................. 39 5.3. Системы документирования и отслеживания ошибок ............... 41 5.4. Жизненный цикл ошибки ............................................................. 42 5.5. Реализация градации тестов ......................................................... 43 5.5.1. Тест «на дым» и критерии его непрохождения ............. 43 5.5.2. Позитивный тест ............................................................. 44 5.5.3. Негативный тест .............................................................. 44 5.6. Особенности тестирования standalone и веб-приложений ......... 47 6. АВТОМАТИЗАЦИЯ ФУНКЦИОНАЛЬНОГО ТЕСТИРОВАНИЯ ................................................................................ 48 6.1. Достоинства и недостатки автоматизации функционального тестирования .......................................................... 50 6.2. Требования к автоматизированным тестам ................................. 52 6.3. Методы автоматизации функционального тестирования .......... 52 6.3.1. Метод Play&Record........................................................... 52 6.3.2. Метод функциональной декомпозиции ............................ 53 6.3.3. Метод Data-driven ............................................................. 54 6.3.4. Метод Keyword-driven ....................................................... 54 6.4. Семейство Selenium и его возможности ...................................... 55 6.5. Проблемы внедрения автоматизации тестирования программного обеспечения ................................................................. 56 7. ОТЛАДКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ......................... 58 7.1. Методика отладки .......................................................................... 58 7.2. Методы отладки ............................................................................. 60 7.3. Психологические аспекты отладки .............................................. 62 7.4. Средства отладки ........................................................................... 63 ЛИТЕРАТУРА ...................................................................................... 65 5 1. РОЛЬ И МЕСТО ТЕСТИРОВАНИЯ В ЖИЗНЕННОМ ЦИКЛЕ РАЗРАБОТКИ ПРОГРАММ 1.1. Определение термина «тестирование программного обеспечения» Тестирование программ зародилось практически одновременно с программированием. Машинное время стоило дорого, поэтому предприятия с повышенными требованиями к надежности про- грамм (например, авиакосмическая промышленность) стали актив- но разрабатывать методики тестирования. Долгое время было принято считать, что целью тестирования является доказательство отсутствия ошибок в программе. Однако этот тезис не выдерживает критики, т. к. полный перебор всех возможных вариантов выполнения программы находится за пре- делами вычислительных возможностей даже для очень небольших программ. Поэтому никакое тестирование не может гарантировать отсутствия ошибок. Со временем понимание целей тестирования изменилось, и один из основоположников тестирования Гленфорд Майерс предложил следующее определение: «Тестирование – это процесс выполнения программ с целью обнаружения ошибок» [1]. Здесь следует отме- тить, что тестовая деятельность, предусматривающая эксплуатацию программного продукта, называется динамическим тестированием (англ., Dynamic Testing). В то же время существует понятие стати- ческого тестирования (англ., Static Testing), определяющего тесто- вую деятельность, связанную с анализом программного обеспече- ния (ПО) и проводимую без его запуска. К статическому тестирова- нию относятся обзоры кода, инспекции, аудит, критический анализ и т. д. Внимательное изучение этих двух подходов к тестированию показывает, что они дополняют друг друга и позволяют находить разные виды ошибок. Поэтому наиболее эффективные процессы разработки ПО используют комбинацию методов тестирования, реа- лизующих эти подходы. В табл. 1.1 приводятся показатели мини- мальной, средней и максимальной эффективности различных мето- дов тестирования [2]. Из таблицы видно, что тестирование максимально эффективно в тех случаях, когда программа проверяется не только путем запуска, 6 но и путем чтения, статических проверок и т. п. Поэтому классиче- ское определение Майерса, приведенное выше, оказывается слиш- ком узким и не охватывающим всех аспектов современного тести- рования. Поэтому будем пользоваться следующим определением: Тестирование ПО (англ., Software Testing) – это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов. Слово «процесс» используется для уточнения, что тести- рование – это плановая и упорядоченная деятельность. Таблица 1.1 Показатели эффективности различных методов тестирования [2] Название метода Минимальная эффективность Средняя эффективность Максимальная эффективность Персональные просмотры проектных документов Неформальные групповые просмотры Формальные просмотры проектных документов Формальные инспекции кода Моделирование и прототипирование Проверка за партой Тестирование модулей Функциональное тестирование Комплексное тестирование Тестирование в реальных условиях Применение всех перечисленных методов тестирования 1.2. Тестирование в жизненном цикле разработки программного обеспечения До начала 80-х годов процесс тестирования программного обес- печения был разделен с процессом разработки: вначале программи- сты реализовывали заданную функциональность, а затем тестиров- 7 щики приступали к проверке качества созданных программ. Такая модель жизненного цикла разработки ПО называется каскадной (или водопадной) и состоит из 5 основных этапов: разработка тре- бований к программе, проектирование, реализация, тестирование и сопровождение. Однако описанный выше подход создает множе- ство проблем. Например, разработка программ может оказаться до- статочно длительной (скажем, несколько месяцев), чем тогда в это время должны заниматься тестировщики? Другая, более серьезная проблема заключается в плохой предсказуемости результатов такого процесса разработки. Ключевым вопросом здесь может быть: какое количество времени потребуется на завершение продукта, в котором существует 500 известных ошибок? На самом деле, предугадать это совершенно невозможно, так как разные ошибки будут требовать разного количества времени на исправление, а исправление извест- ных ошибок будет неизбежно связано с внесением новых. Существу- ет следующая мрачная статистика: даже однострочное изменение в программе с вероятностью 55 % либо не исправляет старую ошиб- ку, либо вносит новую. Если же учитывать изменения любого объ- ема, то в среднем менее 20 % изменений корректны с первого раза. В связи с этим, в 90-х годах появилась другая методика разра- ботки, которую вслед за компанией Microsoft называют zero-defect mindset. Основная идея этой методики заключается в том, что каче- ство программ проверяется не post factum, а постоянно в процессе разработки. Например, программист не может перейти к разработке новой функциональности, если существуют известные ошибки вы- сокого приоритета в частях, разработанных им ранее. Так появи- лись шарнирно-каскадная (или V-образная), а также спиралевидная модели разработки ПО [2]. При такой постановке вопроса тестирование становится цен- тральной частью каждого этапа жизненного цикла разработки про- грамм: тестированию подвергаются требования к программному продукту, алгоритмы, исходные коды, модули, программные сбор- ки, функциональность программ и т. д. Практика показывает, что, чем раньше найдена ошибка, тем дешевле ее исправить. Частым примером в литературе является следующий: стоимость незамечен- ной ошибки в документе требований, которую можно оценить в 2 $, вырастает в 200 $ на этапе сопровождения, поскольку были затра- чены силы и время на все предыдущие этапы. 8 1.3. Виды тестирования программного обеспечения Долгое время основным способом тестирования программного обеспечения было тестирование методом «черного ящика» – про- грамме подавались некоторые данные на вход и проверялись ре- зультаты в надежде найти несоответствия. При этом, как именно работает программа, считается несущественным. Этот подход до сих пор является самым распространенным в повседневной практике. Наряду с этим подходом существуют методы тестирования, кото- рые изучают внутреннее устройство программы (исходные тексты, модули и их структуры). Их обобщенно называют тестированием «белого ящика». Также существует тестирование по методу «серого ящика», когда имеется частичный доступ к исходному коду (напри- мер, сторонние компоненты или автоматизация функционального тестирования через пользовательский интерфейс). В настоящее время в литературе приведена обширная классифи- кация видов тестирования ПО [3, 4, 5]. Рассмотрим одну из них по следующим признакам: 1) По знанию внутреннего устройства программы: – тестирование по методу «черного ящика»; – тестирование по методу «белого ящика»; – тестирование по методу «серого ящика». 2) По объекту тестирования: – тестирование требований к программному продукту; – тестирование исходного кода (например, обзоры кода); – модульное тестирование (проверка отдельных программных модулей); – интеграционное тестирование (проверка взаимодействия про- граммных модулей); – объектно-ориентированное тестирование (тестирование классов); – функциональное тестирование (проверка работы заявленной функциональности); – системное тестирование (проверка работы программы в реаль- ном системном окружении); – тестирование интерфейса программы; – тестирование удобства использования; – локализационное тестирование (проверка работы программы при переходах на другие иностранные языки); 9 – тестирование производительности; – тестирование безопасности; – тестирование на совместимость (или кроссплатформенное и кроссбраузерное тестирование – проверка работы программы на раз- ных операционных системах и в разных браузерах). 3) По субъекту тестирования: – тестирование, проводимое программистом (например, обзоры кода, модульное тестирование); – тестирование, проводимое тестировщиком (например, функци- ональное тестирование, тестирование производительности); – случайное тестирование (англ., ad hoc testing, проводится не участником проекта без предварительной подготовки с целью найти случайные ошибки в программе); – приемочные испытания (проводятся, как правило, заказчиком). 4) По позитивности тестов: – позитивное тестирование; – негативное тестирование. 5) По степени изолированности компонент: – модульное тестирование; – интеграционное тестирование; – системное тестирование. 6) По степени автоматизации тестирования: – ручное тестирование (проводится человеком); – автоматизированное тестирование (полностью проводится ком- пьютером); – полуавтоматизированное тестирование (проводится и компью- тером, и человеком). 7) По степени подготовки к тестированию: – тестирование по тестовым случаям; – случайное тестирование. 8) По запуску программы на выполнение: – статическое тестирование; – динамическое тестирование; 9) По хронологии тестирования: – до передачи пользователю (альфа-тестирование, тест прием- ки, тестирование новых функциональностей, регрессионное тести- рование); – после передачи пользователю (бета-тестирование). 10 Альфа-тестирование – это тестирование ПО, когда процесс разра- ботки приближается к завершению. В результате проведения такого тестирования в проект могут вноситься незначительные изменения. Бета-тестирование означает тестирование, при котором раз- работка и тестирование по существу завершены, и до окончатель- ного выпуска продукта необходимо обнаружить оставшиеся ошиб- ки и проблемы. 1.4. Смежные вопросы тестирования Об экономической стороне тестирования. Тестирование явля- ется затратной деятельностью, отнимающей время и деньги. По- этому в большинстве случаев разработчики программного обеспе- чения заранее формулируют какой-либо критерий качества созда- ваемых программ (определяют так называемую планку качества), добиваются выполнения этого критерия и затем прекращают тес- тирование, выпуская продукт на рынок. Такая концепция получи- ла название Good Enough Quality (достаточно хорошее ПО), в про- тивовес более очевидной концепции Best Possible Quality (макси- мально качественное ПО). К сожалению, принцип Good Enough Quality зачастую понимают неправильно, ближе к формулировке Quality – If Time Permits (каче- ство, если будет время). Конечно, выпуск плохо протестированного программного продукта из-за недостатка времени – это плохая практика. Опыт показывает, что пользователи склонны со временем забывать даже значительные задержки с выпуском продукта, но плохое качество выпущенного продукта запоминается на всю жизнь. На самом деле, Good Enough Quality – это просто поиск ра- зумного компромисса между затратами на тестирование, длитель- ностью разработки продукта и его качеством. Психологические аспекты тестирования. Тестирование прин- ципиально отличается от программирования по своим психологиче- ским характеристикам. Дело в том, что программирование носит конструктивный характер, а тестирование деструктивно по своей природе. Можно сказать, что программист создает, строит, а тести- ровщик ищет недостатки в этих строениях. Поэтому программисты так часто не замечают очевидных ошибок в своих программах: к своему творчеству трудно относиться критично. 11 Все это не значит, что тестирование «хуже», чем программиро- вание, или, что в процессе тестирования нет места творчеству, – просто эти виды деятельности отличаются коренным образом, и для тестирования требуется иной склад характера, чем для программи- рования. Следовательно, программист не должен тестировать свои собственные программы – для этого необходим другой человек. Более того, программист не должен тестировать даже чужие про- граммы! Дело в том, что программист потратит какое-то время, перенастраиваясь на новую задачу. Даже переключение с одной программистской задачи на другую требует обычно от 10 минут до получаса. Поэтому переключение с одного образа мышления на другой отнимет существенно больше времени. Таким образом, принято считать, что команда разработчиков не должна совпадать с командой инженеров тестирования, но при этом разработчики и тестировщики должны постоянно взаимодейство- вать друг с другом для достижения приемлемого качества оконча- тельного продукта. |