Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 12: Планирование и документация 2 9 9 Важные типы тестирования "черного ящика" На рис. 12.2 перечислены не которые наиболее важные сос тавляющие хорошего плана тестирования. Собственно говоря, речь идет не об одном документе, а о целой группе. Большая часть перечисленных составляющих уже описывалась в этой книге, главным образом в главе 3. Что же касается бета-тес тирования, то о нем рассказывает ся в главе 13. Здесь же мы приведем лишь несколько допол нительных замечаний. • Приемочное тестирование. Когда первая версия продукта передается вашей группе, она первым делом проходит приемочное тестирование. Проблема состоит в том, что руководитель проекта стремиться передать продукт на тестиро вание как можно скорее, чтобы пораньше загрузить вас работой. Однако если в группе мало персонала, а продукт еще очень неста билен, можно вернуть его назад программистам и настаивать на том, чтобы тестирование началось только после достижения разумной степени стабильности. Приемочные тесты лучше всего распространить среди заинтересо ванных сотрудников, чтобы ваши критерии были всем известны и программисты могли сами выполнить эти тесты и быть уверенными, что программа готова к более серьезным испытаниям. Перед тем как направить на тестирование очередную версию, приемочные тесты будут выполнять и руководители проекта, особенно если они будут знать, что не прошедшую их программу вы просто никогда не примете. Приемочные тесты охватывают только наиболее важные действия программы и позволяют выявить самые очевидные ошибки. На их выполнение уходит несколько часов и лишь для особенно сложных систем — до нескольких дней. Именно эти тесты являются первы ми кандидатами на автоматизацию. 3 0 0 Часть II: Приемы и технологии тестирования • Управление потоком. Вопрос об управлении потоком — это вопрос о том, как перевести программу из одного состояния в другое. Те- стировщики главным образом имеют дело с видимым управлением потоком, а не с внутренней структурой программы. Какими спосо бами можно открыть данное диалоговое окно? Какие последователь ности команд меню позволят распечатать информацию? Какие опции и команды позволяют перевести программу в данное состо яние? • Функциональность. Анализ функциональности программы позволяет сказать, удовлетворяет ли она требованиям и ожиданиям пользова теля. Например, игра может обладать исключительно простым и удобным интерфейсом, не иметь ошибок, мгновенно реагировать на действия пользователя, обладать прекрасным звуком и графикой, но, если при этом играть в нее будет неинтересно, такая игра ничего не стоит и на ее коммерческий успех рассчитывать не придется. Стратегия разработки компонентов тестового плана Изложенные в этой книге сведения можно прекрасно дополнить кни гами таких авторов, как Эванс (Evans, 1984) и Хезел (Hetzel, 1988). У них иной, но не менее полезный и практичный подход к планированию тести рования. Поступательная разработка тестовых материалов В традиционной литературе о разработке программного обеспечения утверждается, что настоящая команда разработчиков следует методу водо пада. Этот метод предполагает, что проект проходит ряд последовательных фаз — от анализа требований до создания проектных документов, за кото рыми следует кодирование, окончательное тестирование и выпуск. Однако на практике все не так просто, и далеко не всегда удается при держиваться четкой последовательности этапов. Подробнее об этой пробле ме можно прочитать в превосходной книге Тома Гилба (Tom Gilb, Principles of Software Engeneering Management, Addison-Wesley, 1988) и его статьях. (Можно также обратиться к таким авторам, как Голд и Льюис (Gould & Lewis, 1985) и Бейкер и Бакстон (Baecker & Buxton, 1987, глава 11)). В качестве альтернативы традиционному подходу Гилб предлагает раз бить программу на маленькие фрагменты и по очереди проектировать, писать и отлаживать каждый из них в комплексе с уже готовой частью программы. Таким образом, у вас постоянно будет целостная и работающая система. Если добавлять к ней функции в порядке их приоритета, вы все гда будете знать, что самая важная работа уже выполнена. Со временем Глава 12: Планирование и документация 3 0 1 программа вырастет в надежный и полезный продукт с богатыми возмож ностями. Вы же сможете постоянно расширять требования и совершенство вать проект, понимая по ходу разработки, каким он должен быть. И обратите внимание, что стоимость этих усовершенствований будет исклю чительно низкой! В следующей главе мы еще вернемся к обсуждению методологии раз работки продукта, а в этой сосредоточимся главным образом на плане тестирования. Независимо от метода разработки продукта в целом, его тестирование и, в частности, разработку тестового плана лучше всего вы полнять эволюционным способом. Вместо того чтобы разрабатывать один большой тестовый план, можно начать с одной из его составляющих и постепенно расширять этот документ, добавляя в него все новые и новые разделы. Разработав первую часть плана, можно приступить к поиску ошибок на его основе. Следующие разделы будут углублять и расширять области поиска. Лучше всего добавлять разделы в план в порядке их при оритета, чтобы к тому моменту, когда руководитель объявит, что тестиро вание окончено и продукт выходит в свет (а это может случиться в любой момент), вы были уверены, что все наиболее важные тесты уже выполне ны. Такой эволюционный подход, на наш взгляд, гораздо эффективнее традиционного метода водопада, даже если остальная часть команды раз работчиков следует этому второму методу. Однако имейте в виду, что это вопрос спорный. • Канер (Капег) и Фолк (Folk) полагают, что для тестирования при кладного программного обеспечения эволюционный подход всегда лучше. • Нгуйен (Nguyen), напротив, рекомендует метод водопада, предлагая сначала написать полный план, утвердить его и только после этого приступать к тестированию. Он считает, что это особенно важно, когда весь процесс разработки ведется по настоящему методу водо пада. Настоящий метод водопада означает, что началу разработки тестового плана предшествует утверждение полной и подробной спецификации. В больших проектах часто именно так и бывает. Если же спецификация не так подробна или предполагается, что по ходу дела она без предупреждения будет меняться, Нгуйен также рекомендует эволюционный подход к тестированию. Похоже, что традиционный взгляд на вещи предполагает обязательное следование методу водопада, независимо от того, как организован весь проект в целом. Это означает, что до тех пор, пока тестовая документация не будет завершена, никто не должен приступать к тестированию продук- та, даже если он уже вполне готов к этому. А тестировщики соответствен- 3 0 2 Часть II: Приемы и технологии тестирования но должны требовать полную спецификацию продукта, иначе они не смогут приступить к разработке своего плана. К сожалению, традиционный подход не учитывает реалий разработки, прикладного программного обеспечения. А эти реалии включают следую- щие факты. • Прикладные программы разрабатываются в короткие сроки и неред ко довольно неупорядоченно. И разработка, и тестирование начина- ются до того, как заканчивается работа над документацией. Более того, спецификация может и вовсе никогда не быть завершена. Изменения требований рынка в любой момент могут повлечь за собой пересмотр ключевых особенностей программы, поскольку главным и фактически единственным важным требованием являет- ся ее конкурентоспособность. • Не во власти тестировщика или даже руководителя группы тестиро- вания изменить философию компании. Итак, главное, чему следует научиться, — это максимально эффектив но выполнять свою работу в существующих условиях. По нашему же опыту лучше всего этому способствует эволюционный подход к тестированию. Следует упомянуть о двух главных преимуществах эволюционной раз работки тестового плана. • При тестировании методом водопада вы сначала обдумываете и планируете всю работу и только затем приступаете к ее выполне- нию. На бумаге все выглядит прекрасно, но на деле можно узнать продукт как следует только после его хотя бы краткого тестирова ния. Не может же планирование работ предшествовать изучению продукта. Таким образом, наиболее последовательным является как раз эволюционный метод, позволяющий проектировать будущую работу на основе уже полученного опыта. • Предположим, что у вас в руках прекрасная спецификация, напи санная в самом начале разработки. (Именно так и должно обстоять дело, если следовать методу водопада.) Вы приступаете к написанию плана параллельно с программированием, чтобы к моменту его за вершения быть готовыми начать тестирование. Однако в течение первого года разработки в спецификацию вносятся серьезные изме нения, вызванные техническими проблемами и изменениями требо ваний рынка. В результате львиную долю средств, выделенных на тестирование, придется потратить на переработку тестового плана. Этого не случится, если работать эволюционным методом и плани ровать тесты по мере того, как будет приближаться их черед выпол нения. Глава 12: Планирование и документация 3 0 3 Быстрота реализации проекта является важнейшей составляющей обще го качества проведения работ. (Подробное обсуждение этого вопроса мож но найти у Джурана (Juran, 1989, с. 49). ) Как правило, эволюционный подход к тестированию и разработке тестового плана является наиболее быстрым и дешевым способом, позволяющим приступить к работе сразу же по завершении кодирования и сделать эту работу хорошо. Начальная разработка тестовых материалов Итак, используемый нами подход предполагает проведение тестирова ния параллельно с работой над его планом. При этом ни одно из этих двух дел не должно слишком далеко уходить вперед. Посвятив день планирова нию, проведите все же пару часов за компьютером, проверяя свои идеи на деле. А концентрируясь на тестировании, держите под рукой блокнот для записи новых идей. Еще лучше работать сразу с двумя компьютерами, используя один для тестирования, а другой для работы над планом. Таким образом, не пропадет ни одна из хороших идей, пришедших вам в голову в ходе работы, и все они будут реализованы наилучшим образом. Поначалу тестовый план может выглядеть просто как набор заметок. Но со временем — по мере того, как вы будете получать все больший опыт работы с про граммой, все больше о ней узнавать и находить все больше и больше ошибок — он будет приобретать все более организованный вид. На рис. 12.3 показаны первые шаги разработки тестового плана. Рабо та начинается с поверхностного знакомства с программой — выполнения всех ее основных команд и опробования всех основных режимов. Постарайтесь понять, с какими проблемами столкнутся ее пользовате ли в течение первых двух часов работы. Эти проблемы лучше всего решить как можно раньше. • Тестирование по документации. Начните со сравнения поведения программы с имеющимся черновиком руководства пользователя. Если у вас есть спецификация, сверьте программу и с ней. Пройди тесь по руководству строчка за строчкой, делая все, что в нем напи сано, нажимая каждую упомянутую клавишу. Невероятно, как много 3 0 4 Часть II: Приемы и технологии тестирования проблем выявляется в ходе этой работы. К тому же ее результаты оказывают неоценимую помощь как программистам, так и техничес ким писателям. • Начните разработку тестовой документации с организационного материала, например, со списка функций программы. В этот список включается все, что должна делать программа. Старайтесь ничего не упустить, поскольку полнота этого списка будет определять полно ту тестирования продукта. Однако поначалу список будет далеко не полным. Вам будет не хватать глубины знания продукта, и к тому же часть его функций будет просто не документирована. В дальнейшем список будет расширяться и в конечном счете охватит все функции программы. Об этом постепенном расширении списка функций мы еще поговорим в одном из следующих разделов. • Выполните простейший анализ граничных условий. Подумайте об; ограничениях, которым соответствуют вводимые программой дан- ные. Если программа не разрушается, попробуйте ввести значения,; выходящие за эти границы. В черновиках пользовательского руко водства ограничения обычно не указаны. Что же касается специфи кации, то слишком уж часто разработчики не оставляют от перечисленных в ней требований камня на камне. Поэтому, тести- руя программу, придется ориентироваться только на реальные гра- ницы данных. Запишите, какими они оказались, и покажите свои] заметки техническим писателям или программистам, чтобы согласо вать окончательный вариант поведения программы и внести изме нения либо в нее саму, либо в документацию и собственные' тестовые примеры. Итак, начинайте с построения основ. Для работы с планом выберите инструмент, позволяющий с легкостью просматривать и реорганизовывать его компоненты. На этом первом этапе вы обязательно будете тестировать программу, хотя и не слишком тщательно. Все же это позволит выявить ряд наиболее очевидных проблем, которые лучше всего устранить как можно раньше. А далее план будет углубляться и расширяться, пока не превратит ся в прекрасно организованную тестовую документацию. Что дальше? Итак, первоначальное знакомство с программой завершено. Что же дальше? Каковы следующие наиболее важные области тестирования? На чем следует сосредоточить внимание и дальнейшие усилия? К сожалению, волшебной формулы здесь нет. Все зависит от ваших знаний и инстинкта тестировщика. Можно только сказать, что, скорее всего, вы приступите к работе над одной из шести областей, показанных на рис. 12.4. Глава 12: Планирование и документация 3 0 5 • Наиболее вероятные ошибки. Если известно, что в определенной части программы очень много ошибок, поработайте прежде всего с ней. Внутри программы ошибки обитают колониями. В ходе иссле дований, проведенных Майерсом (Myers) в 1979 году, 47% ошибок было найдено в 4% всех модулей системы. Это пример, иллюстри рующий совершенно реальную тенденцию — чем больше ошибок обнаружено в определенной области программы, тем больше их еще предстоит там найти. И даже вносимые исправления с большей чем обычно вероятностью влекут за собой новые ошибки. Те области, которые в ходе первоначального тестирования показали себя наибо лее слабыми, останутся такими и в дальнейшем. Поэтому лучше всего начать с ними работать как можно раньше и как можно обсто ятельнее. • Наиболее заметные ошибки. Можно поступить и иначе — прежде всего сконцентрироваться на тех ошибках, которые более всего за метны пользователю или наиболее негативно скажутся на его работе и на его впечатлении о продукте. Подумайте, какие части програм мы будут использоваться чаще других, какие ее возможности выгод но отличают ее от конкурентов и какие функции наиболее важны для пользователя. Те из функций, которые сами по себе хороши, но не являются жизненно важными компонентами продукта, можно протестировать во вторую очередь. Если они не работают, это, ко нечно, плохо. Но гораздо хуже, если не функционируют базовые элементы продукта, ведь тогда это вообще не продукт. • Наиболее часто используемые области программы. Ошибки в этих областях повторяются без конца. Поэтому, даже если они не особен но серьезны, пользователь вскоре почувствует раздражение. • Отличительные особенности программы. Если вы продаете базу данных и утверждаете, что она сортирует таблицы в 48 раз быстрее, чем продукты конкурентов, функцию сортировки следует протести ровать особенно тщательно. Если сортировка и в самом деле выпол няется быстро, но неправильно, вряд ли это понравится пользователям. Высоко оптимизированные фрагменты кода являют- 3 0 6 Часть II: Приемы и технологии тестирования ся потенциальным источником ошибок, которые к тому же трудно исправлять. Поэтому чем раньше вы сообщите о подобных ошибках, тем лучше. • Сложнейшие для тестирования аспекты. Поговорите с программи стом и спросите у него, есть ли в программе особенно сложные области, об ошибках в которых ему не хочется даже думать. Впол не возможно, что он расскажет вам о таких областях. В этом случае возьмитесь за их тестирование как можно раньше, как минимум за несколько месяцев до окончательного выпуска продукта, чтобы у программиста было достаточно времени на исправление найденных там ошибок. Иначе, если вы найдете в такой области ошибку за неделю до выпуска, у программиста будет инфаркт или он уволит ся и ошибка так и не будет исправлена. • Самые понятные для вас функциональные области. Возможно, вы читали программный код или хорошо знакомы с продуктами подоб ного типа. Это значит, что отдельные области программы вам на столько хорошо знакомы, что вы готовы немедленно приступить к их тестированию. Так и поступайте. С остальными составляющими программы вы познакомитесь по ходу тестирования. Работая с наи более понятной частью программы, постарайтесь разобраться, как она взаимодействует с остальными частями. В результате, даже если выбранная область не является критической, вы приобретете хоро ший опыт, выявите ряд ошибок и в дальнейшем быстрее разберетесь с остальными составляющими продукта. Углубление тестового плана Тестовый план можно углубить путем добавления к нему разнообразных компонентов: списков функций, других рабочих списков, деревьев приня тия решений, диаграмм граничных условий, тестовых матриц и т.д. Все это — ваши средства анализа программы и выделения необходимых тестов. • В следующем разделе, "Компоненты плана тестирования", расска зывается о назначении всех этих компонентов и о том, как их раз рабатывать. Вы узнаете о том, какую роль в их создании играет эволюционный подход. • После описания отдельных компонентов речь пойдет об их объеди нении в различных типах плановых документов. • Затем предмет дискуссии расширяется, охватывая организацию те стового проекта и назначение приоритетов отдельным задачам. Эти вопросы освещаются в главе 13. В этой же главе, в нескольких разделах, посвященных проведению тестирования после выпуска альфа-версии продукта, продолжается дальнейшее рассмотрение процесса разработки тестового плана. Глава 12: Планирование и документация 3 0 7 Компоненты плана тестирования В этом разделе описываются строительные блоки тестовой документа ции. Весь процесс планирования организован вокруг четырех базовых ти пов диаграмм, примеры которых приведены на рис. 12.5: • списки; • таблицы; • планы; • матрицы. Все это очень краткие документы. Они показывают, что необходимо знать о тестируемой программе. Эти документы позволяют быстро органи зовать работу, а также выделите вопросы, которые вы не понимаете, и те, в которых разбираться не обязательно. Теоретически все эти списки и таблицы можно составить на основе спецификации. Однако на самом деле именно они помогли бы вам выявить "бреши" в спецификации, если бы кто-нибудь попросил вас ее проанали зировать. На самом деле лишь в очень редких случаях спецификации прикладных программных продуктов настолько подробны, чтобы по ним можно было составить все перечисленные документы. В результате на их формирование уходит львиная доля времени, выделенного на планирование вашей рабо ты. Тем не менее, они исключительно важны, а потому мы настоятельно рекомендуем взять их разработку за нерушимое правило. Увлекшись разработкой списков и таблиц, ничего не стоит выбиться из рабочего графика, так как процесс этот трудоемкий, а анализируемый материал очень объемен. 3 0 8 Часть II: Приемы и технологии тестирования Поэтому мы рекомендуем составлять таблицы постепенно, параллель но с тестированием продукта. Прежде всего формируются основы всех базовых документов, а затем они постепенно дополняются ранее неизвес тным фактами и новыми уровнями детализации. Этот эволюционный под ход мы проиллюстрируем несколькими примерами. Глава 12: Планирование и документация 3 0 9 Большая часть информации попадает в наши таблицы из спецификации, заметок разработчиков, черновиков руководства пользователя и другой до кументации к продукту, а также из устных бесед с программистами и ру ководителем проекта. Еще одна значительная часть информации, иногда до 75%, является результатом собственного опыта тестировщиков, полученного в ходе экспериментов с программой. Такова действительность: вы выпол няете тесты, ищите граничные условия, комбинируете входные данные и формируете отчеты таких форматов, каких руководитель проекта никогда и не предполагал. Иногда, хотя и далеко не всегда, руководитель проекта может проанализировать полученные вами результаты и сказать, можно ли считать поведение программы правильным. В большинстве случаев вам придется решать это самим. Если вам покажется, что определенные дей ствия программы нелогичны или недопустимы, составляйте отчет об ошиб ке. Если же вы не уверены в своем впечатлении, пометьте отчет как Вопрос. И последнее замечание. Составив списки и таблицы, передайте их ав торам пользовательской и технической документации. Вся эта информация им очень нужна. Скорее всего, они отблагодарят вас, предоставив собствен ные таблицы и схемы, и будут держать вас в курсе собственных открытий и недокументированных изменений программы. Списки Написать список достаточно легко. Главное, ничего не упустить и вклю чить в него все необходимые элементы. Зато после того, как это сделано, вы будете избавлены от необходимости постоянно о них помнить. Списки отчетов и экранных форм Самым первым делом составляются два важнейших списка, отражаю щих ключевые функции программы, это списки входных и выходных форм. В первый из них включаются все экранные формы ввода данных, и в том числе диалоговые окна. Во второй входят все отчеты — как печатные, так и выводимые на экран или в файлы. Опираясь на эту информацию, можно затем составить список всех переменных, которые программа ото бражает и печатает, и всех переменных, значения которых вводятся пользо вателем. На рис. 12.6 приведен пример списка отчетов системы отслеживания проблем. Этот простой список исключительно важен. Ведь, тестируя сис тему, придется проверять каждый отчет по многу раз: как минимум по одному разу на каждом цикле. А раз так, вам не обойтись без такого кон трольного списка — иначе как гарантировать, что ни один из отчетов не будет пропущен? Кроме того, если отчеты будет генерировать другой тес- тировщик, вам необходимо будет дать ему их список, особенно если сам он мало знаком с программой. 3 1 0 Часть II: Приемы и технологии тестирования Список входных и выходных переменных Составьте список всех переменных, значения которых вводятся про граммой — будь то через экранные формы, диалоговые окна или каким- либо иным способом. Примером такой переменной может быть Номер отчета о проблеме. Этот номер у каждого отчета свой, но у любого отчета он обязательно имеется. Каждое поле отчета о проблеме представляет со бой отдельную переменную, значение которой задается при вводе отчета либо вами, либо самой системой. Тестируя систему отслеживания проблем, вы составляете список всех ее переменных, начиная, конечно, с формы отчета о проблеме (рис. 5.1 из главы 5). Часть их перечислена на рис. 12.7. Структурой отчета определяется, что одни из его переменных могут содержать только числа, такие как Номер отчета о проблеме, другие предназначены для ввода нескольких строк текста, такие как переменная Подробное описание проблемы и как ее воспроизвести. Глава 12: Планирование и документация 3 1 1 Если программа читает данные с диска, выясните у руководителя про екта, какова структура соответствующих файлов. Включите в список и те переменные, значения которых вводятся из файлов. По мере углубления тестирования стоит подумать о написании собственной тестовой програм мы, непосредственно читающей файлы данных и проверяющей коррект ность их содержимого. Формат файлов данных нередко меняется в ходе разработки, причем руководитель проекта вполне может забыть вас об этом предупредить, а может и сам быть не в курсе этих изменений. Подобные случаи — прекрасная возможность найти новые ошибки. Обязательно следует составить список и всех выходных переменных, печатаемых в отчетах, выводимых на экран в ответ на запросы пользова теля и передаваемых другим задачам или даже другим компьютерам. Рассмотренные нами списки представляют собой перечень тех перемен ных, которые подлежат непосредственному тестированию. Однако они не содержат всех необходимых сведений об этих переменных, и в частности, следующих. • В списках ничего не сказано о том, где искать перечисленные в них переменные (в каком диалоговом окне или отчете). Эта информация вносится в отдельные таблицы, такие как на рисунках 12.11—12.13. • Из них не видно, каковы допустимые и недопустимые значения каждой переменной. Для их описания служат диаграммы, подобные приведенным на рис. 12.17. • В них не отражены взаимосвязи между входными и выходными значениями. (Например, в поле Проблема сводного отчета выводят ся данные из одноименного поля исходного отчета о проблеме. Разумеется, не всегда выходная переменная имеет то же имя, что и входная, однако выходные данные всегда так или иначе формируют ся на основе входных, и эти алгоритмы должны быть вам известны.) Нередко выходная переменная является просто копией одной из входных, однако их связи могут быть и гораздо более сложными. Рассмотрим систему, выписывающие счета за сделанные по почте заказы. Ее входными документами могут быть заказы, а входными переменными — наименования и цены заказываемых товаров. Вы ставляемый заказчику счет содержит набор выходных переменных. Одна из них — это общая стоимость покупки, вычисленная на ос нове цен отдельных элементов. Вторая — это сумма налога, которая, хотя и не отражает прямо значения входных переменных, все же вы числяется на их основе. Третьей переменной может быть итоговый баланс, включающий общую стоимость покупки с налогом и, воз можно, задолженность после предыдущих покупок. Заметьте, что за долженность извлекается из файла данных, а не из текущего заказа клиента. 3 1 2 Часть II: Приемы и технологии тестирования Взаимосвязи между входными и выходными переменными лучше всего описываются в форме таблицы ввода/вывода, примеры кото рой приведены на рисунках 12.2 и 12.3. Несмотря на то что в базовом списке переменных отсутствуют подроб ные сведения о каждой из них, этот список исключительно полезен. Преж де всего, он является основой построения ряда более подробных таблиц. Кроме того, как минимум на первых трех циклах тестирования у вас про сто не будет времени на сбор всей этой детализирующей информации. Единственным контрольным средством будут списки переменных ввода/ вывода. Тесты для каждой из них придумываются на ходу, а допустимые значения определяются интуитивным и пробным путем. Разумеется, эти тесты не будут такими обстоятельными и элегантными, как те, которые вы затем включите в тщательно продуманные планы, однако для начала они вполне подойдут. Следует добавить, что на начальных этапах тестирования у вас не бу дет ни времени, ни достаточного знания программы для того, чтобы соста вить абсолютно полный список переменных. Рассматривайте то, что получится, лишь как первую версию. В дальнейшем наверняка будут обна руживаться новые диалоговые окна, новые отчеты, новые файлы данных, а также измененные версии тех диалоговых окон, отчетов и файлов, кото рые вы уже включили в свои списки. Список возможностей и функций Прежде всего составьте список тех функций программы, которые оче видны для ее пользователя. Включите в него все команды меню, парамет ры командной строки, всевозможные кнопки и опции и т.п. — все значительные возможности, имеющиеся у программного продукта. Это будет список функций самого верхнего уровня. Позднее вам предстоит составить список подфункций и подподфунк- ций. В конечном счете получится подробный и строго структурированный перечень всех возможностей продукта. (Мы рекомендуем пользоваться для его создания специальным процессором иерархических списков или пла нов.) Полный список функций будет вашим путеводителем по программе и одновременно контрольным инструментом для прохождения каждого цикла тестирования — он поможет ничего не забыть и одновременно позволит отмечать, что уже пройдено и что еще осталось. В случае с системой отслеживания проблем первый черновик списка функций может выглядеть так, как на рис. 12.8. В нем всего десяток эле- ментов. Однако следующие версии этого списка будут уже гораздо более полными. Глава 12: Планирование и документация 3 1 3 Список сообщений об ошибках Составьте список всех гене рируемых программой сообще ний об ошибках. Если этот список нельзя будет просто по лучить у руководителя проекта в готовом виде, попробуйте вос пользоваться утилитой, которая извлекает текстовые сообщения из исполняемого файла, а перед этим выясните у программис тов, имеются ли в программе файлы ресурсов: возможно, что все сообщения последовательно перечислены в одном из таких файлов. Если же сообщений не будет нигде, кроме кода, а он в исполняемом виде по какой-либо причине не поддается анализу с помо щью утилит поиска текста, попросите у руководителя проекта, чтобы он предоставил вам исходный код программы. Вы обязаны протестировать каждое состояние программы, которое приводит к сообщению об ошибке. Обязательно заставьте ее вывести все возможные сообщения. Прочтите их внимательно. Достаточно ли они адек ватны и информативны? Как ведет себя программа после вывода сообще ния об ошибке? Восстанавливает ли она свою работоспособность и правильно ли она это делает? Будьте готовы к тому, что обработка ошибочных ситуаций окажется хуже всего сделанной частью программы — непродуманной и кишащей ошибками. Поэтому важно как следует продумать свой инструментарий: лучше всего для тестирования этой части программы подойдет не просто список сообщений об ошибках, а подробная таблица для проверки коррек тности восстановления программы поле каждой из ошибочных ситуаций. Чуть позже мы рассмотрим пример такой таблицы, чтобы было понятнее, о чем идет речь. Список файлов программы Дату и время создания файлов программы и тех их версий, которые описаны в вашей документации, следует периодически сравнивать. Даже если руководитель проекта и будет предоставлять вам списки вносимых в эти файлы изменений (что вполне вероятно), его список может быть непол- 3 1 4 Часть II: Приемы и технологии тестирования ным. Если вам известно, с какими данными или функциональными обла стями программы связан каждый из файлов, сравнение их версий позволит быть в курсе изменений программы, а значит, и потенциальных ошибок. Иногда все файлы программы перечисляются в ее документации. Если в вашем случае это так, сравните этот список со своим и передайте авто рам документации перечень расхождений. Перед выпуском программы вы ОБЯЗАНЫ убедиться, что на дистрибутивный диск помещены самые последние версии программных файлов. Вы себе даже не представляете, как часто компании распространяют диски не с теми файлами, и вынуждены эти файлы заменять. Это очень неприятно и очень дорого. Конечно, получив комплект дистрибутивных дисков в самую последнюю минуту, так и хочется отослать их на размно жение, выполнив лишь самую поверхностную проверку. Но не поддавайтесь этому искушению. Проверьте всю информацию самым тщательным образом. Ведь речь идет о результате всей вашей работы! Список совместимого оборудования Составьте список компьютеров, принтеров, мониторов и всех прочих устройств, с которыми должна работать тестируемая вами программа. Об ратитесь к главе 8 — в ней вы найдете много полезных сведений о тести ровании аппаратного обеспечения. Список совместимых программ Составьте список всех программ, с которыми тестируемая вами про грамма должна успешно работать. Протестируйте каждую из них на совме стимость. Расширяя этот список в ходе дальнейшего тестирования, внесите в него не только программы, но и их взаимодействующие компоненты. Вообще, понятие совместимости двух программ может иметь различный смысл. • Обе программы сосуществуют в памяти компьютера. • Одна из программ читает файлы данных другой. • Программы обмениваются сообщениями. • Программы должны хранить данные в одном и том же формате. • В программах одинаковые команды выполняются с помощью оди наковых клавиатурных комбинаций. • Программы следуют одним и тем же соглашениям о пользователь ском интерфейсе. Глава 12: Планирование и документация 3 1 5 Список совместимого операционного окружения Под управлением каких операционных систем может работать тестиру емая вами программа. С какими версиями этих систем она совместима? Если ряд версий операционной системы адаптирован к определенному аппаратному обеспечению, с какими из них необходимо протестировать программу? Что, если одна из компаний выпускает операционную систе му, совместимую с той, для которой разрабатывается ваш продукт, — сле дует ли протестировать его с этой системой? Поверх операционной системы может работать целый ряд резидентных утилит. Эти дополнительные программы управляют сетью, различными внешними устройствами или же расширяют базовый интерфейс ОС. На пример, поверх командно-ориентированной операционной системы может работать графическая пользовательская оболочка. Для полноценного тестирования вам понадобится полный список всех операционных систем, утилит, драйверов и интерфейсных оболочек, с которыми должен работать продукт. Если позволяет время, организуйте информацию в таблицы, отражающие связи между всеми этими компонен тами (например, какая оболочка для какой операционной системы долж на запускаться). Перечень материалов В перечень материалов включается все, что входит в комплект постав ки программного продукта, проще говоря, все, что пользователь найдет в коробке. Это прежде всего все диски, а также все рекламные листовки и буклеты, документация, странички исправлений, наклейки на коробке и все остальное, что является частью программного продукта. Все перечисленное в списке материалов вы обязаны проверить. Строго следуя этому списку, вы гарантированно ничего не упустите. Список публикуемых документов Все связанные с программой документы, которые выйдут за пределы вашей компании, также подлежат самой тщательной проверке. Это анон сы, реклама, пользовательская документация, различные буклеты, листки с ответами группы технической поддержки, материалы, рассылаемые по почте, руководства по диагностике и сопровождению продукта, инструкции по его установке, пресс-релизы, копии изображений на коробке и наклей ках и многое другое. Список всех этих материалов поможет ничего не забыть и вовремя проверить каждый из них. 3 1 6 Часть II: Приемы и технологии тестирования Таблицы У списков есть один недостаток — информация в них не организована. и связи между их отдельными элементами никак не видны. Свою роль напоминания и контроля они выполняют прекрасно, но там, где важны связи, удобнее воспользоваться табличной формой организации информации. Для иллюстрации процесса формирования и использования таблиц да вайте предположим, что разработчики системы отслеживания проблем модифицировали ее таким образом, что она автоматически печатает отче ты в определенные дни. Это усовершенствование необходимо протестиро вать, т.е. убедиться, что отчеты действительно печатаются вовремя. Самой естественной схемой для вашей работы и будет приведенная на рис. 12.9 таблица. Таблица отчетов В таблице на рис. 12.9 перечислены те же отчеты, что и в списке на рис. 12.6. Все это — отчеты, генерируемые системой отслеживания проблем. Однако в таблице есть место и для дополнительной информации. В ней показано, когда формируется каждый отчет и сколько его копий печатается программой. Информация организована в виде строк и столбцов. Обычно все они поименованы. • В первой строке обычно записываются заголовки столбцов, отража ющие вносимую в них информацию. На рис. 12.9 в первом столб це перечислены отчеты, во втором указана частота их формирования, а в третьем — количество копий каждого отчета. • Первый столбец обычно показывает, какая информация содержит ся в каждой строке. На рис. 12.9 в нем перечислены все отчеты программы. Вся имеющаяся в строке информация относится к ука занному в ней отчету. Отчеты на рис. 12.9 перечислены в том же порядке, в каком они рассматривались в главе 6. Для начала это удобнее всего, посколь ку это гарантирует, что ничего не упущено. Однако для тестирова ния удобнее сгруппировать вместе все отчеты, печатаемые в один и тот же день, как на рис. 12.10, ведь и проверять их вы, скорее все го, будете вместе. Таблица входных и выходных значений На рис. 12.7 приведен пример таблицы входных значений программы. В первом столбце перечислены переменные — они взяты из списка на рис. 12.7. Во втором столбце указаны названия диалоговых окон или форм ввода данных, в которых пользователь вводит значения этих переменных. Глава 12: Планирование и документация 3 1 7 3 1 8 Часть II: Приемы и технологии тестирования Глава 12: Планирование и документация 3 1 9 Этот столбец назван Источник. Значение переменной не обязательно вводится в одном-единственном месте программы, поэтому в таблице при сутствует еще один столбец, названный Второй источник. (См. рис. 12.11.) Структура таблицы выходных переменных полностью аналогична, разве что вместо окон, в которых данные вводятся (их источников), перечисля ются формы, в которых они отображаются или печатаются. При этом за головок столбца Источник заменяется на Отчет. Параллельно с печатью и отображением на экране или же вместо этого переменные могут сохранять ся в файлах. В этом случае в таблицу выходных переменных можно доба вить еще один столбец под названием Файл. (См. рис. 12.12.) Таблица ввода/вывода Любые вводимые в программу данные должны ею использоваться. Они могут появиться в отчете, использоваться в вычислениях, для поиска дру гой нужной программе информации или определения ее дальнейших дей ствий. Как тестировщику вам необходимо точно знать, как используется зна чение той или иной входной переменной. Что произойдет, если изменить ее значение? На какие другие данные это повлияет? То же самое можно сказать и о выходных переменных: вы должны знать, откуда они берутся и как формируются. Почему программа решает напечатать именно это значение, а не какое-нибудь другое? И какие еще переменные вовлечены в процесс принятия ее решения? Чтобы наглядно представить всю эту информацию, создайте таблицу и в первом ее столбце перечислите входные переменные. Во втором столб це против каждой входной переменной укажите все выходные переменные, которые с ней так или иначе связаны. Суть каждой связи опишите в тре тьем столбце. Поскольку в системе отслеживания проблем нет хорошего образца такой таблицы, мы обратились к примеру программы, выписыва ющей счета за заказанные товары. (Эта программа была коротко описана несколько ранее.) Единственной приведенной в таблице входной перемен ной является цена заказанных товаров. Она связана с несколькими выход ными переменными. Две из четырех перечисленных в таблице выходных переменных осно ваны на переменной Общая_стоимость, которая, в свою очередь, зависит от переменной Цена_товара. Будучи выходным значением, Общая_стои- мость является одновременно и промежуточной переменной, т.е. промежу точным результатом, полученным в ходе формирования выходных данных на основе входных. Ее значение определяется вводом и, в свою очередь, определяет вывод программы. Иногда полезно отслеживать не только значения входных и выходных данных программы, но и ее промежуточные результаты. 3 2 0 Часть II: Приемы и технологии тестирования Глава 12: Планирование и документация 3 2 1 С этой целью в таблицу ввода/вывода добавляется еще один столбец. Что получается в результате в нашем примере со счетами на заказы, пока зано на рис. 12.13. На этом рисунке в качестве промежуточной перемен ной выступает переменная Общая_стоимость: она записана в таблице рядом с переменной Налог_с_продажи, что указывает на их связь. Почему вторую таблицу можно считать усовершенствованным вариан том первой? Ответ прост: она экономит время тестирования. В обоих слу чаях вам придется выполнить как минимум по одному тесту на каждую пару переменных. Обычно несколько тестов выполняется для проверки граничных условий. Например, стоит посмотреть, что будет с выходными данными, если ввести максимально допустимое значение входной перемен ной. Если же в программе имеется промежуточная переменная, зависящая от множества входных параметров и определяющая множество выходных (или других промежуточных переменных), тогда количество необходимых тестов значительно сокращается. В этом случае отдельно проверяются вза имозависимости между входными и промежуточным значениями и между промежуточным и выходными. И тех, и других тестов сравнительно не много. Чтобы убедиться в этом на примере, создайте еще пару таблиц, подоб ных приведенным на рисунках 12.12 и 12.13. Входными переменными пусть будут Цена_1, Цена_2, Цена_3 и Цена 4. В качестве выходных переменных подойдут Цена_товара_в_счете, Общая_стоимость (сумма всех четырех цен), Налог_с_продажи и Итоговый_баланс. В первой таблице, такой как на рис. 12.12, должно получиться 16 строк и соответственно 16 пар переменных. Четыре строки должны отражать связи переменной Цена_1 с переменными Цена_товара_ в_счете, Обща- я_стоимость, Налог_с_продажи и Итоговый_баланс. И такие же четыре строки должны присутствовать для каждой из остальных входных перемен ных: Цена_2, Цена_3 и Цена 4. Во второй таблице получится только 10 строк. Каждая из переменных Цена_1, Цена_2, Цена_3 и Цена 4 будет комбинироваться не с четырьмя, а только с двумя переменными: Цена_товара_в_счете и Общая_стоимость. Всего получается 8 строк. Затем промежуточная переменная Общая_стои- мость комбинируется с выходными переменными Налог_с_продажи и Итоговый_баланс — это еще две строки. Итого 8 + 2 = 10. Суть различия двух стратегий состоит в том, что во втором случае вза имосвязь между входными (цены) и выходными (налог и итоговый баланс) данными никогда не тестируется непосредственно. Если программа достаточно сложна, анализ потоков ее данных можно углубить. Для этого вся обработка данных разбивается на несколько стадий. Каждая из этих стадий получает данные от предыдущей. Одни из выход ных переменных очередной стадии могут быть просто копиями ее входных переменных, в то время как другие могут быть результатами обработки 3 2 2 Часть II: Приемы и технологии тестирования входной информации. Анализ промежуточных значений позволяет тести- ровщику определить, где и почему что-то в программе пошло не так. Кроме того, они представляют собой поле поиска дополнительных граничных условий и других потенциальных источников ошибок, а в результате — основу для расширения набора тестов. Итак, у нас вырисовываются три типа таблиц. • В таблицах первого типа отражаются все входные переменные, то, как они используются, где они появляются в качестве промежуточ ных результатов и как влияют на выходные данные. Для каждой из входных переменных необходимо составить список всех связанных с ней стадий обработки данных и результирующих значений. • В таблицах второго типа отражаются все выходные переменные и то, откуда берутся их значения. Для каждой из выходных переменных необходимо составить список всех связанных с ней стадий обработ ки данных и результирующих значений. • В таблицах третьего типа отражаются все очевидные стадии разра ботки. Очевидность стадии означает, что можно просмотреть все ее входные и выходные данные. (На самом деле обработка данных в программе может быть разбита на большее количество этапов, но их входные и выходные данные программой не выводятся, и их никак нельзя увидеть извне — разве что в отладчике.) Для каждой из ста дий следует перечислить все ее входные и выходные переменные. Информация в этих трех таблицах повторяется. Фактически для объе динения всех необходимых сведений достаточно и одной из них. Однако это не значит, что составление всех трех таблиц — лишняя работа. Их ценность в том, что они позволяют анализировать программу с разных точек зрения. Мы очень часто включаем в тестовую документацию диаграммы пото ков данных, показывающих, как программа генерирует или откуда получа ет каждый элемент данных, где она его использует или в каком виде и когда выводит (на печать, экран, диск и т.п.). Вся эта информация зани мает множество страниц документации, но она того стоит. Подробнее обо всем этом можно почитать у таких авторов, как Гейн и Сарсон (Gane & Sarson, 1979) и Де Макро (De Macro, 1979). Таблицы и деревья решений В таблице решений отражается логика программы. Каждый ее элемент — это Д (да) или Н (нет) либо И (истина) или Л (ложь). Программа по стоянно принимает решения, что ей делать дальше. Эти решения зависят от определенных обстоятельств, а точнее, от значений определенных дан ных. Эти обстоятельства и принимаемые программой решения и описыва ются в таблице. Глава 12: Планирование и документация 3 2 3 Пример таблицы решений приведен на рис. 12.4. Система печатает два сводных отчета. В первом перечисляются все отчеты о проблемах, отложен ные в текущем месяце (в июле). Во втором отчете перечислены отложен ные проблемы на указанную дату. Формируя эти сводные отчеты, система перебирает все имеющиеся отчеты о проблемах и по каждому из них при нимает решение: включать ли его в документы, и в какие именно. В первых трех строках таблицы перечислены вопросы, ответы на кото рые определяют решение программы. • Отложена ли проблема программистом? (Если да, в поле Код резо люции должно стоять 3.) • Ввел ли тестировщик значение Да в поле Считать отложенным? • Была ли резолюция наложена в июле? Две нижние строки таблицы показывают, какое решение принимается в каждом из случаев. "В каждом из случаев" означает при каждой возмож ной комбинации ответов на вопросы. Все эти комбинации перечислены в правой части таблицы на рис. 12.4. Такая информация должна присутство вать в любой таблице решений — в ней всегда должны быть приведены все возможные комбинации условий, определяющих решение программы. Кроме того, в ней должны быть перечислены и все возможные решения. Любую таблицу решений легко можно превратить в дерево. Многим людям даже легче представить эту информацию в виде дерева, а не в виде таблицы. На рис. 12.15 показано дерево решений, эквивалентное таблице на рис. 12.14. Если вам понадобятся дополнительные примеры таблиц и деревьев принятия решений, их приводят в своей книге Гейн и Сарсон (Gane & Sarson, 1979). |