Proposing SQL Statement Coverage Metrics: Difference between revisions
Programsam (talk | contribs) |
Programsam (talk | contribs) No edit summary |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 124: | Line 124: | ||
statements. | statements. | ||
'''Server-side target statement coverage''' = | '''Server-side target statement coverage''' = [[File:Sess-eqn-1.png]] | ||
where Test(''t'') is a SQL statement tested at least once. | where Test(''t'') is a SQL statement tested at least once. | ||
| Line 138: | Line 138: | ||
'''Metric''': The input variable coverage criterion can be measured by the percentage of input variables tested at least once by the test set out of total number of input variables found in any target statement in the production code of the system. | '''Metric''': The input variable coverage criterion can be measured by the percentage of input variables tested at least once by the test set out of total number of input variables found in any target statement in the production code of the system. | ||
'''Input variable coverage''' = | '''Input variable coverage''' = [[File:Sess-eqn-2.png]] | ||
where Test(f) is an input variable used in at least one test. | where Test(f) is an input variable used in at least one test. | ||
| Line 148: | Line 148: | ||
The relationship between target statement coverage and input variable coverage is not yet known; however, we contend that input variable coverage is a useful, finer-grained measurement. | The relationship between target statement coverage and input variable coverage is not yet known; however, we contend that input variable coverage is a useful, finer-grained measurement. | ||
Input variable coverage has the effect of weighting a target statement which has more input variables more heavily. Since most input variables are each a separate potential vulnerability if not adequately validated, a target statement which contains more input variables is of a higher threat level. | Input variable coverage has the effect of weighting a target statement which has more input variables more heavily. Since most input variables are each a separate potential vulnerability if not adequately validated, a target statement which contains more input variables is of a higher threat level. | ||
== 4. Related Work == | == 4. Related Work == | ||
| Line 337: | Line 337: | ||
iTrust was written to conform to a MySQL<sup>8</sup> back-end. The MySQL JDBC connector was used to implement the data storage for the web application by connecting to a remotely executing instance of MySQL v5.1.11-remote-nt. The <code>java.sql.PreparedStatement</code> class is one way of representing SQL statements in the JDBC framework. Statement objects contain a series of overloaded methods all beginning with the word execute: <code>execute(…)</code>, <code>executeQuery(…)</code>, <code>executeUpdate(…)</code>, and <code>executeBatch()</code>. These methods are the java.sql way of issuing commands to the database and each of them represents a potential change to the database. These method calls, which we have previously introduced as ''target statements'', are the focus of our coverage metrics. | iTrust was written to conform to a MySQL<sup>8</sup> back-end. The MySQL JDBC connector was used to implement the data storage for the web application by connecting to a remotely executing instance of MySQL v5.1.11-remote-nt. The <code>java.sql.PreparedStatement</code> class is one way of representing SQL statements in the JDBC framework. Statement objects contain a series of overloaded methods all beginning with the word execute: <code>execute(…)</code>, <code>executeQuery(…)</code>, <code>executeUpdate(…)</code>, and <code>executeBatch()</code>. These methods are the java.sql way of issuing commands to the database and each of them represents a potential change to the database. These method calls, which we have previously introduced as ''target statements'', are the focus of our coverage metrics. | ||
<center>[[File:SESS-Figure7.png]]<br /> | |||
'''Figure 7. General iTrust architecture'''</center> | |||
The version of iTrust we used for this study is referred to as iTrust Fall 2007, named by the year and semester it was built and redistributed to a new set of graduate students. iTrust was written to execute in Java 1.6 and thus our testing was conducted with the corresponding JRE. Code instrumentation and testing were conducted in Eclipse v3.3 Europa on an IBM Lenovo T61p running Windows Vista Ultimate with a 2.40Ghz Intel Core Duo and 2 GB of RAM. | The version of iTrust we used for this study is referred to as iTrust Fall 2007, named by the year and semester it was built and redistributed to a new set of graduate students. iTrust was written to execute in Java 1.6 and thus our testing was conducted with the corresponding JRE. Code instrumentation and testing were conducted in Eclipse v3.3 Europa on an IBM Lenovo T61p running Windows Vista Ultimate with a 2.40Ghz Intel Core Duo and 2 GB of RAM. | ||
| Line 403: | Line 406: | ||
This work is supported by the National Science Foundation under CAREER Grant No. 0346903. Any opinions expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. | This work is supported by the National Science Foundation under CAREER Grant No. 0346903. Any opinions expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. | ||
== | == 10. References == | ||
: <sup>[1]</sup> B. Beizer, Software testing techniques: Van Nostrand Reinhold Co. New York, NY, USA, 1990. | : <sup>[1]</sup> B. Beizer, Software testing techniques: Van Nostrand Reinhold Co. New York, NY, USA, 1990. | ||
| Line 424: | Line 427: | ||
: <sup>[18]</sup> D. Willmor and S. M. Embury, "Exploring test adequacy for database systems," in Proceedings of the 3rd UK Software Testing Research Workshop, Sheffield, UK, pp. p123-133, 2005. | : <sup>[18]</sup> D. Willmor and S. M. Embury, "Exploring test adequacy for database systems," in Proceedings of the 3rd UK Software Testing Research Workshop, Sheffield, UK, pp. p123-133, 2005. | ||
: <sup>[19]</sup> H. Zhu, P. A. V. Hall, and J. H. R. May, "Software Unit Test Coverage and Adequacy," ACM Computing Surveys, vol. 29, no. 4, 1997. | : <sup>[19]</sup> H. Zhu, P. A. V. Hall, and J. H. R. May, "Software Unit Test Coverage and Adequacy," ACM Computing Surveys, vol. 29, no. 4, 1997. | ||
== 11. End Notes == | == 11. End Notes == | ||
| Line 436: | Line 438: | ||
# http://works.dgic.co.jp/djunit/ | # http://works.dgic.co.jp/djunit/ | ||
# For our case study, we used MySQL v5.0.45-community-nt found at http://www.mysql.com/ | # For our case study, we used MySQL v5.0.45-community-nt found at http://www.mysql.com/ | ||
[[Category:Workshop Papers]] | |||