” COM3529编程 辅导、 写作Java程序设计COM3529 SOFTWARE TESTING ANALYSISAssignment, Spring 2021Automated Tool Support for Logic Coverage of Java Code1 OverviewThe aim of this assignment is to develop automated tool support for logic testing of Java methods.The aim of this tool, or framework, is to minimise the amount of effort required by a human testerwhen faced with the task of manually writing a test suite for some arbitrary Java method that theymight be given. The more automated support your tool/framework can provide, the higher the markyou will get.A very basic submission that is worthy of a pass mark, for example, might involve implementingRandom Testing for Condition Coverage (i.e., a very basic coverage criterion), along with a schemefor manually instrumenting conditions. (This would be a simple extension of what we did in theWeek 5 lecture for randomly Generating test cases for Branch Coverage of the classify method ofthe Triangle class.)A more advanced submission might seek to provide automated tool support for a more advancedcoverage criterion like MCDC. It might automatically parse Java methods to obtain branch predicatesand figure out what the test requirements are that are needed by such a criterion. It might automaticallyinstrument the Java code, as opposed to relying on a tester manually having to insert loggingstatements. It might apply a more advanced test generation method, for example Search-BasedTesting. A more advanced submission might even automatically write out the Java code statementsneeded to produce a JUnit test suite.Section 4 goes into further detail about the requirements behind this assignment, and the differentaspects that you are expected to tackle.Before we go into further detail, there are two key things you should know about this assignment: You can use third-party Java libraries as part of your assignment. For example, I wouldntexpect you to write a full-featured parser for Java, if you need one. (Alternatively, you may wantto write a very basic parser yourself, that provides simple and limited support, it is up to you.) Ifyou can source a package to do certain key tasks (that might normally take months to programyourself), then you can use it. (This is a Software Engineering module, after all.)However, you must include any Java packages or tools as is (i.e., without modifying them) for example as a .jar file and declare it as a dependency of your tool. (This is quite easyto achieve in Maven, which we have been using throughout the course.) That is, you must notcopy anybodys code and use it as part of your own tool, as though you had written it yourself.This would amount to plagiarism, of course. You can work as an individual or in teams of up to four people. Marks will be awardedon the basis of what you have achieved in proportion to the number of people in your team.The advantage of working in a team is That you will be able to tackle more aspects of theproject, while also being free to discuss the different aspects of the problem it entails and giveeachother help, without fear of falling foul of academic rules regarding assignment collusion.Unless you specify otherwise (e.g., because of a large discrepancy in the distribution of thework among team members), the overall mark you achieve for the assignment will be awardedto each member of the group.12 Submission of Your WorkYour submission should take the form of a GitHub repository. Your repository should contain all theJava code needed to run and operate your tool, along with example Java methods on which your toolwith run, and for which it successfully works with. (Note there is no choice of language here, thisassignment must be completed in Java.)Your GitHub repository should contain a README.md file in the root directory, written in MarkDown.The README.md should contain: Details of your team, listing each person involved, their Sheffield email address, and the workthey contributed to the project. A section overviewing the support your tool provides and what automation it delivers. Thissection should further include a detailed list of all of your tools different features and how theywould assist a human tester perform logic testing in practice. A section detailing how to install and run your tool (or how to run the different parts of your tool,if different stages are required). This section should include a list of libraries or utilities yourtool is dependent on, and how to get hold of them. (A simple way to handle this requirementis to limit yourself to packages that can be automatically obtained via Maven ( httpss://maven.apache.org/) or Gradle ( httpss://gradle.org/) and use one of those build automation tools. One or more worked examples that demonstrate how to use your tool in practice.The deadline for this assignment is Monday, 26 April 2020, 5pm (Week 9).By this date, you should have emailed me, Phil McMinn (p.mcminn@sheffield.ac.uk), with the URLof your repository.You must not make any further changes to your repository after this date. If you do, your work willbe subject to standard Department of Computer Science lateness penalties, i.e. 5% per working dayfollowing the submission date, up to a maximum of five days after which you will score zero.3 Help and QuestionsThe lab session in Week 5 will be devoted any immediate questions about the assignment.You may ask further questions about the assignment via the module discussion board, where amember of the teaching team Will respond to your query.4 Detailed RequirementsThere are many aspects to writing an automated test case generation tool/framework. Your submissionwill consider each of the following aspects, but may not need to address them completely. Inother words, your submission may only provide limited automation for some aspect, requiring a humantester to do the rest of the work. The more automation you can provide out of the box, however,the higher the mark you will achieve.In this section, we will consider the calculate method of the BMICalculator class, provided inthe uk.ac.shef.com3529.practicals package of the online code repository supporting this module(available at httpss://github.com/philmcminn/com3529-code) and listed here:21 package uk.ac.shef.com3529.practicals;23 public class BMICalculator {45 public enum Type {6 UNDERWEIGHT,7 NORMAL,8 OVERWEIGHT,9 OBESE;10 }1112 public static Type calculate(double weightInPounds, int heightFeet, int heightInches) {13 double weightInKilos = weightInPounds * 0.453592;14 double heightInMeters = ((heightFeet * 12) + heightInches) * .0254;15 double bmi = WeightInKilos / Math.pow(heightInMeters, 2.0);1617 if (bmi 18.5) {18 return Type.UNDERWEIGHT;19 } else if (bmi = 17.5 bmi 25) {20 return Type.NORMAL;21 } else if (bmi = 25 bmi 30) {22 return Type.OVERWEIGHT;23 } else {24 return Type.OBESE;25 }26 }27 }4.1 Analysis of the Method Under TestTo start at the beginning, your tool needs to know what conditions are present in the method undertest and their form. For example, the calculate method has branch predicates on lines 17, 19, and21. The predicate on line 17 only has one condition, while the predicates on lines 19 and 21 bothconsist of two conditions composed by the logical operators. Furthermore, the branch predicateon line 19 wont be encountered unless the branch predicate on line 17 evaluates to false, while thebranch predicate on line 21 would be encountered unless both predicates on lines 17 and 19 evaluateto false.At a basic level, the tool could simple expect this information to be inputted manually by the tester.This could be provided via some additional file, or the tester could use your framework as an API (i.e.,a package of useful Java methods for supporting automated testing), writing the required informationas Java code in the form of parameters to methods provided by your framework. Of course, thiswouldnt be providing much automated support at all, since the burden of work is on the human. Butit provides a basis by which to start your framework will need some data structures in which tostore all of this information.Later on, you May choose to provide further automation in this area, for example by parsing theJava method. You could write your own simple parser that is capable of detecting if, while, and forstatements, and dissecting the conditions within them. Or, you may wish to enlist the support of afull-blown parsing tool, such as the JavaParser library ( httpss://javaparser.org/).4.2 Generating Test RequirementsOnce youve figured out the conditions in the method under test, you can figure out the test requirementsneeded by various logic coverage criteria. This is easy for a basic criterion like ConditionCoverage, but more technical for a coverage criterion like MCDC (in restricted or correlated form).For the branch predicate on line 17, there is only one condition, so this is trivial. All logic coveragecriteria for this predicate are the same as Branch Coverage two test requirements, where thepredicate/condition evaluates to true in one requirement, and false in the other.3Things get more complicated for the branch predicates on lines 19 and 21, however, which arecomposed of two conditions. Generating the test requirements for Condition Coverage involves testrequirements that executing each individual condition as true and false. MCDC is more complicated,and you will need to consider whether you will support either the restricted or correlated variant (orboth). Of course, you can support multiple coverage criteria for further marks!4.3 InstrumentationOne challenge your tool needs to solve is how to know which conditions have been covered, i.e.whether they were executed or not, and if they were, whether they evaluated to true or false.At the very least, you will need to provide a scheme so that a tester can insert logging statementsthemselves that are needed by the tool in order to run.We did this for the classify method of the Triangle class in the Week 5 lecture, for example. Forconsidering individual conditions, you might want to do something cleverer. For example, instrumentationof line 21 of the calculate method of the BMICalculator class could take the form:… if (logCondition(3, bmi = 17.5) logCondition(4, bmi 25) { …where logCondition is a method provided by your framework that logs the ID number of the conditionas the first parameter, takes the condition as the second parameter, and returns the boolean resultof the evaluation of the condition so that the program preserves its normal functionality.public void logCondition(int id, Boolean condition) {boolean result = condition;// … log the id somewhere, along with the result,// thereby storing whether the condition was executed// as true or false, for computing coverage later on…return result;}If youre planning on incorporating a Search-Based method into your tool (see below), the instrumentationwill likely need to log the values of variables so that your tool can also compute fitness. Forexample:public void logGreaterThanOrEqualsCondition(int id, double leftOperand, double rightOperand) {double fitness = leftOperand – rightOperand;boolean result = false;if (fitness = 0) {result = true;} else {fitness += K;}// … log the id somewhere, along with the result,// thereby storing whether the condition was executed// as true or false, for computing coverage later on…// … also log fitness …return result;}Or, you may wish to have the tool insert those instrumentation statements itself. This could beachieved in conjunction with the Java Parser, mentioned earlier.4.4 Test Data GenerationYour tool needs to provide some level of Test data generation support. This could be random, as perthe example in the Week 5 lecture. However, you may wish to provide a more advanced mecha-4nism, using Search-Based techniques. You could use the Alternating Variable Method (e.g., via thepublicly available open-source AVMf httpss://avmframework.org), or by incorporating a simpleEvolutionary Algorithm of your own.(Hint: The AVMf provides an example of test data generation that you could study to see what ideasyou could borrow for this assignment.)4.5 Computing CoverageFor a given test case, and given the logging information provided by your instrumentation, you needto be able to figure out which test requirements were covered by the test case and its coverage level.This would contribute to the coverage level for a series of test cases that together maximise coverage,provided as an automatically generated test suite for a tester to use.4.6 Outputting Test CasesYour tool needs to output the test cases it generates in some form or other. This could take the formof a very basic series of System.out.println statements that write information to the console. Toprovide comprehensive tool support though, a tester would want a JUnit test suite. This may onlybe partial containing calls to the method under test with test data only, requiring the human testerto fill in the assertions. Or, it could have a go at providing those assertions as well by observingthe outputs of the method given the inputs. For example, suppose the values 182, 6, and 0 weregenerated for the calculate method:assertTrue(BMICalculator.calculate(182, 6, 0) == Type.NORMAL);For methods that return integers or doubles, you could use assertEquals instead.4.7 ExamplesYou need to devise some examples on which to try your test tool/framework, and present them asevidence of what your tool does as part of your submission. You can use the BMICalculator as oneof these examples.4.8 DocumentationFinally, you should document what your tool does, and how to use it via a README.md file provided inthe root directory of your GitHub repository. See Section 2 for more details on what to do here.5 Indicative Marking SchemeYour submission will be graded according to the following criteria.A grade will be awarded to each criterion. The grades assigned over all criteria will then be aggregateddepending on the number of people in your team. For example, an individual working on theirown would not be expected to hit as many high levels of achievement as a group of four to obtain thesame overall final grade.5Criterion (Automation Aspect) Level of Achievement Indicative Grade1. Analysis of the Method Under Test PassRequires significant manual input 3rd2:2Requires some manual input, partial automated support 2:1Method under test fully parsed, with conditions and structure of predicatesextracted and analysed1st2. Test Requirement Generation PassSimple coverage criterion implemented (e.g., Condition Coverage) 3rd2:2Advanced coverage criterion implemented (e.g., Restricted or CorrelatedMCDC)2:1Multiple criteria implemented 1st3. Instrumentation PassSupplies a simple API that is applied within code blocks 3rd2:2Supplies an advanced API that is applied within conditions 2:1Method under test is Automatically parsed and intrumented 1st4. Test Data Generation Very basic random number generation PassConfigurable random number generation (e.g., input parameters canbe configured with upper and lower bounds)3rdAdvanced random number generation (e.g., can be used to generatenon-numerical inputs randomly, such as strings and other types, likeobjects)2:2Advanced random number generation (e.g., can use example inputsas the basis of seeds, similar to fuzzing), or, applies a search-basedtechnique out of the box (e.g., the AVMf)2:1Applies own search-based method (e.g., implemented own evolutionaryalgorithm) or similarly advanced technique1st5. Coverage Level Computation Passand Reporting 3rdCoverage level computed for simple criterion as implemented for (2)above2:22:1Coverage level computed and individual Uncovered elements reported1st6. Test Suite Output Pass3rdSimple output of inputs to the command line 2:22:1Writes out JUnit Java code that can be compiled separately and run 1st7. GitHub Repo and README.md Pass3rdProblems with repo (e.g., files missing) and/or instructions deficient 2:2Everything works and can be setup from the repo, according to instructionssupplied in the README.md2:1README.md especially well-polished, installation and running toolworked flawlessly1st如有需要，请加QQ：99515681 或WX：codehelp
“
添加老师微信回复‘’官网 辅导‘’获取专业老师帮助，或点击联系老师1对1在线指导。
