Недостатки тестирования ПО

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

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

Принцип “тестируй как можно раньше и как можно чаще” большинством компаний, к сожалению, не соблюдается. Обычно тестирование откладывается до последней минуты, говорит Джефф Финдли, старший архитектор решений для Азиатско-Тихоокеанского региона и Японии в фирме Micro Focus. Разработчики стремятся отсрочить тестирование важнейших функций и транзакций вплоть до самого выпуска продукта.

Рей Ванг, главный аналитик и генеральный директор фирмы Constellation Research, добавляет, что даже если компании признают важность подготовки высококачественного ПО, то скорее в соответствии с принципом “быстрее, лучше, дешевле”. Это ограничивает вероятность отказа программ, но одновременно и возможности предвидения неожиданных трудностей, которые могут возникнуть в реальной жизни, и готовности к ним.

“Тестирование из искусства превратилось в науку”, — считает Ванг. Немногие компании сейчас достигают этого уровня в процессе интегрированной гибкой разработки. Они составляют планы тестирования параллельно с функциональными спецификациями. При этом больше времени уходит на планирование, зато остается меньше ошибок, сказал аналитик.

“Если вы пересчитали все деревья, это не значит, что вы видели лес”, — сказал Рамешвар Вьяс, генеральный директор компании Ranosys Technologies, предоставляющей услуги по тестированию ПО. Компаниям всегда следует помнить об этом при подготовке тестовых программ, считает он. Управление изменениями и рисками являются составными частями общего плана, который должен включать тестирование на предмет всего того, что ПО не должно делать.

Финдли подчеркивает, что всё тестируемое компаниями ПО должно соответствовать требованиям бизнеса. Эти требования следует четко сформулировать, согласовать с акционерами и хранить в центральном репозитарии. Зачастую составляются многочисленные документы, в которых многократно и различным образом описываются предъявляемые требования. В результате появляется множество интерпретаций, что в свою очередь ведет к сбоям в работе приложения и к его дорогостоящей переделке, поясняет он.

Эти комментарии были высказаны после 1 августа, когда американская трейдерская компания Knight Capital Group потеряла 440 млн. долл. из-за того, что небрежно обновленное ПО отдало несколько ошибочных распоряжений на Нью-Йоркской фондовой бирже. Ей пришлось выпутываться с помощью финансового спасательного круга. Всего неделю спустя в Азии произошел сбой системы резервного копирования на Токийской фондовой бирже. В результате торговля дериватами была приостановлена на 95 минут.

Достаточно — это сколько?

Как компаниям оценить, какой объем и продолжительность тестирования ПО позволит избежать подобных инцидентов? Это зависит от того, как они определяют риски, связанные с выполнением конкретных функций приложения, считает Финдли.

Важно понять влияние сбоя на бизнес, а затем двигаться в обратном направлении, тестируя каждый элемент как можно раньше, причём тесты должны соответствовать требованиям бизнеса, для проверки которых они проводятся, поясняет руководитель компании Micro Focus.

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

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

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

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

Тестирование - способ обеспечения качества. Недостаточно выполнить проектирование и кодирование ПО, необходимо также обеспечить его соответствие требованиям и спецификациям.

С технической точки зрения тестирование заключается в выполнении ПО на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик ПО заказанным свойствам.

ыполнерия Многократно проводимые исследования показали, что чем раньше обнаруживаются те или иные несоответствия или ошибки, тем больше вероятность их правильного исправления (рис. 9.1, а) и ниже его стоимость (рис. 9.1, б).

Если стоимость обнаружения и устранения ошибок кодирования принять за единицу, то стоимость выявления и исправления на следующих этапах ЖЦ ПО можно представить следующим образом

Оценка стоимости ошибок на разных этапах создания ПО

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

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

В зависимости от того, где и когда при работе над проектом разработки ПО был обнаружен дефект, цена его может разниться в 50-100 раз. Причина состоит в том, что для его исправления придется затратить средства на некоторые (или все) нижеперечисленные действия.

1. Повторная спецификация.

2. Повторное проектирование.

3. Повторное кодирование

4. Повторное тестирование

5. Замена заказа – сообщить клиентам и операторам в необходимости заменить дефектную версию исправленной

6. Внесение исправлений – выявить и устранить все неточности, вызванные неправильным функционированием ошибочно специфицированной системы, что может потребовать выплаты определенных сумм возмущенным клиентам, повторнрго выполнения определенных вычислительных задач на ЭВМ и т.д.

7. Списание той части работы (кода, части проектов и т.п.), которая выполнялась с наилучшими побуждениями, но оказалось ненужной, когда обнаружилось, что все это создавалось на основе неверных требований.

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

9. Выплаты по гарантийным обязательствам.

10. Ответсвенность за изделие, если клиент через суд требует возмещения убытка, причиненного некачественным ПП.

11. Затраты на обслуживание - представитель компании должен посетить клиента, чтобы установить новую версию ПО.

12. Создание документации.

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

На начальных этапах такой контроль осуществляют в основном вручную или с использованием CASE-средств, на последних - он принимает форму тестирования.

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

Тестирование - процесс выполнения программы с намерением (или целью) найти ошибки.

Доказательство (proof) — попытка найти ошибки в програм­ме безотносительно к внешней для программы среде.

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

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

Аттестация (certification) — авторитетное подтверждение правильности программы. При тестировании с целью аттеста­ции выполняется сравнение с некоторым заранее определенным стандартом.

Отладка (debugging) направлена на установление точной при­роды известной ошибки, а затем - на исправление этой ошибки. Эти два вида деятельности связаны – результаты тестирования являются исходными данными для отладки.

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

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

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

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

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

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

Примечание. Обычно на вопрос о цели тестирования начинающие программисты отвечают, что целью тестирования является «доказательство правильности программы». Это абсолютно неверное мнение. Г. Майерс [47] предлагает очень удачную аналогию для пояснения этого положения.

Представьте себе, что вы пришли на прием к врачу и пожаловались на боль в боку. Врач выслушал вас и направил на обследование. Через некоторое время вы возвращаетесь к врачу с ворохом заключений и результатов анализов, и во всех этих бумагах написано, что все исследуемые параметры у вас в норме. Но бок то болит, значит, что-то не в порядке, хотя анализы этого и не показывают... Так и сложное программное обеспечение, безошибочно работающее на всех тестовых наборах, может содержать и обычно содержит некоторое количество ошибок.

Процесс разработки современного программного обеспечения предполагает три стадии тестирования:

• автономное тестирование компонентов программного обеспечения (модульное тестирование);

• комплексное тестирование разрабатываемого программного обеспечения (интеграционное тестирование);

• системное или оценочное тестирование на соответствие основным критериям качества и исходным требованиям.

Различают уровни тестирования:

- альфа-тестирование – имитация реальной работы с системой штатными разработчиками либо реальная работа с системой потенциальными пользователями/заказчиком на стороне разработчика.

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

Для повышения качества тестирования рекомендуется соблюдать следующие основные принципы:

• предполагаемые результаты должны быть известны до тестирования;

• следует избегать тестирования программы автором;

• необходимо досконально изучать результаты каждого теста;

• необходимо проверять действия программы на неверных данных;

• необходимо проверять программу на неожиданные побочные эффекты

на неверных данных.

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

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

Ключевой вопрос – полнота тестирования: какое количество каких тестов гарантирует, возможно, более полную проверку программы?

Пример. Программа, вычисляющая функцию двух переменных Y=F(X, Z). Если тип X, Y, Z real, то полное число тестов

Если на каждый тест тратить 1мс, то мс = 800 млн. лет.

А чего не может тестирование?

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

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

Тестирование – технико-экономическая проблема, основанная на компромиссе время – полнота. Поэтому нужно стремиться к возможно меньшему количеству хороших тестов с желательными свойствами.

Формирование тестовых наборов. В соответствии с определением тестирования удачным следует считать тест, который обнаруживает хотя бы одну ошибку.