2. Что? Где? Когда...? Как называется? Что содержит? Для чего? Когда и кем? А надо ли?
3. Артефакты тестирования План тестирования (Test Plan) Стратегия тестирования (Test strategy) Варианты использования (Use cases) Тестовые сценарии (Test cases) Матрица соответствий (Traceability matrix) «Список проверки» (Checklist) Описание ошибки (Bug report) Отчет о тестировании (Test result report) ....
4. Как называется: План тестирования – Test Plan Что содержит: Требуемые ресурсы(специальное оборудование, ПО, люди и их обязанности, тренинги), что будет / не будет протестировано,условияначала тестирования, условия успешного/неуспешного окончания тестирования, риски, стратегия тестирования[?], типы тестирования1
5. Как называется: План тестирования – Test Plan Для чего: понять что, как, когда будет/не будет проверяться (составить календарный план, определится с инструментарием и тд.) донести эту информацию до продюссера/команды Когда: Начало работы над проектом Кем: Менеджер тестировщиков/руководитель группы
6.
7. процесс разработки ПО сертифицирован (e.g. CMMI) и вам нужно показывать его проверяющим
13. Как называется:Стратегия тестирования - Test strategy Чтобы узнать: Как тестирование даст ответ, что данный функционал работает? Что нужно сделать и чем пользоваться для достижения целей тестирования? Когда определённый функционал будет тестироваться и когда ожидать результатов? Когда: Начало работы над проектом Кем: Руководитель группы/ведущий тестировщик
17. описывает типичные способы работы пользователя с системойДля: понимание того, как пользуются предоставленным в тестирование ПО Когда: перед написанием тестовых сценариев; после того, когда есть утвержденный макет продукта /определенной функциональности Кем: аналитики/тестировщики
18.
19.
20.
21.
22.
23.
24.
25. Как называется:Отчет о тестировании - Test result report Что: кто тестировал (люди), что тестировал (билды и т.д.), как тестировали (техники, средства), итог тестирования (общий, кол-во открытых/ закрытых/переоткрытых багов), рекомендации от отдела тестирования
26.
27. информирования руководства о положении дел на проекте с точки зрения отдела тестированияКогда: периодически + итоговый отчет тестирования Кем: от тестировщика до руководителя группы
Что содержит: Описывает весь объем работ по тестированию, начиная с описания объекта, стратегии тестирования (?), расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.Типы: функциональное, нагрузочное, регрессионное, УИ, инсталляционное и т.д.
Что содержит: Описывает весь объем работ по тестированию, начиная с описания объекта, стратегии тестирования (?), расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.Для чего: есть утверждения, что не всегда это нужно... Иногда тест план приобретает
Что содержит: Описывает весь объем работ по тестированию, начиная с описания объекта, стратегии тестирования (?), расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.Для чего: есть утверждения, что не всегда это нужно... Иногда тест план приобретает
Стратегия тестирования — это план проведения работ по тестированию системы или её модуля, учитывающий специфику функциональности и зависимости с другими компонентами системы и платформы. Стратегия определяет типы тестов, которые нужно выполнять для данного функционала системы, включает описание необходимых подходов с точки зрения целей тестирования и может задавать описания или требования к необходимым для проведения тестирования инструментам и инфраструктуре.Получается немного страшновато? Попробуем разбить на более детальные части используя, к примеру, разбивку по вопросам, на которые отвечает стратегия тестирования.Стратегия отвечает на вопросы:Как, каким образом тестирование даст ответ, что данный функционал работает?Что нужно сделать и чем пользоваться из инструментальных средств, для достижения целей тестирования?Когда определённый функционал будет тестироваться и соответственно когда ожидать получения результатов?
Стратегия тестирования — это план проведения работ по тестированию системы или её модуля, учитывающий специфику функциональности и зависимости с другими компонентами системы и платформы. Стратегия определяет типы тестов, которые нужно выполнять для данного функционала системы, включает описание необходимых подходов с точки зрения целей тестирования и может задавать описания или требования к необходимым для проведения тестирования инструментам и инфраструктуре.Получается немного страшновато? Попробуем разбить на более детальные части используя, к примеру, разбивку по вопросам, на которые отвечает стратегия тестирования.Стратегия отвечает на вопросы:Как, каким образом тестирование даст ответ, что данный функционал работает?Что нужно сделать и чем пользоваться из инструментальных средств, для достижения целей тестирования?Когда определённый функционал будет тестироваться и соответственно когда ожидать получения результатов?Для чего:Что в общем случае даёт разработка стратегии тестирования? Разбор задачи тестирования на составляющие, выделение тестовых областей и в конечном итоге более полное понимание задачи тестирования в конкретном проекте. Как мы видели на примере тестирования инженерного калькулятора, понимание задачи позволяет разделять функциональность тестируемого приложения или системы на области, которые могут тестироваться автономно, что позволяет снизить (и порой достаточно существенно!) затраты на тестирование.
Стратегия тестирования — это план проведения работ по тестированию системы или её модуля, учитывающий специфику функциональности и зависимости с другими компонентами системы и платформы. Стратегия определяет типы тестов, которые нужно выполнять для данного функционала системы, включает описание необходимых подходов с точки зрения целей тестирования и может задавать описания или требования к необходимым для проведения тестирования инструментам и инфраструктуре.Получается немного страшновато? Попробуем разбить на более детальные части используя, к примеру, разбивку по вопросам, на которые отвечает стратегия тестирования.Стратегия отвечает на вопросы:Как, каким образом тестирование даст ответ, что данный функционал работает?Что нужно сделать и чем пользоваться из инструментальных средств, для достижения целей тестирования?Когда определённый функционал будет тестироваться и соответственно когда ожидать получения результатов?Для чего:Что в общем случае даёт разработка стратегии тестирования? Разбор задачи тестирования на составляющие, выделение тестовых областей и в конечном итоге более полное понимание задачи тестирования в конкретном проекте. Как мы видели на примере тестирования инженерного калькулятора, понимание задачи позволяет разделять функциональность тестируемого приложения или системы на области, которые могут тестироваться автономно, что позволяет снизить (и порой достаточно существенно!) затраты на тестирование.
Когда: examples: чеклистпроверки юзабилити веб-форм:Состав полей1. Форма содержит минимально необходимое для работы системы количество полей?2. Форма содержит минимально необходимое для работы системы количество полей, обязательных для заполнения?3. Все обязательные поля находятся сверху формы?4. Поля формы сгруппированы по смыслу?GUI controls5. Недлинные раскрывающиеся списки заменены на группы radiobutton?6. Длинные раскрывающиеся списки заменены либо на поля с автозаполнением, либо на иерархические структуры с radiobutton?7. Раскрывающиеся списки с множественным выбором вообще не используются?8. При вводе длинных значений в поля text и textarea не возникает прокрутки?9. При щелчке по подписям к элементам checkbox и radiobutton их состояние изменяется?10. У формы есть кнопка submit?Описание формы11. Все обязательные для заполнения поля помечены звездочками?12. У всех полей есть понятные подписи?13. У всех полей, понятность подписей к которым вызывает сомнения, есть примеры заполнения?14. Присутствуют диагностические сообщения и об ошибках, и об успешном завершении операции?15. По тексту сообщений об ошибках пользователь может понять, что он сделал не так, и исправиться?Функциональность кода16. Ограничения на ввод вызваны только причинами безопасности?17. При возврате к форме из-за ошибок заполнения значения всех полей сохраняются в том виде, в котором их отправил пользователь?Чеклист для оценки работы с СУБДЯ хочу привести простой список, который, я надеюсь, поможет вам выявить узкие места в работе с СУБД на ваших проектах. Все это мои личные наработки, поэтому на какую либо полноту, упорядоченность, уникальность и безоговорочность они претендовать не могут. Итак, начнем.Структура БД- Созданы ли домены для всех необходимых столбцов?- Созданы ли все необходимые fk(foreign key)?- Созданы ли индексы для fk указывающие на таблицы с большим объемом данных(в некоторых СУБД индексы создаются вместе с fk)?- Правильный ли порядок полей в составных индексах?- Есть ли таблицы где размер id(pk) поля(домена) занимает более 30% от объема строки(кортежа) и есть вторичный pk(primary key)?- Можно ли заменить триггеры на fk?Работа с СУБД- Используете ли вы Connection pool?- Используете ли вы серверные курсоры?- Используете ли вы read-only транзакции и курсоры где возможно? Однонаправленные курсоры?- Используете ли вы параметризированные и подготовленные запросы (особенно при многократной вставке информации)?- Используете ли вы явное управление транзакциями?- Минимизирована ли длина транзакции?- Есть ли очень длинные или объемные транзакции, которые можно разбить на несколько?- Есть ли у вас после IUD запросов select в той же транзакции?- Выставлен ли таймаут для запроса?- выставлен ли минимально возможный Isolation Level? Меняете ли вы его в зависимости от нужд транзакции?- Знаете ли вы что, когда и на сколько блокируется на запись? А на чтение?- Блокируются ли любая ваша таблица более чем на секунду?- Знаете ли вы TOP 5 запросов в вашей системе по кол-ву вызовов? А по времени выполнения?- Можно ли часть часто используемой информации закэшировать?- Есть ли у вас выборки, которые по условию возвращают более 30% данных из таблицы?- Есть ли у вас выборки, которые возвращают информации в 2 раза больше чем необходимо?- Есть ли запросы, которые сканируют всю таблицу не по ключу(natural scan)?Вот вкратце и все что вспомнилось. Почти обо все вопросы я в свое время спотыкался. Практически каждый может выиграть вам кучу времени у сервера без всяких хитрых махинаций и подстроек СУБД и БД в частности.Не обвиняйте во всех проблемах других – попробуйте сначала найти их в себе.P.S. Если причина упоминания какого-либо пункта не ясна - спрашивайте.
Когда: examples: чеклистпроверки юзабилити веб-форм:Состав полей1. Форма содержит минимально необходимое для работы системы количество полей?2. Форма содержит минимально необходимое для работы системы количество полей, обязательных для заполнения?3. Все обязательные поля находятся сверху формы?4. Поля формы сгруппированы по смыслу?GUI controls5. Недлинные раскрывающиеся списки заменены на группы radiobutton?6. Длинные раскрывающиеся списки заменены либо на поля с автозаполнением, либо на иерархические структуры с radiobutton?7. Раскрывающиеся списки с множественным выбором вообще не используются?8. При вводе длинных значений в поля text и textarea не возникает прокрутки?9. При щелчке по подписям к элементам checkbox и radiobutton их состояние изменяется?10. У формы есть кнопка submit?Описание формы11. Все обязательные для заполнения поля помечены звездочками?12. У всех полей есть понятные подписи?13. У всех полей, понятность подписей к которым вызывает сомнения, есть примеры заполнения?14. Присутствуют диагностические сообщения и об ошибках, и об успешном завершении операции?15. По тексту сообщений об ошибках пользователь может понять, что он сделал не так, и исправиться?Функциональность кода16. Ограничения на ввод вызваны только причинами безопасности?17. При возврате к форме из-за ошибок заполнения значения всех полей сохраняются в том виде, в котором их отправил пользователь?Чеклист для оценки работы с СУБДЯ хочу привести простой список, который, я надеюсь, поможет вам выявить узкие места в работе с СУБД на ваших проектах. Все это мои личные наработки, поэтому на какую либо полноту, упорядоченность, уникальность и безоговорочность они претендовать не могут. Итак, начнем.Структура БД- Созданы ли домены для всех необходимых столбцов?- Созданы ли все необходимые fk(foreign key)?- Созданы ли индексы для fk указывающие на таблицы с большим объемом данных(в некоторых СУБД индексы создаются вместе с fk)?- Правильный ли порядок полей в составных индексах?- Есть ли таблицы где размер id(pk) поля(домена) занимает более 30% от объема строки(кортежа) и есть вторичный pk(primary key)?- Можно ли заменить триггеры на fk?Работа с СУБД- Используете ли вы Connection pool?- Используете ли вы серверные курсоры?- Используете ли вы read-only транзакции и курсоры где возможно? Однонаправленные курсоры?- Используете ли вы параметризированные и подготовленные запросы (особенно при многократной вставке информации)?- Используете ли вы явное управление транзакциями?- Минимизирована ли длина транзакции?- Есть ли очень длинные или объемные транзакции, которые можно разбить на несколько?- Есть ли у вас после IUD запросов select в той же транзакции?- Выставлен ли таймаут для запроса?- выставлен ли минимально возможный Isolation Level? Меняете ли вы его в зависимости от нужд транзакции?- Знаете ли вы что, когда и на сколько блокируется на запись? А на чтение?- Блокируются ли любая ваша таблица более чем на секунду?- Знаете ли вы TOP 5 запросов в вашей системе по кол-ву вызовов? А по времени выполнения?- Можно ли часть часто используемой информации закэшировать?- Есть ли у вас выборки, которые по условию возвращают более 30% данных из таблицы?- Есть ли у вас выборки, которые возвращают информации в 2 раза больше чем необходимо?- Есть ли запросы, которые сканируют всю таблицу не по ключу(natural scan)?Вот вкратце и все что вспомнилось. Почти обо все вопросы я в свое время спотыкался. Практически каждый может выиграть вам кучу времени у сервера без всяких хитрых махинаций и подстроек СУБД и БД в частности.Не обвиняйте во всех проблемах других – попробуйте сначала найти их в себе.P.S. Если причина упоминания какого-либо пункта не ясна - спрашивайте.
В своей книге "Тестирование программного обеспечения" Сэм Канер приводит определение: "Если программа не делает того, чего пользователь от нее вполне обосновано ожидает, значит налицо программная ошибка.”
По сложившейся традиции вся учебная литература мира информационных технологий обучает читателей и студентов разрабатывать объемную и подробную тестовую документацию. Мы позволим себе не согласиться с этой традицией, поскольку наш опыт свидетельствует, что документация не должна быть впечатляющей - она должна быть эффективной.
