Software ERROR LỖI PHẦN mềm là gì

LỖI PHẦN MỀM LÀ GÌ
Một định nghĩa chung về lỗi phần mềm là sự không phù hợp giữa chương trình và
đặc tả của nó. Không sử dụng định nghĩa này.
Sự không phù hợp giữa chương trình và đặc tả của nó là một lỗi trong chương trình
chỉ khi đặc tả tồn tại và nó đúng.
Dưới đây là hai định nghĩa tốt hơn: • Một lỗi phần mềm có mặt khi chương trình
không làm những gì người sử dụng cuối có thể kỳ vọng nó làm (Myers, 1976, trang
6).
• Không bao giờ có thể có một định nghĩa tuyệt đối cho lỗi, cũng không xác định
tuyệt đối sự tồn tại của chúng. Mức độ mà một chương trình có lỗi được đo bằng
mức độ mà nó không hữu ích. Đây là một phương pháp cơ bản của con người
(Beizer, 1984, trang 12). Myers (1976) đã loại trừ rõ ràng "các sai sót về nhân tố
con người" từ định nghĩa của ông về các lỗi phần mềm. Chúng tôi thấy đây chỉ là
một nhóm sai sót. Có thể khó thuyết phục được một lập trình rằng lỗi giao diện
người dùng là lỗi hoặc điều đó quan trọng hoặc người kiểm tra có quyền nói với
anh ta về điều đó, nhưng khách hàng phàn nàn về các lỗi yếu tố con người nghiêm
trọng như khi họ phàn nàn về tai nạn.
CÁC LOẠI LỖI PHẦN MỀM
Chúng tôi mô tả 13 loại chính. Không có gì là hoàn toàn chính xác về phân loại
này. Chẳng hạn, Beizer's (1990) là một cí dụ rất hữu ích và khá khác biệt.
LỖI GIAO DIỆN NGƯỜI DÙNG Có nhiều cách để làm cho một chương trình khó
khăn khi làm việc. Chúng tôi gộp chúng dưới tiêu đề "giao diện người dùng". Dưới
đây là một số danh mục con:
Một chương trình có vấn đề về chức năng nếu nó không làm điều đúng điều nó nên
làm, hoặc nó lúng túng hoặc không làm đầy đủ. Những thông số kĩ thuật xác định
chức năng của một chương trình cho một nhóm thực hiện, nhưng định nghĩa cuối
cùng về những gì một chương trình được "cho là" tâm huyết của người người làm.
Tất cả các chương trình sẽ có vấn đề về chức năng bởi vì những người dùng khác
nhau có những mong đợi khác nhau. Bạn không thể đoán trước được kỳ vọng của

mọi người. Có thể bạn không thể đáp ứng được nhu cầu của mọi người mà không
làm giảm tính đơn giản và toàn vẹn khái niệm của chương trình.
Một chương trình có vấn đề về chức năng nếu như chương trình đó làm người
dùng khó khăn, lúng túng, khó hiểu, hoặc không thể. Vấn đề này là một lỗi chức
năng nếu kỳ vọng của người dùng là hợp lý.
Giao tiếp: Làm thế nào để bạn tìm hiểu và làm thế nào để sử dụng chương trình?
Những thông tin nào có sẵn trên màn hình? Chừng này đã đủ chưa? Nó có thể hiểu
được? Có xúc phạm không? Bạn đã nói gì khi bạn phạm sai lầm hoặc bạn cần giúp
đỡ? Nó khá hữu ích? Có chính xác không? Có điều gì gây kích thích, gây hiểu
nhầm, gây nhầm lẫn hoặc trình bày không tốt?
Về cấu trúc câu lệnh: Dễ dàng bị lạc trong chương trình? Có bất kỳ lệnh nào khó
hiểu hoặc dễ gây nhầm lẫn với người khác? Bạn làm gì sai lầm, những gì bạn tốn
thời gian, và tại sao?
Về thiếu câu lệnh: Những gì còn thiếu? Chương trình có buộc bạn phải suy nghĩ
một cách cứng nhắc, không tự nhiên hoặc không hiệu quả? Bạn có thể tùy chỉnh nó
cho phù hợp với phong cách làm việc hoặc nhu cầu của bạn? Khả năng tùy biến
cho một chương trình như thế này quan trọng như thế nào?
Hiệu suất: Tốc độ là bản chất của phần mềm tương tác. Bất cứ điều gì làm cho
người dùng nghĩ rằng chương trình đang làm việc chậm là một vấn đề.
Đầu ra: Hầu hết các chương trình hiển thị, in, biểu đồ, hoặc lưu thông tin. Bạn sử
dụng hầu hết các chương trình để có được những kết quả này. Bạn có nhận được
những gì bạn muốn? Làm các bản in có ý nghĩa? Bạn có thể đọc đồ thị không?
Chương trình sẽ lưu dữ liệu theo một định dạng mà một chương trình khác có thể
đọc? Bạn có thể điều chỉnh sản lượng phù hợp với nhu cầu của bạn? Bạn có thể
chuyển hướng đầu ra đến sự lựa chọn của bạn về thiết bị đầu cuối, máy in hoặc tệp
tin?
XỬ LÍ LỖI
Xử lý lỗi bao gồm dự đoán được khả năng lỗi và bảo vệ chúng, thông báo các điều
kiện lỗi, và xử lý được một lỗi đã phát hiện một cách hợp lý. Nhiều chương trình
phát hiện chính xác lỗi nhưng sau đó phân nhánh theo thói quen phục hồi lỗi mà

không kiểm tra. Những lỗi thường gặp này có thể gây ra nhiều thiệt hại hơn vấn đề
ban đầu.
RANH GIỚI – LIÊN QUAN ĐẾN LỖI
Các ranh giới đơn giản nhất là số, giống như những cái được thảo luận trong ví dụ
đầu tiên trong chương 1. Nhưng việc sử dụng đầu tiên của một chương trình cũng
là một điều kiện biên. Số lượng lớn nhất và nhỏ nhất của bộ nhớ mà một chương
trình có thể đối phó được là ranh giới. Nếu có bất kỳ khía cạnh nào trong việc sử
dụng hoặc hoạt động của chương trình có thể được mô tả là chạy từ nhiều hơn đến
nhỏ hơn, từ lớn nhất đến nhỏ nhất, sớm nhất đến mới nhất, trước hết là từ trước,
ngắn gọn nhất đến dài nhất, bạn có thể kiểm tra ranh giới ở các biên của các phạm
vi của các giá trị. Trong ranh giới, chương trình hoạt động tốt. Tại hoặc ngoài các
ranh giới, chương trình có thể croak.
DỰ ĐOÁN LỖI
Số học khó khăn và dễ bị lỗi trong một số ngôn ngữ. Nhiều khả năng, chương trình
sẽ giải thích sai các công thức phức tạp. Nó cũng có thể mất độ chính xác vì nó
tính, do làm tròn và cắt xén các lỗi. Sau nhiều tính toán trung gian, nó có thể khẳng
định rằng 2 + 2 là -1, mặc dù không có bước trung gian nào có sai sót logic. Danh
mục này cũng bao gồm các lỗi tính toán do các thuật toán không chính xác. Chúng
bao gồm việc sử dụng các công thức, công thức không phù hợp với dữ liệu và phá
vỡ biểu thức phức tạp thành các thành phần sử dụng các quy tắc không chính xác.
Trong lỗi thuật toán, mã thực hiện chính xác những gì lập trình đã có trong tâm trí.
MỞ ĐẦU VÀ BỔ SUNG
Một chức năng có thể không thành công trong lần đầu tiên bạn sử dụng nó. Lần
đầu tiên, bạn có thể nhận được hiển thị kỳ lạ, tính toán sai, các vòng lặp vô hạn,
hoặc các thông báo lỗi bộ nhớ ngoài. Một số trong số này quay trở lại mỗi khi bạn
khởi động lại chương trình. Các chương trình xấu nhất sẽ lưu trữ thông tin khởi tạo
vào đĩa và chỉ thất bại khi sử dụng lần đầu tiên - trước khi tạo tệp khởi tạo. Sau khi
bạn sử dụng chương trình một lần, bạn không thể tìm thấy những lỗi mà không có

một bản sao mới của chương trình. Điều này có vẻ vô hại cho đến khi bạn nhận ra
rằng tất cả các khách hàng của bạn sẽ bắt đầu với một bản sao mới của chương
trình. Các lập trình cũng đôi khi quên rằng bạn có thể sao lưu ở giữa một thói quen,


để cố gắng thay đổi một cái gì đó bạn đã làm trước đó. Nếu mọi thứ được thiết lập
trong lần đầu tiên bạn sử dụng một phần của chương trình, điều gì sẽ xảy ra nếu
bạn trở lại phần đó? Liệu nó đặt lại tất cả mọi thứ để không? Bạn vừa mất tất cả dữ
liệu?
LUỒNG QUẢN LÝ LỖI
Luồng kiểm soát của một chương trình mô tả những gì nó sẽ làm gì tiếp theo, trong
những trường hợp nào. Một lỗi điều khiển xảy ra khi chương trình làm điều sai trái
tiếp theo. Các lỗi kiểm soát cực đoan dừng chương trình hoặc làm cho nó chạy
loạn xạ. Lỗi rất đơn giản có thể dẫn đến các chương trình để hành vi sai trái ngoạn
mục.
LỖI TRONG XỬ LÍ VÀ GIẢI THÍCH DỮ LIỆU
Một mô-đun có thể truyền dữ liệu sang mô-đun khác hoặc cho một chương trình
khác. Một bộ dữ liệu có thể được truyền qua lại nhiều lần. Trong quá trình này, nó
có thể bị hỏng hoặc bị giải thích sai. Các thay đổi gần đây nhất đối với dữ liệu có
thể bị mất hoặc có thể đến một số bộ phận của hệ thống nhưng không phải là
những thứ khác.
ĐIỀU KIỆN KẾT QUẢ
Cuộc đua cổ điển là giữa hai sự kiện, gọi chúng là A và B. Hoặc A hoặc B có thể
xảy ra tiếp theo. Nếu A đến trước, chương trình hoạt động. Nếu B xảy ra trước A,
chương trình không thành công vì nó mong đợi A luôn xuất hiện trước B. Người
lập trình không nhận ra rằng B có thể thực hiện trước chỉ trong điều kiện đặc biệt.
Các điều kiện về “ kết quả nằm trong số những thử nghiệm ít nhất. Mong đợi các
điều kiện kết quả trong các hệ thống đa xử lý và các hệ thống tương tác (các hệ
thống đáp ứng hầu hết người sử dụng đầu vào gần như ngay lập tức). Họ rất khó để
nhân rộng, đặc biệt là nếu người kiểm tra không nhạy cảm với các vấn đề thời gian.

Họ đã dẫn đến nhiều báo cáo về lỗi "không thể khắc phục được".
ĐIỀU KIỆN TẢI
Chương trình có thể không hoạt động khi quá tải. Nó có thể thất bại trong một
khối lượng lớn (nhiều công việc trong một thời gian dài) hoặc căng thẳng cao (tải
tối đa cùng một lúc). Nó có thể thất bại khi nó hết bộ nhớ, máy in, hoặc các tài


nguyên khác, hoặc khi nó cố gắng chia sẻ bộ nhớ hoặc thời gian CPU với các
chương trình khác hoặc giữa hai thói quen của riêng mình. Tất cả các chương trình
có giới hạn. Các vấn đề là liệu chương trình có thể đáp ứng các giới hạn được nêu
ra và làm thế nào khủng khiếp nó chết khi giới hạn được vượt quá.
PHẦN CỨNG
Các chương trình gửi dữ liệu không hợp lệ đến thiết bị, bỏ qua các mã lỗi trở lại và
cố gắng sử dụng thiết bị đang bận hoặc không ở đó. Ngay cả khi phần cứng bị
hỏng, phần mềm cũng bị hỏng nếu nó không nhận diện và phục hồi từ sự thất bại
của phần cứng.
NGUỒN VÀ KIỂM SOÁT PHIÊN BẢN
Các vấn đề cũ lại xuất hiện nếu người lập trình liên kết một phiên bản cũ của một
chương trình con với phiên bản mới nhất của phần còn lại của chương trình. Bạn
phải biết (ai đó phải biết) phiên bản của từng phần của một chương trình đang
được sử dụng hoặc giao cho khách hàng.
Ai đó cũng phải đảm bảo rằng chương trình có bản quyền chính xác, màn hình
đăng nhập và số phiên bản. Cần phải kiểm tra hàng chục chi tiết nhỏ.
Việc thực thi các tiêu chuẩn "nguồn và phiên bản" thường được ủy quyền cho các
nhóm Bảo đảm chất lượng. Theo quan điểm của chúng tôi, việc xác định các vấn
đề kiểm soát nguồn và phiên bản là một chức năng kiểm tra, thực thi 66
TÀI LIỆU
Tài liệu không phải là phần mềm nhưng nó là một phần của sản phẩm phần mềm.
Tài liệu kém có thể dẫn người dùng tin rằng phần mềm không hoạt động chính xác.
Thảo luận chi tiết về lỗi tài liệu vượt quá phạm vi của cuốn sách này, nhưng thử

nghiệm tài liệu được thảo luận trong Chương 10.
LỖI KIỂM THỬ
Cuối cùng, nhưng chắc chắn không kém: nếu một lập trình viên làm cho một và
một nửa lỗi trên mỗi dòng mã, bạn sẽ thực hiện bao nhiêu lần kiểm tra? Lỗi do
người kiểm thử gây ra là một trong số những lỗi phổ biến nhất được phát hiện
trong quá trình kiểm thử. đừng quên rằng một số lỗi của bạn phản ánh các vấn đề


trong giao diện người dùng của chương trình. Nếu chương trình dẫn bạn làm sai,
nó có vấn đề thiết kế. Lỗi của bạn cũng là dữ liệu thử nghiệm.