Linux Standard Base Основной современный стандарт Linux, стандарт ISO/IEC 23360 с 2005 года Определяет состав и поведение основных системных библиотек.

Slides:



Advertisements
Similar presentations
Configuration management
Advertisements

Configuration management
Model Based Testing in Linux Standard Base Compliance Program A.V.Khoroshilov, A.K.Petrenko { khoroshilov, petrenko ispras.ru MBT Users Conference.
Chapter 2 – Software Processes
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Dr Gordon Russell, Napier University Unit Data Dictionary 1 Data Dictionary Unit 5.3.
Research topics Semantic Web - Spring 2007 Computer Engineering Department Sharif University of Technology.
Configuration Management
Chapter 3 Software Two major types of software
Database Systems: Design, Implementation, and Management Ninth Edition
Chapter 1 Database Systems. Good decisions require good information derived from raw facts Data is managed most efficiently when stored in a database.
Enterprise Systems & Architectures. Enterprise systems are mainly composed of information systems. Business process management mainly deals with information.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
Chapter 2: Software Process Omar Meqdadi SE 2730 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Configuration Management (CM)
5 - 1 Copyright © 2006, The McGraw-Hill Companies, Inc. All rights reserved.
AL-MAAREFA COLLEGE FOR SCIENCE AND TECHNOLOGY INFO 232: DATABASE SYSTEMS CHAPTER 1 DATABASE SYSTEMS Instructor Ms. Arwa Binsaleh.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
MVC WITH CODEIGNITER Presented By Bhanu Priya.
©© 2013 SAP AG. All rights reserved. Product Development Scenario Overview Open Legend Project Manager Scenario Description The following business roles.
International User Group Information Delivery Manuals: Exchange Requirements Courtesy:This presentation is based on material provided by AEC3. Contact.
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
Database Principles: Fundamentals of Design, Implementation, and Management Chapter 1 The Database Approach.
Integrated ALM with Cross-Tool Reporting Kovair Marketing Kovair Software Copyright ©
1 The XMSF Profile Overlay to the FEDEP Dr. Katherine L. Morse, SAIC Mr. Robert Lutz, JHU APL
CS223: Software Engineering
Jens Ziegler, Markus Graube, Johannes Pfeffer, Leon Urbas
Internet Made Easy! Make sure all your information is always up to date and instantly available to all your clients.
An Overview of Requirements Engineering Tools and Methodologies*
Chapter 1 The Systems Development Environment
Working in the Forms Developer Environment
CS 389 – Software Engineering
Chapter 18 Maintaining Information Systems
Computer Aided Software Engineering (CASE)
Software Life Cycle “What happens in the ‘life’ of software”
Chapter 1 The Systems Development Environment
CO6025 Advanced Programming
IS442 Information Systems Engineering
Applied Software Implementation & Testing
Teaching slides Chapter 1.
Chapter 2 – Software Processes
Goal, Question, and Metrics
Tools of Software Development
Chapter 1 Database Systems
Product Development Scenario Overview
Introduction to Software Testing
Component-Based Software Engineering
Software engineering -1
Chapter 13 Quality Management
Automating Profitable Growth™
Analysis models and design models
Chapter 7 –Implementation Issues
For University Use Only
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Decentralized Model-Based Testing of Distributed Systems
Database Systems Design, Implementation, and Management Coronel | Morris 11e ©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or.
Chapter 1 Database Systems
Department of Computer Science Abdul Wali Khan University Mardan
Scriptless Test Automation through Graphical User Interface
Configuration management
Chapter 1 The Systems Development Environment
Overview Activities from additional UP disciplines are needed to bring a system into being Implementation Testing Deployment Configuration and change management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 Tools of Software Development l 2 types of tools used by software engineers:
The Database Environment
Database Systems: Design, Implementation, and Management Tenth Edition
Mark Quirk Head of Technology Developer & Platform Group
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management
Lecture 23 CS 507.
From Use Cases to Implementation
Presentation transcript:

Linux Standard Base Основной современный стандарт Linux, стандарт ISO/IEC 23360 с 2005 года Определяет состав и поведение основных системных библиотек и функций Linux Цель – избавиться от необходимости «подпиливать» приложения под каждый дистрибутив Linux Разрабатывается консорциумом The Linux Foundation SE Department and LVC

Инфраструктура LSB SE Department and LVC

LSB Navigator Интерактивная онлайн-версия спецификации LSB Аналитическая информация о популярных дистрибутивах и приложениях Linux (264 дистрибутива и 1500 приложения) Сервисы LSB Workgroup для поддержки решений Построен на основе центральной базы LSB Database Действующая версия: http://linuxfoundation.org/navigator Shallow tests – simple tests with the only guaranteed purpose of ensuring the interface does not crash (in many cases it is additionally checked that the interface doesn’t return an error code) being called with some particular correct parameters and in the correct environment. This is close to “existence” or “smoke” or “sanity” tests (but beware - these terms are interpreted differently by different experts). We use a new technology and tools (AZOV Framework) for automatic shallow tests generation based on some description of the interfaces, their parameters, interlinks and default values in a database or based on header sources. The core idea here is to augment the database to contain enough information about the interfaces and their dependencies that would allow automatically building correct call chains representing typical scenarios of interface usage. Normal tests – this is the most reasonable level of testing quality. Normal tests check the main functionality and may check a few error scenarios. Most of the existing tests in the industry are of this quality. We have developed T2C Framework to help to automate a lot of tedious tasks in development of conformance tests allowing test developers to focus on test logic not on numerous auxiliary general issues. Drawing an analogy with programming languages, T2C enables effective writing tests in a “high level programming language” compared to “assembly” in manual test development. Deep tests – this is the level when most of the specification assertions are tested in various conditions/states. This level of testing is hard to achieve by manual tests - that’s why we have developed an advanced testing technology UniTESK to automate this. UniTESK is an model-driven technology for automated test development. The key point of the technology is automatic generation of tests based on formal requirement specifications and corresponding test scenarios. UniTESK gives the following benefits (though requiring very good engineers to be involved): Thorough testing is achieved relatively easy by making sophisticated computer algorithms responsible for test sequences generation based on high level scenario descriptions in SeC language. Separating specifications and test scenarios allows independently changing the tests as requirements evolve and improve test coverage thoroughness as resources appear. Automatic test generation allows smooth parameterization and customization thus facilitating adaptation of the tests for various usage conditions (e.g. for pared-down embedded Linux systems or extended enterprise requirements). SE Department and LVC

Инструменты для выполнения тестов для LSB Библиотеки для выполнения тестов: Linux App Checker (тестирование приложений) LSB Distribution Checker (тестирование дистрибутивов) Основные черты: Web-интерфейс для запуска тестов и анализа результатов Интеграция с базой известных проблем и ошибок SE Department and LVC 4 of 18 4

There are three major areas in which ISP RAS participates in collaboration with LF: The first thing is extending test coverage of the LSB tests. The problem is that now only about 20% of interfaces are somehow tested. We definitely need to develop more tests to cover 100% of interfaces. The quality of testing should depend on the importance of interfaces - deep quality for important interfaces, shallow testing for not important. The next thing is that we need to review and improve the quality of the standard text to make it suitable for using by application and upstream developers. We started these two activities in the OLVER project for LSB Core (1 500 interfaces) and need to extend our experience to the whole LSB (30 000 interfaces now). Finally we need to create new infrastructure for making LSB practically useful for the masses of application developers and allow LSB workgroup and its stakeholders easier and more consistently tracking the Linux evolution and reflect the industry needs in future versions of the standard. Currently we are developing the following things: The backbone thing is a central LSB database that need to hold all the LSB related information: LSB constituent elements, Linux ecosystem tracker (to track applications and distributions and their evolution in terms of compatibility), various information for LSB development decision making. LSB Navigator – a web portal for interaction between Linux developers, Linux distribution vendors and LSB workgroup. It will be an interactive system for querying, analyzing and submitting various information. The beta version is available at the linuxtesting site, the link is announced in the press articles (see the LF site). Test Execution Framework – a framework for user friendly execution of LSB tests and analysis of the results. The first version is already deployed in the production as announced in the newest Linux Foundation press release as a part of LSB 3.1 Update 1. Certification System – an automated framework for conducting distribution and application certification for LSB. All the systems must be integrated with information about all the key elements linked to each other - distributions, applications, upstream components, tests and LSB specification. Важное замечание – это текущий взгляд на задачи, но на самом деле постоянно появляются новые задачи и потребности.

AppChecker – совместимость с дистрибутивами

Немного статистики LSB 4.1 (выпущен в февраля 2011 года) - 57 библиотек, ~40.000 функций Типичный дистрибутив (1 DVD диск) - ~500 библиотек, ~600.000 функций База знаний LSB: ~300 дистрибутивов ~1500 приложений Shallow tests – simple tests with the only guaranteed purpose of ensuring the interface does not crash (in many cases it is additionally checked that the interface doesn’t return an error code) being called with some particular correct parameters and in the correct environment. This is close to “existence” or “smoke” or “sanity” tests (but beware - these terms are interpreted differently by different experts). We use a new technology and tools (AZOV Framework) for automatic shallow tests generation based on some description of the interfaces, their parameters, interlinks and default values in a database or based on header sources. The core idea here is to augment the database to contain enough information about the interfaces and their dependencies that would allow automatically building correct call chains representing typical scenarios of interface usage. Normal tests – this is the most reasonable level of testing quality. Normal tests check the main functionality and may check a few error scenarios. Most of the existing tests in the industry are of this quality. We have developed T2C Framework to help to automate a lot of tedious tasks in development of conformance tests allowing test developers to focus on test logic not on numerous auxiliary general issues. Drawing an analogy with programming languages, T2C enables effective writing tests in a “high level programming language” compared to “assembly” in manual test development. Deep tests – this is the level when most of the specification assertions are tested in various conditions/states. This level of testing is hard to achieve by manual tests - that’s why we have developed an advanced testing technology UniTESK to automate this. UniTESK is an model-driven technology for automated test development. The key point of the technology is automatic generation of tests based on formal requirement specifications and corresponding test scenarios. UniTESK gives the following benefits (though requiring very good engineers to be involved): Thorough testing is achieved relatively easy by making sophisticated computer algorithms responsible for test sequences generation based on high level scenario descriptions in SeC language. Separating specifications and test scenarios allows independently changing the tests as requirements evolve and improve test coverage thoroughness as resources appear. Automatic test generation allows smooth parameterization and customization thus facilitating adaptation of the tests for various usage conditions (e.g. for pared-down embedded Linux systems or extended enterprise requirements). SE Department and LVC 7 of 18 7