Lỗi not responding phâ n mê m chma61 công

Nếu các bạn cài đặt bartender phiên bản mới nhất trên windows 10 sẽ không bị lỗi gì. Tuy nhiên vì thói quen hay lý do nào đấy các bạn cần cài các phiên bản thấp hơn thì sao?

Trong quá trình cài đặt và sử dụng phần mềm thiết kế tem nhãn bartender trên windows 10, chúng ta thường sẽ thấy có những phát sinh lỗi khi cài đặt. Trong bài viết này, Hacode sẽ hướng dẫn các bạn khắc phục tất cả các lỗi hay gặp phải khi cài đặt bartender.

Những lỗi thường phát sinh trong quá trình cài đặt bartender trên windows 10

Có rất nhiều lý do khiến các phiên bản cũ bartender không cài đặt được trên windows 10 nhưng chung lại Hacode nhận thấy chúng ta thường sẽ gặp phải những vấn đề lỗi như sau:

  • Phụ thuộc vào sự phân quyền: bartender sẽ dựa vào cách cấp quyền trên Windows để khởi chạy, và điều này sẽ bị phá vỡ khi bạn sử dụng phần mềm bartender trên một hệ thống khác cao hơn.
  • Phụ thuộc vào các phiên bản cũ của phần mềm: một số phần mềm có thể phụ thuộc vào những thư viện cũ chẳng hạn như .NET framework 3.5 (vì mặc định Windows 10 không được cài sẵn thư viện này).

Khắc phục thế nào ?

Khắc phục lỗi phân quyền quản trị:

Đôi khi việc khắc phục có thể đơn giản chỉ bằng việc chạy phần mềm đó dưới quyền của người quản trị. Để làm được việc này, bạn nhấn phải chuột lên shortcut bartender

Lỗi not responding phâ n mê m chma61 công
và chọn Run as administrator là được, nếu như bạn muốn luôn luôn chạy phần mềm này dưới quyền hạn cao nhất thì thiết lập như sau.

  • Bạn nhấn phải vào ứng dụng và chọn Properties, chuyển sang thẻ Compatibility và đánh dấu chọn vào ô Run this program as an administrator \> OK để hoàn tất.

Lỗi not responding phâ n mê m chma61 công

Khắc phục chế độ tương thích

Windows 10 có một chương trình khắc phục các lỗi tương thích với các tùy chọn cho phép bạn dễ dàng tùy chỉnh. Việc cần làm là bạn kích phải chuột vào biểu tượng của ứng dụng đó chọn Properties > Compatibility > Compatibility mode > Run this program in compatibility mode for.

Lỗi not responding phâ n mê m chma61 công

Từ đây, bạn có thể chạy phần mềm trên các nền tảng Windows khác thấp hơn như Windows 98/XP/vista/7/8.

Khắc phục sự phụ thuộc vào các phiên bản cũ

Windows 10 được cài đặt sẵn .NET framework 4.5. Tuy nhiên khi ta cài đặt phiên bản cũ, bartender lại yêu cầu phiên bản .NET Framework v3.5 cài đặt cùng với phiên bản .NET Framework 4.5. Để khắc phục tình trạng này, bạn nhấn tổ hợp Windows + W, nhập vào từ khóa turn windows features và chọn vào kết quả duy nhất. Trong hộp thoại hiện ra, bạn đánh dấu chọn vào ô .NET Framework 3.5 (include .NET 2.0 and 3.0) rồi bấm OK và chờ một lát để hoàn tất, quá trình này yêu cầu có kết nối mạng để hệ thống tải về các thành phần cần thiết.

Lỗi not responding phâ n mê m chma61 công

Nếu như các bạn thực hiện theo cách trên không được thì có thể tham khảo bài viết dưới đây:

  • Hướng dẫn cài đặt .NET Framework 3.5 Offline trên Windows 10

Trên đây Hacode đã hướng dẫn các bạn chi tiết cách khắc phục các lỗi xảy ra khi cài đặt bartender trên windows 10. Mọi vướng mắc khi cài đặt các bạn có thể để lại comment bên dưới để hacode có thể hỗ trợ giúp các bạn.

Một lỗi phần mềm là một lỗi, lỗ hổng, thất bại, hoặc có lỗi trong một chương trình máy tính hoặc hệ thống đó là nguyên nhân nó tạo ra kết quả không chính xác hoặc không mong muốn, hoặc vận hành theo cách không được định hướng trước.

2. Những thuật ngữ nào mô tả lỗi phần mềm?

Phụ thuộc vào nơi mà bạn được làm việc (như một tester), bạn sẽ sử dụng những thuật ngữ khác nhau để mô tả điều gì sẽ xảy đến khi phần mềm bị lỗi. Dưới đây là một số thuật ngữ: Defect: nhược điểm Fault: khuyết điểm Failure: sự thất bại Anomaly: sự dị thường Variance: biến dị Incident: việc rắc rối *Problem:*vấn đề Error: lỗi Bug: lỗi Feature: đặc trưng Inconsistency: sự mâu thuẫn

Fault, failure và defect có xu hướng ám chỉ một vấn đề thật sự quan trọng, thậm chí là nguy hiểm. Dường như là không đúng khi gọi một biểu tượng (icon) không được tô đúng màu là 1 lỗi (fault). Những từ này cũng thường ám chỉ một lời khiển trách: chính là do nó (fault) mà phát sinh lỗi phần mềm (software failure)

Anomaly, incident, variance thì không có vẻ là quá tiêu cực và thường được sử dụng để đề cập tới sự vận hành không được dự tính trước thay vì hoàn toàn là lỗi (all-out failure).

Có lẽ, Problem, error và bug là những thuật ngữ chung nhất thường được sử dụng, dùng để chỉ sai sót của lập trình viên trong quá trình tạo ra sản phẩm.

3. Quy tắc xác định lỗi phần mềm?

Một lỗi phần mềm xuất hiện khi 1 hoặc nhiều hơn trong 5 quy tắc dưới đây là đúng:

Quy tắc 1: Phần mềm không thực hiện một số thứ giống như mô tả trong bản đặc tả phần mềm Ví dụ: đặc tả của 1 calculator đã nói rõ rằng: nó sẽ thực thi phép cộng, phép trừ, phép nhân, phép chia đúng. Nếu bạn nhận việc kiểm thử phần mềm Calculator, nhấn phím “+” và không có chuyện gì xảy ra, đó chính là một lỗi

Quy tắc 2: Phần mềm thực hiện một số việc mà bản đặc tả yêu cầu nó không được thực hiện Ví dụ: Bản đặc tả phần mềm yêu cầu rằng, calculator sẽ không bao giờ bị đột ngột ngưng hoạt động, bị khóa lại hoặc bị đóng băng. Nếu bạn ấn liên tục lên các phím và nhận được thông điệp từ calculator là “not responding” (dừng quá trình hồi đáp với dữ liệu vào), đây là một lỗi theo quy tắc 2.

Quy tắc 3: Phần mềm thực hiện một số chức năng mà bản đặc tả không đề cập tới Ví dụ: Lập trình viên tự ý thêm vào phép tính căn bậc 2, trong khi đặc tả của calulator chỉ yêu cầu các phép tính cộng, trừ, nhân, chia.

Quy tắc 4: Phần mềm không thực hiện một số việc mà bản đặc tả không đề cập tới, nhưng là những việc nên làm Ví dụ: Bạn mong muốn rằng công việc sẽ được duy trì cho đến khi pin hoàn toàn hết, hoặc ít nhất bằng cách nào đó báo cho bạn biết Pin đã yếu. Những phép tính đúng đã không xảy ra khi pin yếu, và nó cũng không chỉ rõ điều gì sẽ xảy đến. Quy tắc số 4 tạo nên lỗi này.

Quy tắc 5: Trong con mắt của người kiểm thử, phần mềm là khó hiểu, khó sử dụng, chậm đối với người sử dụng Trong trường hợp của calculator, có lẽ bạn đã tìm thấy những nút có kích thước quá nhỏ. Hoặc có thể sự sắp xếp của nút “=” đã làm cho nó khó sử dụng. Hoặc sự bố trí màu sắc làm cho nó rất khó nhìn... Tất cả những điều này đều là lỗi (bug) theo quy tắc 5.

4. Vòng đời của lỗi?

Vòng đời của lỗi là một hành trình mà mà lỗi đi qua trong suốt cuộc đời của nó. Nó thay đổi từ tổ chức này sang tổ chức khác, từ dự án này đến dự án khác và nó được điều chỉnh bởi quy trình kiểm thử phần mềm.

Lỗi not responding phâ n mê m chma61 công

Vòng đời của lỗi bao gồm các trạng thái dưới đây:

New: Khi mà lần lỗi được log lên lần đầu tiên bời người kiểm thử

Assigned: Khi lỗi đã được đăng lên và chỉ định cho lập trình viên nào đó

Open: Khi lập trình viên đang sửa lỗi

Fixed: Khi lập trình viên đã hoàn thành việc sửa lỗi

Retest: Người kiểm thử kiếm tra lại lỗi đã được sửa hay chưa, có phát sinh thêm lỗi mới nào không

Reopened: Nếu lỗi vẫn còn, người kiểm thử sẽ trả lại cho lập trình viên. Lỗi phải đi lại một vòng đời như cũ.

Deferred: Lỗi sẽ được sửa trong bản phát hành tiếp theo. Lý do có thể là độ ưu tiên của lỗi có thể là thấp, thiếu thời gian để phát hành hoặc lỗi có thể không có ảnh hưởng lớn đến phần mềm.

Rejected: Nếu lập trình viên cho rằng không phải là lỗi, họ có thể chuyển sang trạng thái này

Duplicate: Lỗi được đăng trùng với nhau

Closed: Khi người kiểm thử đã thấy lỗi được sửa triệt để

Not a bug/Enhancement: Một số thay đổi trong ứng dụng, không phải là lỗi

5. Mẹo để viết một báo cáo lỗi tốt:

Một trong những kỹ năng quan trọng nhất mà bạn cần có trong hộp công cụ của người kiểm thử nghiệm là khả năng viết một báo cáo lỗi tốt. Việc tìm kiếm lỗi chỉ là một phần của công việc, bởi vì nếu các nhà phát triển không thể phát hiện ra lỗi bạn tìm thấy, họ sẽ gặp khó khăn để khắc phục chúng. Phần mềm theo dõi lỗi của bạn nên bao gồm một số trường bắt buộc để đảm bảo rằng người kiểm thử đưa ra một bản báo cáo đầy đủ về lỗi mà họ gặp phải. Và người kiểm thử nên trau dồi kỹ năng mô tả của họ.

Lỗi not responding phâ n mê m chma61 công

Báo cáo lỗi tốt bao gồm:

TIÊU ĐỀ: Mọi thứ bắt đầu với một tiêu đề. Nó phải rõ ràng để người đọc có một cái nhìn tổng quát ngay trong nháy mắt

NỘI DUNG LỖI: Mô tả phải rõ ràng và súc tích. Nên nhớ rằng người đọc báo cáo của bạn đã không thấy lỗi trước đó.

CÁC BƯỚC TÁI HIỆN LỖI: Cần mô tả cụ thể các bước để tái hiện lỗi. Có thể dùng các công cụ để chụp ảnh, quay phim để làm cho các bước này rõ ràng hơn.

Khi lỗi không xảy ra với tỉ lệ 100% theo các bước bạn mô tả, thì bạn phải cung cấp thông tin đó cho lập trình viên được biết.

KẾT QUẢ HIỆN TẠI: Bạn phải làm rõ kết quả hiện tại như thế nào, khác với kì vọng ra sao. Trường này giúp ngăn ngừa bất kỳ sự hiểu nhầm nào và cho lập trình viên biết chuyện gì đã xảy ra

KẾT QUẢ MONG MUỐN: Bạn cần nêu ra những yêu cầu cụ thể theo như đặc tả ban đầu khi thực hiện các bước bạn đã nêu ra.

PHIÊN BẢN: Bạn cũng cần phải có được phiên bản phần mềm đúng. Đôi khi một lỗi sẽ được khắc phục khi một lỗi khác được giải quyết, hoặc chỉ đơn giản bởi một số thay đổi trong phiên bản mới nhất của phần mềm. Nếu sai phiên bản, lập trình viên có thể mất rất nhiều thời gian để tìm ra lỗi đó.

THÔNG TIN CHI TIẾT: Bạn đang sử dụng thiết bị nào? Hệ điều hành nào đang chạy? Bạn đã sử dụng trình duyệt nào? Mọi chi tiết bạn có thể đưa ra về nền tảng sẽ giúp ích cho các lập trình viên nhanh chóng tái hiện lỗi.

MỨC ĐỘ ƯU TIÊN VÀ MỨC ĐỘ NGHIÊM TRỌNG: Đề cập đến Mức độ ưu tiên và Mức độ nghiêm trọng của lỗi giúp quản lí dự án và lập trình viên biết nên ưu tiên sửa lỗi nào trước.

TÀI LIỆU MINH HỌA: Những tài liệu đính kèm, thường là ảnh chụp màn hình hoặc video, thường được các lập trình viên xem đầu tiên, trước khi đọc các bước mô tả của bạn. Vì vậy ảnh hoặc video minh họa đính kèm sẽ giúp các lập trình viên tiết kiệm nhiều thời gian quý báu!

TAGS & LINKS: Bạn nên sử dụng các thẻ mô tả cho phép bạn lọc cơ sở dữ liệu và tìm các nhóm lỗi liên quan. Đôi khi bạn muốn đưa một ID lỗi hoặc một liên kết trong báo cáo lỗi của bạn lên một cái gì đó mà bạn cảm thấy có liên quan chặt chẽ hoặc tương tự nhưng không tương tự như một bản sao.

ASSIGNEE: Tùy vào quy trình của dự án bạn đang làm, quy định sẽ chỉ định lỗi cho ai.

6. KẾT LUẬN

Đối với người kiểm thử phần mềm, muốn tìm ra lỗi phải hiểu lỗi là gì. Khi đã tìm ra lỗi, việc quan trọng hơn là phải truyền tải nó một các dễ hiểu nhất tới các lập trình viên. Hy vọng bài viết trên sẽ giúp cho bạn có cái nhìn tổng quan về lỗi và cách trình bày lỗi!

Tài liệu tham khảo: https://voer.edu.vn/c/loi-bug-la-gi/4c771e16/32455ae1 http://toolsqa.com/software-testing/defect-life-cycle/