甲骨文亚太研发中心-其中一软件项目的测试策略

1、Test Strategy For Project L360Version : 19/10/2006Status : DraftAuthor : Tommy GuanChange LogVERSIONREVIEWERSCHANGES19/10/2006Tommy Gua nCreati onTable of Contentsif !supportLists-1. Introduceif !supportLists-2. Scope of testingif !supportLists-3. Testing assumptions and considerationsif !supportLis

2、ts-4. Testi ng Approach Testi ng Main Structure Problem tracking Testi ng Schedule Testi ng Sig n-off Testing process Control5. Opening issues6. Test ing team and con tact in formatio n1. IntroduceLearning 360 is a web-enabled, strategic K-12 information solution which focuses on delivering improved

3、 student outcomes through Intelligent Diagnostics, Early Intervention and Risk Reduction. It builds on the strong foundations of Oracle technologies and applications to deliver a solution designed to put children first, support informed decision making, capitalise on teachers knowledge and connect t

4、he learning community.This document will describe how to test this product by following several main business lines to cover most of functionalities and user objects.2. Scope of testingFunction testingThis test area will cover the functionalities ofL360. It will depend on the Function Specprovided f

5、rom dev.team.Business Line testing.This test area will cover the main business lines often used by customers. Test.team will work with dev.team to figure out three or four main business lines for L360.GUI testingThis area will cover all GUI of L360 to make sure L360 is user-friendly and the behavior

6、 of objects are as normal.3. Test Assumptions and ConsiderationsDev.team provide related documents for L360.Dev.team provide L360 product trainingtesting , such as reviewing test specification. serverAll documents will be put on CDC Online Services4. Testing ApproachThis Section will define how to d

7、o testing in detail.Main StructureWe will merge Function Testing,Business Line Testing and GUI Testing into one test suite.All testing will be around three or four main business lines of L360 to cover most of functionalities and user objects.The following is the teacher ? ? s business line as an exa

8、mple.1.Testing according to the teacher ? ? s business lineModuleActio nExpected result for actionActual result for actionActio n test ing resultModuleTest ingResultI.TeacherLoginModule1.keep the user n ame in putbox empty, click OK butt onGet a warning say ingPleasein put User NameThere is no this

9、warni ngFailedBug123454Function:Failed due to bug123456 and bug1234542.keepthepassword in putbox empty,click OK butt onGet a warning say ing Please in put PasswordGettheexpected warni ngPassed3.set a wrong user n ame,the n clickOKbutt onGet a warning say ingUserName is not correctGettheexpected warn

10、i ngPassedBusin ess:Passed4.set a wrong user password, then click OK butt onGet a warning say ingUserpassword is not correctThere is no this warni ngFailedBug1234565.set a correct user n ame and correct password, the n clickOKbutt onLoginsuccessfullyLoginsuccessfullyPassedGUI:Passed6. ? ? ? ? ?2.Cre

11、ate a new programe? ? ? ? ?Function: ? ?Busin ess: ? ?GUI:? ?3.Update an existi ng program? ? ? ? ? ? ? ? ? ? ? ?We will use Oracle Bug db to trace the problems.Bug TemplatePROBLEM:WORKAROUND TO REPRODUCE:RELATED BUGS:VERSION:Filling a bug Bug should be well formed and should provideas much informat

12、ion as possible. Bug should include the problem description, symptoms, work around, and the versions with which it reproduces. By default, all the bugs get assigned to ? ofdev.team. He will evaluate and assign the bugs periodically.Trace a bugOnce the bug status changed by dev.team,please notice the

13、 filer to double check and change the status accordingly.Once the bug status changed by test.team,please assign the bug back to dev.team.All bugs should be closed as 91(fixed) or92(not a bug) at the end after verified by test.team. Dev.team should not close any bug.ScheduleTest Strategy Development:

14、 23/10 - 27/10 (5 days- dependant on the appointment of a Test Manager - the earlier the better)R1/R2 System Overview with CDC Test Team:30/10 - 1/11(3 days - dependant on the appointment of a Test team - the earlier the better)Figure out the main business line with dev.team30/10-1/11. Please refer

15、to the above item about business line testing.Dev.team review and approve the test spec (6/11? C 8/11).dev.team? ? s review, then the test spec finalized.(9/11 ? C 1day)TestScript Prepare based on the test spec:(9/11-11/12) (22 days - Test plans will initially need to be created using Version R1 and

16、 the Desig n Docume nts un til R2 is ready to be in stalled). We will use QTP as our automati on tool. Per Apps teams in Oracle who has bee n work ing on Apps test ing for years. With their experienee, Apps testing has their own features and not feasible to be automated. But we can try to automate s

17、ome simple test cases.CDC R2 Migratio n/In stall: 12/11 - 17/11 (5 days -To be comme need at the earliest possible opport unity to allow accurate test pla ns (in clud ing content) to be prepared utiliz ing the R2 system)Functional Test Iteration 1: (12/12-25/12)(10 days-All prepared Test Scripts/Pla

18、 ns will be executed and bugs recorded and fixes retested). During this Iteration, we will report issues to dev.team by Bugdb. And after this Iteration, we will summarize the issues and report to dev.team. Functional TestIterati on2:(26/12? C10/01/07)(10 days - All prepared Test Scripts/Plans will b

19、e executed and bugs recorded and fixes retested). We should get an updated vers ion from dev.team after Iteration1. This Iteration will focus on the fix.Test ing Sig n-offTest.team n eed to provide a detailed testi ng result summary. Please refer toTest ing Result Summary template for detail.Testing

20、 Process ControlPeriodWho joinMilesto neTest strategyTest.team,Dev.team,PMThe test strategy finished by test.team get approved and fin alized.Test SpecTest.team,Dev.teamThe test Spec finished by test.team get approved from dev.team and fin alized.Test Script PrepareTest.teamAutomate the test cases t

21、hat are feasible to be automated, and the finished scripts can run smoothly.Functional Test Iteration1Test.team,Dev.teamRun all the scripts and test plan according to approvedtest spec. All issues are recorded in bug db and no tice dev.team.Funtional Test Iteration2Test.team,Dev.teamAll critical bugs should be