Mục lục bài họcĐang ở d06-b2
Testing: validation, verification and test data
Validation and verification are not the same
| validation | an automatic check by the computer that the data entered is reasonable |
| verification | a check that the data entered matches the original source |
The crucial point, and the one most often missed: validation cannot tell whether data is correct — only whether it is sensible.
A date of birth of $\text{14/03/2008}$ passes every validation check that could be written. It is still wrong if the person was born in $2009$. Only verification — comparing against the source document — catches that.
Validation checks
- range check — the value lies between stated limits, for example a mark from $0$ to $100$;
- length check — the data has the right number of characters, for example a password of at least $8$;
- type check — the data is the right data type, for example a number where a number is expected;
- presence check — a required field is not left empty;
- format check — the data follows a pattern, for example two letters then six digits;
- check digit — an extra digit calculated from the others, used on barcodes and account numbers to catch typing errors.
Verification methods
- double entry — the data is typed twice and the computer compares the two versions; a difference means at least one was mistyped;
- visual check — a person reads the data on screen and compares it with the original document.
Note that double entry does not prove the data is correct either: someone can make the same mistake twice, or copy the same wrong source. It only catches typing slips.
The four types of test data
| normal | values inside the accepted range that the program should accept — for a mark out of 100: $45$ |
| abnormal (erroneous) | values the program should reject — $-5$, $150$, or the word "fifty" |
| extreme | the largest and smallest values still accepted — $0$ and $100$ |
| boundary | values on either side of each limit, one accepted and one rejected — $-1$ and $0$; $100$ and $101$ |
Extreme and boundary are the pair most often confused. Extreme data is a single value at each end. Boundary data comes in pairs straddling the limit, and each pair tests a different outcome.
Boundary testing matters because the commonest coding error is writing $>$ where $\geq$ was meant. That error is invisible to normal data and only shows up exactly at the limit.
Trace tables
A trace table records the value of every variable after each step of an algorithm, so the programmer can see where a value first becomes wrong.
It is the standard way to dry-run an algorithm by hand, before or instead of running it.
Types of error
- syntax error — breaks the rules of the language, so the program will not translate; for example a missing bracket;
- logic error — the program runs but gives the wrong answer; for example adding where it should subtract.
Logic errors are far more dangerous, precisely because nothing reports them.
Kiểm tra hợp lệ và kiểm tra đúng nguồn không phải một.
- Kiểm tra hợp lệ — máy tính tự động kiểm xem dữ liệu nhập vào có hợp lý không;
- Kiểm tra đúng nguồn — kiểm xem dữ liệu nhập vào có khớp với bản gốc không.
Điểm then chốt, và cũng là điểm hay bị bỏ sót nhất: kiểm tra hợp lệ không cho biết dữ liệu có đúng hay không — nó chỉ cho biết dữ liệu có hợp lý hay không.
Một ngày sinh $\text{14/03/2008}$ vượt qua mọi phép kiểm tra hợp lệ có thể nghĩ ra. Nhưng nó vẫn sai nếu người đó sinh năm $2009$. Chỉ có kiểm tra đúng nguồn — đối chiếu với giấy tờ gốc — mới bắt được lỗi đó.
Các phép kiểm tra hợp lệ.
- kiểm khoảng — giá trị nằm trong giới hạn đã nêu, ví dụ điểm từ $0$ đến $100$;
- kiểm độ dài — dữ liệu có đúng số ký tự, ví dụ mật khẩu ít nhất $8$ ký tự;
- kiểm kiểu — dữ liệu đúng kiểu dữ liệu, ví dụ chỗ cần số thì phải là số;
- kiểm có mặt — ô bắt buộc không được bỏ trống;
- kiểm định dạng — dữ liệu theo đúng khuôn mẫu, ví dụ hai chữ cái rồi sáu chữ số;
- chữ số kiểm tra — một chữ số phụ tính ra từ các chữ số kia, dùng trên mã vạch và số tài khoản để bắt lỗi gõ nhầm.
Các cách kiểm tra đúng nguồn.
- nhập hai lần — dữ liệu được gõ hai lần và máy so sánh hai bản; khác nhau nghĩa là ít nhất một bản gõ sai;
- kiểm bằng mắt — một người đọc dữ liệu trên màn hình và đối chiếu với giấy tờ gốc.
Chú ý nhập hai lần cũng không chứng minh dữ liệu đúng: người ta có thể mắc cùng một lỗi hai lần, hoặc chép từ cùng một nguồn sai. Nó chỉ bắt được lỗi gõ nhầm.
Bốn loại dữ liệu thử.
- Bình thường — giá trị nằm trong khoảng chấp nhận, chương trình phải nhận. Với điểm trên thang $100$: $45$;
- Bất thường — giá trị chương trình phải từ chối: $-5$, $150$, hoặc chữ “năm mươi”;
- Cực trị — giá trị lớn nhất và nhỏ nhất còn được chấp nhận: $0$ và $100$;
- Biên — giá trị nằm ở hai bên mỗi giới hạn, một cái được nhận và một cái bị từ chối: $-1$ và $0$; $100$ và $101$.
Cực trị và biên là cặp bị lẫn nhiều nhất. Dữ liệu cực trị là một giá trị đơn ở mỗi đầu. Dữ liệu biên đi thành cặp nằm hai bên giới hạn, và mỗi cặp kiểm một kết quả khác nhau.
Kiểm biên quan trọng vì lỗi lập trình phổ biến nhất là viết $>$ trong khi ý định là $\geq$. Lỗi đó hoàn toàn không lộ với dữ liệu bình thường và chỉ hiện ra đúng ngay tại giới hạn.
Bảng lần vết. Bảng lần vết ghi lại giá trị của mọi biến sau mỗi bước của thuật toán, nhờ đó lập trình viên thấy được chỗ nào một giá trị bắt đầu sai.
Đây là cách chuẩn để chạy thử bằng tay một thuật toán, trước khi hoặc thay vì chạy máy.
Các loại lỗi.
- lỗi cú pháp — vi phạm quy tắc của ngôn ngữ, nên chương trình không dịch được; ví dụ thiếu một dấu ngoặc;
- lỗi logic — chương trình vẫn chạy nhưng cho kết quả sai; ví dụ dùng phép cộng ở chỗ đáng ra phải trừ.
Lỗi logic nguy hiểm hơn nhiều, đúng vì không có gì báo về nó cả.
Một trường học nhập ngày sinh học sinh từ giấy khai sinh. (a) Nêu các phép kiểm tra hợp lệ có thể dùng. (b) Giải thích vì sao kiểm tra hợp lệ vẫn không đủ. (c) Nêu hai cách kiểm tra đúng nguồn và hạn chế của chúng.
(a) Các phép kiểm tra hợp lệ có thể dùng.
- kiểm định dạng — ngày sinh phải theo khuôn $\text{DD/MM/YYYY}$;
- kiểm khoảng — tháng phải từ $1$ đến $12$; ngày phải từ $1$ đến $31$; năm phải hợp lý với độ tuổi học sinh;
- kiểm kiểu — ba phần đều phải là số;
- kiểm có mặt — ô ngày sinh không được bỏ trống.
(b) Vì sao kiểm tra hợp lệ vẫn không đủ.
Kiểm tra hợp lệ chỉ trả lời được câu hỏi “dữ liệu này có hợp lý không?” Nó không bao giờ trả lời được câu hỏi “dữ liệu này có đúng không?”
Ví dụ cụ thể. Nhân viên gõ $\text{14/03/2008}$ trong khi giấy khai sinh ghi $\text{14/03/2009}$.
Giá trị này vượt qua mọi phép kiểm ở phần (a): đúng định dạng, tháng và ngày trong khoảng, đều là số, không để trống. Máy tính không có cách nào biết nó sai.
Lý do gốc: máy tính không nhìn thấy giấy khai sinh. Nó chỉ có thứ được gõ vào, nên nó chỉ kiểm được thứ đó có tự nó hợp lý hay không.
Muốn phát hiện sai lệch so với bản gốc thì bắt buộc phải có một phép so sánh với bản gốc — và đó chính là kiểm tra đúng nguồn.
(c) Hai cách kiểm tra đúng nguồn và hạn chế.
Cách một — nhập hai lần. Dữ liệu được gõ hai lần, thường bởi hai người, và máy so sánh hai bản. Khác nhau nghĩa là ít nhất một bản đã gõ sai, và máy yêu cầu nhập lại.
Hạn chế: nó không chứng minh dữ liệu đúng. Hai người có thể mắc cùng một lỗi, hoặc cùng đọc nhầm một chữ số viết xấu trên giấy. Nó cũng gấp đôi thời gian nhập liệu.
Cách hai — kiểm bằng mắt. Một người đọc dữ liệu trên màn hình và đối chiếu từng ô với giấy tờ gốc.
Hạn chế: nó phụ thuộc vào sự tập trung của con người. Khi phải soát hàng trăm bản ghi giống nhau, người soát bỏ sót — và càng soát lâu càng dễ sót.
Kết luận: không phép kiểm nào bảo đảm tuyệt đối. Cách thực tế là dùng cả hai: kiểm tra hợp lệ chặn dữ liệu vô lý, kiểm tra đúng nguồn bắt lỗi chép sai.
Một chương trình chỉ chấp nhận điểm từ $0$ đến $100$. Nêu ví dụ cho từng loại dữ liệu thử, nói rõ kết quả mong đợi, và giải thích vì sao dữ liệu biên bắt được lỗi mà dữ liệu bình thường không bắt được.
Dữ liệu bình thường. Ví dụ: $45$, $72$.
Kết quả mong đợi: chương trình chấp nhận và xử lý bình thường.
Mục đích: kiểm chương trình làm đúng việc chính của nó với đầu vào thông thường.
Dữ liệu bất thường. Ví dụ: $-5$, $150$, và chữ “năm mươi”.
Kết quả mong đợi: chương trình từ chối và hiện thông báo lỗi rõ ràng.
Chú ý ví dụ thứ ba: nó kiểm kiểm kiểu, tức chương trình có xử lý được khi người dùng gõ chữ vào ô số không. Nhiều chương trình bị treo ở đúng chỗ này.
Dữ liệu cực trị. Ví dụ: $0$ và $100$.
Kết quả mong đợi: chương trình chấp nhận cả hai.
Đây là giá trị lớn nhất và nhỏ nhất còn hợp lệ — mỗi đầu một giá trị.
Dữ liệu biên. Ví dụ: cặp $(-1, 0)$ và cặp $(100, 101)$.
Kết quả mong đợi: $-1$ bị từ chối nhưng $0$ được nhận; $100$ được nhận nhưng $101$ bị từ chối.
Chú ý dữ liệu biên đi thành cặp, và mỗi cặp kiểm hai kết quả trái ngược nằm cạnh nhau.
Vì sao dữ liệu biên bắt được lỗi mà dữ liệu bình thường không bắt được.
Lỗi lập trình phổ biến nhất ở chỗ này là viết dấu lớn hơn trong khi ý định là lớn hơn hoặc bằng.
Cụ thể. Giả sử lập trình viên viết điều kiện chấp nhận là $\text{diem} > 0$ và $\text{diem} < 100$, trong khi đúng ra phải là $\text{diem} \ge 0$ và $\text{diem} \le 100$.
Chương trình sai này hoạt động hoàn toàn bình thường với $45$, với $72$, với mọi giá trị ở giữa. Không có gì lộ ra cả.
Nó chỉ sai ở đúng hai giá trị: nó từ chối $0$ và từ chối $100$, dù cả hai đều hợp lệ.
Nói cách khác, lỗi này chỉ hiện ra ngay tại giới hạn. Không kiểm biên thì lỗi lọt vào sản phẩm, và chỉ bị phát hiện khi có học sinh thật đạt đúng $0$ hoặc đúng $100$ điểm.
Đọc xong rồi — làm thử ngay
Bài tập của chương Algorithm Design and Problem-Solving gồm 14 câu trắc nghiệm và 5 đề tự luận. Đáp án hiện ngay khi chọn, miễn phí.