CS2103 - Lecture 9
CS2103 - Lecture 9 CS2103
Popular in Software Engineering
Popular in Quantitative Methods
This 3 page Class Notes was uploaded by Jerry Tan on Friday October 23, 2015. The Class Notes belongs to CS2103 at National University of Singapore taught by Damith C. Rajapakse in Summer 2015. Since its upload, it has received 27 views. For similar materials see Software Engineering in Quantitative Methods at National University of Singapore.
Reviews for CS2103 - Lecture 9
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 10/23/15
National University of Singapore NUS CS2103 Software Engineering AY2015 SEM 1 Lecture 9 Product Quality Friday 16th October 2015 By Jerry Tan Si Kai CS2103 Software Engineering Lecture 9 Product functional what about quality Two types of quality assurance QA Validation fail buggy requirements Are we building the correct product Verification fail buggy programs Are we building the product correctly Hence 2 types of testing 1 Acceptance testing done by the User to determine Validation Done on a deployment environment VERY IMPORTANT a Test against REQUIREMENT SPECIFICATIONS b Business analysts talk to the users 2 System testing done by the internal testing department to determine Verification Done in a test bed a SYSTEM SPECIFICATION b Built by engineers GUI testing tend to be hard how do you make it easy 1 Minimize logic in GUI leave 95 in logic and test LOGIC first 2 Manual or automate testing of the other 5 in the GUI How much testing is enough Using a coverage tool install a plugin to Eclipse leave it active while testing At the end they will highlight the code 1 red Code was not executed at all 2 yellow partial execution of code 3 green code was executed Types of coverage 1 Statement coverage all statements in a code block are executed 2 Path coverage all different paths in the conditional logic execution of the code Achieving 100 path coverage is much harder but better than statement coverage BUT too many test cases how to prioritize a Only one invalid input per test case b All valid inputs should appear at least once in all inputs c How to ensure 100 path coverage by drawing code graphs not covered in this module Other QA techniques 1 Code reviews get others to look at your code Live or remote through GIT 2 Static analysis using tools in Eclipse to help you Analyze the code without running it a Using the CodeProAnalyticsTool in TEAMMATES 3 Formal methods a Mathematical prove of the algorithm in the code b Logical analysis of the code c Graph analysis 4 Testing as a career Easier to get in easier to get ahead Blame others not get blamed Still can code Testsavvy coders are good coders Heuristics of good test cases 1 Methods a Scripted testing predetermined b Exploratory testing onthe y comes with experience 2 How much info revealed a Black box model don t care about what is inside the Unit under test b White box model care about what is inside the Unit Under Test eg implementation efficiency c Gray Box Most of the time we don t care but sometimes under certain conditions we care 3 How to choose a Why choose Testing is costly b Heuristics of test writing i ii iii Equivalence partitioning An algorithm should treat a range of inputs in the same way and another range of inputs another way To take advantage of this partition the input space and output space and write the test cases to cover the partitions Which cases should be tested Boundary value analysis are most likely to have errors because they show up in the code Not possible in some cases eg testing a function that checks for prime numbers infinitely many boundary values Combining multiple inputs based on all the possible inputs to a method test through all the permutations and combinations of those inputs But c Effectiveness amp Efficiency 1 ii iii Who is more effective The guy who found more bugs Who is more efficient The guy who wrote lesser test cases Write a test case only if it can catch a bug that other test cases cannot catch