Các định nghĩa và thuật ngữ trong kiểm thử phần mềm (Phần 2)

Các định nghĩa và thuật ngữ trong kiểm thử phần mềm (Phần 2)

(Link phần 1: https://viblo.asia/nguyen.thu.phuong/posts/MJyGjQlqvPB)

H

Hazard analysis - Phân tích nguy hại: Một kỹ thuật được sử dụng để mô tả các yếu tố rủi ro (risk). Kết quả của phân tích nguy hại sẽ điều khiển các phương pháp sẽ được sử dụng để phát triển và kiểm thử hệ thống.

I

Impact analysis - Phân tích ảnh hưởng: Việc đánh giá sự thay đổi tác động đến các tầng trong tài liệu phát triển, tài liệu kiểm thử và các thành phần, tác động đến tài liệu đặc tả.

Incident - Sự cố: Sự kiện bất kỳ xảy ra mà được yêu cầu điều tra.

[After IEEE 1008]

Incremental testing - Kiểm thử tăng dần: Kiểm thử tại nơi các thành phần hoặc hệ thống đã được tích hợp và kiểm thử một hoặc nhiều lần, cho đến khi tất cả các thành phần hoặc hệ thống được tích hợp và kiểm thử.

Independence of testing - Tính độc lập của kiểm thử: Phân chia nhiệm vụ từng phần nhằm khuyến khích hoàn thành mục tiêu kiểm thử.

[After DO-178b]

Informal review - Xem xét không chính thức: Một xem xét không được dựa trên một tài liệu chính thức.

Inspection - Kiểm tra: Một dạng đánh giá ngang hàng được dựa trên kiểm tra trực quan tài liệu để phát hiện khiếm khuyết (defect).

Integration - Tích hợp: Quá trình kết hợp các thành phần hoặc các hệ thống thành một tổ hợp lớn hơn.

Integration testing - Kiểm thử tích hợp: Kiểm thử được thực thi để phát hiện khiếm khuyết (defect) trong giao diện và trong tương tác giữa các thành phần hoặc hệ thống được tích hợp.

Interface testing - Kiểm thử giao diện: Tích hợp các loại kiểm thử có liên quan đến kiểm thử giao diện giữa các thành phần và các hệ thống.

Invalid testing - Kiểm thử không hợp lệ: Kiểm thử sử dụng giá trị đầu vào mà sẽ bị từ chối bởi thành phần hoặc hệ thống.

K

Keyword driven testing - Kiểm thử theo từ khóa: Một kịch bản kỹ thuật sử dụng bộ dữ liệu có chứa không chỉ dữ liệu kiểm thử và mong muốn đầu ra, nhưng còn bao gồm từ khóa liên quan đến ứng dụng được kiểm thử. Các từ khóa này đã được ghi nhớ bởi kịch bản hỗ trợ đặc biệt được gọi từ kịch bản điều khiển (control script) cho kiểm thử.

L

Load testing - Kiểm thử tải: Một loại kiểm thử hiệu năng được thực hiện để đánh giá hành vi vủa thành phần hay hệ thống khi tăng dần tải.

Ví dụ: Số người sử dụng song song và/ hoặc số giao dịch, để xác định ngưỡng tải có thể xử lý được bởi các thành phần hoặc hệ thống.

M

Maintenance - Bảo trì: Biến đổi một sản phẩm phần mềm sau khi bàn giao để sửa chữa khiếm khuyết, để nâng cao hiệu năng hoặc thuộc tính khác, hoặc để thích ứng sản phẩm đối với việc môi trường bị biến đổi.

[IEEE1219]

Maintenance testing - Kiểm thử bảo trì: Kiểm thử các thay đổi đến hoạt động của hệ thống hoặc ảnh hưởng của một môi trường thay đổi đến hoạt động của hệ thống.

Memory leak - Rò rỉ bộ nhớ: Một khiếm khuyết trong kho động của chương trình là nguồn gốc của lỗi đòi lại bộ nhớ sau khi đã hoàn thành việc sử dụng, khiến cho chương trình gặp lỗi do thiếu bộ nhớ.

Monkey testing: Kiểm thử bằng cách lựa chọn ngẫu nhiên từ phạm vi rộng lớn của yếu tố đầu vào và bởi đẩy ngẫu nhiên các nút (button), kiểm thử như không có sự hiểu biết nào về sản phẩm.

Multiple condition coverage - Nhiều điều kiện bao phủ: Tỷ lệ kết hợp của tất cả điều kiện đầu ra duy nhất trong một statement được thực hiển bởi bộ kiểm thử (test suite). 100% điều kiện bao phủ (condition coverage) bao hàm 100% điều kiện bao phủ quyết định (condition determination coverage).

N

Negative testing - Kiểm thử tiêu cực: Các kiểm thử nhằm cho thấy rằng một thành phần hoặc một hệ thống không làm việc. Kiểm thử tiêu cực liên quan đến thái độ của các tester chứ không phải tiếp cận đặc tả kiểm thử hoặc kỹ thuật thiết kế kiểm thử.

Ví dụ: Kiểm thử với giá trị đầu vào không hợp lệ hoặc exeception.

Non-functional requirement - Yêu cầu phi chức năng: Một yêu cầu mà không liên quan đến chức năng, nhưng liên quan đến các thuộc tính như là độ tin cậy (reliability), hiệu quả (efficiency), tính khả dụng (usability), tính bảo trì (maintainability) và tính di động (portability).

Non-functional testing - Kiểm thử phi chức năng: Kiểm thử các thuộc tính của thành phần hoặc hệ thông mà không liên quan đến chức năng.

Ví dụ: Độ tin cậy (reliability), hiệu quả (efficiency), tính khả dụng (usability), tính bảo trì (maintainability) và tính di động (portability).

Non-functional test design techniques - Kỹ thuật thiết kế kiểm thử phi chức năng: Quy trình để lấy được và/ hoặc lựa chọn test case cho kiểm thử phi chức năng dựa trên phân tích đặc tả của thành phần hoặc hệ thống mà không tham chiếu đến cấu trúc bên trong của nó. (Kỹ thuật thiết kế kiểm thử Blackbox).

O

Output - Đầu ra: Một biến (dù nơi lưu trữ là một thành phần hay bên ngoài) được viết bởi một thành phần.

P

Pair testing - Cặp kiểm thử: Hai người (ví dụ: hai tester, một dev và một tester, hoặc một người dùng và một tester,...) làm việc cùng nhau để tìm ra khiếm khuyết. Thông thường, họ chia sẻ chung một máy tính và kiểm soát thương mại nó trong kiểm thử.

Pairwise testing - Kiểm thử theo cặp: Kỹ thuật thiết kế kiểm thử black box với test case được thiết kế để thực thi tât cả kết hợp riêng rẽ có thể có của mỗi cặp thông số đầu vào.

Pass - Đạt: Một kiểm thử được coi là vượt qua nếu kết quả thực tế của nó phù hợp với kết quả mong đợi của nó.

Pass/fail criteria - Tiêu chí đạt/ không đạt: Các quy tắc quyết định được sử dụng để xác định xem một mục kiểm thử (chức năng) hoặc tính năng đã đạt hay chưa đạt.

[IEEE 829]

Path - Đường dẫn: Một chuỗi các sự kiện, ví dụ thực thi statement, của một thành phần hoặc hệ thống từ một điểm đầu vào đến một điểm kết thúc.

Path coverage - Đường dẫn bao phủ: Tỷ lệ đường dẫn mà đã được thực thi bỏi bộ kiểm thử (test suite). 100% đường dẫn bao phủ (path coverage) bao gồm 100% LCSAJ bao phủ (LCSAJ coverage).

Peer review - Đánh giá ngang hàng: Một đánh giá về làm việc của phần mềm bởi các đồng nghiệp cùa nhà sản xuất sản phẩm nhằm mục đích xác định khiếm khuyết và cải tiến.

Ví dụ: Thanh tra (inspection), đánh giá kỹ thuật (technical review) và walkthrough.

Priority - Độ ưu tiên: Mức của (kinh doanh) quan trọng được phân chia cho mỗi mục.

Procedure testing - Quy trình kiểm thử: Kiểm thử nhằm đảm bảo rằng các thành phần hoặc hệ thống có thể hoạt động khi kết hợp với các quy trình kinh doanh của người dùng mới hoặc quy trình hiện tại.

Process - Quá trình: Một tập hợp các hoạt động liên quan đến nhau, chuyển đổi đầu vào thành đầu ra.

[ISO 12207]

Product risk - Sản phẩm rủi ro: Một nguy cơ liên quan trực tiếp đến đối tượng kiểm thử.

Project risk - Rủi ro dự án: Một nguy cơ liên quan đến quản lý và kiểm soát các dự án (kiểm thử). Ví dụ: Thiếu nhân sự, thời gian chặt chẽ, thay đổi yêu cầu, ...

Q

Qualification - Trình độ chuyên môn: Quá trình chứng minh khả năng thực hiện các yêu cầu đặc tả. Thuật ngữ "đủ điều kiện (qualified)" được sử dụng để chỉ tình trạng tương ứng.

[ISO 9000]

Quality - Chất lượng: Mức độ mà một thành phần, hệ thống hoặc quy trình đáp ứng yêu cầu đặc tả và/ hoặc được khách hàng/ người dùng cần và mong đợi.

[After IEEE 610]

Quality assurance - Đảm bảo chất lượng: Một phần của quản lý chất lượng tập trung vào việc chắc chắn đã cung cấp đầy đủ yêu cầu chất lượng.

[ISO 9000]

R

Random testing - Kiểm thử ngẫu nhiên: Một kỹ thuật kiểm thử hộp đen với test case được lựa chọn, có thể sử dụng ngẫu nhiên một thuật toán giả định, để phù hợp với cấu hình hoạt động. Kỹ thuật này có thể sử dụng để kiểm thử các thuộc tính phi chức năng như là độ tin cậy (reliability ) và hiệu năng (performance).

Regression testing - Kiểm thử hồi quy: Kiểm thử một chương trình thử nghiệm trước theo thay đổi để chắc chắn rằng khiếm khuyết (defect) đã không xảy ra hoặc được phát hiện trong khu vực không bị thay đổi của phần mềm, như là kết quả của sự thay đổi. Nó thực thi khi phần mềm hoặc môi trường của nó được thay đổi.

Release note - Lưu ý bàn giao: Một tài liệu xác định các mục kiểm thử, cấu hình, tình trạng hiện tại và thông tin bàn giao khác được cung cấp bởi phát triển để kiểm thử, và có thể từ các bên liên quan, vào lúc bắt đầu của một giai đoạn thực thi kiểm thử.

[After IEEE 829]

Requirement - Yêu cầu: Một điều kiện hoặc khả năng cần thiết bởi người sử dụng để giải quyết vấn đề hoặc đạt được một mục tiêu mà phải đáp ứng hoặc sở hữu bởi một hệ thống hoặc thành phần hệ thống để đáp ứng một hợp đồng, tiêu chuẩn, đặc tả, hoặc áp dụng một tài liệu chính thức khác.

[After IEEE 610]

Requirements-based testing - Yêu cầu dựa trên kiểm thử: Một cách tiếp cận để kiểm thử bằng cách test case được thiết kế dựa trên mục tiêu kiểm thử và điều kiện kiểm thử xuất phát từ yêu cầu. Ví dụ: Kiểm thử thực thi đặc tả chức năng hoặc thăm dò thuộc tính phi chức năng như là độ tin cậy (reliability ) hoặc tính khả dụng (usability).

Re-testing - Kiểm thử lại: Kiểm thử chạy các test case mà đã bị thất bại tại thời điểm chạy trước đó, để xác minh rằng đã thành công sau các hành động khắc phục.

Review - Xem xét: Một đánh giá tình trạng của sản phẩm hoặc trạng thái của dự án để xác định sự khác biệt từ kế hoạch (plan) và để đưa ra cải tiến. Ví dụ bao gồm xem xét quản lý (management review), xem xét (review), xem xét kỹ thuật (technical review), kiểm tra (inspection), và walkthrough.

[After IEEE 1028]

Risk - Rủi ro: Một yếu tố có thể dẫn đến những hậu quả tiêu cực trong tương lai, thường được diễn tả như một ảnh hưởng.

Risk analysis - Phân tích rủi ro: Quá trình đánh giá rủi ro được xác định để ước tính ảnh hưởng của nó và khả năng xảy ra (likehood).

Risk-based testing - Rủi ro dựa trên kiểm thử: Một cách tiếp cận để kiểm thử làm giảm mức độ rủi ro của sản phẩm và thông báo đến các bên liên quan trạng thái của chúng, bắt đầu trong giai đoạn đầu của dự án. Nó liên quan đến việc xác định rủi ro sản phẩm và việc hướng dẫ sử dụng chúng trong quá trình thử nghiệm.

Root cause - Nguyên nhân gốc rễ: Một nguồn của một khiếm khuyết (defect) được loại bỏ, làm giảm hoặc loại bỏ sự xuất hiện của các loại khiếm khuyết (defect).

[CMMI]

Root cause analysis - Phân tích nguyên nhân gốc rễ: Một kỹ thuật phân tích nhằm xác định nguyên nhân gốc rễ của khiếm khuyết (defect). Bằng cách chỉ đạo các biện pháp khắc phục, với hi vọng rằng khả năng khiếm khuyết tái phát được giảm thiểu.

S

Security - An toàn: Thuộc tính của sản phẩm phần mềm dựa trên khả năng của mình để ngăn chặn sự truy cập trái phép, dù vô tình hay cố ý đến các chương trình hoặc dữ liệu.

[ISO 9126]

Security testing - Kiểm thử an toàn: Kiểm thử để xác định độ an toàn của sản phẩm phần mềm.

Severity - Mức độ nghiêm trọng: Mức độ ảnh hưởng của một khiếm khuyết bên trong phát triển hoặc hoạt động của thành phần hoặc hệ thống.

Smoke test: Một tập hợp của tất cả các định nghĩa/ kế hoạch về test case mà bao phủ chức năng chính của thành phần hoặc hệ thống, để xem xét các chức năng quan trọng nhất của chương trình làm việc, nhưng không quan tâm đến các mục chi tiết. Bản build hàng ngày được kiểm thử smoke là việc làm tốt nhất.

Software life cycle - Vòng đời phần mềm: Khoảng thời gian bắt đầu từ khi dự án được hình thành và kết thúc khi phần mềm không có sẵn để sử dụng. Vòng đời phần mềm thường bao gồm một giai đoạn khái niệm (concept phase), giai đoạn yêu cầu (requirements), giai đoạn thiết kế (design), giai giai đoạn thực thi (implementation), giai đoạn kiểm thử (test), cài đặt và bàn giao (installation & checkout), giai đoạn vận hành và bảo trì (operation & maintenance), thỉnh thoảng bao gồm cả giai đoạn nghỉ hưu (retirement phase). Lưu ý các giai đoạn này có thể chồng lên nhau hoặc được thực thi lặp đi lặp lại.

State diagram - Sơ đồ trạng thái: Một sơ đồ mô tả các trạng thái mà một thành phần hoặc hệ thống có thể giả định, và cho thấy các sự kiện hay hoàn cảnh gây ra và /hoặc kết quả của một sự thay đổi từ một phần nhỏ.

Statement coverage - Bao phủ trạng thái: Tỷ lệ báo cáo thực thi đã được thực hiện bởi một bộ kiểm thử (test suite).

Static testing - Kiểm thử tĩnh: Kiểm thử một thành phần hoặc hệ thống với đặc tả hoặc thực thi mức độ mà không cần thực thi sản phẩm đó.

Ví dụ: xem xét (review) hoặc phân tích code tĩnh (static code analysis)

Stress testing - Kiểm thử căng thẳng: Một loại kiểm thử hiệu năng được thực hiện để đánh giá một hệ thống hay thành phần tại giới hạn của tải trọng hoặc dự đoán đặc tả tải của nó, hoặc giảm thiểu các nguồn sẵn có như là truy cập bộ nhớ hoặc server.

[After IEEE 610]

Stub: Việc triển khai khung hoặc mục đích đặc biệt của thành phần phần mềm, sử dụng để phát triển hoặc kiểm thử một thành phần được gọi đến hoặc theo cách không phụ thuộc vào nó. Nó thay thế việc gọi đến thành phần.

[After IEEE 610]

System integration testing - Kiểm thử tích hợp hệ thống: Kiểm thử tích hợp hệ thống và bản đóng gói, kiểm thử giao diện cho các tổ chức bên ngoài.

Ví dụ: Electronic Data Interchange, Internet

System testing - Kiểm thử hệ thống: Quá trình kiểm thử một hệ thống tích hợp để xác minh rằng nó đáp ứng yêu cầu đặc tả.

[Hetzel]

T

Technical review - Đánh giá kỹ thuật: Một hoạt động thảo luận nhóm ngang hàng để tập trung đạt được sự đồng thuận về các phương pháp kỹ thuật sẽ thực hiện.

[Gilb and Graham, IEEE 1028]

Test approach - Tiếp cận kiểm thử: Việc thực hiện chiến thuật kiểm thử cho dự án đặc biệt. Nó thường bao gồm các quyết định dựa theo mục đích kiểm thử của dự án và đánh giá rủi ro, điểm khởi đầu liên quan đến quá trình kiểm thử, kỹ thuật thiết kế kiểm thử được áp dụng, tiêu chuẩn kết thúc (exit criteria) và loại kiểm thử được thực hiện.

Test closure - Kiểm thử đóng: Trong giai đoạn kiểm thử đóng của quá trình kiểm thử dữ liệu được thu thập từ hoạt đồng hoàn thành để củng cố kinh nghiệm, testware, sự kiện và các con số. Giai đoạn kiểm thử đóng bao gồm việc hoàn tất và đạt được testware và quá trình đánh giá kiểm thử, bao gồm chuẩn bị báo cáo đánh giá kiểm thử.

Test strategy - Chiến lực kiểm thử: Một mô tả ở mức cao của mức kiểm thử (test level) được thực hiện và kiểm thử trong các mức (level) cho một tổ chức hoặc chương trình (một hoặc nhiều dự án).

Top-down testing - Kiểm thử top-down: Một cách tiếp cận tăng dần để kiểm thử tích hợp mà các thành phần ở phía trên của kiến trúc thành phần được kiểm thử đầu tiên, với các thành phần thấp hơn được mô phỏng bằng stub. Thành phần đã được kiểm thử là sau khi sử dụng để kiểm thử thành phần ở mức thấp hơn. Quá trình này lặp đi lặp lại cho đến ki thành phần thấp nhất được kiểm thử.

U

Usability - Tính khả dụng: Khả năng của phần mềm được hiểu, được biết, được sử dụng và sự hấp dẫn đối với người sử dụng khi sử dụng trong điều kiện đặt tả.

[ISO 9126]

Usability testing - Kiểm thử tính khả dụng: Kiểm thử để xác định mức độ sản phẩm phần mềm được hiểu, dễ học, dễ hoạt động và hấp dẫn người dùng dưới điều kiện đặt tả.

[After ISO 9126]

V

V-model - Mô hình chữ V: Một framework để mô tả hoạt động của vòng đời phát triển phần mềm từ yêu cầu đặc tả đến bảo trì. Mô hình chữ V minh họa hoạt động kiểm thử có thể tích hợp trong mỗi giai đoạn của vòng đời phát triển phần mềm như thế nào

Validation - Xác nhận: Chứng nhận bằng cách kiểm tra và thông qua việc cung cấp các bằng chứng khách quan mà yêu cầu cho một mục đích sử dụng cụ thể hoặc ứng dụng đã hoàn thành.

[ISO 9000]

Variable - Biến đổi: Một yếu tố cả dung lượng lưu trữ trong máy tính có thể truy cập bằng một chương trình phần mềm bằng cách truy cập đến nó dưới một cái tên.

Verification - Xác nhận: Xác nhận bằng cách kiểm tra và thông qua việc cung cấp các bằng chứng khách quan của yêu cầu đặt tả đã được hoàn thành.

[ISO 9000]

W

Walkthrough: Trình bày từng bước từng bước bởi tác giả của tài liệu để thu thập thông tin và để thiết lập hiểu biết chung về thành phần của nó.

White-box test design technique - Kỹ thuật thiết kế kiểm thử hộp trắng: Phương pháp để lấy được và/ hoặc lựa chọn test case dựa trên một phân tích của các cấu trúc bên trong của thành phần hoặc hệ thống.

White-box testing - Kiểm thử hộp trắng: Kiểm thử dựa trên một phân tích cấu trúc bên trong của thành phần hoặc hệ thống.

_Nguồn tham khảo: _

http://www.softwaretestinghelp.com/software-testing-terms-complete-glossary/

http://www.istqb.org/downloads/category/20-istqb-glossary.html