5 Replies Latest reply on Jan 8, 2010 12:03 PM by philmodjunk

    Test Data Structure

    vipero00

      Title

      Test Data Structure & Analysis

      Post

      I am a test engineer and am using FMP 10 on my MacBook Pro running OS10.5.8. For now I am running one kind of test and am storing the results in FM. Basically I have two major tables. SessionTbl and TestResultsTbl.

       

      SessionTbl has each test session that I have run.

       

      TestResultsTbl stores the test results. There are 16 fields in this table of which seven have to do with configuration. The rest id the unit contain raw data and calculated results and the sessionID.

       

      This works well for data entry by session and printing reports for a test session.

       

      The configuration fields are:

      Channel

      Rate

      Power

      Port

      Position

      Polarity

      FirmWareVer 

       

      Now I want to do several comparisons to show unit to unit variation, test repeatability and other effects. I need to compare apples to apples so Channel, Rate, Power, Port, Position, and Polarity need to match in any comparison. In all there are 12 (channel, rate) combinations and 8 (Port, Position, Polarity) combinations for a total of 96 total tests per unit. Because of the large number of total tests and the time required a test session is usually limited to a single unit and a block of 24 tests. If I know the worst case combinations I may only do those worst case ones to save time.

       

      I've thought about listing the combinations in a CombinationsTbl with a CombID key field in order to make the comparisons easier.

       

      Just to get me started I think I have a 4 step process to go through.

       

      1. Identify the total number of sets of data I can compare.

      2. Select two of them

      3. Extract the data from the two selected sets.

      4. Compare config to config in the selected sets.

       

      I don't know how to do any of those steps and I don't know the FM terminology so I can search properly. Any push in the right direction would be greatly appreciated.

       

      Norm 

        • 1. Re: Test Data Structure & Analysis
          philmodjunk
            

          Here are some key terms you can research:

           

          Summary fields and summary reports--this is a way to produce aggregate results like Sum, Average, standard deviation, min, max.... over a group of records.

           

          Finding records and a "found set" that's the easiest way to select a group of test result records with matching configuration. The above summary fields will compute values for all records in a given found set.

           

          Sub-Summary parts--can't tell if you need this, but it's a way to group records by a given field value (such as your configuration field) and display sub-totals via summary fields.

           

          Aggregate functions--this is another approach to computing Sum, Average, and other values that would use a relationship to match results of a specified configuration.

          • 2. Re: Test Data Structure & Analysis
            vipero00
              

            PhilModJunk - thanks for the hints.

             

            I've been successful at creating two levels of sort. I not only established a list of configurations composed of three fields but a number of States that are comprised of five fields. For the states I just calculated a state numer and sorted by it. TestState = Power + 100 * Rate::RateID + 1000 * Channels::ChannelID+ 10000 * FirmWare::FirmWareID + 100000 *  DUT::DUTid. This gives me guaranteed unique states for all of the test results that I have.

             

            I used two sub-summary parts so now each state is listed followed by a list of results that is sorted and grouped by configuration.

             

            What this looks like is a long single column with groupings by state then configuration.

             

            Is it possible to manipulate this into a table so that there are nine columns (state, config1, config2....., config8) one for each configuration) and each row is a different state?

             

            About aggregation I don't really need to compute any mins, max, averages or totals. 

            • 3. Re: Test Data Structure & Analysis
              philmodjunk
                

              What you are describing is sometimes referred to as a "cross tab" query or report. This can be done in Filemaker though not as easily as you can with some other database products.

               

              You can create a layout that refers to your session table and uses 8 portals to display your 8 columns of data in one row portals. When you create such a portal, you'll find theres an option at the bottom for specifying the initial row and number of rows. For column one you specify 1 as your initial row, column 2 you specify 2 as your initial row... etc. This trick is sometimes called a "horizontal portal" as you can hide the portal boundaries and make this look like a single portal with the records laid out horizontally instead of vertically.

              • 4. Re: Test Data Structure & Analysis
                vipero00
                   If I'm not mistaken this approach requires that the records be sorted so that in the data field the config order is 1234567812345678123... This also means that there can be no missing configurations. Say for some unit config 4 is missing that will move 5 into 4s spot and the resulting matrix is hosed. Do I have that right?
                • 5. Re: Test Data Structure & Analysis
                  philmodjunk
                    

                  If I undersatnd you correctly, No. You just need two tables. One with one record for each state and a second that stores the data that you display in the 8 portal based columns.

                   

                  It occurs to me that for a given "state" you may have more than one set of 8 data records. Perhaps you would run the same set of test on more than one data. In those situations you'd have to include a second pair of fields in your relationship to filter the portals to show the desired data.