Тестирование. Ю. Б. Попова тестирование и отладка программного
 Скачать 0.6 Mb.
|
|
6.2. Требования к автоматизированным тестам Для того чтобы начинать разрабатывать автоматизированные тесты, необходимо определиться со следующими вопросами: – Какую функциональность нужно автоматизировать? – Какие действия необходимы для проведения теста? – Где брать тестовые данные? – Каков ожидаемый результат теста? – Каковы критерии успешного прохождения теста? Выделим основные требования к автоматизированным тестам: 1) Тест должен тестировать сам, т. е. не только эмулировать дейст- вия пользователя с программой, но и проводить проверки. 2) Тест должен выдавать результат в таком виде, чтобы сразу можно было понять, где ошибка. 3) Один тест должен проверять только одну функциональность либо один случай использования функциональности. 4) Каждый тест должен быть независимым (т. е. выполняться независимо от других тестов). 5) Тест должен запускаться на разных платформах и в разных браузерах. 6) Наличие документированных требований или пояснений к за- пуску теста. 7) Тест должен одинаково хорошо работать на быстрой машине и медленной. 6.3. Методы автоматизации функционального тестирования 6.3.1. Метод Play&Record Метод Play&Record (в литературе также встречается название Record&Playback) – это возможность работать в режиме записи дей- ствий, совершаемых над приложением, и повторное воспроизведение их автоматически. Записанные действия преобразуются в программ- ный код на языке программирования, который встроен в инструмент автоматизации. Последовательность шагов в этом методе такова: 1. Из инструмента автоматизации происходит захват тестируе- мого приложения. 2. Включается запись действий. 53 3. Выполняются требуемые действия над программой. 4. Останавливается запись. 5. Включается проигрывание записанных действий. Записанные действия отображаются в виде программного кода на встроенных языках программирования, в качестве которых могут быть как собственные языки инструментов, например, 4Test для инструмента SilkTest [14], так и распространенные языки програм- мирования, например, C# или JavaScript в TestComplete. В получен- ный таким образом скрипт можно вносить изменения, проверки, циклы, формировать логику теста и т. д. К недостаткам метода Play&Record можно отнести следующие: 1) Скрипты, получаемые этим методом, содержат фиксирован- ные значения, которые должны быть изменены каждый раз, когда в приложении что-то меняется. 2) Стоимость, связанная с поддержкой автоматизированных скриптов, полученных по этому методу, астрономическая и непри- емлемая, поскольку их приходится часто переписывать. 3) Полученные скрипты не надежны и часто не работают, даже если тестируемое приложение не изменялось. Причинами здесь мо- гут быть различные всплывающие окна, сообщения или другие собы- тия, которые происходили либо не происходили в момент записи те- ста, и, соответственно, которые будет ожидать скрипт во время по- вторного воспроизведения либо неожиданно произойдут для скрипта. 4) Если тестировщик совершает ошибку, например, во время ввода данных, тест должен быть записан заново. 6.3.2. Метод функциональной декомпозиции Главный принцип метода заключается в приведении всех тесто- вых случаев к некоторым функциональным задачам, которыми мо- гут быть: – навигация (например, доступ к странице заказа из главного меню); – бизнес-функции (например, оформление заказа); – проверка данных (например, проверка состояния заказа); – возврат к навигации. Таким образом, самый верхний уровень скриптов представляет собой скрипт, содержащий серии вызовов одного или нескольких 54 скриптов для конкретных тестовых случаев. Скрипты этих тестовых случаев вызывают необходимые скрипты бизнес-логики. Скрипты утилит могут вызываться в любом месте скрипта, где это необходимо. 6.3.3. Метод Data-driven Метод Data-driven (англ., Data Driven Testing, DDT, тестирова- ние, управляемое данными) является продолжением метода функ- циональной декомпозиции. Отличие состоит в том, что данные для тестов выносятся за пределы кода скрипта, как правило, в Exсel- таблицу. Например, для проверки авторизации может быть создана таблица, которая в каждой строке хранит имя пользователя, пароль и ожидаемый результат. Тогда скрипт обращается к таблице с тес- товыми данными и поочередно начинает их перебирать, выполняя нужные действия теста и сравнивая фактические результаты с ожи- даемыми. На основании проверок формируется журнал о прохож- дении тестов. 6.3.4. Метод Keyword-driven Метод Keyword-driven или тестирование, управляемое ключевыми словами, можно рассматривать как продолжение и модификацию метода Data-driven. Тестовый сценарий здесь представлен в виде электронной таблицы, содержащей в одной из колонок специальные ключевые слова, а в остальных колонках могут быть тестовые дан- ные, ожидаемые результаты и другая необходимая информация. Ключевое слово является, как правило, функцией некоторой биб- лиотеки и реализует предписанную последовательность действий. Управляющий скрипт обращается к таблице тестового сценария, на- ходит ключевое слово в нем, считывает из той же строки тестовые данные и выполняет действие, описанное этим ключевым словом. Полученный результат далее сравнивается с ожидаемым, и генери- руется отчет о прохождении теста. Затем скрипт находит следующее ключевое слово, и так до конца документа. Таким образом, реализу- ется трехслойная модель автоматизации: – 1-й слой – библиотека ключевых слов; – 2-й слой – тестовый сценарий в виде электронной таблицы; – 3-й слой – управляющий скрипт. 55 К преимуществам такого подхода можно отнести следующие: 1) тестовые сценарии могут быть реализованы в формате элект- ронной таблицы, которая содержит все данные для ввода и провер- ки, таким образом, сценарий пишется только один раз; 2) тестовые сценарии могут быть написаны в любом формате, ко- торый поддерживает конвертацию tab-delimited или comma-delimited; 3) создавать тестовые сценарии может любой тестировщик, даже не владеющий навыками автоматизированного тестирования; 4) если тестовые сценарии уже существуют в каком-либо форма- те, их не сложно перевести в формат электронных таблиц; 5) скрипты-утилиты, созданные для одного приложения, могут быть использованы с небольшими изменениями для тестирования других программ. 6.4. Семейство Selenium и его возможности В рамках семейства Selenium имеется несколько программных продуктов, которые могут быть использованы в процессе функцио- нального тестирования. Например, Selenium Server позволяет орга- низовать удаленный запуск браузера, при помощи Selenium Grid можно построить кластер из Selenium-серверов. Также имеется «ре- кордер» Selenium IDE, который умеет записывать действия пользо- вателя и генерировать код. Однако главным в семействе является Selenium WebDriver, который представляет собой библиотеку, поз- воляющую разрабатывать программы, управляющие поведением браузера. Для группировки и запуска тестов, а также для генерации отчетов о тестировании при таком подходе используются фрейм- ворки тестирования (п. 3.7). Например, JUnit или TestNG для Java, NUnit или MSTest для .Net, RSpec или Cucumber для Ruby. Разра- ботка тестов ведется, соответственно, в средах Eclipse, Intellij IDEA, MS Visual Studio, RubyMine и так далее. C целью следования принципам повторного использования тесто- вого кода и функциональной декомпозиции, программный каркас для автоматизации тестирования с использованием Selenium WebDriver разделяется на несколько слоев (рис. 6.1): слой тестов, бизнес-слой, слой для работы с пользовательским интерфейсом и слой вспомога- тельных библиотек. 56 Рис. 6.1. Схема каркаса для автоматизации тестирования с использованием Selenium WebDriver Слой тестов содержит описания сценариев в программном коде. Бизнес-слой описывает наиболее часто используемые сложные опе- рации, которые специфичны для тестируемой системы. Слой для ра- боты с элементами пользовательского интерфейса реализует взаи- модействие тестирующего кода с тестируемой системой через поль- зовательский интерфейс. Данный слой в случае веб-приложений можно реализовать на основе программного интерфейса WebDriver. 6.5. Проблемы внедрения автоматизации тестирования программного обеспечения В ходе внедрения автоматизации тестирования существует риск невозврата вложений в этот процесс. Для оценки возврата инвес- тиций используется универсальный коэффициент окупаемости ин- вестиций ROI [15]. Этот показатель является одним из основных способов измерения эффективности вложений и рассчитывается по следующей формуле: ROI = прибыль / затраты. (6.1) 57 Для успешного возврата инвестицией показатель ROI должен быть равен либо больше единицы. При внедрении автоматизации необходимо рассчитать, насколько автоматизация эффективней, чем ручное тестирование. Формула c учетом затрат принимает следую- щий вид [15]: ROI автоматизации = (X – Y) / Y, (6.2) где X – затраты на ручное тестирование; Y – затраты на автоматизацию тестирования и его поддержку. В данном случае значение успешности инвестиций начинается от нуля. Поэтому перед внедрением автоматизации можно произ- вести прогнозирование с оценкой ROI, после чего делать вывод о внедрении или не внедрении автоматизации тестирования. Также необходимо учитывать следующие факторы: – технологии, на которых построена система, а именно, наличие инструментов для их автоматизации; – потенциальную изменяемость интерфейсов системы, на кото- рых будет основываться автоматизация; – специфику проверок системы, а именно, их пригодность для автоматизации; – потенциальный объем автоматизируемых тестов; – планируемую частоту проведения тестирования; – необходимость разработки специализированных инструментов для автоматизации; – рост затрат на поддержку автоматизированных тестов; – сроки разработки. При оценке объема автоматизации и планируемого покрытия те- стами, можно прибегнуть к разбиению тестов по уровням работы с системой и по видам тестирования. В [16] приводится пример соот- ношения автоматизированных тестов в различных видах тестирова- ния на проекте по разработке ПО. Данный пример, представленный на рис. 6.2, называется пирамидой автоматизации тестов. Цель сле- дования описанному соотношению – обеспечить максимально воз- можное покрытие кода при минимальных затратах. Проблема внедрения автоматизации в короткие сроки решается использованием существующих программных каркасов для автома- тизации тестирования, перенесением опыта автоматизации с других 58 проектов, внедрением процесса разработки на основе тестов или на основе поведения. Рис. 6.2. Пирамида автоматизации тестов [16] 7. ОТЛАДКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 7.1. Методика отладки Отладка –это процесс обнаружения причин возникновения оши- бок и их последующего исправления. Отладка на некоторых проек- тах занимает до 50 % времени разработки. Это одна из самых слож- ных частей программирования. По психологическим причинам от- ладка – это самая нелюбимая работа программиста. Многие програм- мисты стремятся как можно быстрее написать программу, а затем обнаружить ошибки путем многократного ее выполнения с разно- образными тестовыми данными без их внимательного анализа и тщательного проектирования. Это приводит к значительным затра- там времени при установлении причин ошибок и их локализации, заметному снижению надежности программ, что в дальнейшем про- является на этапе сопровождения программного изделия. Кроме того, известным фактом является внесение новых ошибок при отладке. 59 В методике отладки принято выделять две части: – нахождение причины возникновения ошибки (90 % времени отладки, как правило, уходит на эту часть); – исправление причины ошибки. Наиболее эффективным считается обобщенный научный подход нахождения причин ошибок. Он состоит из следующих шагов: 1) сбор данных через повторяющиеся эксперименты; 2) создание гипотезы, отражающей максимум доступных данных; 3) разработка эксперимента для проверки гипотезы; 4) подтверждение или опровержение гипотезы; 5) итерация предыдущих шагов (при необходимости). Тогда, с учетом обобщенного научного подхода, методику отлад- ки можно описать в виде последовательности следующих этапов: 1. Стабилизация ошибки (1-й шаг обобщенного научного подхода). 2. Обнаружение точного места ошибки (2–4 шаги обобщенного научного подхода). 3. Исправление ошибки. 4. Проверка исправления. 5. Поиск похожих ошибок. При стабилизации ошибки рекомендуется свести тест к мини- мально возможному. Если проблема возникает не стабильно, то ее практически невозможно диагностировать. Однако статистика по- казывает, что нестабильные ошибки обычно связаны с проблемами инициализации или висячими указателями. В качестве рекомендаций по обнаружению точного места ошиб- ки можно предложить следующие: – используйте все доступные данные при выдвижении гипотез; – воспроизведите ошибку различными способами; – используйте результаты негативных тестов; – проведите «мозговой штурм» в поисках новых гипотез; – сужайте подозрительные фрагменты кода; – внимательнее отнеситесь к тем методам и функциям, где уже встречались ошибки; – проверяйте недавние исправления; – проводите интеграцию постепенно; – ищите типичные ошибки; 60 – обсудите проблему с коллегами; – отдохните от проблемы. В настоящее время синтаксические ошибки все реже приходится искать вручную, однако, если все же такое произошло, то не дове- ряйте номеру строки с ошибкой, на которую указывает компилятор, смотрите ±1 строку, также внимательнее отнеситесь к предупреж- дениям компилятора; используйте метод «разделяй и властвуй»; ищите лишние комментарии или кавычки. Когда месторасположение ошибки определено, можно перехо- дить к исправлению. Здесь рекомендации могут быть следующими: – разберитесь в проблеме, прежде чем ее исправлять; – разберитесь в программе, а не только в проблеме; – убедитесь в правильности диагноза до исправления; – не торопитесь при внесении исправлений; – сохраняйте исходную версию кода; – исправляйте проблему, а не ее симптом; – вносите исправления только тогда, когда вы уверены; – вносите исправления только по одной штуке за раз; – проверяйте свои исправления; – ищите похожие ошибки. 7.2. Методы отладки Большинство ошибок можно обнаружить по косвенным призна- кам посредством тщательного анализа текстов программ и резуль- татов тестирования без получения дополнительной информации. При этом используют различные методы: – ручного тестирования; – индукции; – дедукции; – обратного прослеживания. Метод ручного тестирования (также встречается названиеметод «грубой силы»)– это самый простой и естественный способ, наибо- лее распространенный и традиционно используемый программис- тами. Всесторонний анализ за столом исходного кода и алгоритма программы, выходных результатов и сообщений компилятора, вы- 61 полнение тестируемой программы вручную, используя тестовый на- бор, при работе с которым была обнаружена ошибка. Для повышения эффективности отладки в текст программы включают операторы отладочного кода, которые регистрируют результаты использования конкретного оператора. Довольно часто проводят распечатку выбо- рочных значений переменных. После завершения отладки отладоч- ные операторы можно оставить в виде комментариев для дальней- шего использования на этапе сопровождения. Данный метод эффективен, однако трудно применим для больших программ, программ со сложными вычислениями, а также в тех слу- чаях, когда ошибка связана с неверным представлением програм- миста о выполнении некоторых операций. Данный метод часто ис- пользуют как составную часть других методов отладки. Метод индукции основан на тщательном анализе симптомов ошибки, используя стратегию движения от частного к общему. Если компьютер просто «зависает», то фрагмент проявления ошибки вы- числяют, исходя из последних полученных результатов и действий пользователя. Полученную таким образом информацию организуют и тщательно изучают, просматривая соответствующий фрагмент про- граммы. В результате этих действий выдвигают гипотезы об ошиб- ках, каждую из которых проверяют. Если гипотеза верна, то детали- зируют информацию об ошибке, иначе – выдвигают другую гипо- тезу. Организуя данные об ошибке, целесообразно записать все, что известно о ее проявлениях, причем фиксируют как ситуации, в ко- торых фрагмент с ошибкой выполняется нормально, так и ситуации, в которых ошибка проявляется. Если в результате изучения данных никаких гипотез не появляется, то необходима дополнительная ин- формация об ошибке. Дополнительную информацию можно полу- чить, например, в результате выполнения схожих тестов. В процес- се доказательства пытаются выяснить, все ли проявления ошибки объясняет данная гипотеза, если не все, то либо гипотеза не верна, либо ошибок несколько. Метод дедукции реализует формирование множества причин, которые могли бы вызвать данное проявление ошибки. Затем ана- лизируются причины и исключаются те, которые противоречат имеющимся данным. Если все причины исключены, то следует вы- полнить дополнительное тестирование исследуемого фрагмента. В противном случае наиболее вероятную гипотезу пытаются доказать. 62 Если гипотеза объясняет полученные признаки ошибки, то ошибка найдена, иначе – проверяют следующую причину. Метод обратного прослеживания (или инверсное прослежива- ние логики программы) наиболее эффективен для небольших про- грамм и направлен на анализ логики выполнения программы в об- ратном направлении. Отладка начинается с точки программы, где обнаружен неверный ожидаемый результат. На основе полученных в этой точке значений переменных, необходимо определить, исходя из логики программы, какие результаты должны были быть при правильной работе программы. Последовательное продвижение к на- чалу программы позволяет достаточно быстро и точно определить место (и причину возникновения) ошибки, т. е. место между опера- тором, где результат выполнения программы соответствовал ожи- даемому, и оператором, в котором появились расхождения. Процесс продолжают, пока не обнаружат причину ошибки. |