사용자 흐름으로
서비스 테스트하기用用户流程
测试服务
실제 사용자처럼 처음부터 끝까지 써 보고 예상과 비교합니다.不再增加功能。
像真实用户那样从头到尾用一遍，再与预期比对。
설명서를 읽어야 쓸 수 있다면要看说明书才会用的话
친구에게 내가 만든 서비스를 보여 줍니다. 친구가 화면을 봅니다. 그리고 묻습니다. “이거 뭐부터 눌러야 돼?”你把自己做的服务给朋友看。朋友盯着画面，然后问：“这个先点哪儿？”
내가 “거기 칸에 단어를 넣고 아래 버튼을 누르면 돼”라고 말해 주면 그제야 씁니다. 그런데 내가 옆에 없다면 어떨까요? 만든 사람은 어디를 눌러야 하는지 이미 알고 있어서 그것이 어렵다는 사실을 알아차리지 못합니다. 오늘은 모르는 사람인 척 내 서비스를 써 봅니다.你说一句“在那个框里输入词，再点下面的按钮就行”，朋友这才用起来。可要是我不在旁边呢？做的人本来就知道该点哪里，所以察觉不到那有多难。今天要装作不知情的人来用一遍自己的服务。
설명서를 읽어야 쓸 수 있다면如果得先读说明书才会用(이어서)（续）
사용자가 설명 없이도 서비스를 시작하고, 결과를 얻고,
문제가 생기면 다시 시도할 수 있을까?用户能不用别人解释就开始使用、拿到结果，
出了问题还能重试吗？
- 10~11회에 대표 사용자 흐름과 SQLite 데이터 기억 기능을 만들었습니다.第 10~11 次课做出了代表性用户流程与 SQLite 数据记忆功能。
- 9회의
09_development_plan_학생ID_이름.md이 테스트 시나리오의 재료가 됩니다.第 9 次课的09_development_plan_학생ID_이름.md就是测试场景的材料。 - 10~11회의 화면 → 요청 → API → 응답 → SQLite → 화면 연결이 문제를 나누는 데 쓰입니다.第 10~11 次课的画面 → 请求 → API → 响应 → SQLite → 画面连接可用来分类问题。
12회에는 새 기능도, 자동 테스트 코드도 만들지 않습니다. 9회에 설계한 사용자 흐름을 테스트 시나리오로 바꾸어 직접 실행하며 계획한 경험과 실제 결과를 비교합니다.第 12 次课既不加新功能，也不写自动化测试代码。把第 9 次课设计的用户流程改成测试场景，亲手跑一遍，再把计划中的体验与实际结果作比较。
테스트는 예상과 실제를 비교하는 일이다测试就是拿预期与实际作比较 핵심核心
기능 하나가 한 번 작동했다는 사실보다 사용자가 흐름 전체를 끝낼 수 있는지가 중요합니다. 부분마다 잘 되는데 이어지지 않는 서비스는 흔합니다.比起某个功能成功跑过一次，更重要的是用户能不能把整条流程走完。各部分都好用却接不上的服务很常见。
3-1에서 코드를 읽고 결과를 먼저 예상한 뒤 실행해서 비교했습니다. 지금은 대상이 코드에서 사용자 경험으로 바뀌었을 뿐, 순서는 같습니다.3-1 里读代码时是先预测结果再运行比对。现在只是把对象从代码换成了用户体验，顺序一样。
9회의 사용자 흐름에서 테스트를 만든다从第 9 次课的用户流程里造出测试 핵심核心
09_development_plan_학생ID_이름.md의 각 단계를 질문으로 바꾸면 테스트가 됩니다. 새로 만들 것이 없습니다.把 09_development_plan_학생ID_이름.md 里的每一步改写成问句，就成了测试。不用另造。
| 개발 계획의 흐름开发计划里的流程 | 테스트 시나리오测试场景 |
|---|---|
| 처음 화면에서 안내를 본다在第一个画面看提示 | 처음 방문한 사용자가 무엇을 해야 할지 이해하는가?第一次来的用户明白该做什么吗？ |
| 값을 입력하고 핵심 행동을 한다输入值并做出核心行动 | 대표적인 값으로 결과까지 도달하는가?用有代表性的值能走到结果吗？ |
| 잘못된 값을 입력한다输入错误的值 | 이유와 고칠 방법을 알고 다시 시도할 수 있는가?知道原因与改法，能重试吗？ |
| 저장한 기록을 다시 본다再看已保存的记录 | 새로고침 · 재실행 뒤에도 필요한 기록이 보이는가?刷新、重启之后需要的记录还看得到吗？ |
9회에 흐름을 보는 것 · 행동 · 반응으로 적어 두었기 때문에, 오늘은 그것을 질문으로 바꾸기만 하면 됩니다. 계획이 없었다면 무엇을 시험해야 할지부터 정해야 했을 것입니다.因为第 9 次课把流程写成了看到的 · 行动 · 反应，今天只要把它改成问句就行。要是当初没有计划，就得先决定该测什么。
기본 사용자 시나리오 네 가지四种基本用户场景 핵심核心
① 처음 방문① 第一次访问
- 서비스의 목적을 알 수 있는가?能看出服务的目的吗？
- 처음 해야 할 행동을 알 수 있는가?能看出最先该做的行动吗？
- 작동하지 않는 예시 버튼이나 빈 화면이 보이지 않는가?有没有出现不能用的示例按钮或空白画面？
② 대표 정상 흐름② 代表性正常流程
- 9회에 정한 순서대로 행동할 수 있는가?能按第 9 次课定的顺序行动吗？
- 행동 뒤 서비스 반응을 알아볼 수 있는가?行动之后看得出服务的反应吗？
- 사용자가 핵심 결과에 도달하는가?用户能到达核心结果吗？
③ 예외 뒤 다시 시도③ 遇到例外后重试
- 잘못된 입력이나 상황을 알아볼 수 있는가?看得出输入或情况有误吗？
- 무엇을 고쳐야 하는지 안내하는가?会提示该改什么吗？
- 안내를 따른 뒤 정상 흐름으로 돌아갈 수 있는가?照提示做完，能回到正常流程吗？
④ 다시 방문하거나 반복 사용④ 再次访问或反复使用
- 같은 행동을 다시 할 수 있는가?同样的行动能再做一次吗？
- 핵심 기능의 기록이 새로고침 뒤에도 남는가?核心功能的记录刷新后还在吗？
- 프로젝트를 다시 실행한 뒤 저장된 기록을 다시 볼 수 있는가?项目重启之后还能再看到已保存的记录吗？
- 화면의 기록과 SQLite Viewer의 값이 같은가?画面上的记录与 SQLite Viewer 里的值一致吗？
내 서비스의 시나리오 네 줄我的服务的四条场景 실습实践
앞의 네 가지를 내 서비스의 문장으로 바꿔 적습니다. 9회 개발 계획을 옆에 펴 놓고 질문으로 바꾸기만 하면 됩니다.把前面的四种换成自己服务的句子。把 9 次的开发计划摊在旁边，改成问句就行。
| 시나리오场景 | 내 서비스에서는 이렇게 묻는다在我的服务里这样问 |
|---|---|
| ① 처음 방문① 首次访问 | |
| ② 대표 정상 흐름② 主要正常流程 | |
| ③ 예외 뒤 다시 시도③ 出错后再试 | |
| ④ 다시 방문④ 再次访问 |
새로 만들 것이 없습니다. 9회에 적은 흐름을 질문으로 바꾸는 것뿐입니다.没有要新做的。只是把 9 次写的流程改成问句。
입력의 경계는 필요한 서비스만 확인한다输入的边界只在需要的服务上确认 확장拓展
숫자 범위, 글자 길이와 파일 크기처럼 분명한 제한이 있는 프로젝트만 가장 작거나 큰 값과 허용하지 않는 값을 추가로 시험합니다.只有像数值范围、文字长度、文件大小这样有明确限制的项目，才额外测最小值、最大值与不允许的值。
모든 학생에게 같은 경계값 테스트를 억지로 요구하지 않습니다. 내 서비스에 그런 제한이 없다면 이 절은 건너뜁니다.不强求所有学生做同样的边界值测试。自己的服务没有这类限制，就跳过这一节。
경계값보다 대표 흐름과 예외 뒤 회복 흐름을 먼저 통과시킵니다. 대표 흐름이 막혀 있는데 경계값을 시험하는 것은 순서가 뒤바뀐 것입니다.先让代表流程与例外后的恢复流程通过，再谈边界值。代表流程还卡着就去测边界值，是本末倒置。
예상한 반응을 먼저 적는다先把预期的反应写下来 핵심核心
시나리오마다 다음 네 가지를 적습니다. 앞의 두 가지는 실행 전에 씁니다.每个场景都写下面四项。前两项要在运行之前写。
- 사용자 행동用户行动
- 예상한 서비스 반응预期的服务反应
- 실제 결과实际结果
- 판정 — 통과 / 실패 / 확인 필요判定 —— 通过 / 失败 / 待确认
실행해 본 뒤 예상 결과를 바꾸면 계획과 실제를 비교할 수 없습니다. 화면에 나온 것을 예상 칸에 적어 넣으면 모든 항목이 “통과”가 되지만, 아무것도 확인하지 못한 것입니다.跑完再改预期，就没法比较计划与实际了。把画面上出现的东西填进预期栏，所有项目都会变成“通过”，可你什么也没确认到。
실패도 숨기지 않고 13회 수정 근거로 사용합니다. 실패가 하나도 없는 테스트 기록은 대개 제대로 시험하지 않은 기록입니다.失败也不遮掩，把它当作第 13 次课修改的依据。一条失败都没有的测试记录，多半是没有认真测的记录。
실행하기 전에 예상을 적는다运行之前先写下预期 실습实践
실행하기 전에 왼쪽 두 칸을 채웁니다. 오른쪽 두 칸은 다음 시간에 실제로 해 보고 채웁니다. 실행한 뒤에 예상 칸을 고치면 아무것도 확인하지 못한 것이 됩니다.运行之前先填左边两格。右边两格下节课实际操作后再填。运行之后再改预期栏，就等于什么都没验证。
| # | 사용자 행동用户动作 | 예상한 반응预期的反应 | 실제 결과实际结果 | 판정判定 |
|---|---|---|---|---|
| 1 | ② 대표 정상 흐름② 主要正常流程 | |||
| 2 | ③ 예외 뒤 다시 시도③ 出错后再试 | |||
| 3 | ④ 다시 방문④ 再次访问 |
- 실행하기 전에 예상 칸을 다 채웠다.运行之前把预期栏都填满了。
- 예상 칸에 화면에 보일 것을 적었다. 「잘 된다」는 예상이 아니다.预期栏写的是画面上会出现什么。「能用」不算预期。
처음 달라진 단계를 찾는다找出第一处不一样的步骤 핵심核心
처음 화면은 예상대로 보이는가?
→ 사용자가 행동할 수 있는가?
→ 행동 직후 반응이 나타나는가?
→ 원하는 결과가 보이는가?
→ 예외 뒤 다시 시도할 수 있는가?
→ 저장된 기록이 다시 방문했을 때 남는가?- 마지막으로 예상대로 보인 단계最后一次符合预期的步骤
- 처음 예상과 달라진 단계第一处与预期不同的步骤
- 그때 사용자가 한 행동当时用户做的行动
- 화면에 실제로 보인 내용画面上实际显示的内容
이 네 가지를 찾으면 학생이 세부 코드를 해석하지 않아도 AI에게 문제를 구체적으로 전달할 수 있습니다.找齐这四样，学生不用去解读细节代码，也能把问题具体地讲给 AI 听。
| 필요한 경우 이렇게 나눕니다需要时这样分类 | 관련될 가능성이 있는 곳可能相关的部分 |
|---|---|
| 필요한 입력란·버튼·결과가 보이지 않음输入框、按钮或结果看不见 | 화면 표시画面显示 |
| 행동 뒤 반응이 다름行动之后反应不对 | 요청 데이터 → API 처리 → 응답 → 화면 반영请求数据 → API 处理 → 响应 → 画面更新 |
| 이전 기록이 사라짐之前的记录不见了 | SQLite 저장·조회SQLite 保存·查询 |
처음 달라진 단계 찾기找出第一个不一样的步骤 실습实践
예상과 다른 것이 하나라도 있으면 네 줄로 옮겨 적습니다. 이 넷이면 코드를 읽지 않아도 AI에게 문제를 정확히 전할 수 있습니다.只要有一处和预期不同，就写成四行。有这四行，不用读代码也能把问题准确告诉 AI。
| # | 적을 것要写的 | 내가 본 것我看到的 |
|---|---|---|
| 1 | 마지막으로 예상대로 보인 단계最后一个符合预期的步骤 | |
| 2 | 처음 예상과 달라진 단계第一个与预期不同的步骤 | |
| 3 | 그때 사용자가 한 행동那时用户做的动作 | |
| 4 | 화면에 실제로 보인 내용画面上实际显示的内容 |
- 두 번째 줄이 처음 달라진 곳이다. 그 뒤로 이상한 것은 적지 않는다.第二行是第一个不同的地方。之后的异常不用写。
- 네 번째 줄에 화면에 보인 글자를 그대로 옮겨 적었다.第四行照抄了画面上出现的文字。
수정한 뒤 같은 행동으로 다시 확인한다改完之后用同样的动作再确认 핵심核心
문제를 고친 뒤에는 같은 시작 상태와 같은 행동으로 다시 시험합니다. 다른 값으로 바꾸면 수정 전후를 비교하기 어렵습니다.改完问题之后，用同样的起始状态、同样的行动再测一次。换了别的值，就难以比较改前改后。
수정 때문에 대표 정상 흐름이 깨지지 않았는지 처음부터 다시 한 번 확인합니다. 예외를 고치다가 정상 흐름을 막는 일이 흔합니다.还要从头再确认一遍，修改有没有把代表性正常流程弄坏。改例外时把正常流程堵住，是常有的事。
여러 문제를 한꺼번에 고치면 무엇 때문에 달라졌는지 알 수 없습니다. 10-2와 11-2에서 “가장 작은 수정 하나”를 요청했던 이유가 이것입니다.一次改好几个问题，就说不清是什么带来了变化。10-2 与 11-2 之所以要求“只提一个最小的修改”，就是这个原因。
AI는 사용자 시나리오를 제안할 수 있다AI 可以提议用户场景 핵심核心
PRD와 09_development_plan_학생ID_이름.md를 읽고
사용자 관점의 테스트 시나리오를 제안해 줘.
- 처음 방문 1개
- 대표 정상 흐름 1개
- 예외 뒤 다시 시도하는 흐름 1개
- 저장된 기록을 확인하는 다시 방문 흐름 1개
각 시나리오에는 시작 상태, 사용자 행동과 예상한 서비스 반응을 적어 줘.
자동 테스트 코드, 공격 방법과 전문 보안 테스트는 만들지 마.AI의 제안을 모두 사용할 필요는 없습니다. 학생은 자신의 서비스 목적과 사용자 흐름에 맞는지 판단합니다. 내 서비스에 없는 기능을 시험하라는 제안은 빼면 됩니다.AI 的提议不必全用。学生要判断它是否符合自己服务的目的与用户流程。要你去测自己服务里没有的功能，删掉就是。
요청문 마지막 줄에 있는 대로 공격 방법과 전문 보안 테스트는 만들지 않습니다. 이 수업의 테스트는 사용자가 서비스를 쓸 수 있는지 확인하는 것입니다.照请求文最后一行所写，不造攻击手法与专业安全测试。这门课的测试，是确认用户能不能用这个服务。
테스트 기록을 준비한다准备测试记录 실습实践
교사가 제공한 테스트 기록 양식을 복사하여 프로젝트 docs/ 폴더에 저장합니다. 양식 전문은 이 차시 부록에 있습니다.复制老师提供的测试记录样式，保存到项目的 docs/ 文件夹。样式全文在本课时的附录里。
12_test_record_학생ID_이름.md
12_test_record_260701_홍길동.md- 예상한 서비스 반응은 실행 전에 작성한다.预期的服务反应要在运行之前写。
- 실제 결과와 판정은 실행 뒤 기록한다.实际结果与判定在运行之后记。
- 발견한 문제는 사용자에게 미치는 영향으로 분류한다.发现的问题按对用户的影响分类。
양식 7절에서 문제를 핵심 결과에 도달 못 함 → 이해·재시도 어려움 → 표현 개선 → 남겨 둘 한계 네 단계로 나눕니다. 13회에는 위에서부터 고칩니다.样式第 7 节把问题分成四级：到不了核心结果 → 难以理解或重试 → 表达可改进 → 留作局限。第 13 次课从上往下改。
테스트 기록 양식 — 머리말과 1~2항测试记录样式 — 抬头与第 1~2 项
# 사용자 흐름 테스트 기록
- 학생 ID:
- 이름:
- 서비스 이름:
- 테스트한 날짜:
- 테스트한 프로젝트 버전:
- PRD 파일:
- 개발 계획 파일:
## 1. 테스트할 사용자 흐름
- 흐름의 시작:
- 사용자의 핵심 행동:
- 사용자가 확인할 핵심 결과:
- 핵심 예외 상황:
- 저장할 핵심 기록:
- 기록이 생기는 행동:
- 저장된 기록을 다시 보는 순간:
## 2. 사용자 시나리오별 결과
| 시나리오 | 시작 상태 | 사용자가 한 행동 | 예상한 서비스 반응 | 실제 결과 | 판정 |
|---|---|---|---|---|---|
| 처음 방문 | | | | | 통과 / 실패 / 확인 필요 |
| 대표 정상 흐름 | | | | | 통과 / 실패 / 확인 필요 |
| 예외 뒤 다시 시도 | | | | | 통과 / 실패 / 확인 필요 |
| 같은 행동 반복 | | | | | 통과 / 실패 / 확인 필요 |
| 새로고침·다시 방문 | | | | | 통과 / 실패 / 확인 필요 |테스트 기록 양식 — 3~4항测试记录样式 — 第 3~4 项
## 3. 대표 정상 흐름 단계별 확인
| 단계 | 사용자가 보는 것 | 사용자의 행동 | 예상한 서비스 반응 | 실제 결과 | 판정 |
|---:|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
| 4 | | | | | |
## 4. 선택 테스트
서비스에 해당하는 경우만 작성한다.
### 입력 범위
| 상황 | 사용한 값 | 예상 결과 | 실제 결과 | 판정 |
|---|---|---|---|---|
| 가장 짧거나 작은 값 | | | | |
| 가장 길거나 큰 값 | | | | |
| 허용하지 않는 값 | | | | |
### 파일 업로드
| 상황 | 사용한 파일 | 예상 결과 | 실제 결과 | 판정 |
|---|---|---|---|---|
| 교사가 허용한 파일 | | | | |
| 허용하지 않은 형식 | | | | |
| 크기 제한 초과 | | | | |4절은 입력 범위 제한이나 파일 업로드가 있는 서비스만 작성합니다.第 4 节只有带输入范围限制或文件上传的服务才写。
테스트 기록 양식 — 5~7항测试记录样式 — 第 5~7 项
## 5. 처음 달라진 단계
- 마지막으로 예상대로 작동한 단계:
- 처음 예상과 달라진 단계:
- 사용자가 한 행동:
- 화면에 실제로 보인 내용:
- 화면 표시·요청 데이터·API 처리·응답·SQLite 저장·조회 중 관련될 가능성이 있는 단계:
## 6. 계획과 실제 결과 비교
- PRD와 일치하는 부분:
- 9회 사용자 흐름과 일치하는 부분:
- 줄이거나 바꾼 부분:
- 바꾼 이유:
- 핵심 목적이 유지되는가? 예 / 아니요
## 7. 발견한 문제와 우선순위
### 사용자가 핵심 결과에 도달하지 못하게 하는 문제
1.
2.
### 사용자가 이해하거나 다시 시도하기 어렵게 하는 문제
1.
2.
### 시간이 있으면 개선할 표현·화면
1.
2.
### 이번 수업에서는 남겨 둘 한계
1.테스트 기록 양식 — 8~9항과 완료 확인测试记录样式 — 第 8~9 项与完成确认
## 8. 시험 제출 확인
### 플랫폼을 사용할 수 있는 경우
- 업로드한 파일명:
- 파일 검증 결과:
- 실행 결과:
- 미리보기에서 확인한 사용자 흐름:
- 로컬과 플랫폼에서 다른 점:
### 플랫폼을 사용할 수 없는 경우
- ZIP 제출 위치:
- 로컬 실행 확인 방법:
- 교사에게 전달할 내용:
## 9. AI 사용과 학생 판단
- AI에게 전달한 사용자 행동과 실제 결과:
- AI가 제안한 원인이나 수정:
- 학생이 직접 다시 확인한 결과:
- 반영한 내용과 이유:
- 반영하지 않은 내용과 이유:
8. 시험 제출 확인은 12-2에서 ZIP을 만들고 플랫폼에 올린 뒤 작성합니다. 오늘은 비워 두세요.8. 试提交确认要在 12-2 做好 ZIP 并上传平台之后写。今天先留空。
테스트 기록 양식 — 완료 확인测试记录样式 — 完成确认
## 테스트 완료 확인
- [ ] 9회의 대표 정상 흐름을 처음부터 끝까지 시험했다.
- [ ] 핵심 예외 상황 뒤 다시 시도할 수 있는지 시험했다.
- [ ] 예상한 서비스 반응을 실행 전에 작성했다.
- [ ] 새로고침·다시 방문 뒤 저장된 기록을 시험했다.
- [ ] 화면의 기록과 SQLite Viewer의 값을 비교했다.
- [ ] 예상과 처음 달라진 단계를 찾았다.
- [ ] 수정한 뒤 같은 사용자 행동을 다시 시험했다.
- [ ] 계획과 실제 결과의 차이를 기록했다.
- [ ] 13회에 고칠 문제를 사용자 영향에 따라 정리했다.이 다섯 쪽을 이어 붙이면 12_test_record_학생ID_이름.md 한 파일이 됩니다. 프로젝트의 docs/ 폴더에 저장하세요.把这五页接起来，就是 12_test_record_학생ID_이름.md 一个文件。请存到项目的 docs/ 文件夹里。
확인 문제检查题
해설 보기查看解析
서비스의 목적은 사용자가 결과에 도달하는 것이기 때문입니다. 입력값 하나하나가 잘 처리돼도 흐름이 이어지지 않으면 사용자는 목적을 이루지 못합니다.因为服务的目的是让用户到达结果。每一个输入值都处理得好，但流程接不上，用户还是达不成目的。
또 시간이 한정되어 있습니다. 대표 흐름이 막혀 있는데 경계값을 시험하는 것은 순서가 뒤바뀐 것입니다.再说时间有限。代表流程还卡着就去测边界值，是本末倒置。
해설 보기查看解析
안내가 나타나도 사용자가 정상 흐름으로 돌아가지 못하면 서비스는 거기서 끝나기 때문입니다. 안내는 목적지가 아니라 돌아가는 길의 표지판입니다.因为即使提示出现了，用户回不到正常流程，服务就在那里断了。提示不是终点，而是回去那条路上的指路牌。
예를 들어 “값을 입력해 주세요”가 뜨는데 입력칸이 사라져 있다면, 안내는 있어도 다시 시도할 수 없습니다.比如弹出“请输入内容”，输入框却不见了，那就是有提示也无法重试。
해설 보기查看解析
찾아야 할 범위를 좁혀 줍니다. “안 돼요”라고만 하면 AI는 전체를 뒤져야 하고, 엉뚱한 곳을 고치거나 프로젝트를 다시 만들자고 할 수도 있습니다.它把要找的范围收窄了。只说“不行”，AI 就得翻遍全部，可能改错地方，甚至提议把项目重做。
“3단계까지는 예상대로였고 4단계에서 이것 대신 저것이 보였다”라고 하면, 3단계와 4단계 사이만 보면 됩니다. 학생은 코드를 해석하지 않고도 이 정보를 줄 수 있습니다.说“到第 3 步都符合预期，第 4 步出现的是这个而不是那个”，就只需看第 3 步与第 4 步之间。学生不用解读代码也能提供这个信息。
내 서비스를 처음 보는 사람이 설명 없이 쓸 수 있을까요? 막힐 것 같은 지점을 한 곳 적어 보세요.第一次看到我服务的人，不用别人解释就能用吗？写下一个你觉得他会卡住的地方。
핵심 정리核心小结
- 테스트는 실제 사용자처럼 서비스를 처음부터 끝까지 이용해 보는 활동이다.测试是像真实用户那样把服务从头用到尾的活动。
- 9회의 사용자 흐름을 질문으로 바꾸면 그대로 테스트가 된다.把第 9 次课的用户流程改成问句，就成了测试。
- 대표 정상 흐름과 예외 뒤 회복 흐름을 우선한다.优先代表性正常流程与例外后的恢复流程。
- 모든 프로젝트에서 저장된 기록을 다시 보는 흐름을 확인한다.每个项目都要确认再次查看已保存记录的流程。
- 입력 경계 테스트는 서비스에 필요한 경우에만 추가한다.输入边界测试只在服务需要时才加。
- 예상을 먼저 적는다. 실행한 뒤 예상을 고치면 비교할 것이 없어진다.先写预期。跑完再改预期，就没什么可比的了。
- 마지막 정상 단계와 처음 달라진 단계를 찾으면 코드 없이도 문제를 설명할 수 있다.找出最后一次正常的步骤与第一处不同的步骤，不用代码也能说明问题。
- 12회의 테스트 결과는 13회의 수정 우선순위를 정하는 근거다.第 12 次课的测试结果，是定第 13 次课修改优先级的依据。
다음 차시에는 오늘 만든 시나리오를 실제로 실행하고 결과를 기록합니다. 그다음 문제에 우선순위를 매기고, 프로젝트를 ZIP으로 만들어 시험 제출합니다.下一课时把今天做的场景真正跑一遍并记录结果。然后给问题排优先级，把项目打成 ZIP 试提交。
12-2. 사용자 흐름 테스트와 시험 제출 →