Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 12: Планирование и документация 3 4 5 К сожалению, здесь же имеется и целый ряд проблем. • Неопытные тестировщика (включая и многих достаточно опыт ных программистов) — это плохие тестировщики. Для подтверждения этого факта приведем пример из нашей соб ственной практики. Мы исследовали производительность нескольких прекрасных специалистов из отдела технической поддержки. Эти люди занимались жалобами пользователей, уже купивших наш про дукт. Их заинтересованность в поиске проблем была крайне высо ка. Работали они по подробным и очень тщательно подготовленным сценариям. Параллельно с ними программу тестировали несколько сотрудников нашей группы — ту же версию и по тем же сценариям. Результат был однозначным: опытные тестировщики нашли больше ошибок, причем среди них были такие, которые вообще было трудно пропустить, и все же неспециалисты их пропустили. Особенно плохо неопытные тестировщики справляются с трудноуло вимыми ошибками или ошибками, связанными с временными пара метрами выполнения программы. Они редко документируют ошибки, которые трудно повторить. Кроме того, они не документи руют проблемы, которые, как им кажется, могут быть связаны с неверным пониманием программы. Неопытные тестировщики не до кументируют ошибку, если им кажется, что читатель отчета посчи тает ее незначительной. И есть еще много других проблем, которые они пропускают или оставляют недокументированными. • Написание хорошего сценария требует много времени. На написа ние хорошего сценария и подготовку сопутствующих материалов (копий экрана, файлов и т.п.) уходит в 5-15 раз больше времени, чем на подготовку и выполнение исходного теста. • Сценарий ни в коем случае не должен содержать ошибок. У тести- ровщиков, которые им руководствуются, нет ни опыта, ни знаний для исправления ошибок в сценарии. Если что-то пойдет не так, как в нем написано, они просто не будут знать, что делать. И если та кой тестировщик поймет, что в сценарии есть ошибка, он не будет документировать даже те проблемы, которые увидит, поскольку посчитает, что они связаны со сценарием, а не с самой программой. Разрабатывая сценарии, следует постоянно иметь в виду, что они пи шутся не для опытных тестировщиков, а значит, в них должна быть совер шенно иная информация. Скорее всего, вам придется составлять оба типа документов. В сценарии ничего не говорится о назначении тестов и их входных данных. Ведь неопытного тестировщика такая информация толь ко смутит. Главное содержание сценария — это процедура выполнения теста, и в частности, следующая информация. 3 4 6 Часть II: Приемы и технологии тестирования • Четкие пошаговые инструкции для выполнения теста. Его испол нитель не должен догадываться, что и как делать, это должно быть совершенно четко записано в инструкции. • Точное описание ожидаемых результатов, включая и то, что должен видеть тестировщик на каждом этапе инструкции. Очень полезны распечатки копий экрана. Отметьте в них маркером, куда именно следует смотреть. • Описание возможных вариантов неудачного прохождения теста программой. Не вдаваясь во внутренние механизмы работы програм мы, расскажите, что может быть не так и как это будет выглядеть. Приведите примеры того, что тестировщик может увидеть или услы шать в случае сбоя. • Квадратики, в которых тестировщик будет отмечать, что тест выполнен. Сценарий может иметь форму контрольного списка или бланка, в который вписываются ответы на вопросы. Если необходи мо, чтобы тестировщик обратил внимание на определенный аспект поведения программы, следует внести в сценарий соответствующий вопрос. То, как организовать сценарий, может существенно повлиять на резуль таты работы. Инструкции должны быть отделены от описаний, например, Что сделать должно быть записано в отдельном столбце, перед Что вы увидите. Не менее важен и порядок заданий. Тестировщик не должен пе рескакивать между классами тестов. Кроме того, у него не должно быть чувства, что он зря теряет время. Прежде чем передать сценарий временному персоналу, предложите его для опробования опытному тестировщику. Заметки для руководителя Ваш руководитель, вероятнее всего, сам является опытным тестировщи- ком, и поэтому все ваши тестовые материалы будут ему интересны. Однако лучше думать о нем как об администраторе и оставить в стороне его тех нический опыт. Прежде всего его интересует продвижение работ и то, на сколько хорошо протестирована каждая из составляющих программы. Возможно также, что его заинтересует, когда в последний раз выполнялся определенный тест или когда тестировался тот аспект программы, в кото ром только что выявлена серьезная ошибка. В идеале заметки для руководителя проекта должны храниться в базе данных. В ней должно быть по одной записи для каждого теста, а сами записи должны содержать следующую информацию. • Имя или номер, однозначно идентифицирующие тест. • Набор классификационных идентификаторов. Вместе эти иденти фикаторы указывают, что с помощью данного теста проверяется | Глава 12: Планирование и документация 347 восстановление информации с диска, сортировка, выбор опции из главного меню и отображение сортируемых данных. Благодаря тако му количеству идентификаторов при возникновении проблемы легко отыскать все связанные с ней тесты. • Список результатов тестирования. Для каждого из циклов, в кото рых выполнялся данный тест, в списке указывается тестировщик и номер цикла, а результат теста определяется как пройден или не пройден (со ссылкой на отчет о проблеме). Кроме того, программу следует разделить на ряд функциональных об ластей и для каждой из них оценить приблизительное количество необхо димых тестов. Со временем, когда ваш собственный список функций программы будет расширен, можно пересмотреть это разбиение. Это помо жет формировать "показательные" отчеты о том, сколько тестов для каж дой из областей уже выполнено и сколько еще предстоит. Документы для юридического использования Если клиенты подадут на вашу компанию в суд за ошибки в програм ме, адвокат должен будет доказать, что тестирование программы проводи лось тщательно и на достаточном профессиональном уровне. Если это и в самом деле так и если сбои программы могут обходится клиентам очень дорого, ведите записи о проделанной работе. Спросите у юриста компании, какие записи будут ему наиболее полезны. Подробнее этот вопрос рассматривается в главе 14. Типы тестовых документов В этом разделе описывается несколько типов документов, составляющих тестовые материалы. Многие из них основаны на стандарте ANSI/IEEE Standard 829-2983 for Software Test Documentation, в котором предпринята попыт ка определить универсальный набор документов для промышленного исполь- зрвания. О многих других спецификациях для тестовых документов пишет Шалмейер (Schulmeyer, 1987). Стандарт 829-2983 можно за несколько долларов заказать по следующе му адресу: Computer Society of the IEEE P. O. Box 80452 Worldway Postal Center Los Angeles, CA 90080 Можно также позвонить в офис IEEE Standards Sales в Нью Джерси по телефону 201-981-0060. В стандарте 829 ничего не говорится о том, в каких случаях необходим каждый из перечисленных в нем документов. Выбор комплекса докумен- 3 4 8 Часть II: Приемы и технологии тестирования тов определяется нуждами проекта и личными предпочтениями его руко водства, поэтому мы воздерживаемся от каких бы то ни было советов по этому поводу. Единственное, что можно сказать наверняка, — это то, что никто и никогда не станет составлять все перечисленные в стандарте до кументы. Более того, форма и содержание этих документов также зависят от вашего выбора: если какой-либо из них показался вам полезным, это еще не значит, что нельзя опустить некоторые его составляющие. Стандарт никоим образом не должен вас связывать. Он описан в этой книге пото му, что является хорошей основой, которую после тщательного анализа следует адаптировать к собственным нуждам. И последнее: не пытайтесь написать всю документацию до начала тестирования. Первый черновик тестового плана лучше написать заранее, остальное же гораздо эффектив нее дорабатывать по ходу тестирования. Кроме того, полезно перед нача лом тестирования распространить среди заинтересованного персонала комплекс приемочных тестов. Тестовый план В этом документе определяется содержание работ по тестированию программного продукта. Это может быть один-единственный документ, но чаще он представляет собой целый комплекс документов, полный перечень которых приводится в отдельном разделе плана. Вот как разделы тестово го плана определяются стандартом ШЕЕ 829. • Идентификатор тестового плана. Это уникальное имя или номер плана. Такой идентификатор полезен при хранении документов в базе данных. • Введение. В этом разделе приводятся ссылки на все связанные юри дические документы и стандарты, а также плановые документы са мого продукта. • Тестируемые элементы. Речь идет о подлежащих тестированию программных компонентах — функциях, модулях, возможностях и т.п. Можно либо перечислить их прямо здесь, либо сослаться на соответствующий документ. Кроме того, в этот раздел включаются ссылки на спецификации (требования и проектные документы) и документацию к продукту (руководство пользователя, руководство по установке продукта и т.п.). • Тестируемые функции. Снабдите их ссылками на спецификацию комплекса тестов. • Нетестируемые функции. Какие именно и почему. • Подход. Опишите общий подход к тестированию: кем оно выполня ется, каковы основные видов планируемых работ, какие технологии и средства применяются для тестирования каждой из основных Глава 12: Планирование и документация 3 4 9 групп функций продукта. Каковы критерии адекватного тестирова ния каждой группы? Стандартом определяется, что именно здесь, а не в разделе "Календарный план" приводятся базовые требования, включая крайние сроки завершения работ и требования к наличию персонала и тестируемых элементов. • Критерии прохождения тестов. Как тестировщик определяет, про шла ли программа конкретный тест? • Критерии приостановки и возобновления работ. Перечислите все возможные причины, по которым тестирование может быть прекра щено до решения проблемы. Что должно быть сделано, чтобы рабо ты можно было продолжить? Какие тесты после этого должны быть проведены повторно? • Документация. Это список всех тестовых документов, которые дол жны быть составлены для данного продукта. • Задачи тестирования. Перечислите все задачи, которые решаются в ходе подготовки к тестированию и его проведения. Покажите зависимости между задачами, укажите, какие особые навыки или специалисты необходимы для выполнения каждой из них. Здесь же указывается, кто и когда выполняет работы и насколько они трудо емки. • Необходимое оборудование. Здесь перечисляется все необходимое для работы аппаратное и программное обеспечение, тестировочные сред ства, лабораторное оборудование и т.п. • Ответственность. Это перечень групп и отдельных лиц, ответ ственных за управление, проектирование, подготовку, выполнение, контроль работ, исправление ошибок, решение проблем, обеспече ние необходимого оборудования и т.п. • Необходимый персонал и обучение. Специалисты каких квалифика ций и в каком количестве необходимы для решения поставленных задач, какое обучение необходимо пройти имеющимся сотрудникам? • Календарный план. Перечислите ключевые даты, укажите, когда необходимы конкретные ресурсы (люди, техника, инструментальные средства и др.). • Риск и непредвиденные обстоятельства. Каковы наихудшие пред положения о выполнении тестового плана? Из-за чего тестировщи- ки могут не уложиться в сроки и что будет предпринято в этом случае? • Утверждение. Кто утверждает тестовый план? Укажите место для их подписей. 3 5 0 Часть II: Приемы и технологии тестирования Список функций Этого документа в стандарте ШЕЕ 829 нет. О списке функций програм мы подробно рассказывалось в соответствующем разделе этой главы. Его можно включить в раздел тестового плана "Тестируемые элементы", а можно сделать отдельным документом. Критерии приемки на тестирование Этого документа в стандарте IEEE 829 также нет. Приемочные тесты — это небольшой набор тестов, которые должна пройти программа, прежде чем она будет принята тестовой группой для проведения полного цикла тестирования. Если программа не проходит эти тесты, значит, она еще слишком нестабильна, чтобы с ней стоило возить ся. На приемочные тесты, как правило, должно уходить меньше получаса, и уж никак не более двух часов. Если в данном проекте используются приемочные тесты, напишите документ с их точным определением. Передайте его программистам, при чем сделайте это заранее — до начала первого цикла тестирования. Этот документ должен быть настолько подробным, чтобы программисты могли самостоятельно тестировать по нему программу еще до того, как передадут ее вам. Это позволит им устранить самые явные ошибки так, чтобы их никто не увидел. Спецификация комплекса тестов Этот документ определяет, как будет тестироваться каждая функция или группа функций программы. В соответствии со стандартом IEEE 829 в него входят следующие разделы. • Идентификатор спецификации тестового проекта. Это уникальное имя или номер документа. • Тестируемые функции. Это область применения данной специфика ции. • Подход. Этот раздел дополняет и расширяет соответствующий раз дел тестового плана. В нем описываются специфические тестовые технологии. Как анализируются результаты тестов (визуально или программным путем)? На каких граничных и других условиях осно вывается выбор конкретных тестов? Каковы ограничения и требова ния, общие для всех (или большинства) тестов? • Определения тестов. Перечислите и коротко опишите все тесты данного комплекса. Если тестируется много различных типов фун кций, комплексов тестов также может быть достаточно много. • Критерии прохождения тестов. Как тестировщик решает, прошла ли тест данная функция или комбинация функций? Глава 12: Планирование и документация 3 5 1 Спецификация отдельного теста В соответствии со стандартом 829, спецификация, описывающая отдель ный тест, включает следующие разделы. • Идентификатор спецификации теста. Это уникальный номер до кумента. • Тестируемые элементы. Для каких функций, модулей и т.п. пред назначается данный тест? Приведите ссылки на спецификации и руководства. • Спецификации ввода. Приведите значения всех входных данных, их диапазоны или имена файлов. Здесь указывается все, что так или иначе относится ко входным данным теста: содержащие их области оперативной памяти, значения, передаваемые операционной системой, другими программами или базами данных, выводимые на экран запро сы, а также взаимосвязи этих элементов данных. Сюда же относятся и временные характеристики ввода. Например, если тестировщик должен ввести информацию, пока мигает индика тор активности диска или в течение секунды после получения опре деленного сообщения, об этом следует написать в данном разделе. • Спецификация ввода. Перечислите все выходные значения и сооб щения. Если время ответа имеет значение, указывайте и его. • Необходимые ресурсы. Здесь перечисляются специфические требова ния к аппаратному и программному обеспечению, другим техничес ким средствам и персоналу. • Особые процедурные требования. В этом разделе описываются не стандартные действия по настройке и тестированию или специфи ческие формы анализа результатов. • Зависимости между тестами. Какие тесты должны быть выполне ны перед данным тестом, почему и что будет, если программа их не пройдет? Спецификация процедуры тестирования В этом документе описывается последовательность действий по выпол нению каждого набора тестов и анализу их результатов. В соответствии со стандартом 829 в него включаются следующие разделы. • Идентификатор спецификации процедуры тестирования. • Назначение. Для чего служит данная процедура? В раздел включа ются перекрестные ссылки на все связанные с ней тесты. • Особые требования. Здесь приводится перечень всех процедур, ко торые должны предшествовать данной, специфические навыки тес- 3 5 2 Часть II: Приемы и технологии тестирования тировщика, особые требования к аппаратно-программной среде и инструментам. • Последовательность выполнения процедуры. В перечень включаются следующие из необходимых действий. • Запись в журнале. Специальные методы или формат протоколи рования результатов или наблюдений. • Настройка. Подготовка к выполнению процедуры. • Начало. Как начать выполнение процедуры. • Выполнение. Перечень действий, выполняемых в данной проце дуре. • Измерения. Как выполняются тестовые измерения (например, как фиксируется время ответа). • Приостановка. Как приостановить тест в случае необходимости (например, если он слишком длинный и тестировщик хочет уйти домой на ночь). • Возобновление. С какого места и как процедура возобновляется после приостановки. • Остановка. Как завершить выполнение процедуры. • Восстановление. Как вернуть окружение в исходное состояние. • |