『新东方在线托福听力』为托福考生准备了ETS托福TPO/Official 21 Lec 2听力练习：How did the software product developed during Project Split differ from the product developed during Project Unity?原文题目答案解析，TPO/Official 21 Lec 2听力原文范文音频翻译。

托福TPO/Official 21 Lec 2听力原文How did the software product developed during Project Split differ from the product developed during Project Unity?-新东方托福官方网校手机版

旁白：听一段计算机科学的课程讲解。

Narrator: Listen to part of a lecture in a Computer Science class.

教授正在讨论软件工程的问题。

The professor is discussing software engineering.

教授：之前我们一直在讲软件开发周期，今天我们进入下一阶段的讨论——软件测试，以及为何在测试过程中找到bugs是件好事。

Professor: We've been talking about the software development cycle, and today I'd like to move on to the next stage of that cycle-testing, and why finding bugs during testing is actually a great thing.

呃……软件产品的质量往往很大程度在取决于它的测试情况。利兹，有什么问题吗？

Eh...eh... the quality of the software product often relies heavily on how well it's been tested. Liz?

学生：嗯……就一个小小的问题。

bugs是指编程码存在的问题是吗？

Bugs is the word for problems in the program code, correct?

教授：是的，编程码或者计算机本身存在的问题都叫bug。

Professor: Yeah, in code or in a computer itself.

其实这个术语的背后还有一个小故事。

There is a bit of a story behind that term.

恩……追溯到20世纪40年代，那还是计算机产业刚刚起步的时候，几个计算机科学家一直工作到很晚，因为计算机的一个回路出现了问题。

Um... back in the 1940s, when the computer industry was just starting, a group of computer scientists was working late one night, and there was a problem in one of the computers' circuits.

当他们去检查的时候，发现一个五公分的飞蛾卡在了那里。

When they examined it, they found a five-centimeter long moth caught in there.

当他们拿走飞蛾以后，计算机就恢复正常工作了。

Once they debugged the computer, it worked just fine.

从此以后，所有计算机的问题都被称为bugs了。

And ever since then, all kinds of computer problems have been known as bugs.

不管怎么说，bugs最好是在开发或者测试阶段就被发现。

Anyway, you want to find bugs while the software is still in the development and testing phases.

如果当软件产品已经投放市场了才发现bugs的话，局势就会比较尴尬了。

Finding them when the software product has already been put on the market can be quite embarrassing.

大致来讲，每个软件工程都有一组开发人员和一组测试人员。杰克？

Generally speaking, every software development project has a group of testers and a group of developers. Jack?

教授：大致来说他们是由两组完全不同的人组成。

Professor: They are generally completely different groups of people.

我个人的观点是开发人员和测试人员一定要是由两组不同的人来组成，因为软件开发人员总会对自己的作品有些偏爱，这就导致他们忽视一些其他人看起来很明显的问题。

My personal opinion is that they have to be different groups of people because developers often have a bias for their own work, and it blinds them to certain problems that might be obvious to somebody else.

所以说有不同的人来参与到项目中来的话，会使测试更完善。

So it is always good to have a different set of eyes to go in there and make sure that everything is tested properly.

开发人员与测试人员的心态是不一样的。

Developers and testers have different mentalities.

软件开发人员是有建设性、有创意性，他们往往花大量的时间来共同创建新的产品。

The mentality of the software developer is constructive, creative, they are spending long hours working together to create and build something new.

而软件测试人员的主要任务就是观察这些产品并发现问题，然后来提升软件的质量。

A software tester, on the other hand, their entire goal is to look at this product and find problems with it, to improve it.

那么软件开发人员和测试人员之间的不同就会引起一点小摩擦。

Now, this difference between the testers and the developers can lead to an environment where there is a bit of friction.

这种摩擦有时就会使开发人员和测试人员很难在一起协调的工作。

And that friction sometimes makes it difficult for the two teams to work together.

There are two projects that I worked on a couple of years ago.

我称其中的一个为分离项目组，这组的开发人员和测试人员就很难在一起共事。

One, which I'll call Project Split, well, the testing and development teams did not work well together.

另一组我称之为团结项目组，这组人员就合作起来很愉快。

And the other, I'll call Project Unity, during which both teams worked very well together.

第一组人员在进行缺陷讨论会议时，也就是开发人员和测试人员在一起，嗯……讨论各种各样的问题并找出解决方案。

Now, during Project Split, we had defect meetings where the developers and the testers met together, eh... eh... to discuss various problems and how they should be fixed.

你在一进入会议室的时候将就能感到那种紧张的气氛。

And you could sense the conflict just by walking into the room.

准确来讲是，测试人员和开发人员完全对立来坐。

Literally, the testers and the developers sat on opposite sides on the table.

呃……而且开发人员对收到的反馈总是持有怀疑的态度。

Um... and ... and the developers were very defensive about the feedback.

学生：恩，当bugs被指出的时候他们肯定不会开心，毕竟那是他们做的产品嘛。

Student: Well, if bugs are being pointed out they wouldn't be too happy since it's their work.

教授：的确如此。正因为这两组人员不能协调的工作，所以修正工作总是进行的很缓慢。

Professor: Exactly. Now, because the two teams weren't working well together, the fixes were coming very very slowly.

而且正如你们所知道的，有些时候当你在修正bugs的时候又会引发一些新的bugs，或者在进行了一些调整之后，新的bugs才显现出来，所以说这些新加的bugs总是未能及时修复。

And you know, a lot of times when you fix bugs you introduce new bugs, or you discover bugs and other areas that only come to light because something has been changed, so fixing all those new additional bugs was also being delayed.

呃……测试的过程比预期的要长得多，我们最终就不得不将存有bugs的产品投放市场，当然这并不是明智之举。

Um... the test process went on much longer than expected and we ended up having to put the product on the market with known bugs in it, which was obviously not ideal.

学生：好的，那么团结项目组呢？

Student: Ok, and what about Project Unity?

教授：恩……这组的不同之处体现于缺陷讨论会上，开发人员和测试人员并没有产生对立的局势，而是很好的进行协作。

Professor: Um... this was different because two teams worked closely together during the defect meetings, instead of put up walls.

呃……我们甚至无需指明谁来进行修复，这又是谁的错。

Um... we didn't even talked about, you know, who should fix this, who is at fault.

我们也都知道到底哪些地方需要修复。

We all acknowledge what needed to be fixed.

所以，假如说我们有十个bugs，我们就会说:“嘿，不如这样吧，我们先来修复这个吧”，因为这样就可以显露出一系列我们还没有发现的缺陷问题。

So if we had ten bugs, we said, ‘Hey, you know what? Let's do this one first ‘cause this would expose another whole bunch of defects that we haven't even seen yet.'

因为我们也很有前瞩性和效率性。

So we were being proactive and effective.

正因为我们做事很有效率，事实上我们总能不仅仅是修复了bugs，还能注入一些之前没有计划过的升级元素。

And because we were so much more effective with our time, we were actually able to do more than just fix the bugs, we even put in some improvements that we hadn't planned.

According to the professor, where does the term "bug" used for computer problems come from?

What points does the professor make about software developers?

What factor made work on Project Unity efficient?

How did the software product developed during Project Split differ from the product developed during Project Unity?

When the professor discusses some work meeting attended by two teams, why does he say this:

Narrator Listen to part of a lecture in a Computer Science class. The professor is discussing software engineering. Professor We’ve been talking about the software development cycle, and today I’d like to move on to the next stage of that cycle-testing, and why finding bugs during testing is actually a great thing. Eh...eh... the quality of the software product often relies heavily on how well it’s been tested. Liz? Student Um...just a quick thing. Bugs is the word for problems in the program code, right? Professor Yeah, in code or in a computer itself. There is a bit of a story behind that term. Um... back in the 1940s, when the computer industry was just starting, a group of computer scientists was working late one night, and there was a problem in one of the computers’ circuits1. When they examined it, they found a five-centimeter long moth caught in there. Once they debugged the computer, it worked just fine. And ever since then, all kinds of computer problems have been known as bugs. Anyway, you want to find bugs while the software is still in the development and testing phases. Finding them when the software product has already been put on the market can be quite embarrassing. Generally speaking, every software development project has a group of testers and a group of developers. Jack? Student And they are different people? Professor They are generally completely different group of people. My personal opinion is that they have to be different groups of people because developers often have a bias for their own work, and it blinds them to certain problems that might be obvious to somebody else. So it is always good to have a different set of eyes to go in there and make sure that everything is tested properly. Ok, now, here’s the key. Developers and testers have different mentalities. The mentality of the software developer is constructive, creative, they are spending long hours working together to create and build something new. A software tester, on the other hand, their entire goal is to look at this product and find problems with it, to improve it. Now, this difference between the testers and the developers can lead to an environment where there is a bit of friction. And that friction sometimes makes it difficult for the two teams to work together. There are two projects that I worked on a couple of years ago. One, which I’ll call Project Split, well, the testing and development teams did not work well together. And the other, I’ll call Project Unity, during which both teams worked very well together. Now, during Project Split, we had defect meetings where the developers and the testers met together, eh... eh... to discuss various problems and how they should be fixed. And you could sense the conflict just by walking into the room. Literally, the testers and the developers sat on opposite sides on the table. Um... and ... and the developers were very defensive about the feedback. Student Well, if bugs are being pointed out they wouldn’t be too happy since its their work. Professor Exactly. Now, ‘cause the two teams weren’t working well together, the fixes were coming very very slowly. And you know, a lot of times when you fix bugs you introduce new bugs, or you discover bugs and other areas that only come to light because something has been changed, so fixing all those new additional bugs was also being delayed. Um... the test process went on much longer than expected and we ended up having to put the product on the market with known bugs in it, which was obviously not ideal. Student Ok, and what about Project Unity? How was it different? Professor Um... this was different because two teams worked closely together during the defect meetings, instead of put up walls. Um... we didn’t even talked about, you know, who should fix this, who is at fault. We all acknowledge what needed to be fixed. So if we had ten bugs, we said, ‘Hey, you know what? Let’s do this one first ‘cause this would expose another whole bunch of defects that we haven’t even seen yet.’ So we were being proactive and effective. And because we were so much more effective with our time, we were actually able to do more than just fix the bugs, we even put in some improvements that we hadn’t planned. Student Well, if bugs are being pointed out they wouldn’t be too happy since its their work. Professor Exactly. Now, ‘cause the two teams weren’t working well together, the fixes were coming very very slowly. And you know, a lot of times when you fix bugs you introduce new bugs, or you discover bugs and other areas that only come to light because something has been changed, so fixing all those new additional bugs was also being delayed. Um... the test process went on much longer than expected and we ended up having to put the product on the market with known bugs in it, which was obviously not ideal. Now, during Project Split, we had defect meetings where the developers and the testers met together, eh... eh... to discuss various problems and how they should be fixed. And you could sense the conflict just by walking into the room. Literally, the testers and the developers sat on opposite sides on the table. Um... and ... and the developers were very defensive about the feedback.