В.В. Кулямин - Тестирование на основе моделей, страница 2

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

Пример такого свойства —отсутствие сбоев при работе программы. Если такие неявные требования действительнодолжны быть выполнены, можно проводить тестирование на их основе. Если же это не так,то есть иногда сбой может рассматриваться как корректное поведение системы (если,скажем, вводятся совсем некорректные исходные данные), то подобное тестирование можетпривести к неправильным выводам о наличии ошибок в системе.Чтобы требования к программному обеспечению можно было уверенно использовать приего разработке и тестировании, они должны обладать рядом характеристик, которыезафиксированы в стандартах, регламентирующих разработку программного обеспечения.Два таких стандарта — IEEE 830 [5] и IEEE 1233 [6] — определяют следующиехарактеристики правильно составленных требований к ПО.•Адекватность, соответствие реальным потребностям пользователей ПО.•Однозначность, отсутствие двусмысленностей и возможностей разного толкования.•Полнота — отражение в требованиях всех существенных потребностей и всех ситуаций,в которых система должна будет функционировать.•Непротиворечивость или согласованность между разными элементами требований.•Систематичность представления — требования должны быть описаны в рамкахнекоторой системы с четким указанием места каждого требования среди остальных, сопределением связей и зависимостей между ними и приоритетности для различныхзаинтересованных лиц.•Прослеживаемость — требования должны иметь четко определенные связи с модулямиразрабатываемой системы, частями проектной документации и тестами, чтобы всегдаможно было определить, для выполнения или проверки каких требований созданкаждый из этих элементов и насколько он им соответствует.•Проверяемость или возможность для каждого требования однозначно установить припомощи того или иного анализа системы, выполнено это требование или нет.•Модифицируемость или возможность внесения изменений в набор требований сбыстрым исправлением всех возникающих при этом дефектов с точки зрения другиххарактеристик.В ходе работы над создаваемой программной системой или переработки ужесуществующей всегда, в том или ином виде, проводится анализ требований, цель которого— подготовить представление требований к ПО, имеющее все указанные характеристики.Анализ требований обычно включает следующие виды деятельности.•Выделение требований.

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

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

Однако тестирование— не единственный такой метод. Что же отличает его от других методов контроля качества?Тестирование определяется как проверка соответствия поведения программной системытребованиям, выполняемая по результатам реальной работы этой системы в некоторомконечном наборе специально созданных ситуаций [7,8]. При этом проверяемая системаобычно называется тестируемой системой (system under test или SUT по-английски).В этом определении можно отметить следующие аспекты.•Проверка соответствия требованиям.Как уже указывалось, тестирование возможно лишь при наличии требований кпрограмме.

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

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

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