Способы обеспечения качества программных продуктов

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

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

     Тестирование  оказывается довольно необычным  процессом (вот почему оно и считается  трудным), так как этот процесс  разрушительный. Ведь цель проверяющего (тестовика) — заставить программу  сбиться. Он доволен, если это ему  удается; если же программа на его тесте не сбивается, он не удовлетворен.

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

     Тестирование (testing), как мы уже выяснили,—процесс выполнения программы (или части  программы) с намерением (или целью) найти ошибки.

     Доказательство (proof) — попытка найти ошибки в  программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Многие исследователи считают доказательство альтернативой тестированию — взгляд во многом ошибочный; более подробно это обсуждается в гл. 17.

     Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

     Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде.

     Аттестация (certification) — авторитетное подтверждение  правильности программы, аналогичное  аттестации электротехнического оборудования Underwriters Laboratories. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

     Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование — деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.

     Тестирование  модуля, или автономное тестирование (module testing, unit testing) — контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает также математическое доказательство.

     Тестирование  сопряжении (integration testing) — контроль сопряжении между частями системы (модулями, компонентами, подсистемами).

     Тестирование внешних функций (external function testing) — контроль внешнего поведения системы, определенного внешними спецификациями.

     Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

     Тестирование  приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.

     Тестирование  настройки (installation testing) — проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки

     Бета - тестирование программного обеспечения.

     Другой  способ проверки - бета-тестирование. В этом случае разработчики программного обеспечения разрешают пользователям попробовать предварительные версии продуктов. Однако большинство разработчиков, с утверждают, что внешние бета-тестеры не выявляют такого большого количества ошибок.

     Выводы.

     Быстрое увеличение сложности и размеров современных комплексов программ при  одновременном повышении ответственности  выполняемых функций резко повысило требования со стороны пользователей  к их качеству, надежности функционирования и безопасности применения. Для каждого проекта ПС, выполняющего ответственные функции, должны разрабатываться и применяться система качества, специальные планы и программа, методология и инструментальные средства, обеспечивающие требуемые качество, надежность и безопасность функционирования. Для удовлетворения высоких требований к функционированию необходимы выделение из ЖЦ ПС задач и работ по обеспечению качества программ, а также обучение и концентрация усилий разработчиков на анализе и обосновании рентабельности выбранной методологии и методов разработки комплексов программ.

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

     Только  скоординированное, комплексное применение в проектах ПС с начала проектирования современных методов и стандартов позволяет достигать высокого качества, необходимого для использования  ПС в распределенных критических  и сложных системах обработки информации. Необходимо убедить руководителей проектов, заказчиков и разработчиков в том, что тщательно регламентированное и достаточно полное системное проектирование ПС и БД на основе современных методов и международных стандартов выгодно с позиции сокращения ошибок и повышения качества сложных комплексов программ.