Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Тестирование программного обеспечения. Фундамен...docx
Скачиваний:
3
Добавлен:
01.05.2025
Размер:
936 Кб
Скачать
☆

Глава 3: Типы тестов ... 67

пню лучше всего быть пассивными участниками и высказываться только в случае необходимости.) На этапе проектирования в центре внимания ана- 111 гиков должны быть следующие вопросы.

• Действительно ли проект хорош? Будет ли на его основе создан эффективный, компактный, хорошо тестируемый и легкий в сопро­вождении и модернизации продукт?

• Соответствует ли проект требованиям? Проект должен быть формализованным выражением требований, представленных в доку­ментации этапа планирования.

• Полон ли проект? Описывает ли проект все взаимосвязи между модулями и данными, передачу данных между модулями, условия работы каждого модуля и их реализацию.

• Достаточно ли он реалистичен? Удовлетворяют ли имеющиеся системные ресурсы (как аппаратные, так и программные) потребно­стям проекта? Сможет ли программный продукт работать достаточ­но быстро, достаточно быстро извлекать информацию из баз данных и ее обрабатывать? Удачно ли выбраны инструментальные средства разработчиков?

• Хорошо ли описана в проекте подсистема обработки ошибок? При

нисходящем проектировании особенно велико искушение оставить вопросы обработки ошибок на потом — как самые незначительные. И когда наступает это “потом”, о подобных элементах часто вооб­ще забывают, или же из-за нехватки времени они проектируются наспех, поверхностно и в результате — плохо. Все возможные усло­вия возникновения ошибок должны быть самым тщательным обра­зом продуманы и описаны в проекте. Важно правильно определить уровень, на котором обрабатывается каждая из ошибок, чтобы ее возникновение в одном модуле не вело к ошибкам в других.

О многих возможных ошибках проектирования и критериях оценки проектных документов рассказывается в книгах Данна (Dunn, 1984) и Фридмана и Вейнберга (Freedman & Weinberg, 1982). Об анализе проекта можно также почитать и у Бейзера (Beizer, 1990).

Совещания аналитиков

Обычно целью совещаний, проводимых при анализе проектных доку­ментов, является не решение проблем, а прежде всего их выявление.

В совещании должна участвовать небольшая группа сотрудников — около семи человек. В эту группу не должны входить авторы проекта. Аналитики заранее читают документы и на совещании критикуют их и задают друг другу вопросы. Во многих компаниях проект вообще не счи­

68 Часть I: Основы

тается завершенным, пока на него не будет составлена формальная рецен­зия (разумеется, одобрительная). Таким образом, проект перерабатывает­ся и снова анализируется до тех пор, пока он не будет одобрен группой аналитиков. Совещания этой группы могут быть трех типов: обзорные, ин­спекционные и рецензионные.

• Обзорное совещание. На таком совещании проектировщики демонстри­руют модель программы. Шаг за шагом они показывают, что делает программа с тестовыми данными, предложенными аналитиками. Такая демонстрация позволяет увидеть, как взаимодействуют между собой различные части системы, и выявить ее недостатки: неудобные ре­жимы, избыточность функций или пропущенные детали.

• Инспекционное совещание. На таком совещании специалисты под­робно анализируют каждый элемент проекта или его отдельный аспект: обработку ошибок, соответствие ранее выработанным стан­дартам, эффективность реализации конкретной функции и т.д.

• Рецензионное совещание. К этому совещанию аналитики готовят список возникших у них вопросов. Они делятся своими соображе­ниями и выделяют элементы проекта, которые показались им неточ­ными или сомнительными. Цель этого совещания — сформировать список всех выявленных проблем и убедиться, что каждую из них проектировщики правильно поняли. Решение выявленных проблем в задачи совещания не входит.

Идеальное рецензионное совещание должно направляться опытным в этом деле специалистом и обязательно записываться. Такой специалист- организатор находит подходящее помещение, ведет совещание, останавли­вает говорящих, когда они прерывают друг друга или отклоняются от темы, и готовит итоговый отчет. Он следит за тем, чтобы от обсуждения проблем аналитики не переходили к обсуждению способов их решения. Это будет сделано позднее меньшей группой специалистов и вне рецензионного со­вещания.

Специальный персонал записывает все важные замечания и с помощью проекторов или другой аналогичной техники выводит их на большой экран, где они видны каждому участнику совещания. Любой, кому покажется, что записывающий упустил нечто важное, может попросить отобразить эту ин­формацию. Обязательно должно фиксироваться каждое достигнутое согла­шение. Записаны должны быть и все вопросы, которые остались открытыми до следующего совещания. Такая техника проведения совеща­ний исключительно способствует их продуктивности, особенно когда мне­ния аналитиков очень сильно расходятся.

Некоторые группы тестирования специально обучают свой персонал ведению и протоколированию таких совещаний. Это прекрасная идея,