小型应用程式专题

进阶

专题四步曲:需求分析 → 设计 → 编写 → 测试。设计时先定资料结构(字典)同函式分工(加分、统计、存档);测试要涵盖正常输入和极端输入(文字当分数、空字典、重复姓名)。

适合:中三资讯及通讯科技 · 单元:程式设计进阶 · 建议学习路径第 4/13 课

学完呢课,你会识:
  • 专题四步曲:需求分析 → 设计 → 编写 → 测试,次序不可乱。
  • 设计先定两件事:资料结构(字典:姓名→分数)和函式分工(每个函式只做一件事)。
  • 选单配 while 回圈;记住 input 回传字串,比较时要写 == "1"。
文体:专案指南课有声朗读

文体小知识:专案指南课由企划到评估逐步带你完成整个制作,适合接著做小组功课和比赛作品。

资讯及通讯科技Information & Communication Technology

§课文原文 Passage

1写一个真正的程式,不是一坐下就打代码。专业流程有四步:需求分析(搞清楚要做什么、给谁用)→ 设计(计划资料结构、函式分工、介面样式)→ 编写(分段写、一边写一边试)→ 测试(正常情况、极端情况都要试)。跳过前两步,之后几乎一定会推倒重来。

2以示范专案「成绩记录器」为例。需求分析:同学想用一个程式记录各科测验分数,可以随时加入新分数、查看平均与最高分,关掉程式后资料仍然保留。这三句就是需求 — 每一项之后都要在测试时逐一验证。

3设计阶段:资料结构选字典 grades = {"小明": 85, "Mary": 90},键是姓名、值是分数;函式分工为 add_score() 加分、show_stats() 显示统计、save() 存档、load() 读档;主程式用 while 回圈显示选单,让用户输入 1 至 4 选功能。设计划在纸上,写代码时就不会迷失方向。

4编写与测试:每次只写一个函式,写完立即试用,确保无误才写下一个。测试时要问三个问题:正常输入对不对(85 和 90 的平均是 87.5)?极端输入会怎样(输入 "abc" 当分数、姓名重复、字典空时计平均)?资料存档后重新载入是否一模一样?全部通过,专案才算完成。

1重点摘要 Summary

专题四步曲:需求分析 → 设计 → 编写 → 测试。设计时先定资料结构(字典)同函式分工(加分、统计、存档);测试要涵盖正常输入和极端输入(文字当分数、空字典、重复姓名)。

2生字卡 Vocabulary

R
Requirements analysis需求分析

确定程式要做什么、给谁用的阶段,产出清晰的功能清单。

D
Design设计

计划资料结构、函式分工和介面样式,作为编写前的蓝图。

I
Implementation编写实作

按设计逐个函式把代码写出来,一边写一边试的阶段。

T
Testing测试

用正常和极端输入验证程式是否合乎需求的阶段。

M
Menu选单

列出功能编号让用户选择的介面,配合 while 回圈反复显示。

I
Input validation输入验证

检查用户输入是否合理(例如分数必须是数字),不合理就提示重输。

M
Modular design模组化设计

把程式拆成各司其职的小函式,容易编写、测试和修改。

B
Boundary case边界情况

最容易被忽略的极端情况,例如空清单、零分、重复姓名。

D
Documentation文件说明

记录程式的功能、用法和设计决定,方便他人和未来的自己理解。

3逐步讲解 Steps

  1. 专题开发的第一步:需求清单写真正的程式不是一开机便打代码。专业流程的第一步是写需求清单:把程式要做的事逐条写下,每条一句。以「成绩记录器」为例:一,可以加入学生姓名和分数;二,可以显示平均分和最高分;三,关闭程式后资料仍在。三条需求之后会逐条验收,未完成的便未算完工。需求写得清楚,后面的设计与测试才有依据;跳过这一步,写到一半往往发现功能遗漏,要推倒重来。
  2. 选定资料结构第二步按需求选定资料结构。成绩记录器需要「以姓名查分数」,字典正合适:grades = {"小明": 85, "Mary": 90},姓名做键、分数做值。加入记录即 grades["阿强"] = 78;查询即 grades["小明"];统计之前用 grades.values() 取出全部分数。若需求是「依先后次序记录事件」,便该选清单;「以姓名查电话」选字典。资料结构选对,之后每个功能都顺手;选错则处处受阻。
  3. 函式分工第三步把工作分配给函式,每个函式只做一件事:add_score(grades, name, score) 负责加入记录;show_stats(grades) 负责计算并显示平均与最高分;save(grades) 与 load() 负责存档读档。单一职责的好处有二:出错时能迅速定位是哪个函式的问题;想修改计算平均的方法,只需改动 show_stats 一处。函式之间以参数传递资料、以 return 交回结果,主程式只负责调度指挥。
  4. 主选单回圈与输入主程式用 while True: 建立选单回圈:先 print("1 加分 2 统计 3 离开"),再 choice = input("请选择:"),其后 if choice == "1": 加入分数,elif choice == "3": break 跳出。关键细节:input() 传回的是字串,"1" 不是数字 1,比较时必须写 choice == "1";若要当数字使用,须以 int(choice) 转换。忘记这一点是新手最常见的错误,程式会对输入 1 毫无反应,令人一头雾水。
  5. 输入验证:防呆设计用户不一定照规矩输入。若用户在分数栏输入 "abc",int(text) 会报错令程式崩溃。解法用 try/except:text = input("分数:") 之后,try: score = int(text) except ValueError: print("请输入数字") 并 continue 回到选单。这样程式遇到非法输入只提示、不崩溃。专业软件与游戏的防呆设计,全部源自这个思想:假设用户会出错,预先挡住,体验才会顺畅。
  6. 测试正常与极端情况测试分两类。正常情况:加入 85 与 90 之后选统计,期望平均 87.5、最高 90;把期望值预先写在纸上,跑完逐项核对。极端情况:不输入任何分数便看统计,空字典会除以零出错,必须先判断 len(grades) == 0;输入重复姓名,程式应更新而非重复记录;存档之后关闭程式再重开,资料必须一模一样。极端情况最能揭发隐藏错误,正式交付之前必须逐项通过。
  7. 专题的完成标准专题完成的标准不是「程式能跑」,而是三问全部通过:正常输入结果正确吗?极端输入会否崩溃?资料存档重载是否一致?此外宜回看需求清单逐条打勾。过程中「每次只写一个函式,写完立即试用」的纪律,能把除错范围缩到最小;一口气写完全部才测试,错误会互相纠缠。这套「需求、设计、分段编写、双向测试」的流程,适用于往后任何编程专题。

4图解 Diagrams

多媒体专题:五步由零到成品 Project steps1定主题目标观众系边个2写脚本故事版 storyboard3收集素材相・声・片(版权!)4制作整合剪辑5测试发布人哋睇得明吗最常见死因:冇脚本就开工——做到一半先知缺素材、次序乱分工贴士(小组):一人脚本一人素材一人剪辑——同步沟通最紧要完成后自查:讯息清楚?音量适中?有冇错字?播放流畅?
图 1:多媒体专题五步

5例题示范 Example

例题:为成绩记录器编写 show_stats(grades) 函式,输出平均分与最高分,并以 grades = {"小明": 85, "Mary": 90, "阿强": 78} 演示。

  1. 先挡空字典:if len(grades) == 0: print("暂无记录") 后 return,避免除以零。
  2. 取出分数:scores = list(grades.values()),得 [85, 90, 78]。
  3. 计算统计:average = sum(scores) / len(scores) = 253 ÷ 3 ≈ 84.33;highest = max(scores) = 90。
  4. 输出:print("平均分", round(average, 1), "最高分", highest),画面显示平均分 84.3 最高分 90。
  5. 补充测试:以空字典 {} 呼叫一次,确认显示「暂无记录」而非报错。
  6. 答案:show_stats 先挡住空字典,再由 [85, 90, 78] 算出平均 84.3 分与最高 90 分并印出。要点是防御式开头(检查空字典)与以 round 控制小数位。

6常见错误 Mistakes

✗ 「一开始就打代码,一边写一边想做什么。」
✓ 没有需求分析和设计,写到一半才发现功能错漏,往往要推倒重来;先花十分钟计划,之后省几小时。
✗ 「全部代码塞在一大段里最方便。」
✓ 拆成小函式(加分、统计、存档各自独立),出错时容易定位,修改时不会牵一发动全身。
✗ 「用户一定会输入数字,不用检查。」
✓ 真实用户什么都会打:"abc"、负数、空白。加入 try-except 和范围检查,程式才耐用。
✗ 「资料存在变数里就好,关掉再重新输入。」
✓ 变数随程式结束消失;用 open("grades.txt", "w") 存档、开程式时 load() 读回,资料才长期保留。
✗ 「正常情况对了就完成,不用测极端情况。」
✓ 空字典计平均、重复姓名、分数 0 分这些边界情况最容易出错;专业测试两类都要覆盖。

75 题快测 Quick check

Q1小型应用程式开发的正确次序是?A. 编写→测试→设计→需求分析 B. 需求分析→设计→编写→测试 C. 设计→编写→需求分析→测试

Q2成绩记录器中,grades = {"小明": 85, "Mary": 90},grades["阿强"] = 78 之后,len(grades) 是多少?

Q3用户输入分数时打了 "abc",哪种写法可以令程式不崩溃?

Q4grades 是空字典时呼叫 show_stats() 计平均会出什么问题?应该怎样处理?

Q5写出测试成绩记录器的任何三项检查。

8重点回顾 Recap

  • 专题四步曲:需求分析 → 设计 → 编写 → 测试,次序不可乱。
  • 设计先定两件事:资料结构(字典:姓名→分数)和函式分工(每个函式只做一件事)。
  • 选单配 while 回圈;记住 input 回传字串,比较时要写 == "1"。
  • 输入验证用 try-except 接住 ValueError,程式遇到错误输入不崩溃。
  • 测试要涵盖正常和极端情况:空字典、重复姓名、存档重载都要逐一验证。

同级其他科

同一科其他级别