Мы поможем в написании ваших работ!
ЗНАЕТЕ ЛИ ВЫ?
|
Тестирование в итеративном жизненном цикле проекта
Содержание книги
- Структура классов ППП для решения задач оптимизации
- virtual void function() = 0;. class CAbstractProblem. чисто виртуальная функция. class CRealProblem: public CAbstractProblem. входные данные задачи. конструктор. деструктор. функции доступа к переменным класса. class CAbstractResult. чисто виртуальная фун
- Решение задач лп с помощью пакета ilog OPL Studio
- sum(j in Products) a[i,j]*x[j]>=b[i];
- forall(i in Parameters : i <> Calories)
- Тестирование программного обеспечения
- Тестирование в итеративном жизненном цикле проекта
- Принципы поиска ошибок при тестировании
- Проверка в нормальных условиях предполагает тестирование на данных, которые характерны для реальных условий функционирования программы.
- Дж. Шеферд. Программирование на Microsoft VIsual C++. Net
- Система, управляемая сообщениями
- By byte (8-битовое целое без знака)
- h дескриптор (handle) - обычно DWORD
- quot;SubSystem"->"/SUBSYSTEM:WINDOWS" или "/SUBSYSTEM:CONSOLE"
- Include "windows. H". Lresult callback windowproc(. Lparam lparam). Paintstruct PS;. HDC hdc;. Char lpszhello[]="hello, World. ";. Switch (wmessage). HDC = beginpaint(hwnd, &ps);. Rect RT;. Getclientrect(hwnd, &rt);. Amp;rt,dt_
- Подготавливаем данные класса окна и регистрируем его
- LPARAM lParam; // конкретный смысл которой зависит от
- Регистрация класса окна и Создание окна
- BOOL InitInstance(HINSTANCE hInstance, int nCmdShow,
- Оконная процедура регистрируется в системе и вызывается всякий раз, когда Windows выполняет какую-либо операцию над окном приложения.
- GetClientRect(hWnd, &rt);. DrawText(hdc,lpszHello,strlen(lpszHello),&rt,DT_LEFT);. EndPaint(hWnd, &ps);. case WM_DESTROY: PostQuitMessage(0); break;. return DefWindowProc(hWnd,wMessage,wParam,lParam);. return 0;
- Общие сведения о сообщениях Win32
- Аппаратные (входные данные от мыши, клавиатуры и таймера);
- Список (list Box) –элемент отображения списка элементов, позволяющий пользователю выбрать один или несколько из них.
- пиктограммы (icons) – битовые массивы, использующиеся для визуального представления различных объектов в системе.
- CCmdTarget - базовый класс для всех объектов, которые могут получать и отправлять сообщения.
- Шаг2. Выбираем «An empty project»
- Макросы-компоненты карты сообщений
- afx_msg void OnLButtonUP(UINT nFlags, CPoint point);
- Nmhdr *pnotifystruct, //указатель на структуру с данными
- Посылает сообщение в объект класса cwnd или его потомка, непосредственно вызывая оконную процедуру, и не выходит из нее, пока та не обработает сообщение;
- strMessageText.Format("Error number %d", nError);
- Архитектура «Документ-представление» и MDI-приложения
- HMENU CMDIChildWnd::m_hMenuShared
- дескриптор меню, ассоциированного с окном “MDI child”.
- CDocument* CView:: GetDocument()
- Динамическое создание с помощью конструктора
- virtual POSITION CDocument::GetFirstViewPosition()
- Класс шаблона cdoctemplate в приложении отвечает за взаимодействие документов, их представлений и фреймов. В MDI приложении используется его потомок cmultidoctemplate.
- CMultiDocTemplate* pDocTemplate;
- CFrameWnd* pFrame,CDocument* pDoc, BOOL bMakeVisible=TRUE);
- POSITION CWinApp::GetFirstDocTemplatePosition()
- Документ, связанный с активным представлением
- AFX_THREADPROC pfnThreadProc, // Глобальная функция потока
- UINT Msg, // идентификатор сообщения
- Solver* pSolver; //Solver to use
- virtual CDocument* CFrameWnd::GetActiveDocument()
- SendMessage(WM_COMMAND,ID_FILE_SAVE,0);
- while (::GetMessage(&msg, NULL,0,0))
- Объекты, объявленные как volatile, не подвержены оптимизации и временному хранению в регистрах, но читаются и записываются каждый раз напрямую в память.
Тестирование в итеративном жизненном цикле проекта
Жизненный цикл разработки ПО.
(см., например, Ф. Крачтен. Введение в Rational Unified Process. – М. Изд. дом "Вильямс", 2002)
Классический подход к разработке ПО включает водопадный жизненный цикл. При таком подходе разработка последовательно проходит фазы анализа требований, проектирования, программирования и тестирования элементов, а также тестирования подсистем и всей системы в целом. Основной проблемой данного подхода является рост риска со временем; так что устранять ошибки предыдущих фаз становится слишком дорого. Первоначальный проект, наверняка, будет иметь изъяны в ключевых требованиях, и позднее обнаружение проектных недоработок может привести к перерасходу средств или отказу от проекта.
Альтернативой водопадному подходу является поэлементный итерационный процесс:
· Первоначальное планирование
o планирование
o анализ и проектирование
o реализация
o тестирование (при каждой итерации создается выполнимая версия)
o распространение
· Оценка
При таком подходе установление рисков, угрожающих проекту, осуществляется на более ранних этапах жизненного цикла, когда еще можно эффективно и своевременно реагировать на них.
Итеративный подход
Итеративный процесс дает множество решений, устраняющих основные причины проблем водопадного метода. В частности, непрерывное итеративное тестирование позволяет объективно оценить состояние проекта. В результате существенные недоразумения становятся очевидными на ранних этапах. Нагрузка команды (особенно испытателей) возрастает по мере развития проекта.
Тестирование – не обособленный вид деятельности и не фаза проекта, в которой выполняется оценка качества. Если разработчикам нужна своевременная обратная связь с качеством продукта, то тестирование должно производиться в течение всего жизненного цикла: тестировать можно функциональные возможности ранних прототипов, устойчивость архитектуры (при этом всегда можно подкорректировать неудачные решения). Можно протестировать и конечный продукт для оценки его готовности к передаче в руки заказчиков. Существует распространенная точка зрения, что тестирование – это финальная проверка глобальной работоспособности. Однако в такой ситуации упускается основное преимущество тестирования: возможность организации обратной связи, когда еще есть время и ресурсы для принятия необходимых мер.
Присутствие в бригаде разработчиков лиц, занимающихся испытаниями, необходимо по двум главным причинам. Во-первых, испытатели способствуют более четкому формулированию требований, поскольку смотрят на эти требования с несколько иной точки зрения, чем разработчики (это позволяет раньше обнаруживать ошибки в алгоритмах и неполноту спецификаций и ускорить разработку проекта). Во-вторых, сами масштабы работы испытателей делают целесообразным их подключение к разработке уже на этапе проектирования.
В контексте объектно-ориентированной архитектуры тестирование должно охватывать как минимум три направления:
· Тестирование модулей. Предполагает тестирование отдельных классов и механизмов.
· Тестирование подсистем. Предполагает тестирование целых категорий классов или подсистем.
· Тестирование системы. Предполагает тестирование системы как целого. Входит в обязанности контролеров качества.
Возможно, самым главным количественным показателем качества продукта является количество обнаруживаемых ошибок при его тестировании. График количества обнаруженных ошибок в процессе тестирования (в случае управляемого проекта) должен иметь форму горба, с вершиной примерно в середине периода тестирования, а дальше эта кривая должна падать почти до нуля. Неуправляемому процессу соответствует неубывающая по времени или медленно убывающая кривая.
В процессе итеративного продвижения по жизненному циклу проекта можно вести непрерывный сбор данных о количестве обнаруженных ошибок. При каждом новом релизе, начиная с самых ранних, эта кривая должна иметь форму горба.
|
