Учебное пособие санктПетербург 2015
 Скачать 3.34 Mb.
|
|
СИСТЕМНОЕ (ИЛИ ЭНД-ТУ-ЭНД) ТЕСТИРОВАНИЕ (system or end-to-end testing) Системное тестирование подразумевает полную и доскональную проверка всей системы от начала до конца. Является самым масштабным и трудоёмким, требуем боль- шого количества ресурсов, но может быть автоматизирова- но при помощи инструментов автоматического тестирова- ния и непрерывной интеграции (continuous integration). 143 Тестирования программного обеспечения РУЧНОЕ ТЕСТИРОВАНИЕ (manual testing) Представляет последовательное исполнение тест- кейсов без помощи каких-либо программ, автоматизи- рующих работу. Является наиболее затратным по вре- мени, зависимым от компетенции тестировщика и ме- ханически монотонным. АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ (automated testing) Это отдельная дисциплина тестирования, значи- тельная часть эффективности работы в рамках которой зависит от того, какие задачи отданы для автоматизации и как эта автоматизация была осуществлена. Автомати- зация может как принести огромное облегчение всем тестировщикам, так и завалить работу всего отдела и отложить релиз. В данном методе тестирования приме- няются специализированные системы автоматизации и непрерывной интеграции. ТЕСТИРОВАНИЕ ПО ТЕСТ-КЕЙСАМ (documented testing) На первых стадиях разработки тестов покрыва- ющих разрабатываемую систему происходит создание тест-кейсов, которые представляют собой сценарии работы системы и ожидания от результатов этой рабо- ты (появление окна, выведение результата, появление сообщения и т.д.). Является одним из самым простых методов тестирования, не предъявляющих особых тре- бований к квалификации тестировщика. 144 Методы оценки и измерения характеристик информационных систем ИНТУИТИВНОЕ ТЕСТИРОВАНИЕ (ad hoc testing) В данном методе поиск ошибок и некорректностей в процессе работы системы производится на интуитив- ной основе, без применения конкретных методологий. 6.5 Основные инструменты процесса тестирования 6.5.1 Система управления требованиями Исходя из приведённого обзора подхода к управ- лению требованиями, необходимо заметить, что для максимально эффективной работы с ними невозмож- но обойтись без использования какого-либо средства автоматизации основных процессов. Существуют различные системы, каждая из которых имеет свои достоинства и недостатки. Выбор подобного про- граммного обеспечения необходимо осуществлять на основании потребностей в рамках конкретного про- екта. Это связано с его масштабами, сложностью и сроками реализации. Масштаб напрямую влияет на общее количество требований к системе и её компо- нентам. Сложность привносит дополнительные тре- бования, предусмотреть которые не первых этапах разработки было невозможно. Это связано, к примеру, с архитектурными особенностями реализации, влия- ющими на некоторые компоненты системы. К таким особенностям можно отнести платформу разработки, например, JAVA или .NET Framework. В зависимости от выбранного программного фреймворка реализа- ция системы будет зависеть от имеющихся библио- тек, наборов дополнительных плагинов, особеннос- тей языка программирования и т.д. В таких условиях реализация одинакового функционала на различных 145 Тестирования программного обеспечения платформах разработки будет состоять из различ- ного количества требований. В свою очередь, сроки реализации накладывают ограничения на оператив- ность принятия решений, как управленческих, так и производственных. Если требуется быстро принять какое-либо решение, а информации для этого недо- статочно, в силу необходимости её консолидации из различных источников, сроки его принятия велики, что негативным образом сказывается на общем про- цессе реализации. Необходимо отметить, что при использовании систем управления требованиями можно добиться на- глядности существующей модели требований, одна- ко визуализация преимущественно происходит в виде иерархической структуры, что затрудняет поиск конк- ретного элемента в этой модели. Несмотря на это, по- добные системы значительно упрощают трассировку требований, так как позволяют наглядно отображать изменения в требованиях, а также их распространение на связанные зависимые требования. Среди систем подобного рода можно выделить: 1. 3SL Cradle. 2. IBM Rational DOORS. 3. Borland Caliber. 4. Devprom Requirements. 5. codeBeamer Requirements Management. 6. Cognition Cockpit. 7. in-STEP BLUE. 8. inteGREAT. 9. Jama. 10. Kovair ALM Studio. 11. Polarion REQUIREMENTS. 12. TestTrack. 13. Visure Requirements. 146 Методы оценки и измерения характеристик информационных систем Следует отметить, что, несмотря на большой вы- бор, общий функционал систем по работе с требовани- ями примерно идентичен, различия касаются возмож- ностей интеграции с другими сторонними системами или наличии функционала подобных систем в самом указанном продукте. 6.5.2 База знаний Процесс разработки любой системы сопровож- дается созданием большого количества информации: диаграммами, схемами, описаниями, визуальными мо- делями, чертежами, макетами и т.д. Учитывая распре- деление обязанностей по созданию данных результатов разработки, бывает непросто быстро получить доступ к необходимым сведениям. В таких ситуациях весьма удобным решением является создание общей базы зна- ний, в которой все работники могут находить требуе- мые сведения. Важным моментом, при создании дан- ного информационного агрегатора, является разработка структурированного рубрикатора, использование ко- торого в значительной степени будет влиять на общий эффект применений базы знаний. Связано это с быстро- той и удобством поиска информации, причём различия в идиосинкратически модальном поведении пользова- телей значительно усложняют его создание. Грамотно спроектированная база знаний позво- лит значительно сократить время поиска информации, что, в свою очередь, сократит время принятия решений в процессе разработки. Кроме этого, база знаний может стать хранилищем требований для проектов компании, благодаря чему упростится процесс их повторного ис- пользования. Проще говоря, любая рабочая информа- ция, которая подлежит дальнейшему использованию, может храниться в базе знаний. 147 Тестирования программного обеспечения Существуют следующие популярные средства ре- ализации базы знаний: 1. Wiki. 2. Atlassian Confluence. 3. eXo Platform. 4. Helpjuice. 5. Comintelli’s Knowledge Management System. 6. Spiceworks’ Knowledge Base. 7. Moxie Knowledgebase. 8. Zendesk. 9. Freshdesk. 10. Safeharbor Knowledge Solutions. 11. Knowledgeowl. Необходимо отметить, что реализация базы зна- ний возможна при помощи множества других инстру- ментов, как специальных, так и обще профильных. К примеру, можно создать сетевые ресурсы, сгруппиро- ванные определённым образом, и располагать в них требуемую информацию. При этом существует воз- можность управлять правами доступа пользователей к различным каталогам и файлам, однако поиск и управ- ление такой базой будет неудобным. 6.5.3 Система управления задачами Процесс разработки информационной систе- мы требует консолидации усилий большого числа людей. Каждый из них занимает определённую по- зицию в иерархии управления, что подразумевает необходимость распределения обязанностей и кон- троль над процессом их выполнения. Современные системы управления задачами позволяют не только фиксировать начальный и конечный этапы работы над конкретным поручением, но также предостав- ляют возможности по указанию дополнительных 148 Методы оценки и измерения характеристик информационных систем сведений, требуемых при его исполнений, деком- позировать поставленную задачу на подзадачи, ус- танавливать дополнительных наблюдателей и со- исполнителей. Использование таких систем позво- ляет значительно упростить процесс контроля над деятельностью персонала, формировать перечни выполненных задач для анализа эффективности ра- боты, которые можно использовать в системе моти- вации. Наиболее продвинутые системы также поз- воляют вести учёт времени выполнения задач. Подобные системы обычно являются составной часть более крупных информационных продуктов, пос- кольку призваны контролировать выполнения задач конкретной предметной области. Примерами могут яв- ляться системы: 1. Bitrix24. 2. eXo Platform. 3. Wrike. 4. Asana. 5. JIRA Atlassian. 6. Trello. 7. Basecamp. 8. TAIGA. 9. Producteev. 10. Freedcamp. 6.5.4 Система управления дефектами Любая информационная система для конечного пользователя представляется в виде окна программного обеспечения, в котором он работает. Отношение поль- зователя к информационной системе в целом чаще все- го складывается из опыта работы с её программной час- тью. Если программная реализация системы содержит ошибки, работает нестабильно, требует большого коли- 149 Тестирования программного обеспечения чества усилий для освоения, её качество для пользова- теля, при всей сложности и обширности архитектурной составляющей, будет низким. Чтобы этого не произош- ло, разработчикам приходится проводить сложные и дорогостоящие процедуры по улучшению качества. К ним относится процесс выявления дефектов (bug). Правильная организация этого процесса затрагивает множество участников. Выявление дефекта и его докумен- тирование происходит на этапе тестирования. Далее про- исходит передача информации о дефекте разработчикам, причём это может быть сделано по средствам базы знаний или специальной системы управления дефектами. Имея запись о соответствующем дефекте можно отслеживать состояние его устранения, ответственное за это лицо, вре- мя устранения, а также другие дополнительные сведения. Следует заметить, что накопленная база дефектов позво- ляет сократить шансы появления ошибок в дальнейших разработках, так как даёт представление и возможных де- фектах и причинах их возникновения. К системам управления дефектами относятся: 1. Inflectra SpiraTeam. 2. YouTrack. 3. Bugzilla. 4. Mantis. 5. FogBugz. 6. Zoho Projects. 7. BugHerd. 8. Bugify. 9. Pivotal Tracker. 10. JIRA Atlassian. 11. TestLink. 12. TestRail. 13. Sitechco. 14. Microsoft Team Foundation Server. 150 Методы оценки и измерения характеристик информационных систем 6.5.5 Система создания, хранения и запуска тестовых сценариев Эффективность процесса тестирования напрямую отражается на сроках реализации любого проекта, его стоимости и потенциальной прибыли, так как невыход на рынок в срок может привести к её недополучению. Потенциальным решением для повышения качества и скорости тестирования является его автоматизация, од- нако даже создание автоматических тестов полностью не решает проблемы. Автоматические тесты выполня- ют тестовые сценарии автоматически, но при этом сами требуют запуска. С каждым новым релизом от разра- ботчиков необходимо в ручную запускать множество автоматических тестов, которые, в свою очередь, запус- кают тестовые сценарии и документируют результаты. Для более рационального использования времен- ных и человеческих ресурсов существуют системы не- прерывной интеграции (continuous integration). Такие системы позволяют одновременно в изолированных средах запускать сразу несколько автоматических тес- тов, а также имеют возможность работы по расписа- нию. Таким образом, команда тестировщиков планирует проводимые тестирования заранее, имеет возможность выполнять весь их набор одновременно, а результаты прохождения тестов отображать комплексно. Если раз- рабатываемая система покрыта тестами в требуемом масштабе, то применение систем непрерывной интег- рации позволит в течение нескольких дней произвести тестирование итерационного релиза и передать список необходимых доработок разработчикам. Следует заметить, что конфигурирование таких систем может быть весьма трудоёмким, поскольку в ком- пании должны быть разработаны автоматические тесты 151 Тестирования программного обеспечения на все отслеживаемые требованиями параметры. Если этого не сделано, что проводить комплексное тестиро- вание не имеет особого смысла, так как в дальнейшем требуются дополнительные мероприятия для проверки соответствия остальным требованиям. Кроме этого, та- кого рода системы требуют дополнительной ИТ-инфра- структуры, начиная от выделенного сервера и заканчивая сборками различного программного обеспечения. Примерами систем непрерывной интеграции яв- ляются: 1. Jenkins CI. 2. Atlassian Bamboo. 3. ThoughtWorks Go. 4. Buildbot. 5. JetBrains TeamCity. 6. Hudson CI. 7. Continua CI. 8. Codeship. 9. CircleCI. 10. AppVeyor. 11. Microsoft Team Foundation Server. 12. Travis CI. 152 Методы оценки и измерения характеристик информационных систем 7. Стандартизация и сертификация программного обеспечения 7.1 Законодательство в сфере стандартизации В современных условиях постоянно растущего рынка программного обеспечения, мощного развития ин- формационных систем и технологий, острой конкуренции среди разработчиков ПО и ИС, высокой требовательнос- ти потребителей к качеству и безопасности программных продуктов сложились объективные условия появления целого ряда стандартов и руководств, которые до мельчай- ших деталей стандартизируют процессы проектирования, разработки и внедрения информационных систем. Проблем в области стандартизации за двадцать пять лет в стране накопилось достаточно много, которые полностью не решались ни одним принятым законода- тельным актом. Старая система стандартизации прекра- тила свое существование с распадом СССР. Перестали существовать структуры, которые разрабатывали новые стандарты, совершенствовали и обновляли старые. Боль- шие надежды возлагались на закон «О Техническом ре- гулировании» [1], но его ограниченность и затянувшаяся на десяток лет реализация привели систему стандартиза- ции в стране в плачевное состояние. Выходом стал под- ход, при котором в России принимались наиболее удач- ные стандарты других стран, прежде всего Европейского союза. Например, популярный стандарт ISO 9000-2011, после перевода и принятия в России стал межгосударс- твенным стандартом ГОСТ ISO 9000-2011. И таких при- меров достаточное количество. Это лучше, чем полное отсутствие хороших и современных стандартов. Миро- вой опыт лучших компаний тоже надо учитывать, что бы с нуля не «изобретать велосипед». 153 Стандартизация и сертификация программного обеспечения Развитая национальная система стандартизации – это не только безопасность населения, но гарантия сохранения жизни и здоровья людей. Это закреплено в новом Федеральном законе N 162-ФЗ “О стандарти- зации в Российской Федерации” 29 июня 2015 года. Федеральный закон N 162- ФЗ “О стандартизации в Российской Федерации” Федеральный закон устанавливает правовые ос- новы стандартизации в Российской Федерации, в том числе функционирования национальной системы стан- дартизации, и направлен на обеспечение проведения единой государственной политики в сфере стандарти- зации. Настоящий Федеральный закон регулирует от- ношения в сфере стандартизации, включая отношения, возникающие при разработке (ведении), утверждении, изменении (актуализации), отмене, опубликовании и применении документов по стандартизации, указан- ных в статье 14 настоящего Федерального закона. Основные определения и понятия 1) Документ по стандартизации - документ, в котором для добровольного и многократного примене- ния устанавливаются общие характеристики объекта стандартизации, а также правила и общие принципы в отношении объекта стандартизации, за исключением случаев, если обязательность применения документов по стандартизации устанавливается настоящим Феде- ральным законом. 2) Документы, разрабатываемые и применя- емые в национальной системе стандартизации (далее - документы национальной системы стандарти- зации), - национальный стандарт Российской Федера- ции (далее - национальный стандарт), в том числе ос- новополагающий национальный стандарт Российской 154 Методы оценки и измерения характеристик информационных систем Федерации (далее - основополагающий национальный стандарт), и предварительный национальный стандарт Российской Федерации (далее - предварительный на- циональный стандарт), а также правила стандартиза- ции, рекомендации по стандартизации, информацион- но-технические справочники. 3) Информационно-технический справоч- ник - документ национальной системы стандар- тизации, утвержденный федеральным органом исполнительной власти в сфере стандартизации, содержащий систематизированные данные в опре- деленной области и включающий в себя описание технологий, процессов, методов, способов, обору- дования и иные данные. 4) Национальная система стандартизации - механизм обеспечения согласованного взаимодействия участников работ по стандартизации (федеральный ор- ган исполнительной власти, осуществляющий функции по выработке государственной политики и норматив- но-правовому регулированию в сфере стандартизации, федеральный орган исполнительной власти в сфере стандартизации, другие федеральные органы исполни- тельной власти, Государственная корпорация по атом- ной энергии “Росатом” и иные государственные корпо- рации в соответствии с установленными полномочия- ми в сфере стандартизации, технические комитеты по стандартизации, проектные технические комитеты по стандартизации, комиссия по апелляциям, юридичес- кие лица, в том числе общественные объединения, заре- гистрированные на территории Российской Федерации, физические лица - граждане Российской Федерации) на основе принципов стандартизации при разработке (ве- дении), утверждении, изменении (актуализации), отме- не, опубликовании и применении документов по стан- |