 | Эта статья поднимает множество проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны ) ( Узнайте, как и когда удалить этот шаблон сообщения )
|
Существует значительное разнообразие среди тестирования программного обеспечения писателей и консультантов о том , что представляет собой ответственное тестирование программного обеспечения. Выдающиеся члены Школы контекстно-ориентированного тестирования [1] считают, что большая часть работ о тестировании программного обеспечения является доктриной, мифологией и фольклором. Некоторые утверждают, что это убеждение прямо противоречит стандартам, таким как стандарт тестовой документации IEEE 829 , и организациям, таким как Управление по санитарному надзору за качеством пищевых продуктов и медикаментов, которые их продвигают. Ответ Школы, ориентированной на контекст, состоит в том, что уроки, извлеченные из тестирования программного обеспечениявключает один урок, поддерживающий использование IEEE 829, и другой, противостоящий ему; что не все тестирование программного обеспечения происходит в регулируемой среде, и что методы, подходящие для таких сред, будут чрезвычайно дорогими, ненужными и неподходящими для других контекстов; и что в любом случае FDA обычно продвигает принцип наименее обременительного подхода.
Некоторые из основных противоречий включают:
Лучшие практики [ править ]
Многие члены Школы тестирования, основанной на контексте, считают, что передовых методов тестирования не существует, а скорее, что тестирование - это набор навыков, которые позволяют тестировщику выбирать или изобретать методы тестирования, подходящие для каждой уникальной ситуации. Джеймс Бах писал: «... нет практики лучше, чем все другие возможные практики, независимо от контекста». [2] Однако некоторые специалисты по тестированию не видят проблем с концепцией «передовой практики» и не считают, что этот термин подразумевает универсальное применение той или иной практики. [3]
Гибкое против традиционного [ править ]
Примерно с 1990 года новый стиль написания о тестировании стал ставить под сомнение то, что было раньше. Основополагающей работой в этом отношении считается « Тестирование компьютерного программного обеспечения » Джема Канера . [4] Вместо того чтобы предполагать, что тестировщики имеют полный доступ к исходному коду и полным спецификациям, эти авторы, включая Канера и Джеймса Баха , утверждали, что тестировщики должны научиться работать в условиях неопределенности и постоянных изменений. Между тем, противоположная тенденция к «зрелости» процессов также получила распространение в форме модели зрелости возможностей . Движение по гибкому тестированию (которое включает, помимо прочего, формы тестирования, применяемые при гибкой разработке). projects) пользуется популярностью в основном в коммерческих кругах, тогда как CMM была принята правительственными и военными поставщиками программного обеспечения.
Однако утверждение, что «модели зрелости», такие как CMM, набирают силу против или противодействуют Agile-тестированию, может быть неверным. Гибкое движение - это «способ работы», а CMM - это идея улучшения процесса.
Но необходимо учитывать другую точку зрения: операционную культуру организации. Хотя может быть правдой, что тестировщики должны иметь способность работать в мире неопределенности, верно также и то, что их гибкость должна иметь направление. Во многих случаях тестовые культуры являются самостоятельными, и в результате могут быть получены бесплодные и непродуктивные результаты. Более того, предоставление положительных свидетельств дефектов может указывать либо на то, что вы нашли верхушку гораздо более серьезной проблемы, либо на то, что вы исчерпали все возможности. Фреймворк - это тест тестирования. Он обеспечивает границу, которая может измерить (подтвердить) производительность нашей работы. Обе стороны имеют и будут продолжать спорить о достоинствах своей работы. Доказательство тому - каждая оценка качества доставки. Если вы слишком узко сфокусированы, систематические проверки не принесут пользы.С другой стороны, обнаружение множества ошибок не означает, что Agile-методы были движущей силой; Возможно, вы просто наткнулись на заведомо плохую работу.
Исследовательские и скриптовые [ править ]
 | В этом разделе не процитировать любые источники . ( Декабрь 2017 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
Исследовательское тестирование означает одновременное проектирование и выполнение тестов с упором на обучение. Тестирование по сценариям означает, что обучение и разработка тестов происходят до выполнения теста, и довольно часто обучение приходится повторять во время выполнения теста. Исследовательское тестирование очень распространено, но в большинстве статей и тренингов о тестировании оно почти не упоминается и обычно неправильно понимается. Некоторые авторы считают это основной и необходимой практикой. Структурированное исследовательское тестирование - это компромисс, когда тестировщики знакомы с программным обеспечением. Составлен нечеткий план тестирования, известный как устав тестирования, в котором описывается, какие функции необходимо протестировать, но не как, что позволяет отдельным тестировщикам выбирать метод и этапы тестирования.
Есть два основных недостатка, связанных с преимущественно исследовательским подходом к тестированию. Во-первых, нет возможности предотвратить дефекты, которые могут произойти, когда предварительное проектирование тестов служит формой структурированного статического тестирования, которое часто выявляет проблемы в системных требованиях и дизайне. Во-вторых, даже с использованием уставов тестирования сложно продемонстрировать охват тестами и добиться повторяемости тестов с использованием чисто исследовательского подхода к тестированию. По этой причине часто используется смешанный подход, состоящий из сценариев и исследовательского тестирования, для получения преимуществ и устранения недостатков каждого подхода.
Ручное или автоматическое [ править ]
Некоторые авторы считают, что автоматизация тестирования настолько дорога по сравнению с ее стоимостью, что ее следует использовать с осторожностью. [5] Другие, например сторонники гибкой разработки , рекомендуют автоматизировать 100% всех тестов. Проблема с автоматизацией заключается в том, что для автоматизированного тестирования требуются автоматизированные тестовые оракулы (оракул - это механизм или принцип, с помощью которого можно распознать проблему в программном обеспечении). Такие инструменты имеют ценность в программном обеспечении для нагрузочного тестирования (при одновременном входе в приложение с сотнями или тысячами экземпляров) или при проверке периодических ошибок в программном обеспечении. Успех автоматизированного тестирования программного обеспечения зависит от полного и всестороннего планирования тестирования. Стратегии разработки программного обеспечения, такие как разработка через тестированиеполностью совместимы с идеей посвящения значительной части ресурсов тестирования организации автоматизированному тестированию. Многие крупные организации, занимающиеся программным обеспечением, проводят автоматическое тестирование. Некоторые разработали собственные автоматизированные среды тестирования специально для внутренней разработки, а не для перепродажи.
Дизайн программного обеспечения и реализация программного обеспечения [ править ]
В этом разделе не процитировать любые источники . ( Декабрь 2017 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
[ non sequitur ]
если тестирование программного обеспечения собирает информацию о продукте или программе для заинтересованных сторон, из этого не следует, что есть выбор между реализацией тестирования или дизайном, т. е. это ошибочное предположение. [ требуется пояснение ] В идеале, тестировщики программного обеспечения не должны ограничиваться только тестированием реализации программного обеспечения, но и тестированием проекта программного обеспечения. При таком предположении роль и участие тестировщиков резко изменятся. В такой среде изменится и цикл тестирования. Чтобы протестировать дизайн программного обеспечения, тестировщики вместе с дизайнером и программистом будут рассматривать требования и спецификации проекта, что может помочь выявить ошибки на более раннем этапе разработки программного обеспечения.
Кто наблюдает за сторожами? [ редактировать ]
Этот раздел требует дополнительных ссылок для проверки . ( Январь 2008 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
Один принцип в тестировании программного обеспечения резюмируется классическим латинским вопросом, заданным Ювеналом: Quis Custodiet Ipsos Custodes (Кто наблюдает за сторожами?) Или, альтернативно, неофициально упоминается как концепция " Гейзенбуга " (распространенное заблуждение, которое сбивает с толку Гейзенберга принцип неопределенности с эффектом наблюдателя ). Идея состоит в том, что любая форма наблюдения - это также взаимодействие, что акт тестирования также может повлиять на то, что проверяется.
На практике инженер-испытатель тестирует программное обеспечение (а иногда и аппаратное обеспечение или прошивку ) с другим программным обеспечением (а также аппаратным и встроенным ПО). Процесс может дать сбой, который не является результатом дефектов в целевом объекте, а скорее является результатом дефектов (или даже предполагаемых функций) инструмента тестирования.
Разрабатываются метрики для измерения эффективности тестирования. Один из методов - анализ покрытия кода (это очень спорно), когда каждый может согласиться с тем, какие области вообще не охвачены, и попытаться улучшить охват в этих областях.
Ошибки также могут быть специально помещены в код, и количество ошибок, которые не были обнаружены, можно предсказать на основе процента обнаруженных намеренно размещенных ошибок. Проблема в том, что он предполагает, что преднамеренные ошибки являются ошибками того же типа, что и непреднамеренные.
Наконец, есть анализ исторической активности находок. Измеряя количество обнаруженных ошибок и сравнивая их с прогнозируемыми числами (на основе прошлого опыта с аналогичными проектами), можно сделать определенные предположения относительно эффективности тестирования. Хотя это и не является абсолютным показателем качества, но если проект наполовину завершен и дефектов не обнаружено, то могут потребоваться изменения в процедурах, используемых QA.
Ссылки [ править ]
- ^ context-driven-testing.com
- ↑ Бах, Джеймс (8 июля 2005 г.). «Нет передового опыта» . Проверено 5 февраля 2018 .
- ^ Colantonio, Джо (13 апреля 2017). «Лучшие практики против хороших практик - поиск с Рексом Блэком» . Проверено 5 февраля 2018 .
- ^ Канер, Джем ; Джек Фальк; Хунг Куок Нгуен (1993). Тестирование компьютерного программного обеспечения (Третье изд.). Джон Вили и сыновья. ISBN 1-85032-908-7. CS1 maint: обескураженный параметр ( ссылка )
- ^ Примером может служить Марк Фьюстер, Дороти Грэм: Автоматизация тестирования программного обеспечения. Эддисон Уэсли, 1999, ISBN 0-201-33140-3
