 so last time we had seen some of the embedded software testing specific, so we had the build-to-speed requirements for embedded software testing, then the marketing driver, course objectives, the question, and whatever learning welcome, and we had a directly session about whatever the session we are going to have, there are a planned session of the embedded software of embedded connection, okay, so today's session I am going to touch upon some of the embedded system testing what we have discussed last time, okay, so here is embedded system, there are two kinds of system, one is the general purpose system, the other one is the embedded system, so how do we do this, okay, so general purpose system is organized set of working functionality doing one or more tasks according to a fixed program or on set of, so it is intended for general purpose, like general computing, calculation or any of the basic dialogs and etc., for example we use the desktop laptop for our general purpose activities or any other computing system such as server, mainframe, computer etc., these are large computing systems, so these are all categorized under general computer system or general purpose system, so now coming to embedded system, so an embedded system is a standalone system customized for a specific platform, so it is intended for doing certain functionality only, so unlike a general desktop or laptop system, so this is meant for doing certain application, certain target based system or some computing or anything other than general purpose, what is the word embedded system, unlike a PC embedded system is not designed to be programmed by any user, whereas a PC a personal computer will have programming capability intended to be built by the same user, whereas embedded system in specific, embedded system always runs a fixed application, whatever the intended functions of the system, there is a fixed set of feature, fixed amount of application which is intended for embedded system to run, so that is why it is a fixed application, it is meant for, for example we take there are range of applications for embedded systems, there could be space systems or aerospace, military applications, automobiles like ECU, atomic control unit which fits the various parts of the part, then we have home systems, we have telecom something like PDAs, mobile tablets, and we have entertainment system such as the inspector works and these are some of the range of embedded systems of the system, one or the other way this will have an embedded system residing inside, we are intended to give you a specific part, for example aerospace embedded systems will have avionics of systems meant for flight control or cockpit display or brake control or heads of display or flight entertainment etc., similarly we have automobile or automotive embedded systems where power train systems or brake control unit or cameras and camera vision systems reverse their monitoring systems, these are some of the example applications residing within the embedded systems of these domains, so basically these six or seven high level domains list out what are the possible embedded systems which are going to be used within the various domains embedded systems will have multiple subsystems, something like nearest square so we see from the activated any of the interface that it uses, so it can be a group of embedded subsystems as well, so altogether it is called an embedded system, an embedded system is one that has hardware, it is a software embedded in it, it has one of its important components, so here embedded system means it has all the elements of piece of box having certain amount of specific application domain, so for that application domain it needs hardware, suppose a motor needs to be run which is nothing but a motor hardware and there is a hardware suspiciously and to drive that hardware suspiciously we need a piece of software that is embedded software, so all these components are embedded system and it can have multiple embedded systems as well, so what are the broad level components of that application way embedded system, usually embedded system will have a basic micro cluster or micro controller or a digital signal cluster, so we will see in the next what are the micro controller systems we are going to use and are going to use these, these are all the basic purpose cluster, so these clusters are very much hot of the embedded system like we have micro cluster doing all the logic calculations and everything, generally micro controllers are used in the embedded system which is meant for interfacing the various devices doing the processing accordingly we have DSPs which are meant for embedded systems having more sort of calculations or arithmetic or image processing this level of embedded system are developed using DSPs and after the processor part we have memory which is very important the processor will interact with the memory to get the data or to execute the program or instruction on the memory so memory there are two types in a broader way random access memory and real-time RAM in the program I will not talk much about RAM and com so this will be discussed in the specifics of embedded systems in the process, so we have memory the additional memory such as addit, duty, feeding on or use this etc so both are all part of the memory then we have inputs for the embedded systems the inputs could be any canner input or digitizer or amounts or keyboard or user seeing in some inputs which can be unlocked or discrete what are unlocked and what are discrete types probably we will touch base when we do the test cases and all that when we see into the requirement how it is automated etc embedded systems will have to produce outputs or at least the results the results could be an action of what are the inputs the outputs could be a monitor or a printer or driving a motor or displaying some values etc so this will be part of the output components of the embedded system for doing all this we need interfaces interfaces in the field which will interact with the embedded systems as well as the external world external world could be another device or a user or any other process so there are various interfaces that are used for example Ethernet or network connected embedded systems they use it RS32 which is an asynchronous interface typically the computer will have it to get the law and all that this is a serial peripheral interface when we have a I2C then all we know about USB so these are some of the interfaces that embedded systems use some of the embedded systems are like the processor part the memory input interface the output interface and the interface devices okay in continuation of that we have embedded system development environment how it is going to be developed host target development environment will be used host is a digital windows PC it will have a connection with the target embedded system the target will be a digital microcontroller based robots we have decided to make a control of any of the processors or ADSU then once we have this setup available we use debugging there is a tool which will be used it is called integrated development environment with the tool we can use the software code embedded C or any other program to download to the target board and to debug it at a development level we use the IDE environment so these are some of the embedded development environment so this is a typical embedded system development environment but depicted in a simpler way as I said the laptop or desktop is connected to the target system there is a intermediate probe box which will be used for interacting with the target system that is called usually that is used by JTAG or VDM JTAG is the most popular one which will interface with the target system and provide to the host the needed values what are the memory or the interface and we can start, stop the program and all that so this box you can see here will provide the debugging facility to the target so this is a typical embedded system development environment so we will see some of the basic definitions that are used in embedded systems the very elementary definition software development life cycle which is the main framework under which the embedded systems are developed the life cycles will have different phases the requirement or the planning phase then we will have a design then we have implementation that is coding then we have the verification that is verifying the embedded system these are some of the typical software development life cycles phases and debugging is one of the term that is used is used to be act of attempting to determine the cause of the symptoms of malconsistence detected by testing or when it is used to be a problem these are the definitions from various cases from the embedded system we use as we said debugging to debug the target work to see what are the programming issues or any defects what are the changes that are needed those sort of information we use in debug so these are the development definitions errors are the mistake or while programming from the development team they may introduce certain failures or faults they are nothing but errors and then we have faults a bug goal defect which could be used in the hardware or the software that is part of the embedded system the defects are identified to system testing then we have a failure then a fault code is executed it may lead to incorrect results failure means after we deploy the embedded systems into the field it may malfunction or it may not work as expected or accuracy may not be as of the requirement those are all will result in a failure these are some of the embedded systems that are used okay now coming to programming what I told in the yesterday that we need a development environment we need to program it to the target system using certain languages embedded C or embedded C plus plus etc so embedded C is a typical language they use it is very similar to standard C like structured programming is possible and that is the way it is going to be used and there are some restrictions because of the target hardware it will be core and data memory restrictions and time restrictions so embedded C will be programmed with these restrictions because the target system will have a defined memory or defined timing requirement so according to that this programming will be done and in addition we have embedded programming special features dedicated for target hardware target hardware as I said microcontroller and those features like register you say the memory related operations they are all specific to embedded systems so these are all part of the features that are used under embedded C and I depicted here embedded C environment there are two portions which are which is a differentiator the first one is a standard C how they use it in a the below one is embedded C used on the target based development so you can see the difference in terms of C code combined in a PC and the PC the same as x86 there is a personal computer you can generate the object file and the object file is a computer and the linked output will be executed that will be executed on the assembly this is a standard C and we have embedded C environment where C source code is compiled cross compiled what I mean cross compiled means the cross compiler will have compiling instruction the target board is nothing but having the microcontroller not the x86 it will be any of the motor or arm or TTI based microcontroller so see to that there are cross compiler generate object file and those object files will be compiled and it will be generated in executable or binary file which will be banned or it will be programmed into the target board also we have along with the embedded C there are few programming areas which are usually developed in assembly language so there is a assembler along with the compilation which will generate the assembly output which will also be linked along with the library and it will be generated in the executable or binary also this will be deployed into the target board and the target board will be ready for deployment or till the execution or so anything on specific embedded some basics as we progress on the embedded software okay in the last session we have discussed about embedded software testing basic what is testing process of embedded software in order to verify that it satisfies the requirements the whole of testing verification and validation determine whether the system needs the requirements import the components of the common report provide insight into the proper development process why we need testing because the developers could use some of the overview but in bugs are very easy to find the interesting than development post release debugging is very expensive so we cannot afford to leave the product straight away from the development so that would be perfect bugs in the development tools we can use for development please do understand and present the product to the user for the customer and report as a part and we do not want to complain get complain from customer identity defects and we have analysis on cost of embedded software defects costs will increase as we find the defects in different cases cost will be less if we find a problem or if in the design of the requirement and as we go along the different cases of the embedded software system cost will double or it will multiple there are few elements which are be used for embedded software the planning which talks about the plans of development verification and technical inputs for embedded software as a testing activity the system requirement for the software requirement system design for the software design then we have the results all together the technical input for the product certificate for the embedded software system then we have of course the guidelines and standards which are to be used for development of all the above activities we have a testing process for defined test planning which talks about what is the plan test case I am going to have what is the standard what is the process I will follow so once this is laid out then we have the corresponding specification how the test will be developed then once the specification and the procedure script for environment is ready we are going to have the execution test execution could be manually done or automated so running into that or script then we have test coverage as a result of the test execution and we will have a report test report having the output test execution test log or now coming to embedded software testing the environment how the setup will be testing the setup we will have something like this where we have a laptop or desktop and it is interface with the target system the target system means an embedded system which is under test so we will have an interface using an USB or an internet or a scan so we will have the test execution interface with the target system what I mean to say is you have some of the testing driven from the system desktop and the testing data that are required to enter into the system target system will be done with the USB or internet system and for test driven system of the desktop of the user level we will have tools or scripts tools so in USB and LTRT LTA so these are basically one of the tools that are used along with that we can also have scripting mechanism which basically triggers some of the inputs that are required for the specific embedded system the inputs will trigger the input data what is needed for a specific input and it will put in the output the output also can be monitored or viewed the same interface so this is something like an interface hooked for the embedded system from the PC perspective and that interface will be used as an input as well as the output now coming to the embedded system having something like as a black box how it can be triggered like as I said we can drive the data from the desktop as well as there is an alternate mechanism to hook into the embedded system this will be the nearest end user environment something that is called as a test panel so what we do is see embedded system will have a specific application running all the time and certain data will not be realistic when it is running in the field only it will have the realistic input from the user perspective but within the lab environment or the embedded system or testing setup how are you going to feed it with the same test panel the test panel will have a typical discrete inputs analog inputs potential matrix etc also there are test books we will read some of the internet messages or the ITC interface so to produce some of the realistic value the test panel data can be recorded or viewed as a result after the embedded system use is that, in the desktop environment, so this will be the debugging as well as the system embedded testing set up, this will be the test panel to target system and most likely మాసిని చానిన్లిచారిని. నౘంది బాన్ంతి. వార్ ఆరె పాస్ని. So, once we have set up we know I mean we have seen how text should be approached, how text should be done. They have residing in previous system different test methods of the level that are used. that are used that typical ones will acceptance testing user level acceptance testing system testing functional and non functional then we have integration testing and we have so there are four testing methods or testing level one is acceptance testing system testing integration testing and component testing each one we will accept the testing or user testing is also called so this is based on the user specification that means given the MS system or the end product to a user how he will view it that is what this testing will talk about so basically there are certain critical requirements or the critical acceptance procedure which need to be passed these are all part of the acceptance of those requirements then important key features or functionality suppose you take a mobile system the important key features generally what they specify in the requirement of specification it should have a conference call it should enable the wife I should have it should have internet browsing capability photo video audio recording so many features those are all some of the user specifications which can be tested again under the acceptance of the specification usually acceptance testing will not be a serious one it will be a period process minimum set of requirements of the features that will be part of the completion objective will be the time criteria usually will be tested on the field or with the help of the user it can be used by the user or deployed into the market acceptance testing test will validate the business functional requirement what is the system is supposed to do we should validate these are some of the key parameters under the user that is the first level of testing then we have a system testing which is the next level of embedded system testing here in embedded system testing we have the entire embedded system as an integrated unit with complete interfaces involved meaning that the entire end product will be tested as a system so as I said the end-to-end system setup will be used and this end-to-end system will be used for system testing the end-to-end system will have all the features in the functionality and the interfaces that are required with the help of which this embedded system will be completely tested so look at this what I was mentioning is there is a test panel which will give the realistic input against the target system this will be the primary system testing mechanism and the system testing will have an actual environment where how the system will be used in the field for example you want to use some of the components better within the car it will be actually deployed within the car with the test inputs or the environment inputs coming from the car it could be speed of the car while driving the car etc it may not be enough to have the actual environment in the field what will happen is some of the requirements we may have to break the embedded system box or the embedded system elements that is called as the open box type of them for example some of the capability requirements in terms of performance some primary performance or speed performance need to be tested by opening the embedded system box which may result in validating some of the implemented code or going through the code or debugging the code these are categorized as the open box type of testing the system testing is also called as functional testing where all the functions of the embedded system will be tested so that is about the second level of testing we have the next method called integration testing what do we do in integration testing so basically integration testing will have integration of sub-modules of the system under test and which will evaluate the interaction of the all these modules basically we will have suppose ten modules all these ten modules they are called sub-modules will have to be interacted will have to be integrated then it will be evaluated against each modules how they interact how are the data or some of the signals are interacted among the sub-modules all this will be called as the integration testing integration testing could be done at two approaches one is a top-down approach top-down integration where high level of procedures or requirements are addressed first and then low level from the requirements then to design then to code will be attacked in order to complete the testing like the modules at a higher level it is used next method of integration we do is bottom up why because top-down approach may not be enough to complete the requirement based testing so we may have to do some of these unit level integration that means the logical units only need to be where is the first we will begin with unit level functions lowest possible units are first integrated then they are grouped into the next level towards the higher level all these units are tested this is a method of integration testing we have seen acceptance user level testing testing the last one is the unit testing or the component level testing so what we do in component level testing the smallest units or the smallest functionality or the things of the energy system will be tested as a unit as I said there are 10 modules or modules each module or module will have number of functionalities or number of units it may have 5, 1, 2, 10 whatever it is all these will be tested as a unit typically a core function procedure will be called as the unit analysis that unit alone will be tested input what is the functionality and what is the output it produces also we have coverage aspects coming under units that means we need to cover from different perspective it is having a structural coverage industry is very important to have a structural coverage reported and it should be 100% that means 100% of the functionalities of the feature has to be covered and the coverage could be done with the help of statement that is implemented statement or the logical branching of the unit or the MCDC it is nothing but modified condition or decision condition coverage that means it tells value and cases for loops all these will be tested under so it will be used as a coverage the tools that are used for unit testing basically are LDRAs in automotive aerospace the tools will basically help in identity which will generate the coverage of the source code that instrumented code will be run on the target and the unit under test will be tested with the Pascal criterion and almost it is covered here as I said the logical units are used individually or in a group manner so all the units one that is completed it is called as unit testing in a typical embedded system where we have complex functions in aerospace automotive engine control etc it may not be possible for us to completely test at one method that is the big level or integration level so we have to credit based testing that means suppose unit testing we are able to test with the coverage of 80% so there is a 20% gap the 20% gap we can take the credit from integration testing or the system test basically they follow across the industry to have 100% coverage and of course before deployment the fitness of the product user acceptance testing so these are some of the testing methods of levels now we have categories of testing once we have the testing how it is broadly categorized once we have the test setup available the test can be done with the black box test other one is the white box test as I said the black box test will be based on external specification without knowledge of how the system is constructed we do not have to bother about the individual units or the integrated modules in the embedded system unit all we have to see as a black box the test input how we can expect the test output typically as a black box the embedded system as a unit completely with this aspect for example a telephone instrument you take it as a black box how we are going to test it is we connect it to the the telephone wire or telephone jack then we will dial up some number then we will pause with the help of the buttons that are related to instrument so we use as a black box the complete telephone instrument this is under the black box test there is an extra type of testing a test is a white box here we need to know the internal logics of this structure how it is organized how it is designed this is basically driven from the software design or the system design of the embedded system what I mean is there are different logical groups of the embedded product modules which are part of the embedded system those will be tested something like we have 10 design modules which are responsible for 10 different functions as I said when I take up the phone with the telephone jack it should be a dial tone the ring tone how it comes will be responsible by some of the features of the function embedded system those features will be separately as a individually we will test the white box test method usually it will be logical testing or logical it could be development environment also we can use it for white box test where the lowest possible requirements of functionality device drivers or memory or target board we may not be able to feed at a black box what we are going to do is we will use the white box method where we will use the debugger with the help of the debugger we will monitor the memory or the register which will display the values where it is in the integer that is all the next testing type is called regression testing so what we do in the regression testing basically when we have the product done with all these testing methods which may result in what will happen is these testing methods will result in some failure suppose or some changes may happen in terms of fixing the schedule what will happen is it needs to be retested so how it will be retested is using regression testing that means given a black box or given a white box embedded system we will basically address those tests which are failed earlier are supposed to pass now because those failures are reported and those failures are bug fixed so all we need to do is we will re-execute we will not change the test approach or we will not modify the test based on our design what we will do is we will simply run those tests on the packet board so we will use the method for regression testing so testing of the changes have been made to ensure that no unwanted changes are that means apart from whatever the fixes that are required there should not be any additional defects the changes could be due to earlier stages or any improvements like memory they would not modify the changes need not be resulting in any of the requirements the changes could be from the failures of the earlier stages all these will come under consideration and that is all about embedded system testing and test methods and the types of testing that we use in the industry next session we will discuss about test case design