We have many automation test file *.aii for each screens in our project.
When perform to test function for each screen, we have to run in sequence each *.aii file.
So could you suggest some ways ( or the best way) to manage as well as maintain these files in the silverlight project ?
3 Answers, 1 is accepted
I am sorry I don't really understand what problem you are trying to solve. The .aii files are automatically kept and maintained within your test project. What type of management problem are you trying to solve?
Greetings,Cody
Rank 1
I used to create automation test as:
My screen has functions: Add, Update, Delete
I will create 3 files as AddTest.aii, UpdateTest.aii, DeleteTest.aii
AddTest.aii includes steps as: Login -> Displaylist -> Add->Verify data
UpdateTest.aii includes steps as: Login -> Displaylist -> Update->Verify data
DeleteTest.aii includes steps as: Login -> Displaylist -> Delete->Verify data
Every time I perform to test functions, I will run in sequence 3 times for testing, Is it good to create 3 test file for one screen Or it's better to merge 3 test function in one automation test file and only run once ?
What's your idea ?
Thank you very much for the clarification. Now I believe I understand what you are after.
This is a matter of test case management (which is a little different that test file management). We do recommend modularizing your tests and do a one to one mapping of each test case to one physical test.
From there you can create a "test suite" which is running all of your tests together in a batch. That is what the test lists are for. WebUI Test Studio supports two types of test lists:
1 - A static list of tests. The list of tests to run never changes
2 - A dynamic list of tests. Here WebUI will study the properties of all the tests an only run those that match the properties you have specified.
We also suggest further modularizing your tests into even smaller portions that you can then reuse via test-as-step. For example you could structure it as:
1 - A login test which is used as a subtest via test-as-step
2 - An Add test which assumes you are logged in and does nothing but Add a record
3 - An Update test
4 - A Delete test
5 - A verify data test (possibly multiple versions of this type)
With these smaller test modules you can now more easily maintain your test project (e.g. Login is handled in only one place so that's the only place you need to update when/if needed). Now you create your high level test which mostly calls the subtests via test-as-step feature.
Does that answer your question adequately?
Cody