Hi, Karen >> >> >>> 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. > OK, thanks. I will read the python bridge to see how to dynamically generate the time zone in python. > >>> 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. > Thanks > >> 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? > post-verify script will be run manually after reboot, and there is no plan to automate it. But it will be covered during test cycle by manual. Currently the text suite QE is working on is focus on the Text UI of text-installer only, and the test suite takes advantage of expect script to capture something showing on the screen and verify with expected characters.
Here what I meant is if there is a way to verify the correctness of Time Zone settings except "post-verify" after rebooting. I.E., we don't have to reboot the machine, and the test suite could verify the Time Zone setting on the installed OS. As I know, the installed OS is mounted on /a or /rpool during installation, could we just verify /a/etc/default/init or other Time Zone file to verify if the installer sets Time Zone correctly or not? >>> 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. > I picked them by random frankly, I tried to cover every time zone region, for time zone locations and time zone inside, I selected some of them on different positions on the scroll bar. "Chile" is the 1st item of Pacific Ocean and "Angola" is the 2nd item Africa, and "Egypt" is close to the beginning while "Tanzania" is close to the bottom. "Wallis & Futuna" is the last item of Pacific Ocean on the screen. 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 >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > >
