UART in depth

http://web.engr.oregonstate.edu/~traylor/ece473/lectures/uart.pdf

Advertisements

What is Traceability Matrix?

Traceability Matrix is a document used for tracking the requirement, Test cases and the defect. This document is prepared to make the clients satisfy that the coverage done is complete as end to end, This document consists of Requirement/Base line doc Ref No., Test case/Condition, Defects/Bug id. Using this document the person can track the Requirement based on the Defect id.

Bug Error and Defect

What is Defect Leakage ?

Defect leakage occurs at the Customer or the End user side after the application delivery. After the release of the application to the client, if the end user gets any type of defects by using that application then it is called as Defect leakage. This Defect Leakage is also called as Bug Leak.

What are the contents in an effective Bug report?

Project, Subject, Description, Summary, Detected By (Name of the Tester), Assigned To (Name of the Developer who is supposed to the Bug), Test Lead ( Name ), Detected in Version, Closed in Version, Date Detected, Expected Date of Closure, Actual Date of Closure, Priority (Medium, Low, High, Urgent), Severity (Ranges from 1 to 5), Status, Bug ID, Attachment, Test Case Failed (Test case that is failed for the Bug)

What is Bug Life Cycle?

Bug Life Cycle is nothing but the various phases a Bug undergoes after it is raised or reported.

  • New or Opened
  • Assigned
  • Fixed
  • Tested
  • Closed

What is Error guessing and Error seeding ?

Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them.

Error Seeding is the process of adding known faults intentionally in a program for the reason of monitoring the rate of detection & removal and also to estimate the number of faults remaining in the program.

What is the difference between Bug, Error and Defect?

Error : It is the Deviation from actual and the expected value.

Bug : It is found in the development environment before the product is shipped to the respective customer.

Defect :
It is found in the product itself after it is shipped to the respective customer.

Why does software have bugs?

  • Miscommunication or no communication – about the details of what an application should or shouldn’t do
  • Programming errors – in some cases the programmers can make mistakes.
  • Changing requirements – there are chances of the end-user not understanding the effects of changes, or may understand and request them anyway to redesign, rescheduling of engineers, effects of other projects, work already completed may have to be redone or thrown out.
  • Time force – preparation of software projects is difficult at best, often requiring a lot of guesswork. When deadlines are given and the crisis comes, mistakes will be made.

Types of Software Testings

Explain Load, Performance, Stress Testing with an example

Load Testing and Performance Testing are commonly said as positive testing where as Stress Testing is said to be as negative testing.

Say for example there is an application which can handle 25 simultaneous user logins at a time. In load testing we will test the application for 25 users and check how application is working in this stage, in performance testing we will concentrate on the time taken to perform the operation. Where as in stress testing we will test with more users than 25 and the test will continue to any number and we will check where the application is cracking the Hardware resources.

What is Security testing?

It is a process used to look out whether the security features of a system are implemented as designed and also whether they are adequate for a proposed application environment. This process involves functional testing, penetration testing and verification.

What is Installation testing?

Installation testing is done to verify whether the hardware and software are installed and configured properly. This will ensure that all the system components were used during the testing process. This Installation testing will look out the testing for a high volume data, error messages as well as security testing.

What is AUT ?

AUT is nothing but “Application Under Test”. After the designing and coding phase in Software development life cycle, the application comes for testing then at that time the application is stated as Application Under Test.

What is Negative testing?

Negative testing – Testing the system using negative data is called negative testing, e.g. testing the password where it should be a minimum of 8 characters so testing it using 6 characters is negative testing.

What is Ad-hoc testing?

Ad hoc testing is concern with the Application Testing without following any rules or test cases.

For Ad hoc testing one should have strong knowledge about the Application.

Describe bottom-up and top-down approaches in Regression Testing.

Bottom-up approach : In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module.

Top-down approach : In this approach testing is conducted from main module to sub module. if the sub module is not developed a temporary program called STUB is used for simulate the submodule.

What is the difference between structural and functional testing?

Structural testing is a “white box” testing and it is based on the algorithm or code.

Functional testing is a “black box” (behavioral) testing where the tester verifies the functional specification.

What is Re- test ? What is Regression Testing ?

Re- test – Retesting means we testing only the certain part of an application again and not considering how it will effect in the other part or in the whole application.

Regression Testing – Testing the application after a change in a module or part of the application for testing that is the code change will affect rest of the application.

What is UAT testing? When it is to be done?

UAT testing – UAT stands for ‘User acceptance Testing. This testing is carried out with the user perspective and it is usually done before the release.

What are the basic solutions for the software development problems?

  • Basic requirements – clear, detailed, complete, achievable, testable requirements has to be developed. Use some prototypes to help pin down requirements. In nimble environments, continuous and close coordination with customers/end-users is needed.
  • Schedules should be realistic – enough time to plan, design, test, bug fix, re-test, change, and document in the given schedule.
  • Adequate testing – testing should be started early, it should be re-tested after the bug fixed or changed, enough time should be spent for testing and bug-fixing.
  • Proper study on initial requirements – be ready to look after more changes after the development has begun and be ready to explain the changes done to others. Work closely with the customers and end-users to manage expectations. This avoids excessive changes in the later stages.
  • Communication – conduct frequent inspections and walk-through in appropriate time period; ensure that the information and the documentation is available on up-to-date if possible electronic. More emphasize on promoting teamwork and cooperation inside the team; use prototypes and proper communication with the end-users to clarify their doubts and expectations.

What are the common problems in the software development process?

  • Inadequate requirements from the Client – if the requirements given by the client is not clear, unfinished and not testable, then problems may come.
  • Unrealistic schedules – Sometimes too much of work is being given to the developer and ask him to complete in a Short duration, then the problems are unavoidable.
  • Insufficient testing – The problems can arise when the developed software is not tested properly.
  • Given another work under the existing process – request from the higher management to work on another project or task will bring some problems when the project is being tested as a team.
  • Miscommunication – in some cases, the developer was not informed about the Clients requirement and expectations, so there can be deviations.

What software testing types can be considered?

Black box testing – This type of testing doesn’t require any knowledge of the internal design or coding. These Tests are based on the requirements and functionality.

White box testing – This kind of testing is based on the knowledge of internal logic of a particular application code. The Testing is done based on the coverage of code statements, paths, conditions.

Unit testing – the ‘micro’ scale of testing; this is mostly used to test the particular functions or code modules. This is typically done by the programmer and not by testers; it requires detailed knowledge of the internal program design and code. It cannot be done easily unless the application has a well-designed architecture with tight code; this type may require developing test driver modules or test harnesses.

Sanity testing or Smoke testing – This type of testing is done initially to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing the systems in every 5 minutes or corrupting databases, the software may not be in a ‘sound’ condition to proceed for further testing in its current state.

Functional testing – This a commonly used black-box testing geared to check the functional requirements of an application; this type of testing should be done by testers.

Integration testing – This testing is combining the ‘parts’ of an application to determine if they function together correctly. The ‘parts’ can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to the client/server and distributed systems.

Incremental Integration testing – This is continuous testing of an application when a new functionality is added the existing ones; it checks the application functionality by verifying whether it works separately before all parts of the program are completed, in this type it will be checked whether to introduce test drivers or not; this is done by programmers or by testers.

Regression testing – This is testing the whole application again after the fixes or the modifications are done on the software. This is mostly done at the end of the Software development life cycle. Mostly Automated testing tools are used for these type of testing.

System testing – This is a type of black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.

End-to-end testing – This is similar to system testing; this involves testing of a complete application environment such as interacting with a database, using network communications, or interacting with other hardware, applications and so on.

UAT ( User Acceptance Testing ) – This type of testing comes on the final stage and mostly done on the specifications of the end-user or client.

Usability testing – This testing is done to check the ‘user-friendliness’ of the application. This depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.

Compatibility testing – Testing how well the software performs in a particular hardware, software, operating system, network etc.

Comparison testing – This is nothing comparing the software strengths and weakness with another competing product.

Mutation testing – This is another method for determining if a set of test data or test cases is useful, by purposely introducing various code changes or bugs and retesting with the original test data or cases to determine whether the ‘bugs’ are detected.

Embedded Questions and Answers

Related To All the Questions:

Memory Related Explanations:

Basic concepts on Endianness

  • Big-Endian means that the most significant byte of any multibyte data field is stored at the lowest memory address, which is also the address of the larger field.
  • Little-Endian means that the least significant byte of any multibyte data field is stored at the lowest memory address, which is also the address of the larger field.

How to switch from one format to the other?

It is very easy to reverse a multi-byte number if you need the other format, it is simply a matter of swapping bytes and the conversion is the same in both directions. The following example shows how an Endian conversion function could be implemented using simple C unions:

unsigned long ByteSwap1 (unsigned long nLongNumber)

{

   union u {unsigned long vi; unsigned char c[sizeof(unsigned long)];};

   union v {unsigned long ni; unsigned char d[sizeof(unsigned long)];};

   union u un;

   union v vn;

   un.vi = nLongNumber;

   vn.d[0]=un.c[3];

   vn.d[1]=un.c[2];

   vn.d[2]=un.c[1];

   vn.d[3]=un.c[0];

   return (vn.ni);

}

Note that this function is intented to work with 32-bit integers.

A more efficient function can be implemented using bitwise operations as shown below:

unsigned long ByteSwap2 (unsigned long nLongNumber)

{

   return(((nLongNumber&0x000000FF)<<24)+((nLongNumber&0x0000FF00)<<8)+((nLongNumber&0x00FF0000)>>8)+((nLongNumber&0xFF000000)>>24));

}

A 16-bit version of a byte swap function is really straightforward:

unsigned short ByteSwap4 (unsigned short nValue)

{

   return (((nValue>> 8)) | (nValue << 8));

}

Finally, we can write a more general function that can deal with any atomic data type (e.g. int, float, double, etc) with automatic size detection:

#include <algorithm> //required for std::swap

#define ByteSwap5(x) ByteSwap((unsigned char *) &x,sizeof(x))

void ByteSwap(unsigned char * b, int n)

{

   register int i = 0;

   register int j = n-1;

   while (i<j)

   {

      std::swap(b[i], b[j]);

      i++, j–;

   }

}

For example, the next code snippet shows how to convert a data array of doubles from one format (e.g. Big-Endian) to the other (e.g. Little-Endian):

double* dArray; //array in big-endian format

int n; //Number of elements

for (register int i = 0; i <n; i++)

   ByteSwap5(dArray[i]);

Who to know whether system uses big endian or little endian format and how to convert among them?

Here is a small code segment to determine the endianess of a system at run time.
1)      short int number = 0x1;
          char *byte = (char*)&number;
          if ( byte[0] )
                    printf(“Little endian”);
          else
                    printf(“Big endian”);
                                     
OR
2)      unsigned int a = 0x01;
a = a>>1;
if(a){
          printf(“little endian”);
}

else{
          printf(“big endian”);
}

How to dynamically test for the Endian type at run time?

You can use the following function to see if your code is running on a Little- or Big-Endian system:

#define BIG_ENDIAN      0

#define LITTLE_ENDIAN   1

int TestByteOrder()

{

   short int word = 0x0001;

   char *byte = (char *) &word;

   return(byte[0] ? LITTLE_ENDIAN : BIG_ENDIAN);

}

This code assigns the value 0001h to a 16-bit integer. A char pointer is then assigned to point at the first (least-significant) byte of the integer value. If the first byte of the integer is 0x01h, then the system is Little-Endian (the 0x01h is in the lowest, or least-significant, address). If it is 0x00h then the system is Big-Endian.

Similarly,

bool IsBigEndian()

{

   short word = 0x4321;

   if((*(char *)& word) != 0x21 )

     return true;

   else

     return false;

}

which is just the reverse of the same coin.

You can also use the standard byte order API�s to determine the byte-order of a system at run-time. For example:

bool IsBigEndian() { return( htonl(1)==1 ); }