分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请轻击人工智能教程大家好！欢迎来到我的网站！ 人工智能被认为是一种拯救世界、终结世界的技术。毋庸置疑，人工智能时代就要来临了，科… 继续阅读 前言https://www.captainai.net/troubleshooter

1. Use page objects pattern, and consider use Selenium PageFactory. (Page object methods should return a value.)
2. Preferred selector order : id > name > links text > css > xpath.
3. Get name of the running test.
4. Be fluent.
5. Be robust and portable.
6. Avoid Thread.sleep prefer Wait or FluentWait.
7. Use relative URLs.
8. Create your dataset.
9. Fresh browser per test.
10. Keep your test scripts separate from the framework, though it is in the same codebase.
11. In page objects and other framework classes, if there is some issue to log/write, output it as a state other than a failure (e.g. "[WARN] Login link was not found." or "[INFO] Homepage initialization complete."). Only use assertions and report [FAIL] in the actual test code/script.
12. From the start, build your framework read a configuration file for things like the target server url to test, database to get data from, logging levels, etc. You may want to also start with the ability to pass the config file name as a parameter when launching your tests. And place your configuration in .properties.
13. Use TestNG. JUnit works fine, but use TestNG. Then learn about grouping tests and using datasources. They will give you incredible flexibility.
14. Keep driver use (FireFoxDriver, ChromeDriver, etc) inside the page objects. Don't let them appear in your test scripts.
15. Use @BeforeClass and @AfterClass (or their variants) to setup and teardown drivers and connections to outside resources (a driver is an outside resource).
16. Reporting.
    This is a very crucial piece which many ignore while creating the framework. The report that you present is what other teams would see. It should be simple, concise and easy to access.
    Another point about reporting is sending email alerts to the team whenever a test fails. No one wants to/can keep an eye on a test suite all the time. If something fails, framework should alert the users. It should also be noted that too much of alerts will cause the teams to ignore it. So alert the teams only on failures and not at the end of every execution.
17. Write a test case script as small as possible.
18. Write test cases as independent with each other. Write each test as its own unit. Write the tests in a way that won't be reliant on other tests to complete.
19. Store locators separately. (Do not include locators in test script flow.)
20. Write a different method for each common/unique/specific action. (Even though it has one line to execute no problem but, it should be a separate method.)
21. Reuse the code (methods). Do not duplicate code anywhere. (I mean don't copy paste any lines from one file to another. Instead of the create a methods with those lines and call that method in both files.)
22. Have separate library called utility with Reporting, necessary credentials, browser configurations, etc.
23. Have common naming structure. Such as method name, class name, variable names.
24. Creating methods to pre-load data for testing should not be done using Selenium, existing APIs should be leveraged to create data for the AUT.