Hi Jason, Please see my comments inline.
Jason Zhao wrote: > Hi, Karen, > > Thank you very much for your quick reply. Please see comments in line. > >> Hi Jason, >> >> In terms of testing timezone related stuff in the text installer, I think >> we need 3 kind of tests. >> >> 1) The list of timezones displayed by the text installer GUI is >> generated dynamically >> by calling functions in the libzoneinfo.so library, and the results are >> displayed. >> I believe there should be some sort of validation to make sure that the >> text installer >> is displaying everything that's found correctly. >> >> > Yes, it is the point. It requires test programs are able to generate the > timezones information dynamically by calling libzoneinfo.so library. In > order to do it, I assume we need to know how the text-installer calls > the libzoneinfo.so library and the test program will simulate the invoke > and generate the same map dynamically. Currently, the tests are written > in expect and shell which is obviously could not do the invoke of > libzoneinfo.so, C or other programs are need to be developed. > The text installer project developed a python bridge that calls functions in the C library, and displays the results in the text installer. >> 2) We need to ensure that the user's selection of timezone gets correctly >> displayed in the summary screen. >> >> > Our time zone test case will cover user selection of time zone and > verify it whether correctly or not on summary screen. > >> 3) We need to ensure that the user's selection of timezone actually gets set >> in the installed system. >> >> > It could be verified after whole installation and reboot, after reboot, > we have post-verify script to verify some configuration items including TZ. > But if it is possible to verify before the whole installation complete > it will be convenient, but it requires internal knowledge how the > installer configure the installed OS on micro-root. How could the test > verify the TZ configuration in micro-root? And when is appropriate time > to verify it, e.g., after packages transferring, after libti however > before packages transferring or after post-install script. > It should be sufficient to verify that the user chosen timezone is correctly set after reboot. > Currently, could we just verify "/etc/init" to get the default time zone > setting? If it so, another new test case may require to be added for > this test purpose. Otherwise, post-verify script could cover the > verification, though it require manually run the script after installation. > You mean, this post-verify script will have to be run manually after the system is rebooted? Is there a plan to automate it? >> I think your question below only address for item 2 above. What's your plan >> for the 2 other type of tests? >> >> The list of timezones is generated from the system dynamically. However, >> your >> list below is a static list. If the value from the system changes, your list >> will have to be updated manually? To do test #2 above better, perhaps >> we should define the exact algorithm used to map what gets selected by >> the user to what gets displayed in the Summary screen. Then, the test >> program >> can compute the result, and verify the summary screen displays the user's >> selection correctly. >> >> > The point of the list is to avoid covering all the items in time > zone(regions/locations/time zone), because the total combination could > is about thousands, and it is time consuming to test all the combination > and verify them one by one during one test cycle, so we need to pick up > limited combinations for testing. Here I need to make sure the limited > test combination could cover most of the functionality. That is why we > need a limited list. > > And you are right, the supported time zone list is a static list > currently, but since the list is limited and it has dedicated > Regions/Locations/Time zone, it is static. If the system changes, the > list have to be updated manually, as you said. > I understand that it would be too time consuming to test all possible combinations. Can you explain why you picked those 50 combinations? I think it would help to evaluate whether the timezones you picked is enough. Thanks, --Karen > Thanks > Jason > >> Jason Zhao wrote: >> >> >>> Hi, Sue, Keith and Karen, >>> >>> Per last meeting yesterday, I will write a test-supported time zone list >>> to you. Please review it in attachment. >>> The reason of the list is because there are thousands of selection pairs >>> and it will time-consuming for testing to iterate all the items and >>> verify one by one. >>> >>> Currently, there are totally 50 pairs on this list, please review it to >>> see if it is enough. >>> >>> Africa: 5; >>> Americas: 12; >>> Antarctica Ocean: 1; >>> Arctic Ocean: 1; >>> Asia:9; >>> Atlantic Ocean: 2; >>> Australia: 2; >>> Europe: 12; >>> Indian Ocean: 1; >>> Pacific Ocean: 5 >>> >>> >>> Request: >>> On this list, since I don't know what the expected result for each >>> selection pair(Region/Location/Time zone) so I mark them with "?". During >>> test, we will verify the result one by one on "Installation Summary" >>> screen. Since summary page is not finished, yet and we don't know what the >>> expected result will be, would you please tell what are the exact results >>> or how to get the results. Thanks! >>> >>> Question: >>> Currently, on the "Time Zone" screen after selection of "Pacific >>> Ocean/United States", there are a lot of items inside, including "Eastern >>> Time", "Central Time".... Do you think it is correct? I mean on "Pacific >>> Ocean" region, the "United States" location should only contain several >>> time zone, not the whole list of time zone of "United States". E.G., the >>> "Eastern Time" should be at the other side of "Pacific Ocean" across >>> American continent, and it will be inappropriate to be here. >>> >>> >>> Thanks >>> Jason >>> >>> >>> >> >> > >
