Лекции по дисциплине _Тестирование информационных систем_ (2). Лекции на специальности спо базовой подготовки 09. 02. 07 Информационные системы и программирование Ульяновск 2021
 Скачать 65.19 Kb.
|
|
Тема 3.4 Тестирование отдельных модулей Инструментарии анализа качества программных продуктов в среде разработки. Software Quality Assurance (SQA) — это комплекс мероприятий по обеспечению качества в процессах разработки программного обеспечения. Это гарантирует, что разработанное программное обеспечение соответствует и соответствует определенным или стандартизированным спецификациям качества. SQA — это непрерывный процесс в рамках жизненного цикла разработки программного обеспечения (SDLC), который регулярно проверяет разработанное программное обеспечение, чтобы убедиться, что оно соответствует требуемым показателям качества. Практики SQA применяются в большинстве типов разработки программного обеспечения независимо от используемой модели разработки программного обеспечения. SQA включает и внедряет методологии тестирования программного обеспечения для тестирования программного обеспечения. Вместо проверки качества после завершения, SQA обрабатывает тест на качество на каждом этапе разработки, пока программное обеспечение не будет завершено. С SQA процесс разработки программного обеспечения переходит в следующую фазу только тогда, когда текущая / предыдущая фаза соответствует требуемым стандартам качества. SQA обычно работает над одним или несколькими отраслевыми стандартами, которые помогают в разработке рекомендаций по качеству программного обеспечения и стратегий реализации. Включает в себя следующие виды деятельности: Определение и реализация процесса Аудиторская проверка Повышение квалификации Могут проводиться процессы: Методология разработки программного обеспечения Управление проектом Управление конфигурацией Разработка требований / Управление Предварительный расчет Разработка программного обеспечения Тестирование и др. После того, как процессы определены и внедрены, Контроль качества выполняет следующие обязанности: Выявить слабые места в процессах Исправить эти недостатки, чтобы постоянно улучшать процесс Выявление ошибок системных компонентов. Одной из основных причин изменений комплексов программ являются организационные дефекты при модификации и расширении функций ПС, которые отличаются от остальных типов и условно могут быть выделены как самостоятельные. Ошибки и дефекты данного типа появляются из-за недостаточного понимания коллективом специалистов технологии процесса ЖЦ ПС, а также вследствие отсутствия четкой его организации и поэтапного контроля качества продуктов и изменений. Изменения характеристик системы и внешней среды, принятые в процессе разработки ПС за исходные, могут быть результатом аналитических расчетов, моделирования или исследования аналогичных систем. В ряде случаев может отсутствовать полная адекватность предполагаемых и реальных характеристик, что является причиной сложных и трудно обнаруживаемых системных ошибок, и дефектов развития проекта. Ситуация с такими ошибками дополнительно усложняется тем, что эксперименты по проверке взаимодействия ПС с реальной внешней средой во всей области изменения параметров зачастую сложны и дороги, а в отдельных случаях, при создании опасных ситуаций, недопустимы. Сложность проявления, обнаружения и устранения ошибок значительно конкретизируется и становится измеримой, когда устанавливается связь этого понятия с конкретными ресурсами, необходимыми для решения соответствующей задачи, и возможными проявлениями дефектов. При разработке и сопровождении программ основным лимитирующим ресурсом обычно являются допустимые трудозатраты специалистов, а также ограничения на сроки разработки, параметры ЭВМ, технологию проектирования корректировок ПС. Показатели сложности при анализе можно разделить на две большие группы: сложность ошибок при создании корректировок компонентов и комплекса программ — статическая сложность, когда реализуются его требуемые функции, вносятся основные дефекты и ошибки; сложность проявления ошибок функционирования программ и получения результатов — динамическая сложность, когда проявляются дефекты и ошибки, отражающиеся на функциональном назначении, рисках и качестве применения версии ПС. Системные ошибки в ПС определяются, прежде всего, неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. Кроме того, эти процессы зачастую зависят от самих алгоритмов и поэтому не могут быть достаточно определены и описаны заранее без исследования изменений функционирования ПС во взаимодействии с внешней средой. На начальных этапах не всегда удается точно и полно сформулировать целевую задачу всей системы, а также целевые задачи основных групп программ, и эти задачи уточняются в процессе проектирования. В соответствии с этим уточняются и конкретизируются спецификации на отдельные компоненты и выявляются отклонения от уточненного задания, которые могут квалифицироваться как системные ошибки. Характеристики внешних объектов, принятые в качестве исходных данных в процессе разработки алгоритмов, могут являться результатом аналитических расчетов, моделирования или исследования аналогичных систем. Во всех случаях может отсутствовать полная адекватность условий получения предполагаемых и реальных характеристик внешней среды, что является причиной сложных и трудно обнаруживаемых ошибок. Это усугубляется тем, что очень часто невозможно заранее предусмотреть все разнообразие возможных внешних условий и реальных сценариев функционирования и применения версий программного продукта. При автономной и в начале комплексной отладки версий ПС относительная доля системных ошибок может быть невелика (около 10%), но она существенно возрастает (до 35—40%) на завершающих этапах комплексной отладки новых базовых версий ПС. Методы идентификации сбоев и ошибок Ошибка (error) - состояние программы, при котором выдаются неправильные результаты, причиной которых являются изъяны (flaw) в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, следовательно, и к неверному решению. Дефект (fault) в программе - следствие ошибок разработчика на любом из этапов разработки, которая может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. В процессе выполнения программы может быть обнаружен дефект или сбой. Отказ (failure) - это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования. Отказ может быть результатом следующих причин: ошибочная спецификация или пропущенное требование, означающее, что спецификация точно не отражает того, что предполагал пользователь; спецификация может содержать требование, которое невозможно выполнить на данной аппаратуре и программном обеспечении; проект программы может содержать ошибки (например, база данных спроектирована без средств защиты от несанкционированного доступа пользователя, а требуется защита); программа может быть неправильной, т.е. она выполняет несвойственный алгоритм или он реализован не полностью. Таким образом, отказы, как правило, являются результатами одной или более ошибок в программе, а также наличия разного рода дефектов. Все ошибки, которые возникают в программах, принято подразделять на следующие классы: логические и функциональные ошибки; ошибки вычислений и времени выполнения; ошибки ввода/вывода и манипулирования данными; ошибки интерфейсов; ошибки объема данных и др. Логические ошибки являются причиной нарушения логики алгоритма, внутренней несогласованности переменных и операторов, а также правил программирования. Функциональные ошибки - следствие неправильно определенных функций, нарушения порядка их применения или отсутствия полноты их реализации и т.д. Ошибки вычислений возникают по причине неточности исходных данных и реализованных формул, погрешностей методов, неправильного применения операций вычислений или операндов. Ошибки времени выполнения связаны с необеспечением требуемой скорости обработки запросов или времени восстановления программы. Ошибки ввода-вывода и манипулирования данными являются следствием некачественной подготовки данных для выполнения программы, сбоев при занесении их в базы данных или при выборке из нее. Ошибки интерфейса относятся к ошибкам взаимосвязи отдельных элементов друг с другом, что проявляется при передаче данных между ними, а также при взаимодействии со средой функционирования. Ошибки объема относятся к данным и являются следствием того, что реализованные методы доступа и размеры баз данных не удовлетворяют реальным объемам информации системы или интенсивности их обработки. Анализ типов ошибок в программах является необходимым условием создания планов тестирования и методов тестирования для обеспечения правильности ПО. Автоматизация тестирования в продуктивной среде Непрерывное тестирование ускоряет поставку программного обеспечения, делая весь процесс тестирования более быстрым. А благодаря незамедлительной обратной связи, которая помогает уже на самых ранних этапах выявлять ошибки и другие проблемы в приложении, гарантирует, что команды разработки будут создавать высококачественные и надежные приложения. Кроме того, сама способность организовать и проводить эффективное тестирование может значительно снизить затраты в компании, как за счёт экономии времени разработчиков, так и вследствие создания добротного конвейера поставки, в котором они могут быстро вносить изменения в код с минимальными рисками нарушения работоспособности приложения в продуктивной среде. Главным элементом непрерывного тестирования является его автоматизация, что даёт множество преимуществ: Быстрое получение обратной связи Аккуратное и тщательное тестирование Высокое покрытие тестами Быстрое обнаружение ошибок Повторное использование тестов Более короткие сроки поставки Адаптация для DevOps Экономия времени и денег Несмотря на перечисленные выше преимущества, начальные вложения в автоматизацию тестирования могут быть очень высоки. Приобретение ПО, затраты на обучение работе с ним, проектирование и создание автоматизированных тестов — всё это требует немалых времени и денег. Однако, как только вы начинаете всё активнее разрабатывать новые функции в своём продукте, ручное тестирование в конечном итоге выходит дороже, а автоматическое — дешевле. Перед планированием автоматизации тестирования нужно учесть несколько факторов. Вот примеры тестов и сценариев, для которых не нужна автоматизация. Пользовательский опыт (UX) - Эта область тестирования не может быть автоматизирована. Многие аспекты UX-проектирования требуют ручного, долгого и утомительного тестирования. Например, когда разработчики хотят понять, насколько легко пользователи могут зарегистрироваться на веб-сайте, или проверить, какие наборы полей дают лучшую видимость профилей пользователей. Подобные тесты должны быть проведены вручную. Стадии ранней разработки - Когда какая-то функция только-только разрабатывается, в её код постоянно вносятся изменения, а это может затруднить составление и теста. На ручное тестирование этих функций уходит меньше времени, поэтому следует дождаться стабильной версии. Функциональность, не имеющая большой важности - Автоматизация тестирования требует времени и усилий, поэтому следует автоматизировать тестирование не всех функций, разрабатываемых в рамках проекта, а лишь самых важных функций. Низкоприоритетные можно оставить в стороне и продолжить тестировать их вручную. Тесты без понятных результатов - Командам разработки необходимо знать ожидаемый результат для каждого входа функции. Если результаты непонятны, то и автоматизация не предоставит необходимых доказательств того, что функция работает должным образом. Тема 3.5 Реинжиниринг бизнес-процессов в информационных системах Сущность реинжиниринга бизнес-процессов. Этапы реинжиниринга Инжиниринг бизнеса — это набор приемов и методов, которые компания использует для проектирования бизнеса в соответствии со своими целями. Реинжиниринг — это фундаментальное переосмысление и радикальное перепроектирование деловых процессов для достижения резких, скачкообразных улучшений главных современных показателей деятельности компании, таких, как стоимость, качество, сервис и темпы (термин «реинжиниринг» ввел М. Хаммер). Это определение содержит четыре ключевых слова: «фундаментальный», «радикальный», «резкий (скачкообразный)» и «процесс» (наиболее важное слово). 1. Фундаментальный. На начальной стадии реинжиниринга необходимо ответить на такие основные вопросы: почему компания делает то, что она делает? почему компания делает это таким способом? какой хочет стать компания? Отвечая на эти вопросы, специалисты должны переосмыслить текущие правила и положения (зачастую не сформулированные в письменной форме) ведения бизнеса и часто оказывающиеся устаревшими, ошибочными или неуместными. 2. Радикальный. Радикальное перепроектирование — это изменение всей существующей системы, а не только поверхностные преобразования, т.е. входе радикального перепроектирования предлагаются совершенно новые способы выполнения работы. 3. Резкий (скачкообразный). Реинжиниринг не применяется в тех случаях, когда необходимо улучшение либо увеличение показателей деятельности компании на 10-100%, а используются более традиционные методы (от произнесения зажигательных речей перед сотрудниками до проведения программ повышения качества), применение которых не сопряжено со значительным риском. Реинжиниринг целесообразен только в тех случаях, когда требуется достичь резкого (скачкообразного) улучшения показателей деятельности компании (500-1000% и более) путем замены старых методов управлении новыми. Смысл реинжиниринга бизнес-процессов в двух его основных этапах: определение оптимального (идеального) вида бизнес-процесса (в первую очередь основного); определение наилучшего (по средствам, времени, ресурсам и т. п.) способа перевода существующего бизнес-процесса в оптимальный. Порядок проведения: Разработка корпоративной стратегии; Определение ключевых компетенций, которые необходимы для внедрения стратегии; Подробный анализ существующих процессов; Выявление процессов, требующих изменения; Определение ключевых показателей эффективности для бизнес-процессов; Собственно реинжиниринг; Контроль и постоянное совершенствование новых процессов на основе ключевых показателей эффективности. Изучение методологии структурного системного анализа Методология структурного анализа и проектирования ПО определяет шаги работы, которые должны быть выполнены, их последовательность, правила распределения и назначения операций и методов. В настоящее время успешно используются такие методологии, как SADT (Structure Analysis and Design Technique), структурный системный анализ Гейна-Сарсона, структурный анализ и проектирование Йодана/Де Марко, развитие систем Джексона и другие. Перечисленные структурные методологии жестко регламентируют фазы анализа требований и проектирования спецификаций и отражают подход к разработке ПО с позиций рецептов "кулинарной книги". Несмотря на достаточно широкий спектр используемых методов и диаграммных техник, большинство методологий базируется на следующей "классической" совокупности: Диаграммы потоков данных в нотации Йодана/Де Марко или Гейна-Сарсона, обеспечивающие анализ требований и функциональное проектирование информационных систем; Расширения Хатли и Уорда-Меллора для проектирования систем реального времени, основанные на диаграммах переходов состояний, таблицах решений, картах и схемах потоков управления; Диаграммы "сущность-связь" (в нотации Чена или Баркера) для проектирования структур данных, схем БД, форматов файлов как части всего проекта; Структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры модулей. Разработка ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данных раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными – структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Основные методологии обследования организаций Понятие "моделирование бизнес-процессов" пришло в быт большинства аналитиков одновременно с появлением на рынке сложных программных продуктов, предназначенных для комплексной автоматизации управления предприятием. Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании. Для решения подобных задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными. В настоящий момент к семейству IDEF можно отнести следующие стандарты: IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы; IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе; IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе “раскрашенных сетей Петри” (CPN – Color Petri Nets); IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3; IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы; IDEF5 – методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация. |