Kiểm thử và bảo trì
Đã giới thiệu| English | Ý nghĩa |
|---|---|
| run-time error/rʌn taɪm ˈerə/ | lỗi thời gian chạy |
| syntax error/ˈsɪntæks ˈerə/ | lỗi cú pháp |
| logic error/ˈlɒdʒɪk ˈerə/ | lỗi logic |
| dry run/draɪ rʌn/ | chạy thử tay |
| walkthrough/ˈwɔːkθruː/ | đi kèm |
| white-box testing/waɪt bɒks ˈtestɪŋ/ | kiểm thử hộp trắng |
| black-box testing/blæk bɒks ˈtestɪŋ/ | kiểm thử hộp đen |
| integration testing/ˌɪntɪˈɡreɪʃn ˈtestɪŋ/ | kiểm thử tích hợp |
| stub/stʌb/ | khung giả |
| alpha testing/ˈælfə ˈtestɪŋ/ | kiểm thử alpha |
| beta testing/ˈbiːtə ˈtestɪŋ/ | kiểm thử beta |
| acceptance testing/əkˈseptəns ˈtestɪŋ/ | kiểm thử chấp nhận |
| test strategy/test ˈstrætədʒi/ | chiến lược kiểm thử |
| test plan/test plæn/ | kế hoạch kiểm thử |
| normal data/ˈnɔːml ˈdeɪtə/ | dữ liệu bình thường |
| abnormal data/əbˈnɔːml ˈdeɪtə/ | dữ liệu bất thường |
| extreme data/ekˈstriːm ˈdeɪtə/ | dữ liệu cực trị |
| boundary data/ˈbaʊndəri ˈdeɪtə/ | dữ liệu biên |
| corrective maintenance/kəˈrektɪv ˈmeɪntənəns/ | bảo trì sửa lỗi |
| adaptive maintenance/əˈdæptɪv ˈmeɪntənəns/ | bảo trì thích ứng |
| perfective maintenance/pəˈfektɪv ˈmeɪntənəns/ | bảo trì hoàn thiện |
| regression testing/rɪˈɡreʃn ˈtestɪŋ/ | kiểm thử hồi quy |
Ba mươi bảy giây
- On 4 June 1996 the first Ariane 5 rocket lifted off from French Guiana. Thirty-seven seconds later it veered off course and destroyed itself. The payload was four satellites worth $370 million.
- Nguyên nhân là do một dòng mã, được tái sử dụng từ Ariane 4, đã chuyển đổi một số 64-bit thành nguyên số 16-bit. Ariane 5 bay nhanh hơn, con số lớn hơn, và phép chuyển đổi gây tràn: một lỗi thời gian chạy trong một thủ tục thậm chí không còn cần thiết sau khi cất cánh.
- Dòng mã này chưa bao giờ được thử nghiệm với dữ liệu bay của Ariane 5. Không ai đã chọn dữ liệu thử nghiệm ở cực giới hạn của phạm vi tên lửa mới.
- Bài học này bao gồm ba loại lỗi, các phương pháp thử nghiệm, cách chọn dữ liệu thử nghiệm, và cách giữ cho một chương trình hoạt động sau khi phát hành.
Ba loại lỗi
- Lỗi cú pháp phá vỡ ngữ pháp của ngôn ngữ: thiếu dấu ngoặc, sai chính tả từ khóa. Nó được phát hiện ở giai đoạn dịch, vì vậy chương trình sẽ không chạy cho đến khi được sửa.
- Lỗi thời gian chạy xảy ra khi chương trình đang thực thi: chia cho 0, tập tin không tồn tại, chỉ số mảng vượt quá giới hạn. Chương trình bị sập hoặc ném ngoại lệ; cách khắc phục là kiểm tra trước thao tác rủi ro.
- Lỗi logic cho phép chương trình chạy và tạo ra kết quả sai:
+thay vì-, vòng lặp lệch một đơn vị, các điều kiện sắp xếp sai thứ tự. Không có dấu hiệu nào cảnh báo; chỉ có thử nghiệm và truy vết mới tiết lộ được nó.
Phát hiện ở giai đoạn dịch, phát hiện ở thời gian chạy, phát hiện duy nhất trong đầu ra
Gắn mỗi loại lỗi với cách nó xuất hiện.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
Ngôn ngữ = bắt được khi dịch; Logic = sai kết quả; Chạy thời gian = sập khi đang chạy.
Ví dụ minh họa: tìm và sửa lỗi
Total ← 0
FOR i ← 1 TO Count
Total ← Total + Marks[i]
NEXT i
Average ← Total / Count
IF Average > 50 THEN
OUTPUT "Pass"
- Cú pháp:
IFkhông cóENDIF. Bộ dịch từ chối nó. Thời gian chạy: nếuCountbằng 0 thì phép chia thất bại; hãy bảo vệ nó bằngIF Count > 0 THEN. Logic: nếu điểm đạt là 50 trở lên,> 50sẽ khiến một học sinh đạt điểm đúng bằng 50 bị trượt; nó nên là>= 50. - Đặt tên loại, giải thích tại sao nó là loại đó, và đưa ra cách sửa. Ba phần, ba điểm.
Một chương trình chia tổng số cho số lượng mục và bị sập khi tập tin đầu vào trống. Đây là:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Chia cho số 0 xảy ra khi chương trình đang chạy và làm dừng lại. Một biện pháp bảo vệ như IF Count > 0 sẽ khắc phục.
Phương pháp thử nghiệm: đọc mã
- Chạy khô truy vết mã trên giấy, ghi lại giá trị của mỗi biến vào bảng truy vết sau mỗi dòng.
- Trình duyệt (walkthrough) là một cuộc họp nhóm: lập trình viên giải thích mã từng dòng trong khi đồng nghiệp tìm kiếm các khuyết tật.
- Thử nghiệm hộp trắng thiết kế các bài kiểm tra dựa trên cấu trúc nội bộ của mã, để đảm bảo mọi câu lệnh, nhánh và vòng lặp đều được kích hoạt. Thử nghiệm hộp đen thiết kế các bài kiểm tra chỉ dựa trên tài liệu yêu cầu: cung cấp đầu vào, so sánh đầu ra với những gì mong đợi, mà không cần nhìn vào mã.
Nhìn từ bên ngoài vào trong, hoặc nhìn từ bên trong vào mọi đường dẫn
Thiết kế các trường hợp thử nghiệm dựa hoàn toàn vào tài liệu kỹ thuật (dữ liệu đầu vào và kết quả mong đợi), bỏ qua mã nguồn bên trong, được gọi là kiểm thử hộp ______.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Kiểm thử hộp đen dựa trên tài liệu kỹ thuật; kiểm thử hộp trắng sử dụng cấu trúc nội bộ của mã để bao phủ các câu lệnh và nhánh.
Phương pháp thử nghiệm: tích hợp và phát hành
- Thử nghiệm tích hợp kết hợp các mô-đun đã được thử nghiệm riêng lẻ và kiểm tra các giao diện giữa chúng. Một mô-đun giả (stub) đóng vai thay thế cho một mô-đun chưa được viết, trả về các giá trị cố định để các phần còn lại có thể được thử nghiệm từ trên xuống dưới.
- Thử nghiệm Alpha α được thực hiện nội bộ bởi các nhà phát triển trước khi phát hành. Thử nghiệm Beta β cung cấp cho một nhóm người dùng thực hạn chế chương trình trong môi trường riêng của họ.
- Thử nghiệm chấp nhận được thực hiện bởi khách hàng, đối chiếu với các yêu cầu, để quyết định xem sản phẩm có đáp ứng được mục đích hay không.
Phòng thí nghiệm quy trình phần mềm
Phân loại các ví dụ phát triển theo giai đoạn hoặc công cụ chúng thuộc về.
Ví dụ minh họa: phương pháp nào cho tình huống nào
- Mô-đun báo cáo đã hoàn thành nhưng mô-đun cơ sở dữ liệu mà nó gọi chưa tồn tại: hãy thử nghiệm nó bằng một mô-đun giả trả về dữ liệu cố định.
- Hai mô-đun vượt qua bài kiểm tra của riêng mình nhưng thất bại khi đầu ra của mô-đun này feeds vào mô-đun kia: thử nghiệm tích hợp của giao diện.
- Phần mềm đã hoàn thiện; công ty muốn tìm lỗi trong điều kiện thực tế trước khi phát hành rộng rãi: kiểm thử beta bởi một nhóm người dùng hạn chế.
- Khách hàng quyết định có thanh toán hay không: kiểm thử chấp nhận dựa trên các yêu cầu đã thỏa thuận. Tên phương pháp và mục đích của nó.
Ghép nối mỗi tình huống với phương pháp kiểm tra phù hợp.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
Mô phỏng cho phần thiếu, beta cho người dùng thực, chấp nhận cho khách hàng, tích hợp cho sự kết nối.
Chiến lược kiểm thử và kế hoạch kiểm thử
- Chiến lược kiểm thử là phương pháp tiếp cận tổng quát: sẽ thực hiện những loại kiểm thử nào, do ai thực hiện, khi nào, và những gì phải đạt tiêu chuẩn trước khi bước sang giai đoạn tiếp theo.
- Kế hoạch kiểm thử là danh sách chi tiết các bài kiểm thử. Với mỗi bài: mục đích, dữ liệu đầu vào, kết quả đợi đợi, và cột cho kết quả thực tế khi chạy kiểm thử.
- Một bài kiểm thử không có kết quả mong đợi không phải là kiểm thử. Nó chỉ cho biết chương trình đã làm gì, chứ không cho biết điều đó có đúng hay không.
Kế hoạch kiểm thử liệt kê, đối với mỗi bài kiểm thử, dữ liệu đầu vào và kết quả mong đợi.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Mục đích, đầu vào, kết quả mong đợi và một cột cho kết quả thực tế. Chiến lược là phương pháp tiếp cận tổng quát; kế hoạch là danh sách chi tiết.
Chọn dữ liệu kiểm thử
- Dữ liệu bình thường: các giá trị hợp lệ điển hình nằm trong phạm vi, nên được chấp nhận và xử lý chính xác.
- Dữ liệu bất thường: các giá trị nên bị từ chối, nằm ngoài phạm vi hoặc sai kiểu.
- Dữ liệu cực trị: các giá trị lớn nhất và nhỏ nhất vẫn được chấp nhận, nằm ở rìa của phạm vi. Dữ liệu biên: các cặp跨越 (cross) mỗi cạnh biên, bao gồm giá trị cực trị được chấp nhận và giá trị bị từ chối ngay bên ngoài nó, nơi ẩn chứa các lỗi lệch một đơn vị.
Bên trong, bên ngoài, và ngay trên đường kẻ
Đối với trường chấp nhận điểm 0–100, những giá trị nào là giá trị kiểm thử biên?
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Dữ liệu biên nằm ở rìa của phạm vi hợp lệ (và ngay bên ngoài) — nơi các lỗi lệch một đơn vị ẩn giấu.
Ví dụ minh họa: dữ liệu kiểm thử cho điểm số từ 0 đến 100
| Loại | Dữ liệu | Kết quả mong đợi |
|---|---|---|
| bình thường | 50, 75 |
được chấp nhận và xử lý |
| bất thường | -10, 200, "abc" |
bị từ chối: nằm ngoài phạm vi hoặc sai kiểu |
| cực trị | 0, 100 |
được chấp nhận: giá trị hợp lệ nhỏ nhất và lớn nhất |
| biên | -1 và 0, 100 và 101 |
-1 bị từ chối, 0 được chấp nhận; 100 được chấp nhận, 101 bị từ chối |
- Mỗi hàng cần có kết quả mong đợi; chỉ có bảng đầu vào thì chỉ lấy được một nửa điểm. Các giá trị cực trị đều được chấp nhận:
-1là giá trị biên, không phải cực trị.
Một trường chấp nhận điểm từ 0 đến 100. Những giá trị nào là dữ liệu kiểm thử cực đoan? Chọn tất cả các đáp án đúng.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
Giá trị cực đoan là giá trị nhỏ nhất và lớn nhất vẫn được chấp nhận. -1 bị loại bỏ, nên nó là biên hoặc bất thường; 50 là bình thường.
Bảo trì
- Hầu hết chi phí vòng đời của một chương trình được chi trả sau khi phát hành. Bảo trì sửa lỗi khắc phục các lỗi tìm thấy khi sử dụng.
- Bảo trì thích ứng giữ cho chương trình hoạt động trong môi trường thay đổi: hệ điều hành mới, API mới, sự thay đổi về luật pháp.
- Bảo trì hoàn thiện cải tiến một chương trình đã hoạt động tốt: hiệu suất nhanh hơn, tính năng mới mà người dùng yêu cầu. Một chương trình có thể cần cả ba loại trong suốt vòng đời của nó.
Sửa chữa, duy trì hoạt động, làm cho tốt hơn
Bảo trì sửa chữa khắc phục lỗi, bảo trì hoàn thiện cải tiến tính năng, và bảo trì thích ứng giữ cho phần mềm hoạt động trong môi trường thay đổi.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Ba loại bảo trì: sửa chữa (sửa lỗi), hoàn thiện (nâng cấp), thích ứng (hệ điều hành/hardware/quy tắc mới).
Một chương trình lương được thay đổi vì luật thuế đã thay đổi. Đây là loại bảo trì nào?
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Chương trình không có lỗi và không được cải tiến; môi trường của nó đã thay đổi. Đó là bảo trì thích ứng.
Sửa đổi một chương trình hiện có
- Đọc mã nguồn hiện có cho đến khi hiểu thuật toán và luồng dữ liệu. Tìm xem thay đổi nên nằm ở đâu: subroutine nào, dòng code nào.
- Thực hiện thay đổi càng nhỏ càng tốt; không viết lại mã đang hoạt động. Cập nhật mọi phần liên quan: mỗi hàm gọi với tham số danh sách đã thay đổi, mỗi routine sử dụng cấu trúc dữ liệu đã thay đổi.
- Kiểm thử hành vi mới và cũ: kiểm thử hồi quy đảm bảo rằng những thứ từng hoạt động không bị hỏng. Sau đó ghi tài liệu về thay đổi.
After changing a program, regression testing checks that:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Kiểm thử hồi quy chạy lại các bài kiểm thử cũ để xác nhận hành vi hiện có vẫn hoạt động sau khi thay đổi.
Sắp xếp các bước sửa đổi một chương trình hiện có theo thứ tự.
Difficulty 3/5 · 200 coins + a small bonus on first completion today
Hiểu, định vị, thay đổi nhỏ, lan truyền, kiểm tra mọi thứ, ghi chép. Bỏ qua kiểm thử hồi quy là cách một bản vá gây ra lỗi cho thứ khác.
Điểm số dễ mất
- Cực trị được chấp nhận; bất thường bị từ chối.
0và100là cực trị;-1và101là giá trị biên thuộc phía bị từ chối. - Lỗi logic không làm chương trình bị dừng đột ngột. Nếu nó bị dừng, đó là lỗi thời gian chạy.
- Alpha là nội bộ; beta là người dùng thực bên ngoài. Một stub thay thế module bị thiếu; nó không phải là phương pháp kiểm thử cho mã hoàn chỉnh.
- Hàng trong kế hoạch kiểm thử không có kết quả đầu ra sẽ không điểm. Kiểm thử hồi quy được thực hiện sau mọi thay đổi.
Bạn đã nắm vững
- lỗi cú pháp ngăn chặn quá trình dịch · lỗi thời gian chạy làm chương trình đang chạy bị dừng · lỗi logic vẫn chạy nhưng đưa ra kết quả sai, chỉ tìm thấy qua kiểm thử
- các phương pháp: chạy tay, vùng walkthrough, hộp trắng (từ mã nguồn), hộp đen (từ tài liệu yêu cầu), tích hợp (giao diện, với stubs cho module bị thiếu), alpha (nội bộ), beta (người dùng thực), chấp nhận (khách hàng)
- dữ liệu kiểm thử: bình thường được chấp nhận, bất thường bị từ chối, cực trị là các rìa được chấp nhận, biên là hai bên mỗi rìa; mỗi bài kiểm thử đều có kết quả mong đợi
- bảo trì: sửa lỗi khắc phục, thích ứng cập nhật môi trường, hoàn thiện cải tiến; sửa đổi nhỏ, cập nhật các hàm gọi, kiểm thử hồi quy