Testing

• Code Optimization Testing:

Before implementing the backend , it is necessary to carry out some basic testing covering the functionality of all the units and widgets in the app.  In this testing, it was intended to test all the units (classes, methods etc.) ,  whether the widgets are built properly and how all the widgets function in integration. 

These tests were carried out using the dependencies provided by the Flutter framework .                                                                                                  

Dependencies used:  flutter_test

• User Input Validation Testing:

The only time the user inputs some kind of data that'll be stored in the database using the App is, when they are creating or editing the user profile. It is important to define user input validation standards in order to avoid malice usage. 

When deciding the user input validation standards, the following were taken into consideration.

• The data size limitations allowed by the Firestore database such as 1MB as maximum document size. (Refer here the data size quotas of Firestore)

• The practical validation  standards (eg: Contact number would be 10 digits in the country, a valid email would contain '@' sign etc.)

• Security aspect(eg: The minimum no.of characters allowed for a password i.e. minimum password strength,  is one of the decisive factors on the level of security we expect to provide) 

Based on above ,  several such validations were defined for that scenario(user profiles) and each of those were tested as below. 

The validations that were tested:

1. User name:  Minimum length : 3 characters                                                                                                                                                                                                                                                Maximum length : 50 characters

2. Age : Length < 3 (digits)   { Practically, no age limits for users has been defined so far i.e. 1 to 99 years old allowed, if they can use an email account }  

3.  Contact No: 10 digits 

4. Password validity : Minimum length : 3 characters                                                                                                                                                                                                                                                  Maximum length : 50 characters       

5. Email validity                                                                                                                                                                                                            

 These tests were carried out using the UI and the firebase console during the test runs.

The test results were positive(pass) for all of the test cases.

• Device Compatibility Testing:

This App, similar to any e-commerce app,  is designed for a diverse crowd of users . Therefore, it is expected for these users to use the app from a variety of devices . One of the main designing goals was , not to restrict the users from using the app due to some device incompatibility (regardless of the screen size, os version etc.).  

Therefore following tests were carried out to test the device compatibility of the app.

• Testing the app on different devices using Firebase Test Lab ( Robo Test)  :

The following  snapshots show some of the test results.

• Testing the app running on different actual devices:

The mobile app was run in two  different models of smart phones mainly to test with the screen size variations( view mobile screen shots ). The app worked fine in all aspects in both the occasions.

The overall device compatibility test gave satisfactory results and we plan to carry out further testing  in this regard.

• Authentication Testing:

Though this app does not deal with much of personal information of the users, majority of it's operations are related to financial transactions in one way or other. Moreover, the app gives access to view  past/present shopping activities of the user. Therefore, user authentication is of much importance to provide the required security.

The following are the test results related to user authentication that were tested using the UI  through several test runs.

-The user receives a verification email during sign up.

-Login is not allowed for an incorrect username or password.

-A user can not register with an email address that's already been registered.

-User can change the password (Forgot password option).

• Database Testing:

The major point of focus here is providing the user with the latest product details . Therefore, the App carries less offline content and almost all data are retrieved from the cloud database.  There are many features that the App offers which are or related to some monetary transactions like buy-now option and placing on the way or delivery orders.  Therefore, it is important to test the data retrieval, saving, data formats and also database querying, thoroughly.

Therefore, the following were tested with the use of the UI and the Firebase console.

1. The backend related operations

• Retrieving  product details  based on category.:-Needed to test whether the querying works fine .

• User profile  creation and editing. :- At user profile creation a document with the id being uid of the user(which is given at the authentication) should be created. And querying for choosing the right document for editing  should work fine.

• Delivery orders /On the way orders :  A document with uid should be created/edited. Querying for editing should work fine.

All these operations gave expected results during the final test runs. 

2. Practical issues 

• Data retrieval takes a variable time period.:- During first few test runs,  data retrieval was not synchronized well and sometimes resulted in errors due to delays. This was fixed by changing the code (with  suitable builders etc.)

EMBEDDED SYSTEM TESTING 

• It is performed on both software and hardware.

•  It is basically performed on hardware.

• it can be either white box or black box testing.

• It is performed on the embedded systems.

• It is not related to database.

• Behavior of the hardware is tested.

• It is majorly manual.

• It is less costly as compared to software testing.

What we testing

• connectivity test

check power is present for the component

check the reset pin and other configuration related pins

check he connectivity of programming port

We can test the connectivity test using ossiloscope or logic logic analyzer when designing the hardware.

• firmware testing(when programming microcontroller)

compiler optimization

variable overflow

typos

We can test the firmware test using

• • unit testing

  • static code analysis(sonarqube)

  • Platform.io(Cross-platform PlatformIO IDE and Unified Debugger · Static Code Analyzer and Remote Unit Testing Multi-platform and Multi-architecture Build System · Firmware File Explorer and Memory Inspection)

• RFID tracking

However, the exploration process of deploying such a system can be overly tedious, and the results of the deployment are often too random to be reliably generalized. RFID deployments typically suffer from problems such as:

1) Receiving too little energy from tags

2) Being too vulnerable to environmental factors

3) Cross coupling of neighboring tags (i.e., the couplingof a signal from one tag to another)

4) Requiring too much tuning

Thus, when deploying an RFID system, we need to test it to ensure its reliability and quality. The testing process involves a series of activities to evaluate and determine whether the system meets its required results under controlled conditions.

For example, under a certain hardware and software configuration, a user of a system in an interface performs some operations and obtains particular results. We need to ensure that results meet our requirements. The testing techniques mainly involve executing a program in order to find bugs. Such testing can be very time-

SD CARD

• Checking the speed of read write in SD CARD

• MEMORY TESTING 

The purpose of a memory test is to confirm that each storage location in a memory device is working.Memory Testing is performed when prototype hardware is ready and the designer needs to verify that address and data lines are correctly wired and memory chips are working properly.Basic idea implement in testing can be understood by this simple task:

Write some set of Data values to each Address in Memory and Read it back to verify.

Ex. If number ’50’ is stored at a particular Address it is expected to be there unless rewritten or erased.

If all values are verified by reading back then Memory device passes the test.Only through careful selection of data values can make sure passing result to be meaningful.

Difficulties involved in memory testing:

It can be difficult to detect all memory problems with a simple test.

Many Embedded Systems include Memory Tests only to detect catastrophic memory failures which might not even notice memory chips removal.

COMMON MEMORY PROBLEMS

Memory Problems rarely occur with the chip itself, but due to a variety of post production tests to check quality this possibility is ruled out.Catastrophic Failure is a memory problem that occurs due to physical and electrical damage, it is uncommon and easily detectable.A common source of memory problems is associated with the circuit board. Typical circuit board problems are:

Circuit board wiring between Processor & Memory device.

•  Missing Memory chip.

• Improperly inserted Memory chip.

Errors in Circuit board wiring between Processor & Memory device.

These are usually caused by,

• An error in design

• An error in production of the board

• Any damage after manufacture

TEST WE CAN DONE

 A data bus test: Checks electrical wiring problems

An address bus test: Checks improperly inserted chips

A device test: Checks to detect missing chips and catastrophic failures and problems with the control bus wiring

Address Bus Test

 Address bus problems lead to overlapping memory locations.In the Address Bus test we need to confirm that each of the address pins can be set to 0 and 1 without affecting any of the others.The smallest set of address that will cover all possible combinations is the set of “power of two” addresses.After writing one of the addresses, we must check none of the others has been overwritten.

 Device Test

 It is used to test if the memory device is working properly. It is necessary to test the integrity of the memory device itself.The thing to test is that every bit in the device is capable of holding both 0 and 1.For a thorough and complete device test every memory location has to be visited twice