Home > Community > Blogs > System Design and Verification > android system verification part 5
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Android System Verification Part 5

Comments(0)Filed under: System Design and Verification, android, GPS

In the previous article I introduced the use of Specman for generating sequences of commands to send to the Android emulator. I demonstrated a better way to generate hardware stimulus compared to using the original telnet connection to the Android console. The technique was also better than trying to think of all possible combinations of commands and trying to create a script or C program to cover everything. Today, I will demonstrate how to use coverage to understand the generated sequences and identify areas were additional sequences might be needed to cover holes.

The first thing we can easily do is to create a coverage item for the kind of sequence we generate and send to the Android emulator:

extend sw_sequence {
   cover ended is {
        item kind using ignore = (kind == RANDOM or
                                  kind == SIMPLE or
                                  kind == MAIN);
        item kind using also text = "sequence type";
   };
};

Transition coverage is an easy way to see which type of command followed another command type. For example, did we ever change the network delay after a call was placed on hold? This can be done with a single line to the previous cover statement:

transition kind;

Another coverage scenario might to be cover the length of the SMS messages received. Historically, the maximum length of an SMS was set at 160 characters, this includes any letters, numbers, and punctuation. Subsequently most phones started supporting longer messages by breaking them into multiple 160 character SMS messages. Coverage can be used to make sure Android correctly handles all different message lengths.

When I was doing some testing of the SMS message length I came across this post, a user complaint about the Android Messenger saying that only a maximum of 3*160 characters are supported and larger messages were converted to MMS (which may have different pricing depending on the user's plan).

extend  SMS sw_sequence {
   cover ended is also {
      item sms_cmd using text = "SMS command type";
      item sms_length using ranges = {
          range([0], "Zero Length", UNDEF, 1);
          range([1..160], "Normal Length", UNDEF, 1);
          range([161..480], "Long Length", UNDEF, 1);
          range([481..MAX_INT], "Very Long Length", UNDEF, 1);
      };
      item sms_type using text = "Normal or Long SMS (160 characters or less is normal)";
   };
};

Coverage provides a way to merge and view the results of multiple tests. This gives a complete view of all of the system activity over the full set of tests. The screen shot below shows the coverage GUI. The right side shows the transition coverage of the sequence kind.

 

Photobucket 

The next step is to implement checking so that we can be sure that the generated sequences actually succeed. Right now, we can send a command to make a phone call, put a call on hold, or set the GPS location, but how do we know these commands were actually carried out correctly? This is where checking comes in. Checking is needed to close the loop so we can send commands and check they were done correctly, but this will be the topic for next time.

Jason Andrews

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.