The Program Development Life Cycle
A-Level Computer Science Topic 12 19:26 English narration · English + 中文 subtitles burned in
Chapters
Transcript
A tiny bug, if it slips through to release, can cost a fortune to fix — far more than catching it early.
一个小小的漏洞，如果一路溜到发布之后，修起来可能要花一大笔钱——远比早早抓住它要贵得多。
That is why we don't just start typing code.
这就是为什么我们不会一上来就敲代码。
We follow a development life cycle: a set of stages that plan, manage and control a project — plan the work, coordinate the team, and build in testing at every step.
我们遵循一套开发生命周期：一组阶段， 用来计划、管理和控制一个项目——规划工作、协调团队，并在每一步都内置测试。
Get the process right, and you build the right product, on time, with far fewer nasty surprises.
把流程做对，你就能按时做出正确的产品，而且讨厌的意外要少得多。
Great software isn't just written — it's planned, built, tested, and maintained.
优秀的软件不只是写出来的——它是被规划、构建、测试和维护出来的。
Today: the life cycle stages, the models teams use, the three kinds of error, how we choose test data, and the maintenance that follows.
今天我们讲： 生命周期的各个阶段、团队使用的模型、三种错误、我们如何选择测试数据，以及随之而来的维护。
Let's begin.
让我们开始吧。
Every project moves through five stages.
每个项目都会经历五个阶段。
Analysis: find out what the program must do, and write down the requirements.
分析：弄清楚程序必须做什么，并把需求写下来。
Design: decide how — the data structures, the algorithms, the modules.
设计：决定怎么做——数据结构、算法、模块。
Coding, or implementation: write the source code, following the design.
编码（实现）：按照设计写出源代码。
Testing: run it against test data, and fix the bugs.
测试：用测试数据来运行它，并修复漏洞。
And maintenance: after release, keep it working and useful.
还有维护：发布之后，让它持续可用又好用。
Most of a program's cost, in fact, comes after it ships.
事实上，一个程序的大部分成本，都发生在它交付之后。
The design stage has named outputs, and a question can ask you to list them: the structure chart giving the modules and their parameters, flowcharts or pseudocode for each module, identifier tables and the data structures, the screen and file layouts, and the test plan — written now, from the specification, before any code exists.
设计阶段有明确的产出物，题目可能要你把它们列出来： 给出模块和参数的结构图、每个模块的流程图或者伪代码、 标识符表和数据结构、屏幕和文件的布局， 以及测试计划——就在这时写，依据规格说明书，在任何代码存在之前。
Documentation is produced through the cycle, not bolted on at the end.
文档是在整个周期中不断产出的，而不是最后临时补上的。
Before the models, be clear what a life cycle is FOR, because that is a question in itself.
在讲各种模型之前，先弄清楚生命周期是为了什么，因为这本身就是一道题。
It manages complexity, by breaking one enormous program into phases you can finish and check.
它管理复杂性，把一个庞大的程序拆成一个个能做完、能检查的阶段。
It coordinates teams, so people are not writing the same thing twice or waiting on each other.
它协调团队，免得有人把同一件事做两遍，或者互相干等。
It tracks progress with milestones, so you know whether you are late while there is still time to act.
它用里程碑跟踪进度，让你在还来得及补救的时候就知道自己晚了。
It builds testing in rather than leaving it to the end.
它把测试内建进去，而不是留到最后。
It records design decisions for whoever maintains the code in five years.
它记录设计决策，留给五年后维护代码的人。
And it manages risk.
它还管理风险。
That also explains why there are several models: no single life cycle fits every project.
这也解释了为什么会有好几种模型：没有哪一种生命周期适合所有项目。
The choice depends on the size and complexity, how clear the requirements are at the start, how much change you expect, the risk, the team, and the deadline.
选择取决于规模和复杂度、一开始需求有多清晰、预计会有多少变更、风险、团队，以及期限。
The examiner's list for the purpose of a development life cycle: it breaks a large project into stages that can be planned and managed; it makes sure the requirements are found and agreed before design and coding begin; it builds in testing and documentation rather than leaving them to the end; and it lets the work be divided between people with a known order of dependencies.
考官关于「开发生命周期的目的」的清单是： 它把一个大项目拆成可以计划和管理的阶段； 它保证需求在设计和编码开始之前就被找出来并达成一致； 它把测试和文档编写内建进流程，而不是留到最后； 而且它让工作可以在多人之间分配，依赖关系的先后是已知的。
The waterfall model is a linear sequence — analysis, design, coding, testing, maintenance — and each stage is finished before the next begins.
瀑布模型是一条线性的序列——分析、设计、编码、测试、维护—— 每个阶段都要全部完成，下一个才开始。
Its strengths are that it is clear and well-documented, and it works well when the requirements are stable and known from the start.
它的长处是清晰、文档完备， 而且在需求稳定、一开始就明确的情况下效果很好。
Its two weaknesses are what exams ask for.
它的两个短处正是考试要问的。
It copes badly with mid-project change, because going back means unwinding finished stages.
它很难应对项目中途的变更，因为回头就意味着把已经做完的阶段拆开重来。
And the customer sees nothing working until the very end, so a misunderstanding at the analysis stage stays hidden until it is expensive.
而且客户直到最后才看得到能运行的东西，所以分析阶段的一个误解会一直隐藏着， 直到代价高昂时才暴露。
The iterative model makes repeated passes, each producing a partial working version that gets reviewed and refined.
迭代模型进行多轮反复，每一轮都产出一个能运行的部分版本，供评审和改进。
That catches problems earlier and suits projects where the requirements are discovered over time — but it is harder to estimate, because you do not know at the start how many passes you will need.
这样能更早发现问题，适合那些需求是逐步摸清楚的项目—— 但它更难估算工期，因为你一开始并不知道需要多少轮。
Rapid application development goes further, leaning heavily on a prototype and constant user feedback, with parts built in parallel.
快速应用开发走得更远，它大量依赖原型和持续的用户反馈，各个部分并行开发。
It delivers something very fast and copes well with changing requirements, but it depends on users being available throughout, and it suits smaller systems rather than large ones.
它能非常快地交付出东西，也很能适应变化的需求， 但它依赖用户全程都能配合，而且适合较小的系统，不适合大型系统。
Agile is the fourth model on the syllabus.
敏捷是考纲上的第四种模型。
It works in short iterations called sprints, each producing something that works, with constant collaboration and testing throughout rather than a testing phase at the end.
它以称为冲刺的短迭代来工作，每一轮都产出能运行的东西， 而且全程都在持续协作和测试，而不是把测试留成最后一个阶段。
Its strength is that it is flexible and adaptive — a change in requirements is normal rather than a crisis.
它的长处是灵活、适应性强——需求变化在这里是常态，而不是危机。
Its cost is that it needs a committed customer who is available continuously, and a skilled team, because there is far less written specification to fall back on.
它的代价是需要一位全程都能配合的、投入的客户，还需要一支水平高的团队， 因为可供依靠的书面规格说明少得多。
No single approach fits every project, so teams pick a model.
没有哪一种做法适合所有项目，所以团队会挑一个模型。
The waterfall model runs the stages in a straight line — each finished before the next.
瀑布模型让各个阶段排成一条直线—— 每一个都要在下一个开始前完成。
It is clear and well-documented, but poor at coping with change, and the customer sees nothing working until the very end.
它清晰、文档完善，但不擅长应对变化， 而且客户直到最后才看得到能运行的东西。
The iterative and agile models instead work in repeated passes, each producing a working version to review and refine.
迭代模型和敏捷模型则采用反复的多轮迭代， 每一轮都产出一个可运行的版本，供审阅和改进。
They handle changing requirements far better, but are harder to plan.
它们对付需求变化要好得多，但更难做计划。
State the principle, one benefit and one drawback for each, because that is exactly how the scheme lists them.
每一种都要说出原理、一个优点和一个缺点，因为评分标准就是这么列的。
Waterfall: the stages run in a fixed order, each signed off before the next starts — simple to manage and fully documented, but inflexible once a stage is finished and there is no working software until late.
瀑布模型：各阶段按固定顺序进行，前一阶段签收后才开始下一阶段—— 管理简单、文档完整，但一旦某个阶段完成就很难改动，而且很晚才有可运行的软件。
Iterative: a small working version is built first and repeatedly improved — working software early and often, and the customer's feedback shapes each version, but the total time and cost are hard to estimate.
迭代模型：先做出一个小的可运行版本，然后反复改进—— 很早就有可运行软件而且不断更新，客户的反馈会影响每一个版本， 但总的时间和成本很难估算。
R A D: prototypes of parts are built quickly and refined with the user until accepted — very fast first delivery and the user is involved throughout, but it needs skilled developers and committed users, and the documentation suffers.
快速应用开发：快速做出局部的原型，和用户一起打磨到被接受为止—— 第一版交付非常快，用户全程参与， 但它需要有经验的开发者和投入的用户，而且文档质量会打折扣。
Two design tools are named in the syllabus, and this is the first.
考纲上点名了两种设计工具，这是第一种。
A structure chart shows the hierarchical decomposition of a program into modules — subroutines — and, crucially, the parameters passed between them.
结构图展示的是一个程序如何被层次化地分解成 模块，也就是子程序，而且关键在于，它还标出模块之间传递的参数。
Each module is a rectangle.
每个模块是一个矩形。
A line links a caller above to the module it calls below.
一条线把上面的调用者连到它所调用的下面的模块。
The small arrows on those lines carry the data: one direction for values going down into the module, the other for results coming back up.
线上那些小箭头承载着数据：一个方向表示传进模块的值，另一个方向表示返回的结果。
Here Convert temperature calls INPUT, Convert to Celsius and OUTPUT, with the temperature travelling along the links.
这里"转换温度"调用了输入、转换为摄氏和输出三个模块，温度就沿着这些连线传递。
And here is what makes it useful in an exam: you can read the procedure signatures straight off it, then write the matching pseudocode.
而它在考试中好用的地方在于：你可以直接从图上读出各个过程的签名，再写出对应的伪代码。
The symbols the examiner asks about, one at a time.
考官会问的那些符号，一个一个来。
A box is a module.
方框是一个模块。
A line links a caller above to the modules it calls below, read left to right in the order they are called.
连线把上面的调用者和下面被它调用的模块连起来，从左到右按调用顺序读。
A small arrow with an open circle at its tail is a data couple — a parameter passed down into a module, or a value returned up.
尾部带空心圆的小箭头是数据耦合—— 向下传进模块的参数，或者向上返回的值。
An arrow with a filled circle is a control couple: a flag, usually boolean, that tells the caller what happened.
带实心圆的箭头是控制耦合：一个标志，通常是布尔型，告诉调用者发生了什么。
A diamond at a branch means selection — only one of the modules below it is called, depending on a condition.
分叉处的菱形表示选择——根据条件，下面的模块只有一个会被调用。
And a curved arrow sweeping across the links means iteration: the modules under it are called repeatedly in a loop.
而横扫过这些连线的弧形箭头表示迭代：它下面的模块会在循环中被反复调用。
The second design tool is the state-transition diagram, and it answers a different question: not how the program is built, but how it behaves over time.
第二种设计工具是状态转换图，它回答的是另一个问题：不是程序怎么搭起来的， 而是它随时间如何表现。
Each state the system can be in is a circle; each transition is an arrow labelled with the event that causes it.
系统可能处的每一个状态是一个圆圈； 每一次转换是一个箭头，上面标着引发它的事件。
This one is a door lock with the code two-five-nine: from Locked, the correct digit moves you along, and a wrong digit sends you back.
这一张是密码为二五九的门锁： 从"已锁定"出发，输对一位就往前走一步，输错一位就退回去。
It suits anything with modes — vending machines, traffic lights, user interfaces.
它适合任何有模式切换的东西——自动售货机、红绿灯、用户界面。
And its real value is what it makes visible: missing transitions leap out.
而它真正的价值在于它让什么变得可见：缺失的转换会一眼跳出来。
What happens if a second coin goes in while the machine is awaiting a selection?
如果机器正在等待选择时又投进一枚硬币，会怎么样？
If no arrow answers that, the design has a hole.
要是没有箭头回答这一点，设计就有漏洞。
Reading and drawing one: a circle is a state the system can be in, an arrow from one circle to another is a transition, and the label on the arrow is the event that causes it, with any condition or output written alongside.
读和画一张状态转换图： 圆圈是系统可能处于的一个状态，从一个圆到另一个圆的箭头是一次转换， 箭头上的标签是引发它的事件，条件和输出写在旁边。
Read it by following the arrows from the starting state; draw one by listing the states first, then asking which event moves the system out of each.
读的时候从起始状态沿着箭头走； 画的时候先把状态列出来，再逐个问：哪个事件会让系统离开这个状态。
When a program goes wrong, the fault is one of three kinds.
当程序出错时，毛病无非是三种之一。
A syntax error breaks the language's grammar — a missing bracket — so the program won't even translate.
语法错误违反了语言的语法——比如少了一个括号—— 于是程序连翻译都通不过。
A run-time error strikes while running — dividing by zero, or a missing file — and the program crashes.
运行时错误在运行途中发作——除以零，或者找不到文件——程序就崩溃了。
A logic error is the sneakiest: the program runs fine, but gives the wrong answer.
逻辑错误最阴险：程序运行得好好的，却给出错误的答案。
It leaves no error message, so only careful testing reveals it.
它不留下任何错误提示， 所以只有仔细的测试才能揭露它。
The cleanest way to hold the three error types apart is to ask WHEN each one shows up.
要把三种错误分清楚，最干净的办法是问：每一种是在什么时候暴露出来的。
Follow the pipeline: you write code, it gets translated, it runs, it produces output.
顺着这条流水线看：你写代码，代码被翻译，程序运行，产生输出。
A syntax error stops it at translation — the program never runs at all, so you find out immediately.
语法错误在翻译时就把它拦住了——程序根本跑不起来，所以你立刻就会知道。
A run-time error gets past translation and crashes during the run: divide by zero, file not found, array index out of range.
运行时错误能通过翻译，却在运行途中崩溃：除以零、文件找不到、数组下标越界。
And a logic error passes translation, runs to completion without complaint, and gives you the wrong output.
而逻辑错误既通过了翻译，又顺顺当当跑完全程，然后给你一个错误的输出。
That is why it is the hardest of the three: nothing tells you it happened except the answer being wrong.
这正是它三者中最难对付的原因：除了答案不对，没有任何东西告诉你它发生了。
Exposing and avoiding faults are two different lists, and questions ask for one or the other.
「暴露缺陷」和「避免缺陷」是两份不同的清单，题目会指定问哪一份。
Faults are exposed by testing against a test plan, by a dry run or trace table, by a walkthrough with colleagues, and by the IDE's debugger.
缺陷通过以下方式被暴露：按测试计划测试、手工跟踪或者用跟踪表、 和同事一起走查代码，以及使用集成开发环境的调试器。
They are avoided by designing before coding — a structure chart and pseudocode — by modular code with meaningful identifiers and comments, by validation of every input, and by handling exceptions rather than letting a run-time error stop the program.
缺陷通过以下方式被避免：先设计后编码——结构图和伪代码—— 模块化的代码配上有意义的标识符和注释、 对每一个输入做验证， 以及处理异常而不是让运行时错误直接把程序停掉。
Now the named testing methods, because a question will ask for one by name.
现在讲那些有名称的测试方法，因为题目会点名要某一种。
A dry run means tracing the code on paper, writing each variable's value into a table as you go.
手工跟踪的意思是在纸上追踪代码， 一边走一边把每个变量的值填进一张表里。
A walkthrough is a team review of the code.
走查是团队对代码的评审。
White-box testing is designed from the code's internal structure, aiming to cover every statement, every branch and every loop.
白盒测试是依据代码的内部结构来设计的，目标是覆盖每一条语句、每一个分支、每一个循环。
Black-box testing is designed from the specification alone — feed in inputs, check the outputs, never look at the code.
黑盒测试只依据规格说明来设计——喂进输入，检查输出，从不看代码。
Integration testing combines modules and tests the interfaces between them, which is where mismatched assumptions surface.
集成测试把模块组合起来，测试它们之间的接口，那里正是各方假设不一致会暴露的地方。
And a stub is a placeholder standing in for a module that does not exist yet, so the overall structure can be tested top-down before every part is written.
而桩是一个占位符，代替尚未写出来的模块，好让整体结构能够自顶向下地先测起来， 不必等每一部分都写完。
Three more are about WHO tests, and they come in order.
还有三种讲的是谁来测，而且是按顺序来的。
Alpha testing is done by the developers themselves, in-house, before release.
α 测试由开发人员自己做，在公司内部，发布之前。
Beta testing is done by a limited group of real users, in their own environment, on their own machines — which finds the problems no office ever reproduces.
β 测试由一小群真实用户来做，在他们自己的环境里、自己的机器上—— 这能发现办公室里永远重现不出来的问题。
Acceptance testing is done by the customer, and it has a different purpose entirely: not to find bugs, but to decide whether the product is fit for purpose and they will accept it.
验收测试由客户来做， 而它的目的完全不同：不是为了找出缺陷，而是判断这个产品是否适合用途、他们是否接受。
If you are asked to distinguish these, the answer is always who does it, and where.
如果题目要你区分这三者，答案永远是：谁来做，在哪里做。
Two terms that sound alike and are examined on the difference.
有两个术语听起来很像，而考的正是它们的区别。
A test strategy is the high-level approach: which kinds of testing you will do, who does them, when, and the criteria for moving on to the next stage.
测试策略是高层的方针： 你要做哪几类测试、由谁来做、什么时候做，以及进入下一阶段的判定标准。
A test plan is the detailed list of tests themselves — each one with its input data, its expected output, and an actual-output column to fill in when you run it.
测试计划则是那些测试本身的详细清单——每一条都带着输入数据、预期输出， 以及一栏留着运行时填写的实际输出。
Strategy is the policy; plan is the table.
策略是政策，计划是表格。
And that actual-output column matters: a test plan without it records what you intended to do, not what happened.
而那一栏实际输出很重要：没有它的测试计划记录的是你打算做什么，而不是实际发生了什么。
What each contains, precisely.
两者各包含什么，说准确。
A test strategy states which testing methods will be used at which stage — module testing by the programmer, then integration, alpha, beta, acceptance — who is responsible for each, what test data is required, and the criteria for passing to the next stage.
测试策略说明在哪个阶段使用哪些测试方法—— 程序员做的模块测试，然后是集成测试、内测、公测、验收测试—— 每一项由谁负责、需要哪些测试数据，以及进入下一阶段的标准。
A test plan lists the individual tests: for each one the module or feature under test, the input data, the reason that data was chosen — normal, abnormal, extreme or boundary — the expected result, a space for the actual result, and what to do if they differ.
测试计划列出一个个具体的测试： 每一个都写明被测的模块或功能、输入数据、 选这组数据的理由——正常、异常、极端还是边界—— 预期结果、填写实际结果的位置，以及两者不一致时怎么办。
The plan is written at the design stage, from the specification, so that it tests what the program should do rather than what it happens to do.
测试计划是在设计阶段、根据规格说明书写出来的， 这样它测的是程序「应该」做什么，而不是它「碰巧」做了什么。
Good testing needs the right test data.
好的测试需要正确的测试数据。
Say a field accepts a mark from zero to one hundred.
假设有一个字段，接受零到一百的分数。
Normal data is a typical value inside the range, like fifty.
正常数据是范围之内的典型值， 比如五十。
Extreme data is the largest and smallest values still accepted — zero and one hundred, sitting right on the boundary.
极端数据是仍然被接受的最大值和最小值——零和一百，正好落在边界上。
Abnormal data should be rejected — minus ten, two hundred, or letters.
异常数据应该被拒绝——负十、两百，或者字母。
And every test must carry its expected result, or it proves nothing.
而每一个测试都必须带上它的预期结果， 否则它什么也证明不了。
Let us do the classic one.
我们来做那道最经典的题。
A field accepts an exam mark from zero to one hundred.
某个字段接受零到一百的考试分数。
Give test data of each kind.
给出每一类的测试数据。
Normal data is a typical value inside the range — fifty, accepted.
正常数据是范围内的典型值——五十，应当被接受。
Abnormal data should be rejected: minus ten, two hundred, or the text "abc", which is the wrong type entirely.
异常数据应当被拒绝： 负十、二百，或者文字"abc"，那根本就是错误的类型。
Extreme data is the largest and smallest values that are still ACCEPTED — zero and one hundred.
极端数据是仍然会被接受的最大值和最小值——零和一百。
Now the pair everyone confuses.
现在说说人人都会弄混的那一对。
An extreme value sits inside the range and is accepted.
极端值位于范围之内，是被接受的。
But boundary data is always a pair, straddling the edge: minus one rejected alongside zero accepted, and one hundred accepted alongside one hundred and one rejected.
而边界数据永远是成对的，跨在边缘两侧： 负一被拒绝，与之相对的零被接受；一百被接受，与之相对的一百零一被拒绝。
That is exactly where an off-by-one error hides.
那里正是差一错误藏身的地方。
And whatever you write, every value must carry its expected result, or the test plan proves nothing at all.
而且不管你写什么，每一个值都必须带上它的预期结果， 否则这份测试计划什么也证明不了。
After release comes maintenance — most of a program's lifetime cost.
发布之后就是维护——它占了一个程序一生中的大部分成本。
There are three kinds.
维护有三种。
Perfective: improving it even though it works, adding a feature or making it faster.
完善性维护：即使程序能用也去改进它，加一个功能，或让它更快。
Adaptive: keeping it working as the world changes — a new operating system, or a new law.
适应性维护： 在世界发生变化时让它继续能用——一个新的操作系统，或一条新的法规。
And corrective: fixing the bugs that users find.
纠正性维护： 修复用户发现的漏洞。
A long-lived program needs all three.
一个长命的程序，这三种都需要。
Why each is needed, with the reasons the mark scheme lists.
每一类为什么需要，用评分标准列出的理由。
Corrective: a fault is reported by a user after release, or a wrong output is noticed in circumstances the testing did not cover.
纠正性维护：发布之后用户报告了一个故障， 或者在测试没有覆盖到的情形下出现了错误的输出。
Adaptive: the operating system, hardware or browser is upgraded, a law or company rule changes, or the program must work with a new external system or file format.
适应性维护：操作系统、硬件或者浏览器升级了， 法律或者公司规定变了， 或者程序必须和一个新的外部系统或文件格式配合工作。
Perfective: users ask for extra features or a better interface, the program is made faster or made to use less memory, or the code is tidied to make future changes easier.
完善性维护：用户要求增加功能或者改进界面， 程序被优化得更快或者更省内存， 或者代码被整理过，让以后的修改更容易。
Finally, the routine for changing code somebody else wrote — six steps, and exams do ask for them in order.
最后是修改别人写的代码的流程——六个步骤，而考试确实会要求你按顺序说出来。
One: read the existing code until you actually understand the algorithm and the data flow.
第一，通读现有代码，直到你真正理解了算法和数据流向。
Two: find where the change goes — which subroutine, which lines.
第二，找到改动该放在哪里——哪个子程序，哪几行。
Three: make the change as small as possible; do not rewrite working code because you would have written it differently.
第三，把改动做到尽可能小；不要因为你会写得不一样，就去重写本来能用的代码。
Four: update related parts — every caller of a parameter list you changed, every routine that touches a data structure you changed.
第四，更新相关的部分——凡是调用了你改过的参数表的地方， 凡是用到你改过的数据结构的例程。
Five: test the new behaviour AND the old.
第五，既测试新行为，也测试旧行为。
That second half is regression testing, and it is the step that catches what you broke elsewhere.
后半句就是回归测试，正是这一步能抓出你在别处弄坏了什么。
Six: document the change.
第六，把这次改动记录下来。
And notice why the design tools from earlier still matter: clear comments, meaningful names, decomposed subroutines and a structure chart are what make step one possible at all.
再注意前面那些设计工具为什么依然重要：清晰的注释、有意义的命名、 分解好的子程序和一张结构图，正是它们让第一步成为可能。
Analysing a program you did not write: start from the identifier table and the module headers, because they tell you what each module receives and returns before you read a line of its body.
分析一个不是你写的程序： 先从标识符表和模块头部入手， 因为在你读任何一行函数体之前，它们就告诉了你每个模块接收什么、返回什么。
Then trace the algorithm with a trace table for one small input, noting where each output value comes from.
然后用一个小的输入，借助跟踪表把算法走一遍， 记下每一个输出值是从哪里来的。
Only then change anything.
做完这些，才动手改。
Three marks to lock in.
三个要拿稳的分。
First, know the life cycle stages, and compare the models — waterfall versus iterative.
第一，记住生命周期的各个阶段，并比较各种模型——瀑布与迭代。
Second, tell apart the three errors: syntax at translation, run-time during the run, logic in the wrong output.
第二，把三种错误分清楚：语法错误在翻译时，运行时错误在运行中，逻辑错误在错误的输出里。
Third, give test data of three kinds — normal, boundary, and erroneous — each with its expected result.
第三，给出三种测试数据——正常、边界和错误——每一个都带上它的预期结果。
Nail these, and this topic is yours.
掌握这些，这个专题就是你的了。
The fixed-wording definitions, one answer only.
固定措辞的定义，只给一个答案。
A development life cycle is the sequence of stages, from analysis to maintenance, followed to produce and support a program.
开发生命周期，是从分析到维护、为生产和支持一个程序而遵循的一系列阶段。
The waterfall model carries out the stages in a fixed order, each completed before the next begins.
瀑布模型按固定顺序执行各阶段，前一个完成之后才开始下一个。
The iterative model produces a working version and then repeatedly refines it until complete.
迭代模型先做出一个可运行的版本，然后反复改进直到完成。
Rapid application development builds prototypes quickly and refines them with user feedback until they are accepted.
快速应用开发快速构建原型，并根据用户反馈打磨，直到被接受。
A structure chart shows how a program is decomposed into modules, the order in which they are called and the parameters passed between them.
结构图展示程序如何被分解成模块、模块的调用顺序，以及它们之间传递的参数。
A state-transition diagram shows the states a system can be in and the inputs that cause it to move between them.
状态转换图展示系统可能处于的各个状态，以及使它在状态之间转移的输入。
And the mistakes that lose marks every year.
再说每年都在丢分的那些错误。
Do not describe a stage by its name — "in the design stage the program is designed" earns nothing; say what is produced: the structure chart, the pseudocode, the test plan.
不要用阶段的名字来描述阶段—— 「在设计阶段，程序被设计出来」一分不给； 要说这一阶段产出什么：结构图、伪代码、测试计划。
A wrong output from a program that runs to the end is a LOGIC error, not a run-time error.
一个能跑到结尾却输出错误的程序，那是逻辑错误，不是运行时错误。
Boundary data means the values on BOTH sides of the edge, not just the extremes.
边界数据指的是边界两侧的值，不是只有极端值。
Alpha testing is in-house by the developers, beta testing is by real users outside — they are not the same.
内测是开发者在公司内部做的，公测是外部真实用户做的——两者不一样。
Adaptive maintenance responds to a change OUTSIDE the program; perfective improves a program that nobody had to change.
适应性维护是对程序之外的变化作出反应； 完善性维护改进的是一个本来不需要改的程序。
And in a structure chart the modules read left to right in the order they are called, with an arrow for every parameter.
另外在结构图里，模块从左到右按调用顺序排列，每个参数都要有自己的箭头。