📚 Practical Assessment Guide for Cambridge Pre-U Computer Science (Paper 3) | 剑桥Pre-U 计算机科学实验考核要点与实操指南
The practical component of Cambridge Pre-U Computer Science (CAIE) requires candidates to undertake an individual programming project that demonstrates computational thinking, problem-solving, and software development skills. Unlike the written papers, this assessment emphasises the entire lifecycle of a solution — from identifying a suitable problem and analysing requirements through to implementation, testing, and critical evaluation. Success depends not only on writing correct code but also on producing clear design documentation, following sound programming conventions, and reflecting on the quality of the final product.
剑桥 Pre-U 计算机科学（CAIE）的实践考核要求考生独立完成一个编程项目，以展示计算思维、问题解决和软件开发能力。与笔试不同，该考核覆盖解决方案的完整生命周期——从识别合适的问题、分析需求，到实现、测试以及批判性评价。成功不仅取决于编写正确的代码，还在于生成清晰的设计文档、遵循良好的编程规范并对最终成果的质量进行反思。
1. Understanding the Practical Assessment | 理解实践考核结构
The practical paper (Paper 3) is an internally assessed, externally moderated coursework component typically carrying 40% of the total Pre-U marks. Candidates must submit a complete project folder containing their source code, executable if applicable, and a well-structured report that includes analysis, design, testing and evaluation. The assessment objectives reward original thinking, appropriate use of advanced techniques, and thorough documentation at every stage.
实践试卷（Paper 3）是内部评估、外部审核的课程作业，通常占 Pre-U 总成绩的 40%。考生须提交完整的项目文件夹，包括源代码、可执行文件（如适用）以及结构清晰的报告，报告须涵盖分析、设计、测试和评价。评分目标鼓励原创思维、合理运用高级技术，并要求各阶段文档详尽。
Teachers are responsible for supervising the project, ensuring that the work remains the candidate’s own, and marking it against the published assessment criteria. The report should make clear what third-party resources (e.g., libraries or code snippets) have been used and how they are integrated. Understanding the marking grid helps you to prioritise activities: a robust design and reflective evaluation often carry equal weight to the code itself.
教师负责监督项目、确保作品为考生本人完成，并依据官方评分标准进行打分。报告应清楚说明使用了哪些第三方资源（如库或代码片段）以及如何集成。了解评分矩阵有助于合理安排工作重心：扎实的设计和反思性评价往往与代码本身具有同等权重。
2. Choosing and Scoping the Project | 项目选题与范围界定
Select a topic that genuinely interests you and allows you to demonstrate a range of technical skills — for instance, a booking system, an educational game with persistent scores, or a data visualisation tool using an API. The problem must be sufficiently complex to meet the Pre-U criteria, but not so ambitious that it cannot be completed within the available time. A well-scoped project typically involves a GUI, file or database handling, sorting/searching, and user input validation.
选择一个真正感兴趣且能展示多种技术技能的主题，例如预约系统、带有积分存储的教育游戏或使用 API 的数据可视化工具。问题须具备足够复杂性以满足 Pre-U 标准，但不宜过于庞大以至于无法在可用时间内完成。界定得当的项目通常涉及图形用户界面、文件或数据库处理、排序/搜索以及用户输入验证。
Write a concise proposal stating the problem, the intended users, and the key functional requirements. Seek approval from your teacher early; this prevents later changes of direction that could jeopardise deadlines. The scope must be clear: what the software will and will not do. Too many features often lead to shallow implementation; a deeper treatment of fewer features is more highly rewarded.
撰写一份简明提案，陈述问题、目标用户和关键功能需求。尽早寻求教师批准，这可以避免日后改变方向导致无法按时完成。范围必须清晰：软件能做到什么，不做什么。功能过多往往导致实现肤浅；对少数功能进行深度处理反而得分更高。
3. Problem Analysis and Requirements Specification | 问题分析与需求规格
Begin by breaking down the problem into manageable sub-problems. Use context diagrams and data flow analysis to show how data enters and leaves the system. For each sub-problem, identify the inputs, processes, and outputs. This decomposition forms the backbone of your design and demonstrates analytical rigour.
首先将问题分解为可管理的子问题。使用上下文图和数据流分析展示数据如何进出系统。对每个子问题明确输入、处理和输出。这种分解构成设计的主干，并展现分析的严谨性。
Requirements should be categorised as functional (what the system does, e.g., ‘search for a student record’) and non-functional (constraints such as response time, usability, and security). Number each requirement so it can be traced through the design and testing sections. A clear requirements table, perhaps with MoSCoW prioritisation, gives structure to later planning and evaluation.
应将需求分为功能性需求（系统做什么，如“搜索学生记录”）和非功能性需求（如响应时间、可用性和安全性等约束）。为每项需求编号，以便在设计、测试部分进行追踪。一张清晰的需求表（或许附 MoSCoW 优先级）可为后续规划和评价提供结构。
4. Algorithm Design and Pseudocode Conventions | 算法设计与伪代码规范
Translate the core processes into step-by-step algorithms illustrated with pseudocode. The CAIE syllabus encourages a clear, readable pseudocode style using consistent indentation, meaningful variable names, and standard control structures (IF-ENDIF, WHILE-ENDWHILE, FOR loops). Avoid language-specific constructs; the pseudocode should be understandable even by someone not familiar with your chosen programming language.
将核心过程转化为逐步的算法并用伪代码说明。CAIE 大纲鼓励清晰可读的伪代码风格：统一缩进、有意义的变量名以及标准控制结构（IF-ENDIF、WHILE-ENDWHILE、FOR 循环）。避免特定语言的结构，伪代码应能被不熟悉你所选编程语言的人理解。
For each key module, include the pseudocode alongside a flowchart or structure diagram. Explain any non-trivial algorithmic choices, such as why binary search is preferred over linear search for a sorted list, and justify the time complexity using Big O notation (e.g., O(log n)). This shows awareness of efficiency and theoretical underpinning.
对每个关键模块，在伪代码旁附上流程图或结构图。对任何非平凡的算法选择加以解释，例如为什么对有序列表用二分查找优于线性查找，并用大 O 表示法（如 O(log n)）说明时间复杂度。这表现出对效率与理论基础的关注。
5. Data Structures and File Handling | 数据结构与文件处理
The project often requires persistent storage. Decide whether to use flat text files, CSV, JSON, or a relational database (e.g., SQLite). Justify your choice based on the data volume, query needs, and concurrency requirements. For file handling, demonstrate secure reading/writing and effective error handling — for example, using ‘try-except’ blocks to manage missing files or invalid data.
项目常常需要持久化存储。确定使用纯文本文件、CSV、JSON 或关系型数据库（如 SQLite）。基于数据量、查询需求和并发要求说明理由。对于文件处理，展示安全的读写和有效的错误处理——例如使用“try-except”块来管理缺失文件或无效数据。
Within the code, select appropriate data structures: arrays or lists for ordered collections, dictionaries/hash maps for fast lookups, and classes/records for modelling entities. When using object-oriented programming, design a class hierarchy with clear inheritance or composition relationships. Include a diagram of the data model and explain how it satisfies the requirements.
在代码中选择合适的数据结构：对有序集合使用数组或列表，对快速查找使用字典/哈希映射，对实体建模使用类/记录。若采用面向对象编程，设计具有清晰继承或组合关系的类层次。附上数据模型图并解释其如何满足需求。
6. Coding Standards and Implementation | 编码规范与实现
Write modular, well-commented code that follows a consistent naming convention (e.g., camelCase or snake_case). Declare variables with meaningful names and avoid global variables; pass data via parameters and return values. Use constants for fixed values and include docstrings to describe the purpose of each function. Such practices are explicitly rewarded in the Pre-U marking criteria.
编写模块化、注释良好的代码，遵循一致的命名约定（如 camelCase 或 snake_case）。用有意义的名称声明变量，避免全局变量；通过参数和返回值传递数据。对固定值使用常量，并为每个函数添加文档字符串说明其用途。这些实践在 Pre-U 评分标准中有明确加分。
The implementation section of the report should not merely paste all the code. Select representative screenshots and highlight novel or complex segments. Explain how the code implements specific algorithms, how user input is validated, and how the interface responds to errors. This narrative demonstrates deep understanding beyond mere typing.
报告中的实现部分不应简单粘贴全部代码。应选取代表性截图并高亮新颖或复杂的段落。解释代码如何实现特定算法、如何验证用户输入以及界面如何响应错误。这种叙述性说明展示出超越单纯键入代码的深刻理解。
7. Testing Strategies and Debugging | 测试策略与调试
Employ a systematic testing approach: start with unit tests for individual functions, then integration tests for module interactions, and finally acceptance tests against the original requirements. Use a test table that records the test ID, test data, expected result, actual result, and corrective action taken. This traceable format shows that testing was thorough and not a last-minute addition.
采用系统的测试方法：从针对独立函数的单元测试开始，再到模块间交互的集成测试，最后对照原始需求进行验收测试。使用测试表记录测试编号、测试数据、预期结果、实际结果和采取的纠正措施。这种可追踪的形式表明测试是彻底的，并非临时添加。
Show evidence of debugging: describe at least two non-trivial logic errors encountered, how you identified them (e.g., using breakpoints or print statements), and how you resolved them. This reflective detail proves you can diagnose and fix problems independently — a key skill assessed in the practical component.
展示调试证据：描述至少两个遇到的非平凡逻辑错误，如何发现（如使用断点或打印语句）以及如何解决。这种反思性细节证明你能够独立诊断和修复问题——这是实践部分评估的一项关键技能。
8. Evaluation and Critical Reflection | 评价与批判性反思
Evaluation should be objective and criteria-based. Revisit the original requirements and measure the extent to which each has been met. If a requirement was partially met or not implemented, explain why and discuss what could be done differently. Use evidence from testing to support your judgements, and consider user feedback if you conducted any informal testing with peers.
评价应客观且基于标准。重新审视原始需求，衡量每项需求的满足程度。若某项需求仅部分满足或未实现，解释原因并讨论可如何改进。使用测试证据支持判断，如果曾进行任何非正式同伴测试，也应纳入用户反馈。
Go beyond a simple checklist. Critically analyse the effectiveness of your algorithms — discuss space-time trade-offs and possible improvements (e.g., replacing bubble sort with quicksort). Reflect on the design choices: what worked well, what limitations remain, and what you would change with more time or different skills. Genuine reflection is a differentiator at the top mark bands.
超越简单的核对清单。批判性地分析算法的有效性——讨论时空权衡及可能的改进（如将冒泡排序换成快速排序）。反思设计选择：哪些效果良好，仍存在哪些限制，若有更多时间或不同技能会做何改变。真正的反思是拉开顶部分数的关键区分因素。
9. Documentation and Commentary Writing | 文档与注释撰写
Your project report should read like a coherent technical narrative, not a collection of disjointed sections. Use clear headings, numbered figures, and cross-references. The analysis and design sections should logically lead to the implementation, which in turn leads to testing and evaluation. Ensure consistency: terms defined in analysis should be used consistently throughout.
项目报告应读起来像一篇连贯的技术叙述，而非割裂的部分集合。使用清晰的标题、编号图表和交叉引用。分析、设计部分应合乎逻辑地导向实现，实现再导向测试与评价。确保一致性：分析中定义的术语应在全文统一使用。
Within the code itself, use line comments sparingly but meaningfully; explain ‘why’ rather than ‘what’. Produce a user guide (separate from the technical report) that explains how to install and run the software, with screenshots of key screens. Both documents must be proofread for clarity and spelling — presentation matters.
在代码内部，注释要精炼而有意义；解释“为什么”而不是“做什么”。编写一份用户指南（与技术报告分开），说明如何安装和运行软件，并附上关键界面截图。两份文档都需校对以确保清晰性和拼写正确——呈现质量至关重要。
10. Avoiding Common Pitfalls | 避免常见问题
Many candidates lose marks by leaving the evaluation section too short or superficial. Allocate sufficient time — around 20% of the project schedule — to write a deep evaluation. Another common mistake is neglecting data validation: robust programs anticipate invalid input types, out-of-range values, and empty fields. Demonstrate defensive programming throughout.
许多考生因评价部分过短或肤浅而丢分。应为深入评价分配充分时间——约占项目日程的 20%。另一个常见错误是忽视数据验证：健壮的程序应预判无效输入类型、越界值和空字段。全程展示防御性编程。
Avoid over-reliance on code generation tools or templates that produce code you cannot fully explain. The practical assessment probes your understanding; you must be able to walk through the logic of every line you submit. Also, steer clear of trivial projects with no algorithmic challenge — for example, a simple quiz without persistence or user management. Aim to incorporate at least one advanced data structure or algorithm beyond the standard array.
避免过度依赖代码生成工具或你无法完全解释的模板。实践考核考察理解深度；你必须能够逐行解释所提交代码的逻辑。同时，避开毫无算法挑战的简单项目——例如无持久存储或用户管理的简易问答。力争纳入至少一种超越标准数组的高级数据结构或算法。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
屏轩国际教育cambridge primary/secondary checkpoint, cat4, ukiset,ukcat,igcse,alevel,PAT,STEP,MAT, ibdp,ap,ssat,sat,sat2课程辅导，国外大学本科硕士研究生博士课程论文辅导