Лекции. Тестирование ПО (all in one) (Лекции), страница 2

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

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

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

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

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

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

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

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

В англоязычной литературе в этомсмысле чаще всего употребляется термин defect.•Часто ошибкой или сбоем называют наблюдаемое нарушение требований,проявляющееся при некотором сценарии работы рассматриваемой системы. Ванглийском языке этому значению соответствует термин failure.•Ошибка в коде программы, вызывающая сбой, и состоящая в неправильномиспользовании какой-то конструкции языка программирования, употреблении лишнейконструкции или в пропуске необходимой.

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