谷歌软件测试之道：创新与实践

Test

Google

5星 · 超过95%的资源需积分: 9 76 浏览量更新于2023-06-07 2 收藏 9.63MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"How Google Tests Software 是一本探讨谷歌如何进行软件测试的英文书籍。作者James Whittaker揭示了谷歌在测试领域的创新实践，包括自动化与手动测试的结合、内部与外包资源的融合，以及利用真实环境测试来补充实验室测试。这本书对于希望保持测试实践相关性、竞争力和意义的所有测试人员来说，都是必读之作。" 谷歌是软件测试领域的先驱，它不断尝试新的方法以解决新问题并推出更优秀的应用。James Whittaker在书中详细介绍了谷歌在快速发展的应用测试世界中的成功策略。他采取了一种计算机科学的方法来处理测试问题，这种方法有望成为未来软件公司的标准。谷歌的测试实践强调了几个关键点： 1. 自动化与手动测试的平衡：谷歌认识到完全依赖自动化或手动测试都有其局限性，因此他们将两者结合起来，确保测试的全面性和效率。自动化测试用于执行重复性高、可预测性强的任务，而手动测试则用于评估更复杂、需要人类判断的场景。 2. 内部与外部资源的整合：谷歌不仅依赖内部团队进行测试，还与外部资源合作，如外包测试团队和用户社区，以获取更广泛和多样化的测试反馈。 3. 现实世界测试：除了在受控实验室环境中进行测试，谷歌还引入了"在野外"（in-the-wild）测试，即将产品推向实际用户，收集真实使用情况下的数据，以发现可能在实验室环境中未暴露的问题。 4. 持续集成与快速发布：谷歌采用持续集成实践，使得代码频繁合并，并快速进行测试和部署，这有助于尽早发现问题并减少集成风险。 5. 测试驱动开发(TDD)：书中可能会提到谷歌对TDD的采用，这是一种开发模式，开发者在编写功能代码之前先编写测试用例，以此确保代码质量。 6. 智能测试工具和框架：谷歌开发了各种工具和框架，比如Test Automation Platform (TAP)，帮助测试工程师更有效地设计和执行测试，提高测试覆盖率和效率。 7. 测试文化：谷歌重视整个组织的测试文化，鼓励所有员工参与测试，强调质量是每个人的责任，而非仅限于测试团队。 8. 反馈循环和敏捷方法：谷歌的测试过程紧密与敏捷开发流程相结合，快速迭代和持续改进是其核心原则。这本书深入探讨了谷歌如何通过这些方法来保证其产品的质量和用户体验，对于任何想了解和学习高效软件测试实践的人来说，都是宝贵的资源。通过学习和应用这些策略，其他公司也能提升自己的测试能力和软件质量。

资源详情

资源推荐

ptg7759704

worked, of course, but in the process, we learned valuable lessons and

practices that are applicable to any company that wants to grow or move at

the speed of Google. We learned how to have attention to quality without

derailing development or the speed at which we got things done. The

resulting process, with some insights into the thinking behind them and

what makes them work, is what this book is about. If you want to under-

stand how Google met the challenges of testing in the twenty-first century

on modern Internet, mobile, and client applications, then you have come to

the right place. I may wish it was me who was telling the rest of the story,

but James and his coauthors beat me to it and they have nailed the essence

of what testing is like here at Google.

One final note on the book: James Whittaker is the guy who made this

book happen. He came to Google, dug in to the culture, took on big and

important projects, and shipped products such as Chrome, Chrome OS,

and dozens of smaller ones. Somewhere in that time, he became the public

face of Google testing. But, unlike some of his other books, much of this

material is not his. He is as much a reporter on the evolution of how

Google tests software as he is a contributor to it. Keep that in mind as you

read it because James will probably try to take all the credit for himself!

As Google grew from 200 to over 20,000 employees, there were many

people who played important roles in developing and putting into action

our testing strategy. James credits many of them and they have contributed

directly by writing sidebars and giving interviews that are published in

this book. However, no one, not me, James, or anyone else mentioned in

this book, has had as much influence as Patrick Copeland, the architect of

our current organizational structure and leader of Google’s Engineering

Productivity team. Every tester in the company reports up through Patrick

and he is the executive whose vision created what James has documented

and contributed to here. If anyone can take credit for how Google tests

software today, it’s Patrick. I am not just saying this because he’s my boss; I

am saying it because he’s my boss and he told me to say it!

Alberto Savoia is an engineering director and innovation agitator at

Google. He first joined Google in 2001 when, among other things, he man-

aged the launch of Google AdWords and played a key role in kick-starting

a developer / unit testing culture in the company. He is also the author of

The Way of Testivus and of “Beautiful Tests” in O’Reilly’s Beautiful Code.

Note by James Whittaker: I couldn’t agree more! As a scribe and jour-

nalist in this process, I owe most of the material to the organization that

Patrick has created. And I am not just saying this because he gave me per-

mission to write this book. As my boss, he made me write this book!

Foreword by Alberto Savoia xv

www.it-ebooks.info

ptg7759704

A Fault to Guide Software Testing

010101011011000100100100101010110110001001001001010

Foreword by Patrick Copeland

My adventure with Google started in March of 2005. If you read Alberto’s

foreword, you know a bit about the conditions of Google around that time.

It was small but beginning to show signs of serious growing pains. It was

also a time of rapid technological change as the web world was welcoming

dynamic content and the cloud was becoming a viable alternative to the

then dominant world of client-server.

That first week, I sat with the rest of the Nooglers topped with a tri-

colored propeller hat listening to the founders discussing corporate strate-

gy at a weekly company meeting called TGIF. I knew little about what I

had gotten myself into. I was naïve enough to be excited and aware

enough to be more than a little intimated. The speed and scale of Google

made my previous decade of 5-year ship cycles seem like poor preparation.

Worse still, I think I was the only tester wearing one of those Noogler hats.

Surely there were more of us somewhere!

I joined Google when engineering was just shy of 1,000 people. The

testing team had about 50 full timers and some number of temporary

workers I never could get my head around. The team was called “Testing

Services” and focused the majority of its energy on UI validation and

jumping into projects on an as-needed basis. As you might imagine, it

wasn’t exactly the most glorified team at Google.

But at that time it was enough. Google’s primary businesses were

Search and Ads. The Google world was much smaller than it is today, and

a thorough job of exploratory testing was enough to catch most quality

concerns. But the world was slowly changing. Users were hitting the web

in unprecedented numbers and the document-based web was giving way

to the app-based web. You could feel the inevitability of growth and

change where the ability to scale and get to market quickly would be the

difference between relevance and…a place you did not want to be.

Inside Google, the scale and complexity issues were buckling Testing

Services. What worked well with small homogenous projects was now

burning out good testers as they leapt from one project that was on fire to

the next. And topping all that off was Google’s insistence to release quick-

er. Something needed to give and I had the choice between scaling this

manually intensive process or changing the game completely. Testing

Services needed a radical transformation to match the radical change hap-

pening to the industry and the rest of Google.

I would very much like to say that I drew upon my vast wealth of

experience and conjured the perfect test organization, but the truth is that

my experience had taught me little more than the wrong way to do things.

Every test organization I ever worked as part of or led was dysfunctional

in one way or the other. Stuff was always broken. The code was broken, the

www.it-ebooks.info

ptg7759704

tests were broken, and the team was broken! I knew what it meant to be

buried under quality and technical debt where every innovative idea was

squashed lest it risk breaking the fragile product it depended on. If my

experience taught me anything, it was how not to do testing.

In all my interactions up to this point, one thing about Google was

clear. It respected computer science and coding skill. Ultimately, if testers

were to join this club, they would have to have good computer

science fundamentals and some coding prowess. First-class citizenship

demanded it.

If I was going to change testing at Google, I needed to change what it

meant to be a tester. I used to try to imagine the perfect team and how such

a team would shoulder the quality debt and I kept coming back to the

same premise: The only way a team can write quality software is when the

entire team is responsible for quality. That meant product managers, devel-

opers, testers…everyone. From my perspective, the best way to do this was

to have testers capable of making testing an actual feature of the code base.

The testing feature should be equal to any feature an actual customer

might see. The skill set I needed to build features was that of a developer.

Hiring testers who can code features is difficult; finding feature devel-

opers who can test is even more difficult. But the status quo was worse

than either so I forged ahead. I wanted testers who could do more for their

products and at the same time, I wanted to evolve the nature and owner-

ship of the testing work, which meant asking for far larger investment

from the development teams. This is the one organizational structure I had

yet to see implemented in all my time in the industry and I was convinced

it was right for Google, and I thought that as a company, we were ready

for it.

Unfortunately, few others in the company shared my passion for such

profound and fundamental change. As I began the process of socializing

my equal-but-different vision for the software testing role, I eventually

found it difficult to find a lunch partner! Engineers seemed threatened by

the very notion that they would have to play a bigger role in testing, point-

ing out “that’s what test is for.” Among testers, the attitude was equally

unsavory as many had become comfortable in their roles and the status

quo had such momentum that change was becoming a very hard problem.

I kept pressing the matter mostly out of fear that Google’s engineering

processes would become so bogged down in technical and quality debt

that I’d be back to the same five-year ship cycles I had so happily left

behind in the old client-server world. Google is a company of geniuses

focused on innovation and that entrepreneurial makeup is simply incom-

patible with long product ship cycles. This was a battle worth fighting and

I convinced myself that once these geniuses understood the idea of devel-

opment and testing practices for a streamlined and repeatable “technology

factory,” they would come around. They would see that we were not a

startup anymore and with our rapidly growing user base and increasing

technical debt of bugs and poorly structured code would mean the end of

their coder’s playground.

xviii Foreword by Patrick Copeland

www.it-ebooks.info

ptg7759704

I toured the product teams making my case and trying to find the

sweet spot for my argument. To developers, I painted a picture of continu-

ous builds, rapid deployment, and a development process that moved

quickly, leaving more time for innovation. To testers, I appealed to their

desire to be full engineering partners of equal skill, equal contribution, and

equal compensation.

Developers had the attitude that if we were going to hire people skilled

enough to do feature development, then we should have them do feature

development. Some of them were so against the idea that they filled my

manager’s inbox with candid advice on how to deal with my madness.

Fortunately, my manager ignored those recommendations.

Testers, to my surprise, reacted similarly. They were vested in the way

things were and quick to bemoan their status, but slow to do anything

about it.

My manager’s reaction to the complaints was telling: “This is Google,

if you want something done, then do it.”

And so that’s what I did. I assembled a large enough cadre of like-

minded folks to form interview loops and we began interviewing candi-

dates. It was tough going. We were looking for developer skills and a tester

mindset. We wanted people who could code and wanted to apply that skill

to the development of tools, infrastructure, and test automation. We had to

rethink recruiting and interviewing and then explain that process to the

hiring committees who were entrenched and comfortable with the way

things were.

The first few quarters were rough. Good candidates were often torpe-

doed in the vetting process. Perhaps they were too slow to solve some

arcane coding problem or didn’t fare well in something that someone

thought was important but that had nothing to do with testing skill. I

knew hiring was going to be difficult and made time each week to write

hiring justification after hiring justification. These went to none other than

Google co-founder Larry Page who was (and still is) the last approval in

the hiring process. He approved enough of them that my team began to

grow. I often wonder if every time Larry hears my name he still thinks,

“Hiring testers!”

Of course, by this time, I had made enough noise trying to get buy-in

that we had no choice but to perform. The entire company was watching

and failure would have been disastrous. It was a lot to expect from a small

test team supported by an ever-changing cast of vendors and temps. But

even as we struggled to hire and I dialed back the number of temps we

used, I noticed change was taking hold. The more scarce testing resources

became, the more test work was left for developers to do. Many of the

teams rose to the challenge. I think if technology had stayed the same as it

was, this alone would have taken us nearly where we needed to be.

But technology wasn’t standing still and the rules of development and

testing were changing rapidly. The days of static web content were gone.

Browsers were still trying to keep up. Automation around the browser was

a year behind the already tardy browsers. Making testing a development

Foreword by Patrick Copeland xix

www.it-ebooks.info

剩余313页未读，继续阅读

renzhewh

粉丝: 39
资源: 101

会员权益专享

谷歌软件测试之道：创新与实践

how google test software

How Google tests software

How google tests software

how ATE test a Power Switch unit

how to use GetParam() in googletest

how to test Measure Power Consumption

how to test a Power Switch IC

how to using python to unit test

how to Import the video file into your video editing software.

give me a summerize of how to use the software obsidian

HowTo_support_WIFI_certification_test

Code coverage test

根据标点符号对字符串进行分割 text = "Hello, how are you?I hope you're doing well. This is a test."

系统测试参考文献有哪些

f_test.seek(0) f_test.truncate()

在程序中定义一字符串”hello,how are you!”，分别用字节流和字符流实现将该字符串保存到d:\t2_1.txt, d:\t2_2.txt中，程序分别保存为Test2_1.java和Test2_2.java。

Mann-Kendall monotonicity test python

会员权益专享

最新资源