Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 3. Планирование испытаний 63 Стадия формулирования требований. Определите все документы, которые со держат требования и генерируются на данной стадии, а также все документы, со держащие итоги инспекций, которые получены как результат статического тести рования. Если вы составляете план проведения испытаний на стадии формулиро вания требований, этот шаг может оказать помощь при составлении плана и гра фика выполнения необходимых инспекций. Назначьте членов группы тестирова ния, которые должны принимать участие в проведении инспекций. Выберите хранилище для результатов инспекций. Стадия системного проектирования. Определите все проектные документы, ко торые составляются на данной стадии и план участия группы тестирования в свя занных с этим инспекциях. В документах, формулирующих требования (докумен ты технического задания), указано, что должно тестироваться, а документы эс кизного проекта помогут получить представление о том, как проводить тестиро вание. Стадии тестирования проектов программ, программных кодов, модульного тестирования и комплексных испытаний. Если группа тестирования принимает участие в статическом или динамическом тестировании любых из указанных выше видов деятельности, потребуются соответствующие планы. Время от времени, группа тестирования прогоняет тесты с целью выявления утечек памяти или про верки цикломатической сложности тестирования на стадиях модульного тестиро вания и комплексных испытаний. Если этот так, то планы таких испытаний долж ны учитываться в общем плане испытаний. Если ответственность за эти стадии возлагается только на коллектив разработчиков, их роль должна определяться в форме предположения. Системные испытания. Опишите запланированные вами виды тестирования: функциональная проверка, нагрузочные испытания, испытания под нагрузкой, проверка безопасности, проверка наращиваемости, проверка удобства и простоты обслуживания и другие. Сформулируйте высокоуровневые цели для этих видов тестирования и укажите, как проследить их связь с породившими их требования ми и функциональными спецификациями. Если какие-то виды тестирования опус каются, дайте логическое обоснование их пропуска и оцените связанные с этим риски. Приемочные испытания. Дайте описание плана приемочных испытаний, вклю чая альфа-, бета- и другие виды тестирования. Часто бывает полезно составить от дельный план приемочных испытаний, а в нем указать объемы работ и ограниче ния, накладываемые на тестирование, критерии включений и исключения из ис пытаний и условия испытаний. Поскольку нередко цель приемочных испытаний состоит не только в том, чтобы продемонстрировать заказчику функциональные возможности программного продукта, но и в обнаружении дефектов, план прие мочных испытаний целесообразно рассматривать как документ, направленный извне. Регрессионное тестирование. Укажите в плане регрессионного тестирования, составлен ли он для эксплуатационных версий или же является частью стратегии итеративного выпуска версий. Опишите, как выбираются и разрабатываются рег рессионные тесты, какое должно использоваться оборудование й какова страте- 64 Часть I. Процесс быстрого тестирования гия автоматизации регрессионного тестирования. Исходя из предположения, что тестами покрываются не все функциональные возможности, укажите объемы рег рессионного тестирования и риски, связанные с тем, что некоторые участки будут пропущены и останутся непокрытыми. Подход к тестированию должен отражаться в документах, содержащих планы проведения испытаний. Один из способов показан на примере шаблона далее в этой главе. Пример плана проведения испытаний для приложения ТМТ приводится в третьей части книги. Определение критериев тестирования и точек контроля качества Цель определения критериев тестирования заключается в установке на месте заказ чика набора правил, регламентирующих поток тестирования. Очень важно опреде литься с критериями тестирования до начала испытаний. После того, как вы присту пили к выполнению плана испытаний, поздно объявлять критерии, инициирующие или останавливающие тестирование. Например, если вы рассчитываете на то, что программный продукт успешно пройдет модульное тестирование и комплексные ис пытания, вы должны заявить об этом заранее в подготовленном плане испытаний. После этого план должен быть проверен и утвержден людьми, которые будут зани маться модульным тестированием и комплексными испытаниями. Ввод в действие и выполнение критериев тестирования помогает проекту выдерживать намеченные сроки за счет исключения временных потерь, которые будут неизбежны в случае, ко гда на испытательный стенд попадает программный продукт, не готовый к испыта ниям, либо в ситуации, когда продолжаются испытания продукта, который нужно отправлять на переделку. Поскольку критерии тестирования затрагивают интересы других групп, они не могут односторонне устанавливаться группой тестирования. Применение критериев должно быть согласовано со всеми заинтересованными сторонами. Критерии могут быть установлены для модульного тестирования и комплексных испытаний, однако такие критерии обычно определяются организацией-разработчиком. Рассматривае мые здесь критерии тестирования применяются главным образом в отношении сис темного тестирования. Существует пять типов критериев, которые могут определяться перед началом системного тестирования. Критерий входа описывает, что нужно сделать перед началом тестирования. На пример, возможно, потребуется располагать документами технического задания в окончательной форме. Можно поставить задачу, чтобы программный продукт был упакован в том же виде, в каком он будет поставляться заказчику. Во время тести рования может возникнуть необходимость в служебных программах, конфигура ционных файлы или данных, которыми будет пользоваться заказчик. Если на вас возложена ответственность за проверку документации, сопровождающей про граммный продукт, она также должна быть доступна во время тестирования. Один из способов выполнения критерия входа предусматривает проверку готовности к испытаниям. Эта проверка использует контрольную таблицу элементов действий, которые другие группы согласились передать как входные данных для тестирования. Глава 3. Планирование испытаний 65 Критерий выхода описывает то, что вы считаете необходимым для завершения испытаний. Несмотря на то что группы тестирования часто пытаются сделать критерий выхода условием поставки программного продукта, это нереально. Ре шение на поставку принимается и должно приниматься высшим руководством разработок. Критерий выхода из испытаний должен звучать примерно так: "все запланированные тесты выполнены, все исправленные дефекты проверены, уве домления о всех обнаруженных новых дефектах были выданы. Невыполненные пункты плана, такие как неудачный прогон некоторого набора тестов из-за неис правности оборудования, задокументированы". Как и в случае критерия входа в испытания, допускается проведение проверки готовности, которая обеспечит полное выполнение всех тестов, и оценки готовности программного продукта к поставкам на базе результатов тестирования. Критерий приостановки/возобновления описывает, что произойдет, если по причине из-за дефектов продолжение тестирования окажется невозможным. Дру гими словами, если дела складываются настолько неудачно, что запланированные испытания провести не удается, их необходимо прекратить до тех пор, пока обна руженные дефекты не будут устранены. Критерий успешного/неудачного прохождения теста. Прогон каждого теста должен давать заранее известные результаты. Если получен ожидаемый результат, считается, что продукт успешно прошел тест, в противном случае прохождение теста завершается неудачно. В то же время может случиться так, что прогон неко торой группы тестов не выполняется, поскольку они либо искажены или заблоки рованы дефектами, либо необходимые для их прогона ресурсы отсутствуют. Целе сообразно определить заранее, что делать с тестами, которые не удалось выпол нить. Возможно, будет запланировано пометить каждый невыполненный тест бук вой " N " в итоговом отчете и объяснить в поле комментария, что случилось и что было предпринято в контексте решения проблемы. Может быть, в ваши планы входит замена искаженных тестов специальным видом тестирования и регистра ция результатов в специальном акте об испытаниях. Другие критерии, определяемые процессом или стандартами. Если программ ный продукт должен соответствовать некоторому стандарту или ваша компания предъявляет определенные требования к выполняемому процессу, скорее всего, придется учесть ряд дополнительных критериев. Например, в вашем локальном процессе могут быть определены конкретные средства, выдающие сообщения об обнаруженных дефектах или отчеты по результатам испытаний. В дополнение к приведенным выше критериям, полезно определить критерий тестирования и подготовить контрольную таблицу готовности в рамках плана прове дения испытаний. Этот момент отображен в описании плана проведения испытаний далее в главе и в примере плана проведения испытаний в третьей части книги. Определение стратегии автоматизации П р и наличии реальных планов и разумных предположений использование автомати зированных инструментальных средств и автоматизированных тестовых случаев представляет собой прекрасный способ снижения временных затрат на тестирование программного продукта. Любая многократно выполняемая задача является кандида- 66 Часть I. Процесс быстрого тестирования том на автоматизацию. Однако обычно на автоматизацию задачи уходит намного больше времени, чем на ее выполнение, поэтому для каждой задачи, которая может быть автоматизирована, целесообразно провести тщательный анализ потенциально го выигрыша от автоматизации. Выполняя анализ возможных выгод, следует пом нить, что для самой автоматизации характерен собственный автономный жизненный цикл. Эффективная автоматизация требует специальной подготовки персонала, раз работки, отладки и верификации, как и любой другой проект разработки программ ного обеспечения. Бесплановая и плохо выполненная автоматизация означает не только напрасный расход ресурсов, она даже может привести к нарушению графика выполняемых работ, если время будет тратиться на отладку средств автоматизации, а не на тестирование. Дастин (Dustin), Рашка (Rashka) и Пауль (Paul) в [15] приводят наиболее распро страненные необоснованные предположения, связанные с применением автомати зированного тестирования, равно как и реальные выгоды, на которые можно рассчи тывать, если автоматизации выполнена правильно и следует строгому процессу. Не обоснованные предположения (ожидания) сведены в табл. 3.1, а достижимые выгоды от автоматизации перечислены в табл. 3.2. Если вы все-таки решились вложить средства в автоматизацию тестирования, сле дует проанализировать все последствия этого решения в рамках выбранной страте гии тестирования. Например, задача формирования тестовой среды может зависеть от того, как будет осуществляться прогон тестов — в автоматическом или в ручном режиме. Поскольку и для задач, решаемых в ручном режиме, и для задач, решаемых в автоматическом режиме, необходимо приобретать одни и те же аппаратные средст ва, соединять их между собой кабелями, подключать к компьютерным сетям и вво дить их в эксплуатацию, возможно, имеет смысл сделать автоматизированную тесто вую среду постоянно действующей конфигурацией. Подобный подход позволит вы полнять автоматизированные тесты без вмешательства со стороны оператора. Если предполагается выполнять прогон автоматизированных тестов в рамках регрессив ных испытаний или для целей технического обслуживания, имеет смысл построить специализированную стационарную испытательную установку, которая будет нахо диться на рабочей площадке весь период, пока поддерживается программный про дукт. Однако такое решение влечет за собой существенное увеличение расходов на установку соответствующих аппаратных средств и на помещения, в котором распола гается испытательный стенд. В случае неавтоматизированного режима тестирования конфигурация технических средств создается по ходу дела. Другая проблема, связанная с разработкой стратегии автоматизации, имеет отно шение к процессу. Хорошо известно, что тестирование программного обеспечения должно быть сформированным до принятия решения по поводу автоматизации. Тер мин "сформированный" означает, что тестирование интегрировано в жизненный цикл программного обеспечения, что в основу целей испытаний и тестовых случаев положены требования, и что существует автономная организация тестов. Попытка использовать автоматизацию в условиях хаотичного процесса тестирования едва ли окажется успешной. Автоматизацию лучше всего внедрять как часть непрерывного процесса совершенствования процесса тестирования, но не применять подход "большого взрыва", требующий автоматизации всего и сразу. (Более подробную инфор мацию, касающуюся совершенствования процесса тестирования, можно найти в главе 6). Глава 3. Планирование испытаний 67 Таблица 3.1. Необоснованные ожидания от автоматизированного тестирования (по материалам [15]) Необоснованные ожидания Комментарий Автоматизировать можно все, что угодно Все необходимое может выполнить единственное инструментальное средство Можно привести несколько примеров, когда автоматизация не имеет смысла. Если тот или иной тест нужно прогнать только один раз, нет смысла автоматизировать его, поскольку на автоматизацию уйдет больше времени, чем на прогон теста вручную. Если требования сформулированы нечетко или программные коды регулярно подвергаются изменениям, то не имеет смысла автоматизировать тесты, которые будут постоянно меняться. Кроме того, нецелесообразна также автоматизация тестов, требующих вмешательства оператора, подобных, например, замене оборудования во время прогона теста. В настоящее время ни одно из доступных на рынке программных средств не способно генерировать планы проведения испытаний, поддерживать проектирование тестов и управлять исполнением тестов. Не существует ни одного инструментального средства, которое поддерживало бы все операционные системы и все языки программирования. Средства автоматизации следует тщательно выбирать под имеющуюся задачу. Временной график тестирования немедленно сократится Автоматизация тестирования может уменьшить время, затрачиваемое на тестирование, однако для того, чтобы сократить график работ, необходимы определенные затраты на подготовку персонала, разработку автоматизации и совершенствование процесса тестирования. После принятия решения об автоматизации график выполнения работ расширяется ввиду необходимости поддержки начальных вложений ресурсов. Современные средства автоматизации просты в использовании Поставщики инструментальных средств постоянно повышают простоту использования инструментальных средств автоматизации, однако у вас не должно складываться впечатление, что эти средства можно эффективно задействовать без специальной подготовки. При планировании стратегии автоматизации обязательно следует дать адекватную оценку времени, затрачиваемого на такую подготовку, а также поддержки со стороны поставщиков соответствующих программных продуктов. Автоматизация обеспечивает стопроцентное тестовое покрытие Даже с использованием автоматизации полное тестирование компьютерной программы невозможно. Подробное обоснование этого тезиса приводится во врезке 3.1. 68 Часть I. Процесс быстрого тестирования Таблица 3.2. Выгоды, которые приносит автоматизированное тестирование (по материалам [15]) Извлекаемая выгода Комментарий Повышенная надежность системы Уточненные определения требований Усовершенствованные тесты производительности и испытания при перегрузках Повышенная повторяемость тестирования Доступны различные инструментальные средства, которые поддерживают разработку проверяемых требований. Некоторые из этих средств требуют использования формальных языков, в то время как другие моделируют требования графически. Существуют инструментальные средства тестирования под нагрузкой, позволяющие специалистам по тестированию разрабатывать сценарии, которые осуществляют автоматический сбор статистических данных по времени отклика, по количеству пользователей, по числу транзакций и продолжительности больших транзакций. Есть возможность проводить испытания при перегрузках, в рамках которых система подвергается предельным нагрузкам с целью определения причины отказа. Автоматизированное тестирование протекает каждый раз одинаково, что существенно уменьшает количество ошибок, вызванных непостоянствами, имеющими место при ручной методике испытаний. Повышенная повторяемость тестирования » очень важна при воспроизведении дефектов и проверке исправлений. Повышение качества тестирования Проверочные испытания сборок Повышение качества статического и динамического тестирования кода Повышение качества регрессионного тестирования Повышение качества проверки на совместимость Более эффективное выполнение однотипных задач тестирования и тестирование в нерабочее время Автоматизированные испытания могут использоваться как своего рода "испытания герметичности" программной сборки (build) при ее переходе со стадии разработки на стадию тестирования. Критерии входа часто требуют проведения испытаний на герметичность, благодаря которым к тестированию не допускаются сборки, не готовые к испытаниям. В результате достигается существенная экономия трудозатрат. Возможен анализ кода на предмет утечек памяти, на чрезмерную сложность, на ошибки во время прогона, на присутствие недостижимых кодов и другие виды дефектов. Более подробную информацию о статическом тестировании можно найти в главе 9. Автоматизированное регрессионное тестирование используется для проверки, не вкралась ли ошибка при переносе ранее правильно работавшего программного кода в новую сборку. В некоторых случаях автоматизированные тесты можно переносить в другие операционные системы и платформы, что расширяет тестовое покрытие без увеличения объемов неавтоматизированного тестирования. Автоматизация однообразных, однотипных задач уменьшает вероятность ошибок тестирования и позволяет сократить сроки испытаний. Автоматический прогон тестов можно выполнять ночью или в выходные дни, тем самым давая возможность специалистам по тестированию в рабочие часы сосредоточиться на решении более сложных и творческих задач. |