Session capabilities - Selenium教程

- [Instructor] So far, we've gotten all our system dependencies set up and installed Appium. Now we can begin to learn how to write Appium code. As we discussed earlier, Appium has a client-server architecture which means every Appium command gets sent over the network as an http request. We want our test to proceed in a logical manner, one step after the other, finding elements and interacting with them. What this means is that our Appium client code needs to attach something to every request to let the Appium server know we are dealing with the same test. In Appium web driver lingo, that little something is called a session ID and the Appium server will associate any commands sent in with that ID as belonging to the same session. Again, the session ID is the thing which is used to group automation commands together and to allow a test to proceed one step at a time. So you can see here that the various commands that need to follow one another in the course of a particular test all share the same session ID. What all of this means is that before we begin our automation, we need to start an Appium session. And when we're done, we need to stop an Appium session. We'll discuss how exactly to do that shortly. For now, let's talk about telling Appium what kind of session we want. We can start many different kinds of Appium sessions. We can start a session on an IOS simulator, for example. Or we could start one on an Nexus S Android device physically plugged into our computer. So to make sure we're automating the right kind of thing for our test, we need to tell Appium what it is we want. We do this a form of session parameters known as capabilities. Capabilities are essentially a set of keys and values that get wrapped up into an object and sent to the Appium server during session initialization. There are many, many capabilities that Appium supports, well over a hundred. Some capabilities are generic and take effect in any platform Appium supports. Other capabilities are platform-specific, or even driver-specific. We'll encounter a few different capabilities throughout the course. However, there's a minimal set of capabilities which is required to start an Appium session on any native mobile app, and those should always be included. These capabilities are platform name, the value here should be a string noting the mobile platform you want to test on. Usually, it's either IOS or Android. And platform version. This is a string denoting the version of that mobile operating system that you want to automate. For example, if you're working with IOS it could be 12.1 or 12.2. Device name. This is a string that lets Appium know what manner of device it should connect to. It could be for example, the iPhone 8 simulator, in which case Appium will look for or start that particular IOS simulator for running the test. Or if you want to simply connect to an already running Android emulator, you could choose a value of Android emulator. And we have the app capability. This last required capability is a path to the prebuilt binary version of the app that you want to test. It should either be an absolute local path, like slash users, slash foo, slash apps, slash apps at apk, or a fully qualified URL to a downloadable zipped version of the app. And of course for Android, the app extension will be apk, and for IOS the app extension will be dot app and it needs to be zipped. Let's take a look at a concrete example of what implementing capabilities will look like in our code. We'll be seeing this very frequently throughout the course, so here's what one instantiation of capabilities might look like. Once we know what keys and values we want for our capabilities, we actually have to encode them in our script so that it can send the capabilities to the server during session initialization. In the Appium java client, this is done via the desired capabilities object. Basically, you instantiate a new one of these objects, and then call the set capability method on it with a particular capability name and value you want to add to the set of capabilities. So in this case, we're setting the platform name, platform version, device name, automation name, and app capabilities with the particular values you see here as the second parameter in each line. Once we've defined our capabilities, we need to actually use them to start an automation session. To start a session, we merely instantiate a class called Appium driver. Well, not directly. There are two important classes that inherit from Appium driver. One is called Android driver, and the other's called IOS driver. Base on which class we use, the java client will make sure that the appropriate platform-specific methods are available to us. So in this example, we're starting an Android session and we therefor use the Android driver class. To start the session, we also need to tell the Appium client where the Appium server is. In our case, we're assuming Appium is running locally, on its default port of 47 23. In this code example, once the instantiation of Android driver is complete, we have ourselves an automation session. Now we can do whatever we want with it. In the future, it will find elements and interact with them. But the safest thing to learn first, is how to quit the session when we're done. To do that, we simply call the quit method on our driver object. It's important to always quit sessions cleanly, because it tells Appium that it can freely reallocate resources for other tests, for example access to a particular device or emulator. So that's it. That's how you tell Appium to start sessions on a particular platform and device, and how to stop the session when you're done with your automation.