Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Общая некорректность тест-кейсов. Может быть вызвана множеством при- чин и выражаться множеством образов, но вот классический пример: Шаги выполнения Ожидаемые результаты … 4. Закрыть приложение нажатием Alt+F4. 5. Выбрать в меню «Текущее состояние». … 4. Приложение завершает работу. 5. Отображается окно с заголовком «Текущее состояние» и содержимым, соответствую- щим рисунку 999.99. Здесь или не указано, что вызов окна «Текущее состояние» происходит где- то в другом приложении, или остаётся загадкой, как вызвать это окно у завершив- шего работу приложения. Запустить заново? Возможно, но в тест-кейсе этого не сказано. Неверное разбиение наборов данных на классы эквивалентности. Дей- ствительно, иногда классы эквивалентности {91} могут быть очень неочевидными. Но ошибки встречаются и в довольно простых случаях. Допустим, в требованиях ска- зано, что размер некоего файла может быть от 10 до 100 КБ (включительно). Раз- биение по размеру 0–9 КБ, 10–100 КБ, 101+ КБ ошибочно, т.к. килобайт не явля- ется неделимой единицей. Такое ошибочное разбиение не учитывает, например, размеры в 9.5 КБ, 100.1 КБ, 100.7 КБ и т.д. Потому здесь стоит применять неравен- ства: 0 КБ ≤ размер < 10 КБ, 10 КБ ≤ размер ≤ 100 КБ, 100 КБ < размер. Также можно писать с использованием синтаксиса скобок: [0, 10) КБ, [10, 100] КБ, (100, ∞) КБ, но вариант с неравенствами более привычен большинству людей. Тест-кейсы, не относящиеся к тестируемому приложению. Например, нам нужно протестировать фотогалерею на сайте. Соответственно, следующие тест-кейсы никак не относятся к фотогалерее (они тестируют браузер, операцион- ную систему пользователя, файловый менеджер и т.д. — но НЕ наше приложение, ни его серверную, ни даже клиентскую часть): • Файл с сетевого диска. • Файл со съёмного носителя. • Файл, заблокированный другим приложением. • Файл, открытый другим приложением. • Файл, к которому у пользователя нет прав доступа. • Вручную указать путь к файлу. • Файл из глубоко расположенной поддиректории. Формальные и/или субъективные проверки. Чаще всего данную ошибку можно встретить в пунктах чек-листа. Возможно, у автора в голове и был чёткий и подробный план, но из следующих примеров совершенно невозможно понять, что будет сделано с приложением, и какой результат мы должны ожидать: • «Сконвертировать». • «Проверить метод getMessage()». • «Некорректная работа в корректных условиях». • «Скорость». • «Объём данных». • «Должно работать быстро». В отдельных исключительных ситуациях можно возразить, что из контекста и дальнейшей детализации становится понятно, что имелось в виду. Но чаще всего никакого контекста и никакой дальнейшей детализации нет, т.е. приведённые при- меры оформлены как отдельные полноправные пункты чек-листа. Так — нельзя. Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 163/298 Как можно и нужно – см. в примере чек-листа {113} и всём соответствующем раз- деле {112} Теперь для лучшего закрепления рекомендуется заново прочитать про оформление атрибутов тест-кейсов {121} , свойства качественных тест-кейсов {133} и ло- гику построения {149} качественных тест-кейсов и качественных наборов тест-кейсов. Отчёты о дефектах Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 164/298 2.5. Отчёты о дефектах 2.5.1. Ошибки, дефекты, сбои, отказы и т.д. Упрощённый взгляд на понятие дефекта Далее в этой главе мы глубоко погрузимся в терминологию (она действи- тельно важна!), а потому начнём с очень простого: дефектом упрощённо можно счи- тать любое расхождение ожидаемого (свойства, результата, поведения и т.д., ко- торое мы ожидали увидеть) и фактического (свойства, результата, поведения и т.д., которое мы на самом деле увидели). При обнаружении дефекта создаётся отчёт о дефекте. Дефект — расхождение ожидаемого и фактического результата. Ожидаемый результат — поведение системы, описанное в требованиях. Фактический результат — поведение системы, наблюдаемое в процессе тестирования. ВАЖНО! Эти три определения приведены в предельно упрощённой (и даже искажённой) форме с целью первичного ознакомления. Полноцен- ные формулировки см. далее в этой же главе. Поскольку столь простая трактовка не покрывает все возможные формы про- явления проблем с программными продуктами, мы сразу же переходим к более по- дробному рассмотрению соответствующей терминологии. Расширенный взгляд на терминологию, описывающую проблемы Разберёмся с широким спектром синонимов, которыми обозначают про- блемы с программными продуктами и иными артефактами и процессами, сопут- ствующими их разработке. В силлабусе ISTQB написано 307 , что человек совершает ошибки, которые при- водят к возникновению дефектов в коде, которые, в свою очередь, приводят к сбоям и отказам приложения (однако сбои и отказы могут возникать и из-за внешних усло- вий, таких как электромагнитное воздействие на оборудование и т.д.). Таким образом, упрощённо можно изобразить следующую схему: Рисунок 2.5.a — Ошибки, дефекты, сбои и отказы 307 A human being can make an error (mistake), which produces a defect (fault, bug) in the program code, or in a document. If a defect in code is executed, the system may fail to do what it should do (or do something it shouldn't), causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so. Defects occur because human beings are fallible and because there is time pressure, complex code, complexity of infrastructure, changing technologies, and/or many system interactions. Failures can be caused by environmental conditions as well. For example, radiation, magnetism, electronic fields, and pollution can cause faults in firmware or influence the execution of software by changing the hardware conditions. [ISTQB Syllabus] Ошибка Дефект Сбой или отказ Ошибки, дефекты, сбои, отказы и т.д. Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 165/298 Если же посмотреть на англоязычную терминологию, представленную в глоссарии ISTQB и иных источниках, можно построить чуть более сложную схему: Рисунок 2.5.b — Взаимосвязь проблем в разработке программных продуктов Рассмотрим все соответствующие термины. Ошибка (error 308 , mistake) — действие человека, приводящее к некоррект- ным результатам. Этот термин очень часто используют как наиболее универсальный, описыва- ющий любые проблемы («ошибка человека», «ошибка в коде», «ошибка в докумен- тации», «ошибка выполнения операции», «ошибка передачи данных», «ошибочный результат» и т.п.) Более того, куда чаще вы сможете услышать «отчёт об ошибке», чем «отчёт о дефекте». И это нормально, так сложилось исторически, к тому же термин «ошибка» на самом деле очень широкий. Дефект (defect 309 , bug, problem, fault) — недостаток в компоненте или си- стеме, способный привести к ситуации сбоя или отказа. Этот термин также понимают достаточно широко, говоря о дефектах в доку- ментации, настройках, входных данных и т.д. Почему глава называется именно «от- чёты о дефектах»? Потому что этот термин как раз стоит посередине — бессмыс- ленно писать отчёты о человеческих ошибках, равно как и почти бесполезно просто описывать проявления сбоев и отказов — нужно докопаться до их причины, и пер- вым шагом в этом направлении является именно описание дефекта. Сбой (interruption 310 ) или отказ (failure 311 ) — отклонение поведения си- стемы от ожидаемого. В ГОСТ 27.002-89 даны хорошие и краткие определения сбоя и отказа: Сбой — самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора. Отказ — событие, заключающееся в нарушении работоспособного состо- яния объекта. Эти термины скорее относятся к теории надёжности и нечасто встречаются в повседневной работе тестировщика, но именно сбои и отказы являются тем, что тестировщик замечает в процессе тестирования (и отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины). 308 Error, Mistake. A human action that produces an incorrect result. [ISTQB Glossary] 309 Defect, Bug, Problem, Fault. A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system. [ISTQB Glossary] 310 Interruption. A suspension of a process, such as the execution of a computer program, caused by an event external to that process and performed in such a way that the process can be resumed. [ http://www.electropedia.org/iev/iev.nsf/display?open- form&ievref=714-22-10 ] 311 Failure. Deviation of the component or system from its expected delivery, service or result. [ISTQB Glossary] Error (Mistake) Defect (Problem, Bug, Fault) Failure, Interruption Anomaly, Incident (Deviation) Ошибки, дефекты, сбои, отказы и т.д. Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 166/298 Аномалия (anomaly 312 ) или инцидент (incident 313 , deviation) — любое от- клонение наблюдаемого (фактического) состояния, поведения, значения, результата, свойства от ожиданий наблюдателя, сформированных на ос- нове требований, спецификаций, иной документации или опыта и здра- вого смысла. Итак, мы вернулись к тому, с чего начинали в части этой главы, описывающей предельно упрощённый взгляд на дефекты. Ошибки, дефекты, сбои, отказы и т.д. являются проявлением аномалий — отклонений фактического результата от ожи- даемого. Стоит отметить, что ожидаемый результат действительно может основы- ваться на опыте и здравом смысле, т.к. поведение программного средства никогда не специфицируют до уровня базовых элементарных приёмов работы с компьюте- ром. Теперь, чтобы окончательно избавиться от путаницы и двусмысленности, до- говоримся, что мы будем считать дефектом в контексте данной книги: Дефект — отклонение (deviation 313 ) фактического результата (actual re- sult 314 ) от ожиданий наблюдателя (expected result 315 ) , сформированных на основе требований, спецификаций, иной документации или опыта и здра- вого смысла. Отсюда логически вытекает, что дефекты могут встречаться не только в коде приложения, но и в любой документации, в архитектуре и дизайне, в настройках тестируемого приложения или тестового окружения — где угодно. Важно понимать, что приведённое определение дефекта позволяет лишь поднять вопрос о том, является ли некое поведение приложения дефек- том. В случае, если из проектной документации не следует однозначного положительного ответа, обязательно стоит обсудить свои выводы с кол- легами и добиться донесения поднятого вопроса до заказчика, если его мнение по обсуждаемому «кандидату в баги» неизвестно. Хорошее представление о едва-едва затронутой нами теме теории надёжности можно получить, прочитав книгу Рудольфа Стапелберга «Руководство по надёжности, доступности, ремонтопригодности и без- опасности в инженерном проектировании» (Rudolph Frederick Stapelberg, «Handbook of Reliability, Availability, Maintainability and Safety in Engineering Design»). А краткую, но достаточно подробную классификацию аномалий в про- граммных продуктах можно посмотреть в стандарте «IEEE 1044:2009 Standard Classification For Software Anomalies ». 312 Anomaly. Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, etc. or from so meone’s perception or experience. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation. See also bug, defect, deviation, error, fault, failure, incident, problem. [ISTQB Glossary] 313 Incident, Deviation. Any event occurring that requires investigation. [ISTQB Glossary] 314 Actual result. The behavior produced/observed when a component or system is tested. [ISTQB Glossary] 315 Expected result, Expected outcome, Predicted outcome. The behavior predicted by the specification, or another source, of the component or system under specified conditions. [ISTQB Glossary] Отчёт о дефекте и его жизненный цикл Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 167/298 2.5.2. Отчёт о дефекте и его жизненный цикл Как было сказано в предыдущей главе, при обнаружении дефекта тестиров- щик создаёт отчёт о дефекте. Отчёт о дефекте (defect report 316 ) — документ, описывающий и приорити- зирующий обнаруженный дефект, а также содействующий его устране- нию. Как следует из самого определения, отчёт о дефекте пишется со следую- щими основными целями: • предоставить информацию о проблеме — уведомить проектную команду и иных заинтересованных лиц о наличии проблемы, описать суть проблемы; • приоритизировать проблему — определить степень опасности проблемы для проекта и желаемые сроки её устранения; • содействовать устранению проблемы — качественный отчёт о дефекте не только предоставляет все необходимые подробности для понимания сути случившегося, но также может содержать анализ причин возникновения про- блемы и рекомендации по исправлению ситуации. На последней цели следует остановиться подробнее. Есть мнение, что «хо- рошо написанный отчёт о дефекте — половина решения проблемы для програм- миста». И действительно, как мы увидим далее (и особенно в главе «Типичные ошибки при написании отчётов о дефектах» {199} ), от полноты, корректности, аккурат- ности, подробности и логичности отчёта о дефекте зависит очень многое — одна и та же проблема может быть описана так, что программисту останется буквально исправить пару строк кода, а может быть описана и так, что сам автор отчёта на следующий день не сможет понять, что же он имел в виду. ВАЖНО! «Сверхцель» написания отчёта о дефекте состоит в быстром ис- правлении ошибки (а в идеале — и недопущении её возникновения в бу- дущем). Потому качеству отчётов о дефекте следует уделять особое, по- вышенное внимание. Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла, которые схематично можно показать так (рисунок 2.5.c): • Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт. • Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто- то из проектной команды назначается ответственным за исправление де- фекта. Назначение ответственного производится или решением лидера ко- манды разработки, или коллегиально, или по добровольному принципу, или иным принятым в команде способом или выполняется автоматически на ос- нове определённых правил. • Исправлен (fixed) — в это состояние отчёт переводит ответственный за ис- правление дефекта член команды после выполнения соответствующих дей- ствий по исправлению. • Проверен (verified) — в это состояние отчёт переводит тестировщик, удосто- верившийся, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестировщик, изначально написавший отчёт о дефекте. 316 Defect report, Bug report. A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function. [ISTQB Glossary] Отчёт о дефекте и его жизненный цикл Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 168/298 По поводу того, должен ли проверять факт устранения дефекта именно тот тестировщик, который его обнаружил, или обязательно другой, есть много «священных войн». Сторонники второго вари- анта утверждают, что свежий взгляд человека, ранее не знакомого с данным дефектом, позволяет ему в процессе верификации с большой вероятностью обнаружить новые дефекты. Несмотря на то, что такая точка зрения имеет право на существо- вание, всё же отметим: при грамотной организации процесса тести- рования поиск дефектов эффективно происходит на соответствую- щей стадии работы, а верификация силами тестировщика, обнару- жившего данный дефект, всё же позволяет существенно сэконо- мить время. Рисунок 2.5.c — Жизненный цикл отчёта о дефекте с наиболее типичными перехо- дами между состояниями Набор стадий жизненного цикла, их наименование и принцип перехода от стадии к стадии может различаться в разных инструментальных сред- ствах управления жизненным циклом отчётов о дефектах. Более того — многие такие средства позволяют гибко настраивать эти параметры. На рисунке 2.5.c показан лишь общий принцип. • Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий (хотя, конечно, ничто не ме- шает в будущем этому дефекту стать «открытым заново» (reopened)). Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инстру- ментальных средствах управления отчётами о дефектах: o В некоторых средствах существуют оба состояния — «Проверен» и «Закрыт», чтобы подчеркнуть, что в состоянии «Проверен» ещё могут потребоваться какие-то дополнительные действия (обсуждения, до- полнительные проверки в новых билдах и т.д.), в то время как состоя- ние «Закрыт» означает «с дефектом покончено, больше к этому во- просу не возвращаемся». o В некоторых средствах одного из состояний нет (оно поглощается дру- гим). Обнаружен Назначен Исправлен Проверен Отложен Закрыт Открыт заново Отклонён Рекомендован к отклонению Отчёт о дефекте и его жизненный цикл Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 169/298 o В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте может быть переведён из множества предшествующих состо- яний с резолюциями наподобие: ▪ «Не является дефектом» — приложение так и должно работать, описанное поведение не является аномальным. ▪ «Дубликат» — данный дефект уже описан в другом отчёте. ▪ «Не удалось воспроизвести» — разработчикам не удалось вос- произвести проблему на своём оборудовании. ▪ «Не будет исправлено» — дефект есть, но по каким-то серьёз- ным причинам его решено не исправлять. ▪ «Невозможно исправить» — непреодолимая причина дефекта находится вне области полномочий команды разработчиков, например существует проблема в операционной системе или аппаратном обеспечении, влияние которой устранить разум- ными способами невозможно. Как было только что подчёркнуто, в некоторых средствах отчёт о де- фекте в подобных случаях будет переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за «Отклонён». • Открыт заново (reopened) — в это состояние (как правило, из состояния «Ис- правлен») отчёт переводит тестировщик, удостоверившийся, что дефект по- прежнему воспроизводится на билде, в котором он уже должен быть исправ- лен. • Рекомендован к отклонению (to be declined) — в это состояние отчёт о де- фекте может быть переведён из множества других состояний с целью выне- сти на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт). • Отклонён (declined) — в это состояние отчёт переводится в случаях, по- дробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту. • Отложен (deferred) — в это состояние отчёт переводится в случае, если ис- правление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что в обозри- мом будущем ситуация исправится (выйдет новая версия библиотеки, вер- нётся из отпуска специалист по некоей технологии, изменятся требования заказчика и т.д.). Для полноты рассмотрения данной подтемы приведём пример жизненного цикла, принятого по умолчанию в инструментальном средстве управления отчё- тами о дефектах JIRA 317 ( рисунок 2.5.d). 317 «What is Workflow». [ https://confluence.atlassian.com/jira063/what-is-workflow-683542483.html ] Отчёт о дефекте и его жизненный цикл Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 170/298 Рисунок 2.5.d — Жизненный цикл отчёта о дефекте в JIRA Открыт В работе Закрыт Открыт заново Исправлен Создание Исправление Закрытие Остановка работы Начало работы Повторное открытие Исправление Закрытие Закрытие Закрытие Начало работы Повторное открытие |