Рубрики в студии меняются, но идиотека останется и будет жить, что бы не случилось.
Завести тоже рубрику, что-ли? Даже не знаю.
Написал сегодня несколько хотелок своему провайдеру, обещали, что ждать не больше трех рабочих дней. В прошлый раз ждал три рабочих месяца. потом узнал, что посеяли заявление. Кстати, у них на сайте тоже бага есть.
Посмотрим, что из этого всего получится.
суббота, 31 января 2009 г.
Так
Я не последний из 167 983 человек. Я последний из 167 982.
А всего нас чуть больше двух миллионов.
Немеряно.
P.S. Нашел багу на сайте тестировщиков. Странное ощущение. Бага некритичная, поберегу на память.
Кот спит.
А всего нас чуть больше двух миллионов.
Немеряно.
P.S. Нашел багу на сайте тестировщиков. Странное ощущение. Бага некритичная, поберегу на память.
Кот спит.
среда, 28 января 2009 г.
Митрополит Кирилл избран Патриархом Московским и Всея Руси
"Приближалась Пасха Иудейская, и Иисус пришел в Иерусалим и нашел, что в храме продавали волов, овец и голубей, и сидели меновщики денег. И, сделав бич из веревок, выгнал из храма всех, [также] и овец и волов; и деньги у меновщиков рассыпал, а столы их опрокинул. И сказал продающим голубей: возьмите это отсюда и дома Отца Моего не делайте домом торговли."©Ин. 2:13-16
Свои обиды Христос прощал. А когда оскорбили отца - не сдержался. А кто б сдержался?
А с другой стороны, надо же где-то покупать свечи и кресты? А может - не надо?
При чем тут Кирилл? При том, что грядут большие перемены, РПЦ станет сильнее и богаче.
А Сыну будет все так же обидно за Отца.
Кот всем своим видом как бы говорит нам, что надо верить в себя.
Свои обиды Христос прощал. А когда оскорбили отца - не сдержался. А кто б сдержался?
А с другой стороны, надо же где-то покупать свечи и кресты? А может - не надо?
При чем тут Кирилл? При том, что грядут большие перемены, РПЦ станет сильнее и богаче.
А Сыну будет все так же обидно за Отца.
Кот всем своим видом как бы говорит нам, что надо верить в себя.
вторник, 27 января 2009 г.
А не спеть ли песню
... о любви.
Подкинули мне кусочек текста.
Важнейшая тема - подарки. Подарки должны носить характер щедрого сброса обильных излишков, но не отрыванием от себя последнего куска. Миллион алых роз выглядит красиво и романтично, однако художник из одноимённой песни неспроста остался ни с чем. При всём при том, что даме было очень приятно, ведь это был знак её высокой привлекательности! Другое дело, если вы располагаете миллиардом этих роз - тогда такие выходки делать вполне можно, и даже нужно. Это вовсе не означает, что вы должны быть прижимисто-расчётливы, скорее наоборот. Но вы своим подарком должны продемонстрировать наличие у вас избыточных ресурсов, а вовсе не способность лечь костьми ради прекрасной дамы. Если вы отдали ей всё, что у вас было в подарок, и остались ни с чем, то зачем вы ей нужны, когда у вас ничего больше нет? Вам ведь нужно будет на что-то детей растить. А самопожертвенность в этом смысле ведь малоценная; даже наоборот. Поэтому принимая знаки внимания, даже разорительные, женщина как правило не чувствует себя за это чем-то обязанной.
Отсюда
Интересно, не так ли? Или не так?
Кот как бы намекает нам, что проще надо быть. Вот у котов все проще.
Подкинули мне кусочек текста.
Важнейшая тема - подарки. Подарки должны носить характер щедрого сброса обильных излишков, но не отрыванием от себя последнего куска. Миллион алых роз выглядит красиво и романтично, однако художник из одноимённой песни неспроста остался ни с чем. При всём при том, что даме было очень приятно, ведь это был знак её высокой привлекательности! Другое дело, если вы располагаете миллиардом этих роз - тогда такие выходки делать вполне можно, и даже нужно. Это вовсе не означает, что вы должны быть прижимисто-расчётливы, скорее наоборот. Но вы своим подарком должны продемонстрировать наличие у вас избыточных ресурсов, а вовсе не способность лечь костьми ради прекрасной дамы. Если вы отдали ей всё, что у вас было в подарок, и остались ни с чем, то зачем вы ей нужны, когда у вас ничего больше нет? Вам ведь нужно будет на что-то детей растить. А самопожертвенность в этом смысле ведь малоценная; даже наоборот. Поэтому принимая знаки внимания, даже разорительные, женщина как правило не чувствует себя за это чем-то обязанной.
Отсюда
Интересно, не так ли? Или не так?
Кот как бы намекает нам, что проще надо быть. Вот у котов все проще.
воскресенье, 25 января 2009 г.
Вопросы тестировщику
Еще несколько вопросов к тестировщику, ответы на которые не помешало бы мне знать.
Это к заметкам на полях.
1. Что такое приемочное тестирование (Acceptance Testing)?
2. Что такое тестирование доступности (Accessibility Testing)?
3. Что такое специальное тестирование (Ad Hoc Testing)?
4. Что такое гибкое тестирование (Agile Testing)?
5. Что такое бинарный интерфейс приложения (Application Binary Interface (ABI))?
6. Что такое программный интерфейс приложения (Application Programming Interface (API))?
7. Что такое программное обеспечение автоматизации качества (Automated Software Quality (ASQ))?
8. Что такое автоматизированное тестирование (Automated Testing)?
9. Что такое форма Бэкуса-Наура (Backus-Naur Form)?
10. Что такое базовый блок (Basic Block)?
11. Что такое тестирование базового пути (Basis Path Testing)?
12. Что такое базовый набор тестов (Basis Set)?
13. Что такое основание тестирования (Baseline)?
14. Что вы будете делать в течение первого рабочего дня?
15. Что такое бета-тестирование (Beta Testing)?
16. Что такое тестирование бинарной портативности (Binary Portability Testing)?
17. Что такое тестирование черного ящика (Black Box Testing)?
18. Что такое восходящее тестирование (Bottom Up Testing)?
19. Что такое тестирование границ (Boundary Testing)?
20. Что такое баг (Bug)?
21. Что такое дефект (Defect)?
22. Что такое анализ граничных значений (Boundary Value Analysis)?
23. Что такое тестирование ветвей (Branch Testing)?
24. Что такое широкое тестирование (Breadth Testing)?
25. Что такое компьютерные инструменты для тестирования программного обеспечения (Computer Aided Software Testing (CAST))?
26. Что такое инструментарий записи/воспроизведения (Capture/Replay Tool)?
27. Что такое модель зрелости разработки программного обеспечения (Capability Ma-turity Model (CMM))?
28. Что такое график причин и следствий (Cause Effect Graph)?
29. Что такое завершенный код (Code Complete)?
30. Что такое покрытие кода (Code Coverage)?
31. Что такое инспекция кода (Code Inspection)?
32. Что такое скозной контроль кода (Code Walkthrough)?
33. Что такое кодирование (Coding)?
34. Что такое сравнительное тестирование (Compatibility Testing)?
35. Что такое компонент (Component)?
36. Что такое компонентное тестирование (Component Testing)?
37. Что такое тестирование совместного доступа (Concurrency Testing)?
38. Что такое тестирование соответствия (Conformance Testing)?
39. Что такое тестирование управления контекстом (Context Driven Testing)?
40. Что такое тестирование преобразования (Conversion Testing)?
41. Что такое цикломатическая сложность (Cyclomatic Complexity)?
42. Что такое словарь данных (Data Dictionary)?
43. Что такое диаграмма потоков данных (Data Flow Diagram)?
44. Что такое тестирование управления данными (Data Driven Testing)?
45. Что такое отладка (Debugging)?
46. Что такое дефект (Defect)?
47. Что такое тестирование зависимости (Dependency Testing)?
48. Что такое глубокое тестирование (Depth Testing)?
49. Что такое динамическое тестирование (Dynamic Testing)?
50. Что такое эмулятор (Emulator)?
©Оригинал и перевод
Это к заметкам на полях.
1. Что такое приемочное тестирование (Acceptance Testing)?
2. Что такое тестирование доступности (Accessibility Testing)?
3. Что такое специальное тестирование (Ad Hoc Testing)?
4. Что такое гибкое тестирование (Agile Testing)?
5. Что такое бинарный интерфейс приложения (Application Binary Interface (ABI))?
6. Что такое программный интерфейс приложения (Application Programming Interface (API))?
7. Что такое программное обеспечение автоматизации качества (Automated Software Quality (ASQ))?
8. Что такое автоматизированное тестирование (Automated Testing)?
9. Что такое форма Бэкуса-Наура (Backus-Naur Form)?
10. Что такое базовый блок (Basic Block)?
11. Что такое тестирование базового пути (Basis Path Testing)?
12. Что такое базовый набор тестов (Basis Set)?
13. Что такое основание тестирования (Baseline)?
14. Что вы будете делать в течение первого рабочего дня?
15. Что такое бета-тестирование (Beta Testing)?
16. Что такое тестирование бинарной портативности (Binary Portability Testing)?
17. Что такое тестирование черного ящика (Black Box Testing)?
18. Что такое восходящее тестирование (Bottom Up Testing)?
19. Что такое тестирование границ (Boundary Testing)?
20. Что такое баг (Bug)?
21. Что такое дефект (Defect)?
22. Что такое анализ граничных значений (Boundary Value Analysis)?
23. Что такое тестирование ветвей (Branch Testing)?
24. Что такое широкое тестирование (Breadth Testing)?
25. Что такое компьютерные инструменты для тестирования программного обеспечения (Computer Aided Software Testing (CAST))?
26. Что такое инструментарий записи/воспроизведения (Capture/Replay Tool)?
27. Что такое модель зрелости разработки программного обеспечения (Capability Ma-turity Model (CMM))?
28. Что такое график причин и следствий (Cause Effect Graph)?
29. Что такое завершенный код (Code Complete)?
30. Что такое покрытие кода (Code Coverage)?
31. Что такое инспекция кода (Code Inspection)?
32. Что такое скозной контроль кода (Code Walkthrough)?
33. Что такое кодирование (Coding)?
34. Что такое сравнительное тестирование (Compatibility Testing)?
35. Что такое компонент (Component)?
36. Что такое компонентное тестирование (Component Testing)?
37. Что такое тестирование совместного доступа (Concurrency Testing)?
38. Что такое тестирование соответствия (Conformance Testing)?
39. Что такое тестирование управления контекстом (Context Driven Testing)?
40. Что такое тестирование преобразования (Conversion Testing)?
41. Что такое цикломатическая сложность (Cyclomatic Complexity)?
42. Что такое словарь данных (Data Dictionary)?
43. Что такое диаграмма потоков данных (Data Flow Diagram)?
44. Что такое тестирование управления данными (Data Driven Testing)?
45. Что такое отладка (Debugging)?
46. Что такое дефект (Defect)?
47. Что такое тестирование зависимости (Dependency Testing)?
48. Что такое глубокое тестирование (Depth Testing)?
49. Что такое динамическое тестирование (Dynamic Testing)?
50. Что такое эмулятор (Emulator)?
©Оригинал и перевод
Есть вопросы
Это к моим заметкам
Тестовые вопросы на вакансию "Тестировщик (QA)":
1. Перечислите основные цели тестирования.
2. Перечислите основные цели обеспечения качества.
3. В чем заключается принцип тестирования по методу "черного ящика"?
4. В чем заключается принцип тестирования по методу "прозрачного ящика"?
5. В чем заключается тестирование сборки?
6. Какие стратегии сборки вы знаете? Перечислите их достоинства и недостатки.
7. Какие типы ошибок позволяет обнаружить тестирование сборки?
8. В чам заключается тестирование компонентов?
9. Какие типы ошибок позволяет обнаружить тестирование компонентов?
10. В чем заключается тестирование системы?
11. Какие типы ошибок позволяет обнаружить тестирование системы?
12. Расположите тестирование компонентов, тестирование сборки и тестирование системы в том порядке, в каком эти методы применяются в жизненном цикле разработки.
13. Что такое "граничные условия"? Приведите примеры граничных условий.
14. Перечислите известные вам методы обеспечения качества.
15. Перечислите известные вам принципы организации процесса производства ПО.
16. В чем особенность "водопадной" модели организации процесса производства ПО? На каком принципе она базируется?
17. В чем особенность модели унифицированного процесса (UP) организации производства ПО? На каком принципе она базируется?
18. В чем особенность модели производства ПО? применяемой в экстремальном программировании (XP)? На каком принципе она базируется?
19. Что является основой для создания тестовых сценариев?
20. Перечислите известные вам средства автоматизации тестирования. Дайте их сравнительную характеристику.
21. Перечислите известные вам автоматизированные средства отслеживания дефектов и (или) изменений. Дайте их сравнительную характеристику.
22. Перечислите известные вам автоматизированные средства управления версиями. Дайте их сравнительную характеристику.
23. Перечислите нефункциональные характеристики программных средств (категории нефункциональных требований), которые могут быть подвергнуты тестированию. Опишите, как вы будете проводить тестирование каждой из этих характеристик.
24. Что такое "покрытие"?
25. Какие вы знаете виды покрытий?
26. Для чего используется анализ покрытия?
27. Как оценить степень покрытия?
28. Что представляет собой диаграмма переходов? Для чего она используется?
29. Что представляет собой матрица перекрестных ссылок? Для чего она используется?
30. Когда используется метод тестирования ортогональных массивов?
31. В чем заключается тестирование наследования? Для чего оно используется?
32. Для чего используются тесты категории "нет данных"?
33. Для чего используются тесты категории "повторное выполнение"?
34. Для чего используются тесты категории "верные данные"?
35. Для чего используются тесты категории "неверные данные"?
36. Для чего используются тесты категории "потери мощности"?
37. Для чего используются тесты категории "создание напряжений в системе"?
38. Для чего используются тесты категории "тестирование характеристик"?
39. Что собой представляет тестовый пример (TestCase в UP)?
40. Что собой представляет план тестирования?
©it4business.ru
Надо будет для себя ответить, сдается мне, не лишнее. Навскидку отвечу менее, чем на треть вопросов, хотя с большинство понятий знаком. Слегка, хех.
Тестовые вопросы на вакансию "Тестировщик (QA)":
1. Перечислите основные цели тестирования.
2. Перечислите основные цели обеспечения качества.
3. В чем заключается принцип тестирования по методу "черного ящика"?
4. В чем заключается принцип тестирования по методу "прозрачного ящика"?
5. В чем заключается тестирование сборки?
6. Какие стратегии сборки вы знаете? Перечислите их достоинства и недостатки.
7. Какие типы ошибок позволяет обнаружить тестирование сборки?
8. В чам заключается тестирование компонентов?
9. Какие типы ошибок позволяет обнаружить тестирование компонентов?
10. В чем заключается тестирование системы?
11. Какие типы ошибок позволяет обнаружить тестирование системы?
12. Расположите тестирование компонентов, тестирование сборки и тестирование системы в том порядке, в каком эти методы применяются в жизненном цикле разработки.
13. Что такое "граничные условия"? Приведите примеры граничных условий.
14. Перечислите известные вам методы обеспечения качества.
15. Перечислите известные вам принципы организации процесса производства ПО.
16. В чем особенность "водопадной" модели организации процесса производства ПО? На каком принципе она базируется?
17. В чем особенность модели унифицированного процесса (UP) организации производства ПО? На каком принципе она базируется?
18. В чем особенность модели производства ПО? применяемой в экстремальном программировании (XP)? На каком принципе она базируется?
19. Что является основой для создания тестовых сценариев?
20. Перечислите известные вам средства автоматизации тестирования. Дайте их сравнительную характеристику.
21. Перечислите известные вам автоматизированные средства отслеживания дефектов и (или) изменений. Дайте их сравнительную характеристику.
22. Перечислите известные вам автоматизированные средства управления версиями. Дайте их сравнительную характеристику.
23. Перечислите нефункциональные характеристики программных средств (категории нефункциональных требований), которые могут быть подвергнуты тестированию. Опишите, как вы будете проводить тестирование каждой из этих характеристик.
24. Что такое "покрытие"?
25. Какие вы знаете виды покрытий?
26. Для чего используется анализ покрытия?
27. Как оценить степень покрытия?
28. Что представляет собой диаграмма переходов? Для чего она используется?
29. Что представляет собой матрица перекрестных ссылок? Для чего она используется?
30. Когда используется метод тестирования ортогональных массивов?
31. В чем заключается тестирование наследования? Для чего оно используется?
32. Для чего используются тесты категории "нет данных"?
33. Для чего используются тесты категории "повторное выполнение"?
34. Для чего используются тесты категории "верные данные"?
35. Для чего используются тесты категории "неверные данные"?
36. Для чего используются тесты категории "потери мощности"?
37. Для чего используются тесты категории "создание напряжений в системе"?
38. Для чего используются тесты категории "тестирование характеристик"?
39. Что собой представляет тестовый пример (TestCase в UP)?
40. Что собой представляет план тестирования?
©it4business.ru
Надо будет для себя ответить, сдается мне, не лишнее. Навскидку отвечу менее, чем на треть вопросов, хотя с большинство понятий знаком. Слегка, хех.
пятница, 23 января 2009 г.
Обратно же
Сегодня окунался в прорубь. Добрая православная традиция, которой следую третий год.
Скажу пару слов в защиту горячо нелюбимого православия.
На крещение более миллиона людей окунулись в проруби в этом году. Я уверен, что их было больше пяти миллионов, но пусть – миллион.
Были сердечные приступы, был случай, когда 60 человек одновременно провалились под лед.
И ни один не умер. Напонимаю, дело происходит в России. Ни. Один. Не. Умер.
Эй, там, высоко, есть кто?
Скажу пару слов в защиту горячо нелюбимого православия.
На крещение более миллиона людей окунулись в проруби в этом году. Я уверен, что их было больше пяти миллионов, но пусть – миллион.
Были сердечные приступы, был случай, когда 60 человек одновременно провалились под лед.
И ни один не умер. Напонимаю, дело происходит в России. Ни. Один. Не. Умер.
Эй, там, высоко, есть кто?
РПЦ
"Всякое нормальное государство не может не учитывать мнение большинства своего народа."©митрополит Кирилл здесь сказал
Я лично знаком с более чем тремя сотнями людей. И, насколько мне известно, православных христиан среди нет(есть считающие себя таковыми, хех).
Ни слова против православных христиан, и даже ни слова против считающих себя таковыми.
Но вот митрополит, видимо, живет на другой планете. Ну или в другом измерении. Ведь не может же православный митрополит врать или быть дураком?
Кот, например, в бога не верит.
Я лично знаком с более чем тремя сотнями людей. И, насколько мне известно, православных христиан среди нет(есть считающие себя таковыми, хех).
Ни слова против православных христиан, и даже ни слова против считающих себя таковыми.
Но вот митрополит, видимо, живет на другой планете. Ну или в другом измерении. Ведь не может же православный митрополит врать или быть дураком?
Кот, например, в бога не верит.
четверг, 22 января 2009 г.
Люди говорят
В jabber'е 3 человека, в аське шесть.
Неужели люди перестали болтать и занялись работой, учебой, сексом?
w_bf@livejournal.com - я тут. И как обычно в icq тоже.
Ребята, давайтежить дружно перейдем на Jabber?
Или хотя бы будем писать письма. Ну не надо аськи...
И кот ждет. Очень ждет.
Неужели люди перестали болтать и занялись работой, учебой, сексом?
w_bf@livejournal.com - я тут. И как обычно в icq тоже.
Ребята, давайте
Или хотя бы будем писать письма. Ну не надо аськи...
И кот ждет. Очень ждет.
вторник, 20 января 2009 г.
Процесс тестирования
Наткнулся на несколько вопросов, которые формулируют ответы:
Установка процесса
Чтобы определить, существует ли у вас процесс тестирования в полном объеме необходимо выполнить небольшой тест. Всего шесть вопросов.
1. Есть ли у вас тестировщики (роль в проекте)?
2. Есть ли у вас сформулированная стратегия тестирования?
3. Используется ли система учета дефектов?
4. Есть ли у вас изолированное тестовое окружение?
5. Применяется ли процедура передачи новой версии программы в тестирование?
6. Есть ли у вас процедура оценки готовности программы?
Если на какой-то из вопросов вы ответили «нет», то должен вас огорчить. У вас нет процесса тестирования. Все расходы на содержание тестировщиков и траты на тестовые активности могут оказаться не эффективными. Каждый «нет» означает, что вы либо не контролируете процесс, либо не контролируете тестовое окружение, либо не контролируете работу тестировщиков, либо все вместе. Но вывод из всего этого один - вы не управляете процессом и, следовательно, уровнем качества вашего продукта.
©Гринкевич Сергей Статья написана по мотивам доклада, сделанного автором на конференции “Российские Интернет технологии 2007″ (РИТ2007) в апреле 2007 года в Москве.
Установка процесса
Чтобы определить, существует ли у вас процесс тестирования в полном объеме необходимо выполнить небольшой тест. Всего шесть вопросов.
1. Есть ли у вас тестировщики (роль в проекте)?
2. Есть ли у вас сформулированная стратегия тестирования?
3. Используется ли система учета дефектов?
4. Есть ли у вас изолированное тестовое окружение?
5. Применяется ли процедура передачи новой версии программы в тестирование?
6. Есть ли у вас процедура оценки готовности программы?
Если на какой-то из вопросов вы ответили «нет», то должен вас огорчить. У вас нет процесса тестирования. Все расходы на содержание тестировщиков и траты на тестовые активности могут оказаться не эффективными. Каждый «нет» означает, что вы либо не контролируете процесс, либо не контролируете тестовое окружение, либо не контролируете работу тестировщиков, либо все вместе. Но вывод из всего этого один - вы не управляете процессом и, следовательно, уровнем качества вашего продукта.
©Гринкевич Сергей Статья написана по мотивам доклада, сделанного автором на конференции “Российские Интернет технологии 2007″ (РИТ2007) в апреле 2007 года в Москве.
Quality Assurance Plan
Набрел на форуме на мысль, которую надо записать, а потом выполнить. Я думаю, это будет относиться к заметкам на полях.
Во-первых, поищите в инете примеры "SQA PLan" или "Software Quality Assurance Plan". Есть такой IEEE стандарт 730.
В нем они рекомендуют иметь следующие секции(на 1998год, есть редакция от 2002го):
a) Purpose;
b) Reference documents;
c) Management;
d) Documentation;
e) Standards, practices, conventions, and metrics;
f) Reviews and audits;
g) Test;
h) Problem reporting and corrective action;
i) Tools, techniques, and methodologies;
j) Code control;
k) Media control;
l) Supplier control;
m) Records collection, maintenance, and retention;
n) Training;
o) Risk management.
Итак, чтобы я посоветовал включить в документ, названый концепцией тестирования (у нас такого нет):
1. Контракт с другими командами, которые работают над проектом (разработчики, менеджемент, билд-инженеры итд). Включить в этот пункт информацию о том, чем именно ваша команда тестирования занимается(т.е. сервисы вашей команды) и чем не занимается. Например: делаем Smoke тестирование, автоматизируем тестирование GUI. Не делаем: Unit-тестирование, поддержку билд-процедуры и анализ падений билдов во время билд-процедуры. Итд Итп.
2. Критерии, начала тестирования. Т.е. условия, которые должны быть соблюденены для проекта чтобы был смысл привлекать тестеров к их деятельности. Понятно, что есть проектно-независимые критерии, например, наличие дефект-трэкера для данного проекта; хранение сырцов под системой контроля версий; регулярные (или по крайней мере нумерованные) билды и тд.
3. Критерии окончания тестирования.
4. Пропишите свои обязательства по услугам, котрые оказывает команда тестирования. Например, верификация high-priority дефектов должна проходить на том же билде, где это было починено итд.
5. Определите, порядок обращения за услугами. Оговорите, что все запросы на какое-либо тестирование должны идти через руководителя группы тестирования. Иначе может получиться так, что разработчики будут напрямую приходить к тестерам и просить что-то сделать (а они будут!), не задумываясь о том, что у каждого есть ворох задач и спланированый график их выполнения.
Сюда же можно отнести сроки, за которые желательно предупреждать о предстоящем тестировании.
6. Опишите, как вообще процесс тестирования встраивается в общий процесс разработки. На какой стадии начинается, что требуется от других команд итд.
7. Определите те проверки, которые не зависят от проекта и которые обязательно должны быть выполнены в каждом проекте. Например, проверка копирайтов вашего продукта.
8. Определите стратегию распределения ресурсов, в случае более одного проекта. В основном про людей, но и про оборудование тоже, особенно если оно какое-то уникальное.
9. Опишите что не включено в данный документ, и где это можно найти . Дайте ссылки на некоторые нормативные документы, описания процессов. Например, процесс обработки дефектов.
10. Определите виды тестирования; порядок и частоту, с которой каждый вид тестирования будет производиться. Это конечно зависит от проектов сильно, но если они у вас типичные, то можно и добавить.
11. Определите как ваша команда отчитывается перед руководством. Какие документы, когда, как и зачем должны быть предоставлены до, во время и по окончанию работы.
©LeshaL (Пост)
Во-первых, поищите в инете примеры "SQA PLan" или "Software Quality Assurance Plan". Есть такой IEEE стандарт 730.
В нем они рекомендуют иметь следующие секции(на 1998год, есть редакция от 2002го):
a) Purpose;
b) Reference documents;
c) Management;
d) Documentation;
e) Standards, practices, conventions, and metrics;
f) Reviews and audits;
g) Test;
h) Problem reporting and corrective action;
i) Tools, techniques, and methodologies;
j) Code control;
k) Media control;
l) Supplier control;
m) Records collection, maintenance, and retention;
n) Training;
o) Risk management.
Итак, чтобы я посоветовал включить в документ, названый концепцией тестирования (у нас такого нет):
1. Контракт с другими командами, которые работают над проектом (разработчики, менеджемент, билд-инженеры итд). Включить в этот пункт информацию о том, чем именно ваша команда тестирования занимается(т.е. сервисы вашей команды) и чем не занимается. Например: делаем Smoke тестирование, автоматизируем тестирование GUI. Не делаем: Unit-тестирование, поддержку билд-процедуры и анализ падений билдов во время билд-процедуры. Итд Итп.
2. Критерии, начала тестирования. Т.е. условия, которые должны быть соблюденены для проекта чтобы был смысл привлекать тестеров к их деятельности. Понятно, что есть проектно-независимые критерии, например, наличие дефект-трэкера для данного проекта; хранение сырцов под системой контроля версий; регулярные (или по крайней мере нумерованные) билды и тд.
3. Критерии окончания тестирования.
4. Пропишите свои обязательства по услугам, котрые оказывает команда тестирования. Например, верификация high-priority дефектов должна проходить на том же билде, где это было починено итд.
5. Определите, порядок обращения за услугами. Оговорите, что все запросы на какое-либо тестирование должны идти через руководителя группы тестирования. Иначе может получиться так, что разработчики будут напрямую приходить к тестерам и просить что-то сделать (а они будут!), не задумываясь о том, что у каждого есть ворох задач и спланированый график их выполнения.
Сюда же можно отнести сроки, за которые желательно предупреждать о предстоящем тестировании.
6. Опишите, как вообще процесс тестирования встраивается в общий процесс разработки. На какой стадии начинается, что требуется от других команд итд.
7. Определите те проверки, которые не зависят от проекта и которые обязательно должны быть выполнены в каждом проекте. Например, проверка копирайтов вашего продукта.
8. Определите стратегию распределения ресурсов, в случае более одного проекта. В основном про людей, но и про оборудование тоже, особенно если оно какое-то уникальное.
9. Опишите что не включено в данный документ, и где это можно найти . Дайте ссылки на некоторые нормативные документы, описания процессов. Например, процесс обработки дефектов.
10. Определите виды тестирования; порядок и частоту, с которой каждый вид тестирования будет производиться. Это конечно зависит от проектов сильно, но если они у вас типичные, то можно и добавить.
11. Определите как ваша команда отчитывается перед руководством. Какие документы, когда, как и зачем должны быть предоставлены до, во время и по окончанию работы.
©LeshaL (Пост)
воскресенье, 18 января 2009 г.
Регрессионное тестирование
Очередное продолжение заметок на полях.
При корректировках программы необходимо гарантировать сохранение качества. Для этого используется регрессионное тестирование - дорогостоящая, но необходимая деятельность в рамках этапа сопровождения, направленная на перепроверку корректности измененной программы. В соответствии со стандартным определением, регрессионное тестирование - это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов, или что измененная система по-прежнему соответствует требованиям.
Главной задачей этапа сопровождения является реализация систематического процесса обработки изменений в коде. После каждой модификации программы необходимо удостовериться, что на функциональность программы не оказал влияния модифицированный код. Если такое влияние обнаружено, говорят о регрессионном дефекте. Для регрессионного тестирования функциональных возможностей, изменение которых не планировалось, используются ранее разработанные тесты. Одна из целей регрессионного тестирования состоит в том, чтобы, в соответствии с используемым критерием покрытия кода (например, критерием покрытия потока операторов или потока данных), гарантировать тот же уровень покрытия, что и при полном повторном тестировании программы. Для этого необходимо запускать тесты, относящиеся к измененным областям кода или функциональным возможностям.
Другая цель регрессионного тестирования состоит в том, чтобы удостовериться, что программа функционирует в соответствии со своей спецификацией, и что изменения не привели к внесению новых ошибок в ранее протестированный код. Эта цель всегда может быть достигнута повторным выполнением всех тестов регрессионного набора, но более перспективно отсеивать тесты, на которых выходные данные модифицированной и старой программы не могут различаться.
Важной задачей регрессионного тестирования является также уменьшение стоимости и сокращение времени выполнения тестов.
Виды регрессионного тестирования
Поскольку регрессионное тестирование представляет собой повторное проведение цикла обычного тестирования, виды регрессионного тестирования совпадают с видами обычного тестирования. Можно говорить, например, о модульном регрессионном тестировании или о функциональном регрессионном тестировании.
Другой способ классификации видов регрессионного тестирования связывает их с типами сопровождения, которые, в свою очередь, определяются типами модификаций. Выделяют три типа сопровождения:
• Корректирующее сопровождение, называемое обычно исправлением ошибок, выполняется в ответ на обнаружение ошибки, не требующей изменения спецификации требований. При корректирующем сопровождении производится диагностика и корректировка дефектов в программном обеспечении с целью поддержания системы в работоспособном состоянии.
• Адаптивное сопровождение осуществляется в ответ на требования изменения данных или среды исполнения. Оно применяется, когда существующая система улучшается или расширяется, а спецификация требований изменяется с целью реализации новых функций.
• Усовершенствующее (прогрессивное) сопровождение включает любую обработку с целью повышения эффективности работы системы или эффективности ее сопровождения.
В процессе адаптивного или усовершенствующего сопровождения обычно вводятся новые модули. Чтобы отобразить то или иное усовершенствование или адаптацию, изменяется спецификация системы. При корректирующем сопровождении, как правило, спецификация не изменяется, и новые модули не вводятся. Модификация программы на фазе разработки подобна модификации при корректирующем сопровождении, так как из-за обнаружения ошибки вряд ли требуется менять спецификацию программы. За исключением редких моментов крупных изменений, на фазе сопровождения изменения системы обычно невелики и производятся с целью устранения проблем или постепенного расширения функциональных возможностей
Соответственно, определяют два типа регрессионного тестирования: прогрессивное и корректирующее.
• Прогрессивное регрессионное тестирование предполагает модификацию технического задания. В большинстве случаев при этом к системе программного обеспечения добавляются новые модули.
• При корректирующем регрессионном тестировании техническое задание не изменяется. Модифицируются только некоторые операторы программы и, возможно, конструкторские решения.
Прогрессивное регрессионное тестирование обычно выполняется после адаптивного или усовершенствующего сопровождения, тогда как корректирующее регрессионное тестирование выполняется во время тестирования в цикле разработки и после корректирующего сопровождения, то есть после того, как над программным обеспечением были выполнены некоторые корректирующие действия. Вообще говоря, корректирующее регрессионное тестирование должно быть более простым, чем прогрессивное регрессионное тестирование, поскольку допускает повторное использование большего количества тестов.
Подход к отбору регрессионных тестов может быть активным или консервативным. Активный подход во главу угла ставит уменьшение объема регрессионного тестирования и пренебрегает риском пропустить дефекты. Активный подход применяется для тестирования систем с высокой исходной надежностью, а также в случаях, когда эффект изменений невелик. Консервативный подход требует отбора всех тестов, которые с ненулевой вероятностью могут обнаруживать дефекты. Этот подход позволяет обнаруживать большее количество ошибок, но приводит к созданию более обширных наборов регрессионных тестов.
Управляемое регрессионное тестирование
Для обеспечения управляемости регрессионного тестирования необходимо выполнение ряда условий:
• Как при модульном, так и при интеграционном регрессионном тестировании в качестве модулей, вызываемых тестируемым модулем непосредственно или косвенно, должны использоваться реальные модули системы. Это легко осуществить, поскольку на этапе регрессионного тестирования все модули доступны в завершенном виде.
• Информация об изменениях корректна. Информация об изменениях указывает на измененные модули и разделы спецификации требований, не подразумевая при этом корректность самих изменений. Кроме того, при изменении спецификации требований необходимо усиленное регрессионное тестирование изменившихся функций этой спецификации, а также всех функций, которые могли быть затронуты по неосторожности. Единственным случаем когда мы вынуждены положиться на правильность измененного технического задания, является изменение технического задания для всей системы или для модуля верхнего (в графе вызовов) уровня, при условии, что кроме технического задания, не существует никакой дополнительной документации и/или какой-либо другой информации, по которой можно было бы судить об ошибке в техническом задании.
• В программе нет ошибок, кроме тех, которые могли возникнуть из-за ее изменения.
• Тесты, применявшиеся для тестирования предыдущих версий программного продукта, доступны, при этом протокол прогона тестов состоит из входных данных, выходных данных и траектории. Траектория представляет собой путь в управляющем графе программы, прохождение которого вызывается использованием некоторого набора входных данных. Ее можно применять для оценки структурного покрытия, обеспечиваемого набором тестов.
• Для проведения регрессионного тестирования с использованием существующего набора тестов необходимо хранить информацию о результатах выполнения тестов на предыдущих этапах тестирования.
Обоснование корректности метода отбора тестов
• Некоторые участки кода программы не получают управление при выполнении некоторых тестов.
• Если участок кода реализует требование, но измененный фрагмент кода не получает управления при выполнении теста, то он и не может воздействовать на значения выходных данных программы при выполнении данного теста.
• Даже если участок кода, реализующий требование, получает управление при выполнении теста, это далеко не всегда отражается на выходных данных программы при выполнении данного теста. Действительно, если изменяется первый блок программы, например, путем добавления инициализации переменной, все пути в программе также изменяются, и, как следствие, требуют повторного тестирования. Однако может так случиться, что только на небольшом подмножестве путей действительно используется эта инициализированная переменная.
• Не каждый тест, проверяющий код, находящийся на одном пути с измененным кодом, обязательно покрывает этот измененный код.
• Код, находящийся на одном пути с измененным кодом, может не воздействовать на значения выходных данных измененных модулей программы.
• Не всегда каждый оператор программы воздействует на каждый элемент ее выходных данных
Классификация тестов при отборе
Создание наборов регрессионных тестов рекомендуется начинать с множества исходных тестов. При заданном критерии регрессионного тестирования все исходные тесты подразделяются на три подмножества:
• Множество тестов, пригодных для повторного использования. Это тесты, которые уже запускались и пригодны к использованию, но затрагивают только покрываемые элементы программы, не претерпевшие изменений. При повторном выполнении выходные данные таких тестов совпадут с выходными данными, полученными на исходной программе. Следовательно, такие тесты не требуют перезапуска.
• Множество тестов, требующих повторного запуска. К ним относятся тесты, которые уже запускались, но требуют перезапуска, поскольку затрагивают, по крайней мере, один измененный покрываемый элемент, подлежащий повторному тестированию. При повторном выполнении такие тесты могут давать результат, отличный от результата, показанного на исходной программе. Множество тестов, требующих повторного запуска, обеспечивает хорошее покрытие структурных элементов даже при наличии новых функциональных возможностей.
• Множество устаревших тестов. Это тесты, более не применимые к измененной программе и непригодные для дальнейшего тестирования, поскольку они затрагивают только покрываемые элементы, которые были удалены при изменении программы. Их можно удалить из набора регрессионных тестов.
• Новые тесты, которые еще не запускались и могут быть использованы для тестирования.
Классификация тестов по отношению к изменениям в коде требует анализа последствий изменений. Тесты, активирующие код, затронутый изменениями, могут требовать повторного запуска или оказаться устаревшими. Чтобы тест был включен в класс тестов, требующих повторного запуска, он должен быть затронут изменениями в коде, а также должен способствовать увеличению степени покрытия измененного кода по используемому критерию. Затронутым элементом теста может быть траектория, выходные значения, или и то, и другое. Чтобы тест был включен в класс тестов, пригодных для повторного использования, он должен вносить вклад в увеличение степени покрытия кода и не требовать повторного запуска.
Степень покрытия кода определяется для тестов, пригодных для повторного использования, поскольку к этому классу относятся тесты, не требующие повторного запуска и способствующие увеличению степени покрытия до желаемой величины. Если имеется компонент программы, не задействованный пригодными для повторного использования тестами, то вместо них выбираются и выполняются с целью увеличения степени покрытия тесты, требующие повторного запуска. После запуска такой тест становится пригодным для повторного использования или устаревшим. Если тестов, требующих повторного запуска, больше не осталось, а необходимая степень покрытия кода еще не достигнута, порождаются дополнительные тесты и тестирование повторяется.
Окончательный набор тестов собирается из тестов, пригодных для повторного использования, тестов, требующих повторного запуска, и новых тестов. Наконец, устаревшие и избыточные тесты удаляются из набора тестов, поскольку избыточные тесты не проверяют новые функциональные возможности и не увеличивают покрытие.
Возможности повторного использования тестов
К изменению существующих тестов могут привести три следующих вида деятельности программистов:
• Создание новых тестов.
• Выполнение тестов.
• Изменение кода.
Поскольку каждый тест содержит входные данные, выходные данные и траекторию, эти компоненты могут подвергнуться изменению в любой комбинации. При изменении входных данных существующего теста будем считать, что старый тест прекращает существование, и создается новый тест. Таким образом, к числу разрешенных изменений теста относятся всевозможные пертурбации выходных данных или траекторий. Изменение выходных данных без изменения траектории и/или входных данных невозможно. Следовательно, существует только два возможных варианта изменения теста: изменение траектории или изменение траектории и выходных данных.
В соответствии с приведенными выше рассуждениями можно выделить четыре уровня повторного использования теста:
• Уровень 1. Тест не допускает повторного использования. Требуется создание нового набора тестов (например, путем удаления или изменения этого теста).
• Уровень 2. Повторное использование возможно только входных данных теста. Во многих случаях цель тестирования состоит в активизации некоторых покрываемых элементов программы. Если из траектории существующего теста видно, что элементы программы, подлежащие покрытию, задействуются до измененных команд, входные данные теста могут быть использованы повторно для покрытия этих элементов. В результате изменений в программе и/или техническом задании новая траектория и выходные данные теста могут отличаться от результатов предыдущего выполнения. Таким образом, тесты первого уровня должны быть запущены повторно для получения новых выходных данных и траекторий.
• Уровень 3. Возможно повторное использование как входных, так и выходных данных теста. Очевидно, что на этом уровне обычно располагаются функциональные тесты. Если модуль подвергся только изменению кода с сохранением функциональности, возможно повторное использование существующих функциональных тестов для проверки правильности реализации. Поскольку траектория может измениться, а выходные данные - подвергнуться воздействию со стороны изменений кода, такие тесты должны быть запущены повторно, но ожидается получение идентичных результатов.
• Уровень 4. Наивысший уровень повторного использования теста, предусматривающий повторное использование входных данных, выходных данных и траектории теста. В этом случае на траектории теста не изменяется ни один оператор. Следовательно, в повторном запуске этих тестов необходимости нет, так как выходные данные и траектория останутся неизменными.
Классификация выборочных методов
Для проверки корректности различных подходов к регрессионному тестированию используется модель оценки методов регрессионного тестирования. Основными объектами рассмотрения стали полнота, точность, эффективность и универсальность.
• Полнота
• Точность
• Эффективность
• Универсальность
©www.intuit.ru
При корректировках программы необходимо гарантировать сохранение качества. Для этого используется регрессионное тестирование - дорогостоящая, но необходимая деятельность в рамках этапа сопровождения, направленная на перепроверку корректности измененной программы. В соответствии со стандартным определением, регрессионное тестирование - это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов, или что измененная система по-прежнему соответствует требованиям.
Главной задачей этапа сопровождения является реализация систематического процесса обработки изменений в коде. После каждой модификации программы необходимо удостовериться, что на функциональность программы не оказал влияния модифицированный код. Если такое влияние обнаружено, говорят о регрессионном дефекте. Для регрессионного тестирования функциональных возможностей, изменение которых не планировалось, используются ранее разработанные тесты. Одна из целей регрессионного тестирования состоит в том, чтобы, в соответствии с используемым критерием покрытия кода (например, критерием покрытия потока операторов или потока данных), гарантировать тот же уровень покрытия, что и при полном повторном тестировании программы. Для этого необходимо запускать тесты, относящиеся к измененным областям кода или функциональным возможностям.
Другая цель регрессионного тестирования состоит в том, чтобы удостовериться, что программа функционирует в соответствии со своей спецификацией, и что изменения не привели к внесению новых ошибок в ранее протестированный код. Эта цель всегда может быть достигнута повторным выполнением всех тестов регрессионного набора, но более перспективно отсеивать тесты, на которых выходные данные модифицированной и старой программы не могут различаться.
Важной задачей регрессионного тестирования является также уменьшение стоимости и сокращение времени выполнения тестов.
Виды регрессионного тестирования
Поскольку регрессионное тестирование представляет собой повторное проведение цикла обычного тестирования, виды регрессионного тестирования совпадают с видами обычного тестирования. Можно говорить, например, о модульном регрессионном тестировании или о функциональном регрессионном тестировании.
Другой способ классификации видов регрессионного тестирования связывает их с типами сопровождения, которые, в свою очередь, определяются типами модификаций. Выделяют три типа сопровождения:
• Корректирующее сопровождение, называемое обычно исправлением ошибок, выполняется в ответ на обнаружение ошибки, не требующей изменения спецификации требований. При корректирующем сопровождении производится диагностика и корректировка дефектов в программном обеспечении с целью поддержания системы в работоспособном состоянии.
• Адаптивное сопровождение осуществляется в ответ на требования изменения данных или среды исполнения. Оно применяется, когда существующая система улучшается или расширяется, а спецификация требований изменяется с целью реализации новых функций.
• Усовершенствующее (прогрессивное) сопровождение включает любую обработку с целью повышения эффективности работы системы или эффективности ее сопровождения.
В процессе адаптивного или усовершенствующего сопровождения обычно вводятся новые модули. Чтобы отобразить то или иное усовершенствование или адаптацию, изменяется спецификация системы. При корректирующем сопровождении, как правило, спецификация не изменяется, и новые модули не вводятся. Модификация программы на фазе разработки подобна модификации при корректирующем сопровождении, так как из-за обнаружения ошибки вряд ли требуется менять спецификацию программы. За исключением редких моментов крупных изменений, на фазе сопровождения изменения системы обычно невелики и производятся с целью устранения проблем или постепенного расширения функциональных возможностей
Соответственно, определяют два типа регрессионного тестирования: прогрессивное и корректирующее.
• Прогрессивное регрессионное тестирование предполагает модификацию технического задания. В большинстве случаев при этом к системе программного обеспечения добавляются новые модули.
• При корректирующем регрессионном тестировании техническое задание не изменяется. Модифицируются только некоторые операторы программы и, возможно, конструкторские решения.
Прогрессивное регрессионное тестирование обычно выполняется после адаптивного или усовершенствующего сопровождения, тогда как корректирующее регрессионное тестирование выполняется во время тестирования в цикле разработки и после корректирующего сопровождения, то есть после того, как над программным обеспечением были выполнены некоторые корректирующие действия. Вообще говоря, корректирующее регрессионное тестирование должно быть более простым, чем прогрессивное регрессионное тестирование, поскольку допускает повторное использование большего количества тестов.
Подход к отбору регрессионных тестов может быть активным или консервативным. Активный подход во главу угла ставит уменьшение объема регрессионного тестирования и пренебрегает риском пропустить дефекты. Активный подход применяется для тестирования систем с высокой исходной надежностью, а также в случаях, когда эффект изменений невелик. Консервативный подход требует отбора всех тестов, которые с ненулевой вероятностью могут обнаруживать дефекты. Этот подход позволяет обнаруживать большее количество ошибок, но приводит к созданию более обширных наборов регрессионных тестов.
Управляемое регрессионное тестирование
Для обеспечения управляемости регрессионного тестирования необходимо выполнение ряда условий:
• Как при модульном, так и при интеграционном регрессионном тестировании в качестве модулей, вызываемых тестируемым модулем непосредственно или косвенно, должны использоваться реальные модули системы. Это легко осуществить, поскольку на этапе регрессионного тестирования все модули доступны в завершенном виде.
• Информация об изменениях корректна. Информация об изменениях указывает на измененные модули и разделы спецификации требований, не подразумевая при этом корректность самих изменений. Кроме того, при изменении спецификации требований необходимо усиленное регрессионное тестирование изменившихся функций этой спецификации, а также всех функций, которые могли быть затронуты по неосторожности. Единственным случаем когда мы вынуждены положиться на правильность измененного технического задания, является изменение технического задания для всей системы или для модуля верхнего (в графе вызовов) уровня, при условии, что кроме технического задания, не существует никакой дополнительной документации и/или какой-либо другой информации, по которой можно было бы судить об ошибке в техническом задании.
• В программе нет ошибок, кроме тех, которые могли возникнуть из-за ее изменения.
• Тесты, применявшиеся для тестирования предыдущих версий программного продукта, доступны, при этом протокол прогона тестов состоит из входных данных, выходных данных и траектории. Траектория представляет собой путь в управляющем графе программы, прохождение которого вызывается использованием некоторого набора входных данных. Ее можно применять для оценки структурного покрытия, обеспечиваемого набором тестов.
• Для проведения регрессионного тестирования с использованием существующего набора тестов необходимо хранить информацию о результатах выполнения тестов на предыдущих этапах тестирования.
Обоснование корректности метода отбора тестов
• Некоторые участки кода программы не получают управление при выполнении некоторых тестов.
• Если участок кода реализует требование, но измененный фрагмент кода не получает управления при выполнении теста, то он и не может воздействовать на значения выходных данных программы при выполнении данного теста.
• Даже если участок кода, реализующий требование, получает управление при выполнении теста, это далеко не всегда отражается на выходных данных программы при выполнении данного теста. Действительно, если изменяется первый блок программы, например, путем добавления инициализации переменной, все пути в программе также изменяются, и, как следствие, требуют повторного тестирования. Однако может так случиться, что только на небольшом подмножестве путей действительно используется эта инициализированная переменная.
• Не каждый тест, проверяющий код, находящийся на одном пути с измененным кодом, обязательно покрывает этот измененный код.
• Код, находящийся на одном пути с измененным кодом, может не воздействовать на значения выходных данных измененных модулей программы.
• Не всегда каждый оператор программы воздействует на каждый элемент ее выходных данных
Классификация тестов при отборе
Создание наборов регрессионных тестов рекомендуется начинать с множества исходных тестов. При заданном критерии регрессионного тестирования все исходные тесты подразделяются на три подмножества:
• Множество тестов, пригодных для повторного использования. Это тесты, которые уже запускались и пригодны к использованию, но затрагивают только покрываемые элементы программы, не претерпевшие изменений. При повторном выполнении выходные данные таких тестов совпадут с выходными данными, полученными на исходной программе. Следовательно, такие тесты не требуют перезапуска.
• Множество тестов, требующих повторного запуска. К ним относятся тесты, которые уже запускались, но требуют перезапуска, поскольку затрагивают, по крайней мере, один измененный покрываемый элемент, подлежащий повторному тестированию. При повторном выполнении такие тесты могут давать результат, отличный от результата, показанного на исходной программе. Множество тестов, требующих повторного запуска, обеспечивает хорошее покрытие структурных элементов даже при наличии новых функциональных возможностей.
• Множество устаревших тестов. Это тесты, более не применимые к измененной программе и непригодные для дальнейшего тестирования, поскольку они затрагивают только покрываемые элементы, которые были удалены при изменении программы. Их можно удалить из набора регрессионных тестов.
• Новые тесты, которые еще не запускались и могут быть использованы для тестирования.
Классификация тестов по отношению к изменениям в коде требует анализа последствий изменений. Тесты, активирующие код, затронутый изменениями, могут требовать повторного запуска или оказаться устаревшими. Чтобы тест был включен в класс тестов, требующих повторного запуска, он должен быть затронут изменениями в коде, а также должен способствовать увеличению степени покрытия измененного кода по используемому критерию. Затронутым элементом теста может быть траектория, выходные значения, или и то, и другое. Чтобы тест был включен в класс тестов, пригодных для повторного использования, он должен вносить вклад в увеличение степени покрытия кода и не требовать повторного запуска.
Степень покрытия кода определяется для тестов, пригодных для повторного использования, поскольку к этому классу относятся тесты, не требующие повторного запуска и способствующие увеличению степени покрытия до желаемой величины. Если имеется компонент программы, не задействованный пригодными для повторного использования тестами, то вместо них выбираются и выполняются с целью увеличения степени покрытия тесты, требующие повторного запуска. После запуска такой тест становится пригодным для повторного использования или устаревшим. Если тестов, требующих повторного запуска, больше не осталось, а необходимая степень покрытия кода еще не достигнута, порождаются дополнительные тесты и тестирование повторяется.
Окончательный набор тестов собирается из тестов, пригодных для повторного использования, тестов, требующих повторного запуска, и новых тестов. Наконец, устаревшие и избыточные тесты удаляются из набора тестов, поскольку избыточные тесты не проверяют новые функциональные возможности и не увеличивают покрытие.
Возможности повторного использования тестов
К изменению существующих тестов могут привести три следующих вида деятельности программистов:
• Создание новых тестов.
• Выполнение тестов.
• Изменение кода.
Поскольку каждый тест содержит входные данные, выходные данные и траекторию, эти компоненты могут подвергнуться изменению в любой комбинации. При изменении входных данных существующего теста будем считать, что старый тест прекращает существование, и создается новый тест. Таким образом, к числу разрешенных изменений теста относятся всевозможные пертурбации выходных данных или траекторий. Изменение выходных данных без изменения траектории и/или входных данных невозможно. Следовательно, существует только два возможных варианта изменения теста: изменение траектории или изменение траектории и выходных данных.
В соответствии с приведенными выше рассуждениями можно выделить четыре уровня повторного использования теста:
• Уровень 1. Тест не допускает повторного использования. Требуется создание нового набора тестов (например, путем удаления или изменения этого теста).
• Уровень 2. Повторное использование возможно только входных данных теста. Во многих случаях цель тестирования состоит в активизации некоторых покрываемых элементов программы. Если из траектории существующего теста видно, что элементы программы, подлежащие покрытию, задействуются до измененных команд, входные данные теста могут быть использованы повторно для покрытия этих элементов. В результате изменений в программе и/или техническом задании новая траектория и выходные данные теста могут отличаться от результатов предыдущего выполнения. Таким образом, тесты первого уровня должны быть запущены повторно для получения новых выходных данных и траекторий.
• Уровень 3. Возможно повторное использование как входных, так и выходных данных теста. Очевидно, что на этом уровне обычно располагаются функциональные тесты. Если модуль подвергся только изменению кода с сохранением функциональности, возможно повторное использование существующих функциональных тестов для проверки правильности реализации. Поскольку траектория может измениться, а выходные данные - подвергнуться воздействию со стороны изменений кода, такие тесты должны быть запущены повторно, но ожидается получение идентичных результатов.
• Уровень 4. Наивысший уровень повторного использования теста, предусматривающий повторное использование входных данных, выходных данных и траектории теста. В этом случае на траектории теста не изменяется ни один оператор. Следовательно, в повторном запуске этих тестов необходимости нет, так как выходные данные и траектория останутся неизменными.
Классификация выборочных методов
Для проверки корректности различных подходов к регрессионному тестированию используется модель оценки методов регрессионного тестирования. Основными объектами рассмотрения стали полнота, точность, эффективность и универсальность.
• Полнота
• Точность
• Эффективность
• Универсальность
©www.intuit.ru
Красиво...
суббота, 17 января 2009 г.
Однако же
Я почти не помню книгу, я смотрю фильм.
Ребята, по фильму мне больше импонирует идеология Пожарского, нежели Фандорина.
На стороне Фандорина честь. Нет, даже Честь.
А Пожарский прав и эффективен, предельно эффективен.
Он сдил. Летели непозволительные щепки. Затронуты личные интересы.
Но в той реальности он больше помог России.
Ребята, по фильму мне больше импонирует идеология Пожарского, нежели Фандорина.
На стороне Фандорина честь. Нет, даже Честь.
А Пожарский прав и эффективен, предельно эффективен.
Он сдил. Летели непозволительные щепки. Затронуты личные интересы.
Но в той реальности он больше помог России.
Так
Это великолепное прощание более чем столетней давности:
"Честь имею".
Читал одноименную книгу. У героя книги была честь, я так считаю.
"Честь имею".
Читал одноименную книгу. У героя книги была честь, я так считаю.
пятница, 16 января 2009 г.
Вот возник вопрос
"единственная перспектива у продвинутого парня в этой стране — работать клоуном у пидарасов ... альтернатива - пидарасом у клоунов"
©Пелевин "Empire V"
Вы согласны с утверждением? И если хоть чуть чуть согласны - не испугаетесь сказать кто вы?
©Пелевин "Empire V"
Вы согласны с утверждением? И если хоть чуть чуть согласны - не испугаетесь сказать кто вы?
четверг, 15 января 2009 г.
Рутина
На новой работе в срочном, но размеренном порядке изучаю все, что пока еще не знаю, но очень хочу знать.
Интересных проектов - море, возможности - для моего уровня - почти безграничны.
Все инструменты к моим услугам.
Ощущаю себя торпедным катером, на который установили батарею 150мм орудий, систему запуска межконтинентальных ракет, вместо мины установили небольшой ядерный заряд, сзади на барже присобачили атомный двигатель и до кучи навесили пару десятков ракет земля-воздух.
Дали право барражировать у берегов потенциального противника, самостоятельно вести переговоры. Только перед объявлением войны посоветоваться с президентом. А капитан катера думал, что это будет учебная тревога и патрулирование бухты.
Как-то так.
P.S. Что за зверь TFS? Посмотрим...
Кот тоже правильно смотрит на будущее. Да, кот, мы бахнем, мы обязательно по ним бахнем.
Интересных проектов - море, возможности - для моего уровня - почти безграничны.
Все инструменты к моим услугам.
Ощущаю себя торпедным катером, на который установили батарею 150мм орудий, систему запуска межконтинентальных ракет, вместо мины установили небольшой ядерный заряд, сзади на барже присобачили атомный двигатель и до кучи навесили пару десятков ракет земля-воздух.
Дали право барражировать у берегов потенциального противника, самостоятельно вести переговоры. Только перед объявлением войны посоветоваться с президентом. А капитан катера думал, что это будет учебная тревога и патрулирование бухты.
Как-то так.
P.S. Что за зверь TFS? Посмотрим...
Кот тоже правильно смотрит на будущее. Да, кот, мы бахнем, мы обязательно по ним бахнем.
Читаю книжку Романа Савина
И цитирую:
010 nothing is set in stone
011 тестировщикам большую часть заработной платы платят за честность
012 спецификация — это инструмент, с помощью которого вы сможете выпустить качественный продукт и прикрыть свою спину (в оригинале звучит как CYA или cover your ass)
013 у тестировщика больше прав, чем он думает. И вообще это не права, а обязанности
014 юнит тестирование – обязанность программиста
015 как показывает опыт, совместный выезд для игры в пейнтбол раз в месяц гораздо эффективнее для сплочения коллектива, чем совместная проспиртовка мозгов во время пятничных застолий
016 на каждый баг, для которого был произведен патч-релиз, должен быть написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе тест-кейсов для регрессивного тестирования соответствующей функциональности
017 software has bugs
018 тестировщик не занимается поиском доказательств того, что ПО
работает
019 "it's not a bug, it's a feature"
010 nothing is set in stone
011 тестировщикам большую часть заработной платы платят за честность
012 спецификация — это инструмент, с помощью которого вы сможете выпустить качественный продукт и прикрыть свою спину (в оригинале звучит как CYA или cover your ass)
013 у тестировщика больше прав, чем он думает. И вообще это не права, а обязанности
014 юнит тестирование – обязанность программиста
015 как показывает опыт, совместный выезд для игры в пейнтбол раз в месяц гораздо эффективнее для сплочения коллектива, чем совместная проспиртовка мозгов во время пятничных застолий
016 на каждый баг, для которого был произведен патч-релиз, должен быть написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе тест-кейсов для регрессивного тестирования соответствующей функциональности
017 software has bugs
018 тестировщик не занимается поиском доказательств того, что ПО
работает
019 "it's not a bug, it's a feature"
вторник, 13 января 2009 г.
Довументирование и оценка качества тестирования
Заметки на полях о тестировании.
Описание тестов
Описание тестов разрабатывается для облегчения анализа и поддержки тестового набора. Описание может быть реализовано в произвольной форме, но при этом должны выполнять следующие задачи:
1. Анализировать степень покрытия продукта тестами на основании описания тестового набора.
2. Для любой функции тестируемого продукта найти тесты, в которых функция используется.
3. Для любого теста определить все функции и их сочетания, которые данный тест использует (затрагивает).
4. Понять структуру и взаимосвязи тестовых файлов.
5. Понять принцип построения системы автоматизации тестирования.
Документирование и жизненный цикл дефекта
Каждый дефект, обнаруженный в процессе тестирования, должен быть задокументирован и отслежен. При обнаружении нового дефекта его заносят в базу дефектов. Для этого лучше всего использовать специализированные базы, поддерживающие хранение и отслеживание дефектов - типа DDTS . При занесении нового дефекта рекомендуется указывать, как минимум, следующую информацию:
1. Наименование подсистемы, в которой обнаружен дефект.
2. Версия продукта (номер build ), на котором дефект был найден.
3. Описание дефекта.
4. Описание процедуры (шагов, необходимых для воспроизведения дефекта).
5. Номер теста, на котором дефект был обнаружен.
6. Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.
Занесенный в базу дефектов новый дефект находится в состоянии "New" . После того, как команда разработчиков проанализирует дефект, он переводится в состояние "Open" с указанием конкретного разработчика, ответственного за исправление дефекта. После исправления дефект переводится разработчиком в состояние "Resolved". При этом разработчик должен указать следующую информацию:
1. Причину возникновения дефекта.
2. Место исправления, как минимум, с точностью до исправленного файла.
3. Краткое описание того, что было исправлено.
4. Время, затраченное на исправление.
После этого тестировщик проверяет, действительно ли дефект был исправлен и если это так, переводит его в состояние "Verified". Если тестировщик не подтвердит факт исправления дефекта, то состояние дефекта изменяется снова на "Open".
Если проектная команда принимает решение о том, что некоторый дефект исправляться не будет, то такой дефект переводится в состояние "Postponed" с указанием лиц, ответственных за это решение, и причин его принятия.
Тестовый отчет
Тестовый отчет обновляется после каждого цикла тестирования и должен содержать следующую информацию для каждого цикла:
1. Перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему.
2. Количество выполненных тестов – запланированное и реально исполненное.
3. Время, затраченное на тестирование каждой функции, и общее время тестирования.
4. Количество найденных дефектов.
5. Количество повторно открытых дефектов.
6. Отклонения от запланированной последовательности действий, если таковые имели место.
7. Выводы о необходимых корректировках в системе тестов, которые должны быть сделаны до следующего тестового цикла.
Тестовые метрики
Существует устоявшийся набор тестовых метрик, который помогает определить эффективность тестирования и текущее состояние продукта. К таким метрикам относятся следующие:
1. Покрытие функциональных требований.
2. Покрытие кода продукта. Наиболее применимо для модульного уровня тестирования.
3. Покрытие множества сценариев.
4. Количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения. При этом обнаруженные отклонения как в большую, так и в меньшую сторону приводят к анализу причин их появления и, если необходимо, к выработке корректирующих действий.
5. Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит либо о неэффективности тестов (когда большое количество тестов находит мало дефектов) либо о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов).
6. Количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику.
Обзоры тестов и стратегии
Тестовый код и стратегия тестирования, зафиксированные в виде документов, заметно улучшаются, если подвергаются коллективному обсуждению. Такие обсуждения называются обзорами (review). Существует принятая в организации процедура проведения и оценки результатов обзора. Обзоры наряду с тестированием образуют мощный набор методов борьбы с ошибками с целью повышения качества продукта. Цели обзоров тестовой стратегии и тестового кода различны.
Цели обзора тестовой стратегии:
1. Установить достаточность проверок, обеспечиваемых тестированием.
2. Проанализировать оптимальность покрытия или адекватность распределения количества планируемых тестов по функциональности продукта.
3. Проанализировать оптимальность подхода к разработке кода, генерации кода, автоматизации тестирования.
Цели обзора тестового кода:
1. Установить соответствие тестового набора тестовой стратегии.
2. Проверить правильность кодирования тестов.
3. Оценить достигнутую степень качества кода, исходя из требований по стандартам, простоте поддержки, наличию комментариев и т.п.
4. Если необходимо, проанализировать оптимальность тестового кода с целью удовлетворения требований к быстродействию и объему.
©www.intuit.ru
Описание тестов
Описание тестов разрабатывается для облегчения анализа и поддержки тестового набора. Описание может быть реализовано в произвольной форме, но при этом должны выполнять следующие задачи:
1. Анализировать степень покрытия продукта тестами на основании описания тестового набора.
2. Для любой функции тестируемого продукта найти тесты, в которых функция используется.
3. Для любого теста определить все функции и их сочетания, которые данный тест использует (затрагивает).
4. Понять структуру и взаимосвязи тестовых файлов.
5. Понять принцип построения системы автоматизации тестирования.
Документирование и жизненный цикл дефекта
Каждый дефект, обнаруженный в процессе тестирования, должен быть задокументирован и отслежен. При обнаружении нового дефекта его заносят в базу дефектов. Для этого лучше всего использовать специализированные базы, поддерживающие хранение и отслеживание дефектов - типа DDTS . При занесении нового дефекта рекомендуется указывать, как минимум, следующую информацию:
1. Наименование подсистемы, в которой обнаружен дефект.
2. Версия продукта (номер build ), на котором дефект был найден.
3. Описание дефекта.
4. Описание процедуры (шагов, необходимых для воспроизведения дефекта).
5. Номер теста, на котором дефект был обнаружен.
6. Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.
Занесенный в базу дефектов новый дефект находится в состоянии "New" . После того, как команда разработчиков проанализирует дефект, он переводится в состояние "Open" с указанием конкретного разработчика, ответственного за исправление дефекта. После исправления дефект переводится разработчиком в состояние "Resolved". При этом разработчик должен указать следующую информацию:
1. Причину возникновения дефекта.
2. Место исправления, как минимум, с точностью до исправленного файла.
3. Краткое описание того, что было исправлено.
4. Время, затраченное на исправление.
После этого тестировщик проверяет, действительно ли дефект был исправлен и если это так, переводит его в состояние "Verified". Если тестировщик не подтвердит факт исправления дефекта, то состояние дефекта изменяется снова на "Open".
Если проектная команда принимает решение о том, что некоторый дефект исправляться не будет, то такой дефект переводится в состояние "Postponed" с указанием лиц, ответственных за это решение, и причин его принятия.
Тестовый отчет
Тестовый отчет обновляется после каждого цикла тестирования и должен содержать следующую информацию для каждого цикла:
1. Перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему.
2. Количество выполненных тестов – запланированное и реально исполненное.
3. Время, затраченное на тестирование каждой функции, и общее время тестирования.
4. Количество найденных дефектов.
5. Количество повторно открытых дефектов.
6. Отклонения от запланированной последовательности действий, если таковые имели место.
7. Выводы о необходимых корректировках в системе тестов, которые должны быть сделаны до следующего тестового цикла.
Тестовые метрики
Существует устоявшийся набор тестовых метрик, который помогает определить эффективность тестирования и текущее состояние продукта. К таким метрикам относятся следующие:
1. Покрытие функциональных требований.
2. Покрытие кода продукта. Наиболее применимо для модульного уровня тестирования.
3. Покрытие множества сценариев.
4. Количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения. При этом обнаруженные отклонения как в большую, так и в меньшую сторону приводят к анализу причин их появления и, если необходимо, к выработке корректирующих действий.
5. Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит либо о неэффективности тестов (когда большое количество тестов находит мало дефектов) либо о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов).
6. Количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику.
Обзоры тестов и стратегии
Тестовый код и стратегия тестирования, зафиксированные в виде документов, заметно улучшаются, если подвергаются коллективному обсуждению. Такие обсуждения называются обзорами (review). Существует принятая в организации процедура проведения и оценки результатов обзора. Обзоры наряду с тестированием образуют мощный набор методов борьбы с ошибками с целью повышения качества продукта. Цели обзоров тестовой стратегии и тестового кода различны.
Цели обзора тестовой стратегии:
1. Установить достаточность проверок, обеспечиваемых тестированием.
2. Проанализировать оптимальность покрытия или адекватность распределения количества планируемых тестов по функциональности продукта.
3. Проанализировать оптимальность подхода к разработке кода, генерации кода, автоматизации тестирования.
Цели обзора тестового кода:
1. Установить соответствие тестового набора тестовой стратегии.
2. Проверить правильность кодирования тестов.
3. Оценить достигнутую степень качества кода, исходя из требований по стандартам, простоте поддержки, наличию комментариев и т.п.
4. Если необходимо, проанализировать оптимальность тестового кода с целью удовлетворения требований к быстродействию и объему.
©www.intuit.ru
понедельник, 12 января 2009 г.
Так
Набрел тут на строчки:
004 Устные сообщения циркулирующие по горизонтальным и неформальным каналам, менее подвержены искажениям
005 Мужчины ниже, чем полагают женщины, оценивают их деловые и интеллектуальные качества, а женщины ниже, чем полагают мужчины, оценивают их физическую привлекательность
006 Когда встречаются мужчина и женщина, их взаимооценки происходят в эротических терминах
007 Индивиды могут быть самими собой лишь в составе небольших, поддающихся их пониманию групп
008 Банальное начало ориентирует на банальность всей беседы
009 мужчина в среднем слушает других внимательно 10-15 секунд, а после начинает думать, что бы ему добавить к предмету разговора
004 Устные сообщения циркулирующие по горизонтальным и неформальным каналам, менее подвержены искажениям
005 Мужчины ниже, чем полагают женщины, оценивают их деловые и интеллектуальные качества, а женщины ниже, чем полагают мужчины, оценивают их физическую привлекательность
006 Когда встречаются мужчина и женщина, их взаимооценки происходят в эротических терминах
007 Индивиды могут быть самими собой лишь в составе небольших, поддающихся их пониманию групп
008 Банальное начало ориентирует на банальность всей беседы
009 мужчина в среднем слушает других внимательно 10-15 секунд, а после начинает думать, что бы ему добавить к предмету разговора
Nine
Тим Бертон и Бекмамбетов создадут, надеюсь, что скоро.
Вот это:
Я очень хочу посмотреть. И почти мечтаю найти саундтрек.
Рекомендую.
Вот это:
Я очень хочу посмотреть. И почти мечтаю найти саундтрек.
Рекомендую.
воскресенье, 11 января 2009 г.
Индустриальное тестирование
Продолжение заметок на полях о тестировании.
Тестирование, с технической точки зрения, есть процесс выполнения приложения на некоторых входных данных и проверка получаемых результатов с целью подтвердить их корректность по отношению к результату.
Итак, основная последовательность действий при выборе и оценке критериев качества программного продукта включает:
1. Определение всех лиц, так или иначе заинтересованных в исполнении и результатах данного проекта.
2. Определение критериев, формирующих представление о качестве для каждого из участников.
3. Приоритезацию критериев, с учетом важности конкретного участника для компании, выполняющей проект, и важности каждого из критериев для данного участника.
4. Определение набора критериев, которые будут отслежены и выполнены в рамках проекта, исходя из приоритетов и возможностей проектной команды. Постановка целей по каждому из критериев.
5. Определение способов и механизмов достижения каждого критерия.
6. Определение стратегии тестирования исходя из набора критериев, попадающих под ответственность группы тестирования, выбранных приоритетов и целей
Процесс тестирования
1. Модульное тестирование.
2. Интеграционное тестирование.
3. Системное тестирование.
Фазы процесса тестирования
1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т.п.
2. Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы, поскольку наличие исполняемой версии разрабатываемой системы (Implementation Under Testing (IUT) или Application Under Testing (AUT) – часто употребляемые обозначения для тестируемой системы) является одним из необходимых условий тестирования, что создает взаимозависимость в работе команд тестировщиков и разработчиков.
3. Разработка тестов , то есть тестового кода для тестируемой системы, если необходимо - кода системы автоматизации тестирования и тестовых процедур (выполняемых вручную).
4. Выполнение тестов: реализация тестовых циклов.
5. Анализ результатов.
Тестовый цикл
Тестовый цикл – это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build. Тестовый цикл включает следующую последовательность действий:
1. Проверка готовности системы и тестов к проведению тестового цикла включающая:
• Проверку того, что все тесты, запланированные для исполнения на данном цикле, разработаны и помещены в систему версионного контроля.
• Проверку того, что все подсистемы, запланированные для тестирования на данном цикле, разработаны и помещены в систему версионного контроля.
• Проверку того, что разработана и задокументирована процедура определения и создания среза системы, или build.
• Проверки некоторых дополнительных критериев.
2. Подготовка тестовой машины в соответствии с требованиями, определенными на этапе планирования (например, полная очистка и переустановка системного программного обеспечения). Конфигурация тестовой машины, так же, как и срез системы, должны быть однозначно воспроизводимыми.
3. Воспроизведение среза системы.
4. Прогон тестов в соответствии с задокументированными процедурами.
5. Сохранение тестовых протоколов (test log). Test log может содержать вывод системы в STDOUT, список результатов сравнения полученных при исполнении данных с эталонными или любые другие выходные данные тестов, с помощью которых можно проверить правильность работы системы.
6. Анализ протоколов тестирования и принятие решения о том прошел или не прошел каждый из тестов (Pass/Fail).
7. Анализ и документирование результатов цикла.
Последний перед выпуском продукта тестовый цикл не должен включать изменений кода build или кода продукта тестируемой системы. Этот цикл называется " финальным ". Таким образом обеспечивается ситуация, когда финальный цикл полностью повторяем, а выпускаемый продукт полностью совпадает с продуктом, который прошел тестирование. Финальный цикл необходим для гарантии достоверности результатов тестирования.
Планирование тестирования
Тестовый план - это документ, или набор документов, содержащий следующую информацию:
1. Тестовые ресурсы.
2. Перечень функций и подсистем, подлежащих тестированию.
3. Тестовую стратегию, включающую:
• Анализ функций и подсистем с целью определения наиболее слабых мест, то есть областей функциональности тестируемой системы, где появление дефектов наиболее вероятно.
• Определение стратегии выбора входных данных для тестирования. Так как множество возможных входных данных программного продукта, как правило, практически бесконечно, выбор конечного подмножества, достаточного для проведения исчерпывающего тестирования, является сложной задачей. Для ее решения могут быть применены такие методы, как покрытие классов входных и выходных данных, анализ крайних значений, покрытие модели использования, анализ временной линии и тому подобные. Выбранную стратегию необходимо обосновать и задокументировать.
• Определение потребности в автоматизированной системе тестирования и дизайн такой системы
4. Расписание тестовых циклов.
5. Фиксацию тестовой конфигурации: состава и конкретных параметров аппаратуры и программного окружения.
6. Определение списка тестовых метрик, которые на тестовом цикле необходимо собрать и проанализировать. Например, метрик, оценивающих степень покрытия тестами набора требований, степень покрытия кода тестируемой системы, количество и уровень серьезности дефектов, объем тестового кода и другие характеристики.
Типы тестирования
В тестовом плане определяются и документируются различные типы тестов. Типы тестов могут быть классифицированы по двум категориям: по тому, что подвергается тестированию (по виду подсистемы) и по способу выбора входных данных.
Типы тестирования по виду подсистемы или продукта:
1. Тестирование основной функциональности, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом
2. Тестирование инсталляции включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т.п.
3. Тестирование пользовательской документации включает проверку полноты и понятности описания правил и особенностей использования продукта, наличие описания всех сценариев и функциональности, синтаксис и грамматику языка, работоспособность примеров и т.п.
Типы тестирования по способу выбора входных значений:
1. Функциональное тестирование, при котором проверяется:
• Покрытие функциональных требований.
• Покрытие сценариев использования.
2. Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта.
3. Тестирование граничных значений.
4. Тестирование производительности.
5. Тестирование на соответствие стандартам.
6. Тестирование совместимости с другими программно-аппаратными комплексами.
7. Тестирование работы с окружением.
8. Тестирование работы на конкретной платформе
В реальных разработках используются и комбинируются различные типы тестов для обеспечения спланированного качества продукта.
Подходы к разработке тестов
Тестирование спецификации
При разработке тестов, основанной на функциональной спецификации продукта, требования к продукту являются основным источником, определяющим, какие тесты будут разработаны. Для каждого требования пишется один или более тестов, которые в совокупности должны проверить выполнение данного требования в продукте.
Тестирование сценариев
Разработка тестов, основанных на использовании сценариев, осуществляется по следующей методике:
1. Определяется модель использования, включающая операционное окружение продукта и "актеров". Актером может быть пользователь, другой продукт, аппаратная часть и тому подобное, то есть все, с чем продукт обменивается информацией. Разделение на окружение и актеров условно и служит для описания оптимальных способов использования продукта.
2. Разрабатываются сценарии использования продукта. Описание сценария в зависимости от продукта и выбранного подхода может быть строго определенным, параметризованным или разрешать некоторую степень неопределенности. Например, описание сценария на языке MSC допускает задание параметризованных сценариев с возможностью переупорядочивания событий.
3. Разрабатывается набор тестов, покрывающих заданные сценарии. С учетом степени неопределенности, заложенной в сценарии, каждый тест может покрывать один сценарий, несколько сценариев, или, наоборот, часть сценария.
Использование сценариев не требует наличия полной формальной спецификации требований, но зато может потребовать больше времени на разработку и анализ.
Еще одна особенность тестирования сценариев заключается в том, что этот метод направляет тестирование на проверку конкретных режимов использования продукта, что позволяет находить дефекты, которые метод тестирования по требованиям может пропустить.
Ручная разработка тестов
Наиболее распространенным способом разработки тестов является создание тестового кода вручную. Это наиболее гибкий способ разработки тестов, однако характерная для него производительность труда инженеров-тестировщиков в создании тестового кода не намного выше скорости создания кода продукта, а объемы тестового кода на практике зачастую превышают объем кода продукта в 10 раз. Учитывая этот факт, в современной индустрии все больше склоняются к более интеллектуальным способам получения тестового кода, таким как использование специальных тестовых языков (скриптов) и генерации тестов.
Генерация тестов
Использование методики генерации тестового кода по формализованным MSC диаграммам позволяет значительно поднять производительность тестирования, а также преобразовать формализацию (кодировку) сценариев в достаточно интеллектуальную деятельность.
©www.intuit.ru
Тестирование, с технической точки зрения, есть процесс выполнения приложения на некоторых входных данных и проверка получаемых результатов с целью подтвердить их корректность по отношению к результату.
Итак, основная последовательность действий при выборе и оценке критериев качества программного продукта включает:
1. Определение всех лиц, так или иначе заинтересованных в исполнении и результатах данного проекта.
2. Определение критериев, формирующих представление о качестве для каждого из участников.
3. Приоритезацию критериев, с учетом важности конкретного участника для компании, выполняющей проект, и важности каждого из критериев для данного участника.
4. Определение набора критериев, которые будут отслежены и выполнены в рамках проекта, исходя из приоритетов и возможностей проектной команды. Постановка целей по каждому из критериев.
5. Определение способов и механизмов достижения каждого критерия.
6. Определение стратегии тестирования исходя из набора критериев, попадающих под ответственность группы тестирования, выбранных приоритетов и целей
Процесс тестирования
1. Модульное тестирование.
2. Интеграционное тестирование.
3. Системное тестирование.
Фазы процесса тестирования
1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т.п.
2. Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы, поскольку наличие исполняемой версии разрабатываемой системы (Implementation Under Testing (IUT) или Application Under Testing (AUT) – часто употребляемые обозначения для тестируемой системы) является одним из необходимых условий тестирования, что создает взаимозависимость в работе команд тестировщиков и разработчиков.
3. Разработка тестов , то есть тестового кода для тестируемой системы, если необходимо - кода системы автоматизации тестирования и тестовых процедур (выполняемых вручную).
4. Выполнение тестов: реализация тестовых циклов.
5. Анализ результатов.
Тестовый цикл
Тестовый цикл – это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build. Тестовый цикл включает следующую последовательность действий:
1. Проверка готовности системы и тестов к проведению тестового цикла включающая:
• Проверку того, что все тесты, запланированные для исполнения на данном цикле, разработаны и помещены в систему версионного контроля.
• Проверку того, что все подсистемы, запланированные для тестирования на данном цикле, разработаны и помещены в систему версионного контроля.
• Проверку того, что разработана и задокументирована процедура определения и создания среза системы, или build.
• Проверки некоторых дополнительных критериев.
2. Подготовка тестовой машины в соответствии с требованиями, определенными на этапе планирования (например, полная очистка и переустановка системного программного обеспечения). Конфигурация тестовой машины, так же, как и срез системы, должны быть однозначно воспроизводимыми.
3. Воспроизведение среза системы.
4. Прогон тестов в соответствии с задокументированными процедурами.
5. Сохранение тестовых протоколов (test log). Test log может содержать вывод системы в STDOUT, список результатов сравнения полученных при исполнении данных с эталонными или любые другие выходные данные тестов, с помощью которых можно проверить правильность работы системы.
6. Анализ протоколов тестирования и принятие решения о том прошел или не прошел каждый из тестов (Pass/Fail).
7. Анализ и документирование результатов цикла.
Последний перед выпуском продукта тестовый цикл не должен включать изменений кода build или кода продукта тестируемой системы. Этот цикл называется " финальным ". Таким образом обеспечивается ситуация, когда финальный цикл полностью повторяем, а выпускаемый продукт полностью совпадает с продуктом, который прошел тестирование. Финальный цикл необходим для гарантии достоверности результатов тестирования.
Планирование тестирования
Тестовый план - это документ, или набор документов, содержащий следующую информацию:
1. Тестовые ресурсы.
2. Перечень функций и подсистем, подлежащих тестированию.
3. Тестовую стратегию, включающую:
• Анализ функций и подсистем с целью определения наиболее слабых мест, то есть областей функциональности тестируемой системы, где появление дефектов наиболее вероятно.
• Определение стратегии выбора входных данных для тестирования. Так как множество возможных входных данных программного продукта, как правило, практически бесконечно, выбор конечного подмножества, достаточного для проведения исчерпывающего тестирования, является сложной задачей. Для ее решения могут быть применены такие методы, как покрытие классов входных и выходных данных, анализ крайних значений, покрытие модели использования, анализ временной линии и тому подобные. Выбранную стратегию необходимо обосновать и задокументировать.
• Определение потребности в автоматизированной системе тестирования и дизайн такой системы
4. Расписание тестовых циклов.
5. Фиксацию тестовой конфигурации: состава и конкретных параметров аппаратуры и программного окружения.
6. Определение списка тестовых метрик, которые на тестовом цикле необходимо собрать и проанализировать. Например, метрик, оценивающих степень покрытия тестами набора требований, степень покрытия кода тестируемой системы, количество и уровень серьезности дефектов, объем тестового кода и другие характеристики.
Типы тестирования
В тестовом плане определяются и документируются различные типы тестов. Типы тестов могут быть классифицированы по двум категориям: по тому, что подвергается тестированию (по виду подсистемы) и по способу выбора входных данных.
Типы тестирования по виду подсистемы или продукта:
1. Тестирование основной функциональности, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом
2. Тестирование инсталляции включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т.п.
3. Тестирование пользовательской документации включает проверку полноты и понятности описания правил и особенностей использования продукта, наличие описания всех сценариев и функциональности, синтаксис и грамматику языка, работоспособность примеров и т.п.
Типы тестирования по способу выбора входных значений:
1. Функциональное тестирование, при котором проверяется:
• Покрытие функциональных требований.
• Покрытие сценариев использования.
2. Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта.
3. Тестирование граничных значений.
4. Тестирование производительности.
5. Тестирование на соответствие стандартам.
6. Тестирование совместимости с другими программно-аппаратными комплексами.
7. Тестирование работы с окружением.
8. Тестирование работы на конкретной платформе
В реальных разработках используются и комбинируются различные типы тестов для обеспечения спланированного качества продукта.
Подходы к разработке тестов
Тестирование спецификации
При разработке тестов, основанной на функциональной спецификации продукта, требования к продукту являются основным источником, определяющим, какие тесты будут разработаны. Для каждого требования пишется один или более тестов, которые в совокупности должны проверить выполнение данного требования в продукте.
Тестирование сценариев
Разработка тестов, основанных на использовании сценариев, осуществляется по следующей методике:
1. Определяется модель использования, включающая операционное окружение продукта и "актеров". Актером может быть пользователь, другой продукт, аппаратная часть и тому подобное, то есть все, с чем продукт обменивается информацией. Разделение на окружение и актеров условно и служит для описания оптимальных способов использования продукта.
2. Разрабатываются сценарии использования продукта. Описание сценария в зависимости от продукта и выбранного подхода может быть строго определенным, параметризованным или разрешать некоторую степень неопределенности. Например, описание сценария на языке MSC допускает задание параметризованных сценариев с возможностью переупорядочивания событий.
3. Разрабатывается набор тестов, покрывающих заданные сценарии. С учетом степени неопределенности, заложенной в сценарии, каждый тест может покрывать один сценарий, несколько сценариев, или, наоборот, часть сценария.
Использование сценариев не требует наличия полной формальной спецификации требований, но зато может потребовать больше времени на разработку и анализ.
Еще одна особенность тестирования сценариев заключается в том, что этот метод направляет тестирование на проверку конкретных режимов использования продукта, что позволяет находить дефекты, которые метод тестирования по требованиям может пропустить.
Ручная разработка тестов
Наиболее распространенным способом разработки тестов является создание тестового кода вручную. Это наиболее гибкий способ разработки тестов, однако характерная для него производительность труда инженеров-тестировщиков в создании тестового кода не намного выше скорости создания кода продукта, а объемы тестового кода на практике зачастую превышают объем кода продукта в 10 раз. Учитывая этот факт, в современной индустрии все больше склоняются к более интеллектуальным способам получения тестового кода, таким как использование специальных тестовых языков (скриптов) и генерации тестов.
Генерация тестов
Использование методики генерации тестового кода по формализованным MSC диаграммам позволяет значительно поднять производительность тестирования, а также преобразовать формализацию (кодировку) сценариев в достаточно интеллектуальную деятельность.
©www.intuit.ru
Заметки на полях
Цитатки... ничего особенного.
001 Мощь интеллекта не аналог морали, так же как не стыкуется с
моралью истинный профессионализм.
002 Следует конкретно различать и не путать: факты (данные), мнения
(личностные предположения), информацию (аналитически обработанные
данные).
003 Проще всего, впрочем, воспользоваться струей пара исходящего из носика кипящего чайника.
001 Мощь интеллекта не аналог морали, так же как не стыкуется с
моралью истинный профессионализм.
002 Следует конкретно различать и не путать: факты (данные), мнения
(личностные предположения), информацию (аналитически обработанные
данные).
003 Проще всего, впрочем, воспользоваться струей пара исходящего из носика кипящего чайника.
Автоматизация тестирования
Заметки на полях.
Использование различных подходов к тестированию определяется их эффективностью применительно к условиям, определяемым промышленным проектом. В реальных случаях работа группы тестирования планируется так, чтобы разработка тестов начиналась с момента согласования требований к программному продукту (выпуск Requirement Book, содержащей высокоуровневые требования к продукту) и продолжалась параллельно с разработкой дизайна и кода продукта. В результате, к началу системного тестирования создаются тестовые наборы, содержащие тысячи тестов. Большой набор тестов обеспечивает всестороннюю проверку функциональности продукта и гарантирует качество продукта, но пропуск такого количества тестов на этапе системного тестирования представляет проблему. Ее решение лежит в области автоматизации тестирования, т.е. в автоматизации разработки.
Собственно использование эффективной системы автоматизации тестирования сокращает до минимума (например, до одной ночи) время пропуска тестов, без которого невозможно подтвердить факт роста качества (уменьшения числа оставшихся ошибок) продукта. Системное тестирование осуществляется в рамках циклов тестирования (периодов пропуска разработанного тестового набора над build разрабатываемого приложения). Перед каждым циклом фиксируется разработанный или исправленный build, на который заносятся обнаруженные в результате тестового прогона ошибки. Затем ошибки исправляются, и на очередной цикл тестирования предъявляется новый build. Окончание тестирования совпадает с экспериментально подтвержденным заключением о достигнутом уровне качества относительно выбранного критерия тестирования или о снижении плотности не обнаруженных ошибок до некоторой заранее оговоренной величины. Возможность ограничить цикл тестирования пределом в одни сутки или несколько часов поддерживается исключительно за счет средств автоматизации тестирования.
Обобщенная структура системы автоматизации тестирования, в которой создается и сохраняется следующая информация:
• Набор тестов, достаточный для покрытия тестируемого приложения в соответствии с выбранным критерием тестирования – как результат ручной или автоматической разработки (генерации) тестовых наборов и драйвер/монитор пропуска тестового набора.
• Результаты прогона тестового набора, зафиксированные в Log-файле. Log-файл содержит трассы ("протоколы"), представляющие собой реализованные при тестовом прогоне последовательности некоторых событий (значений отдельных переменных или их совокупностей) и точки реализации этих событий на графе программы. В составе трасс могут присутствовать последовательности явно и неявно заданных меток, задающих пути реализации трасс на управляющем графе программы, совокупности значений переменных на этих метках, величины промежуточных результатов, достигнутых на некоторых метках и т.п.
• Статистика тестового цикла, содержащая: 1) результаты пропуска каждого теста из тестового набора и их сравнения с эталонными величинами; 2) факты, послужившие основанием для принятия решения о продолжении или окончании тестирования; 3) критерий покрытия и степень его удовлетворения, достигнутая в цикле тестирования.
Результатом анализа каждого прогона является список проблем, в виде ошибок и дефектов, который заносится в базу развития проекта. Далее происходит работа над ошибками, где каждая поднятая проблема идентифицируется, относится к соответствующему модулю и разработчику, приоритезируется и отслеживается, что обеспечивает гарантию ее решения (исправления или отнесения к списку известных проблем, решение которых по тем или иным причинам откладывается) в последующих build. Исправленный и собранный для тестирования build поступает на следующий цикл тестирования, и цикл повторяется, пока нужное качество программного комплекса не будет достигнуто. В этом итерационном процессе средства автоматизации тестирования обеспечивают быстрый контроль результатов исправления ошибок и проверку уровня качества, достигнутого в продукте. Некачественный продукт зрелая организация не производит.
Издержки тестирования
Интенсивность обнаружения ошибок на единицу затрат и надежность тесно связаны со временем тестирования и, соответственно, с гарантией качества продукта Чем больше трудозатрат вкладывается в процесс тестирования, тем меньше ошибок в продукте остается незамеченными. Однако совершенство в индустриальном программировании имеет пределы, которые прежде всего связаны с затратами на получение программного продукта, а также с избытком качества, которое не востребовано заказчиком приложения. Нахождение оптимума – очень ответственная задача тестировщика и менеджера проекта.
Движение к уменьшению числа оставшихся ошибок или к качеству продукта приводит к применению различных методов отладки и тестирования в процессе создания продукта. На практике популярны следующие методы тестирования и отладки, упорядоченные по связанным с их применением затратам:
• Статические методы тестирования
• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование
• Тестирование реального окружения и реального времени.
Со временем, по мере обнаружения более сложных ошибок и дефектов, эффективность низкозатратных методов падает вместе с количеством обнаруживаемых ошибок.
Отсюда следует, что все методы тестирования не только имеют право на существование, но и имеют свою нишу, где они хорошо обнаруживают ошибки, тогда как вне ниши их эффективность падает. Поэтому необходимо совмещать различные методы и стратегии отладки и тестирования с целью обеспечения запланированного качества программного продукта при ограниченных затратах, что достижимо при использовании процесса управления качеством программного продукта.
©www.intuit.ru
Использование различных подходов к тестированию определяется их эффективностью применительно к условиям, определяемым промышленным проектом. В реальных случаях работа группы тестирования планируется так, чтобы разработка тестов начиналась с момента согласования требований к программному продукту (выпуск Requirement Book, содержащей высокоуровневые требования к продукту) и продолжалась параллельно с разработкой дизайна и кода продукта. В результате, к началу системного тестирования создаются тестовые наборы, содержащие тысячи тестов. Большой набор тестов обеспечивает всестороннюю проверку функциональности продукта и гарантирует качество продукта, но пропуск такого количества тестов на этапе системного тестирования представляет проблему. Ее решение лежит в области автоматизации тестирования, т.е. в автоматизации разработки.
Собственно использование эффективной системы автоматизации тестирования сокращает до минимума (например, до одной ночи) время пропуска тестов, без которого невозможно подтвердить факт роста качества (уменьшения числа оставшихся ошибок) продукта. Системное тестирование осуществляется в рамках циклов тестирования (периодов пропуска разработанного тестового набора над build разрабатываемого приложения). Перед каждым циклом фиксируется разработанный или исправленный build, на который заносятся обнаруженные в результате тестового прогона ошибки. Затем ошибки исправляются, и на очередной цикл тестирования предъявляется новый build. Окончание тестирования совпадает с экспериментально подтвержденным заключением о достигнутом уровне качества относительно выбранного критерия тестирования или о снижении плотности не обнаруженных ошибок до некоторой заранее оговоренной величины. Возможность ограничить цикл тестирования пределом в одни сутки или несколько часов поддерживается исключительно за счет средств автоматизации тестирования.
Обобщенная структура системы автоматизации тестирования, в которой создается и сохраняется следующая информация:
• Набор тестов, достаточный для покрытия тестируемого приложения в соответствии с выбранным критерием тестирования – как результат ручной или автоматической разработки (генерации) тестовых наборов и драйвер/монитор пропуска тестового набора.
• Результаты прогона тестового набора, зафиксированные в Log-файле. Log-файл содержит трассы ("протоколы"), представляющие собой реализованные при тестовом прогоне последовательности некоторых событий (значений отдельных переменных или их совокупностей) и точки реализации этих событий на графе программы. В составе трасс могут присутствовать последовательности явно и неявно заданных меток, задающих пути реализации трасс на управляющем графе программы, совокупности значений переменных на этих метках, величины промежуточных результатов, достигнутых на некоторых метках и т.п.
• Статистика тестового цикла, содержащая: 1) результаты пропуска каждого теста из тестового набора и их сравнения с эталонными величинами; 2) факты, послужившие основанием для принятия решения о продолжении или окончании тестирования; 3) критерий покрытия и степень его удовлетворения, достигнутая в цикле тестирования.
Результатом анализа каждого прогона является список проблем, в виде ошибок и дефектов, который заносится в базу развития проекта. Далее происходит работа над ошибками, где каждая поднятая проблема идентифицируется, относится к соответствующему модулю и разработчику, приоритезируется и отслеживается, что обеспечивает гарантию ее решения (исправления или отнесения к списку известных проблем, решение которых по тем или иным причинам откладывается) в последующих build. Исправленный и собранный для тестирования build поступает на следующий цикл тестирования, и цикл повторяется, пока нужное качество программного комплекса не будет достигнуто. В этом итерационном процессе средства автоматизации тестирования обеспечивают быстрый контроль результатов исправления ошибок и проверку уровня качества, достигнутого в продукте. Некачественный продукт зрелая организация не производит.
Издержки тестирования
Интенсивность обнаружения ошибок на единицу затрат и надежность тесно связаны со временем тестирования и, соответственно, с гарантией качества продукта Чем больше трудозатрат вкладывается в процесс тестирования, тем меньше ошибок в продукте остается незамеченными. Однако совершенство в индустриальном программировании имеет пределы, которые прежде всего связаны с затратами на получение программного продукта, а также с избытком качества, которое не востребовано заказчиком приложения. Нахождение оптимума – очень ответственная задача тестировщика и менеджера проекта.
Движение к уменьшению числа оставшихся ошибок или к качеству продукта приводит к применению различных методов отладки и тестирования в процессе создания продукта. На практике популярны следующие методы тестирования и отладки, упорядоченные по связанным с их применением затратам:
• Статические методы тестирования
• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование
• Тестирование реального окружения и реального времени.
Со временем, по мере обнаружения более сложных ошибок и дефектов, эффективность низкозатратных методов падает вместе с количеством обнаруживаемых ошибок.
Отсюда следует, что все методы тестирования не только имеют право на существование, но и имеют свою нишу, где они хорошо обнаруживают ошибки, тогда как вне ниши их эффективность падает. Поэтому необходимо совмещать различные методы и стратегии отладки и тестирования с целью обеспечения запланированного качества программного продукта при ограниченных затратах, что достижимо при использовании процесса управления качеством программного продукта.
©www.intuit.ru
суббота, 10 января 2009 г.
Сомалийские пираты
Сомаийские пираты освободили танкер за три миллиона.
Я не полный идиот и понимаю, что они преступники, и что это экономический ущерб, что они гопники с оружием, что там людей убивают и вообще все до ужаса несмешно.
Но я воспринимаю их только как информационный повод и забавную историю, потому как они очень далеко от меня, моей страны и вообще(ну, кроме Мослова). В таком ключе и воспринимать дальнейшее.
Viva, флибустьеры века двадцать первого!
Вы выставляете клоунами политиков и генералов! Над вашими головами спутники, запущенные на орбиту за миллиарды, за вами охотится пятый флот США и корабли еще 16 стран, а над вашими лодками флаги с роджером.
Пока есть вы - задницам генералов хоть что-то да угрожает, жирным купцам в дальнем море - не так спокойно.
Пока есть пираты - генералам хоть чуть-чуть стыдно.
Кот с рождения в тельняшке.
Я не полный идиот и понимаю, что они преступники, и что это экономический ущерб, что они гопники с оружием, что там людей убивают и вообще все до ужаса несмешно.
Но я воспринимаю их только как информационный повод и забавную историю, потому как они очень далеко от меня, моей страны и вообще(ну, кроме Мослова). В таком ключе и воспринимать дальнейшее.
Viva, флибустьеры века двадцать первого!
Вы выставляете клоунами политиков и генералов! Над вашими головами спутники, запущенные на орбиту за миллиарды, за вами охотится пятый флот США и корабли еще 16 стран, а над вашими лодками флаги с роджером.
Пока есть вы - задницам генералов хоть что-то да угрожает, жирным купцам в дальнем море - не так спокойно.
Пока есть пираты - генералам хоть чуть-чуть стыдно.
Кот с рождения в тельняшке.
О.о
Начал смотреть Обитаемый остров. Все таки - книга детства, миры Стругацких, все дела.
Не буду повторять посты критиков, они уже все были в топах, а мне не светит.
Вопрос есть небольшой к тем, кто читал.
Как думаете, что должно случиться, чтоб образ этого губастенького переродился в образ жесткого, умного, циничного функционера КОМКОНа-2 Каммерера?
И коту, само собой, интересно. Кот символизирует.
UPD: Посмотрел фото Степанова-Каммерера IRL, так там у него и губки не такие пухлые и линии лица тоньше. Там он гораздо больше похож на мой образ Макса, приятно, да.
Не буду повторять посты критиков, они уже все были в топах, а мне не светит.
Вопрос есть небольшой к тем, кто читал.
Как думаете, что должно случиться, чтоб образ этого губастенького переродился в образ жесткого, умного, циничного функционера КОМКОНа-2 Каммерера?
И коту, само собой, интересно. Кот символизирует.
UPD: Посмотрел фото Степанова-Каммерера IRL, так там у него и губки не такие пухлые и линии лица тоньше. Там он гораздо больше похож на мой образ Макса, приятно, да.
Системное и регрессионное тестирование
Очередная порция заметок на полях.
Системное тестирование
Системное тестирование качественно отличается от интеграционного и модульного уровней. Системное тестирование рассматривает тестируемую систему в целом и оперирует на уровне пользовательских интерфейсов, в отличие от последних фаз интеграционного тестирования, которое оперирует на уровне интерфейсов модулей. Различны и цели этих уровней тестирования. На уровне системы часто сложно и малоэффективно анализировать прохождение тестовых траекторий внутри программы или отслеживать правильность работы конкретных функций. Основная задача системного тестирования - в выявлении дефектов, связанных с работой системы в целом, таких как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство в применении и тому подобное.
Системное тестирование производится над проектом в целом с помощью метода «черного ящика».
1. Категории тестов системного тестирования:
2. Полнота решения функциональных задач.
3. Стрессовое тестирование - на предельных объемах нагрузки входного потока.
4. Корректность использования ресурсов (утечка памяти, возврат ресурсов).
5. Оценка производительности.
6. Эффективность защиты от искажения данных и некорректных действий.
7. Проверка инсталляции и конфигурации на разных платформах.
8. Корректность документации
Поскольку системное тестирование проводится на пользовательских интерфейсах, создается иллюзия того, что построение специальной системы автоматизации тестирования не всегда необходимо. Однако объемы данных на этом уровне таковы, что обычно более эффективным подходом является полная или частичная автоматизация тестирования, что приводит к созданию тестовой системы гораздо более сложной, чем система тестирования, применяемая на уровне тестирования модулей или их комбинаций.
Регрессионное тестирование
Регрессионное тестирование- цикл тестирования, который производится при внесении изменений на фазе системного тестирования или сопровождения продукта. Главная проблема регрессионного тестирования- выбор между полным и частичным перетестированием и пополнением тестовых наборов. При частичном перетестировании контролируются только те части проекта, которые связаны с измененными компонентами. На ГМП это пути, содержащие измененные узлы, и, как правило, это методы и классы, лежащие выше модифицированных по уровню, но содержащие их в своем контексте
Пропуск огромного объема тестов, характерного для этапа системного тестирования, удается осуществить без потери качественных показателей продукта только с помощью регрессионного подхода.
Получив отчет об ошибке, программист анализирует исходный код, находит ошибку, исправляет ее и модульно или интеграционно тестирует результат.
В свою очередь тестировщик, проверяя внесенные программистом изменения, должен:
• Проверить и утвердить исправление ошибки. Для этого необходимо выполнить указанный в отчете тест, с помощью которого была найдена ошибка.
• Попробовать воспроизвести ошибку каким-нибудь другим способом.
• Протестировать последствия исправлений. Возможно, что внесенные исправления привнесли ошибку (наведенную ошибку) в код, который до этого исправно работал.
Таким образом, исправление в одном месте привело к ошибке в другом, что демонстрирует необходимость проведения полного перетестирования. Однако повторное перетестирование требует значительных усилий и времени. Возникает задача – отобрать сокращенный набор тестов из исходного набора (может быть, пополнив его рядом дополнительных - вновь разработанных - тестов), которого, тем не менее, будет достаточно для исчерпывающей проверки функциональности в соответствии с выбранным критерием. Организация повторного тестирования в условиях сокращения ресурсов, необходимых для обеспечения заданного уровня качества продукта, обеспечивается регрессионным тестированием.
В каждом конкретном проекте должны быть определены задачи, ресурсы и технологии для каждого уровня тестирования таким образом, чтобы каждый из типов дефектов, ожидаемых в системе, был «адресован», то есть в общем наборе тестов должны иметься тесты, направленные на выявление дефектов подобного типа. Табл. 4.3 суммирует характеристики свойств модульного, интеграционного и системного уровней тестирования. Задача, которая стоит перед тестировщиками и менеджерами, заключается в оптимальном распределении ресурсов между всеми тремя типами тестирования. Например, перенесение усилий на поиск фиксированного типа дефектов из области системного в область модульного тестирования может существенно снизить сложность и стоимость всего процесса тестирования.
©www.intuit.ru
Системное тестирование
Системное тестирование качественно отличается от интеграционного и модульного уровней. Системное тестирование рассматривает тестируемую систему в целом и оперирует на уровне пользовательских интерфейсов, в отличие от последних фаз интеграционного тестирования, которое оперирует на уровне интерфейсов модулей. Различны и цели этих уровней тестирования. На уровне системы часто сложно и малоэффективно анализировать прохождение тестовых траекторий внутри программы или отслеживать правильность работы конкретных функций. Основная задача системного тестирования - в выявлении дефектов, связанных с работой системы в целом, таких как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство в применении и тому подобное.
Системное тестирование производится над проектом в целом с помощью метода «черного ящика».
1. Категории тестов системного тестирования:
2. Полнота решения функциональных задач.
3. Стрессовое тестирование - на предельных объемах нагрузки входного потока.
4. Корректность использования ресурсов (утечка памяти, возврат ресурсов).
5. Оценка производительности.
6. Эффективность защиты от искажения данных и некорректных действий.
7. Проверка инсталляции и конфигурации на разных платформах.
8. Корректность документации
Поскольку системное тестирование проводится на пользовательских интерфейсах, создается иллюзия того, что построение специальной системы автоматизации тестирования не всегда необходимо. Однако объемы данных на этом уровне таковы, что обычно более эффективным подходом является полная или частичная автоматизация тестирования, что приводит к созданию тестовой системы гораздо более сложной, чем система тестирования, применяемая на уровне тестирования модулей или их комбинаций.
Регрессионное тестирование
Регрессионное тестирование- цикл тестирования, который производится при внесении изменений на фазе системного тестирования или сопровождения продукта. Главная проблема регрессионного тестирования- выбор между полным и частичным перетестированием и пополнением тестовых наборов. При частичном перетестировании контролируются только те части проекта, которые связаны с измененными компонентами. На ГМП это пути, содержащие измененные узлы, и, как правило, это методы и классы, лежащие выше модифицированных по уровню, но содержащие их в своем контексте
Пропуск огромного объема тестов, характерного для этапа системного тестирования, удается осуществить без потери качественных показателей продукта только с помощью регрессионного подхода.
Получив отчет об ошибке, программист анализирует исходный код, находит ошибку, исправляет ее и модульно или интеграционно тестирует результат.
В свою очередь тестировщик, проверяя внесенные программистом изменения, должен:
• Проверить и утвердить исправление ошибки. Для этого необходимо выполнить указанный в отчете тест, с помощью которого была найдена ошибка.
• Попробовать воспроизвести ошибку каким-нибудь другим способом.
• Протестировать последствия исправлений. Возможно, что внесенные исправления привнесли ошибку (наведенную ошибку) в код, который до этого исправно работал.
Таким образом, исправление в одном месте привело к ошибке в другом, что демонстрирует необходимость проведения полного перетестирования. Однако повторное перетестирование требует значительных усилий и времени. Возникает задача – отобрать сокращенный набор тестов из исходного набора (может быть, пополнив его рядом дополнительных - вновь разработанных - тестов), которого, тем не менее, будет достаточно для исчерпывающей проверки функциональности в соответствии с выбранным критерием. Организация повторного тестирования в условиях сокращения ресурсов, необходимых для обеспечения заданного уровня качества продукта, обеспечивается регрессионным тестированием.
В каждом конкретном проекте должны быть определены задачи, ресурсы и технологии для каждого уровня тестирования таким образом, чтобы каждый из типов дефектов, ожидаемых в системе, был «адресован», то есть в общем наборе тестов должны иметься тесты, направленные на выявление дефектов подобного типа. Табл. 4.3 суммирует характеристики свойств модульного, интеграционного и системного уровней тестирования. Задача, которая стоит перед тестировщиками и менеджерами, заключается в оптимальном распределении ресурсов между всеми тремя типами тестирования. Например, перенесение усилий на поиск фиксированного типа дефектов из области системного в область модульного тестирования может существенно снизить сложность и стоимость всего процесса тестирования.
©www.intuit.ru
пятница, 9 января 2009 г.
И еще
Почувствовал новую необходимость в старых наркотиках.
Как вы считаете, какую нехудожественную книгу мне просто клинически необходимо неспеша прочесть?
Профильные книги я читаю сам.
Англо-русский словарь - на всякий случай - у меня имеется.
Кот тоже очень-очень-очень хочет прочесть все-все-все книги. Но, к его счастью, не умеет читать. А я умею, и мне придется.
Как вы считаете, какую нехудожественную книгу мне просто клинически необходимо неспеша прочесть?
Профильные книги я читаю сам.
Англо-русский словарь - на всякий случай - у меня имеется.
Кот тоже очень-очень-очень хочет прочесть все-все-все книги. Но, к его счастью, не умеет читать. А я умею, и мне придется.
вторник, 6 января 2009 г.
Особенности интеграционного тестирования для объектно-ориентированного программирования
Заметки на полях неспеша идут дальше.
Программный проект, написанный в соответствии с объектно-ориентированным подходом, будет иметь ГМП, существенно отличающийся от ГМП традиционной "процедурной" программы. Сама разработка проекта строится по другому принципу - от определения классов, используемых в программе, построения дерева классов к реализации кода проекта. При правильном использовании классов, точно отражающих прикладную область приложения, этот метод дает более короткие, понятные и легко контролируемые программы.
Объектно-ориентированное программное обеспечение является событийно управляемым. Передача управления внутри программы осуществляется не только путем явного указания последовательности обращений одних функций программы к другим, но и путем генерации сообщений различным объектам, разбора сообщений соответствующим обработчиком и передача их объектам, для которых данные сообщения предназначены. Рассмотренная ГМП в данном случае становится неприменимой. Эта модель, как минимум, требует адаптации к требованиям, вводимым объектно-ориентированным подходом к написанию программного обеспечения. При этом происходит переход от модели, описывающей структуру программы, к модели, описывающей поведение программы, что для тестирования можно классифицировать как положительное свойство данного перехода. Отрицательным аспектом совершаемого перехода для применения рассмотренных ранее моделей является потеря заданных в явном виде связей между модулями программы.
Разработка программного обеспечения высокого качества для MS Windows или любой другой операционной системы, использующей стандарт "look and feel", с применением только вновь созданных классов практически невозможна.
Работа по тестированию приложения не должна включать в себя проверку работоспособности элементов библиотек, ставших фактически промышленным стандартом для разработки программного обеспечения, а только проверку кода, написанного непосредственно разработчиком программного проекта. Тестирование объектно-ориентированной программы должно включать те же уровни, что и тестирование процедурной программы - модульное, интеграционное и системное. Внутри класса отдельно взятые методы имеют императивный характер исполнения. Все языки ООП возвращают контроль вызывающему объекту, когда сообщение обработано. Поэтому каждый метод (функция - член класса) должен пройти традиционное модульное тестирование по выбранному критерию.
Каждый класс должен быть рассмотрен и как субъект интеграционного тестирования. Интеграция для всех методов класса проводится с использованием инкрементальной стратегии снизу вверх. При этом мы можем переиспользовать тесты для классов-родителей тестируемого класса, что следует из принципа наследования - от базовых классов, не имеющих родителей, к самым верхним уровням классов.
В ходе интеграционного тестирования должны быть проверены все возможные внешние вызовы методов класса, как непосредственные обращения, так и вызовы, инициированные получением сообщений.
Данные - члены класса (данные, описанные в самом классе, и унаследованные от классов-родителей видимые извне данные) рассматриваются как "глобальные переменные", они должны быть протестированы отдельно на основе принципов тестирования потоков данных.
Методика проведения тестирования программы, представленной в виде классовой модели программного проекта, включает в себя несколько этапов:
1. На первом уровне проводится тестирование методов каждого класса программы, что соответствует этапу модульного тестирования.
2. На втором уровне тестируются методы класса, которые образуют контекст интеграционного тестирования каждого класса.
3. На третьем уровне протестированный класс включается в общий контекст (дерево классов) программного проекта. Здесь становится возможным отслеживать реакцию программы на внешние события
Второй и третий уровни рассматриваемой модели соответствуют этапу интеграционного тестирования.
.
©www.intuit.ru
Программный проект, написанный в соответствии с объектно-ориентированным подходом, будет иметь ГМП, существенно отличающийся от ГМП традиционной "процедурной" программы. Сама разработка проекта строится по другому принципу - от определения классов, используемых в программе, построения дерева классов к реализации кода проекта. При правильном использовании классов, точно отражающих прикладную область приложения, этот метод дает более короткие, понятные и легко контролируемые программы.
Объектно-ориентированное программное обеспечение является событийно управляемым. Передача управления внутри программы осуществляется не только путем явного указания последовательности обращений одних функций программы к другим, но и путем генерации сообщений различным объектам, разбора сообщений соответствующим обработчиком и передача их объектам, для которых данные сообщения предназначены. Рассмотренная ГМП в данном случае становится неприменимой. Эта модель, как минимум, требует адаптации к требованиям, вводимым объектно-ориентированным подходом к написанию программного обеспечения. При этом происходит переход от модели, описывающей структуру программы, к модели, описывающей поведение программы, что для тестирования можно классифицировать как положительное свойство данного перехода. Отрицательным аспектом совершаемого перехода для применения рассмотренных ранее моделей является потеря заданных в явном виде связей между модулями программы.
Разработка программного обеспечения высокого качества для MS Windows или любой другой операционной системы, использующей стандарт "look and feel", с применением только вновь созданных классов практически невозможна.
Работа по тестированию приложения не должна включать в себя проверку работоспособности элементов библиотек, ставших фактически промышленным стандартом для разработки программного обеспечения, а только проверку кода, написанного непосредственно разработчиком программного проекта. Тестирование объектно-ориентированной программы должно включать те же уровни, что и тестирование процедурной программы - модульное, интеграционное и системное. Внутри класса отдельно взятые методы имеют императивный характер исполнения. Все языки ООП возвращают контроль вызывающему объекту, когда сообщение обработано. Поэтому каждый метод (функция - член класса) должен пройти традиционное модульное тестирование по выбранному критерию.
Каждый класс должен быть рассмотрен и как субъект интеграционного тестирования. Интеграция для всех методов класса проводится с использованием инкрементальной стратегии снизу вверх. При этом мы можем переиспользовать тесты для классов-родителей тестируемого класса, что следует из принципа наследования - от базовых классов, не имеющих родителей, к самым верхним уровням классов.
В ходе интеграционного тестирования должны быть проверены все возможные внешние вызовы методов класса, как непосредственные обращения, так и вызовы, инициированные получением сообщений.
Данные - члены класса (данные, описанные в самом классе, и унаследованные от классов-родителей видимые извне данные) рассматриваются как "глобальные переменные", они должны быть протестированы отдельно на основе принципов тестирования потоков данных.
Методика проведения тестирования программы, представленной в виде классовой модели программного проекта, включает в себя несколько этапов:
1. На первом уровне проводится тестирование методов каждого класса программы, что соответствует этапу модульного тестирования.
2. На втором уровне тестируются методы класса, которые образуют контекст интеграционного тестирования каждого класса.
3. На третьем уровне протестированный класс включается в общий контекст (дерево классов) программного проекта. Здесь становится возможным отслеживать реакцию программы на внешние события
Второй и третий уровни рассматриваемой модели соответствуют этапу интеграционного тестирования.
.
©www.intuit.ru
Ужасы нашего городка
Организм успешно борется с кашлем и остатками простуды, при этом совершенно не учитывая пожелания сознания, которое очень хочет спать.
Собственно пост является результатом безоговорочной победы организма: я больше не кашляю и, соответственно, не сплю.
Как видно из ленты, не спится хорошим людям nitris и sioku. Надеюсь, что у них нет подобного диссонанса между бренным телом и бессмертной душой. Я даже придумал, чем займусь.
Сперва прочту очередную главку о всякой ерунде, а потом в пятый раз пересмотрю какие-нибудь несколько серий House M.D.
Кстати, обращаюсь к фанатам сериала: добрые друзья подкинули мне полный набор саундтреков к сезонам с первого по четвертый, часть уже перелита на плеер. Завидуйте, хех.
А все нормальные коты спят.
Собственно пост является результатом безоговорочной победы организма: я больше не кашляю и, соответственно, не сплю.
Как видно из ленты, не спится хорошим людям nitris и sioku. Надеюсь, что у них нет подобного диссонанса между бренным телом и бессмертной душой. Я даже придумал, чем займусь.
Сперва прочту очередную главку о всякой ерунде, а потом в пятый раз пересмотрю какие-нибудь несколько серий House M.D.
Кстати, обращаюсь к фанатам сериала: добрые друзья подкинули мне полный набор саундтреков к сезонам с первого по четвертый, часть уже перелита на плеер. Завидуйте, хех.
А все нормальные коты спят.
понедельник, 5 января 2009 г.
Кино
Скачал:
Они сражались за Родину,
9 рота,
12 Разгневанных Мужчин.
Говорят - кино для дураков. А мне нравится.
Коту тоже.
Они сражались за Родину,
9 рота,
12 Разгневанных Мужчин.
Говорят - кино для дураков. А мне нравится.
Коту тоже.
суббота, 3 января 2009 г.
Тариф новогодний "Отдохни печень"
Всероссийскую пьянку провел в кругу семьи и в онлайне. Что, собственно, и символизирует заголовок. Два дня смотрелся в ящик и от этого очень устал, почему и удрал в Екб.
Буду по одному ловить друзей, глядишь, поймаю еще что доброе.
Кот как бы говорит всем, кроме списка хороших людей: идите, куда шли.
Буду по одному ловить друзей, глядишь, поймаю еще что доброе.
Кот как бы говорит всем, кроме списка хороших людей: идите, куда шли.
четверг, 1 января 2009 г.
Внезапно
Никому не удивляться, что я в интернетах под самый праздник. Потому что это не я. Тот, который я, с кем-то переписывается по аське, зырит ящик и собирается отмечать НГ в кругу семьи. И лечь спать часа в два. Потому как знает, что друзья никуда не денутся в следующие десять дней.
P.S. А кто это пишет? А пишут это его печень и почки, радуясь передышке и совпавшему с ней празднику, и просят поставить какую-нибудь легкую музыку.
P.S. А кто это пишет? А пишут это его печень и почки, радуясь передышке и совпавшему с ней празднику, и просят поставить какую-нибудь легкую музыку.
Подписаться на:
Сообщения (Atom)