Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 1. Понятие о технологии быстрого тестирования 17 • Необходимо обеспечивать достаточно высокое качество тестирования, кото рое бы гарантировало, что дефекты, приводящие к разрушительным последст виям, не просочатся на компьютеры конечных пользователей. Проблема связана с тем, чтобы удовлетворить каждое требование без ущерба для другого. Цель настоящей книги заключается в нахождении эффективного тестового процесса и представлении таких практических технологий, которые удовлетворяли бы обоим требованиям. Мы начнем с изучения фундаментальных основ разработки и тестирования программного обеспечения. Основные определения в области тестирования программного обеспечения Прежде чем приступить к обсуждению процесса разработки программного обеспече ния, дадим определения ряда основных терминов и понятий. По логике вещей лучше всего начать с определения, что собой представляет тестирование программного обеспечения. Тестирование программного обеспечения (software testing)— это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов. Несмотря на всю простоту этого определения, в нем содержатся пункты, которые требуют дальнейших пояснений. Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование суть плановая, упорядоченная деятельность. Этот момент очень важен, если мы заинтересованы в быстрой разработке, ибо хорошо продуманный, систематический подход быстрее приводит к обнаружению про граммных ошибок, чем плохо спланированное тестирование, к тому же проводимое в спешке. Согласно этому определению, тестирование предусматривает "анализ" или "экс плуатацию" программного продукта. Тестовая деятельность, связанная с анализом результатов разработки программного обеспечения, называется статическим тести рованием (static testing). Статическое тестирование предусматривает проверку про граммных кодов, сквозной контроль и проверку программы без запуска па машине, т.е. проверку за столом (desk checks). В отличие от этого, тестовая деятельность, предусмат ривающая эксплуатацию программного продукта, носит название динамического тес тирования (dynamic testing). Статическое и динамическое тестирование дополняют друг друга, и каждый из этих типов тестирования реализует собственный подход к выявлению ошибок. Последний пункт определения, требующий дополнительных пояснений — это по нятие дефекта (bug). Говоря простыми словами, программная ошибка— ни что иное, как изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически получен ных результатов. Дефект может возникнуть на стадии кодирования, на стадии фор мулирования требований или на стадии проектирования, либо же его причина может крыться в некорректной конфигурации или данных. Дефектом может быть также что-то другое, что не соответствует ожиданиям заказчика и что может быть, а может и не быть определено в спецификации программного продукта. Более подробное описание терминологии дефектов приводится во врезке 1.1. 18 Часть I. Процесс быстрого тестирования ДОЛГОВЕЧНОСТЬ ДЕФЕКТА Долговечность дефекта может быть описана следующим образом. Дефект возникает в результате того, что человек допускает ошибку (error), осуществляя некоторый вид деятельности, который имеет отношение к разработке программного обеспечения. К упомянутым видам деятельности относятся, например, формулирование требований, проектирование программы или написание программного кода. Эта ошибка вкрадывает ся в рабочий продукт (перечень требований, проектный документ или программный код) в виде неисправности (fault). До тех пор пока эта неисправность (известная еще как дефект (bug, defect)) присутст вует в рабочем продукте, она может служить причиной появления других дефектов. На пример, если неисправность, допущенная в перечне требований, остается необнаружен ной, вполне вероятно, что это приведет к возникновению соответствующих ошибок в проекте системы, в проекте программы, в программном коде и даже в документации для пользователя. Дефект остается необнаруженным до тех пор, пока не произойдет отказ. Ведь именно тогда пользователь или тестировщик замечает, что система не выполняет возложенных на нее функций. На стадии системных испытаний цель специалиста по тестированию со стоит в том, чтобы вызвать сбой программы, обнаружить и задокументировать связан ные с ним дефекты, а затем удалить их из системы. В идеальном случае долговечность дефекта ограничена моментом, когда он обнаруживается средствами статич*«-к<-.го или динамического тестирования и успешно устраняется. Врезка 1.1 Одно из практических последствий определения процесса тестирования заключа ется в том, что перед специалистами по тестированию и разработчиками поставлены противоположные цели. Цель разработчика состоит в том, чтобы создать программ ный код без дефектов, который соответствует назначению программного продукта и отвечает требованиям заказчика. Разработчик пытается "сделать" программный код. Цель тестировщика связана с анализом кода и эксплуатацией программы, что в ко нечном итоге должно вести к вскрытию дефектов, затаившихся в программном коде, которые проявляются во время его интегрирования, конфигурирования и выполне ния в различных средах. Тестировщик предпринимает попытки "разломать" про граммный код. В данном контексте хорошим результатом для разработчика считается успешное прохождение теста, в то время как для тестировщика успешный результат означает отказ программы на том же самом тесте. В конечном итоге и разработчик, и тестировщик стремятся к единой цели: получить такой программный продукт, кото рый хорошо работает и удовлетворяет требованиям заказчика. Тестирование программного обеспечения выполняет две базовых функции: ве р и ф и к а ц и ю и аттестацию. В [45] функции верификации и аттестации (verification and validation, V&V) определяются следующим образом: Верификация (verification) обеспечивает соответствие результатов конкретной ф а з ы процесса разработки требованиям данной и предшествующей стадий. Аттестация (validation) есть гарантия того, что программный продукт удовлетво ряет системным требованиям. Цель аттестации заключается в том, что система должна отвечать всем предъяв ляемым требованиям, так чтобы происхождение каждой функции можно было про следить до конкретного требования заказчика. Другими словами, аттестация дает гарантию того, что строится правильный продукт. Глава 1. П о н я т и е о т е х н о л о г и и б ы с т р о г о т е с т и р о в а н и я 19 Верификация в большей мере сосредоточена на действиях в рамках конкретной стадии процесса разработки. Например, одна из целей системного тестирования за ключается в обеспечении соответствия проекта системы требованиям, которые были использованы как входные данные для стадии проектирования системы. Для под тверждения соответствия между проектом программы и проектом системы можно воспользоваться модульным тестированием и проверкой взаимодействия и функцио нирования компонентов системы. Проще говоря, верификация дает гарантию того, что продукт строится правильно. В последующих главах, параллельно с прохождени ем всех стадий процесса разработки, будут приводиться соответствующие примеры верификации и аттестации. Остается дать определение еще одного дополнительного понятия — понятия каче ства. Подобно такому свойству, как красота, качество — во многом субъективное по нятие, поэтому точное определение дать ему достаточно трудно. Определим качество программного обеспечения с использованием трех факторов: отказов на месте экс плуатации продукта, надежности и степени удовлетворенности заказчика. Говорят, что программный продукт обладает хорошим качеством {quality), если: • При работе пользователя с программным продуктом возникает небольшое чис ло отказов. Этот факт свидетельствует о том, что на рабочее место просочи лось лишь небольшое число дефектов. • Программный продукт надежен, а это означает, что его прогон редко заверша ется аварийным отказом или что он редко демонстрирует непредсказуемое по ведение при работе в среде заказчика. • Программный продукт удовлетворяет требованиям большинства пользо вателей. Одно из следствий приведенного определения заключается в том, что тестовая группа не только должна принять меры к предотвращению и обнаружению дефектов в процессе разработки программного продукта, но также сконцентрировать свои усилия на повышении его надежности, удобства и простоты использования. Что такое быстрое тестирование? В данной книге т е р м и н "быстрое тестирование" используется как дополнение поня тия "быстрая разработка". Как отмечалось в [33], для разных людей быстрая разра ботка означает различные вещи. Некоторые понимают это как быстрое создание прототипов. Другие представляют ее как некоторое сочетание инструментальных средств CASE, активного участия пользователя и жестких временных ограничений. В редакции Макконнела [33] при определении быстрой разработки не упоминаются специальные инструментальные средства или методы: Быстрая разработка — это обобщенный термин, который означает то же, что "ус коренная разработка" и "сжатые сроки разработки". Он означает разработку про граммного продукта за меньшее время, чем это делалось до сих пор. Таким обра зом, "проект быстрой разработки" означает любой проект, при котором особое значение имеет срок разработки. В том же ключе, быстрое тестирование (rapid testing) означает выполнение тестиро вания программного обеспечения в более быстром темпе, чем это делается в настоя- 20 Часть I. Процесс быстрого тестирования щий момент, при условии сохранения или повышения уровня качества. К сожале нию, простых путей достижения этой цели не существует. На рис. 1.1 показана упро щенная схема, представляющая быстрое тестирование как структуру, построенную на фундаменте из четырех компонентов. Если хотя бы один из этих компонентов ослаб лен, эффективность тестирования существенно снижается. В соответствии с рис. 1.1, к четырем компонентам, которые должны быть оптимизированы для целей быстрого тестирования, относятся персонал, процесс комплексных испытаний, статическое тестирование и динамическое тестирование. Далее приводится краткий анализ всех четырех компонентов. Рис. 1.1. Наиболее важные компоненты быстрого тестирования Персонал Каждый менеджер по тестированию знает, что нужные специалисты представляют собой непременное условие быстрого тестирования. Многочисленные исследования показывают, что производительность разработчиков программного обеспечения различается в пределах 10:1 и даже больше. То же можно сказать и в отношении спе циалистов по тестированию — далеко не каждый специалист обладает навыками, опытом или характером, чтобы стать хорошим специалистом по тестированию. В частности, для выполнения быстрого тестирования нужны хорошо подготовленные и гибкие исполнители, способные работать в условиях жестких временных ограни чений и быть полезными партнерами для разработчиков на ранних стадиях жизнен ного цикла разработки. Несмотря на то что в этой книге основное внимание уделяет ся процессу и технологии тестирования, в главе 6 предлагаются некоторые идеи, ка сающиеся персонала, который должен выполнять тестирование. Процесс комплексных испытаний Независимо от того, насколько высока квалификация персонала, если они не распо лагают систематическим и отлаженным процессом тестирования, они не смогут ра ботать с максимальной эффективностью. В основу процесса тестирования должны Глава 1. Понятие о технологии быстрого тестирования 21 быть положены устойчивые, фундаментальные принципы, а сам процесс тестирова ния должен быть тесно интегрирован с общим процессом разработки программного обеспечения. В части I этой книги большое внимание уделяется описанию способов совершенствования процесса тестирования. Вопросы применения практических технологий и рекомендации по реализации рассматриваются в части И. В центр вни мания проводимого нами анализа попадает исследование вопросов более органично го интегрирования процесса разработки и тестирования. Статическое тестирование В предыдущем разделе мы определили статическое тестирование как вид тестовой деятельности, связанной с анализом продуктов разработки программного обеспече ния. Статическое тестирование проводится с целью подтверждения вывода о том, что рабочий продукт, например, спецификация проекта, правильно реализует все сис темные требования, и с целью контроля качества проекта. Статическое тестирование является одним из наиболее эффективных средств выявления дефектов на ранних стадиях разработки, благодаря чему достигается существенная экономия времени и затрат на разработку. Сюда входят проверки, сквозной контроль и экспертные оцен ки проектов, программных кодов и прочих рабочих продуктов, равно как и статиче ский анализ с целью обнаружения дефектов в синтаксисе, структурах данных и других компонентах программного кода. Статическое тестирование по существу есть все, что можно сделать для выявления дефектов без прогона программного кода. Опыт, накопленный авторами книги, позволяет утверждать, что этим средством зачастую пренебрегают. Статическое тестирование будет предметом наших обсуждений на протяжении первых двух частей этой книги. Динамическое тестирование Часто, когда специалисты думают о тестировании, они имеют в виду динамическое тестирование, в рамках которого предусматривается эксплуатация системы с целью выявления дефектов. Если статическое тестирование не предусматривает прогона программного продукта, то динамическое тестирование без такого прогона обойтись не может. Вообще говоря, динамическое тестирование состоит из прогона програм мы и сравнения ее фактического поведения с ожидаемым. Если фактическое поведе ние отличается от ожидаемого, это значит, что обнаружен дефект. Как будет показа но в последующих главах, динамическое тестирование применяется для выполнения тестов различных типов, таких как функциональная проверка, испытания для опре деления рабочих характеристик и тестирование в предельных режимах. Динамиче ское тестирование является центральным звеном процесса тестирования программ ного обеспечения, и если планирование, проектирование, разработка и выполнение динамического тестирования выполнены недостаточно хорошо, то процесс тестиро вания не может быть эффективным. Динамическое тестирование выполняется не только силами тестовой группы; тестовая группа должна быть частью коллектива разработчиков и совместно с ними принимать участие в проверке взаимодействия и функционирования компонентов системы. 22 Часть I. Процесс быстрого тестирования Разработка стратегии быстрого тестирования Если бы перед вами была поставлена задача исследовать текущий процесс разработки программного обеспечения с целью найти способы повышения эффективности тес тирования, то какая часть процесса в первую очередь привлекла бы ваше внимание? Начнете ли вы эти исследования с анализа того, как планируется выполнять тестиро вание? С анализа средств и методов автоматизации разработки программного обес печения? Ч т о можно сказать об используемой вами системе отслеживания дефектов? П р и н я т ы й в этой книге подход предусматривает исследование каждой фазы про цесса разработки программного обеспечения с позиций специалиста по тестирова нию. Основная цель заключается в определении возможных способов ускорения процесса тестирования при условии сохранения или даже повышения качества про граммного продукта. П р и этом возникает характерный образ специалиста по тести рованию, который сидит на вращающемся стуле и поворачивается лицом к каждому аспекту процесса разработки, определяя, что можно сделать, дабы эта стадия процес са разработки не стала источником дефектов, либо выясняя, можно ли получить на этой стадии информацию, которая позволит ускорить процесс тестирования. Прежде чем приступить к подробному анализу каждой стадии процесса разработ ки программного обеспечения в перспективе тестирования, потребуется заложить определенный фундамент. В этой главе даются определения основных терминов и понятий тестирования программного обеспечения. Затем проводятся исследования каждой фазы типового процесса разработки, которые имеют целью определить воз можные способы ускорения процесса тестирования и повышения его эффективно сти. Во время исследования каждой стадии разработки мы рассчитываем получить ответы на следующие вопросы: • Может ли тестовая группа предпринять на данной стадии какое-либо действие, способное предотвратить утечку дефектов? • Может ли тестовая группа предпринять на данной стадии какое-либо действие, позволяющее уменьшить риск нарушения временного графика разработок? • Можно ли получить какую-либо информацию на текущей стадии разработки, которая позволила бы тестовой группе ускорить планирование тестирования, разработку тестовых случаев или выполнение тестов? Если тестовый процесс разработан с учетом ответов на эти вопросы, то это долж но вызвать повышения темпов тестирования, равно как и качества конечного про граммного продукта. Процесс разработки программного обеспечения До сих пор мы говорили об исследовании процесса разработки программного обес печения, не указывая конкретно, что из этого следует. Одна из причин избегать од нозначных утверждений заключается в том, что не существует процесса разработки, который наилучшим образом подходил бы для всех быстро разрабатываемых проек тов. Например, встроенный контроллер для кардиостимулятора должен создаваться "максимально быстро", тогда как интерактивный словарь для вашего соседа вряд ли должен разрабатываться столь же быстрыми темпами. Глава 1. Понятие о технологии быстрого тестирования 23 В [42] процесс {process) определен как "последовательность шагов, в том числе дей ствия, ограничения и ресурсы, которая приводит к желаемому результату определен ного рода". Из предложенного Пфлигером [42] списка атрибутов процесса выделим следующие: • В рамках процесса предварительно описываются все основные действия. • В процессе задействуются ресурсы, с которыми связана некоторая совокуп ность ограничений (например, расписание), и генерируются промежуточные и конечные результаты. • Процесс может состоять из некоторого числа подпроцессов, связанных между собой определенным образом. Процесс можно определить как некоторую ие рархию процессов, организованных так, что каждый подпроцесс описывается собственной моделью процесса. • С каждым действием процесса связаны критерии входа и выхода, так что из вестно, когда определенное действие начинается и когда завершается. • Действия выполняются последовательно или параллельно по отношению к другим независимым подроцессам, поэтому легко определить, когда некоторое действие выполняется относительно других действий. • Каждый процесс управляется некоторым набором руководящих принципов, определяющих цели каждого действия. • К действию, ресурсу или результату могут применяться ограничения или ди рективы. Например, бюджет или план накладывает ограничения на промежу ток времени, в течение которого выполняется то или иное действие, а некото рое инструментальное средство может накладывать ограничения на способ ис пользования определенного ресурса. Когда процесс имеет отношение к созданию того или иного продукта, это часто называется жизненным циклом. По той же причине разработка программного про дукта называется жизненным циклом программного продукта (software life cycle). Жизнен н ы й цикл программного продукта может быть описан разными способами, в то же время для этой цели часто используется модель, которая представляет основные свойства процесса, сопровождаемые определенным сочетанием текста и иллюст раций. Одной из первых была использована каскадная (или водопадная) модель жизнен ного цикла программного продукта, показанная на рис. 1.2. Основное свойство кас кадной модели заключается в том, что каждая стадия или компонент модели заверша ется перед началом следующей стадии. Процесс начинается с определения требова ний к системе. В каскадной модели эти требования выявляются, анализируются и записываются в специальные документы еще до того, как начнутся работы по проек тированию. Проектирование системы, проектирование программ, кодирование и различные виды тестирования суть самодостаточные и тщательно документирован ные стадии процесса. Следует, однако, заметить, что обычно некоторые стадии вы ступают под различными именами; например, стадия системного проектирования часто называется "проектным заданием" или "эскизным проектом", в то время на как стадию разработки программы зачастую ссылаются как на "рабочий план". 24 Часть I. Процесс быстрого тестирования Рис. 1.2. Каскадная модель жизненного цикла У каскадной модели имеются свои критики. Один из аргументов, к которым они прибегают, касается возможности фиксации всех требований на начальной стадии проекта. Предположим, что вас попросили высказать все свои требования к новому автомобилю до того, как он будет спроектирован и построен. Как заказчику, вам бу дет трудно сформулировать эти требования с т о й степенью детализации, которая необходима для проектирования и построения автомобиля "с нуля". Именно такие запросы предъявляет каскадная модель к заказчику и программисту-аналитику на на чальном этапе каскадного процесса. В [13] и [42] утверждается, что главным недостатком каскадной модели является то, что она не трактует программное обеспечение как процесс решения задачи. Кас кадная модель заимствована из области разработки аппаратных средств. Она ото бражает конвейерный принцип разработки программного обеспечения, по условиям которого компонент сначала разрабатывается, а затем многократно тиражируется. Однако создание программного обеспечения — это, прежде всего, творческий, а от нюдь не производственный процесс. Становление программного обеспечения про исходит по спирали по мере того, как растет понимание задачи. В рамках данного процесса происходят неоднократные продвижения вперед и возвраты обратно, при этом пробуются различные варианты с целью выбора из них наилучшего. Другими |