A Tale of a Deceptive End-to-End Test Automation Engineer
一个欺骗性端到端测试自动化工程师的故事

There is no shame in lacking the ability to perform user end-to-end test automation, but deceitfulness is certainly unacceptable.
缺乏执行用户端到端自动化测试的能力并不可耻，但欺骗肯定是不可接受的。

As a software engineer and test automation engineer, I believe it is essential to emphasize the term “engineer” in our job titles. Engineering, according to widely accepted norms, involves a systematic and reliable approach that aims to create durable and lasting solutions. For instance, if a visually appealing bridge were to collapse merely three days after its inauguration, the “civil engineer” responsible for its design would not only lose their professional qualifications but could also potentially face legal consequences, such as imprisonment. However, the software industry often exhibits a more lenient attitude towards such matters. Therefore, there is a high percentage of fake automated testers.
作为一名软件工程师和测试自动化工程师，我认为有必要在我们的职称中强调 "工程师 "一词。根据广为接受的规范，工程涉及一种系统可靠的方法，旨在创造持久和长期的解决方案。例如，如果一座美轮美奂的大桥在落成三天后就倒塌了，那么负责设计这座大桥的 "土木工程师 "不仅会失去职业资格，还有可能面临监禁等法律后果。然而，软件行业对此类问题往往采取较为宽容的态度。因此，假冒自动测试人员的比例很高。

Long-time readers have witnessed me citing world-renowned agile and testing experts multiple times, these experts have conveyed the same message: implementing genuine and valuable end-to-end test automation via the user interface (UI) is an exceptionally challenging endeavour. Few succeeded.
长期读者曾多次目睹我引用世界知名的敏捷和测试专家的观点，这些专家都传达了同样的信息：通过用户界面（UI）实现真正有价值的端到端测试自动化是一项极具挑战性的工作。成功者寥寥无几。

“In my experience, great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. … They are gold”. - Patrick Copeland, Google Senior Engineering Director, in an interview (2010)

"根据我的经验，优秀的开发人员并不一定能成为优秀的测试人员，但优秀的测试人员（同时具备很强的设计能力）却能成为优秀的开发人员。这是一种心态和激情。......他们是金子"--Patrick Copeland，谷歌高级工程总监，在一次采访中（2010 年）

“95% of the time, 95% of test engineers will write bad GUI automation just because it’s a very difficult thing to do correctly”. - this interview from Microsoft Test Guru Alan Page (2015), author of “How we test software at Microsoft”

"95%的时间里，95%的测试工程师都会编写糟糕的图形用户界面自动化，因为这是一件很难正确完成的事情"--《我们如何在微软测试软件》一书的作者、微软测试大师艾伦-佩奇（Alan Page）（2015 年）接受采访时说。

“Automated testing through the GUI is intuitive, seductive, and almost always wrong!” - Robert C. Martin, co-author of the Agile Manifesto, on his blog (in 2009)

"通过图形用户界面进行自动测试是直观的、诱人的，而且几乎总是错的！"- 罗伯特-C-马丁，《敏捷宣言》的作者之一，在他的博客上（2009 年）

Sadly, many software professionals, due to their limitations, did NOT have this realization. Quite a number of people thought: “Test Automation is just record-n-playback, easy”. How wrong is that?
遗憾的是，许多软件专业人员由于自身的局限性，并没有意识到这一点。不少人认为"测试自动化就是记录-回放，很简单"。这种想法错得有多离谱？

“Testing is harder than developing. If you want to have good testing you need to put your best people in testing.” - Gerald Weinberg, software legend, in a podcast (2018) (current generation of programmers might not heard of Gerald Weinberg, check out the a tweet by DHH on 2023–12–27: “Nobody taught me more about how to do that than the late, great Gerald M. Weinberg.”)

"测试比开发更难。如果你想有好的测试，就必须让最好的人去做测试。"--软件界传奇人物杰拉尔德-温伯格（Gerald Weinberg），在一次播客中（2018 年）（这一代的程序员可能没听说过杰拉尔德-温伯格，请查看 DHH 在 2023-12-27 发布的一条推文："没有人比已故的、伟大的杰拉尔德-温伯格（Gerald M. Weinberg）更能教我如何去做了。"

BTW, I have been achieving E2E (via UI) test automation success (enabled real DevOps, such as Daily Production Releases) for over 15 years. As an engineer, I say things with proof, here it is, Showcase a 500+ End-to-End (via UI) Test Suite: E2E Test Automation is Surely Feasible for Large/Complex Apps.
顺便说一下，我已经成功实现 E2E（通过用户界面）测试自动化（支持真正的 DevOps，如每日生产发布）超过 15 年。作为一名工程师，我说过的话都是有凭有据的，这里就是，展示 500 多个端到端（通过用户界面）测试套件：对于大型/复杂应用程序来说，E2E 测试自动化肯定是可行的。

In this article, I will present a tale story, illustrating a typical fake automated tester when exposed.
在本文中，我将讲述一个故事，说明一个典型的假冒自动测试器暴露后的情况。

Table of Contents: · 95+% E2E Test Automation Engineers I met were Fake · A Tale: Test Automation Engineers Should Take Responsibility for Their Work · Why people like Toby is common?
目录： - 我遇到的 95% 以上的 E2E 测试自动化工程师都是假的 - 一个故事：测试自动化工程师应该对自己的工作负责 - 为什么像托比这样的人很常见？

95+% E2E Test Automation Engineers I met were Fake
我遇到的 95% 以上的 E2E 测试自动化工程师都是假的

Don’t get offended if you are currently doing end-to-end test automation. I haven't met you, so you might well be in that 5% (or 0.25% in Alan Page’s judgement. Compared to Alan’s, my figure is quite conservative).
如果您目前正在进行端到端测试自动化，请不要生气。我还没见过你，所以你很可能就在那 5%（或者按照 Alan Page 的判断是 0.25%。与艾伦相比，我的数字相当保守）。

Here is a story told by Michael Feathers (renowned agile expert and the author of ‘Working Effectively with Legacy Code’) in 2009:
这是迈克尔-费瑟斯（著名敏捷专家，《有效处理遗留代码》一书的作者）在 2009 年讲述的一个故事：

It happens over and over again. I visit a team and I ask about their testing situation. We talk about unit tests, exploratory testing, the works. Then, I ask about automated end-to-end testing and they point at a machine in the corner. That poor machine has an installation of some highly-priced per seat testing tool (or an open source one, it doesn’t matter), and the chair in front of it is empty. We walk over, sweep the dust away from the keyboard, and load up the tool. Then, we glance through their set of test scripts and try to run them. The system falls over a couple of times and then they give me that sheepish grin and say “we tried.” I say, “don’t worry, everyone does.”

这种情况一再发生。我访问一个团队，询问他们的测试情况。我们谈论单元测试、探索性测试，等等。然后，我问到自动化端到端测试，他们指了指角落里的一台机器。那台可怜的机器上安装了某种按座位计价的高价测试工具（或开源工具，无所谓），而它前面的椅子是空的。我们走过去，扫去键盘上的灰尘，装上工具。然后，我们浏览他们的测试脚本集，并尝试运行它们。系统崩溃了几次，然后他们腼腆地笑着对我说 "我们试过了"。我说，"别担心，大家都试过了"。

I also have seen the above (the difference is that I did not ask, instead, checking the test execution reports) many times, and the situation hasn’t changed.
上述情况我也见过很多次（不同的是我没有问，而是查看测试执行报告），情况没有任何变化。

Now a question, do you agree that “the team (in Michael’s story) is doing fake test automation”? Of course, it is. If they (team members) were honest, they would just say “We tried and failed” first, not pointing out the ‘test machine’ and trying to run the tests (and failed a couple of times, betting on luck?). Only then, acknowledged they did not have the capability.
现在有一个问题，你是否同意"（迈克尔故事中的）团队在做虚假的自动化测试"？当然是。如果他们（团队成员）是诚实的，他们就会先说 "我们尝试过，但失败了"，而不是指出 "测试机器 "并尝试运行测试（失败了几次，赌运气？）然后才承认他们没有能力。

Why? Because the team feel embarrassed to acknowledge they couldn’t do end-to-end test automation, they lied.
为什么？因为团队不好意思承认他们无法实现端到端测试自动化，他们撒谎了。

In my opinion, not being to do real test automation is nothing to feel shameful (see reasons below), but lying is.
在我看来，不做真正的自动化测试没什么可耻的（原因见下文），但撒谎却很可耻。

A Tale: Test Automation Engineers Should Take Responsibility for Their Work
一个故事：测试自动化工程师应为自己的工作负责

By principle, everyone would agree with the above statement. However, in test automation, this is usually not the case. Let me elaborate with a hypothetical (but typical and reasonable) story.
原则上，每个人都会同意上述说法。然而，在测试自动化中，情况通常并非如此。让我用一个假设的（但典型合理的）故事来详细说明。

Toby, a senior test automation engineer (contractor), has worked on the projects for 5 months. During the stand-ups, he reported done testing for a number of user stories, and Jira shows that too.
Toby 是一名高级测试自动化工程师（承包商），已经为项目工作了 5 个月。在站立期间，他报告说已经完成了许多用户故事的测试，Jira 也显示了这一点。

Russ, a new project manager, joined the team (staff change). Russ came to Toby, “Hi Toby, the CIO has been trying to do ‘release early, release often’, as you know, end-to-end test automation plays an important role, in regression testing”.
新项目经理 Russ 加入了团队（人员变动）。Russ 找到 Toby 说："Toby，首席信息官一直在努力做到'早发布、勤发布'，正如你所知道的，端到端测试自动化在回归测试中发挥着重要作用。

Toby nodded, “Surely it is”.
托比点点头，"当然是这样"。

Russ said, “Good, we have the same understanding. Now, I am planning to do full regression testing. Then we may get an idea of how often we can do a release. Of course, we have to take into consideration a few rounds of regression testing, to retest bug fixes.”
Russ 说："很好，我们的理解是一致的。现在，我打算进行全面的回归测试。这样我们就能知道多久能发布一次产品。当然，我们必须考虑到几轮回归测试，以重新测试错误修复。

Russ continued, “You are the only test automation engineer in the team. Can you get a list of user stories that your test automation suite cover? I will tell the manual testers not to test those, as it is covered by your test automation. OK, just simply send me a recent test report”.
Russ 继续说："你是团队中唯一的测试自动化工程师。你能拿到你的自动化测试套件所涵盖的用户故事列表吗？我会告诉人工测试人员不要测试这些，因为你的自动化测试已经覆盖了这些内容。好的，只需给我发一份最近的测试报告即可"。

Toby replied, not confidently, “OK”.
托比不自信地回答："好吧"。

After Russ left, Toby rushed to open the test execution in the so-called CI/CD pipeline. Under UI test automation, the most recent run was 3 months ago, and over 50% of test execution failed.
Russ 离开后，Toby 急忙打开了所谓的 CI/CD 管道中的测试执行。在 UI 测试自动化下，最近一次运行是在 3 个月前，超过 50% 的测试执行失败。

The next day, Toby came to Russ’ desk and said “The automated tests ran fine at the time of creation. Because the app and test data changed, a number of automated tests failed. I might need a few weeks to rectify them”.
第二天，托比来到拉斯的办公桌前说："自动测试在创建时运行正常。由于应用程序和测试数据发生了变化，一些自动测试失败了。我可能需要几周时间来纠正它们"。

Russ was unhappy and asked “I thought maintaining the automated test suite is part of your job. Don’t you agree? The app will always change, we are doing Agile, right? Can you get it done in three days? And from that on, make sure all tests are well-maintained”.
Russ 很不高兴，问道："我以为维护自动测试套件是你工作的一部分。你不同意吗？应用程序总是会变的，我们在做敏捷，对吗？你能在三天内完成吗？从那以后，确保所有测试都得到良好维护"。

The next day, Toby came to see Russ with a smile. He said, “Russ, I found a better test automation framework: Playwright, which solved the issues and limitations of our current framework: Cypress. I am confident that I can achieve migrating Cypress to Playwright in three months.”
第二天，托比笑着来找拉斯。他说："拉斯，我找到了一个更好的测试自动化框架：Playwright，它解决了我们现有框架的问题和局限性：Cypress。我有信心在三个月内实现将 Cypress 迁移到 Playwright。

Russ was not impressed, “To my knowledge, it was you who suggested Cypress, to replace the previous failed attempt using TestCafe, 5 months ago. If Cypress was no good as you are saying now, why did you select Cypress in the first place then? ”
Russ 对此不以为然："据我所知，5 个月前是您建议用赛普拉斯来取代之前使用 TestCafe 的失败尝试。如果像你现在说的那样，赛普拉斯不好，那你当初为什么选择赛普拉斯？"

Toby was in silence.
托比沉默不语。

Russ continued, “Our app is just a standard web app, from what I see, unchanged for over 10 years from a testing perspective. I have once seen one real Agile project where the raw Selenium WebDriver test suite enabled ‘daily production releases’. That test automation engineer implemented a handful of core business flow tests in Selenium and ran them in a CT server on the first day, then every day onwards.”
Russ 继续说："在我看来，我们的应用程序只是一个标准的网络应用程序，从测试的角度来看，已经有 10 多年没有变化了。我曾见过一个真正的敏捷项目，其中原始的 Selenium WebDriver 测试套件实现了'每日生产发布'。那位测试自动化工程师在 Selenium 中实施了少量核心业务流程测试，并在第一天就在 CT 服务器中运行，然后每天都运行。

“Facebook is released twice a day, and keeping up this pace is at the heart of our culture. With this release pace, automated testing with Selenium is crucial to making sure everything works before being released.” — DAMIEN SERENI, Engineering Director at Facebook, at Selenium 2013 conference.

"Facebook每天发布两次，保持这种节奏是我们企业文化的核心。在这种发布节奏下，使用 Selenium 进行自动化测试对于确保发布前一切正常至关重要。- Facebook 工程总监 DAMIEN SERENI 在 Selenium 2013 大会上的发言。

Toby said, “It is my mistake for using Cypress, frankly, not just me, many other testers believed …”
托比说："使用赛普拉斯是我的失误，坦率地说，不只是我，许多其他测试人员都认为......"

Russ interrupted him, “You were hired to do useful testing, not experimenting. You are free to dump Cypress to use another, in whatever language. As the project manager, I just want to see real end-to-end execution and test results, daily. Regarding the language, just as an observer, I prefer not JavaScript for a simple reason, to my knowledge, this (Cypress) is the third consecutive test automation failure with JS-based frameworks, the previous two were Protractor and TestCafe.”
拉斯打断了他的话："你们受雇是为了进行有用的测试，而不是做实验。你可以放弃赛普拉斯，改用另一种语言。作为项目经理，我只想每天看到真正的端到端执行和测试结果。关于语言，作为一个旁观者，我不喜欢 JavaScript，原因很简单，据我所知，这（Cypress）已经是连续第三次使用基于 JS 框架的测试自动化失败了，前两次是 Protractor 和 TestCafe。

Toby said, “JavaScript is the most popular ….”
托比说："JavaScript 是最流行的 ...."

Russ stopped Toby and said: “I, and our project team do not care about which language is used for end-to-end scripts at all, as long as it works well, providing real value. You said ‘Yes’ to my request yesterday and now just proposed a different framework. Anyway, in three days, our team members expect to see the daily e2e test execution reports, regardless of the framework or language. What matters is: automated end-to-end test scripts can verify functionalities as an end-user, daily, and remain valid while the app keeps changing.”
拉斯拦住托比说："我和我们的项目团队根本不在乎端到端脚本使用哪种语言，只要它能很好地工作，提供真正的价值。你昨天对我的请求说'是'，现在却提出了一个不同的框架。不管怎么说，三天后，我们的团队成员就会看到每天的 e2e 测试执行报告，而不管使用哪种框架或语言。重要的是：自动化端到端测试脚本可以作为最终用户每天验证功能，并在应用程序不断变化时保持有效。

Three days later, Toby resigned. In his Résumé, an entry was added: “Successfully implemented end-to-end test automation at Company X using Cypress”.
三天后，托比辞职了。在他的简历中，有这样一条记录："在 X 公司使用赛普拉斯成功实施了端到端测试自动化"。

What happened to the project’s test automation afterwards? Russ quickly hired a passionate IT graduate, Darcy, who has no testing or automation experience. He engaged one Test Automation Coach (the test automation engineer he mentioned before) to train Darcy. After one-day training, Darcy started working on converting Cypress tests to raw Selenium WebDriver + RSpec, under the coach’s mentoring. From the 2nd day, the team started to see the e2e test reports on the CT Server (like the one below), detecting regression issues.
项目的测试自动化之后发生了什么？Russ 很快聘请了一位充满热情的 IT 专业毕业生 Darcy，但她没有任何测试或自动化经验。他聘请了一位测试自动化教练（他之前提到过的测试自动化工程师）对达西进行培训。经过一天的培训，达西在教练的指导下开始将 Cypress 测试转换为原始的 Selenium WebDriver + RSpec。从第二天起，团队开始在 CT 服务器上看到 e2e 测试报告（如下图所示），发现了回归问题。

Within the next 5 working days, all Cypress tests (not many anyway) were converted (with the help of BA, as many Cypress tests were invalid or couldn’t complete) to a much better version using raw Selenium WebDriver + RSpec, which BA and manual testers can read and run comfortably. At least two automated regression testing reports each day. Of course, Darcy and the coach had to make necessary updates to the test scripts due to recent changes that were checked in and impacted the automated test scripts. Thanks to the Maintainable Automated Test Design and good tools (e.g. TestWise and BuildWise), maintenance was managed effectively.
在接下来的 5 个工作日内，所有 Cypress 测试（反正也不多）都在 BA 的帮助下（因为许多 Cypress 测试无效或无法完成）转换成了使用原始 Selenium WebDriver + RSpec 的更好版本，BA 和手动测试人员都能轻松阅读和运行。每天至少两份自动化回归测试报告。当然，Darcy 和教练必须对测试脚本进行必要的更新，因为最近的变更被签入并影响了自动化测试脚本。得益于可维护自动测试设计和良好的工具（如 TestWise 和 BuildWise），维护工作得到了有效管理。

The coach told Russ, “Darcy learned well, I don’t need to be here full-time.”, he turned to Darcy, “Remember, running the whole test suite every day at least once. With the growing tests, you will find it harder and harder to maintain them valid. If you are unable to get all tests valid (PASS or failed with good reasons) for 2 days in a row, get Russ to contact me.”
教练对拉斯说："达西学得很好，我不需要全职在这里。"他转向达西："记住，每天至少运行一次整个测试套件。随着测试的不断增加，你会发现越来越难保持它们的有效性。如果你不能连续两天让所有测试都有效（PASS 或有充分理由的失败），请让 Russ 联系我。"

The made-up story comprises a blend of my firsthand witnessed experiences, including the ‘resignation’ part and “Darcy learned to do useful testing in one day”.
这个虚构的故事融合了我的亲身经历，包括 "辞职 "部分和 "达西在一天之内学会了做有用的测试"。

Here I want to point out one thing many people would miss: the importance of Russ, a real Agile manager. Most ordinary project managers, while claiming Agile, would tolerate the faking end-to-end test automation behaviour. Why? It is easy to do so as it is so common. Once test automation is real, while certainly sounds wonderful, but will bring unknowns, i.e. fears to some. Good IT managers, who understand the importance of End-to-End Test Automation, are rare, too.
在这里，我想指出很多人都会忽略的一点：Russ，一位真正的敏捷经理的重要性。大多数普通项目经理虽然声称自己是敏捷项目经理，但却会容忍端到端测试自动化的造假行为。为什么呢？因为这很容易做到，因为它太常见了。一旦测试自动化成为现实，虽然听起来很美好，但却会带来未知数，也就是给某些人带来恐惧。了解端到端测试自动化重要性的优秀 IT 经理也很少见。

Do you think Toby did a satisfying testing job? Of course, not. Will the ‘automated tests’ he left with will be of any use? Highly doubtful. In other words, Toby is a fake test automation engineer, at least for that project. Fake automated testers ruin the reputation of test automation engineers.
你认为托比的测试工作令人满意吗？当然不满意。他留下的 "自动测试 "有用吗？很值得怀疑。换句话说，托比是个假冒的测试自动化工程师，至少在那个项目上是这样。假自动化测试人员毁了测试自动化工程师的声誉。

Some would argue, “It might be a little harsh to call Toby a fake test automation engineer. When first testing the assigned user story, Toby might have found some good defects”.
有人会说："说托比是假冒的测试自动化工程师可能有点过分。在第一次测试指定的用户故事时，托比可能发现了一些好的缺陷"。

Yes, that could be true. But, a manual tester could have accomplished that, most likely, a lot quicker (and also cheaper, as manual testers usually get paid less). Please don’t forget we are talking about the expectation of a Test Automation Engineer.
是的，这可能是真的。但是，人工测试人员完成这项工作的速度可能更快（而且更便宜，因为人工测试人员的工资通常更低）。请不要忘记，我们谈论的是对测试自动化工程师的期望。

Engineering: proven and repeatable process that builds to last.
工程：经过验证的可重复流程，经久耐用。

The real power of end-to-end test automation is regression testing, which means, the automated tests are reliable to run frequently on a daily basis, especially towards to end of the development cycle. Now, if someone tells you (as the project manager), that created the automated tests worked only for that day. How will you feel?
端到端测试自动化的真正威力在于回归测试，这意味着自动化测试可以每天频繁运行，尤其是在开发周期即将结束时。现在，如果有人告诉您（作为项目经理），创建的自动化测试只在当天运行。你会作何感想？

Why people like Toby is common?
为什么托比这样的人很常见？

Creating automated end-to-end tests is very easy, compared to maintenance. Check out my article, “Test Creation Only Accounts for ~10% of Web Test Automation Efforts”.
与维护相比，创建端到端自动化测试非常简单。请参阅我的文章："测试创建只占网络测试自动化工作的 ~10%"。

To be fair, it is largely not Toby’s fault. I am not belittling ‘fake test automation engineers”, because our IT education (university level) never included End-to-End Test Automation. Also, few companies provide training and seek external help such as real test automation coaching. At the same time, there is a huge demand for test automation as most software projects claim “doing Agile”. The responsibility lies with the management for failing to adequately evaluate them and offer comprehensive hands-on training.
公平地说，这主要不是托比的错。我并不是在贬低 "假冒的测试自动化工程师"，因为我们的 IT 教育（大学水平）从未包括端到端测试自动化。而且，很少有公司提供培训，而是寻求外部帮助，如真正的测试自动化辅导。与此同时，由于大多数软件项目都声称要 "实现敏捷"，因此对测试自动化的需求非常大。责任在于管理层没有对他们进行充分评估并提供全面的实践培训。

Imagine Toby confessed no test automation skills, and showed a sincere desire to learn. Thanks to Russ, he would access the real training and the opportunity to work with and learn from a real test automation coach. What a pity!

想象一下，托比承认自己不具备测试自动化技能，并表现出了真诚的学习愿望。多亏了 Russ，他才能获得真正的培训，并有机会与真正的测试自动化教练一起工作和学习。太遗憾了！

But I do despise ‘fakers’ who continue to do fake stuff after witnessing real test automation because faking is easier. These people ruin the reputation of test automation engineers.
但是，我非常鄙视那些 "造假者"，因为造假更容易，他们在目睹了真正的自动化测试之后还在继续造假。这些人破坏了测试自动化工程师的声誉。

In a future article, I will show anyone (with honesty) can do useful end-to-end test automation quickly.
在今后的文章中，我将介绍任何人（只要诚实）都能快速完成有用的端到端测试自动化。

Related reading:
相关阅读

• My eBooks: - Practical Web Test Automation with Selenium WebDriver - Practical Continuous Testing: make Agile/DevOps real - API Testing Recipes in Ruby
  我的电子书： - 利用 Selenium WebDriver 实现实用的 Web 测试自动化 - 实用的持续测试：实现敏捷/开发运营 - Ruby 中的 API 测试食谱
• One Simple Test Automation Scenario Interview Question that Most Candidates Failed
  大多数候选人都失败的一个简单测试自动化场景面试问题
• Benefits of Real Test Automation and Continuous Testing series: Executives, Managers, Business Analysts, Developers, Testers and Customers.
  真实测试自动化和持续测试系列的优势：高管、经理、业务分析师、开发人员、测试人员和客户。
• Why Raw Selenium Syntax is better than Cypress and Playwright? Part 3: Accurate, Intuitive, Consistent, and Geniously Designed
  为什么原始硒语法比 Cypress 和 Playwright 更好？第 3 部分：准确、直观、一致、巧妙的设计
• Chinese Idiom Stories for Software Professionals: #7 Be There just to Make Up the Number (滥竽充数)
  软件专业人士的成语故事：#7 Be there just to make up the number (滥竽充数)
• Practical Advice for Hiring a Junior Test Automation Engineer
  聘用初级测试自动化工程师的实用建议
• 35-Word Functional Test Automation Strategy
  35 字功能测试自动化策略
• Set up, Develop Automated UI tests and Run them in a CT server on your First day at work
  第一天上班就在 CT 服务器中设置、开发自动化用户界面测试并运行它们
• How do I Start Test Automation on Day 1 of Onboarding a Software Project?
  如何在入职软件项目的第一天就开始测试自动化？