软件质量构建：测试驱动开发实战指南

测试驱动开发

5星 · 超过95%的资源需积分: 0 5 浏览量更新于2024-07-18 收藏 9.06MB PDF 举报

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

30元优惠券

《Developer.Testing.Building.Quality.into.Software》是一本深入探讨软件开发中的质量构建实践的书籍，作者是Alexander Tarlinder。本书聚焦于测试驱动开发（TDD）这一关键主题，分为三个章节来展开讨论。首先，"Developer Testing"章节作为全书的起点，它强调了开发者在软件生命周期中的角色，以及他们如何通过积极参与测试过程来提升产品质量。这包括理解测试的目的、策略以及在编码阶段就集成测试的重要性，从而形成一种迭代且持续优化的开发模式。第二章"Testing Objectives, Styles, and Roles"深入解析测试的目标，涵盖了不同类型的测试方法，如功能测试、性能测试、安全测试等，并介绍了测试团队与开发团队之间的协作方式。书中会讨论各种测试风格，比如黑盒测试、白盒测试和灰盒测试，以及测试工程师在项目中的职责划分，例如设计测试用例、执行测试以及与开发人员进行有效沟通。第三章"The Testing Vocabulary"则聚焦于测试领域的专业术语和概念，确保读者对测试术语有清晰的理解。这包括自动化测试、持续集成/持续部署(CI/CD)、回归测试、缺陷管理等核心概念，帮助开发者和测试人员共同构建出高质量的代码库。整个书籍不仅关注测试技术本身，还强调了质量文化在软件开发中的重要性，提倡通过实践TDD，将质量内化到每一个开发步骤中，降低错误和遗漏，减少后期维护成本。此外，书中也提醒读者版权问题，指出某些制造商和卖家的产品名称可能为商标，购买时需遵循相关规则。《Developer.Testing.Building.Quality.into.Software》是一本适合开发人员、测试工程师和质量保证专业人员阅读的实用指南，提供了关于测试驱动开发和软件质量保障的全面而深入的教育资料。通过学习这本书，读者可以提升软件开发流程中的质量意识，掌握有效的测试策略和技术，从而在实际工作中实现更好的产品交付。

资源详情

资源推荐

ptg18145136

Foreword by Lisa Crispin

The subtitle says it all—“Building Quality into Software.” We’ve always known that

we can’t test quality in by testing after coding is “done.” Quality has to be baked in.

To do that, the entire delivery team, including developers, has to start building each

feature by thinking about how to test it. In successful teams, every team member has

an agile testing mind-set. They work with the delivery and customer teams to under-

stand what the customers need to be successful. They focus on preventing, rather

than finding, defects. They find the simplest solutions that provide the right value.

In my experience, even teams with experienced professional testers need devel-

opers who understand testing. They need to be able to talk with designers, product

experts, testers, and other team members to learn what each feature should do. They

need to design testable code. They need to know how to use tests to guide coding,

from the unit level on up. They need to know how to design test code as well as—or

even better than—production code, because that test code is our living documenta-

tion and our safety net. They need to know how to explore each feature they develop

to learn whether it delivers the right value to customers.

I’ve encountered a lot of teams where developers are paid to write production

code and pushed to meet deadlines. Their managers consider any time spent testing

to be a waste. If these organizations have testers at all, they’re considered to be less

valuable contributors, and the bugs they find are logged in a defect tracking system

and ignored. These teams build a mass of code that nobody understands and that is

difficult to change without something breaking. Over time they generally grind to a

halt under the weight of their technical debt.

I’ve been fortunate over the years to work with several developers who really

“get” testing. They eagerly engage in conversations with business experts, design-

ers, testers, analysts, data specialists, and others to create a shared understanding of

how each feature should behave. They’re comfortable pairing with testers and hap-

pily test their own work even before it’s delivered to a test environment. These are

happy teams that deliver solid, valuable features to their customers frequently. They

can change direction quickly to accommodate new business priorities.

Testing’s a vast subject, and we’re all busy, so where do you start? This book deliv-

ers key testing principles and practices to help you and your team deliver the qual-

ity your customers need, in a format that lets you pick up ideas quickly. You’ll learn

the language of testing so you can collaborate effectively with testers, customers, and

other delivery team members. Most importantly (at least to me), you’ll enjoy your

work a lot more and be proud of the product you help to build.

ptg18145136

xvii

preFaCe

I started writing this book four years ago with a very clear mental image of what I

wanted it to be and who my readers were going to be. Four years is quite a while, and

I’ve had to revise some of my ideas and assumptions, both in response to other work

in the field and because of deepening understanding of the subject. The biggest thing

that has happened during the course of those years is that the topic has become less

controversial. Several recent books adopt a stance similar to this one, and there’s some

reassuring overlap, which I interpret as being on the right track.

Why I Wrote This Book

I wrote this book because this was the book I should have read a decade ago! Ten years is

a long time, but believe it or not, I still need this book today—although for other reasons.

Roughly 10 years ago I embarked on a journey to understand software quality. I

wasn’t aware of it back then; I just knew that the code that I and my colleagues wrote

was full of bugs and made us sad and the customers unhappy. I was convinced that

having testers execute manual routines on our software wouldn’t significantly increase

its quality—and time has proven me right! So I started reading everything I could find

about software craftsmanship and testing, which led to two major observations.

First, to my surprise, these topics were often totally separated back then! Books

about writing software seldom spoke of verifying it. Maybe they mentioned one or

two testing techniques, but they tended to skip the theory part and the conceptual

frameworks needed for understanding how to work systematically with testing in dif-

ferent contexts. That was my impression at least. On the other hand, books on testing

often tended to take off in the direction of a testing process. Books on test-driven

development focused on test-driven development. This applied to blogs and other

online material too.

Second, writing testable code was harder than it initially appeared, not to men-

tion turning old legacy monoliths into something that could be tested. To get a feel-

ing for it, I had to dive deep into the areas of software craftsmanship, refactoring,

legacy code, test-driven development, and unit testing. It took a lot of deliberate

practice and study.

Based on these observations and my accumulated experience, I set some goals for

a book project:

ptg18145136

xviii Preface



Make the foundations of software testing easily accessible to developers, so

that they can make informed choices about the kind and level of verifica-

tion that would be the most appropriate for code they’re about to ship. In my

experience, many developers don’t read books or blogs on testing, yet they

keep asking themselves: When have I tested this enough? How many tests

do I need to write? What should my test verify? I wanted these to become

no-brainers.



Demonstrate how a testing mind-set and the use of testing techniques can

enrich the daily routines of software development and show how they can

become a developer’s second nature.



Create a single, good enough body of knowledge on techniques for writing test-

able code. I realized that such a work would be far from comprehensible, espe-

cially if kept concise, but I wanted to create something that was complete enough

to save the readers from plowing through thousands of pages of books and online

material. I wanted to provide a “map of the territory,” if you will.

This is why I should have had a book written with these goals in mind a decade

ago, but why today? Hasn’t the world changed? Hasn’t there been any progress in the

industry? And here comes the truly interesting part: this book is just as applicable

today as it would have been 10 years ago. One reason is that it’s relatively technol-

ogy agnostic. Admittedly it is quite committed to object-oriented programming,

although large parts hold true for procedural programming, and some contents apply

to functional programming as well. Another reason is that progress in the field it cov-

ers hasn’t been as impressive as in many others. True, today, many developers have

grasped the basics of testing, and few, if any, new popular frameworks and libraries

are created without testability in mind. Still, I’d argue that it’s orders of magnitude

easier to find a developer who’s a master in writing isomorphic JavaScript applica-

tions backed by NoSQL databases running in the cloud than to find a developer who’s

really good at unit testing, refactoring, and, above all, who can remain calm when the

going gets tough and keep applying developer testing practices in times of pressure

from managers and stressed-out peers.

Being a consultant specializing in software development, training, and men-

toring, I’ve had the privilege to work on several software development teams and to

observe other teams in action. Based on these experiences, I’d say that teams and

developers follow pretty much the same learning curve when it comes to quality

assurance. This book is written with such a learning curve in mind, and I’ve done my

best to help the reader overcome it and progress as fast as possible.

ptg18145136

Preface xix

Target Audience

This is a book for developers who want to write better code and who want to avoid

creating bugs. It’s about achieving quality in software by acknowledging testability

as a primary quality attribute and adapting the development style thereafter. Readers

of this book want to become better developers and want to understand more about

software testing, but they have neither the time nor support from their peers, not to

mention from their organizations.

This is not a book for beginners. It does explain many foundations and basic

techniques, but it assumes that the reader knows how to work his development envi-

ronment and build system and is no stranger to continuous integration and related

tooling, like static analysis or code coverage tools. To get the most out of this book,

the reader should have at least three years of experience creating software profession-

ally. Such readers will find the book’s dialogues familiar and should be able to relate

to the code samples, which are all based on real code, not ideal code.

I also expect the reader to work. Even though my ambition is to make lots of

information readily available, I leave the knowledge integration part to the reader.

This is not a cookbook.

About the Examples

This book contains a lot of source code. Still, my intention was never to write a pro-

gramming book. I want this to be a book on principles and practices, and as such, it’s

natural that the code examples be written in different languages. Although I’m trying

to stay true to the idioms and structure used in the various languages, I also don’t

want to lose the reader in fancy details specific to a single language or framework;

that is, I try to keep the examples generic enough so that they can be read by anyone

with a reasonable level of programming experience. At times, though, I’ve found this

stance problematic. Some frameworks and languages are just better suited for certain

constructs. At other times, I couldn’t decide, and I put an alternative implementation

in the appendix. The source code for the examples in the book and other related code

are available on the book’s companion website—http://developertesting.rocks.

How to Read This Book

This book has been written with a very specific reader in mind: the pressed-for-time

developer who needs practical information about a certain topic without having to

read tons of articles, blogs, or books. Therefore, the underlying idea is that each chap-

ter should take no more than one hour to read, preferably less. Ideally, the reader

should be able to finish a chapter while commuting to work. As a consequence, the

剩余341页未读，继续阅读

liuyu85cn

粉丝: 0
资源: 2

软件质量构建：测试驱动开发实战指南

Linux命令大全（完整版）+小白速成+面试必备+学不会来找我.rar

字幕在线翻译软件

严蔚敏主讲数据结构视频（.torrent种子）

Software Testing and Continuous Quality Improvement

Go in Practice.pdf

ebook-flutter-revolution.pdf

Msdn Magazine Feb. 2012

a project model for the FreeBSD Project.7z

PyCharm Python Code Review: Enhancing Code Quality and Building a Robust Codebase

Mastering Software Version Management with Tsinghua Mirror Source Addresses

numexpr-2.8.3-cp38-cp38-win_amd64.whl

ujson-5.3.0-cp311-cp311-win_amd64.whl

基于MATLAB车牌识别程序技术实现面板GUI.zip

RJFireWall-maste赛资源

msgpack-1.0.4-cp39-cp39-win_amd64.whl

基于 YOLOv11 的混凝土缺陷检测系统（包含详细的完整的程序和数据）

最新资源