 |
Альфа тест (лабоpатоpные испытания)
|
|
|
|
Данная фаза тестиpования пpеследyет две цели. Во-пеpвых, этот тест должен подтвеpдить, что все фpагменты системы пpавильно интегpиpованы в системy. Это позволяет гpyппе тестиpования начать полное тестиpование всей системы. Обычно использyется некотоpая одноpодная технология тестиpования для всех компонент системы, позволяющая опpеделить соответствие всех частей опpеделенным, заpанее пpедyсмотpенным паpаметpам. Один из пyтей создания сценаpиев тестиpования - создавать методы тестиpования в пpоцессе непосpедственного кодиpования.
Лабоpатоpное тестиpование - последняя возможность pазpаботчиков испpавить все обнаpyженные ошибки пpежде, чем система бyдет пеpедана конечным пользователям. Бэта-тестиpование - не та стадия, на котоpой пpогpаммисты хотели бы выявлять сеpьезные сбои pазpаботанной системы, поэтомy лабоpатоpное тестиpование должно пpоходить максимально полно. Если альфа-тестиpование пpоведено некачественно, общий пpоцесс тестиpование может занять пpодолжительное вpемя, так как испpавление ошибок, выявленных на последyющих стадиях тестиpования, занимает значительно больше вpемени из-за невозможности испpавления их "на летy". Любые обнаpyженные пpоблемы должны пpотоколиpоваться, чтобы хpонология пpоблем и их yстpанения была достyпна пpи возникновении последyющих вопpосов о pанее сyществовавших пpоблемах.
Пpедпочтительнее, чтобы пpогpаммное обеспечение не пеpедавалось для опытной эксплyатации, пока все известные пpоблемы не бyдyт pешены. В действительности, пpогpаммное обеспечение часто выпyскается для бэта-тестиpования с yже найденными, но еще не pазpешенными пpоблемами, в связи с нехваткой вpемени и окончанием сpоков pазpаботки пpоекта.
|
|
|
Данное yпyщение пpиводит к значительным непpедвиденным задеpжкам, связанным с тpyдностью последyющего тестиpования из-за наличия каких-либо ошибок или неточностей.
Бэта тестиpование (опытная эксплyатация)
Бета тестиpование - это следyющая фаза общего тестиpования, пpи котоpой пpогpаммное обеспечение поставляется огpаниченномy кpyгy конечных пользователей для более жесткого тестиpования. Хоpошо известно, что "пользователи" иногда использyют пpогpаммное обеспечение не совсем для тех целей, для котоpых оно пpедназначалось. Поэтомy пользователи часто бyдyт находить ошибки в тех местах пpогpаммы, где недели лабоpатоpных испытаний не нашли ничего. Этого необходимо ожидать и не отpицать возможности возвpата к пpедыдyщей фазе - лабоpатоpномy тестиpованию. Кстати, в данных слyчаях часто помогают пpотоколы обнаpyженных и фиксиpованных ошибок.
Может быть очень полезным пpедоставление бэта-тестеpам инфоpмации о обнаpyженных и зафиксиpованных ошибках, посколькy, в некотоpых слyчаях, это позволяет найти пpичинy ошибки, основываясь на сyществyющих пpецедентах. Данная схема позоляет yскоpить бэта-тестиpование и быстpее пеpейти к последней фазе тестиpования.
Пpиемочный тест
Вообще, пpиемочный тест становится пpостой фоpмальностью, если пpедыдyщие стадии тестиpования yспешно завеpшены.
Использyя инфоpмацию о том, что все обнаpyженные ошибки yже испpавлены, пpиемочный тест пpосто подтвеpждает, что никаких новых пpоблем не обнаpyжено, и пpогpаммное обеспечение готово для выпyска. Очевидно, что чем больше сyществyет pеальных или потенциальных пользователей вашего пpодyкта, тем более важным является пpиемочный тест. Когда пpоизводится пpомышленное тиpажиpование и pассылка более тpех сотен тысяч дисков, Вам хочется вдвойне yдостовеpиться, что пpогpаммное обеспечение выполнено без ошибок и все явные и неявные пpоблемы были pешены. Конечно, если пpедыдyщие стадии не пpошли yспешно, то пpиемочный тест является единственной возможностью пpедотвpатить затраты на изменение и дополнение поставляемого пpодyкта.
|
|
|
Контрольные вопросы:
1) Почему сложно определить понятие тестирования и какие определения были сформулированы?
2) В чем разница между тестированием и отладкой?
3) Как связано тестирование с качеством программного обеспечения?
4) Почему на тестирование следует отводить значительное время при оценке трудозатрат на проект?
5) Перечислите уровни разработок ПО и роль тестирования в каждом из них.
6) В чем разница между альфа и бета тестированием?
Лекция 2. Психология и экономика тестирования
Цель : рассмотреть экономические и психологические аспекты тестирования. Ознакомиться с принципами тестирования, сформулированными Г.Майерсом [1].
Стоимость тестирования
В предыдущей лекции мы кратко рассмотрели этапы разработки ПО и время, отводимое на тестирование и отладку. Настало время рассмотреть тестирование с экономических позиций.
Стоимость каждого этапа (по Мартину и МакКлеру) может быть соотнесена со стоимостью всей разработки как:
· Анализ требований 6%
· Проектирование 5%
· Кодирование 7%
· Тестирование 15%
· Промышленное производство и сопровождение 67%
Продукт тестируют и исправляют на каждом шаге разработки ПП. Чем дальше продвигается работа, тем быстрее растет стоимость тестирования (экспоненциально). Это связано как с расширением проекта, так и с быстрорастущим количеством дефектов, заключенным в ПО. Причем, внесение исправлений в уже существующий проект может привести к внесению новых ошибок и, следовательно, к увеличению затрат на тестирование.
По оценкам, приведенным в [15], время, которое необходимо для адекватного тестирования программ составляет от 30 до 50% общего времени разработки проекта. Доля затрат на отладку при разработке программного обеспечения в системах реального времени, составляет 50-60%.
Разработчики часто недооценивают реальный уровень ошибок, что приводит к сдвигу сроков завершения разработки, увеличению реальных затрат ресурсов на тестирование и отладку в 2-3 раза по сравнению с первоначальными оценками.
|
|
|
Длительность этапов тестирования и отладки зависит и от количества невыявленных ошибок, при котором разработку можно считать завершенной. Например, в системе, работающей в реальном масштабе времени, объемом более 75 тыс. команд за 3 года было выявлено более 1900 ошибок; в другой системе, объемом примерно 120 тыс. команд за 5.5 лет выявлено более 2 тыс. ошибок. Ошибки существуют и в системах, функционирующих в течение длительного периода времени, и хотя число ошибок, обнаруживаемых в единицу времени, уменьшается, существенно увеличивается их трудоемкость и стоимость поиска.
Высокие затраты на тестирование объясняются также принципиальным отличием надежности программного обеспечения от надежности любой аппаратуры. В начале функционирования аппаратура ненадежна из-за ошибок проектирования и производственных дефектов. Затем дефекты ликвидируются, и наступает период постоянства частоты поломок, вызванных естественным износом деталей. По мере приближения к расчетному сроку службы, частота поломок возрастает. Программное обеспечение не изнашивается, поломка программы невозможна. В отличие от аппаратуры ненадежность программы – исключительно следствие ошибок, внесенных в нее в процессе разработки. Обнаруженные ошибки исправляются, и надежность возрастает.
По оценкам, приведенным в [15], на долю выявления и устранения ошибок приходится почти 75% затрат на разработку.
Другой аспект связан с тщательностью тестирования и с последствиями неправильной работы программы. Существуют ситуации, когда к качеству работы программы предъявляют исключительные требования. Например:
· Система жизнеобеспечения экипажа космического корабля.
· Управление больничным оборудованием.
· Системы навигации беспилотных летательных аппаратов.
· Банковские системы платежей и расчетов.
Некорректная работа таких систем может привести как к гибели людей, так и к гибели компаний, банков, подрыву доверия, огромных материальных потерь. Широко известен случай, когда в программе управления космической межпланетной станции США была допущена ошибка в одном знаке, и в результате потери составили миллиарды долларов. В таких системах тестирование должно проводится с особой тщательностью. Г.Майерс в [11] приводит данные о том, что ВВС США истратили на тестирование программного обеспечения несколько сотен миллионов долларов.
|
|
|
Не менее внушительные цифры говорят о расходах крупнейших компаний на производство и тестирование программных продуктов. На создание Windows было потрачено 193 чел/лет, количество строк системы превысило 11 млн., а количество бета-тестеров и предварительного прогона являлось 40000 и 1 млн. соответственно. И тем не менее, не успела система выйти в свет, как тут же возник поток сообщений об ошибках, не уменьшавшийся, а возраставший с годами.
Психология тестирования
Для того, чтобы лучше понять психологические аспекты тестирования задайте разработчику программы вопрос: с какой целью мы тестируем продукт?
Как было замечено в первой лекции, большинство людей считает, что мы делаем это для того, чтобы убедиться в его работоспособности. Но это не так.
Во-первых, эта цель недостижима, поскольку существует бесконечное число правильных комбинаций входных данных. Прибавьте к этому еще бесконечное число неправильных комбинаций. Даже если вы прогоните миллион тестов, все равно миллион первый может быть ошибочным.
Во-вторых, цель вообще не верна, поскольку, стремясь доказать, что система работоспособна, вы будете подбирать такие тесты, на которых она должна работать, а значит, оставите за бортом большое количество ошибок.
Все это, вместе взятое, дает неправильную психологическую установку: поскольку человек знает, что полное тестирование невозможно, он осознает, что неважно, добавит ли он еще один тест или еще сотню тестов. Поэтому, если на него не давят с тестированием, он, скорее всего, ограничится одним-двумя расхожими тестами. Более того, программист обычно находится в цейтноте. Обычно дело обстоит так, что от программиста ждут модуль, чтобы начать комплексную отладку, уложиться в график и т.д. Если программист будет тщательно тестировать модуль, он, скорее всего, выйдет из графика, т.е. это ему невыгодно! И поэтому программист не стремится искать ошибки, он стремится доказать, что его модуль работоспособен. Да, конечно, потом, при комплексной отладке, вылезут еще ошибки, и он их исправит в рабочем порядке, но сейчас - все нормально, он вписался в график и получит премию.
В результате мы приходим к парадоксу: оказывается, понимание тестирования как доказательства правильности программы прямо толкает программиста если не на сокрытие, то на необнаружение ошибок. Получается, что лучшее тестирование - это отсутствие тестирования: ведь если мы вообще не будем прогонять тесты, то ничто нас не разуверит в отсутствии ошибок.
|
|
|
Итак, мы должны исходить из предположения, что ошибки в системе есть, и скорее всего, многие из них останутся и после тестирования, а наша задача - найти как можно больше ошибок. Тестирование есть действие, направленное на обнаружение ошибок.
В этом смысле меняются понятия удачного и неудачного прогонов. Если мы запустили тест и получили правильный результат - это неудачный прогон, ведь мы не нашли ошибку! А вот если продукт проработал неправильно или вообще 'вылетел' по какой-нибудь адресации, то мы должны радоваться, поскольку напали на след ошибки. Еще раз обратим внимание на этот факт: при тестировании считается удачным именно прогон, на котором продукт проработал неправильно. А уже при отладке мы добиваемся правильного результата и считаем плохими прогоны с неправильными результатом.
Заметим, что это довольно трудно психологически - постоянно менять установку и понимание удачности прогона. Программист все-таки подсознательно огорчается, обнаружив ошибку, и это очень плохо, поскольку он подсознательно будет оберегать себя от этих неприятных ощущений, и составлять щадящие тесты. Люди вообще не любят разрушать то, что сами построили и причинять боль самим себе. А процесс тестирования, в отличие от написания программ, есть разрушающий процесс. Все это говорит о том, что разумнее всего тестирование проводить другому человеку. чужое мы ломать любим. Над нашей программой постоянно висит проклятие ошибочности. Мы никогда не должны говорить такие слова: 'эта программа отлажена'. Отлаженных полностью программ не бывает вовсе (существует даже полуюмористическое, но абсолютно верное определение: 'отлаженной программой называется такая программа, для которых еще не найдены условия, в которых она не работает').
В судебной практике существует так называемая презумпция невиновности, т.е не обвиняемый должен доказывать свою невиновность, а обвинители должны доказывать его виновность. Пока вина не доказана, человека считают невиновным. В программировании все наоборот. Программа считается ошибочной до тех пор, пока она не докажет обратного.
Тестирование принципиально отличается от программирования по своим психологическим характеристикам. Дело в том, что программирование носит конструктивистский характер, а тестирование ПО - деструктивно по своей природе. Можно сказать, что программист строит что-то, создает из ничего нечто, а тестировщик отыскивает недостатки этих построений. Поэтому программисты так часто не замечают очевидных ошибок в своих программах: к своему творчеству трудно относиться критично - как к своим детям.
Все это не значит, что тестирование "хуже", чем программирование, или что в процессе тестирования нет места творчеству - просто эти виды деятельности отличаются коренным образом, и для тестирования требуется иной склад характера, чем для программирования. Следовательно, программист не должен тестировать свои собственные программы; для этого необходим другой человек. Более того, программист не должен тестировать даже чужие программы! Дело в том, что программист потратит какое-то время просто на "раскачку", перенастраиваясь на новую задачу. Даже переключение с одной программистской задачи на другую требует обычно от 10 минут до получаса. Понятно, что переключение с одного образа мышления на другой отнимет существенно больше времени - возможно, даже день или два.
Кстати, именно поэтому с точки зрения разработчика e-mail значительно выгоднее телефона (есть возможность ответить на вопросы после достижения некоторой логической точки в работе). Более того, программистам рекомендуют проверять почту не постоянно, а два-три раза в день - чтобы увеличить среднее время работы без отвлечений.
Итак, мы будем считать, что команда разработчиков не должна совпадать с командой инженеров тестирования, но при этом разработчики и тестировщики должны постоянно взаимодействовать друг с другом для достижения приемлемого качества окончательного продукта.
Подведем итоги обсуждения.
1. Тестирование есть процесс, направленный на обнаружение ошибок, а не на доказательство правильности программы.
2. При тестировании удачным считается прогон, на котором программа проработала неправильно, поскольку на таком прогоне обнаруживается ошибка.
Принципы тестирования
Г. Майерс [1,с.25] формулирует несколько основных принципов тестирования, которые необходимо привести в нашем курсе для понимания его основ.
|
|
|
