Причина

Ядро Windows 95 (Kernel32.dll) содержит ошибку, которая препятствует корректному освобожде­ нию определенных небольших структур данных, связанных с процессами сокетов Windows и вы­ деленными каналами. Со временем эти небольшие утечки памяти могут приводить к существен­ ному уменьшению объема доступной памяти.

Имейте в виду, что ресурсы, связанные с программой, можно освободить, закрыв программу. По­ сле выхода из программы и перезапуска Windows 95 память освобождается.

Рис. 10.5. Поступившая в продажу версия Windows 95 с утечками памяти операционной системы.

Утечки памяти особенно трудно выявить в объектно-ориентированных исходных кодах. Тем не менее, при помощи трассировки и отслеживания гистограммы объектов (Object Histogram), разработчик может выяснить, какой объект выделяет и освобождаетпамять и какие вызовы присутствуют между этими вызовами диспетчера памяти. Пе­ ред загрузкой и запуском сомнительной Java-программы саму среду следует запустить с параметром -tracepopulation. Как только объект, вызывающий утечку памяти, локали­ зован, не забудьте воспользоваться технологией статического тестирования для ус­ корения выяснения основной причины. Еще важнее разобраться в коде и любых воз­ можных прерываниях в удачной ветви, которые могут помешать объекту освобождать память. В C++ существует объект debug_malloc, который может оказаться очень полез­ ным для трассировки утечки памяти. Хотя утечки памяти не носят перемежающийся характер, они быстрее проявляются в бездисковых системах с небольшим объемом памяти, нежели в конфигурациях с большим объемом оперативной памяти и диско­ вого пространства, перезагрузка которых выполняется редко (например, в сервер ных приложениях).

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

Тестирование интерфейса " человек-компьютер"

Интерфейс " человек-компьютер" (human-computer interface, HCI) в современных компьютерах может охватывать широкое множество различных периферийных уст­ ройств, таких как клавиатура, клавишная панель, мышь, световое перо, монитор с сенсорным экраном, речевой интерфейс, сканер и многие другие. Кроме того, в слу­ чае использования больших систем управления производством, работающих на осно­ ве больших вычислительных машин, для работы с программой может требоваться большое количество операторов, каждый из которых имеет собственный персональ­ ный компьютер, действующий как терминал большой вычислительной машины. Планирование тестирования исключительно важно для координации тестирования интерфейса " человек-компьютер", поскольку, возможно, это — единственное тести­ рование, при котором продукт рассматривается полностью с точки зрения пользова­ теля. Через этот интерфейс доступны для тестирования многие функциональные тре­ бования пользователя, а именно это и есть основная цель системных испытаний.

При использовании интерфейса " человек-компьютер" для выполнения тестиро­ вания с точки зрения пользователя следует учитывать одно важное обстоятельство. Если команда тестирования начинает тестирование с этапа системных испытаний и при этом интенсивно использует интерфейс " человек-компьютер", диапазон тести­ рования будет очень ограничен. Тестирование интерфейса " человек-компьютер" — лишь один из множества способов выполнения быстрого тестирования с целью об­ наружения ошибок. Фактически, как правило, процесс тестирования интерфейса " человек-компьютер" оказывается не слишком эффективным при поиске даже наибо­ лее общих ошибок, поскольку этот процесс больше ориентирован на проверку мар­ шрута прохождения потока данных по продукту, а этот маршрут уже подвергался ин­ тенсивному поблочному тестированию, выполняемому по тщательно разработанным сценариям.

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

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