Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000151Testlink 1.6.xReports, Metrics, Export and Printpublic2005-10-03 06:192005-10-31 19:28
Reporterkevin 
Assigned Tokevin 
PriorityurgentSeverityblockReproducibilityalways
StatusclosedResolutionopen 
PlatformOSOS Version
Product Version1.6 RC1 
Fixed in Version 
Summary0000151: not all pages are using same build set that is produced by builds.in.php function getBuilds($idPlan)
DescriptionI am testing with tip-of-tree code checked out on oct 2. I performed an upgrade from 1.5 to 1.6 RC1.

I believe the build table structure was changed a few weeks ago. I'm not sure if ALL reports and execution pages have been adjusted correctly to use this new table structure.
 
IS EVERYBODY USING THE builds.in.php function getBuilds($idPlan) to retrieve the builds for a test plan? I don't think all pages are using this and the recent change to the build table is causing discrepancies in report data.
 
I seem to be seeing one set of builds being used for these reports :
 
Results - Query Metrics -- this uses the above mentioned function
Results - The Overall Build Status
 
And another set of builds being used for these reports:
 
Results - General Test Plan Metrics
Execution Mode - color coding of test cases
 
 
---------------
DETAILS:
 
If you use the test data I have uploaded to the tikiwiki site. You can see what I mean:
 
1. select the test plan "IN - 2.1.0 Twoway" (in the db this is project.id = 70)
2. select Test Reports and Metrics
3. select "the overall build status" -
you can clearly see 13 test cases have been marked as passed on build 14
(my Query Metrics report will generate similar results - I am using the )
4. select "general test plan metrics"
5. 21 test cases are marked as passed - 8 more than expected
6. select execute
7. select TC Colored according to "Last Result"
8. count the number of test cases printed in green - there are 21 - 8 more than expected
 
After doing some manual SQL work I have discovered the reason for the discrepancy.
 
The following 8 test cases are marked as passed on build.id 35
1. tcid = 7246 passed build 35
2. tcid = 7247 passed build 35
3. tcid = 7248 passed build 35
4. tcid = 7256 passed build 35
5. tcid = 7262 passed build 35
6. tcid = 7272 passed build 35
7. tcid = 7274 passed build 35
8. tcid = 7276 passed build 35
 
Build.id=35 belongs to a different project! Instead of projid=70, build.id=35 belongs to projid=58. What I think is happening
is that both projects contain build.name=BUILD 15.
 
mysql> select * from build where build.id='35';
+----+--------+----------+------+
| id | projid | name | note |
+----+--------+----------+------+
| 35 | 58 | BUILD 15 | NULL |
+----+--------+----------+------+
1 row in set (0.00 sec)

Again using the data I have uploaded to TikiWiki, you can see how there are
multiple "BUILD ID" entries associated with 3 different projid.
 
mysql> select * from build where build.name="BUILD 15";
+----+--------+----------+------+
| id | projid | name | note |
+----+--------+----------+------+
| 35 | 58 | BUILD 15 | NULL |
| 36 | 63 | BUILD 15 | NULL |
| 37 | 70 | BUILD 15 | NULL |
+----+--------+----------+------+
3 rows in set (0.00 sec)

I think some page are not using the same algorithm builds.in.php function getBuilds($idPlan) provides. This is causing discrepancies in result data.
 
Kevin
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000205)
kevin (reporter)
2005-10-10 20:25

I have uploaded test data to the tiki-wiki site in the file-gallery section which should be used to repro this bug.
(0000215)
kevin (reporter)
2005-10-12 06:14

Martin has asked me to fix this.
(0000230)
kevin (reporter)
2005-10-14 09:08

I've added a function to lib/functions/build.inc.php called getCommaDelimitedBuilds($idPlan, $order_by) which will return a list of build.ids in comma delimited format.

We need to somehow use this in the other reports so that we only select results via SQL statement using

select results where build.id IN ($commaDelimitedBuilds).

An example of this notation is in lib/functions/resultsMoreBuilds.php - and this prevents us retrieving results using build.ids that are not part of the test plan.
(0000235)
kevin (reporter)
2005-10-15 20:05

General Test Plan Metrics report is now fixed. Changes made to lib/functions/results.inc.php
(0000236)
kevin (reporter)
2005-10-16 04:27

fixes checked into lib/execute/execNavigator.php - tree is now populated with correct results.

- Issue History
Date Modified Username Field Change
2005-10-03 06:19 kevin New Issue
2005-10-10 20:25 kevin Note Added: 0000205
2005-10-12 06:14 kevin Note Added: 0000215
2005-10-14 09:08 kevin Note Added: 0000230
2005-10-15 20:05 kevin Note Added: 0000235
2005-10-16 04:27 kevin Note Added: 0000236
2005-10-19 05:10 kevin Assigned To => kevin
2005-10-19 05:10 kevin Status new => resolved
2005-10-31 19:28 fman Status resolved => closed



Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker