Отсутствие силы воли у наших людей породило огромное количество тренингов. Людям нужен толчок, чтобы отказаться от надоедливой работы, нелюбимого человека и серых будней. Однако запала надолго не хватает. В конце концов они вернутся за новой порцией мотивации. Относишь ли ты к ним или можешь оставаться счастливым самостоятельно? Сейчас проверим!
Добро – это то, чего не хватает современному обществу. Убедиться в этом можно пролистав ленту новостей. Позитивного и доброго там мало. Мы поддерживаем мнение, что начинать всегда надо с себя. Пусть этот тест будет твоим первым шагом.
Интуиция - это то, что мы привыкли называть "совпадением" и "случайностью". На самом деле именно шестое чувство приводит нас к тому самому совпадению, которое способно поменять ход событий. Старая, как мир, игра "Орел или Решка" - прекрасный способ проверить свою интуицию. Казалось бы, нет ничего сложного угадать, ведь шанс предельно высок - 50%! Как бы не так. Мы сделаем 8 бросков, попробуй дать столько же правильных ответов.
Союза нерушимых республик свободных уже давно нет, но это не означает, что можно забыть историю великой державы, которая оставила такой яркий след в истории. Сегодня мы подготовили тест, состоящий из вопросов, с которыми справится лишь выпускник советской школы, так как они требуют глубокие знания. Если ты считаешь, что справишься, то скорее приступай!
Биологический возраст - это далеко не самый важный показатель в жизни. Существуют куда более весомые цифры. Например, сколько лет вашей душе или мозгу. Наш поток мыслей - это невероятно сложная система, она развивается и растет вместе с нами. С точки зрения психологии, каждому возрасту соответствуют определенные мысли и выбор. Давайте разберемся, вы преуспеваете или отстаете в своем развитии.
Магистр клуба "Что? Где? Когда?" скандально отстранен от участия в программе. Теперь у него больше нет права своими знаниями и логикой зарабатывать деньги, популярность и уважение. Но, как говорится, на корабле всегда должен быть капитан, предлагаем тебе попробовать занять его место. Используй свой жизненный опыт, логику и смекалку!
Работа – твой второй дом, и весь мир крутится вокруг неё? Или же, работа – способ выжить и приобрести желаемое? Как хорошо ты работаешь и выполняешь свои обязанности, по достоинству ли тебе платят за неё, а может быть, ты заслуживаешь повышения? Пройди наш тест и узнай, какой зарплаты ты, действительно, заслуживаешь. И не забудь показать результат своему начальнику!
Классический набор блюд в России - это пельмени, яичница, жареная картошка, борщ и макароны по-флотски. Это меню закрепилось за нами ещё с советских лет, когда выбор продуктов был скудным. Но так продолжаться больше не может, поэтому предлагаем тебе пройти наш просветительный тест.
Нет проблемы в том, чтобы узнать на фото Альберта Эйнштейна или Михаэля Шумахера. Но мало кто знает, что во всех сферах жизни есть женщины, заслужившие не меньшего внимания. Восстанавливаем справедливость и знакомим тебя с ними.
Сегодня мы подготовили необычайно интересный тест! Он уникален тем, что тут собраны психологические задачи, для решения которых потребуется не ум и логика, а фантазия и внимательность. Если ты считаешь, что справишься, то скорее приступай! Безусловно, твои знания тебе тоже очень помогут!
Знаменитая игра «Кто хочет стать миллионером?» годами собирает целые семьи перед телевизором. Волнение и азарт, которые испытывают участники игры, жаждущие выиграть заветные миллионы, передаются и телезрителям. И не расстраивайся, если по ту сторону экрана ты еще не оказался, ведь сегодня у тебя есть отличная возможность потренироваться! Проверь свои знания!
Любовь – это очень непростое чувство. Некоторым для выражения своих чувств достаточно нескольких дней знакомства, другие же не осмеливаются о них сказать годами, боясь всё испортить. Возможно, наш тест подскажет вам того, кто уже давно не спит по ночам, ломая голову над тем, как вам понравится. И, кто знает, может это перевернёт вашу жизнь!
Самые сумасшедшие и неадекватные люди всегда оказывались примерными семьянинами и работниками. Окружающие могут не замечать, но агрессия внутри переполняет их сердца. Если не проверяться у специалиста, то рано или поздно это выйдет наружу. Наш тест как раз должен помочь разобраться. Точного диагноза не поставим, но о проблеме намекнем.
) записал видео для демонстрации быстрого стресс-тестирования. В его примере подход заключался в подаче на вход визарда приложения огромного объема данных, по существу заставляя приложение нагружать само себя.
Видео длится почти шесть минут. Примерно на середине Джеймс спрашивает: «Вы можете поинтересоваться, почему я не хочу остановиться сейчас. Причина в том, что мы наблюдаем неуклонное ухудшение ситуации. Мы могли бы остановиться сейчас, но возможно мы увидим нечто худшее, если будем продолжать». Таким образом, он продолжил тест. А вскоре после этого Джеймс предложил эвристики для остановки: мы останавливаемся, когда: 1) мы обнаружили достаточно серьезную проблему, или 2) в поведении программы нет явных изменений – программа в целом работает стабильно, или 3) ценность от продолжения теста не оправдывает стоимость. Таковы были эвристики для остановки того теста.
Где-то через год после того, как я впервые увидел это видео, я решил более полно описать эвристики для прекращения тестирования в колонке для журнала «Better Software ». По этому поводу мы с Джеймсом устроили транспективную беседу . Колонку вы можете найти . Ещё год спустя колонка превратилась в неформальную лекцию, которую я прочитал в нескольких местах.
Примерно через шесть месяцев после этого мы оба нашли еще больше эвристик для остановки тестирования. Мы обсуждали их на STAR East 2009, и проходившие в тот момент мимо нас Дэйл Эмери (Dale Emery) и Джеймс Линдсей (James Lyndsay) присоединились к дискуссии. В частности, Дэйл высказал предположение, что во время сражения стрельба может быть остановлена в нескольких случаях: временное затишье, поступление команды «прекратить огонь», соглашение между сторонами о прекращении огня, отход сторон на начальные позиции, разоружение противника. Это показалось мне интересным.
В общем, сейчас я расскажу все эвристики, которые мы нашли. Я подчеркиваю, что эти эвристики для остановки являются именно эвристиками . Эвристики – это быстрые, недорогие способы решения проблемы или принятия решения . Эвристики подвержены ошибкам , то есть они могут как сработать, так и не сработать. Эвристики недостаточно абстрактны , они могут перекрываться и пересекаться друг с другом. Также эвристики зависят от контекста , поэтому предполагается, что они будут использоваться людьми, имеющими знания и навыки для их разумного использования. Ниже я перечислил эвристики и для каждой из них указал некоторые вопросы, при помощи которых можно проверить правомочность её использования.
1. Эвристика «Время вышло !» . Для многих специалистов по тестированию это наиболее распространенная эвристика: мы останавливаем тестирование, когда заканчивается выделенное на него время.
Получили ли мы информацию, которую нам требуется знать о продукте? Не слишком ли высок риск прекращения тестирования? Не был ли срок искусственным , произвольным ? Будет ли выполняться дополнительная разработка , которая потребует дополнительного тестирования ?
Когда-то тест Джозефа Сакса впечатлил меня способностью структурировать мои хаотичные представления об окружающем мире, о себе и других.
Методика включает 60 незаконченных предложений, условно разделенных на 15 групп, которые характеризуют Ваше отношение к:
Друзьям;
Представителям своего и противоположного пола;
Сексуальным отношениям;
Власти и подчинению;
Прошлому и будущему.
Некоторые группы предложений также затрагивают страхи и опасения, которые влияют на Вашу жизнь, указывают на непрожитую вину, а также проливают свет на жизненные цели.
Без обработки тестирование занимает от 20 минут и более.
Инструкция: На бланке теста необходимо закончить предложения одним или несколькими словами.
Бланк теста
1. Думаю, что мой отец редко…
2. Если все против меня, то…
3. Я всегда хотел/хотела…
4. Если бы я занимал руководящий пост…
5. Будущее кажется мне…
6. Мое начальство…
7. Знаю, что глупо, но боюсь…
8. Думаю, что настоящий друг…
9. Когда я был/была ребенком…
10. Идеалом женщины (мужчины) для меня является…
11. Когда я вижу женщину рядом с мужчиной…
12. По сравнению с большинством других семей моя семья…
13. Лучше всего мне работается с…
14. Моя мать и я…
15. Сделал/сделала бы все, чтобы забыть…
16. Если бы мой отец только захотел…
17. Думаю, что я достаточно способен/способна, чтобы…
18. Я мог/могла бы быть очень счастливым/счастливой, если бы…
19. Если кто-нибудь работает под моим руководством…
20. Надеюсь на…
21. В школе мои учителя…
22. Большинство моих друзей не знают, что я боюсь…
23. Не люблю людей, которые…
24. Когда-то…
25. Считаю, что большинство юношей (девушек)…
26. Супружеская жизнь кажется мне…
27. Моя семья обращается со мной, как с…
28. Люди, с которыми я работаю…
29. Моя мать…
30. Моей самой большой ошибкой было…
31. Я хотел/хотела бы, чтобы мой отец…
32. Моя наибольшая слабость заключается в том…
33. Моим скрытым желанием в жизни…
34. Мои подчиненные…
35. Наступит тот день, когда…
36. Когда ко мне приближается мой начальник…
37. Хотелось бы мне перестать бояться…
38. Больше всех люблю тех людей, которые…
39. Если бы я снова стал/стала молодым…
40. Считаю, что большинство женщин (мужчин)…
41. Если бы у меня была нормальная половая жизнь…
42. Большинство известных мне семей…
43. Люблю работать с людьми, которые…
44.Считаю, что большинство матерей…
45. Когда я был/была молодым/молодой, то чувствовал/чувствовала вину, если…
46. Думаю, что мой отец…
47. Когда мне не везет, я…
48. Больше всего в жизни я хотел/хотела бы…
49. Когда я даю другим поручение…
50. Когда буду старым/старой…
51. Люди, превосходство которых над собой я признаю…
52. Мои опасения не раз заставляли меня…
53. Когда меня нет, мои друзья…
54. Моим самым живым воспоминанием детства является…
55. Мне очень не нравится, когда женщины (мужчины)…
56. Моя половая жизнь…
57. Когда я был/была ребенком, моя семья…
58. Люди, которые работают со мной…
59. Я люблю свою мать, но…
60. Самое худшее, что мне случилось совершить, это…
Обработка и интерпретация результатов
Для каждой группы предложений выводится характеристика, определяющая данную систему отношений как положительную(1), отрицательную (2) или безразличную (0).
Например, Будущее кажется мне:
1) мрачным, плохим, странным (2)
2) интересным, интригующим (1)
3) неясным, неизвестным (0)
Такая количественная оценка облегчает выявление дисгармоничной системы отношений. Но более важно, конечно, качественное изучение завершенных предложений.
Ключ
1 группа
. Отношение к отцу 1, 16, 31, 46.
2 группа
. Отношение к себе 2, 17, 32, 47.
3 группа
. Нереализованные возможности 3, 18, 33, 48.
4 группа
. Отношение к подчиненным 4, 19, 34, 49.
5 группа
. Отношение к будущему 5, 20, 35, 50.
6 группа
. Отношение к вышестоящим лицам 6, 21, 36, 51.
7 группа
. Страхи и опасения 7, 22, 37, 52.
8 группа
. Отношение к друзьям 8, 23, 38, 53.
9 группа
. Отношение к своему прошлому 9, 24, 39, 54.
10 группа
. Отношение к лицам противоположного пола 10, 25, 40, 55.
11 группа
. Сексуальные отношение 11, 26, 41, 56.
12 группа
. Отношения к семье 12, 27, 42, 57.
13 группа
. Отношение к сотрудникам 13, 28, 43, 58.
14 группа.
Отношение к матери 14, 29, 44, 59.
15 группа.
Чувство вины 15, 30, 45, 60.
Методика «Неоконченных предложений» применяется в экспериментально-психологической практике давно. Однако, доступен он не только профессионалам. Этот тест можно использовать, как отправную точку в изучении себя и своего отношения к другим и миру в целом. Если результаты Вас расстроили, не спешите впадать в уныние: обсудите их с психологом или человеком, которому Вы доверяете. Так или иначе, каждая группа теста требует отдельного обсуждения и осознавания, а также дополнительного подтверждения другими методиками.
Читайте также:
|
Организация процесса тестирования. Разработка ПО в значительной степени есть процесс передачи информации о конечной программе и перевода этой информации из одной формы в другую. Кроме того, подавляющее число ошибок ПО вызвано дефектами организации работ, недостаточным взаимопониманием и искажениями в процессе передачи и перевода информации.
Путем повышения четкости самого процесса разработки можно избежать появления многих ошибок. Это приводит к тому, что в конце каждого этапа необходимо включение отдельного шага проверки, имеющего целью локализовать наибольшее число ошибок до перехода к следующему этапу. Например, спецификация проверяется путем ее сравнения с выходным результатом предыдущей стадии, а каждая обнаруженная ошибка возвращается для устранения в процесс разработки спецификаций.
Кроме того, конкретные процессы тестирования должны быть ориентированы на конкретные этапы разработки. Это сосредотачивает каждый процесс тестирования на каком-либо шаге перевода, в результате чего фиксируется определенный класс ошибок.
Соотношение между процессами разработки и тестирования.
Собственно процесс тестирования начинается с проверки исходного кода. Для этого применяются методы статического тестирования.
Далее следует тестирование модулей, ориентированное на проверку соответствия спецификациям интерфейса модулей, а также тестирование сопряжения и результатов сборки модульной структуры, ориентированное на проверку соответствия проекту системы и (или) проекту структуры отдельной программы.
После этого появляется тестирование функций, которое заключается в поиске различий между программой и ее внешней спецификацией. При тестировании функций обычно применяются методы функционального тестирования. При этом предполагается, что на более раннем этапе тестирования модулей требуемый критерий покрытия логики, свойственный методам структурного тестирования, удовлетворяется.
Для сопоставления результатов разработки с исходными целями появляется процесс комплексного тестирования или, как его еще называют, тестирование системы, в котором проверяется все ПС как единое целое. При рассмотрении различий между полученными результатами и исходными целями разработки ПО наибольшее внимание уделяется выявлению ошибок перевода, возникающих в процессе разработки внешней спецификации. Это делает комплексное тестирование жизненно важным, так как именно на этом этапе обнаруживается больше всего серьезных ошибок.
Процесс тестирования завершают испытания ПО. Испытания позволяют проверить полноту решения функциональных задач, их качество и соответствие ПО технической документации.
Тестирование системы. В отличие от тестирования функций, внешнюю спецификацию нельзя использовать как базис для получения тестов системы, поскольку это противоречит цели проведения такого тестирования. С другой стороны, документ, отражающий цели системы как таковой (в нашем случае - это техническое задание), нельзя использовать для формирования ее тестов, так как он по определению не содержит точных описаний.
Проблема разрешается применением эксплуатационной пользовательской документации. Тесты системы проектируются на основе анализа ее целей по результатам изучения пользовательской документации. Такая практика позволяет сравнить не только программы с исходным документом, но и результаты ее функционирования с пользовательской документацией, а также пользовательскую документацию с исходным документом.
Существует несколько категорий тестов, каждая из которых направлена на проверку определенных целей. К ним относятся тестирование полноты реализации, тестирование на предельных объемах, тестирование на предельных нагрузках, тестирование удобства эксплуатации, тестирование защиты, тестирование конфигурации оборудования, тестирование совместимости, тестирование надежности, тестирование восстановления, тестирование удобства обслуживания, тестирование удобства установки и тестирование документации.
Тестирование полноты реализации является наиболее очевидным видом тестирования системы, который заключается в проверке выполнения каждого пункта исходного документа. Процедура проверки состоит в последовательном просмотре исходного документа - предложение за предложением. Если предложение содержит конкретную задачу, то определяют, выполняет ли программа эту задачу.
Тестирование на предельных объемах заключается в выполнении программы на больших объемах данных, желательно превышающих предлагаемый эксплуатационный объем. Например, на вход компилятора в качестве теста подают большую исходную программу, на вход редактора связей -программу, содержащую тысячу модулей, а на вход программы моделирования электронных схем - схему, содержащую тысячи компонентов. Цель тестирования на предельных объемах - показать, что программа не может управлять объемом данных, специфицированным в исходных целях.
Тестирование на предельных нагрузках обусловлено тем, что потребность в ресурсах памяти и быстродействии в процессе решения задачи на ЭВМ значительно изменяется в зависимости от состава объема исходных данных. При высокой интенсивности ввода исходных данных может нарушаться временной баланс между длительностью решения совокупности задач ПО в реальном времени и реальной производительностью ЭВМ при решении этих задач. Цель тестирования на предельных нагрузках показать, что ПО не удовлетворяет целям в области эффективности.
Тестирование удобства эксплуатации заключается в выявлении психологических (пользовательских) проблем, возникающих при эксплуатации. При этом тестировании следует установить, как минимум, следующее.
- Можно ли приспособить разработанный интерфейс для информирования и обучения конечного пользователя, а также для обеспечения его работы в реальных условиях?
- Значимы ли, внятны ли, не оскорбительны ли выходные сообщения программы?
- Понятна ли диагностика ошибок?
- Проявляет ли все множество пользовательских интерфейсов постоянство и единообразие синтаксиса, соглашений, семантик, формата, стиля и сокращений?
- Содержит ли система опции, число которых чрезмерно или использование которых маловероятно?
- Выдает ли система какие-либо подтверждения на все входные сообщения?
- Легко ли и приятно ли использовать ПО?
Тестирование защиты заключается в проверке обеспечения защиты информации от несанкционированного доступа. Для тестирования защиты важно построить тесты, которые нарушают программные средства защиты. Одним из путей разработки подобных тестов является изучение известных проблем защиты в подобных существующих системах и построении тестов, которые позволяют проверить, как решаются аналогичные проблемы в тестируемой системе.
Тестирование конфигурации оборудования обусловлено тем, что операционные системы, СУБД и коммуникационные системы должны поддерживать множество конфигураций оборудования (например, различные типы и число устройств ввода-вывода и линий связи, различные объемы памяти и т.п.). Часто число возможных конфигураций слишком велико, чтобы проверить ПО на каждой из них. Однако программу следует тестировать по крайней мере с каждым типом оборудования при минимальной и максимальной конфигурациях. Если можно изменять конфигурацию самого ПО, то необходимо тестировать все возможные его конфигурации.
Тестирование совместимости вызвано тем, что большинство разрабатываемого ПО не является полностью новым. Часто оно заменяет несовершенные, устаревшие системы обработки информации или неавтоматизированные процессы. Поэтому при разработке ПО необходимо обеспечить совместимость со средой, в которой работали заменяемые системы, и если необходимо, создать процедуры конверсии, обеспечивающие переход от одного метода обработки данных к другой. В этом случае, как и при других формах тестирования, тесты должны быть ориентированы на проверку обеспечения совместимости и работы процедуры конверсии.
Назначение всех видов тестирования - повысить надежность ПО, но если в исходном документе, отражающем цели проекта, есть особые указания, например, обеспечить определенное время наработки на отказ или задано допустимое число ошибок, то необходимо провести исследование тестируемого ПО на удовлетворение этих требований. Для этого служит тестирование надежности. Дня проведения этого вида тестирования существует ряд математических моделей надежности. Далее, в разделе, посвященном критериям завершения тестирования, будут рассмотрены две модели надежности: так называемая модель Милса и простая интуитивная модель.
Для операционной системы, СУБД и средств телекоммуникации часто определяется, как система должна восстанавливать свою работоспособность после программных ошибок, неисправностей аппаратуры и ошибок в данных. При тестировании системы требуется показать, что эти функции не выполняются. Для этого служит тестирование восстановления. Для этого можно намеренно ввести в систему программные ошибки, чтобы проверить, восстановится ли она после их устранения. Неисправности аппаратуры можно промоделировать. Ошибки в данных (помехи в линиях связи или неправильные значения указателей в базе данных) можно намеренно создать или промоделировать.
В исходном документе иногда формируются специальные цели удобства обслуживания или сопровождения ПО. Они могут определять средства обслуживания, которыми должно снабжаться ПО (например, программы выдачи дампов памяти, программы диагностики и т.п.), среднее время нахождения ошибки, процедуры, связанные с сопровождением, и качество до кум стации о внутренней логике программы. Естественно, все эти цели должны быть протестированы. Для этого применяется тестирование удобств обслуживания.
Цель тестирования удобства установки - показать, что не удовлетворяются цели по части настройки ПО на конкретные условия эксплуатации.
В проверку системы входит и проверка точности пользовательской документации. Большая часть этой проверки происходит при определении правильности представления предшествующих тестов системы. Кроме этого, пользовательская документация должна быть подвергнута инспекции на предмет ее точности и ясности, аналогично инспекциям исходного текста. Любые примеры, приведенные в документации, должны быть оформлены как тест и проверены на ПО.
Критерии завершения тестирования. При проведении тестирования встает вопрос о том, когда следует закончить тестирование программы, поскольку не представляется возможным определить, является ли выявленная ошибка последней.
В основном на практике придерживаются следующих двух критериев: когда время, отведенное по графику работ на тестирование, истекло; когда все тесты оказались неудачными, то есть были выполнены без выявления ошибок.
Оба эти критерия недостаточно точны и логичны, так как первый критерий не содержит оценки качества тестирования и ему можно удовлетворить, ничего не делая, второй же не зависит от качества тестовых наборов данных.
Однако второй критерий можно улучшить, если ориентироваться на определенные методологии проектирования тестов. Например, можно определить условие завершения тестирования модуля с помощью тестов, получаемых двумя путями: удовлетворением комбинаторному покрытию условий и методу анализа граничных значений по спецификации интерфейса модуля. Все получающиеся тесты в конце концов должны стать неудачными.
Завершение тестирования функций можно определить при выполнении следующих условий: тесты, получаемые методами функциональных диаграмм; эквивалентного разбиения и анализа граничных значений должны стать неудачными.
Однако эти критерии, во-первых, бесполезны на той фазе тестирования, когда определенные методы становятся непригодными, например, на фазе тестирования системы; во-вторых, такое измерение субъективно, т.к. нет гарантии, что данный специалист использовал нужную методологию правильно и точно; в-третьих, чтобы поставить цель и дать возможность выбора наиболее подходящего пути ее достижения, рассмотренные критерии предписывают использование конкретных методов, но не ставят цели.
Иногда используют критерий, основанный в значительной степени на здравом смысле и информации о количестве ошибок, полученных в процессе тестирования. Для этого строят графики зависимости количества ошибок и времени их появления. По форме полученной кривой и определяют, стоит ли продолжать тестирование или нет. На рисунке приведены примеры графиков зависимости количества ошибок от продолжительности тестирования.
Зависимость количества ошибок от продолжительности тестирования.
Из примера видно, что если время тестирования велико и с увеличением времени тестирования число ошибок растет, то, естественно, тестирование следует продолжить. Если в процессе тестирования в определенный момент наступило снижение числа выявления ошибок, если число выявленных ошибок постепенно стремится к нулю или достигло нуля, то понятно, что процесс тестирования можно завершить.
Однако этот критерий тоже недостаточно эффективен, поскольку нет никакой уверенности в том, что в последнем случае в дальнейшем не последует увеличения числа обнаруживаемых ошибок.
Возможен еще один подход к определению критерия завершения тестирования. Поскольку цель тестирования - поиск ошибок, то в качестве критерия можно выбрать некоторое заранее установленное число ошибок, соответствующее некоторой части от предполагаемого общего числа ошибок. Однако с применением этого критерия связан ряд проблем. Во-первых, необходимо оценить общее число ошибок в программе. Во-вторых, требуется выяснить, какой процент этих ошибок можно определить тестированием. И, наконец, нужно определить, какая именно часть ошибок возникла в процессе проектирования и во время каких фаз тестирования целесообразно их выявлять.
Для оценки общего числа ошибок и выявления возможного процента ошибок, который можно обнаружить тестированием, можно воспользоваться методами, применяемыми при определении показателей надежности (модели надежности), например, с помощью модели Миллса или простой интуитивной модели, которые мы рассмотрим немного позже.
Другой способ получения такой оценки основан на статических средних величинах, широко применяемых в промышленности. Например, число ошибок, которое существует в типичных программах, по времени завершения кодирования (до проведения сквозного просмотра или инспекции) составляет примерно 4 - 8 на 100 операторов программы.
Модель Миллса основывается на внесении в программу ошибок с целью оценки в ходе тестирования числа остаточных ошибок, реально содержащихся в программе. Проверяя программу в течение некоторого времени и отсортировывая внесенные ошибки от собственно находящихся в программе, можно оценить число первоначально содержащихся в программе ошибок и число ошибок, оставшихся к моменту оценки.
Если в программу внесено случайным образом S ошибок, при проверке обнаружено n+V ошибок (n – число найденных собственных ошибок; V – число найденных внесенных ошибок), то предполагаемое число первоначально находящихся в программе собственных ошибок может быть рассчитано по формуле: .
Например, при обнаружении 20 собственных и 10 привнесенных ошибок, при общем числе первоначально внесенных ошибок, равном 25, значение N=25*20/10 = 50; т.е. на данном этапе предполагается, что в программе имелось 50 собственных ошибок и тестирование должно быть продолжено.
Оценку числа N можно проводить после каждого нового обнаружения ошибок.
Программа должна отлаживаться до тех пор, пока не будут обнаружены все внесенные ошибки. В момент обнаружения внесенных ошибок можно определить уровень доверия C, указывающий вероятность того, что оценка правильна:
где k - предполагаемое число собственных ошибок, S - число внесенных ошибок, n - число обнаруженных собственных ошибок.
Например, если утверждать, что в программе нет ошибок (k=0), и при внесении в программу 6 ошибок все они были обнаружены, а собственные ошибки обнаружены не были, то C=6/(6 + 0 + 1)=0,86. С другой стороны, чтобы достичь уровня доверия в 0,98 в программу необходимо ввести 39 ошибок: C=39/(39 + 0 + 1)=0,98.
Модель Миллса не лишена ряда недостатков, самые существенные из которых - это необходимость внесения искусственных ошибок (этот процесс плохо формализуем) и достаточно вольное допущение величины k (число собственных ошибок), которое основывается исключительно на интуиции человека, проводящего оценку, т.е. допускает большое влияние субъективного фактора.
Простая интуитивная модель предполагает проведение тестирования двумя группами программистов независимо друг от друга, использующими независимые тестовые наборы.
В процессе тестирования каждая из групп фиксирует все найденные ею ошибки. При оценке числа оставшихся в программе ошибок результаты тестирования обеих групп собираются и сравниваются.
Получается, что первая группа обнаружила N 1 ошибок, вторая – N 2 ошибок, а N 12 - это ошибки, обнаруженные обеими группами.
Если обозначить через N неизвестное количество ошибок, присутствующих в программе до начала тестирования, то можно эффективность тестирования каждой из групп определить как
Предполагая, что возможность обнаружения всех ошибок одинакова для обеих групп, можно допустить, что, если первая группа обнаружила определенное количество всех ошибок, она могла бы определить то же количество любого случайным образом выбранного подмножества.
В частности, можно допустить, что
Значение N 12 известно, а E 1 и Е 2 можно определить как N 12 /N 1 и N 12 /N 2 . Таким образом, неизвестное количество ошибок в про1рамме можно определить по формуле:
Развивая эту модель и опираясь на предположения, что обе группы, проводящие тестирование, имеют равную вероятность обнаружения "общих" ошибок, ее можно рассчитать по следующей формуле:
где P(N12i) - вероятность обнаружения N 12 "общих" ошибок тестирования программы двумя независимыми группами.
Определение ошибок, возникающих в процессе проектирования, использует данные, свидетельствующие о том, что в большом ПО примерно 40% всех ошибок составляют ошибки проектирования логики и кодирования, а остальные сделаны на более ранних этапах проектирования.
Исходя из этого, рассмотрим пример. Допустим, что тестируется программа размером 1000 операторов; число ошибок, остающихся после инспекции исходного текста, оценивается в 5 на 100 операторов. Цель тестирования - обнаружить 98% ошибок кодирования и логики и 95% ошибок проектирования.
Общее число ошибок составляет 500. Предполагается, что 200 из них составляют ошибки кодирования и логики, а 300 - ошибки проектирования. Следовательно, требуется найти 196 ошибок кодирования и логики и 285 ошибок проектирования.
Из соображений здравого смысла логично так распределить процентное отношение найденных ошибок по этапам тестирования, как показано в таблице.
Процентное отношение найденных ошибок по этапам тестирования.
Исходя из этих чисел, можно определить следующие критерии.
- На этапе тестирования модулей необходимо найти и исправить 130 ошибок (65% от оцененных 200 ошибок кодирования и логики).
- На этапе тестирования системы необходимо найти и исправить 6 ошибок и 105 (3% от 200 и 35% от 300).
Другая очевидная проблема для этого вида критериев - это проблема переоценки. Что если в приведенном примере к моменту начала проверки функций остается менее 240 ошибок? Основываясь на данном критерии, завершить фазу проверки функций не удается никогда. Во избежание такой ситуации критерий числа ошибок следует дополнить промежутком времени, в течение которого они должны быть обнаружены. В этом случае, если ошибки найдены быстро, то тестирование на определенном этапе следует продолжать до завершения заданного интервала времени. Если же возникает переоценка, т.е. время прошло, а заданное количество ошибок не обнаружено, то следует пригласить незаинтересованного эксперта, который выскажет свое мнение о причинах возникновения проблемы: либо тесты не эффективны, либо тесты удачны, но в программе действительно мало ошибок.
Наилучшим критерием завершения тестирования является комбинация всех трех рассмотренных подходов. Для тестирования модулей оптимальным будет первый рассмотренный критерий, потому что в большинстве проектов на этой фазе не следят за числом обнаруженных ошибок, здесь важно, чтобы использовался определенный набор методов проектирования тестов. На фазах тестирования функций и системы критерием завершения может служить останов по достижении заданного числа обнаруженных ошибок или достижение момента, определенного графиком работ, при условии, что анализ зависимости числа ошибок от времени тестирования покажет снижение продуктивности.
Начало - половина дела. Это правило приложимо практически к любой сфере деятельности, и даже к тестированию ПО.
Зачастую в начале проекта тестировщики излучают энтузиазм, составляя документацию (стратегия тестирования, план тестирования или тест-кейсы).
Но в дальнейшем нередко возникают сложности. По завершении первого раунда тестирования, тестировщики обычно находят кучу багов, а затем подходят ко второму этапу несколько расслабленными. Имеет место т.н. человеческий фактор и общечеловеческая тенденция, когда становится скучно выполнять повторные операции.
В подобных ситуациях у многих возникает ощущение того, что они делают монотонную работу, и, как следствие, теряется интерес к продолжению тестирования уже знакомого ПО. И во время третьего, примерно, раунда над тестировщиком неумолимо нависает вопрос: «Когда же все-таки нужно прекращать тестирование?»
Каждый тестировщик хотя бы раз задавался таким вопросом, расширенная версия которого выглядела бы так:
Многие тестировщики полагают, что не существует каких-то особых условий, указывающих на то, что тестирование следует завершить. Но чтобы ответить на этот вопрос, придется проанализировать тестовую активность от начала до конца.
Допустим, стоит задача протестировать новый проект.
Начальные действия:
- Команда тестировщиков получает требования.
- Затем следует планирование и разработка.
- Подготавливается и проверяется документация по тестированию.
Тестирование, раунд #1)
Команда тестировщиков приступает к тестированию, как только ей передают только что созданный программный продукт.
На этапе тестирования тестировщики выполняют различные сценарии, пытаясь взломать ПО и обнаружить дефекты. (Поскольку приложение новое и проходит оценку впервые, показатель обнаруженных дефектов будет сравнительно высоким).
Разработчики устраняют дефекты и возвращают разработку тестировщикам для повторного теста.
Тестировщики проводят проводят проверку на предмет наличия дефектов, затем переходят к .
Как только серьезные дефекты устранены и ПО демонстрирует стабильную работу, команда разработчиков выпускает следующую версию.
Тестирование, раунд #2)
Тестировщики начинает второй раунд тестирования и повторяют то, что выполнялось во время первого раунда.
Во время этого процесса, как правило, обнаруживаются еще некоторые дефекты.
Дефекты устраняются разработчиками и приложение вновь отправляется на проверку.
Тестировщики проводят повторные тесты и регрессионное тестирование тех частей разработки, которые не претерпели изменения.
Это можно продолжать до бесконечности. Раунд 3, 4, 5… до тех пор, пока программное обеспечение совершенно не очистится от багов.
Но представляется ли теоретически возможным найти абсолютно все дефекты? Это вопрос на миллион долларов, но попробуем на него ответить.
Большинство приложений устроены сложно, оттого фронт их тестирования достаточно большой. Не то чтобы обнаружить абсолютно все дефекты совсем невозможно, но для этого понадобится вечность.
Даже после того, как большинство багов в ПО найдены, никто не сможет с уверенностью заявить, что приложение стало безупречным.
Более того, такая задача не стоит. Цель тестирование ПО - убедиться, что оно функционально и работает так, как запланировано. Достигается это за счет попыток взлома или поиска отклонений от ожидаемого поведения.
У приложений может быть бесконечное множество дефектов, и проводить до полного их устранения непрактично. Никогда не знаешь, какой из багов окажется последним.
А если «прекращение тестирования, после полного устранения дефектов» теперь не является критерием, тогда из чего же следует исходить?
Попытаемся разобраться, какие факторы следует считать наиболее важными?
Решение о прекращении тестирования обычно зависит от времени (которое есть в распоряжении), бюджета и необходимой продолжительности тестирования.
Чаще всего решение завершить тестирование принимается, когда закончилось время/бюджет, или же когда все тестовые сценарии выполнены. Но это компромиссное решение, которое может быть в ущерб качеству.
Пример
Сценарий тестирования:
Допустим, необходимо протестировать программный модуль, на эту работу выделен определенный бюджет. Время: 1 месяц. Общее количество тестовых сценариев: 200.
Сценарий #1)
Первая неделя : Вы добились успеха - в первый же день нашли дефект Show Stopper. Но тестирование остановилось на 3 дня. Проверять другие сценарии вы не можете, пока не будет устранен обнаружившийся баг. Потеряв время, вы вновь приступаете к работе.
К концу недели проверено 20 сценариев и найдено еще несколько опасных багов.
Неделя 2 : Вы начинаете тестирование, тщательно выискиваете дефекты. За вторую неделю находите несколько багов 1-го, 2-го и 3-го уровня критичности. За это время удалось проверить 70 сценариев.
Неделя 3 : К началу третьей недели все дефекты с высоким приоритетом устранены, но теперь к выполнению текущих сценариев добавляется еще и перепроверка ранее обнаруженных багов. За третью неделю вы охватили 120 сценариев, и нашли еще несколько багов. Теперь остается искать только дефекты третьего порядка.
Неделя 4 : К началу четвертой недели необходимо перепроверить дефекты и 80 оставшихся сценариев. К концу недели вы проверили 180 сценариев; все дефекты с высоким приоритетом были устранены и протестированы повторно.
Данные о проведенном тестировании помещаются в таблицу:
| Недели #1-4 |
Работа | |
| Неделя #1 |
|
|
| Неделя #2 |
|
|
| Неделя #3 |
|
|
| Неделя #4 |
|
|
Может этого уже достаточно?
Время, отведенное на тестирование, истекло. Вы нашли и устранили ряд дефектов первого уровня. Если на этом остановиться, можно ли будет считать разработанное ПО надежным? Не совсем, в силу некоторых причин:
- Сценарии проверены не все.
- Несколько потенциально опасных дефектов не тестировались ни разу.
- Все проверенные сценарии тестировались только раз.
- У ПО все еще есть дефекты.
Сценарий #2)
Неделя 1 : Вы находите дефект первого уровня в первый день тестирования. И тестирование откладывается на 3 дня. Потеряв три дня, вы вновь приступаете к работе.
К концу недели проверено 20 сценариев, найдено еще несколько опасных дефектов.
Результаты первой недели аналогичны примеру #1.
Неделя 2 : За вторую неделю вы находите несколько багов 1-го, 2-го и 3-го уровня критичности. Но теперь задача - охватить как можно больше сценариев. Как итог, 120 сценариев к концу недели.
Неделя 3 : К началу третьей недели все приоритетные дефекты устранены, и теперь, помимо текущих сценариев, необходимо перепроверить ранее обнаруженные дефекты. За третью неделю вы охватили 200 сценариев, и нашли еще ряд багов.
Теперь вы может сообщить только о дефектах второго и третьего уровня.
Данные о проведенном тестировании:
| Недели #1-3 | Работа | Результаты по истечении недели |
| Неделя #1 |
|
|
| Неделя #2 |
|
|
| Неделя #3 |
|
|
Этого достаточно?
Вы охватили полностью все сценарии тестирования, нашли еще несколько дефектов. Если на этом остановиться, можно ли будет считать ПО надежным?
Не совсем:
- Все сценарии проверялись лишь по разу.
- У ПО все еще есть дефекты.
- Регрессионное тестирование не проводилось.
Как можно видеть, оба сценария не гарантируют качества. Лучше всего в такой ситуации попытаться найти золотую середину, использовать такой подход, который бы учитывал все лучшие особенности из первого и второго сценариев. Для этого понадобится определить ряд критериев.
Критерии завершения или выхода
Критерий выхода позволяет установить, какой объем тестирования следует считать достаточным. Определяется он по завершении цикла тестирования и включается в план. Это набор условий или активностей, которые должны быть выполнены, чтобы тестирование можно было назвать законченным.
Что включает в себя критерий выхода?
В идеале это комбинация нескольких факторов, уникальных для всех проектов. Все зависит от требований конкретного проекта. Поэтому во время планирования целесообразнее подсчитать как можно больше параметров.
Ниже приведены некоторые нюансы, которые стоит учитывать во время или . Вы можете составить определенную комбинацию или же использовать все эти факторы, чтобы определить, когда именно следует завершить тестирование.
Тестирование может быть завершено когда:
- Все 100% требований учтены.
- Дефекты установлены/ожидаемое число дефектов обнаружено.
- Все дефекты, относящиеся к классу Show Stopper или Blocker, устранены, ни у одного из критических дефектов нет статуса «открытый».
- Все дефекты с высоким приоритетом идентифицированы и исправлены.
- Defect Rate (скорость дефектообразования) ниже установленного допустимого уровня.
- Очень небольшое число дефектов среднего уровня критичности «открыты», их разбор проведен.
- Число «открытых» дефектов среднего уровня, которые не влияют на пользование системой, очень небольшое.
- Все дефекты с высоким уровнем приоритета закрыты и соответствующие регрессивные сценарии успешно проведены.
Охват теста:
- Охват теста должен быть на уровне 95%.
- Pass Rate текст-кейса также должен быть 95%. Для расчета этого процентного соотношения применяется формула:
(Общее число успешных текст-кейсов / общее число тест-кейсов) * 100.
- Все критически важные тест-кейсы оказались успешными
- 5% тест-кейсов могут быть провалены, но это относится к низкоприоритетным кейсам.
- Достигнуто полное покрытие функционала.
- Все крупные функциональные дефекты успешно устранены.
Сроки:
Срок, отведенный на тестирование, истек.
Документация по тестированию:
Вся документация по тестированию, подлежащая сдаче (например, отчет о тестировании), подготовлена, проверена и передана.
Бюджет:
- Бюджет, выделенный на тестирование, полностью израсходован.
- Совещания в формате «Go / No Go» проведены, решение о релизе продукта принято.
И в заключение, пожалуйста, ответьте на несколько вопросов
Если большинство ответов окажутся утвердительными, это будет означать, что вы можете завершить тестирование. Если большинство ответов будут отрицательными, тогда придется искать, что было упущено.
- Были ли все тест-кейсы проверены по меньшей мере один раз?
- Установлен ли показатель успешности тест-кейса (Test Case Pass)?
- Достигнут ли полный охват тестирования?
- Все функциональные/бизнес «потоки» проверены как минимум раз?
- Найдено ли установленное число дефектов?
- Устранены и «закрыты» ли все дефекты с высоким приоритетом?
- Все ли дефекты прошли повторную проверку и считаются «закрытыми»?
- Регрессивное тестирование проведено для всех «открытых» дефектов?
- Закончился ли выделенный на тестирование бюджет?
- Истекли ли сроки проведения тестирования?
- Вся ли документация по тестированию проверена и опубликована?