Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
На каждом цикле тестирования следует соблюдать баланс между широтой и глубиной охвата программы. Лучше всего думать о программе как о наборе объектов исследования. Составьте их полный список. Это не значит, что границы объектов долж ны быть очень строго очерчены. Просто следует выделить основные фун кции программы, ее меню, возможности, спрогнозировать возможные классы проблем. Затем, положив перед собой этот список, можно по оче реди концентрироваться на каждом из его элементов. • Концентрируясь на классе проблем, спросите себя, где они вероят нее всего могут проявиться, а затем протестируйте эти области про граммы. Например, если речь идет о проблемах совместимости с внешней средой, подумайте, с какой целью программа может обра щаться к интересующим вас устройствам или внешним процессам и как их работа может отразиться на ее функционировании. Затем проверьте, как программа взаимодействует с этими устройствами и процессами, протестируйте несколько различных конфигураций. • Концентрируясь на модуле, функции или возможности программы, подумайте, что в них с наибольшей вероятностью может не работать. Например, можно протестировать все форматы отображаемой графи ки. Постарайтесь в ходе каждого цикла тестирования проработать каждый объект, хотя одним объектам можно при этом уделить меньше внимания, чем другим. Глава 13: Объединяющая 4 0 1 Существует несколько уровней тестирования, и каждый из них позво ляет выявить собственные типы ошибок. • Базовое тестирование — это всеохватывающее, но довольно повер хностное тестирование, позволяющее выяснить, как ведет себя про грамма при "нормальной" эксплуатации. • Неформальное тестирование включает короткие серии тестов, со стоящих из нестандартных действий пользователя и просто различ ных экспериментов с программой. • Интенсивное плановое тестирование включает достаточно большое количество тестов, реализующих ваши лучшие идеи о возможностях выявления проблем в выбранной области программы. • Регрессионные тесты выполняются на каждом цикле тестирования. В идеале они должны охватывать все объекты исследования и тре бовать минимум времени. Базовое тестирование На ранних этапах тестирования программа постоянно меняется — в ответ на отчеты о проблемах в нее вносятся бесчисленные исправления. Эти исправления влекут за собой множество новых ошибок (примерно по одной на каждые три исправления). Одни из этих ошибок содержатся в добавленных фрагментах кода, другие — в исправленных, так что подчас ломается то, что уже прекрасно работало. По этой причине даже самое поверхностное тестирование очередной версии программы позволяет выя вить ряд ошибок. На каждом цикле проверяйте все до единой области программы. Пользуйтесь лучшими и наиболее мощными из разработанных тестов. Если область программы до сих пор тестировалась только поверхностно и на текущем цикле у вас также нет времени на ее детальную проработку — что ж, проведите хотя бы те базовые тесты, которые выполнялись в прошлый раз. Обнаружив новые граничные условия или придумав новые интересные тесты, включите их в свой план. Даже без формального плана базовое тестирование позволит поддерживать определенный уровень стабильности охватываемых им областей программы. Неформальное тестирование Решив, какая область программы будет тестироваться следующей, нач ните работу с ней с неформальных экспериментов. Посвятите им один день, стараясь найти как можно больше ошибок. Сначала попробуйте сде лать что-нибудь реальное, что будет выполнять любой пользователь. Затем, напротив, проверьте устойчивость программы к нестандартным действиям, поэкспериментируйте с граничными значениями, попробуйте организовать 4 0 2 Часть III: Управление проектами и группами ситуации гонок. Следуя интуиции, старайтесь найти самые слабые места программы. Цели вашей работы должны быть следующими. • Как можно раньше выявить основные ошибки. На разработку тестов уходит очень много времени. Если из-за серьезных ошибок в про грамме она будет значительно переделана, часть этого времени может оказаться потраченной зря. С другой стороны, значительную часть ошибок, и в том числе самых серьезных и требующих наиболь ших переделок, можно выявить в ходе одного массированного рей да по программе или ее выбранной области. Поэтому имеет смысл сначала провести такой рейд, а уж потом браться за скрупулезную проработку нюансов. • Дать себе время подумать. Почитайте и подумайте о выбранной области программы. У вас должно выработаться ясное видение воз можных проблем и ошибок, а также типов необходимых тестов. Поэкспериментируйте с областью программы ровно столько, сколь ко необходимо для выявления самых серьезных проблем. Это даст вам неделю или две на ее обдумывание, прежде чем тестирование будет продолжено (в течение этого времени будут исправляться найденные ошибки). • Как можно раньше исправить самые серьезные ошибки. Чем рань ше составить отчет о проблеме, тем раньше и с тем большей веро ятностью, она будет решена. • Улучшить состояние программы. Помните, что тестирование про граммы может быть прекращено в любой момент. Неформальное тестирование гораздо мощнее базового и позволяет выявить гораз до больше проблем. Кроме того, оно выполняется быстро, так что, если с самого начала пройтись таким образом по всем областям программы, можно уже на ранних стадиях тестирования обеспечить определенный уровень ее надежности. Интенсивное плановое тестирование Выберите одну из областей программы и полностью на ней сконцент рируйтесь. После короткого неформального тестирования можно перейти к плановой и скрупулезной работе. Довольно трудно решить, с какой области программы начать. Тут мо жет быть целый ряд соображений, о которых уже рассказывалось в главе 12. Вот первые кандидаты на тестирование. • Области программы, которые при предварительном тестировании показались наиболее слабыми. Глава 13: Объединяющая 4 0 3 • Области программы, ошибки в которых будут наиболее заметны пользователю. • Наиболее часто используемые составляющие программы. • Особенности программы, выделяющие ее среди конкурирующих продуктов. • Компоненты программы, которые труднее всего исправлять. • Самые понятные для вас функциональные области. С чего начинать — это вопрос личных предпочтений. Вместо того чтобы писать подробные планы тестирования слабейших составляющих програм мы, мы обычно начинаем с их массированного неформального тестирова ния, а дальше свое дело делает пачка отчетов о проблемах — пока мы в течение нескольких циклов тестируем остальные части программы, состо яние ее слабейших участков значительно улучшается. Впервые тестируя определенную область программы, вы наверняка не успеете полностью спланировать необходимые работы в течение одного цикла. Этого и не требуется. Выполните такой объем бумажной работы, который покажется наиболее разумным, а остальное оставьте для следую щих циклов. Ведь не обязательно, чтобы все проводимые тесты были зара нее спланированы — что-то можно придумывать прямо по ходу работы. Регрессионное тестирование Один раз тщательно протестировать каждую область программы еще не достаточно — ее тестирование необходимо регулярно повторять. Программа постоянно меняется, возникают новые проблемы, повторно появляются старые ошибки. Регрессионное тестирование должно охватывать програм му так же полно, как и первоначальное, однако не требовать так же мно го времени. Прежде всего в набор регрессионных тестов включаются проверки всех недавних исправлений программы. Этот набор непостоянен, тесты вклю чаются в него, затем какое-то время спустя удаляются, уступая место но вым. Большая часть регрессионных тестов выполняется один-два раза. Однако существует и некоторое более постоянное подмножество тестов, составляющее ядро регрессионного набора. Регрессионных тестов не должно быть слишком много — только необ ходимый минимум, полностью покрывающий выбранную область програм мы. Ими должны по возможности охватываться все аспекты этой области (подпрограммы, граничные условия и т.п.) и все ситуации, чреватые сбо ями и ошибками. Кроме того, желательно, чтобы эти тесты были быстры ми. Конечно, на практике выполнить требование "минимум времени при максимальном охвате" довольно сложно. Включайте в набор самые инте- 4 0 4 Часть III: Управление проектами и группами ресные и полезные тесты, позволяющие проверить, хорошо ли исправлены выявленные ошибки. Проводя базовое и неформальное тестирование, включайте лучшие из тестов в регрессионный набор. Остальные тесты разрабатывайте в процессе планирования. Как минимум половина его вре мени должна быть посвящена тестам, которые будут выполняться по не скольку раз. Подумайте о следующей стратегии выполнения регрессионного тести рования: одна часть тестов выполняется для каждой версии программы, другая — для каждой второй или третьей версии, третья — еще реже. Это поможет ускорить процесс тестирования, сохраняя полноту охвата програм мы. Ближе к концу разработки, когда новые версии могут передаваться на тестирование все чаще и чаще, описанный прием сослужит вам неоцени мую службу. Замечание о циклах тестирования Идеальный цикл — это полное тестирование одной версии продукта. На практике же набор тестов меняется от версии к версии. В одних компаниях тестирование очередной версии программы начина ется только после того, как полностью протестирована предыдущая версия. В других программисты передают программу тестировщикам тогда, когда в нее внесено столько изменений, что работа над предыдущей версией теряет смысл. На ранних стадиях проекта временные интервалы между версиями могут составлять от двух до шести недель. По мере продвижения работы эти интервалы сильно сокращаются, и к концу проекта новые версии мо гут передаваться на тестирование каждые несколько дней. Однако слишком короткие циклы — это не работа. Не успеет тестиров- щик провести приемочные тесты, несколько регрессионных и написать кое-какие заметки, как пора переходить к новой версии программы. Так много ошибок не найти. Постарайтесь добиться утверждения такого календарного плана работ, при котором 25-30% рабочего времени можно будет тратить на планирова ние и выполнение новых тестов. Именно они с наибольшей вероятностью позволяют выявить оставшиеся в программе недостатки. На начальных стадиях тестирования это время у вас будет. А вот дальше, когда сформи руется целая батарея регрессионных тестов, на новые эксперименты вре мени будет оставаться все меньше и меньше. Поэтому старайтесь по возможности сократить время регрессионного тестирования и удлинить время каждого цикла. Пре-бета Во многих компаниях готовность бета-версии считается одним из важ нейших рубежей разработки. По его достижении принимаются важные Глава 13: Объединяющая 4 0 5 решения, завершаются одни виды работ и начинаются другие. Если так обстоит дело и в вашей компании, за две-три недели до завершения бета- версии стоит заняться кое-какой проверочной работой. Проанализируйте общее состояние программы и ее отдельных функций. Достаточно ли она надежна, и все ли в ней уже на своих местах? Действительно ли имеющу юся версию можно с чистым сердцем назвать "бета"? Как правило, такое проверочное тестирование и общая оценка состояния программы выполня ются совместно тестировщиками и руководителем проекта. В некоторых компаниях в календарный план разработки включается этап, который следует непосредственно за альфа-этапом и называется эта пом подготовки бета-версии или просто пре-бета. Он довольно короткий и предназначается для доведения программы до состояния бета-версии. Ру ководитель проекта решает, что программа готова к испытаниям. Он объяв ляет об этом коллективу, и после долгих обсуждений, испытаний, исправлений и повторных проверок руководитель группы тестирования наконец соглашается, что бета-версия готова. В других компаниях утверждение бета-версии проводится не так откры то, но в той или иной форме этот процесс согласования и внесения пос ледних исправлений все равно неизбежен. Как и перед объявлением альфа-версии, будьте готовы к огромному количеству последних изменений и исправлений. Планируйте свое время так, чтобы проверять их быстро и немедленно сообщать о результатах. Бета Как и у альфа-версии, у бета-версии программы множество определе ний. Вот несколько примеров. • Бета-версия — это версия, которую можно передать бета-тестиров- щикам, т.е. людям не работающим в компании, но готовым поэкс плуатировать какое-то время ваш не вполне еще отлаженный продукт и сообщить о своих впечатлениях и найденных ошибках. Будет ли в бета-версии реализован полный набор запланированных функций программы, зависит от выбранной модели разработки. То, что продукт готов к оценке сторонними пользователями, еще не значит, что он полностью завершен. • В типичной бета-версии программы, разрабатывающейся методом водопада, все функции готовы и протестированы, фатальных ошибок нет, серьезных очень мало, несущественные файлы данных готовы, по крайней мере, на 50%, почти завершены файлы для драйверов устройств, готовы все проектные документы и продукт соответствует требованиям. 4 0 6 Часть III: Управление проектами и группами • В типичной бета-версии программы, разрабатывающейся эволюцион ным методом, готово ее ядро и тот набор базовых функций, которые делают ее приемлемым продуктом. Программа полностью протести рована, и, возможно, в ней есть даже некоторые дополнительные функции. При эволюционной модели разработки такое состояние достигается достаточно рано, что позволяет рано передать программу сторонним бета-тестировщикам, а значит, заблаговременно узнать мнение пользователей и сэкономить средства на ее тестировании. Альфа и бета не обязательно должны быть единственными ключевы ми рубежами разработки. Можно определить и еще один рубеж (гам ма?), на котором в программе уже будет множество разнообразных функций, а отсутствующие не будут иметь значительного влияния на ее маркетинговые характеристики. Этот рубеж будет означать, что разработка подходит к концу и вся основная работа уже выполнена. После завершения бета-версии программы руководитель проекта опре деляет окончательную конфигурацию установочных дисков. Составляется список файлов, определяется их формат и то, будут ли они сжатыми. Го товится первая копия дисков, на которых вместо некоторых файлов могут быть просто заглушки — пустые файлы с заранее определенными имена ми. Программирование после завершения бета-версии Если в программе остались неоконченные элементы, их необходимо доделать. Однако таких составляющих уже не много, и большая часть уси лий программистов после завершения бета-версии направляется на исправ ление ошибок, создание файлов данных, написание установочных утилит и блоков поддержки оставшегося аппаратного и программного обеспечения. Что касается проектных работ, то их объем и характер на этом этапе зависят от принятого в компании определения бета-версии программы. Возможно, именно теперь наступит время для "наведения красоты" и выполнения пожеланий пользователей, принимавших участие в бета-тести ровании. Если же пользовательский интерфейс к этому времени "заморо жен" и любые конструкторские изменения запрещены, значит, на этом этапе будут только исправляться ошибки. Обычно в процесс работы с бета-тестировщиками так или иначе оказы вается вовлеченным весь основной персонал проекта — программисты, группа технической поддержки, группа маркетинга и, конечно, группа тестирования. Хотя программисты и не контактируют с бета-тестировщи- ками непосредственно, они могут заниматься написанием служебного про граммного кода, необходимого для организации бета-тестирования или Глава 13: Объединяющая 4 0 7 защиты программы от "пиратов". Последней цели могут служить следую щие средства. • Бомбы с часовым механизмом, разрушающие программу после оп ределенной даты. • Именные версии, во многие места кода которых встроено, непосред ственно или в зашифрованном виде, имя бета-тестировщика. Его имя отображается такой версией программы на экране, и, если те- стировщику вздумается распространять программу тем или иным способом, каждый будет знать, чьих рук это дело. Даже если "пират" удалит свое имя из программного кода, он наверняка пропустит те места, где имя зашифровано. Если после этого он поместит свою ко пию программы в CompuServe, откуда ее сможет загрузить хоть целый мир, компания сможет доказать в суде, что именно этот че ловек является виновником ее потерь. (Хотя едва ли бета-тестиров- щик достаточно богат, чтобы компенсировать потери компании, сама угроза раскрытия предотвратит нелегальные действия.) • Защита от копирования, если только удастся найти достаточно эффективное средство. • Другие приемы, являющиеся профессиональными секретами. Анализируя проблемы, о которых сообщают бета-тестировщики, имейте в виду, что их источником может быть и добавленный в программу защит ный код. Поэтому, если ошибка не воспроизводится, проверьте ту версию программы, с которой работал сообщивший о ней тестировщик. Маркетинговая деятельность после завершения бета-версии Если упаковка и дополнительные материалы еще не готовы, работа над ними продолжается. Обложки и этикетки дисков обычно разрабатываются на бета-этапе, так что по его завершении группа тестирования должна быть готова их проверить. Сотрудники группы маркетинга могут работать с бета-тестировщиками и сообщать руководству об их замечаниях и предложениях. Они же могут отсылать копии продукта обозревателям из периодических изданий и на стаивать на тех изменениях, которые поспособствуют их более благопри ятным отзывам. Вообще, вокруг таких изменений всегда создается очень напряженная атмосфера. С одной стороны, их политическая важность бес спорна. А с другой стороны, они могут повлечь за собой новые серьезные проблемы и ошибки, которые перед самым выпуском, мягко говоря, неже лательны — из-за них может оказаться под угрозой своевременное завер шение проекта. |