Kĩ thuật lập trình - Chapter 13: Construction
Assess whether a set of classes that must work together do so without error
Four common approaches
User interface testing
Use case testing
Interaction testing
System interface testing
Most projects use all four approaches
22 trang |
Chia sẻ: huyhoang44 | Lượt xem: 1045 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Kĩ thuật lập trình - Chapter 13: Construction, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Chapter 13:ConstructionObjectivesBe familiar with the system construction process.Understand different types of tests and when to use them.Understand how to develop documentation.IntroductionConstruction is the development of all parts of the system, documentation, and new operating proceduresProgramming is the largest, but least risky part of systems developmentA program is not considered finished until the test for that program is passed.MANAGING PROGRAMMINGAssigning ProgrammersFirst, group together related classes, then assign each group to a programmerTime required is proportional to number of programmersThe more programmers, the more coordination, which means less time is spent actually codingBest to use a small team of programmersDivide complex projects into autonomous partsCoordinating ActivitiesWeekly project meetingsCreate and enforce standardsDivide resources into three areas: DevelopmentTestingProductionImplement change control measuresManaging the ScheduleTime estimates must be revised as construction proceedsBuild a 10% error margin into all schedulesScope creep occurs when new requirements are added to the project after the system design was finalizedRisk assessments can help predict problems before they derail the projectDESIGNING TESTSTestingThe purpose of testing is to uncover as many errors as feasibleIt is impossible to prove the system error-freeIt is too expensive to look for all possible bugsFour stages of testingUnit testsIntegration testsSystem testsAcceptance testsTesting and Object OrientationEncapsulation and Information-HidingPolymorphism and Dynamic-BindingInheritanceReuseObject-Oriented Development Process and ProductsTest PlanningTesting takes place throughout the development of an object-oriented systemTest plans define a series of tests to be conductedEach test has a specific objective and describes specific test cases to examineStubs are hard-coded placeholders that allow testing using unfinished classesUnit TestsUnit tests focus on a single classBlack box testing examines externally visible behaviors of a classDriven by CRC cards and method contractsTester knows nothing of how the class was codedWhite box testing examines the internals of a classDriven by method specifications for the classRules of Unit TestingWrite the test firstDefine the expected output or result. Don't test your own programs. Test for invalid or unexpected conditions.Use reproducible tests Never write a test that succeeds the first time. The probability of locating more errors in any one module is directly proportional to the number of errors already found in that module. Integration TestsAssess whether a set of classes that must work together do so without errorFour common approachesUser interface testingUse case testingInteraction testingSystem interface testingMost projects use all four approachesFinal TestingSystem Testing determinesHow well the system meets business requirementsUsability, security, & performance under loadAdequacy of documentationAcceptance TestingPrimarily by users with support from project teamGoals is to confirm that the system is complete and is acceptable to the usersDEVELOPING DOCUMENTATIONDeveloping DocumentationDocumentation of the system must be done throughout system developmentTwo fundamentally different typesSystem documentation is for those who install, maintain or build upon the systemUser documentation is for those who use itAssume the users will not read the manuals before starting to use the system!Online documentation is the norm todayTypes of DocumentationReference DocumentsTell users how to perform specific tasksProcedure ManualsDescribe how to perform business tasksEach procedure normally entails multiple tasksTutorialsteach people how to use major components of a systemDesigning Documentation StructureDevelop a set of documentation navigation controls that lead the user to documentation topicsTopics generally come from 3 sourcesCommands and menus in the user interfaceHow to perform certain tasksDefinitions of important termsOnline Help ExampleNavigation buttonsTask titleStep-by-step instructionsWriting Documentation TopicsUse the active voiceUse e-prime styleUse consistent termsUse simple languageUse friendly languageUse parallel grammatical structuresUse steps correctlyUse short paragraphsSummaryManaging ProgrammingDesigning TestsDeveloping Documentation
Các file đính kèm theo tài liệu này:
- ch13_8894.ppt