Статья была переработана с учётом полученной в форуме критики и рекомендаций.
Этой статьей я хотел бы описать своё понимание тестирования программного обеспечения - процесса не тривиального, как мне всегда казалось, и, я даже не мог себе представить, весьма интересного.
Меня всегда интересовало, что такое тестирование ПО. Зачем нанимать кого-то для тестирования программного продукта, если разработчик и сам может потратить пару часов на такое не значительное по приоритету задание. И, наконец-то, зачем вообще тестировать? Ведь программисты ребята умные - пишут правильно. Но
не все так просто как мне казалось.
Перейдя из программистов в тестеры, не имея достаточного количества теории за пазухой, я достаточно долго пытался «поломать» программный продукт, давая на вход заведомо неверные входные данные. И, как не странно, ломалось. Создавалось сообщение об ошибке, и очередной день считался прожитым не зря.
Позже, я начал сталкиваться с тем, что, сколько тесты не гоняй, а ошибки все равно выплывают. Не имея какого-либо представления о том, что и как должно даваться «на вход» тестируемому приложению процесс тестирования казался бесконечным. Как результат - замкнутый круг, в котором сорванные сроки на тестирование, злой ПМ и уставшие от «глупостей» разработчики.
И только многим позже я выделил для себя четкую последовательность действий, которые необходимо выполнять для тестирования программного обеспечения:
- Изучение спецификации. Эта стадия самая важная, её ещё называют анализом дизайна и/или требований. Иногда применяют название «тестирование спецификации», чуть ниже мы поймём, почему именно «тестирование». Тут надо внимательно прочитать документацию (спецификацию) по приложению.
- Дымовое тестирование. На этой стадии надо проверить работает ли система вообще (правильно ли работает, правильно ли «ругается» при не правильной отработке и т.д.). Это делается для того, чтоб понять пригодно ли приложение для дальнейшего тестирования или оно вообще не работает (работает не правильно).
- «Позитивное» тестирование. На этой, третей стадии, надо проверить результат работы приложения при получении им «правильных» входных данных.
- «Негативное» тестирование. Это четвертая, завершающая, стадия начального тестирования. Тут надо посмотреть, как ведет себя приложение, получая на вход «неправильные» данные. Это делается для того, чтоб определить, как ведет себя приложение в таком случае. Если такой вариант описан в спецификации, а он должен быть описан, то сравнить ожидаемый результат с полученным результатом.
Итак, рассмотрим все по порядку.
Спецификация, требования, SRS.
Как определить когда и как должно работать само приложение, когда и как оно должно «ломаться» (то есть как система или её модуль должен реагировать на невалидные данные или неверное поведение пользователя)? Что должно быть в результате правильной отработки, при каких условиях и входных данных правильная отработка должна иметь место? Что должно быть в результате не правильной отработки тестируемого приложения, при каких условиях она должна иметь место?
На все эти вопросы есть ответ в документации тестируемого приложения. Во всяком случае, он, ответ, должен там быть, иначе документация не полная, что равняется ошибке в документации. Хочу оговориться, что уже на этой стадии могут возникать первые дефекты - дефект в спецификации (в требованиях) такой же по важности для системы (а порой и более высокий по приоритету!) дефект. Стоит также оговориться, что тестирование требований это такой полноценный же вид тестирования, которому незаслуженно уделяют мало внимания. Основными показателями успешного тестирования требований является достижение критериев полноты (тестопригодности) и непротиворечивости требований.
Документация дает возможность понять для себя основные ступеньки проверки приложения, где и как должно приложение работать, где «ломаться». И, что не мало важно, как ломаться. Что «говорить» при успешной отработке, какие сообщения на ошибку могут/должны появляться при отработке.
Поняв все «премудрости» требований к приложению и особенности реализации этих требований разработчиком, можно приступать к тестированию конечного результата.
Процесс тестирования
Этот процесс можно описать следующими шагами:
- Проверить, как работает приложение, когда оно получает на вход «правильные» данные (чтоб узнать «что такое хорошо и что такое плохо» читаем документацию);
- Если все работает и работает правильно (т.е. именно так как описано в спецификации), следующим шагом является проверка граничных значений (т.е. там, где начинаются «правильные» данные и там где они заканчиваются);
- Проверка работы приложения при вводе данных, которые не входят в область допустимых значений (опять таки, смотрим спецификацию).
В первом и втором пункте описан процесс, который называется «позитивным» тестированием. «Позитивное» тестирование - это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению тестируемой системы.
Третий же пункт описывает противоположный «позитивному» процесс - «негативное» тестирование. Это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы - различные сообщения об ошибках, исключительные ситуации, «запредельные» состояния и т.п.
Однако предшествовать «позитивному» и «негативному» тестированию должны работы по выполнению «дымового» тестирования.
Информационный словарь дает достаточно четкое определение термина «дымовое тестирование»:
- рудиментарная форма тестирования программного продукта после изменения его конфигурации либо после изменения его (программного продукта) самого. В процессе дымового тестирования тестировщик проверяет ПО на наличие «дыма», т.е. ищет какие-либо критические ошибки программы;
- первый запуск программы после её критического изменения или «сборки».
Приоритеты в тестировании
Почему «позитивное» тестирование считается на порядок более важным, чем «негативное»?
Предположим, что система не слишком устойчива к «плохим» вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить «подводные камни», не будут делать «опасные» или «неразрешённые» действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа «ни в коем случае не оставляйте это поле пустым, а то...».
Но - всего этого не будет вовсе, если система не выполняет свое основное предназначение, если пользователи (заказчики) не могут решить свои бизнес задачи, если они все делают правильно, вводят хорошие данные, но не получают результата. И посоветовать им ничего в этой ситуации нельзя. И они уходят...
Именно поэтому «позитивное» тестирование гораздо, гораздо важнее «негативного».
Впрочем, это не означает, что «негативными» тестами можно пренебречь, т.к. не на всех этапах жизненного цикла ПО приоритеты ценностей сохраняются неизменными.
Резюме
Теперь, сделав первые удачные шаги в тестировании приложения и получив положительный результат, можно думать о более мудреных способах протестировать приложение, как говорится: «Дальше - больше». Все зависит от глубины необходимого уровня тестирования, желания и возможности проверить приложение. Естественно, описанные выше четыре стадии не покрывают полного цикла тестирования приложения, однако являются обязательными для начального тестирования.
Терминология Quality assurance
В этой статье мы будем рассматривать QA (Quality Assurance) в разработке программного обеспечения. Все это относиться к тестированию программного обеспечения, но в этой статье мы не будем изучать тонкости, а лишь разберемся с терминологией. Терминология в QA очень важна, без неё не возможно будет провести тестирования продукта. Как уже могли догадаться, QA расшифровывается как Quality Assurance что в переводе - обеспечение качества (контроль качества). Перейдём непосредственно к терминологии:
Позитивное тестирование (positive testing)
Это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. Основной целью “позитивного” тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.
Негативное тестирование (negative testing)
Это тестирование на данных или сценариях, которые соответствуют нештатному поведению. Основной целью “негативного” тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных.
Функциональное тестирование (functional testing)
Это тестирование в целях проверки реализуемости функциональных требований для решения задачи пользователя.
Функциональные тестирование включают в себя:
- Функциональная пригодность (suitability)
- Точность (accuracy)
- Способность к взаимодействию (interoperability)
- Соответствие стандартам и правилам (compliance)
- Защищённость (security)
Тестирование производительности (performance testing)
Это тестирование, которое проводится с целью определения, как быстро работает вычислительная система или её часть под определённой нагрузкой. Также может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов.
Тестирование производительности включают в себя:
- Нагрузочное тестирование (load testing)
- Стресс-тестирование (stress testing)
- Тестирование стабильности (stability / endurance / soak testing)
Тестирование удобства использования (usability testing)
Это тестирование удобство использования определяет степень простоты доступа пользователя к функциям системы, предоставляемым через пользовательский интерфейс.
Тестирование пользовательского интерфейса (UI testing)
Тестирование графического интерфейса пользователя предполагает проверку соответствия приложения требованиям к графическому интерфейсу, профессионально ли оно выглядит, выполнено ли оно в едином стиле.
Тестирование безопасности (security testing)
Процесс оценки уязвимости программного обеспечения к различным атакам.
Тестирование локализации (localization testing)
Это процесс тестирования локализованной версии программного продукта. Проверка правильности перевода элементов интерфейса пользователя, проверка правильности перевода системных сообщений и ошибок, проверка перевода раздела “Помощь”/“Справка” и сопроводительной документации.
Тестирование совместимости (compatibility testing)
Вид нефункционального тестирования, основной целью которого является проверка корректной работы продукта в определенном окружении.
Окружение может включать в себя следующие элементы:
- Аппаратная платформа;
- Сетевые устройства;
- Периферия (принтеры, CD/DVD-приводы, веб-камеры и и.т.д);
- Операционная система (Unix, Windows, MacOS, …)
- Базы данных (Oracle, MS SQL, MySQL, …)
- Системное программное обеспечение (веб-сервер, файрвол, антивирус, …)
- Браузеры (Internet Explorer, Firefox, Opera, Chrome, Safari)
Тестирование чёрного ящика (black box)
Метод тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта.
Тестирование белого ящика (white box)
Выполняется с целью обнаружения проблем во внутренней структуре программы. Это требует от проверяющего глубокого знания внутренней структуры и следовательно, не может быть выполнено обычным пользователем. Общая задача такого тестирования обеспечить проверку каждого шага по алгоритму программы.
Тестирование серого ящика (grey box)
Представляет собой сочетание тестирования белого ящика и черного ящика. Целью данного тестирования является поиск дефектов, если таковые из-за неправильного структуры или неправильного использования приложений.
Ручное тестирование (manual testing)
Это процесс поиска дефектов в работе программы, когда происходит тестирования работоспособность всех компонентов программы, как если бы он был пользователем.
Автоматизированное тестирование (automated testing)
Этот процесса тестирования использует программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.
Модульное тестирование (component/unit testing)
Процесс позволяющий проверить на корректность отдельные модули исходного кода программы.
Интеграционное тестирование (integration testing)
Тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
Системное тестирование (system/end-to-end testing)
Это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования чёрного ящика и тем самым, не требует знаний о внутреннем устройстве системы.
Мы рассмотрели лишь небольшую часть терминологии, но достаточно важную в QA. Возможно, мы еще затронем тему тестирования, а на сегодня это все.
Похожие статьи:
Решение проблем Adobe Flash на примере YouTube - Читать
- pidval сделал(а) реблог этого от
- alexruzhyk понравилось это
- anko-777 сделал(а) реблог этого от
- понравилось это
- maryarti понравилось это
- dfdor44f понравилось это
- eridi сделал(а) реблог этого от
- seonoptik понравилось это
Мы (не такой уж это и секрет) очень переживаем за качество своих продуктов и с трепетом наблюдаем за обваливанием системы. Это оправдывает существование тестировщиков в мире. Это заставляет нас чувствовать себя героями: пришёл великий Тестер и спас своих пользователей от ужасных критических багов!
И наши тестировщики никогда не забывают про негативное тестирование, хотя не всех прогеров это радует. Но такие проверки не прихоть «злых тестеров», они вызваны необходимостью закрыть уязвимости и обезопаситься от проникновения в систему хакеров и ботов, Dos/DDos атак.
Конечно, ведь в чём состоит призвание тест-специалистов? Нужно найти проблемы. Проблемы, о которых никто чаще всего не успевает подумать, не хочет их видеть и иметь с ними дело. А уж если проверяется не только правильная работа системы, но и её ненормальное поведение, то напряжённости в команде добавляется.
Понимаете, программисты-то пишут софт, нацеливаясь на результат, на запланированный релиз, летят на крыльях вдохновения! А тут наступает этап проверки и многочисленных исправлений и правок «идеального» кода. И всё, прячься кто куда, система на тестировании.
Чтобы никого не нервировать, некоторые специалисты могут откладывать негативное тестирование на потом или вообще игнорировать его (ужас!) в угоду сокращения сроков и бюджета. Ну а чего проверять, если прога не делает даже того, что должна, правда? Не-а.
Позитивное и негативное тестирование
Но обо всём по порядку. При тестировании ПО с помощью тест-кейсов, существует два набора проверок: позитивные и негативные. Причем вторых обычно больше, чем первых.
Позитивное тестирование - это проверка работы системы на соответствие её нормальному (штатному, ожидаемому) поведению, согласно ТЗ и . То есть здесь мы смотрим, делает ли ПО то, чего от него ждут, соответствует ли реализация современным требованиям, поддержаны ли гайдлайны пользовательского интерфейса и т.д.
А негативное тестирование - это тестирование системы на нештатное поведение. Смотрим, устойчиво ли ПО к неверному вводу данных, как обрабатываются исключительные ситуации, какая информация показывается в сообщениях об ошибках, возможно ли нарушить функционирование продукта и/или повлиять на производительность решения и так далее.
Мы уже сказали, что некоторые специалисты оставляют негативное тестирование на потом или вообще про него забывают, что почти одно и то же. Сами знаете, отложенное на потом почти всегда остается не выполненным.
Поэтому, по нашему мнению,
Негативное и позитивное тестирование вообще не нужно разделять и разносить во времени.
Поскольку можем ли мы сказать, что система работает как надо, если проверяем её реакцию только на правильных входных данных?
Позитивно-негативное тестирование
При тестировании ой как важны интуиция, чуйка, охотничьи инстинкты – зовите, как хотите. И вот сидит такой наш инженер, проверяет форму регистрации, допустим.
Проверяет всё по ТЗ и тестовым сценариям, смотрит, как данные обрабатываются, которые юзер должен ввести в поля (не факт, что введёт, кстати) и тут вот оно – озарение! Ему кажется, что если ввести вот в это поле для login какой-нибудь «%адынадын/>», а не обычный текст, то что-то точно произойдёт. Что-то тёмное и мрачное неправильное.
И что? Он должен сказать себе: «Нет. Сейчас я должен заниматься позитивным тестированием и ничем другим. Вот у меня назначено негативное на следующей неделе, тогда и настанет время для %адынадын/>. Наверное»?
Мы считаем такой подход к негативному тестированию неэффективным, и вот почему:
- Если проводить позитивное и негативное тестирование по отдельности, то это будет дольше. Как минимум потому, что это будут уже две итерации тестирования.
- Тестеры и кодеры живут в условиях дедлайнов. И если время строго ограничено, то откладывание негативного тестирования на потом повышает риск того, что про него вообще в итоге забудут. Ведь чем ближе к моменту Х, тем быстрее летит время, скорее требуется выполнить поставленные задачи, исправить дефекты, применить финальные бизнес требования (которые могут измениться) и доделать ещё кучу дел. Дедлайн – время горячее!
- Разделение негативного и позитивного тестирования, по нашему мнению, просто противоречит природе тестера! Ведь основная его задача – это проверка системы на все возможные действия конечного юзера. А люди в большинстве своём нелогичны, и могут делать с софтом самые разные непотребства;)
Мы, как тестировщики, очень переживаем, если система содержит ошибки по проверкам из категории негативных. И особенно, если последствия таких ошибок критичны для всей системы. Но репортить их не боимся. Особенно с таким козырем в рукаве – у нас в команде есть девочки-тестировщицы. И кто сможет упорно отстаивать «идеальность» кода, когда они нежными голосками в пух и прах разносят работоспособность проекта? То-то же.
Так какие выводы мы можем сделать?
Не забывайте про негативное тестирование, объедините его с позитивным, соберите в команде опытных специалистов и старайтесь перекладывать задачу репортинга на плечи девочек! Всё, кроме последнего, советуем на 100%, а уж с этим разберётся ваш проект-менеджер.
И, конечно, обязательно проверяйте свой продукт, не думайте, что программисты сразу напишут код чисто и красиво – без багов всё равно не обойдётесь! Не говоря уже о многочисленных уязвимостях, что подтверждают регулярно утекающие в сеть персональные и конфиденциальные данные.
Тесты по картинкам и рисункам способны рассказать о личности человека даже то, о чем сам он не догадывается. Абстрактный рисунок расскажет, каким является ваше мышление и о чем это говорит.
Тест, который мы вам предложим, основан на тесте швейцарского психолога Германа Роршаха . В его основе лежали 10 аморфных пятен-клякс, которые предлагалось рассмотреть испытуемым. Вариации этого визуального теста широко известны. И сегодня подобные задания используют в самых разных целях, начиная от диагностики депрессии и заканчивая проверкой на силу воображения.
Наш экспресс-тест построен на одном таком абстрактном изображении. Каждый сможет увидеть в нем что-то свое. Взгляните на эту абстракцию и зафиксируйте ту ассоциацию, который она вам напомнила. Не ищите какого-то определенного сходства, не сидите над рисунком слишком долго: чем ярче и отчетливее сформируется ассоциация, тем правдивее получится результат.
Картинка-основа нашего теста выглядит так.
А теперь узнаем результаты и проверим, кто настроен на позитивное и созидательное начало, а кому пора избавляться от негативной энергетики .
Обратите внимание: если картинка вызвала у вас затруднения, если вы ничего не увидели, это замешательство может говорить о ситуации выбора, в которую вы прямо или косвенно поставлены на данный момент. Дискомфорт и раздражение при попытке сложить кляксы в нечто осмысленное также могут говорит о сдерживаемых отрицательных эмоциях.
Цветок. Эта ассоциация зависит от цветового пятна. Если вы видите его в теплых розовых или оранжевых оттенках, ваша энергетика ровная, и можно не беспокоиться, что в сознание прокрался негатив. А если контур цветка составляют голубоватые пятна, их холодный оттенок может свидетельствовать о подсознательной тревоге.
Скрипка. Или другой музыкальный инструмент. Это изображение указывает на творческое начало, но вместе с тем может быть символом тревожности. В целом же, несмотря на последнее обстоятельство, этот результат говорит о положительной направленности вашей энергетики, поскольку вам не чуждо творчество и вы взяли ориентирование на теплый оранжевый: он оказался доминантой в вашем визуальном восприятии.
Фигура человека. Чаще женская, вид со спины, но возможны иные трактовки. Фигуры людей на рисунках говорят об открытости перед окружающими. Вы не похожи на замкнутого человека, даже если являетесь интровертом. Препятствия прошлого не страшны вам, и вам также не чуждо представление о прекрасном.
Краб. Краб, рак или другое членистоногое (возможно, даже паук или осьминог). Эту ассоциацию трудно отнести к приятной, однако не спешите делать выводов. Прислушайтесь к себе. Если розоватое, крабообразное пятно вызывает у вас мысли о крабе где-нибудь на лазурном побережье, скорее всего, вы обладаете богатой фантазией, но ни о чем тревожном эта ассоциация не говорит. А вот если чувства, которые вызваны у вас подобным сходством, негативны (вы боитесь клешней, вам неприятны жвала, которые воображение уже нарисовало за вас) — время задуматься и настроиться на позитивную волну .
Головы. Головы диких животных, горгулий, бычья голова — все это довольно угрожающие символы. К этой же категории можно отнести маску. Подобное деление на части может быть вызвано внутренним разладом.
Внутренние органы. Если в цветовых пятнах вам видятся кости таза или картинка вызывает иные неприятные анатомические ассоциации, это может говорить о скрытых сексуальных проблемах или индивидуальных страхах. С ними лучше всего побороться лицом к лицу. Не спешите расстраиваться, если увидели в нашем тесте по картинке именно это. Позитивные установки способны изменить сознание в лучшую сторону .
Разумеется, все мы разные, и вполне вероятно, что вы увидели в этих абстракциях нечто свое, особенное и уникальное. В таком случае вы наверняка одарены нестандартным мышлением, и вашу креативность стоит беречь и развивать, ведь есть ситуации, в которых не обойтись без творческого подхода .
Желаем вам удачи в познании своей личности и внутреннего Я. Заглядывайте в и не забывайте нажимать на кнопки и
12.10.2016 03:32
Всем известно, что события, происходящие с нами, во многом обусловлены нашими мыслями. И даже если...
· Дымовое тестирование. На этой стадии необходимо проверитьработает ли система вообще (правильно ли работает, правильно лиобрабатывает ошибки и пр.). Это делается для того, чтобы понятьпригодно ли приложение для дальнейшего тестирования или оноизначально работает неправильно.
· «Позитивное» тестирование». На этой стадии необходимо проверить результат работы приложения при получении им «правильных» входных данных.
· «Негативное» тестирование. Это завершающая стадия начального тестирования. Необходимо посмотреть, как ведет себя приложение, подавая на вход «неправильные» данные. Если такой вариантописан в спецификации (а он должен быть описан), то необходимосравнить ожидаемый результат с полученным.
На стадии изучения спецификации определяется, когда и какдолжно работать само приложение, когда и как оно должно реагировать на ошибки, т. е. как система или ее модули должны реагировать на неправильные данные или неверное поведение пользователя
Документация дает возможность понять для себя основные этапы проверки приложения: где и как приложение должно корректно работать, как отрабатывать ошибочные ситуации: выдавать сообщения об ошибке, писать ошибку в файл протокола работы, прекращать выполнение и т. д.
1) проверьте, как работает приложение, когда оно получает навход корректные данные;
2) если все работает правильно, как описано в спецификацииследующим шагом является проверка граничных значений (минимальные и максимальные значения корректных данных);
3) проверьте работу приложения при вводе данных, которые невходят в область допустимых значений (проверка обработки некорректных входных значений).
В первых двух пунктах описан процесс, который называется «позитивным» тестированием.
«Позитивное » тестирование – это тестирование на данных илисценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению проверяемой системы. Основной целью «позитивного» тестирования является проверка того, можно ли припомощи системы делать то, для чего она создавалась.
«Негативное » тестирование – это тестирование на данных илисценариях, которые соответствуют нештатному поведению тестируемой системы, а также выдаче различных сообщений об ошибкахисключительным ситуациям, «запредельным» состояниям и т. п.
Основной целью «негативного» тестирования является проверкаустойчивости системы к воздействиям «негативного» рода: проверканеверного набора данных, проверка обработки исключительныхситуаций (как в реализации самих программных алгоритмов, так ив логике бизнес-правил) и т. п.
Предшествовать «позитивному» и «негативному» тестированиюдолжны работы по выполнению «дымового » тестирования , в ходекоторого осуществляется быстрое, неглубокое тестирование наиболеекритичной функциональности на простых, т. е. типичных сценарияхс минимумом проверок («чтобы только дыма не было»). Может выполняться как на «позитивных», так и «негативных» данных
Дайте определения функциональному, нагрузочному, стресс-тестированию и тестированию стабильности.
Функциональное тестирование заключается в тестировании системы в целях проверки реализуемости функциональных требований, т.е. способности программы в определенных условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает программа, и какие задачи она решает.
Нагрузочное тестирование. В общем случае производится моделирование ожидаемого использования приложения с помощью эмуляции работы нескольких пользователей одновременно. Подобное тестирование больше всего подходит для мультипользовательских систем и особенно использующих клиент-серверную архитектуру(например, Web-серверов).
Стресс-тестирование – вид тестирования ПО, которое оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для «критически важного» ПО. Стресс-тестирование обычно лучше обнаруживает такие качества, как устойчивость, доступность и способность к обработке исключений системой под большой нагрузкой, чем то, что считается признаком корректного поведения в нормальных условиях
Тестирование стабильности . Данный вид тестирования заключается в проверке работоспособности программы при длительнойработе с ожидаемым уровнем нагрузки. Перед тем как начать проверять работу системы при максимальных и критических нагрузкахнеобходимо проверить ее работу в тех условиях, которые заложеныв функциональных требованиях, т. е. запустить систему в штатномрежиме на длительное время. Основная задача такого тестированиясостоит в обнаружении утечек памяти, а также в проверке того, чтоскорость обработки данных и время отклика приложения была одинаковой в начале и конце теста.
Вопросы к теме 18
