Đã đăng vào thg 9 25, 2017 9:21 SA 11 phút đọc

2.0K

Tại sao phần mềm có bug?

Bài đăng này đã không được cập nhật trong 3 năm

Sofware bug là gì?

Software bug là là lỗi hoặc sai sót khi chương trình tạo ra kết quả không mong muốn hoặc không chính xác. Nó khiến phần mềm bị ngăn cặn không thực hiện giống đặc tả và yêu cầu của phần mềm.

Tại sao phần mềm lại có bug?

Có rất nhiều lý do cho lỗi phần mềm. Lý do phổ biến nhất là những sai lầm của con người trong việc thiết kế phần mềm và mã hóa. Một khi bạn đã biết nguyên nhân gây ra lỗi thì bạn sẽ dễ dàng khắc phục và giảm thiểu các lỗi này.

Dưới đây tôi sẽ chia sẻ 10 lý do mà deverloper hay tester hay mắc phải và cũng có thể bạn cũng dễ mắc phải những điều này.

1. Thiếu hoặc không nhận được thông tin chính xác

Thành công của bất kỳ ứng dụng phần mềm nào đều phụ thuộc vào quá trình giao tiếp giữa các bên liên quan, giữa đội ngũ phát triển và kiểm thử phần mềm. Unclear requirements - Yêu cầu không rõ ràng và giải thích sai các yêu cầu là 2 yêu tố chính gây ra lỗi trong phần mềm.

=> Làm rõ ràng thông tin ngay khi nhận được nó. Đảm bảo tính đúng đắn của thông tin mà bạn nhận được.

2. Phần mềm phức tạp

Sự phức tạp của các ứng dụng hiện tại có thể khó để hiểu cho bất cứ ai không có kinh nghiệm trong việc phát triển phần mềm.Các giao diện kiểu Windows, client-server và distributed applications, cơ sở dữ liệu quan trọng và kích thước các ứng dụng làm tăng size ứng dụng, hệ thống hay việc sử dụng các kỹ thuật hướng đối tượng phức tạp ngay từ ban đầu. => Một dự án được thiết kế kỹ lưỡng ngay từ ban đầu thì sẽ có thể được đơn giản hóa đi rất nhiều.

3. Lỗi lập trình

Các lập trình viên thì cũng giống như bất kỳ con người nào trên thế giới và đều có thể mắc lỗi. Không phải tất cả nhà phát triển đều là chuyên gia. Các lập trình viên thiếu kinh nghiệm hoặc kiến thức không tốt có thể mắc những sai lầm trong khi code. Hoặc họ không có giải pháp để viết dòng code đơn giản, hay kiểm tra hay gỡ lỗi. Đó cũng là 1 lý do phổ biến cho hầu hết các vấn đề trong giai đoạn phát triển

=> Hãy học hỏi và áp dụng những công nghệ mới nhất vào dòng code của mình. Nhưng cần đảm bảo được chất lượng dòng code của mình.

4. Yêu cầu thay đổi liên tục

Khách hàng họ không hiểu hoặc có thể hiểu được tác động của những thay đổi, thiết kế lại phần mềm, thay đổi kế hoạch, thời gian khi mà yêu cầu từ ban đầu bị thay đổi. Khi mà công việc từ yêu cầu ban đầu đã xong nhưng vẫn bị ném đi hoặc yêu cầu chỉnh sửa, thay đổi to hay nhỏ thì đều ảnh hưởng tới phần mềm và dễ dàng dẫn đến lỗi phần mềm khi lập trình viện không thể giải quyết hết những vấn đề liên quan, hoặc không thể nhận ra những thay đổi có tầm ảnh hưởng tới chức năng khác như thế nào. Lý do này ngày càng trở nên phổ biến trong hiện nay.

=> Trong môi trường hiện nay, các yêu cầu liên tục được thay đổi để phù hợp hơn với cuộc sống và nó cũng là một thực tế. Trong trường hợp này thì người quản lý cần đưa ra những rủi ro khi sửa đổi, QA và DEV cần phải lên kế hoạch cho việc phát triển và kiểm thử những thay đổi này để không bị ảnh hưởng hay gây lỗi cho chức năng liên quan.

5. Hạn chế thời gian

Việc lên kế hoạch cho các dự án phần mềm là khó khăn nhất, thường là những tính toán phỏng đoán. Khi deadline đến và khủng hoảng xảy ra, sẽ có những sai lầm. Scheduling được lên trước và dựa theo kinh nghiệm của lập trình viên, kiểm thử viên, thiết kế phần mềm. Nếu như họ không thể đảm bảo được đúng theo kế hoạch đã gửi khách hàng ban đầu, họ sẽ không đủ thời gian để code, kiểm tra, thiết kế dự án một các đúng đắn thì khi đó dự án sẽ sót bug.

=> Bạn nên estimate thời gian theo từng phần nhỏ của công việc, như vậy sẽ đảm bảo cho plan của bạn theo đúng tiến độ mà bạn đề ra.

6. Người tự tin thái quá

Một số người này thường hay cho rằng những thay đổi yêu cầu trong dự án là :

K vấn đề
Chuyện nhỏ
Làm tý thì xong …
Thay đổi code cũ chút là xong... Nhưng dù có thay đổi nhỏ nhặt không phức tạp thì chúng ta vẫn nên cẩn thận vẫn hơn

=> Thay vì cách nghĩ trên thì nên nghĩ rằng:

Vấn đề này rất phức tạp,chúng ta sẽ dễ dàng mắc nhiều lỗi
Tôi không thể estimate thời gian hoàn thành nó trong bao lâu,...
Chúng ta không thể hiểu được những dòng code cũ,...

7. Tài liệu code nghèo nàn

Thật khó khăn trong việc duy trì và sửa đổi code cũ hay code kém. Kết quả là lỗi phần mềm. Trong dự án thì quản lý sẽ yêu cầu dev viết tài liệu hoặc code rõ ràng dễ hiểu, nhưng thực tế thì điều đó khó thực hiện được. Họ chỉ quan tâm làm sao nhanh chóng hoàn thành công việc, và code đó là an toàn nếu không ai khác có thể hiểu được.
Bất kỳ lập trình viên mới bắt đầu làm việc trên dòng code này thì có thể bị lẫn lỗn do sự phức tạp của dự án và tài liệu kém. Họ sẽ phải mất nhiều thời gian hơn để học và thực hiện những thay đổi nhỏ trong dòng code này

=> Tạo thói quen viết tài liệu cho dòng code của mình, đon giản hóa dòng code của mình.

8. Công cụ phát triển phần mềm

Visual tools, class libraries, compilers, scripting tools,...thường đưa ra lỗi của họ nhưng docmented ghi chép lại thì sơ xài, dẫn đến người dùng khi dùng công cụ trên thì vẫn gặp lỗi. Thay đổi liên tục công cụ phần mềm thường được lập trình viên sử dụng. Giữ tiến độ giữa các versions khác nhau và tính tương thích của chúng cũng chính là một vấn đề.

=> Khi thay đổi versions của công cụ bạn cần đảm bảo những nơi bạn dùng công cụ đều không bị lỗi, hạn chế update versions theo trào lưu.

9. Kịch bản tự động hóa lỗi thời

Viết kịch bản test tự động mất rất nhiều thời gian, đặc biệt là các kịch bản phức tạp. Nếu các nhóm tự động record/write bất kỳ kịch bản kiểm thử nào nhưng quên không cập nhật nó trong 1 khoảng thời gian thì kịch bản test có thể bị lỗi thời. Nếu các kịch bản test tự động không phải là xác nhận dựa trên yêu cầu đúng đắn nhất thì nó không thể kiểm tra hết các lỗi được.

=> Thường xuyên cập nhật kịch bản test tự động, nếu không có thời gian cập nhật thì chỉ nên kế thừa kịch bản test này.

10. Kinh nghiệm test còn non kém

Tester có tay nghề với kiến thức là vô cùng quan trọng cho sự thành công của bất kỳ dự án. Nhưng việc chỉ định tất cả các tester có kinh nghiệm là không thể cho tất cả các công ty.

=> Kiến thức và khả năng tìm lỗi tốt có thể tạo ra phần mềm chất lượng cao. Các Tester ít kinh nghiệm có làm việc cặp cùng với một Tester kinh nghiệm để đảm bảo chất lượng phần mềm, vừa tăng kinh nghiệm của những Tester non kém. Và quan trọng họ cần phải tự bổ sung kiến thức còn thiếu của bản thân mình. Một vài lý do cũng có thể sẽ ảnh hưởng tới chất lượng phần mềm:

Không có môi trường test
Viết code hoặc test case mà không hiểu rõ yêu cầu
Thiết kế không chính xác dẫn đến các vấn đề trong tất cả các giai đoạn của quy trình phát triển phần mềm
Releasing software và các bản vá phần mềm mà không cần tuân theo vòng đời phát triển phần mềm
Không đào tạo nguồn lực có kỹ năng cần thiết để phats triển hay kiểm thử phần mềm
Không dành thời gian cho kiểm thử hồi quy
Không ưu tiên việc kiểm thử
Thay đổi trong phút chót

Trên đây là một vài lý do mà chúng ta thường mắc phải khi làm trong dự án. Có thể còn nhiều lỗi khác, các bạn có thể cũng nhau chia sẻ trong phần comment của bài viết này.

Link bài viết http://www.softwaretestinghelp.com/why-does-software-have-bugs/

bugs Tester