Department of Computer Science and Engineering The University of Texas at Arlington

Transcription

1 Department of Computer Science and Engineering The University of Texas at Arlington Team: Auto-Climatix Project: Team Members: Raju Karki Robert Lopez Bishal Shrestha Hai Nguyen Anthony Vecera 7/16/12 2:34 AM

2 Table of Contents 1. Introduction Document Overview Purpose Project Scope Definitions and Acronyms References Overview Software Requirements Specification Architecture Design Specification Architectural Data Flows Architectural Requirements Traceability Matrix Detailed Design Specification Module Decomposition Detailed Design Requirements Traceability Matrix Test Items Overview Risk Ratings Chart Hardware Mobile Application Layer Microcontroller Logic Layer Signal Delivery Layer Master Layer Overview Risks Overview Testable Features Overview Testable Features Non-Testable Features Overview Non-Testable Features... 30

3 7. Approach Overview Overall Strategy Error Handling Acceptance Criteria Overview Unit Tests Hardware Tests Integration Tests System Tests Test Deliverables Overview Deliverables Test Case Specifications Test Results Bugs and Defects Test Code Test Schedule Overview Schedule Approvals... 39

4 List of Figures Figure 1: Overview of System Modules... 6 Figure 2: Architecture Layer Overview Figure 3: Architecture Layer Inter-Subsystem Overview Figure 4: Data Flow Descriptions Figure 5: Architectural Traceability Matrix Figure 6: Module Decomposition Chart Figure 7: Detailed Design Module Traceability Matrix Figure 8: Mobile Application Relational Diagram Figure 9: Microcontroller Layer Relational Diagram Figure 10: Signal Delivery Layer Relational Diagram Figure 11: Overall System Relational Diagram Figure 12: Testing Schedule List of Tables Table 1 Vehicle Hardware Unit Tests Table 2 Unit Test for Mobile Application Layer Table 3 Component Test for Mobile Application Layer Table 4 Microcontroller Logic Layer Unit Tests Table 5 Microcontroller Logic Layer Component Tests Table 6: Microcontroller Logic Layer Integration Test Table 7: Unit Test for Signal Delivery Layer Table 8: Component Test for Signal Delivery layer Table 9: Integration Test for Signal Delivery Layer Table 10: Risk Description... 26

5 1. Introduction 1.1. Document Overview The System Test Plan (STP) is designed to establish a proper testing procedure for the. Each unit, component, layer, and requirement is to be tested to ensure that each of these meets the requirements and specifications set out in the System Requirements Specification, Architectural Design Specification, and the Detailed Design Specification. The document is overview is as follows: Introduction References Test Items Risks Testable Features Non-testable Features Approach Acceptance Criteria Test Deliverables Test Schedule Approvals 1.2. Purpose The is a software and hardware system that is designed to allow users to control the disparate components of their vehicle s air conditioning system through an application on their mobile device. In order to use this system, the majority of the vehicle s existing air conditioning control system will be replaced by special hardware that will then be connected to the various components of the car. Once this hardware is properly installed within the vehicle, the mobile device will then be attached to the hardware through a serial cable, and this will allow the application to control the air conditioning control system. This system consists of three architectural layers: Mobile Application Layer: This layer will take input from external sources such as user input in order to control the hardware of the system. This layer will also display system status information to the user.

6 Microcontroller Logic Layer: This layer serves as a translator between the Mobile Application Layer and the Signal Delivery Layer. The Microcontroller Logic Layer receives control signals from the Mobile Application Layer and status signals from the Signal Delivery Layer. Signal Delivery Layer: This layer will take input from the Microcontroller Logic Layer and the actual vehicle hardware, condition the received input, and then send the signals to the actual vehicle hardware components and the Microcontroller Logic Layer respectively Project Scope Due to a variety of factors that are described in more detail within the software requirements specification, the will be currently limited to the automation of the climate control system of an 80 s Mercedes Benz car, and will specifically focus on the automation of the air conditioning and heating components of the vehicle. In addition, the project being developed will utilize a mock-up demonstration of the concept of the Automotive Climate Controller, with the exclusion of several systems in order to focus specifically on the automated components themselves. A diagram of preliminary system design has been provided. The system will be comprised of three primary modules: the mobile device, the microcontroller, and the individual hardware components. The mobile device sends digital input to the microcontroller, which will convert the digital signals to analog signals, which will be sent to the individual hardware components. The individual hardware components will then send analog signals back to the microcontroller, which will be converted back to digital signals, which will then be sent to the mobile device. The mobile device will then display output to the user. Figure 1: Overview of System Modules

7 1.4. Definitions and Acronyms UTA The University of Texas at Arlington ACC GUI Graphical User Interface OS Operating System AC Air Conditioning Auto-Climatix Name of development team

8 2. References 2.1. Overview This section will list any application requirements or important information about the system mentioned in any other documents. For more detailed information, consult the documents listed below Software Requirements Specification (SRS) Architecture Design Specification (ADS) Detailed Design Specification (DDS) 2.2. Software Requirements Specification Customer Requirements Mobile device incorporated Mobile device connected to a microcontroller Standard wake-up procedure Sleep mode incorporated Automatic mode Manual mode Debug mode Clearly visible GUI GUI with meaningful icons and symbols Straight-line touch gesture recognition System failure message incorporated Microcontroller Requirements Microcontroller unit incorporated Real-time response incorporated Programmable microcontroller Timer included -level programming language compatible microcontroller Microcontroller can be simulated Packaging Requirements Fully assembled microcontroller hardware

9 Preloaded microcontroller firmware Preinstalled application on the mobile device Single package Installable and configurable by someone with fair mechanical knowledge Prepackaged power hardware Connectivity Requirements Active mobile device and microcontroller communication Power supplied to mobile device by the microcontroller Power supplied to components with minimal current needs by the microcontroller Power supplied to components with significant amperage by the microcontroller Control of connected hardware components by the mobile device application Switchover valve control Blower motor control Temperature sensor monitoring Mono-valve control Vacuum source control Compressor clutch control Pressure sensor monitoring Vehicle power status monitoring Performance Requirements Cabin temperature control Prompt cabin temperature alteration response Responsive mobile application No memory leaks in the mobile application Physically rugged system Acceptable failure rate Safety Requirements Fly back circuit implementation Fuse implementation Insulated electrical wiring Extreme input temperature warning

10 Maintenance and Support Requirements Direct support until August 2012 Replaceable hardware components Complete documentation delivery Frequent system testing Release of source code after direct support terminates Major problem detection by debug mode Other Requirements Realistic air conditioning mockup

11 2.3. Architecture Design Specification Configuration Mobile Application Layer Micro- Controller Logic Layer Signal Delivery Layer Figure 2: Architecture Layer Overview

12 Figure 3: Architecture Layer Inter-Subsystem Overview

13 Architectural Data Flows The following table describes the details of each of the data flows shown above Layer Signal Delivery Micro-Controller Mobile Application Data Element M1A M1B M2A M2B M3A M3B M4A M4B M5 M6 M7 M8 L1 L2 L3 L4 S1 S2A S2B S3 S4 S5 S6 Description The GUI returns system status information to the touch screen A touch screen event triggered by the user is handled by the GUI The GUI transmits a formatted user command to the Data Processor Subsystem The Data Processor Subsystem relays formatted system status information to the GUI The user profile data returns a response to data processing Data processing sends a command to the user profile data Data processing returns formatted logical climate commands to data conversion Data conversion returns logical climate status to data processing The config relays vehicle hardware configuration and settings to data conversion Data conversion relays a formatted command and port signal to the Action Handler Subsystem The Update Listener Subsystem relays formatted port and status signal to data conversion The Action Handler Subsystem relays a formatted command signal to the MC Listener Subsystem via a serial protocol The Hardware Status Handler Subsystem transmits a formatted status signal to the Update Listener Subsystem The Signal Processor Subsystem relays formatted digital status signal to the Hardware Status Handler Subsystem The MC Listener Subsystem sends a formatted digital command signal to Signal Processor Subsystem The Signal Processor Subsystem sends an analog command signal to Signal Conditioner Subsystem The Signal Conditioner Subsystem relays an analog status signal to Signal Processor Subsystem The Signal Conditioner Subsystem transmits a conditioned analog control signal to vehicle hardware A raw analog status signal is relayed to the Signal Conditioner Subsystem The vehicle battery supplies unreliable 12V to power The power system sends normalized power to Signal Conditioner Subsystem The power system sends normalized power to Signal Processor Subsystem The power system sends normalized power to the mobile device Figure 4: Data Flow Descriptions

14 Architectural Requirements Traceability Matrix Acceptance Criterion Mobile Application Layer Microcontroller Logic Layer Signal Delivery Layer Mobile Device Implemented Microcontroller Connected to Mobile Device Automatic/Manual/Debugging Mode Programmable, Real-time Responding Microcontroller Controls the vehicle hardware interface with the microcontroller Fly Back Circuits Implemented Figure 5: Architectural Traceability Matrix

15 2.4. Detailed Design Specification Module Decomposition Config U1 U2 MOBILE APPLICATION LAYER GUI GUI HANDLER MD2 MD3 DATA PROCESSOR CLIMATE CONTROL PROCESSOR DATA CONVERSION M5 M4A,M4B MDC1 HEXLOGIC CONVERTER HEX(M6) HEX(M7) MOBILE COMMUNICATIONS HEXBIN CONVERTER BIN(MOB1) MD1 PROFILE WRITER M3B PROFILE PARSER M3A MD4 CONFIG PARSER THREAD LISTENER BIN(M8) PROFILE BIN(L1) SIGNAL DELIVERY LAYER SIGNAL CONDITIONER S2A 12 VS (0-12V)S2B 0-12V ANALOG IN S5 GROUND 0 V(S7) POWER 12VS(S4) L4 S1 L6 L5 MICROCONTROLLER LOGIC MC LAYER COMMUNICATIONS SIGNAL PROCESSOR SUBSYSTEM L2 L3 MCC1 RS232 PORT MCC2 MAX VC(S6) CONSTANT SWITCH 5 VS(S8) 12 VC(S3) 5VC(S9) Figure 6: Module Decomposition Chart

16 Detailed Design Requirements Traceability Matrix Requirements Modules Mobile Device Implemented Microcontroller Connected to Mobile Device Automatic/Manual/Debugging Mode Programmable, Real-time Responding Microcontroller Controls the vehicle hardware interface with the microcontroller Fly Back Circuits Implemented GUI Handler X X GUI Listener X X User Event Controller X X Profile Writer X X Profile Parser X X Profile X X Climate Control Processor X X Configuration File X X Configuration Parser X X Hexlogic Converter X X Hexbin Converter X X Thread Listener X X X RS232 Port X X X Max232 X X X Signal Processor X X 12VS Power X X 0-12V Analog In X X Ground X X Constant X X Switch X X Figure 7: Detailed Design Module Traceability Matrix

17 3. Test Items 3.1. Overview The purpose of this section outlines the various modules and components that will be tested by Team Auto-Climatix. The system is broken down into different layers by with unit test and components. The steps of testing are, from lowest level to highest level: - Module/Unit Testing - Component Testing - Integration Testing - System Testing 3.2. Risk Ratings Chart Rating Description Critical Medium Low Failure will result in total implementation halt until test is satisfactorily passed. All staff allocated to issue alleviation. Failure will result in total implementation halt on the component, and all input and output components. All staff directly responsible for development paradigm allocated to issue alleviation. Failure will result in implementation halt on component. Staff member responsible for unit will be directed to complete issue alleviation or request elevation of risk rating. Failure will result in non-stop documentation of component. Resources will be allocated on an availability basis Hardware Unit Test ID Data flow Input Involved Modules Expected Result Risk VU1 S2A/S2B 12V, Heat VU2 S2A/S2B 0/12V VU3 S2A/S2B 0/12V VU4 S2A/S2B PWM VU5 S2A/S2B PWM Source: VS, Temp. Sensor Dest: 0-12V Analog In 0-12V Out Low Source: VS Dest: Compressor Clutch Engage/Disengage Low Source: VS Dest: Switchover Valve Engage/Disengage Source: VS Variant monovalve Dest: Monovalve displacement Source: VS Dest: Blower Motor Variant fan speed Table 1 Vehicle Hardware Unit Tests

18 3.4. Mobile Application Layer Unit Test ID Data flow Input Involved Modules Expected Result Risk MA1 U1/U2 Event Source: Mobile device Dest: GUI Handler Information of system showed on the screen MA2 MD2/MD3 Request Source: GUI Handler Dest: Climate Control Processor Status information returned to GUI handler MA3 MD1 Request Source: Climate Control Processor Dest: Profile Writer The data stored in the profile file MA4 MD4 Request Source: Climate Control Processor Dest: Profile Parser The data loaded from the config file MA5 M3A Access Source: Profile Parser Dest: Profile file The desired configuration under text format. MA6 M3B Access Source: Profile Writer Dest: Profile file Information updated in profile file MA7 M4A/M4B Send/Request Source: Climate Control Processor Dest: Hexlogic Converter Logical climate object updated. MA8 M5 Access Source: Config Parser Dest: Config file Information of AC componets MA9 MDC1 Request Source: Hexlogic Converter Dest: Config Paser AC component objects updated MA10 M6/M7 Send/Request Source: Hexlogic Converter Dest:Hexbin Converter Hexadecimal/binary data transmitted MA11 MOB1 Send Source: Thread Listener Dest: Hexbin Converter Binary stream received

19 MA12 M8 Send Source: Hexbin Converter Dest: RS232 Binary stream received at Microcontroller MA13 L1 Receive Source: RS232 Dest: Thread Listener Binary stream received MA14 - All MA15 - All MA16 - All MA17 - All MA18 - All MA19 - All MA20 - All Entire interfaces of GUI handler Entire interfaces of Climate Control Processor Entire interfaces of Config Writer Entire interfaces of Config Parser Entire interfaces of Hexlogic Converter Entire interfaces of Hexbin Converter Entire interfaces of Thread Listener Unit tests: MA1, MA2 Unit tests: MA2, MA3, MA4 Unit tests: MA3, MA6 Unit tests: MA4, MA5 Unit tests: MA7, MA9, MA10 Unit tests: MA10, MA11, MA12 Unit tests: MA11, MA13 Table 2 Unit Test for Mobile Application Layer

20 Test ID Method Unit test Function Expected type return Risk MA21 Click events MA14 Handle manipulation of user on screen None MA22 processfan MA15 Process a request about Value of slider on the fan configuration screen MA23 processtemp MA15 Process a request about desired temperature The current temperature MA24 processairdirection MA15 Process a request about air flow direction Status of the process MA25 changemode MA15 Change operating mode for the AC system The current mode MA26 sendstatus MA15 Feedback for a request to GUI handler Status of the request MA27 writeprofile MA16 Store a desired Status of the request. configuration of AC A new line in profile system in profile MA28 loadprofile MA17 MA29 loadcomponent MA8 MA30 converthex MA18 MA31 convertlogicdata MA18 MA32 convertbin MA19 MA33 sendsignal MA19 MA34 converthex MA19 MA35 startlisten MA20 MA36 Run MA20 Load desired configuration stored in profile Load information of AC components Convert logic data to hexadecimal data. Transmits hexadecimal data Convert hexadecimal to logic data. Transmits status information Convert hexadecimal to binary transmit binary data Send binary signal to RS232 Convert binary to hexadecimal. Transmit status information Establish a connection to RS232 Listen binary signal from RS232 Text string of the desired information Component objects 2-byte hexadecimal data logical climate objects Logical climate object 2-byte binary data Status of the send command 2-byte hexadecimal data Status of the connection Binary data Table 3 Component Test for Mobile Application Layer

21 Figure 8: Mobile Application Relational Diagram

22 3.5. Microcontroller Logic Layer Unit Test ID Method Data flow Input Expected Result Risk MLU1 MLU2 Tx/Rx Transfer Protocol L1-3, M8, MCC1, 2 0/5V, -15/15V -15/15V or 0/5V decodesignal (byte Identified value assigned to signal) L3 Encoded byte identified port Single byte split evenly encodesignal (byte 0-5V, logical port between port number and Voltage, int portid) S1 number signal strength PWM values output from Mediu m Mediu MLU3 m Mediu MLU4 generatepwm() L4 Port Signal Strength values delegated to ports m selectinput (int Activation of defined MUX Mediu MLU5 selector) L6 4 bits selector channels m collectcommand MLU6 (byte RXReg) L3 RX Register Value Byte Signal Critical transferstatus (byte MLU7 status) L2 Encoded byte Transferal of byte to TSReg Table 4 Microcontroller Logic Layer Unit Tests Test ID Method Unit test Function Expected type return Risk MLC1 Signal Processor MLU5, MLU7, MLU1 Status Input Handler Relay of encoded status to Communications constantly Critical MLC2 Signal Processor MLU4, MLU2 Control Handler Output of PWM on PORT Critical MLC3 Communications MLU6, MLU3, MLU1 Data Relay TX/TX MLC4 Signal Processor - Power On Start MC Activation Low Table 5 Microcontroller Logic Layer Component Tests Test ID Layer Components Input Expected Output Risk Microcontroller Signal Processor, Control byte/status I1 Logic Layer Comms. voltage Control/Status Signal Table 6: Microcontroller Logic Layer Integration Test

23 Figure 9: Microcontroller Layer Relational Diagram 3.6. Signal Delivery Layer Test ID Method Unit test Function Expected type return Risk SDU1 Voltage Supply 12VS 12V Constant 12V Constant to all the hardware component SDU2 Signal 12V Analog IN 0-12V, 4 bytes 0-5V, Port Medium Condition Selection SDU3 Voltage Constant 12V Static 5V Constant Medium Conversion SDU4 Voltage Conversion Switch 12V Static 12V Constant, 5V Constant Table 7: Unit Test for Signal Delivery Layer

24 Test ID Module Feature Input Expected Risk Output SDC1 Power Voltage Static 12V Constant 12V conversion and 5V SDC2 Signal Signal Handler 0V/5V Turn the system Conditioner off/on SDC3 Signal Scale the input 0-12V 0-5V Conditioner voltage SDC4 Signal Conditioner Input port selection 4 bytes Single port Medium Table 8: Component Test for Signal Delivery layer Test Id Layer Feature Input I1 I2 I3 Signal Delivery Layer Signal Delivery Layer Signal Delivery Layer Supply Voltage Signal Relay 12 V Static Byte, Voltage Expected Output 12V constant to Hardware Component and 5V constant to mobile device and microcontroller System turn off/on, change the speed Risk Medium Signal Relay Voltage Voltage Table 9: Integration Test for Signal Delivery Layer Figure 10: Signal Delivery Layer Relational Diagram

25 3.7. Master Layer Overview Figure 11: Overall System Relational Diagram

26 4. Risks 4.1. Overview The purpose of this section is to go over the impact that the testing phase may encounter. We will first describe the risk, then the approach to avoid such risk, and finally the risk will be given a severity level to explain how much the risk is likely to happen. ID Risk Description Avoidance Plan Severity The hardware equipment is damaged The internal electric circuits are damaged The microcontroller does not communicate with mobile device serially Software bugs are not caught prior to the complete system run The vehicle hardware has unpredictable behavior 6 Circuit design is inadequate The team will attempt to repair the damaged equipment, a surplus inventory will be maintained, or the equipment will be ordered for a replacement The team will attempt to repair the damage circuit or build a new circuit The team will add an extra board and a contingency communication protocol Run the system under various mode to ensure all data is working together Use black box testing and have a contingency plan for bypassing troublesome components in the mockup The team will redesign the circuits with more safety components incorporated HIGH HIGH HIGH LOW HIGH LOW Associated Layer Microcontroller Logic Signal Delivery Mobile Communication, Microcontroller Mobile Communication, Microcontroller Microcontroller logic Signal Delivery Layer Table 10: Risk Description

27 5. Testable Features 5.1. Overview Testable features are those, which can be tested and verified by a user of the product. There are three risk levels associated with a test. A high-risk level means that a particular feature may be either difficult to test or require more than ten test runs before success is achieved. A medium risk level means that a particular feature may require four to ten test runs before success is achieved. A low risk level means that a particular feature may require less than four test runs before success is achieved. The criteria for success (and failure) will be discussed later in the document Testable Features Standard wake-up procedure Risk: Low Description: This test will verify that the system becomes active, or "wakes-up," in a consistent manner User's Path: The user will start the vehicle. The system should start up after the vehicle has powered on completely Sleep mode incorporated Risk: Low Description: This test will verify that the system becomes inactive, or "goes to sleep," when the vehicle is powered down User's Path: The user will "turn off" the vehicle by shutting it down normally, such as by removing his or her vehicle key. The system state should transition to sleep mode after the vehicle has shut down completely Automatic mode Risk: Description: This test will verify that the system works on its own to adjust the cabin temperature of the vehicle that the system is installed on.

28 User's Path: The user will input a temperature input into the system. The system should begin altering the settings of the system's hardware components in order to change the temperature to match the user's temperature input as closely as possible Manual mode Risk: Description: This test will verify that the system will allow the user to manually control the external controls of the air conditioning system through the touch screen interface of the system User's Path: The user will select the manual mode button. The system state will change to manual mode. The user will then touch buttons that will have appeared on the touch screen that will allow him or her to control external air conditioning features that were at one point controlled through manual knobs and switches. The system should begin altering the settings of the adjusted system's hardware components in order to match the user's desired settings as closely as possible Debug mode Risk: Description: This test will verify that the system will allow the user to enter debug mode. This test will also verify that the system will allow the user get information about the system's connected hardware components User's Path: The user will select the debug mode button. The system state will change to debug mode. The system will then send a PVM signal to all connected hardware components of the system. The devices that are connected will then respond back. Devices that are not connected will not. The system then shows on its touch screens all of the devices that the system has knowledge of. Devices that are connected will show up on the screen as boxes of one color, and devices that are not connected will show up on the screen as boxes of another color. The user will then see the output of debug mode on the touch screen Straight-line touch gesture recognition Risk: Low

29 Description: This test will verify that the system will allow the user to use straight-line touch gestures to interact with some portions of the system User's Path: The user makes a straight-line touch gesture on the system's touch screen. The system will capture that input and process the user's request accordingly System failure message incorporated Risk: Low Description: This test will verify that the system will inform users if the is not capable of running normally due to a system failure of some sort User's Path: The user will be operating the vehicle normally. Should the system become unstable, it will send a system failure message to the user. It is up to the user to act accordingly Extreme temperature input limits Risk: Low Description: This test will verify that the user cannot make extreme temperature input requests of the system User's Path: The user will input a temperature input into the system. The system should have preset temperature input limits, so the user cannot input an extreme temperature input in the first place.

30 6. Non-Testable Features 6.1. Overview Non-testable features are features that users cannot test or are features that require no testing. The reasons as for why the feature will not require testing will be explained along with the feature that is not to be tested Non-Testable Features Mobile device incorporated This is a system hardware component. It will be verified upon system testing Mobile device connected to a microcontroller This is a system hardware component. It will be verified upon system testing Clearly visible GUI This feature will be tested when the system's Mobile Application Layer is being tested and will require no separate testing GUI with meaningful icons and symbols This feature will be tested when the system's Mobile Application Layer is being tested and will require no separate testing Microcontroller unit incorporated This is a system hardware component. It will be verified on system testing Real-time response incorporated The microcontroller that was selected by the development team should already have this functionality. It will be verified on system testing Programmable microcontroller The microcontroller that was selected by the development team should already have this functionality. It will be verified on system testing.

31 Timer included The microcontroller that was selected by the development team should already have this functionality. It will be verified on system testing level programming language compatible microcontroller The microcontroller that was selected by the development team should already have this functionality. It will be verified on system testing Microcontroller can be simulated The microcontroller that was selected by the development team should already have this functionality. It will be verified on system testing Fully assembled microcontroller hardware The hardware that will be delivered to the customer will be fully assembled in order to deliver the functionality of the system. It will be verified on system testing Preloaded microcontroller firmware The microcontroller that was selected by the development team should already have this functionality. It will be verified on system testing Preinstalled application on the mobile device The development team should have loaded the application onto the mobile device during the implementation phase of the project. It will be verified on system testing Single package The system will be delivered as a single package. It will be verified on system testing Installable and configurable by someone with fair mechanical knowledge There is no possible way to test this feature considering the schedule constraints of the development team. Furthermore, the variety inherent within the subject of "someone with fair mechanical knowledge" makes testing this feature unreliable, at best. This feature will not be tested further Prepackaged power hardware The system will come with any special hardware that is necessary to power the system. This feature will not be tested further.

32 Active mobile device and microcontroller communication The supply of power from the microcontroller to the mobile device implies that the mobile device and the microcontroller are communicating actively. This feature will not be tested further Power supplied to mobile device by the microcontroller The system needs power to function. It is expected that the mobile device will be receiving power from the microcontroller. This feature will not be tested further Power supplied to components with minimal current needs by the microcontroller The system needs power to function. It is expected that components with minimal current needs will be receiving such current needs from the microcontroller. This feature will not be tested further Power supplied to components with significant amperage by the microcontroller The system needs power to function. It is expected that components with significant amperage will be receiving such amperage from the microcontroller. This feature will not be tested further Control of connected hardware components by the mobile device application A testable feature supersedes this feature. This feature will not be tested further Switchover valve control A testable feature supersedes this feature. This feature will not be tested further Blower motor control A testable feature supersedes this feature. This feature will not be tested further Temperature sensor monitoring A testable feature supersedes this feature. This feature will not be tested further Mono-valve control A testable feature supersedes this feature. This feature will not be tested further.

33 Vacuum source control A testable feature supersedes this feature. This feature will not be tested further Compressor clutch control A testable feature supersedes this feature. This feature will not be tested further Pressure sensor monitoring A testable feature supersedes this feature. This feature will not be tested further Vehicle power status monitoring A testable feature supersedes this feature. This feature will not be tested further Cabin temperature control A testable feature supersedes this feature. This feature will not be tested further Prompt cabin temperature alteration response The system is designed to work as quickly as possible to respond to the user's commands. Despite this, there are many significant factors that can impede the system's ability to alter the cabin temperature promptly. The system will perform as well as possible to address this issue. This feature will not be tested further Responsive mobile application The mobile application is designed to respond in a timely manner. This feature will not be tested further No memory leaks The development team is not willing placing memory leaks in the system, and will work to remove any memory leaks that it may discover within the system within schedule constraints. This feature will not be tested further Physically rugged system While the system components may not be particularly sturdy, the system itself will be operating in an enclosed environment that will not be damaged frequently with the exception of external forces that are beyond the control of the development team. As the system will not be directly assaulted during normal operations, the system is thus considered to be physically rugged. This feature will not be tested further.

34 Acceptable failure rate There is not enough time in the project to determine whether or not the system will fail at an acceptable rate. The development team will create a system that is as successful as possible in order to make the system as acceptable as possible within schedule constraints. This feature will not be tested further Fly back circuit implementation This is a system hardware component. It will be verified on system testing Fuse implementation This is a system hardware component. It will be verified on system testing Insulated electrical wiring The electrical wiring used in the is already insulated. This feature will not be tested further Direct support until August 2012 The development team will support the product until the project's conclusion, which is August This feature will not be tested further Replaceable hardware components The hardware of the system is not particularly esoteric or of a niche market; all components were procured via mainstream hardware suppliers, such as Mouser Electronics. This feature will not be tested further Complete documentation delivery The documentation that will be developed by the development team will be as complete as possible considering schedule constraints. This feature will not be tested further Frequent system testing The system is assumed to be frequently by the development team. This feature will not be tested further Release of source code after direct support terminates The source code will be released after the previously stated time frame expires. This feature will not be tested further.

35 Major problem detection by debug mode A testable feature supersedes this feature. This feature will not be tested further Realistic air conditioning mockup The mockup of the system will be as realistic as possible. This feature will not be tested further. 7. Approach 7.1. Overview This section describes how team Auto-Climatix will keep a record of testing and testing results and handle problems during testing Overall Strategy Team Auto-Climatix will be using both black box testing and white box testing as described in the ADS and DDS document to ensure that the system adapts all of the requirements that were defined and solicited in the SRS. The tests will also be performed to assure that the system matches up with the designs specified in the ADS and the DDS. Team Auto-Climatix will document the following during testing: Module name Test ID Type of test (unit, singular component, etc.) Date/Time of test Test results o Pass o Fail State of test: open, closed, reopened, or pending. Attempt number 7.3. Error Handling Even though the testing is carried out in a sophisticated manner, it should be managed effectively and efficiently. Based on the module name for each test case, we can recognize which module the test case is belonged. For both unit and component test cases, each test will be controlled over a team member who takes responsibility for the module. Following is an order that will use to handle entire test cases of the system: Testing over each test case Keeping track by writing down the result of the test case

36 Supplying tested time and comments for every test case, especially the detail data for the test cases not failed. lighting red background color for each test case Assigning the failed test cases for the second tester to review. Set up a schedule and a team member to fix the error of the module regarding to the failed test cases 8. Acceptance Criteria 8.1. Overview The purpose of this test plan is to ensure that the system is bug free in most of the cases. This section describes what needs to be done in order for each category of tests in this test plan to be completed Unit Tests Pass All unit tests return the expected feedback for a correct input, and return an appropriate error indication for an improper incorrect. The appropriate outputs for tests are defined in Test Items Fail Any unit test returns an unexpected feedback for a given input Hardware Tests Pass The hardware component returns an expected value or performs as expected when given input or in a controlled environment Fail The hardware component returns an unexpected value or performs unexpectedly when given input or in a controlled environment Integration Tests

37 Pass The integrated units have an active communication among themselves and they are passing data to each other in an expected format and sequence Fail The integrated units don t have an active communication among themselves or they are not passing data to each other in an expected format or sequence System Tests Pass The system meets the requirements as defined on the SRS Fail The system doesn t meet the requirements as defined on the SRS. 9. Test Deliverables 9.1. Overview This section will list the deliverables created before, during, and after testing the Automotive Climate Controller System Deliverables Test Case Specifications This will list all the inputs and their corresponding expected output for those inputs that will be used during the tests that will be done to ACC System Test Results The results of all the tests to the ACC will be recorded allowing the team for the usage of the results if needed in future. This includes expected results, unexpected results, and any actions taken to fix bugs or defect bugs during the course of testing. All tests will be assigned a number to track them in future if needed Bugs and Defects

38 Any kinds of bugs or defects found during testing of the system will be recorded using a numbering system followed by the comments and indication whether it was fixed or not. This will be kept for future reference and records during the testing phase. This will be a significant source for the system change or system modification in future Test Code All the documentation including the test cases, test results and bug and defects list will be recorded that might be accessible to the user upon request. The testing code that is created by the team will be given to the user along with the system. 10. Test Schedule Overview The team has maintained a straight plan to accomplish all the tasks discussed earlier in this document. The following is a list of the due dates and the items that contribute to accomplishing this test plan: Schedule Task Name Planned Start Planned Finish Planned Work Unit Test 07/10/ /02/ Hardware Test 07/20/ /05/ Integration Test 07/25/ /05/ System Validation Test 07/28/ /07/ Figure 12: Testing Schedule

39 11. Approvals The following list of signatures will approve this document: Name and Roles Signature Date Project Sponsor (Dr. Gergely Zaruba): Project Manager (Mr. Mike O Dell): Team Leader (Raju Karki): Team Member (Anthony Vecera): Team Member (Bishal Shrestha): Team Member (Hai Nguyen): Team Member (Robert Lopez):