Home

System Test Plan

1. 22 2 6 3 Android Producer Consumer 23 2 6 4 Hardware Producer Consumer 24 RISKS aaa ga Na aan 24 3 1 Intro YUGI ON RR 24 32 Dd 24 33 SystemliCiTis Ks uie coe 24 34 Specitic Risks that affect testing re eee ie n eue esee a aana aa a Na ga 24 a ng Pate VG A TA aaa BAG aaa a aana DG Sa a GA aa BAN bud JAN A Aga eee 25 41 OVEN toit tmt DI b tenuti ERA DANA HA 25 2 TP Version 1 0 ALWAYS mHOMe Test Smart Door 4 2 Reguir ments saranane si aa aa oag eg jeda am E Sae Ge ag aja ea SEK A aa aga gae gg aa a aa AG SINA ea am aine a Kie 27 43 Hardware Validation Tests 01 eerte ga aa a aa ba e 32 44 Unit Test Module Level e ett NG NGANA NA NE BANA DA NGANA veta NDEAN AN va AAN a a aa a a a a aa aaa ada aan 33 4 5 Component level Subsystem Testing 0 n aane anan eee 37 4 6 integration a aana a a 42 4 7 System Verification Testing asasaran ceste e ene
2. 44 4 8 Acceptance oco oe prr yx rre a cua esi aav tp Ue a na aa an 45 5 Features Be Tested 2 2 ANERE ea e eu edat saeua ino a 46 5 1 D 46 5 2 Customer Requirements kn 46 5 3 Packaging 50 5 4 Performance Reguiremente 50 6 Features Notto be Tested certe rete 55 6 1 55 6 2 Customer 55 6 3 Packaging Requirement oec ehe Hb Dr eva eed GA SA 55 6 4 Performance 56 6 52 5 524 a na ag aan is EE 56 6 6 Maintenance and Support 56 6 7 Other Requirement iie E eap dese vance ca ecu ge Qe deed de uh 57 7 lee ETC EE 57 71 Overall Test Strategy eei aa E aa aec Re aa BE a met dewa na de Kak and a 57 7 2 Configurations tested
3. 41 Table 26 Wikayer Inte sratiOnnT GSES aaa aa eee oer En aa ga eas 42 Table 27 Processing Layer Integration Tests 43 Table 28 Network Layer Integration Tests 43 Table 29 Data Storage Layer Integration Tests 44 Table 30 System Verification Tests 44 Table 31 Acceptance Criteria x rere eiae 45 Table 32 Cases re rrt ntn epe de 46 33 Example Test LOE 5 ciet tt ost tee a D a ak ma geg 60 Table 34s Testing Schedule ite eg 61 5 Approvals dee Repo 0 61 6 ALWAYS mHOMe TP Version 1 0 E Test Plan Smart Door Document Revision History Revision Revision 2 03 19 2014 First draft submitted for initial review 04 01 2014 Minor fixes through the document TP Version 1 0 ALWAYS it HOMe q Test Plan Smart Door Introduction 1 1 Product Purpose The Smart Door will allow a homeowner to answer the door remotely The doorbell will connect the homeowner and guest s via a call to the homeowner s smart phone The homeowner will receive the call a snapshot of the guest through a mobile application The homeowner will see this information and will be able to decide if he or she
4. eene nennen aaa na entes seen 22 Table 10 Android Producer Consumer Table esses eene we a nennen aana gen paham Gak ana nada aana rennes 23 Table 11 Hardware Producer Consumer Table 24 Table 12 Requirement Satisfaction Tests aiia Eee aeee epe De Ege dad 28 Table 13 UI Requirements Traceability Matrix subada gae na NE ada Tah aaa eene nnne nnn nnne ama de Ta a ga NE Aa da was 29 Table 14 Processing Requirements Traceability Matrix 30 Table 15 Network Requirements Traceability 31 Table 16 Data Storage Requirements Traceability Matt 32 Table 17 Hardware Verification Test Cases 33 Table 18 UI Layer Unit Tests 35 Table 19 Processing Layer Unit Tests 36 Table 20 Network Layer Unit Tests 37 21 Data Storage Layer Unit Tests oreet teneat Foe one aee aran ae EN gak 37 Table 22 Jl Layer Component Tests eat ue see tate a a de orte aana a aa D aaa gak a aan 39 Table 23 Processing Layer Component Tests 40 Table 24 Network Layer Component Tests pote Ree ee De a ed Ee Gama EX ja mi ka da Gene 41 Table 25 Data Storage Layer 5 5 0 a an a
5. RET Android Function Chooser Figure 1 Layer Diagram TP Version 1 0 ALWAYS ii HOMe q Test Plan Smart Door 2 3 2 Layer Description 2 3 2 1 UI Layer Hardware 1 0 229 2 5 6 02 c Android Android Event n SSES gi be Speaker Interface leb Display Request Handler 2 Doorbell 9 uI 16 117 7 d 5 Android Web GUI Android GUI Senso Door 64 Sensor a Door Lock D Figure 2 Ul Layer The UI layer receives input from the user through our software interface the Web GUI Android GUI It also receives input from the user through our hardware such as the doorbell camera and microphone This layer will be responsible for transmitting input to other layers as well as displaying results from other layers This will include transmitting audio and video into meaningful values to properly stream video This layer will utilize our three different interfaces the hardware the web and mobile device 2 3 2 2 Processing Layer 1 4 017 0110 4 Android Activit 5 Android 2 MIN Data Interpreter Microcontroller App ES 1 M2 1 2 Android Push Notifications Command Video Stream Data Pr
6. 1 Critical 1 Critical 5 4 Response Time 5 4 Response Time Android Event Handler Android Function Handler Android Function Handler Process commands for device control using the Android Application Establish that the time to pass an interaction event through the Android Function Handler is faster than 0 3 seconds User Commands Navigate through website while timing length of time to load pages System will respond correctly to given user commands Action on website will take less than 0 3 seconds to complete 1 Critical 1 Critical 3 1 Smartphone Application Control 5 4 Response Time Establish that the time to process an interaction event through the Android Function Handler is faster than 0 3 seconds Click on a video title and time how long to start downloading video Video download will take less than 0 3 seconds to initiate 1 Critical 5 4 Response Time Android Function Handler Microcontroller BUS Process commands for device control using the Android Application Send the logging message upon the receipt of signal data from hardware devices User Commands Digital Signal from USB devices System will respond correctly to given user commands Actions are logged 1 Critical 1 Critical 3 1 Smartphone Application Control 3 3 Keep Activities Log Microcontroller BUS Establish that the Microcontroller is sending the notifications within
7. Video logging and ability to retrieve videos using the Smart Door web app Smart Door system portability and ease of installation Smart Door system does not interfere with normal operation of door Smart Door system supports multiple Smartphones Table 31 Acceptance Criteria 4 8 2 Test Assumptions Acceptance testing assumes that Unit Module testing Component testing Integration testing and System testing has been completed and passed Acceptance testing assumes that the door lock unlock feature is a future requirement TP Version 1 0 45 5 Test Smart Door 4 8 3 Test Cases Passes when the Smart Door Android app Fails when there is no signal from the Wakes and notifies upon connected receives a notification or call from the Smart Door to the Android App when AT1 doorbell being presed doorbell being rung the door bell is rung It will also fail if Wakes and logs the status of the Passes when the Android app receives Falls when the door doesn t send state connected door upon connected door Door State and the final door state is saved of the door if the Android app doesn t AT2 opening or closing to database after the call receive state or the final door 5 Fails if there is no video stream if there Live video monitoring capability within Passes when the Android app allows the is no monitoring button or ends a AT3 the Smart Door andro
8. SRMDUT 1 Microcontroller 8 video Interaction 3 9 Local Storage WIFI and verify that the video is HDD uploaded from local storage Boot the Smart Door Prototype in Microcontroller order to validate that the Turn on the Unit and verify that it The Smart Door Device will boot MHUT 1 A 4 3 9 Local Storage HDD Microcontroller Application data is boots correctly correctly being properly stored on the HDD Establish that the time to relay an 5 Module relays message less than D 1 SHUT1 Server HDD action message through the module is System action message 1 Critical 5 4 Response Time 0 3 seconds faster than 0 3 seconds Establish that the time to relay Microcontroller 5 2 Module relays message less than vu MHUT 2 action message through the module is System action message 1 Critical 5 4 Response Time HDD 0 3 seconds faster than 0 3 seconds 4 5 Component level Subsystem Testing Component level testing will test the functionality and internal data communication of each individual subsystem Component level testing will not include interfaces across subsystem or architectural layer boundaries These interfaces will be tested during Integration testing 4 5 1 Test Assumptions Component level testing assumes that each module within the subsystem has passed module level testing Component level testing assumes that each subset of related modules within a subsystem has passed unit level t
9. The Smart Door prototype will be installed EE M using the included brackets bracket succesfully Verify that the Smart Door Subjective Evaluation by Desi Smart Door Device prototype is installed in a protective E ja aa an ree 00142205 0 0 20 2 Moderate 4 4 Casing Verify that the always home logo is Subjective Evaluation by Desi Smart Door Device displayed on the Smart Door ublective Evaluation by Design smart Door prototype will be found to be enclosed 4 Low 3 Low 4 7 Team Logo prototype S meee Inspection of SD Card s properties Smart Door Device lt using Windows 7 OS to ensure Storage will exceed 23GBs 3 Moderate 3 Low available for storage adequate storage 5 8 Recording Log Log availability Inspect USB power supply to ensure 5 9 Smart Door Device the voltages operate the Smart Door USB power supply Power Supply will operate the prototype 1 Critical 3 Low Supply prototype Install and operate the Smart Door OUT 39 5 10 Power Power Smart Door Device prototype to ensure it functions Household wiring and receptacle Wiring will operate the prototype 1 Critical 3 Low Gr 120 Mount the Smart 0 t t Smart Door Prototype and ring Smart Door Prototype will be usable at th Smart Door Device oun omar Deor andl me asung D
10. NET Unit Test for unit testing the functions modules and subsystems e Java Development Tools JUnit for unit testing the functions modules and subsystems Thermometer for testing hardware heating 58 TP Version 1 0 ALWAYSmHOMe Smart Door Ruler fortesting the size constraint Timer for testing the system latency 7 6 Scheduling 7 6 1 Schedule Preliminary testing during development so that each component is ready for integration ASAP after development 7 6 2 Detailed schedule See section nine of this document 7 7 Feasibility This is similar to the requirements analysis and review except this focuses on our team s ability to meet project requirements If the team is unable to deliver a product that meets its specifications then we will need to determine how feasible the feature is that is not meeting requirements This is a combination of Risk Management but requires a QMP for qualitative and quantitative analysis 1 8 Test Deliverables 8 1 Test Plan The Test Plan describes all aspects of our testing program The plan will include our approach test requirements test data and schedule 8 2 Test Cases Test Cases are included in the test plan These are the actual process input and expected output for each test that we will perform 8 3 Test Log The Test Log is a table used during testing to record the results of each test It will include the test ID number testing personnel exp
11. Specification DDS It will be used as a way to validate and verify our product solves the original problem given This includes the Always Home team s requirements and those of our stakeholders 1 4 Document Scope The STP contains a detailed process for testing the Smart Door system on requirements verification unit test component test hardware test and acceptance test 1 4 1 Requirements verification Ensures that the product is complete and built right with respect to the teams and stakeholders requirements 1 4 2 Unit test Ensures that the lowest level of modules work individually avoiding problems when integrating the modules 1 4 3 Component Test Ensures that all modules work together correctly in the subsystem level TP Version 1 0 ALWAYS mHOMe q Test Plan Smart Door 1 4 4 Integration test Ensures that the combination of functions modules and subsystems function together to fulfill the business requirements 1 4 5 Hardware verification Ensures that the hardware systems function as expected individually and in conjunction with other hardware systems 1 4 6 Acceptance test Ensures that the system as a whole satisfies the requirements of the stakeholders References 2 1 0verview The References section of the System Test Plan provides relevant information to documents that were previously completed for our project These documents are the System Requirements Specification SRS the Architecture Design Specifi
12. View Constructor Request Handler Web Display View Constructor Request Handler Initiate video monitoring from the Web Interface Download a video using the Web Interface Navigate Web GUI to Initiate video monitoring from the Web Interface Navigate Web GUI to Download a video using the Web Interface Video stream is displayed on the website video download progress 15 displayed in the web browser 1 Critical 1 Critical 8 1 Web Interface Support 8 1 Web Interface Support Web Display View Constructor Request Demonstrate lock unlock functionality through the Web Interface Demonstrate door status monitoring capability through the Web Interface Navigate Web GUI to lock and unlock the connected door Navigate Web GUI to display the attached door s status open closed locked unlocked Lock unlock notifications are displayed on the website Door status is displayed on the website 1 Critical 1 Critical 8 1 Web Interface Support 8 1 Web Interface Support Display Layout Manager Android Event Handler Android Function Handler USB Interface Microcontroller Bus Verify that the video window displays correctly in the Android Application Watch a streaming video in the android app The video is visible in the central region of the application window 3 5 Video Monitoring USB Interface Microcontroller BUS Android event Handler Android Function Handler USB Interface Microc
13. allocated by a particular layer will have been shown to be satisfied following the successful completion of the tests indicated in sections 3 3 Unit Test 3 4 Component Level Testing 3 5 Integration Testing and 3 6 System Verification Testing The results will be recorded in the Test Log following the completion of each test 23 components contribute to requirement 5 4 Response Time and the total limit is 7 seconds Each contributing item gets 0 3 seconds allocated to it if some actions are performed faster the extra time will be re allocated 27 TP Version 1 0 ALWAYS mHOMe Test Smart Door Smartphone Application Control System Setup Snapshots Taken Notification Time Keep ActivitiesLog MBUSUTI Lateng PI Emergency Power Supply Response Time Video Monitoring Data Transmission Live Video Feed System Portability Data Transmission Audio Transmission Smart Phone Paring Recording Log Log Availability Motion Sensor N A Recording Log Storage Capacity Local Storage Power Power Supply Hardware Security Power Power Source Z Wave N A Emergency Backup Battery Lock Unlock Open Source 2 Operating Environment Nonintrsive Aceountsetupj Video Log Downloads Size Video Photo Resolution Temperature Control System Availability Mounting HRVUTG Notification Limit 1 Cosng Initialization NUTS Software Acquisition Mounting Height Included Components AT8 Microphone Sensi
14. an acceptable timeframe Digital Signal from GPIO connected device Table 18 Layer Unit Tests TP Version 1 0 Actions are logged 35 2 High 5 2 Notification Time ALWAYS its HOMe Test 4 4 4 1 2 Server Communication Manager Android Command Interpreter Server Communication Manager Data Interpreter Data Processor Local Data Access Download the Software from the internet in order to verify that it is available there Establish that the notifications are passed through the module within an acceptable timeframe Establish that the notifications are passed through the module within an acceptable timeframe Establish that the notifications are passed through the module within an acceptable timeframe Establish that the notifications are passed through the module within an acceptable timeframe Establish that the notifications are passed through the module within an acceptable timeframe Establish that the notifications are passed through the module within an acceptable timeframe Processing Layer Unit Tests User Data Notification from Smart Door Prototype Notification from Smart Door Prototype Notification from Smart Door Prototype Notification from Smart Door Prototype Notification from Smart Door Prototype Notification from Smart Door Prototype Software is downloaded Notification is passed within acceptable time 1 5 seconds Notification is passe
15. configurations will not be tested 7 3 Plan to deal with defects identified In order to effectively manage and correct bugs the team will document the follow characteristics in a bug tracking system when a bug is encountered The time the bug was found A Description of the bug How to reproduce the bug Which components are affected by the bug Severity of the bug d wo Name of the person who found the bug Once a bug has been fixed the person who fixed the bug must document the following in the close out report 1 The time the bug was fixed 2 How the bug was fixed 3 Success failure of bug fix 7 4 Metrics The testing metrics used will follow the requirement priority defined in the SRS The modules that satisfy multiple requirements will be assigned the priority of the highest requirement in the array of requirements Priority 1 Critical Critical priority items will severely impact the product and render it useless Priority 2 High High priority items will greatly impact the usability of the product and render it almost obsolete Priority 3 Moderate Moderate priority items will impact the usability of the product but will still be usable Priority 4 Low Low priority items will not impact the usability of the product but will make some task tedious Priority 5 Future Future priority items will only enhance the usability of the product 7 5 Special Requirements for Testing e ASP
16. of SD Card s properties it 19 2 Microcontroller HDD Wenercher epi cee using Windows 7 5 to ensure Storage will exceed 23GBs 3 Moderate 3 Low d Recordin 92165 for storage Availability adequate storage o 7 Inspection of SD Card s properties Ei h 2 GB 8R Server HDD nsore that at least 322 Gps avallable using Windows 7 OS to ensure Storage will exceed 23GBs 3 Moderate 3 Low log Storage Capacity for st USE adequate storage Download a video through the 3 16 Video Lo Microcontroller HDD Website in order to verify that the User Input to website Video will be downloaded 4 Low 3 Low S 5 Downloads video log is available Table 29 Data Storage Layer Integration Tests 4 6 2 System integration 4 6 2 1 Test Assumptions System integration testing is equivalent to the system verification testing The test cases in the system verification tests require a fully integrated system to function correctly 4 7 System Verification Testing Verification testing will confirm that Always Home designed and implemented the Smart Door system in such a way that the system as a whole meets all of the system level requirements Validation confirms that the Smart Door meets the needs of the stakeholders and will occur upon completion of the Acceptance criteria outlined in section six of this document 4 7 1 Test Cases Initiate Call starting from Doorbell stream to phone a us
17. power from a standard household electrical outlet The system shall provide an emergency backup battery that allows it to operate for at least eight hours The system shall provide the appropriate I O ports for interacting with components including but not limited to General Purpose I O ports USB ports and TRS phone jacks The system shall remain operational within humidity ranges from 0 95 12 Smart Door 3 Moderate 2 High 2 High 2 High 2 High 2 High 3 Moderate 3 Moderate Critical Critical 5 Future Item 2 High 2 High 5 Test Smart Door Video Photo Resolution The system shall have recording 2 High capability for photo and video resolution of at least 352x240 pixels Notification Limit The system shall notify the user of 5 Future Item doorbell rings a maximum of 3 times in a 2 minute period where rings will be processed every 30 seconds Mounting Height The system s user manual shall specify Critical that the portion of the system containing the video camera be mounted within a height range of 60 66 inches Table 3 Performance Requirements 13 TP Version 1 0 ALWAYS ii HOMe i Test Plan Smart Door 2 2 4 Safety Requirements Microphone Mounting The microphone shall be secured 3 Moderate properly to prevent a fall or collision hazard The microphon
18. 195 View Communications Reguest Interface Web Controller Server HDD Communications Table 9 Web Producer Consumer Table 22 Version 1 0 4 Test Smart Door 2 6 3 Android Producer Consumer Matrix Table 10 Android Producer Consumer Table 23 TP Version 1 0 ALWAYS ii HOMe ier Test Plan Smart Door 2 6 4 Hardware Producer Consumer Matrix Table 11 Hardware Producer Consumer Table 3 Risks 3 1 Introduction 3 2 Risk Levels Risk 1 High risk of test failure Risk 2 Moderate risk of test failure Risk 3 Low risk of test failure Risk 4 Possibility of inconclusive test Risk 5 Future implementation 3 3 Systemic risks Risk 1 items from Integration tests 3 4 Specific Risks that affect testing Risk 4 items are testing related risks an inconclusive test does not inform the development team 24 TP Version 1 0 ALWAYS mHOMe q Test Plan Smart Door Impact assessment and management plan as it relates to these risks for each risk Should be a table summarizing the impact of EACH risk at ALL levels Management plan for Risk 1 and Risk 4 4 Test Items 4 1 0verview This section will provide details on what will be delivered to the customer These requirements will be based off our previous documentatio
19. 2 High 5 3 Latency Response time should be less than seven seconds 1 Critical 5 4 Response Time Web Display View Constructor Request Handler Display Layout Manager Android Event Handler Android Function Handler Microcontroller BUS GPIO Interface USB Interface Speaker Interface Microcontroller BUS GPIO Interface USB Interface Speaker Interface Establish that the time to pass an interaction event through the system is faster than 7 seconds Insure that the system availability exceeds 95 Navigate through website while timing length of time to load pages Record the uptime of the microcontroller during a one week period and calculate the percent availability Table 26 UI Layer Integration Tests TP Version 1 0 42 Response time should be less than seven seconds Availability should be above 95 up time 1 Critical 5 4 Response Time 5 15 System Availability ALWAYS its Test 4 6 1 2 2 Android Activity Manager Android Command Interpreter Server Communication Manager Android Activity Manager Android Command Interpreter Video Stream Server Communication Manager Processing Layer Check the Status of the Lock and Door sensors using the Android Application Use the Android Application to initiate video monitoring Touch controls on the Android Application Touch controls on the Android Application e Smart Door Door and
20. 3 seconds to complete 1 Critical 1 Critical 1 Critical 5 4 Response Time 5 4 Response Time 5 4 Response Time Request Handler Establish that the time to initiate an action through the Request Handler is faster than 0 3 seconds Verify that the video window displays correctly in the Android Application Click on a video title and time how long to start downloading video Watch a streaming video in the android app Video download will take less than 0 3 seconds to initiate video is visible in the central region of the application window 1 Critical 5 4 Response Time 3 5 Video Monitoring Establish that the time to pass an interaction event utilizing the Display Layout Manager is faster than 0 3 seconds Navigate through website while timing length of time to load pages Action on website will take less than 0 3 seconds to complete 1 Critical 5 4 Response Time Android Event Handler Establish that the time to initiate an action through the Web Interface is faster than 0 3 seconds Establish that the time to pass an interaction event through the Android Event Handler is faster than 0 3 seconds Click on a video title and time how long to start downloading video Navigate through website while timing length of time to load pages Video download will take less than 0 3 seconds to initiate Action on website will take less than 0 3 seconds to complete
21. 4 TP Version 1 0 ALWAYS mHOMe Test 4 4 4 Test Data 4 4 4 1 4 4 4 1 1 Establish that the time to initiate action through the Web Interface is faster than 0 3 seconds Establish that the time to display an interaction event through the Web Interface is faster than 0 3 seconds UI Layer Unit Tests Navigate through website while timing length of time to load pages Click on a video title and time how long to start downloading video Action on website will take less than 0 3 seconds to complete Video download will take less than 0 3 seconds to initiate 1 Critical 1 Critical Smart Door 5 4 Response Time 5 4 Response Time View Constructor View Constructor Request Handler Establish that the time to process an action through the View Constructor is faster than 0 3 seconds Establish that the time to initiate an action through the View Constructor is faster than 0 3 seconds Establish that the time to process an action through the Request Handler is faster than 0 3 seconds Navigate through website while timing length of time to load pages Click on a video title and time how long to start downloading video Navigate through website while timing length of time to load pages Action on website will take less than 0 3 seconds to complete Video download will take less than 0 3 seconds to initiate Action on website will take less than 0
22. 5 2 2 3 Risk Level Low 5 2 3 Keep Activities Log 5 2 3 1 Description This test will verify if the activity logs are different between users 5 2 3 2 Test Approach This test shall manually verify if the systems activity logs are differentiate between users when logging all interactions and activities of the system 5 2 3 3 Risk Level Low 5 2 4 Emergency Power Supply 5 2 4 1 Description This test will verify the capability of the emergency power supply 5 2 4 2 Test Approach This test shall manually verify if the emergency power supply is on and backup the system if there is power outage 5 2 4 3 Risk Level Low 5 2 5 Video Monitoring 5 2 5 1 Description This test will verify whether the enable registered users to monitor activities via live video feed 47 TP Version 1 0 ALWAYS mHOMe 1 Test Smart Door 5 2 5 2 Test Approach This test shall manually verify if the system allow users to capture activities via live video streaming on their smart phones 5 2 5 3 Risk Low 5 2 6 System Portability 5 2 6 1 Description This test will verify whether the system is a portable device 5 2 6 2 Test Approach This test shall manually verify if the system is a portable device that the customer can take with them when they move 5 2 6 3 Risk Level Medium 5 2 7 Smart Phone Pairing 5 2 7 1 Description This test will verify the ability to pair user activity with a smartp
23. 7 Smart Phone Paring 3 8 Motion Sensor 3 8 Local Storage 3 10 Hardware Security 3 11 Z Wave 3 12 Lock Unlock x x x x 3 13 Open Source x x x x x x x x x 3 14 Nonintrusive Packaging Requirements 41 Size 42 Temperature Control 43 Mounting 44 Casing 4 5 Software Acquisition 4 6 Included Components 47 Team Logo 4 8 System Configuration x x x Performance Requirements 5 1 System x x x x x x x 5 2 Notification Time x x x x 53 Latency x x x x 5 4 Response Time X X X X 5 5 Data Transmission Live Video Feed X x x 5 6 Data Transmission Audio Transmission Xx X x 5 7 Recording Log Log Availability x x x x x x 5 8 Recording Log Storage Capacity 5 9 Power Power Supply 5 10 Power Power Source Emergency Backup Battery 512 1 O Ports 5 13 Operating Environment 3 15 Account Setup x x x x x x x 3 16 Video Log Downloads x x x x X X X X 5 14 Video Photo Resolution 5 15 System Availability x x x x X X x X x 5 16 Notification Limit x x X 5 17 Initialization Time x x x 5 18 Mounting Height 5 20 Microphone Sensitivity Safety Requirements 6 1 Camera Mounting 6 2 Microphone Mounting 6 3 Camera and Microphone Weather Safety 6 4 Receptacles Maintenance and Support Requirements 7 1 Software Updates x x x x 7 2 User Manual 7 3 Open Source X X X X X X X X X Other Requirements 8 1 Web Interface Support 8 2 Portable Source Code X X x x 8 3 Notification Control Tabl
24. Data Transmission Audio Transmission Recording Log Log Availability Recording Log Storage Capacity Power Power Supply Power Power Source Emergency Backup Battery Ports Operating Environment TP Version 1 0 The system shall be able to be mounted and configured in less than ten minutes by the end user The user will mount the hardware near the door and the configuration shall be defined as pairing the user s mobile device with the hardware While the system is operational and connected to the internet the system shall notify the user of guest activity in less than 30 seconds The user shall have an overall user request latency of less than 10 seconds Overall latency includes the transmission of the user request and system response time While the system is operating within the Active state the system shall respond to user requests in less than 7 seconds The system shall transmit video at 30 frames per second at a minimum resolution specified in requirement 5 16 The system shall transmit audio at a minimum of 800 bits per second The logs shall be updated at least 5 minutes after interaction has ended The system shall provide at least 32GB of storage capacity for videos The system shall be equipped with a power supply that will take a power source as specified in requirement 5 10 and provide an operating voltage of 1 15V and a current less than 20A The system shall source 120V AC
25. Lock status messages will be available in the Android Application Video Monitoring will be available in the Android Application 3 1 Smartphone Application Control 3 5 Video Monitoring Android Activity Manager Android Command Interpreter Server Communication Manager ALL modules in Processing Layer Lock and Unlock the connected door using the Android Application Verify that all software is open source by verifying that the GNU license is attached to the software distribution Touch controls on the Android Application GNU License The Door will Lock and Unlock 5 Future Software will found to open Source 1 Critical 3 12 Lock Unlock 3 13 Open Source 7 3 Open Source Android Activity Manager Android Command Interpreter Server Communication Manager ALL Microcontroller Application Modules Verify that the system is able to be setup any malfunction in the Processing Layer will prevent a successful system setup User Data System will be setup correctly 5 1 System Setup Manager Android Command Interpreter Server Communication Manager ALL Microcontroller Application Modules Manager Android Command Interpreter Server Communication Manager Video Stream ALL Microcontroller Application Modules Android Activity Manager Android Command Interpreter Server Communication Manager ALL Microcontroller Application Modules This requirement is considered satisfied it th
26. T9 with normal operation of door intended not open the door Table 32 Acceptance Test Cases 5 Features To Be Tested 5 1 0verview This section includes the list of features that will be tested to ensure that the Smart Door System satisfies the requirements from the System Requirement Specification document Each subsection will describe a specific requirement and how that requirement is tested There are three levels of risk that associated with testable features Following are the levels of risks High feature is difficult to test Medium has been tested and may not work as expected Low Will be implemented and work properly 5 2 Customer Requirements 5 2 1 Smart Phone Application Control 3 2 1 1 Description This test will verify whether the system is controlled by the smartphone application installed on user s smartphone TP Version 1 0 46 5 q Test Plan Smart Door 5 2 1 2 Test Approach This test shall manually verify if the user is able to interact with the smart door system via the user s smartphone application 5 2 1 3 Risk Level Low 5 2 2 Snapshot of Guests at Door 5 2 2 1 Description This test will verify whether the smart door system is able to take photo images and store them when doorbell is rung 5 2 2 2 Test Approach This test shall manually verify if there is any photo image taken and store at the time the doorbell is rung
27. Temperature Control Mounting Casing Software Acquisition Included Components Team Logo System Configuration Table 2 Packaging Requirements TP Version 1 0 The system shall be enclosed in a box that is no larger than 12x12x4 576 cubic in This size will optimize volume while ensuring adequate space is still available for components connections and heat dissipation The enclosure shall provide ventilation for heat removal The product shall provide mounting brackets and screws for secure attachment of the system The portion of the system containing the camera shall be mounted within 2 feet of the door The system shall be enclosed in a case that shall keep its internal components secure The system software shall be available on the Internet Software for the PC hardware interface shall be packaged with the product on a CD The product will be delivered to the end user with the Always Home device user manual and mounting hardware The logo will be visibly displayed on the base of the final product The system s camera doorbell and microphone shall be collocated in a common enclosure 11 Smart Door 1 Critical 3 Moderate 1 Critical 2 High 1 Critical 2 High 4 Low 1 Critical 5 Test 2 2 3 Performance Requirements System Setup Notification Time Latency Response Time Data Transmission Live Video Feed
28. Test Plan HOMe Team Always Home ALWAYS Project Smart Door 5 Team Members James Lunsford Khuong Nguyen Juan Duarte Jay Last Updated 3 19 2014 Smart Door Table of Contents Table Of 2 Table of Figure EEEN 5 Tia LOS on e EE 6 DOCUMENT REVISION He Oe EE H 1 8 11 Ka Ta aa a a GK ata aaa Te Ek aa a 8 12 Product Scope ee m 8 1 3 DOCUMENT BUEDOSE ass dadana aa RE ex aa aaa da D de a 8 1 4 DOCUMENTS Aa ENG SEN a ad ee Ee axe 8 2 EP 9 uu EEEOUJ I 9 2 2 System Requirement Speclcatlon agan adi eg a aaa ai nnn nennen nasa nass aa naa ag sanas sns 10 2 3 Architecture Design Specification 16 2 4 Detailed Design Specification ii a 19 25 Data GEERT ege e el KE 20 2 6 Producer Consumer Matrices 21 2 6 1 System Level Producer Consumer 21 2 6 2 Web Producer Consumer
29. be held until it needs to be access This is where the storage of videos will be for user to see past ones and live ones 18 ALWAYS its TP Version 1 0 Test Smart Door 2 4 Detailed Design Specification 2 4 1 Subsystem Decomposition Figure 6 Subsystem Decomposition 19 TP Version 1 0 ALWAYS iis HOMe Smart Door 2 5 Data Flement Description System Level Data Element Description Data Element Description Webpages displayed on users Monitor from Web GUI User Input into Web GUI User Input passed to Web App from Web GUI Webpages and messages to be displayed by Web GUI from Web App Interactions displayed on users Android Device User Input into Android App User Input passed to Android App from Android GUI Interactions to be displayed by the Android GUI form the Android App Raw Data from the Hardware being passed to the Microcontroller App Audio Data and Lock Unlock commands from Microcontroller App to the Hardware Raw Data from Camera to the Hardware Subsystem Raw Data from Microphone to the Hardware Subsystem Audio Stream from Hardware to User at the Door Lock Unlock Signal from Hardware Subsystem to the Door Lock Raw Data from Door Sensor to the Hardware Subsystem Raw Data from Doorbell to the Hardware Subsystem Raw Data from Door Lock to the Hardware Subsystem Information Requests and Commands from Android App to Vid
30. ble to be setup any malfunction in the Network Layer will prevent a successful system setup User Data Account will be setup correctly 3 Moderate 3 15 Account Setup ALL Web Application modules Android Communication Manager Microcontroller Communications Manager Command Message Processor Log Videos Actions ALL modules in Network Layer Android Communication Manager Microcontroller Communications Manager Command Message Processor Download a video through the Website in order to verify that the video log is available Insure that the system availability exceeds 9596 Turn on Smart Door Prototype and verify that the system is available within five minutes User Input to website Record the uptime of the microcontroller during a one week period and calculate the percent availability User plus in Smart Door Prototype Table 28 Network Layer Integration Tests TP Version 1 0 43 Availability should be above 9596 up time System will be available within five x 1 Critical minutes 3 16 Video Log Downloads 5 15 System Availability 5 17 Initialization Time 5 Test Smart Door 4 6 1 2 4 Data Storage Layer Establish that the time to store a file in Module stores file in less than 3 Store Retrieve Microcontroller Data System action message 1 Critical 1 High 5 4 Response Time the module is faster than 3 seconds second Inspection
31. cation ADS and the Detailed Design Specification DDS documents Each reference sub section provides detailed information required to conduct the test drive More specifically The SRS reference sub section contains customer requirements packaging requirements performance requirements etc system I O that shall be used to determine verification tests The ADS sub section contains data flows between layers which will be used to determine layer integration testing The DDS subsection contains subsystem modules and data flows which will be used for unit testing ALWAYS mHOMe TP Version 1 0 Test 2 2 System Requirement Specification 2 2 1 Customer Requirements 3 1 Smartphone Application Control 3 2 Snapshot of Guests at Door Keep Activities Log 3 4 Emergency Power Supply Video Monitoring System Portability Smart Phone Pairing Motion Sensor Local Storage 3 10 Hardware Security Z Wave Lock Unlock Open Source Nonintrusive Account Setup 3 16 Video Log Downloads The system shall be controlled by a smartphone application installed on the users smartphone providing a means for the users to interact with the system Photo images shall be taken and stored by the system when doorbell is rung The systems activity log shall differentiate between users when logging all interactions and activities of the system The system shall have an emergency power supply The system shall allow regist
32. ch This test shall verify that the system has recording capability for photo and video resolution of at least 352x240 pixels 5 4 9 3 Risk Level Low 52 TP Version 1 0 Test 5 4 10 5 4 10 1 5 4 10 2 5 4 10 3 5 4 11 5 4 11 1 5 4 11 2 5 4 11 3 5 4 12 5 4 12 1 5 4 12 2 5 4 12 3 5 4 13 5 4 13 1 5 4 13 2 5 4 13 3 Version 1 0 System Availability Description This test will verify the availability of the system meet the performance requirement Test Approach This test shall verify that after initial configuration the system is available at least 95 of the time that it is connected to both working 120VAC electrical power and a working internet connection Risk Level Low Notification Limit Description This test will verify the amount of notification meet the performance requirement Test Approach This test shall verify that the system notifies the user of doorbell rings a maximum of 3 times in a 2 minute period where rings will be processed every 30 seconds Risk Level Low Initialization Time Description This test will verify the initialization time meet the performance requirement Test Approach This test shall verify that upon device power on the system is initialized after a period no longer than 5 minutes Risk Level Low Microphone Sensitivity Description This test will verify the micr
33. cription The system shall not notify the customer again for at least two minutes if the user chooses to ignore the first notification 7 Approach Strategy 7 1 Overall Test Strategy The test strategy for the Smart Door will ensures that both the software and the hardware operate to fulfill the requirement set by the team and stakeholders The team will test the hardware to make sure that all the components operate correctly individually and can be integrated correctly The hardware will also be tested to ensure that the hardware will allow software to meeting its functionality The work flow for the testing the software will be done in tiers because the team will be testing the system from the ground up For each function there will be a unit tests done and if the test is successful then integration testing will be done for the module that it belongs to If a module is complete and passes the integration and unit testing then there will be component testing done to the module Once the modules are all complete they will also be unit tested and then if successful then integration testing will be done to the subsystem it belongs to Acceptance testing will then be done to ensure that the system is complete and meets all the requirements 57 TP Version 1 0 ALWAYS mHOMe E Test Plan Smart Door 7 2 Configurations tested not tested Only the priority one through four hardware and software configurations will be tested and priority five future
34. d 4 2 14 Application 2 1 4 3 4 Test Server 2 1 431 Team 4 2 14 5 4 5 14 2 1 4 3 5 Component Test Storage N 2 1 4 3 6 Module Integration Test 1 4 3 7 14 3 8 All Team 1431 sat4 5 14 N A Tue4 8 14 N 2 1 4 3 10 System Test 24439 Wed 4 16 14 4 17 14 Table 34 Testing Schedule 10 Approvals Mike O dell Project Manager Sponsor Sean Jones Repreasentative James Lunsford Lead Developer D o Android Desi Juan Duarte Khuong Nguyen Web Design Lead Software Jay Otterbine i Engineering Lead Table 35 Approvals 61 TP Version 1 0 ALWAYS mHOMe
35. d modules 33 TP Version 1 0 ALWAYS ii HOMe q Test Plan Smart Door Module level testing will be defined as validating and verifying the internal functions within each module upon the completion of implementing the module Unit testing will be defined as testing the interfaces and data transfer between two related modules Modules are defined as related if they exchange any messages or information between each other Module and Unit level testing will not include interfaces across subsystem boundaries These interfaces will be tested during Integration testing 4 4 1 Test Assumptions Module level testing assumes that the module has been completely implemented and debugged Unit level testing assumes that each participating module has been implemented and debugged 4 4 2 Test Requirements Requirements will be generated for each module based on the system level requirements they are intended to fulfill according to the requirements traceability matrix Additional functional requirements will assure that the module fulfills its function within the subsystem 4 4 3 Test Dependencies The Module level tests are intended to have no external dependencies since they are only testing internal functionality of a module Unit level testing will depend on the proper implementation of each participating module Additionally unit level testing will not complete successfully unless each participating module adheres to its interface requirements 3
36. d within acceptable time 1 5 seconds Notification is passed within acceptable time 1 5 seconds Notification is passed within acceptable time 1 5 seconds Notification is passed within acceptable time 1 5 seconds Notification is passed within acceptable time 1 5 seconds e Smart Door 4 5 Software Acquisition 5 2 Notification Time ication Time ication Time ication Time ication Time ication Time Server Communication Manager Establish that the notifications are passed through the module within an acceptable timeframe Notification from Smart Door Prototype Notification is passed within acceptable time 1 5 seconds ication Time Push Notifications Establish that the notifications are passed through the module within an acceptable timeframe Notification from Smart Door Prototype Notification is passed within acceptable time 1 5 seconds ication Time Android Activity Manager Android Command Interpreter Server Communication Manager Data Interpreter Data Processor Local Data Access Server Communication Manager Establish that the time to relay an action message through the module is faster than 0 3 seconds Establish that the time to relay an action message through the module is faster than 0 3 seconds Establish that the time to relay an action message through the module is faster than 0 3 seconds Establish that the time to relay an action message thro
37. e s mounting base must be properly secured to a structure and positioned four or more vertical feet off the ground Receptacles All electric receptacles shall meet the 5 Future Item National Electrical Code for outdoor wiring Table 4 Safety Requirements 2 2 5 Maintenance and Support Requirements teen User Manual The system shall provide English 3 Moderate instructions on how to use and T configure the device There shall be a troubleshooting guide section for Table 5 Maintenance Requirements system installer 14 ALWAYS its TP Version 1 0 Test Smart Door 2 2 6 0ther Requirements Portable Source Code The system shall include an 105 application that provides the same capabilities for controlling and interacting with the system as the smartphone application Table 6 Other Requirements 5 Future Item 15 TP Version 1 0 ALWAYS it HOMe Test Smart Door 2 3 Architecture Design Specification 2 3 1 Architecture Layer Diagram Always Home will be divided into four major layers the UI Layer Processing Layer Networking Layer and Data Storage Layer The architecture of it is based on an extended three tier architecture The layer structure is shown below 242 c ES 1 Android Android Event bor USB Interface Speaker interface we EIS a H i ae
38. e 15 Network Requirements Traceability Matrix 31 TP Version 1 0 Test Smart Door 4 2 7 Storage Layer 4 2 7 1 Requirements Satisfaction Matrix 3 1 3 2 3 3 3 4 3 5 3 6 3 7 3 8 3 8 3 10 3 11 3 12 3 13 3 14 41 42 4 3 4 4 4 5 4 6 4 7 4 8 5 1 5 2 5 3 5 4 5 5 5 6 5 7 5 8 5 9 5 10 5 11 5 12 5 13 3 15 3 16 5 14 5 15 5 16 5 17 5 18 5 20 6 1 6 2 6 3 6 4 7 1 7 2 7 3 8 1 8 2 8 3 Data Storage Layer Requirements Traceability Matrix Server HDD Store Retrieve Server Microcontroller HDD Store Retrieve Customer Requirements eg EE eee Smartphone Application Control Snapshots Taken Keep Activities Log Emergency Power Supply Video Monitoring System Portability Smart Phone Paring Motion Sensor Local Storage Hardware Security Z Wave Lock Unlock Open Source Nonintrusive Packaging Requirements Size Temperature Control Mounting Casing Software Acquisition Included Components Team Logo System Configuration Performance Requirements System Setup Notification Time Latency Response Time Data Transmission Live Video Feed Data Transmission Audio Transmission Recording Log Log Availability Recording Log Storage Capacity Power Power Supply Power Power Source Emergency Backup Battery 1 0 Ports Operating Environment Account Set
39. e Unit Tests for requirements 5 2 Notification Time and 5 4 Response Time are met Monitor the streaming information from the Linux command line to ensure resolution and framerate requirements are being met Monitor the streaming information from the Linux command line to ensure resolution and framerate requirements are being met Test results from unit tests conducted on the Smart Door Prototype Start stream with the Verbose command line argument then visually confirm data transmission rates in the Linux console Start stream with the Verbose command line argument then visually confirm data transmission rates in the Linux console Table 27 Processing Layer Integration Tests 4 6 1 2 3 ALL Web Application modules Android Communication Manager Microcontroller Communications Manager Command Message Processor Network Layer Verify that the system is able to be setup any malfunction in the Network Layer will prevent a successful system setup User Data Itis expected that 5 2 5 3 and 5 4 will be satisfied by the Smart Door Prototype 2 Moderate Framerate and resolution targets will be met as verified by observing 3 Mb second data transmission rate 2 Moderate Framerate and resolution targets will be met as verified by observing 34Mb second data transmission rate 2 Moderate System will be setup correctly 3 Moderate 5 3 Latency 5 5 DataTransmission Video Stream 5 6 DataTra
40. e a network connection to be able to provide a video feed We will also need to take into consideration when a phone is on a weaker network that is not Wi Fi such as 4g 4 1 3 Other Product Level restraints on testing Due to the fact that the end user installs the system we are unable to verify that all of the hardware requirements are met for each Smart Door device We are only able to verify that the design prototype meets the requirements thereby providing some assurance that the all of the subsequent devices are able to meet the requirements provided they are installed correctly 4 2 Requirements Satisfactions 4 2 1 0verview This is a continual review process that ensures that specified requirements are still feasible and within the scope of our design The SRS requirements are not engraved in stone The team will constantly monitor our requirements and receive stakeholder feedback to ensure product viability 4 2 2 Procedure Requirements satisfied by the each architectural layer include those noted in the layer s Requirements Satisfaction Matrix The Requirements Satisfaction Matrix indicates the Test ID of each test that verifies a particular requirement that has been levied on a module of subsystem The test cases showing satisfaction for the allocated requirements are located in the following sections 3 3 Unit Test 3 4 Component Level Testing 3 5 Integration Testing and 3 6 System Verification Testing 4 2 3 Findings All requirements
41. ected result actual result Pass Fail and Comments for each test 59 TP Version 1 0 ALWAYS mHOMe Test Smart Door 8 3 1 Example Test Log Bacon ipsum dolor sit amet short loin prosciutto bacon sausage beef ribs venison Jon Doe Lorem Ipsum boudin biltong Wafer gummi bears donut marshmallow chocolate bar souffl oat cake Don Joe Lorem Lorem Sample 1 Sample 2 What you have to ask yourself is do i feel lucky well do ya punk Sample3 Sally Sample Ipsum Ipsum you measure yourself by the people who measure themselves by you let me tell you Sample4 Jane Doe Ipsum Lorem something my friend hopeis a dangerous Lorizzle ipsizzle dolor izzle amizzle consectetuer adipiscing pizzle Get down get Sample 5 Dane Joe Lorem Lorem down fo shizzle mah Table 33 Example Test Log 8 4 Test Report The Test Report is a summarization of the testing effort after it has been completed This report will include the overall success or failure of the program the pass fail results of each test and any interesting problems from the Test Log 60 ALWAYS iis HOMe TP Version 1 0 Test Smart Door 9 Test Schedule 9 1 Description 9 2 Schedule Task Resource Actual T Task Name Predecessors Planned Start Planned Finish Number Names Start 2143 1 N A Mon 3 24 14 N A Thu3 27 14 2 1 4 3 2 Component Test UI Team 1 3 27 14 N A Sun 3 30 14 1 Test END ponent 165 21431 Sun 3 30 14 N A We
42. ell to be microphone Button Click Signal of the button press audio stream critical 1 critical 1 Hardware The User will be able to hear another user through the speaker audio stream critical 1 Hardware The subsystem will allow messages from the sensors to give a message door state value Hardware allow video stream of the user h 246 video stream critical 1 Table 22 UI Layer Component Tests TP Version 1 0 39 5 Test Smart Door 4 5 4 2 Processing Layer The subsystem will take in door state reguest int door state message future 5 risk 1 The subsystem will begin monitoring reguest int begin monitorting message medium 2 risk 2 The subsystem will take video stream and audio stream video audio stream video audio file critical 1 risk2 The subsystem will take in audio and pass it to the server audio file critical 1 risk2 The subsystem will prepare and send out push notifications int message push notification medium 2 risk 2 The subsystem will take in a video and audio stream and send it to Microcontroller App the server h 246 video audio h 246 video audio critical 1 risk 2 The subsystem will take in messages from hardware and send itif int message for Microcontroller App there is Wi Fi doorbell button click int message critical 1 risk 3 The subsystem will take in messag
43. eo Server Video Audio Streams and Sensor Information from Video Server to Android App Video Audio Streams and Sensor Information from Microcontroller App to Video Server Information Requests and Commands from Video Server to Microcontroller App Recorded Notifications and MPG4 Files from Microcontroller App to Microcontroller HDD Recorded Notifications and MPG4 Files from Microcontroller HDD to Microcontroller App Information Requests from Web App to Server HDD Recorded Notifications and MPG4 Files from Microcontroller HDD to Microcontroller App Information Requests and MPG4 Files from Video Server to Server HDD Recorded Notifications and MPG4 Files from Microcontroller HDD to Microcontroller App Recorded Notifications and MPG4 Files from Server HDD Subsystem to Physical HDD Recorded Notifications and MPG4 Files from Physical HDD to Server HDD Subsystem Recorded Notifications and MPG4 Files from Microcontroller HDD Subsystem to Physical HDD Recorded Notifications and MPG4 Files from Physical HDD to Microcontroller HDD Subsystem Table 7 Data Element Description 20 TP Version 1 0 ALWAYS mHOMe ZE Test Smart Door 2 6 Producer Consumer Matrices 2 6 1 System Level Producer Consumer Matrix Table 8 System Level Producer Consumer Table 21 TP Version 1 0 ALWAYS ii HOMe Test Smart Door 2 6 2 Web Producer Consumer Matrix Web Producer Consumer Table jsonbow 294
44. er at the door Press and Audio Stream to hardware critical 1 Perform monitoring from Video feed of the camera at the Android Device Button click door critical 1 View Recordings from the website Button click Show a list of videos of that users critical 1 Unlock lock door from ER Android Device Button Click Door state confirmation Future 5 Interaction with Users from Android device and Smart Video Audi Door oStream Logged video audio stream critical 1 Table 30 System Verification Tests Answer Call on Android Message of either decline call or device Button click accept call to see them critical 1 44 TP Version 1 0 ALWAYS it HOMe Test Smart Door 4 8 Acceptance Test Each Acceptance Criteria will a unique functional test to be carried out by a sponsor representative Successful completion of all ten acceptance tests will constitute acceptance of the product These tests will be specified in the Smart Door test plan 4 8 1 Criteria Wakes and notifies upon connected doorbell being pressed Wakes and logs the status of the connected door upon connected door opening or closing Live video monitoring capability within the Smart Door android app One way video communication between door and the Smart Door android app Two way audio communication between door and Smart Door android app Smart Door system returns to sleep mode upon completion of interaction
45. ered users to monitor activities via live video feed on smart phones The system shall be a portable device that the customer can take with them when they move The system shall pair user activity with a particular smartphone to keep logs of who interacts with the system The system shall have a short range motion sensor The motion sensor will take a picture and upload it to the server every time the sensor is triggered The device shall have an on board storage device The device shall be enclosed in a secured case The system shall be compatible with Z Wave wireless communications protocol The system shall be able to lock and unlock the door remotely The source code of the system shall be released under an open source license The system shall not interfere with normal functionalities and operations of the existing door and doorbell The system shall provide account setup capability The account setup will be responsible for pairing a phone to a particular Smart Door device The system shall allow registered users to download videos from the video log on the website interface Table 1 Customer Requirements TP Version 1 0 10 Smart Door 1 Critical 1 Critical 1 Critical 4 Low 2 High 2 High 2 High 5 Future 2 high 2 High 5 Future 5 Future 1 Critical 1 Critical 2 High 4 Low ALWAYS its Test Size
46. es from int message for the hardware and send itif door sensor and lock Microcontroller App there is Wi Fi sensor int doorstate future 5 risk 1 Will test to see if there is Wi FI connection if there is send itto server if not send itto Local check for Wi Fi struct of messages and Microcontroller App data connection videos audio critical 1 risk 3 Table 23 Processing Layer Component Tests 40 ALWAYS mHOMe TP Version 1 0 Test 4 5 4 3 Network Layer This will take ina page for error or the page that Smart Door request for a page Request for a page is correctly requested medium 2 risk 3 This will set up the request the videos from request for videos for a Select from video table MySQL the server user statement critical 1 risk 3 Save account information when JSON list of account Insert into user info table MySQL creating an account information statement critical 1 risk 3 Video Server The server will take the audio from the Android Device and prepare it for the microcontroller Audio stream Audio Stream critical 1 risk 1 Video Server The server will take the video audio from the microcontroller and prepare it forthe Android Device Video Audio Stream Video Audio Stream critical 1 risk 1 Video Server The server will convert the message from Microcontroller to be set up for the Android device Int M
47. essage Int Message critical 1 risk 1 Video Server The server will convert the message from Android Device to set up for the Microcontroller Int Message Video Server After a video hosting is completed prepare it to be saved to Database Video Audio Stream Int Message Insert into video tableMySQL statement critical 1 critical 1 risk 2 Table 24 Network Layer Component Tests 4 5 4 4 Data Storage Layer Table 25 Data Storage Layer Component Tests TP Version 1 0 41 ALWAYS iis Test Smart Door 4 6 Integration Test 4 6 1 Layer integration 4 6 1 1 gt Test Assumptions Layer Integration testing assumes that all modules have been completed and that all unit level tests are completed 4 6 1 2 Test Cases 4 6 1 2 1 Reguest Handler Reguest Handler Android Event Handler Android Function Handler UI Layer Verify that log has been updated within five minutes of an interaction lending Complete the procedure to pair the Smart Door device to an Android device The elapsed time between the completion of an action and the posting of the action to the log Pairing Key Interactions are visible on the Log in less than five minutes Smart Door Device is paired to the users smart phone 3 Moderate 2 High 5 7 Recording Log Log Availability 3 15Account Setup Web Display
48. esting 37 TP Version 1 0 E Test Plan Smart Door 4 5 2 Test Requirements Requirements will be generated for each subsystem based on the system level requirements they are intended to fulfill according to the requirements traceability matrix Additional functional requirements will assure that the subsystem fulfills its function within the overall system 4 5 3 Test Dependencies Component level tests are intended to test the subsystem s internal functionality This means that the component level tests are dependent on the module and unit level tests being passed successfully Component level tests depend on each module adhering to its defined interface requirements in order for communication testing to complete successfully 38 TP Version 1 0 ALWAYS mHOMe Test 4 5 4 Test Cases 4 5 4 1 UI Layer The User wil be able to click a button or link on the website to be able to switch from page to page The User will fill out a form to create an account and be able to submit it Button or URL Click Button Click Request to retreive a page JSON list of the form of username password registered mobile device and registered hardware critical 1 critical 1 Smart Door 5 4 The User will see a page on the website either the page they want or an error page 200 with page needed error page if bad request html page critical 1 5 4 The User wi
49. g made available for testing 4 3 4 Test Data 4 3 4 1 Test Cases Evaluate Smart Dor Prototype to lensure that it is portable Smart Door Device Subjective Evaluation by Sponsor 4 Inconclusive Smart Door prototype will be found to be portable 2 High 3 6 System Portability Enclose Smart Door Prototype in its 3 10 Hard secure enclosure and make Subjective Evaluation by Sponsor Smart Door prototype will be found tobe secure 2 High 2 Moderate Smart Door Device available for evaluation Install Smart Door Prototype ina Smart D t ill be found to b Smart Door Device representative location and make Subjective Evaluation by Sponsor RA UN 1 Critical 4 3 14 Nonintrusive available for evaluation Measure the protoype device s Smart Di Protot d 1 Smart Door Device deminsions to assure that it meets 2118 2097 Prototype anc measuring smart Door prototype fits within the required size 1 Critical 2 Moderate 4 1 Size tape the requirement Operate the smart door prototype Operate the Smart Door Prototype Smart Door prototype will continue to operate in 4 2 Temperature Smart Door Device inside a freezer and outside in TX 22 3 Moderate 3 Low through range of temperatures the representive environments Control Mount the Smart Door prototype Smart Door prototype and mounting
50. gency Backup Battery 5 12 1 0 Porte 5 13 Operating Environment 3 15 Account Setup D x x 3 16 Video Log Downloads D x x 5 14 Video Photo Resolution 5 15 System Availability X X X X X 5 16 Notification Limit X X X X 5 17 Initialization Time x X X X X 5 18 Mounting Height 5 20 Microphone Sensitivity Requirement Satisfied by Android Device Safety Requirements 6 1 Camera Mounting 6 2 Microphone Mounting 6 3 Camera and Microphone Weather Safety 6 4 Receptacles Maintenance and Support Requirements SE Software Updates X X X X X 7 2 User Manual X 73 Open Source X D Other Requirements 8 1 Web Interface Support 8 2 Portable Source Code X X X X X 8 3 Notification Control Table 14 Processing Requirements Traceability Matrix 30 ALWAYS Test Smart Door 4 2 6 Network Layer 4 2 6 1 Requirements Satisfaction Matrix 21 Network Layer Requirements Traceability Matrix Web App Video Server Communicatio Communications Communication Communication Manager Processor Videos Actions Customer Requirements 3 1 Smartphone Application Control 32 Snapshots Taken 33 Keep Activities Log x x x x 3 4 Emergency Power Supply 3 5 Video Monitoring x x x x 3 6 System Portability 3
51. he system interfere with functionalities and operations of the existing door and doorbell Risk Level Low Account Setup Description This test will verify whether the system is able to provide account setup capability Test Approach This test shall manually verify if the account setup feature will be able to provide account setup and responsible for pairing a smart phone to a smart door device Risk Level Low Video Log Downloads Description This test will verify if the system allow registered users to download video logs from the website interface 49 5 Test Smart Door 5 2 13 2 Test This test shall manually verify whether registered users are able to pull down video logs from the system 5 2 13 3 Risk Level Low 5 3 Packaging Requirements 5 3 1 Size 5 3 1 1 Description This test will verify if the enclosed case meet the requirement size 5 3 1 2 Test Approach This test shall verify if the system is enclosed in a box that is no larger than 12 x 12 x 4 576 inches 5 3 1 3 Risk Level Low 5 3 2 Temperature Control 5 3 2 1 Description This test will verify the temperature control of the enclosure 5 3 2 2 Test Approach This test shall verify if the enclosure provide ventilation for heat removal 5 3 2 3 Risk Level Low 5 4 Performance Requirements 5 4 1 Notification Time 5 4 1 1 Description This test will ver
52. hone of the system 5 2 7 2 Test Approach This test will manually verify the ability to pair user activity with a particular smartphone to keep logs of who interacts with the system 5 2 7 3 Risk Level Low 5 2 8 Local Storage 5 2 8 1 Description This test will verify if the local storage of the device is able to store data locally 5 2 8 2 Test Approach This test shall manually verify the ability to store data logs locally on the microcontroller in case network connection is lost 5 2 8 3 Risk Level Low 5 2 9 Hardware Security 5 2 9 1 Description This test will verify if the case that enclosed the system is secured 48 TP Version 1 0 ALWAYS mHOMe Test 5 2 9 2 5 2 9 3 2 2 10 5 2 10 1 5 2 10 2 5 2 10 3 5 211 5 2 11 1 5 2 11 2 5 2 11 3 5 2512 5 2 12 1 5 2 12 2 5 2 12 3 Version 1 0 Test This test will manually verify if the system enclosed case is durable and secured Risk Level Low Lock Unlock Description This test will verify whether the lock and unlock feature of the system work or not Test Approach This test shall manually verify if the system is able to lock and unlock the door remotely Risk Level Medium Nonintrusive Description This test will verify whether the system interfere with normal functionalities and operations of the door Test Approach This test shall manually verify if t
53. id app user to see monitoring outside the door without the user ending it critical 1 One way video communication Fails if there is no video stream or the between door and the Smart Door Passes when there is a video stream of the Android phone doesn t display a video ATA android app Smart Door on the Android Smart door app stream Two way audio communication Passes when the users can have a between door and Smart Door android conversation through the Smart Door Fails when there is no audio on the AT5 app Android app Smart Door or Smart Door android app Smart Door system returns to sleep Passes when the Smart Door is off after Fails if the system stays on after five AT6 mode upon completion of interaction monitoring and at the end of the call minutes of an action on it Passes when there is a record in the Fails if the system does not have a Video logging and ability to retrieve database for each video and when the record of the video or unable to AT7 videos using the Smart Door web app website can retrieve the information from retrieve the videos for a user on the Passes when the system is contained into Fails if the Smart Door system is in more Smart Door system portability and ease one box and has a manual on how to install than compnent and does not have AT8 of installation it instructions Fails if the doorbell does not ring when Smart Door system does not interfere Passes when door is functionally as the doorbell is rung and the key does A
54. ify that the notification time meet the performance requirement 5 4 1 2 Test Approach This test shall verify that while the system is operational and connected to the internet the system shall notify the user of guest activity in less than 30 seconds 5 4 1 3 Risk Level Medium 50 TP Version 1 0 ALWAYSmHOMe q Test Plan Smart Door 5 4 2 Latency 5 4 2 1 Description This test will verify that the latency time meet the performance requirement 5 4 2 2 Test Approach This test shall verify that the user shall have an overall user request latency of less than 10 seconds Overall latency includes the transmission of the user request and system response time 5 4 2 3 Risk Level Medium 5 4 3 Response Time 5 4 3 1 Description This test will verify that the response time meet the performance requirement 5 4 3 2 Test Approach This test shall verify that while the system is operating within the Active state the system shall respond to user requests in less than 7 seconds 5 4 3 3 Risk Level Medium 5 4 4 Data Transmission Live Video Feed 5 4 4 1 Description This test will verify that the video transmission rate meet the performance requirement 5 4 4 2 Test Approach This test shall verify that the system transmits video at 30 frames per second at a minimum resolution specified in requirement 5 16 5 4 4 3 Risk Level Medium 5 4 5 Data Transmission Audio Transmission 5 4 5 1 De
55. le of Figures Figure 1 Layer se Y 16 2 gae Ae lg Ae iesse des 17 3 PROCESSING EVI NR 17 Figure 4 Network Layer 18 Figure b Data Storage Layer ia un ei aia sia cete ba e ade ve ed ee xe aa ce vta ear e ua Ra c ei d re xa 18 Figure 6 Subsystem Decomposition 19 Figure 7 System Level Diagramm 26 Version 1 0 Smart Door Table of Tables iTable 1 Customer Req irerents 10 Table 2 Packaging Reg irerents olet ette eer eee dee ag aa 11 Table 3 Performance Requirements isanimi 13 Table 4 Safety Requitetrients carter reu SEENEN AE 14 Table 5 Maintenance Regquiremirits 2 S IER e Pe Td n rea pa enc caus 14 Table 6 Other Requirerients 2 re retour uo 15 Table 7 Data Element Description s sasadan RENEA NANA na aas 20 Table 8 System Level Producer Consumer Table 21 Table 9 Web Producer Consumer Table
56. ll be able to click a button to download a video Button Click Selected video critical 1 5 4 5 7 The User will click a button on the login screen to log into there account Button Click username and password ActionListener username in variable and password in variable critical 1 5 4 The User will click a button on the accept call screen Accept Button Click ActionListener to pull up new page call screen critical 1 5 4 The User will click a button on the accept call screen Decline Button Click ActionListener to end stream critical 1 5 4 The User will click a button on the menu screen to start monitoring Start Monitor Button Click ActionListener to request start monitoring critical 1 5 4 The User will see a video and audio stream as well as action buttons XML format the call screen critical 1 5 13 5 4 The User will see a login page if they have not logged in The User will see the menu screen when they are logged in XML format XML format the login screen the main menu screen critical 1 critical 1 5 13 5 4 The User will see the incoming call screen when the doorbell button has been pressed XML format the incoming call screen critical 1 5 13 5 4 The User will be able to talk to another user audio audio stream critical 1 5 4 Hardware The User will be able to press the doorb
57. mperature Control Reguirement 5 by Smart Door Device a3 Mounting Requirement Sa by Smart Door Device 44 Casing Requirement Satisfied by Smart Door Device 45 Software Acquisition x x 46 Included Components x x x x Team Logo Reguirement Satisfied Smart Door Device System Configuration x x x x x x Performance Requirements 5 1 System x 52 Notification Time 53 Latency x x x x 54 Response Time x x x x x x x x x x 55 Data Transmission Live Video Feed x x 5 6 Data Transmission Audio Transmission x x x 57 Recording Log Log Availability x 58 Recording Log Storage Capacity Requirement Satisfied by Smart Door Device 59 Power Power Supply Requirement Satisfied by Smart Door Device 5 10 Power Power Source Requirement Satisfied by Smart Door Device 5 11 Emergency Backup Battery 5 12 1 0 Ports x x x x 5 13 Operating Environment 3 15 Account Setup x x x 3 16 Video Log Downloads 514 Video Photo Resolution x x 5 15 System Availability x x x x 5 16 x 5 17 x x x x 5 18 Mounting Height Requirement Satisfied by Smart Door Device 5 20 Microphone Sensitivity x x Safety Requirements 6 1 Camera Mounting Reguirement Satisfied by Smart Door Device 62 Microphone Mounting Requirement Satisfied by Smart Door Device 63 Camera and Microphone Weather Safety Requirement Satisfied by Smart Door Device Receptacles Requirement Satisfied by Smart Door Device Maintenance and Support Requirements 71 Software Updates 7 2 Use
58. n e The test procedure will begin with testing the hardware first with configuration of the hardware to have it functional and then provide a video feed Next will be the website to test configuration and to make sure the database is working properly Following integration we will have verification testing to internally test the as built system as a team Following verification testing we will turn in the prototype and conduct acceptance testing with all stakeholders 4 1 1 Version of product The product will be a version 1 0 when the prototype is created It will provide our guiding principles set from our architecture and further defined in our detailed design specification 25 TP Version 1 0 ALWAYS mHOMe Smart Door Test Plan 4 1 2 Design Decomposition System level diagram 4 1 2 1 TT ets L A interpreter Micro Controller HDD Store tetrieve 1 bat pm E ES Microcontroller HOD Figure 7 System Level Diagram 4 1 2 2 Limitations of product 4 1 2 3 Future implementation functions We have included the door lock unlock feature in our detailed design to have it where we can build it in the future We will keep it into consideration while creating our prototype 26 ALWAYS its TP Version 1 0 Smart Door 4 1 2 4 Network Dependency Our system relies on the hardware to hav
59. not teste 58 7 3 Plan deal with defects 58 TAs m 58 7 5 SpecialReguirementsTor Testing cte 58 74 6 S hed ling ssi eR dee iet aa re aed e maa ng 59 Ted 01 1 muere icu 59 8 A TENG NGA TAN NG GEN Ga BNN Ce ada 59 MEL 59 8 2 Test Cases ico AKARANA NAN FORSAN TE 59 83 Denon inimi D mit enn minm 59 3 TP Version 1 0 ALWAYS mHOMe Smart Door 84 22 cashes onde tee 60 9 Test Schedule iristera nia e aed ine een eee pex NG aa a 61 9 1 dl een BEE 61 9 2 Schedule scere 61 10 61 4 Version 1 0 Smart Door Tab
60. nsmission Audio Transmission 5 1 System Setup Android Communication Manager Microcontroller Communications Manager Host Stream Monitor the streaming information from the Linux command line to ensure resolution and framerate requirements are being met Start stream with the Verbose command line argument then visually confirm data transmission rates in the Linux console Framerate and resolution targets will be met as verified by observing 3 Mb second data transmission rate 5 14 Photo Video Resolution Android Communication Manager Microcontroller Communications Manager Host Stream Monitor the streaming information from the Linux command line to ensure resolution and framerate requirements are being met Start stream with the Verbose command line argument then visually confirm data transmission rates in the Linux console Framerate and resolution targets will be met as verified by observing 3 Mb second data transmission rate 5 6 DataTransmission Audio Transmission ALL modules in Network Layer Verify that all software is open source by verifying that the GNU license is attached to the software distribution GNU License Software will be found to be open source 1 Critical 3 13 Open Source 7 3 Open Source ALL Web Application modules Android Communication Manager Microcontroller Communications Manager Command Message Processor Verify that the Account is a
61. ocessor Startup Manager Interpreter AAS BAG Server Communication Manager 0 o 9 4 5 6 Pi 2 4 6 5 Figure 3 Processing Layer The Processing Layer will focus on converting and evaluating our data It will perform task to take the input from the GUIs and Hardware and convert the data to information that can be transferred to other components in our system It will have to be able to take data and prepare it for output 17 TP Version 1 0 ALWAYS i HOMe Test Smart Door 2 3 2 3 Network Layer Web App 49 01 J403N Video Server 7 Figure 4 Network Layer The Network Layer will focus on converting and evaluating our data in terms of information from mobile website and microcontroller It also serves a way to process data from storage to meaningful information It will perform the task of processing the different types of data from our different interface into a uniform data that can be used by other components in our system This is the backbone of our system that will handle the bulk of the processing 2 3 2 4 Data Storage Layer NIN N3 N t x 4 Server HDD Micro Controller HDD 4 Microcontroller Data i 1 5 Data Storage Layer The Data Storage Layer will store information either locally remotely server This 15 where the information will
62. ontroller BUS Verify Interaction records and video logs are stored on microcontroller Hard drive when internet is not available to the device Verify that actions requested in the smartphone GUI are completed by the remainder of the system components Verify that snapshots are taken upon the pressing of the attached doorbell Disconnect WIFI module form the microcontroller then initiate the system by pressing the doorbell Initiate video Monitoring through the android application Press the doorbell Notifications and video of interaction are stored on the microcontroller hard drive View a live video stream the android application Snapshot is sent with notification 1 Critical 1 Critical 3 9 Local Storage 3 1Smartphone Application control 3 2 Snapshots taken Microcontroller BUS GPIO Interface USB Interface Speaker Interface Web Display View Constructor Request Handler Display Layout Manager Android Event Handler Android Function Handler Microcontroller BUS GPIO Interface USB Interface Speaker Interface Verify that total system latency is less than 10 seconds Establish that the time to complete an action using the system is faster than 7 seconds Record the length of time it takes for a notification to arrive after the doorbell is pushed Record the time from pressing the doorbell until the paired android device rings Notification should arrive in less than ten seconds
63. oor P oto pew 1 Critical 4 inconclusive 5 18 Mounting Height a height between 60and 66inches indicated height Install Smart Door Prototype ina Subjective Evaluation by Desi Smart D totype will be found to b Smart Door Device AI EE 4 inconclusive 6 1 Camera Mounting mounted available for evaluation Install Smart Door Prototype i EENG a ee Be SE carek S 6 2 Smart Door Device representative location and make 3 Moderate 4 inconclusive mounted Mounting available for evaluation Install Smart Door Prototype 6 3 d 7 EEN teg Smart Door prototype will be found to be esie Smart Door Device representative location and make E 1 Critical 4 inconclusive Microphone Weather installable during described weather conditions available for evaluation Safety Ensure that the provided receptacl Smart Door Device nsure tnat the provided to test receptacle Receptacle found to be adequate 5 Future 5 Future 6 4 Receptacles is adequate Table 17 Hardware Verification Test Cases 4 4 Unit Test Module Level Module and Unit level testing are iterative processes We will conduct module level testing upon the completion of each module and we will conduct unit level testing upon the completion of relate
64. ophone sensitivity ability of the system meet the performance requirement Test Approach This test shall verify that the system provides a microphone with at least 20db sensitivity to reduce ambient noise processing Risk Level Low 53 5 q Test Plan Smart Door 54 TP Version 1 0 ALWAYS ii HOMe 1 Test Smart Door 6 Features Not to be Tested 6 1 0verview The following listed features are not to be tested since they are either verified by system design or future features Some of these features describe the system properties of the product and do not provide any functionality Others provide future functionalities but are not implemented in current version 6 2 Customer Requirement 6 2 1 Motion Sensor 6 2 1 1 Description The system shall have a short range motion sensor The motion sensor will take a picture and upload it to the server every time the sensor is triggered 6 2 2 7 6 2 2 1 Description The system shall be compatible with Z Wave wireless communications protocol 6 3 Packaging Requirement 6 3 1 Mounting 6 3 1 1 Description The product shall provide mounting brackets and screws for secure attachment of the system The portion of the system containing the camera shall be mounted within 2 feet of the door 6 3 2 Casing 6 3 2 1 Description The system shall be enclosed in a case that shall keep its internal components secure 6 3 3 Soft
65. our or more vertical feet off the ground 6 5 3 Camera and Microphone Weather Safety 6 5 3 1 Description The camera and microphone shall be installed in a manner that is considered to be weather safe 6 5 4 Receptacles 6 5 4 1 Description electric receptacles shall meet the National Electrical Code for outdoor wiring 6 6 Maintenance and Support Requirements 6 6 1 Software Updates 6 6 1 1 Description Software updates shall be available from the internet 56 TP Version 1 0 ALWAYSmHOMe 1 Test Smart Door 6 6 2 User Manual 6 6 2 1 Description The system shall provide English instructions how to use and configure the device There shall be a troubleshooting guide section for system installer 6 6 3 Open Source 6 6 3 1 Description All documents and source code shall be made available without financial remuneration Code shall be commented and include breakpoints to support troubleshooting 6 7 0ther Requirement 6 7 1 Web Interface Support 6 7 1 1 Description The system shall include a web application that provides the same capabilities for controlling and interacting with the system as the smartphone application 6 7 2 Portable Source Code 6 7 2 1 Description The system shall include an 105 application that provides the same capabilities for controlling and interacting with the system as the smartphone application 6 7 3 Notification Control 6 7 3 1 Des
66. r Manual 73 Open Source Other Requirements 81 Web Interface Support x x x 8 2 Portable Source Code 83 Notification Control Table 13 Ul Requirements Traceability Matrix 29 TP Version 1 0 ALWAYS mHOMe Test 4 2 5 Processing Layer 4 2 5 1 Smart Door Requirements Satisfaction Matrix TP Version 1 0 Processing Layer Requirements Traceability Matrix Customer Requirements 31 Smartphone Application Control 32 Snapshots Taken 3 3 Keep Activities Log 3 4 Emergency Power Supply 3 5 Video Monitoring 3 6 System Portability 3 7 Smart Phone Paring 3 8 Motion Sensor 3 8 Local Storage 3 10 Hardware Security 3 11 Z Wave 3 12 Lock Unlock 3 13 Open Source X X X X X 3 14 Nonintrusive Packaging Requirements 41 Size 4 2 Temperature Control 43 Mounting 44 Casing 45 Software Acquisition 4 6 Included Components 47 Team Logo 48 System Configuration Performance Requirements 51 System Setup X X X X x 52 Notification Time X X X X 53 Latency X X X X 5 4 Response Time X X X X 5 5 Data Transmission Live Video Feed X X X 5 6 Data Transmission Audio Transmission X X X 5 7 Recording Log Log Availability 5 8 Recording Log Storage Capacity 5 9 Power Power Supply 5 10 Power Power Source 5 11 Emer
67. scription This test will verify that the video transmission rate meet the performance 5 4 52 Test Approach This test shall verify that the system transmit audio at a minimum of 800 bits per second 5 4 5 3 Risk Level Medium 51 TP Version 1 0 ALWAYS mHOMe q Test Plan Smart Door 5 4 6 Recording Log Log Availability 5 4 6 1 Description This test will verify that the availability of the recording log meet the performance requirement 5 4 6 2 Test Approach This test shall verify that the logs are updated at least 5 minutes after interaction has ended 5 4 6 3 Risk Level Low 5 4 7 Emergency Backup Battery 5 4 7 1 Description This test will verify the duration of the emergency backup battery 5 4 7 2 Test Approach This test shall verify that the system provides an emergency backup battery that allows it to operate for at least eight hours 5 4 7 3 Risk Level Low 5 4 8 Operating Environment 5 4 8 1 Description This test will verify the ability to function within the performance requirement humidity and weather range of the system 5 4 8 2 Test Approach This test shall verify that the system remains operational within humidity ranges from 090 9590 and temperature ranges from 12 C 70 C 5 4 8 3 Risk Level Low 5 4 9 Video Photo Resolution 5 4 9 1 Description This test will verify the photo and video resolution meet the performance requirement 5 4 9 2 Test Approa
68. th a wide range of browsers in order E 5 Future Moderate Communications Android Browser each browser Code for the product to be accepted Each module needs to be compatible 4 3 x f S E T Firefox Chrome Opera IE Native The website will work correctly on 8 2 Portable Source RIUT1 Request Interface with a wide range of browsers in order 2 5 Future Moderate Android Browser each browser Code for the product to be accepted Each module needs to be compatible 1 5 5 Firefox Chrome Opera IE Native The website will work correctly on 8 2 Portable Source WCUT1 Web Controller with a wide range of browsers in order 5 Future Moderate Android Browser each browser Code for the product to be accepted Each module needs to be compatible 3 Server HDD S Firefox Chrome Opera IE Native website will work correctly on 8 2 Portable Source SHCUT 1 2200 with a wide range of browsers in order 5 5 Future Moderate Communications Android Browser each browser Code for the product to be accepted Table 20 Network Layer Unit Tests 4 4 4 1 4 Data Storage Layer Unit Tests Table 21 Data Storage Layer Unit Tests Data Storage Layer Unit Tests Requirement Requirements Test ID Description Expected Output Action Priority Satisfied store Retri Record a video without being ore Retrieve connected to WIFI then reconnect to d 4 video is uploaded to the Server
69. tivity HRVUTS System Configuration Software Updates User Manual 5 7 CameraMoun ng HRVUTI3 OpenSoure Microphone Camera Weather Safety Interface Support Receptacles Portable Source Code Notification Control Table 12 Requirement Satisfaction Tests 28 TP Version 1 0 ALWAYS ii HOMe Test Smart Door 4 2 4101 Layer 4 2 4 1 Overview 4 2 4 2 Requirements Satisfaction Matrix UI Layer Requirements Traceability Matrix Web Display View Constructor Request Handler USB Interface Microcontroller BUS GPlOInterace Speaker Interface Manager Handler Handler Customer Requirements 31 Smartphone Application Control x x 32 Snapshots Taken x x 33 Keep Activities Log x 34 Emergency Power Supply 3 5 Video Monitoring x x x x x 3 6 System Portability Reguirement Satisfied by Smart Door Device 3 7 Smart Phone Paring 38 Motion Sensor 39 Local Storage x x 3 10 Hardware Security Reguirement Satisfied by Smart Door Device 3 11 Z Wave 3 12 Lock Unlock D x x x 3 13 Open Source x 3 14 Nonintrusive Reguirement Satisfied by Smart Door Device Packaging Requirements 41 Size Requirement Satisfied by Smart Door Device 42 Te
70. ugh the module is faster than 0 3 seconds Establish that the time to relay an action message through the module is faster than 0 3 seconds Establish that the time to relay an action message through the module is faster than 0 3 seconds Establish that the time to relay an action message through the module is faster than 0 3 seconds System action message System action message System action message System action message System action message System action message System action message Table 19 Processing Layer Unit Tests TP Version 1 0 Module relays message in less than 0 3 seconds Module relays message in less than 0 3 seconds Module relays message in less than 0 3 seconds Module relays message in less than 0 3 seconds Module relays message in less than 0 3 seconds Module relays message in less than 0 3 seconds Module relays message in less than 0 3 seconds 36 5 4 Response Time 5 4 Response Time 5 4 Response Time 5 4 Response Time 5 4 Response Time 5 4 Response Time 5 4 Response Time ALWAYS its HOMe Test Smart Door 4 4 4 1 3 Network Layer Unit Tests Network Layer Unit Tests Requirement Requirements Test ID Module Description Expected Output Action Priority Satisfied Each modul ds to b tibl View compa Firefox Chrome Opera IE Native The website will work correctly on 8 2 Portable Source VCUT1 NS wi
71. up Video Log Downloads Video Photo Resolution System Availability Notification Limit Initialization Time Mounting Height Microphone Sensitivity Safety Requirements Camera Mounting Microphone Mounting Camera and Microphone Weather Safety Receptacles Maintenance and Support Requirements Software Updates User Manual Open Source Other Requirements Web Interface Support Portable Source Code Notification Control Table 16 Data Storage Requirements Traceability Matrix 4 3 Hardware Validation Tests 4 3 1 Test Assumptions Hardware validation testing assumes that the prototype is complete TP Version 1 0 32 5 Test Smart Door Hardware validation testing assumes that the end user can follow instructions in order to duplicate the results of the validation 4 3 2 Test Requirements Requirements for hardware validation are driven by system level requirements that would not be satisfied by the software in the Smart Door system These requirements can be demonstrated to have been satisfied by the prototype However there is no guarantee that the end user will comply with the included installation instructions and satisfy the mounting and installation related requirements 4 3 3 Test Dependencies The Hardware Validation tests depend on a completed Smart Door Prototype or suitable mockup bein
72. wants to answer or ignore the call The call will send the homeowner a video feed where he or she can interact with the guest s The mobile application will also allow the homeowner to lock or unlock the door while on and off a call The mobile application will also receive notifications when the door is opened or closed The Smart Door web application will store video interactions with guests and will allow the homeowner to view and download the videos 1 2 Product Scope The goal of the Smart Door is to provide a system to facilitate and improve interactions with visitors to one s home or business The Smart Door offers real time notification when the door bell is rung or the door is opened or closed The system features two way audio and one way video from the door to the mobile application The mobile application will allow the user to view a live feed of the door and lock unlock the door remotely The system will include a web application that will contain a history of all the events the door records The history will consist of a log of every time the door opens and closes with a timestamp and a log of every door to mobile video interaction with a timestamp The video log will allow the user to view delete and download the videos 1 3 Document Purpose The System Test Plan STP is necessary to ensure product design and implementation meets the complete product as specified in the System Requirements Specification SRS and the Detail Design
73. ware Acquisition 6 3 3 1 Description The system software shall be available on the Internet Software for the PC hardware interface shall be packaged with the product on a CD 6 3 4 Included Components 6 3 4 1 Description The product will be delivered to the end user with the Always Home device user manual and mounting hardware 6 3 5 Team Logo 6 3 5 1 Description The logo will be visibly displayed on the base of the final product 55 TP Version 1 0 ALWAYS is HOMe Test Smart Door 6 3 6 System Configuration 6 3 6 1 Description The system s camera doorbell and microphone shall be collocated in a common enclosure 6 4 Performance Requirement 6 4 1 System Setup 6 4 1 1 Description The system shall be able to be mounted and configured in less than ten minutes by the end user The user will mount the hardware near the door and the configuration shall be defined as pairing the user s mobile device with the hardware 6 5 Safety Requirement 6 5 1 Camera Mounting 6 5 1 1 Description The camera shall be secured properly to prevent a fall or collision hazard The camera s mounting base must be properly secured to the door and positioned at the correct height for use 6 5 2 Microphone Mounting 6 5 2 1 Description The microphone shall be secured properly to prevent a fall or collision hazard The microphone s mounting base must be properly secured to a structure and positioned f

System Test Plan

Contents

Download Pdf Manuals

Related Search

Related Contents