Gợi ý cho bạn
A
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| Acceptance Criteria | Bao gồm các tiêu chí bắt buộc mà các thành phần hoặc hệ thống đáp ứng được yêu cầu của người dùng | Thường được sử dụng khi break các task nhỏ trong các tool quản lý ticket, tiến độ dự án như: pivotal tracker,... |
| Acceptance Testing | Là loại kiểm thử được tiến hành để xác định hệ thống có đáp ứng được các tiêu chí chập nhận của người dùng không | Được kiểm thử bởi người dùng cuối |
| Accessibility Testing | Là loại kiểm thử khả năng tiếp cận | Được sử dụng để chắc chắn rằng ứng dụng sẽ giúp ích với nhóm người gặp thiệt thòi trong cuộc sống như: khiếm thính, khiếm thị, người già, người tàn tật ... |
| Actual Result | Là kết quả nhận được khi sử dụng chức năng | Được sử dụng nhiều trong khi viết test case hoặc checklist |
| Ad hoc Testing | Là loại kiểm thử không theo bất cứ một quy trình chính thức nào cả | Được sử dụng sau khi kết thúc quá trình kiểm thử theo checklist hoặc testcase |
| Agile Testing | Là loại kiểm thử thực hiện theo một số quy định của agile | Được sử dụng dựa trên quản điểm của khách hàng và kiểm thử sớm nhất có thể |
| Alpha Testing | Là một kiểu kiểm thử thuộc acceptance testing | Được sử dụng bởi người dùng cuối trên môi trường thử nghiệm |
| API | API được sử dụng để tích hợp các hệ thống với nhau. Bạn có thể tạo sẵn dữ liệu cho các hệ thống khác truy cập thông qua API hoặc chấp nhận dữ liệu từ các hệ thống khác. Đây là cách các thiết bị và ứng dụng khác nhau nói chuyện với nhau và chia sẻ thông tin. | Các công ty thành công như Facebook, YouTube và Twitter sử dụng API để ứng dụng của họ có thể giao tiếp với các chương trình của bên thứ ba. Thông thường, API hoạt động tương tự như cách hoạt động của bất kỳ trang web nào. Yêu cầu (request) được gửi từ client tới server và kết quả phản hồi (response) thông qua giao thức http. |
| API Testing | API testing là một loại kiểm thử phần mềm liên quan đến việc kiểm thử các giao diện lập trình ứng dụng (APIs) một cách trực tiếp và là một phần của kiểm thử tích hợp để xác định xem hệ thống có đáp ứng các yêu cầu về tính năng, độ tin cậy, hiệu suất và bảo mật. | Vì các API không có GUI nên kiểm thử API được thực hiện ở tầng nghiệp vụ (bussiness layer) . Trong quá trình kiểm thử API, dữ liệu được trao đổi từ XML hoặc JSON thông qua các yêu cầu và phản hồi HTTP ( HTTP requests and responses). Đây là những công nghệ độc lập và sẽ làm việc với nhiều ngôn ngữ lập trình và công nghệ khác nhau. |
| availability | Mức độ mà một thành phần hoặc hệ thống đang hoạt động và có thể truy cập được khi được yêu cầu sử dụng. | Thường được biểu thị dưới dạng phần trăm. [IEEE 610] |
| audit | Đánh giá độc lập các sản phẩm hoặc quy trình phần mềm để chắc chắn tuân thủ các tiêu chuẩn, hướng dẫn, thông số kỹ thuật và / hoặc thủ tục dựa trên các tiêu chí khách quan, bao gồm các tài liệu chỉ rõ: (1) hình thức hoặc nội dung của sản phẩm được sản xuất (2) quá trình sản xuất các sản phẩm (3) cách đo lường sự tuân thủ các tiêu chuẩn hoặc hướng dẫn. [IEEE 1028] | |
| analyzability | Khả năng của sản phẩm phần mềm được chẩn đoán về các thiếu sót hoặc nguyên nhân gây ra lỗi trong phần mềm hoặc xác định các bộ phận được sửa đổi. | [ISO 9126] Xem thêm phần kiểm tra khả năng bảo trì. |
| Activity Log | Là bảng ghi chép lại các hoạt động thao tác trên hệ thống phần mềm. Nếu không giới hạn thì nó sẽ lưu hết tất cả mọi thao tác xảy ra. | Nếu bị giới hạn các phần lưu trữ thì do từng công ty từng hệ thống muốn lưu những phần cần quan tâm thôi. Tránh bị rối. |
B
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| Beta testing | Là một kiểu kiểm thử thuộc acceptance testing | Được sử dụng bởi người dùng cuối trên môi trường thử nghiệm chỉ dành riêng cho người sử dụng |
| Black box testing | Kiểm thử hộp đen hay còn gọi là kiểm thử hướng dữ liệu | Được sử dụng để kiểm tra xem hệ thống có hoạt động như mong đợi |
| Bottom-up testing | Là một cách tiếp cận gia tăng để kiểm thử tích hợp | Được sử dụng để kiểm tra các thành phần từ thấp tới cao. Lặp lại quá trình tới khi hoàn thành việc kiểm thử hệ thống |
| Boundary value | Là kỹ thuật kiểm thử dựa trên giá trị biên | Được sử dụng để phân tích giá trị ở đầu, cuối , khoảng giữa |
| Boundary Value Analysis | Là kỹ thuật kiểm thử phân tích giá trị biên | Được sử dụng để xác định các ca kiểm thử dựa vào các miền giá trị xác định |
| Bug | Là những lỗi phần mềm trong chương trình tạo ra một kết quả sai hoặc hoạt động không như mong muốn | Bug xảy ra khi chương trình thực hiện không đúng theo bản đặc tả mong muốn. Đôi khi lỗi sẽ được coi là bug và ngược lại. Vì vậy, hãy áp dụng một cách linh hoạt nhưng chính xác để xác định một cách chắc chắn lỗi chúng ta gặp là bug. |
| Branch Testing | Là kỹ thuật kiểm thử nhánh | Được sử dụng để các trường hợp kiểm thử đã thiết kế thực thi theo các nhánh |
| behavior | Dịch là Hành vi. Nó phản hồi của một thành phần hoặc hệ thống đối với một tập hợp các giá trị đầu vào và các điều kiện tiên quyết. | |
| benchmark test | Một tiêu chuẩn mà các phép đo hoặc so sánh có thể được thực hiện. Một bài kiểm tra được sử dụng để so sánh các thành phần hoặc hệ thống với nhau hoặc với một tiêu chuẩn đưa ra nhất định. | Tài liệu trong phần [IEEE 610] |
| blocked test case | Một trường hợp thử nghiệm không thể được thực thi vì các điều kiện tiên quyết để thực thi nó không được đáp ứng. | |
| business process-based testing | Một cách tiếp cận để kiểm tra trong đó các trường hợp kiểm thử được thiết kế dựa trên các mô tả và / hoặc kiến thức về các quy trình kinh doanh. |
C
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| CASE | Viết tắt của cụm từ Computer Aided Software Engineering nghĩa là hệ thống các công cụ được sử dụng để thiết kế và phát triển các phần mềm dưới sự trợ giúp của máy tính | Được sử dụng để phát triển các phần mềm có chất lượng cao |
| CAST | Viết tắt của cụm từ Computer Aided Software Testing nghĩa là hệ thống các công cụ được sử dụng để kiểm thử dưới sự trợ giúp của máy tính | Được sử dụng để kiểm thử tự động các phần mềm |
| Cause-effect graphing | Là một kỹ thuật kiểm thử hộp đen minh hoạ mối quan hệ giữa nguyên nhân - kết quả thông qua đồ thị | Được sử dụng để giảm số lượng các trường hợp kiểm thử mà vẫn đạt được chất lượng mong muốn mà vẫn bao phủ được hết các case cần thiết cho độ bảo phủ tối đa nhất có thể |
| Certification | Quá trình xác nhận rằng một thành phần, hệ thống hoặc người dùng tuân thủ các yêu cầu được chỉ định | Ví dụ: bằng cách vượt qua một kỳ thi |
| Classification Tree Method | Một kỹ thuật thiết kế kiểm thử hộp đen trong đó các trường hợp kiểm thử, được mô tả bằng cây phân loại | Được thiết kế để thực hiện kết hợp các đại diện của các miền đầu vào và / hoặc đầu ra |
| Coverage | Được hiểu là bao phủ, được biểu diễn dưới dạng phần trăm về độ bao phủ của các trường hợp kiểm thử | Sử dụng rất nhiều trong kiểm thử tự động |
| Coverage Analysis | Là phân tích bao phủ | Được sử dụng để đo lường phạm vi bao phủ trong suốt quá trình thực thi kiểm thử với mục đích xác định xem việc kiểm thử bổ sung có bắt buộc hay không và các trường hợp kiểm thử nào là cần thiết |
| Compliance Testing | Là loại kiểm thử mà kiểm tra xem hệ thống được xây dựng phù hợp với các yêu cầu | Được thực hiện bởi các công ty chuyên cung cấp các chứng chỉ chứng nhận tuân thủ quy định |
| Component | Là bộ phận, thành phần trong một hệ thống hoặc phần mềm | Được sử dụng để chỉ các bộ phận thuần tuý |
| Component Integration Testing | Là kỹ thuật kiểm thử tích hợp thành phần | Được sử dụng bởi đội kiểm thử hoặc đội phát triển để kiểm thử riêng biệt từng thành phần với mục đích cuối cùng là kiểm thử được toàn bộ hệ thống |
| Concurrency Testing | Là loại kiểm thử đồng thời | Tức là thử nghiệm để xác định sự xuất hiện của hai hoặc nhiều hoạt động trong cùng một khoảng thời gian, đạt được bằng cách xen kẽ các hoạt động hoặc bằng cách thực hiện đồng thời, được xử lý bởi thành phần hoặc hệ thống |
| Condition | Là Điều kiện được coi như biểu thức logic trong việc phát triển chức năng của hệ thống | Biểu thức logic có thể được đánh giá là đúng hoặc sai. Ví dụ A > B |
| Condition Coverage testing | Là loại kỹ thuật bao phủ điều kiện | Thường được sử dụng bởi nhóm kiểm thử tự động trong đó mỗi điều kiện được gán giá trị đúng và sai |
| Control Flow | Là kiểm soát luồng nghiệp vụ | Được sử dụng trong kiểm thử khi đề cập tới luồng nghiệp vụ. Đảm bảo quản lý đúng theo yêu cầu đặt ra |
| Conversion Testing | Là loại kiểm thử chuyển đổi | Được sử dụng để kiểm thử việc chuyển đổi dữ liệu từ hệ thống hiện tại sang một hệ thống thay thế |
| Capture | Lưu lại ảnh chụp hoặc video làm bằng chứng trong quá trình testing hoặc làm tài liệu | |
| capture/playback tool | Một loại công cụ thực thi kiểm tra trong đó các đầu vào được ghi lại trong quá trình kiểm tra thủ công để tạo các tập lệnh kiểm tra tự động có thể được thực thi sau này (tức là phát lại). Những công cụ này thường được sử dụng để hỗ trợ kiểm tra hồi quy tự động. | |
| changeability | Khả năng của sản phẩm phần mềm để cho phép thực hiện các sửa đổi cụ thể. | [ISO 9126] Xem thêm phần khả năng bảo trì. |
| configuration | Thành phần của một thành phần khác hoặc hệ thống được xác định bởi số lượng, tính chất và các kết nối của các bộ phận cấu thành của nó. | Ví dụ hệ thống bạn khi tạo Document thì có phần select Group. Vậy cái Group đó có thể nó nằm trong phần Configuration để quản lý riềng phần đó cho các phần khác dùng lại. |
D
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| Data Definition | Hiểu là định nghĩ dữ liệu | Thông thường được sử dụng giống như một câu lệnh thực thi trong đó một biến được gán một giá trị. |
| Data Driven Testing | Là kiểm thử hướng dữ liệu | Đây là một kỹ thuật lập trình để lưu trữ dữ liệu đầu vào và kết quả mong đợi trong một bảng hoặc trong bảng tính excel. Được sử dụng để hỗ trợ các công cụ thực hiện kiểm thử như capture, playback |
| Data Flow | Được hiểu là luồng dữ liệu | Được nhắc tới khi muốn biểu diễn trạng thái của dữ liệu. Trạng thái của dữ liệu bao gồm: tạo, sử dụng, xoá |
| Data Flow Analysis | Là phân tích luồng dữ liệu | Đây được coi là hình thức phân tích tính dựa trên định nghĩa và cách sử dụng các biến |
| Data Flow Coverage | Được hiểu là bao phủ luồng dữ liệu | Trong kiểm thử, đây là tỷ lệ các cặp đã định nghĩa được thực thi bởi bộ trường hợp kiểm thử |
| Data Flow Test | Là kỹ thuật kiểm thử luồng dữ liệu | Được thiết kế để kết hợp với các trường hợp kiểm thử thực thi định nghĩa và sử dụng các cặp biến |
| Debugging | Là thuật ngữ mô tả về quá trình tìm kiếm, phát hiện lỗi cũng như nguyên nhân gây ra lỗi | Đây là bước rất quan trọng, không những tìm ra nguyên nhân mà trong lúc thực hiện còn để loại bỏ những dòng lệnh dư thừa, dễ gây ra bug |
| Decision | Được hiểu là quyết định | Mỗi một điểm chương trình tại đó luồng điều khiển có hai hoặc nhiều tuyến thay thế. Một nút có hai hoặc nhiều liên kết đến các nhánh riêng biệt |
| Decision Condition Coverage | Được hiểu là bao phủ điều kiện quyết định | Thuật ngữ này được chỉ cho tỷ lệ phần trăm của tất cả đầu ra điều kiện và đầu ra quyết định nghĩa là 100% bao phủ điều kiện và 100% bao phủ quyết định |
| Decision Condition Testing | Là kỹ thuật kiểm thử điều kiện quyết định | Được sử dụng trong kiểm thử khi thực thi đầu ra điều kiện và đầu ra quyết định |
| Decision Table | Được hiểu là bảng quyết định | Được sử dụng để thiết kế trường hợp kiểm thử trong đó, một bảng bao gồm đầu vào và kết quả đầu ra |
| Decision Table Testing | Là kỹ thuật kiểm thử bảng quyết định | Là kỹ thuật trong kiểm thử hộp đen để thực thi các trường hợp kiểm thử kết hợp đầu vào và đẩu ra bảng quyết định |
| Decision Testing | Là kỹ thuật kiểm thử quyết định | Đây là kỹ thuật thuộc kiểm thử hộp trắng với ca kiểm thử được thiết kế để thực thi các đầu ra quyết định |
| Defect | Được hiểu là nhược điểm | Lỗi trong quá trình phát triển hoặc lỗi logic làm cho chương trình hoạt động sai yêu cầu đề ra. Về cơ bản là giống bug |
| Deliverable | Là trạng thái có thể bàn giao được | Thông thường được sử dụng để chỉ trạng thái của ticket đã được hoàn thành, sẵn sàng bàn giao cho người kiểm thử hoặc khách hàng |
| Design-Based Testing | Là kiểm thử dựa trên thiết kế | Một cách tiếp cận để kiểm tra trong đó các trường hợp kiểm thử được thiết kế dựa trên kiến trúc và / hoặc thiết kế chi tiết của một thành phần hoặc hệ thống (ví dụ: kiểm tra giao diện giữa các thành phần hoặc hệ thống). |
| Documentation Testing | Được hiểu là kiểm tra chất lượng tài liệu | Được sử dụng để kiểm tra chất lượng của tài liệu. Thông thường được dùng khi làm các tài liệu hướng dẫn hoặc tài liệu cài đặt |
| Dynamic Analysis | Được hiểu là phân tích động | Được sử dụng để đánh giá hành vi. Ví dụ: hiệu suất bộ nhớ, sử dụng CPU, của một hệ thống hoặc thành phần trong khi thực hiện |
| Dynamic Testing | Là một kỹ thuật kiểm thử động | Được sử dụng để kiểm tra việc thực thi của các thành phần hoặc hệ thống phần mềm |
| domain | thường để chỉ một nhánh hay mảng hoặc lĩnh vực việc làm trong phần mềm. | Ví dụ: domain bank chỉ nhánh ngân hàng (phạm vi chuyên ngân hàng), domain ERP chỉ mảng hệ thống quản lý quy trình kinh doanh... |
| driver | Một thành phần phần mềm hoặc công cụ kiểm tra thay thế một thành phần khác để đảm nhận việc điều khiển hoặc việc gọi một thành phần hoặc hệ thống khác. | Ví dụ trong automation test với Selenium thì khi mở Browser Chrome lên sẽ sinh ra 1 driver để điều khiển các thành phần trên Browser đó. |
| Data entry | Data entry là quá trình nhập dữ liệu vào hệ thống, đây có thể là những dữ liệu thô bằng file cứng hoặc file mềm. |
E
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| emulator | Là một thiết bị, hệ thống, chương trình máy tính giả lập mô phỏng giống như một thiết bị thật | Được sử dụng khá phổ biến và rộng rãi ở hầu hết các lĩnh vực . Trong lĩnh vực CNTT, thiết bị giả lập đóng vai trò quan trọng cho cả lập trình viên lẫn kiểm thử phần mềm, như là một điều kiện tiên quyết, bắt buộc phải được thông qua trước khi thực hiện trên thiết bị thật |
| entry criteria | Là tiêu chí nhập, bao gồm các điều kiện chung và cụ thể để cho phép một quá trình tiếp tục với một nhiệm vụ được xác định | Thường được dùng trong giai đoạn thử nghiệm. Mục đích của tiêu chuẩn nhập là để ngăn chặn một task ngay từ khi bắt đầu thay vì việc lãng phí cố gắng (effort) so với cố gắng (effort) cần thiết để xóa bỏ tiêu chuẩn nhập thất bại. |
| equivalence partition | Là kiểu kỹ thuật phân vùng tương đương, chia miền đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử | Nguyên tắc để xác định các vùng tương đương, bao gồm: Xác định một vùng tương đương hợp lệ. Xác định hai vùng tương đương không hợp lệ => Nếu điều kiện đầu vào chỉ định là một tập giá trị thì chia vùng tương đương thành 2 tình huống: Một vùng hợp lệ. Một vùng không hợp lệ => Nếu điều kiện đầu vào xác định là một kiểu đúng sai thì chia vùng tương đương thành 2 tính huống: Một vùng hợp lệ. Một vùng không hợp lệ |
| error | Lỗi - Là hành động của con người dẫn đến kết quả không chính xác | |
| Error guessing | Là đoán lỗi - Một kỹ thuật thiết kế kiểm thử dựa trên kinh nghiệm của người kiểm thử để dự đoán trước những khiếm khuyết có thể có mặt trong thành phần hoặc hệ thống bên dưới kiểm thử như một kết quả của lỗi được tạo ra, và để thiết kế các trường hợp đặc biệt để tìm kiếm lỗi | Thông thường được người kiểm thử vận dụng trong quá trình viết các trường hợp kiểm thử, trong khi free test |
| exception handling | Xử lý ngoại lệ - Là hành vi của một thành phần hoặc hệ thống phản ứng với đầu vào sai lầm, từ người dùng của con người hoặc từ một thành phần hoặc hệ thống khác, hoặc đến một lỗi nội bộ. | Thường được sử dụng nhiều bởi develoer và đội kiểm thử phần mềm tự động |
| executable statement | Tuyên bố thực thi - Một câu lệnh, khi được biên dịch, được dịch thành mã đối tượng và sẽ được thực hiện theo thủ tục khi chương trình đang chạy và có thể thực hiện một hành động trên dữ liệu. | |
| expected result | Kết quả mong muốn - Các hành vi dự đoán từ các đặc tả, hoặc nguồn khác của thành phần hoặc hệ thống theo điều kiện quy định. | Thường được sử dụng khi viết các ca kiểm thử và mô tả lỗi để mọi người, nhất là develper nắm được |
| exploratory testing | Kiểm thử thăm dò - Một kỹ thuật thiết kế kiểm thử không chính thức như là việc các tester tích cực kiếm soát thiết kế của kiểm thử bằng những kiểm thử được thực hiện và sử dụng thông tin thu được trong quá trình kiểm thử để thiết kế mới và tốt hơn. | |
| Exhaustive testing | Kiểm thử toàn diện - Một cách tiếp cận kiểm thử với bộ kiểm thử bao gồm kết hợp tất cả các giá trị đầu vào và điều kiện tiền đề. |
F
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| fail | Khuyết điểm - Một thử nghiệm được coi là thất bại nếu kết quả thực tế không khớp với kết quả mong đợi. | |
| failure | Sự thất bại - Chính là sự khác biệt giữa kết quả thực tế trên màn hình và kết quả mong đợi của một thành phần, hệ thống hoặc service nào đó. | Không phải 100% failure là do bug gây ra, trong quá trình test cấu hình sai, test sai môi trường hoặc làm thiếu bước có thể dẫn đến failure |
| feature | Là tính năng - một thuộc tính về một đặc tả thành phần hoặc hệ thống hoặc tài liệu yêu cầu. | Ví dụ: độ tin cậy, tính khả dụng hoặc hạn chế thiết kế. |
| functional integration | Là tích hợp chức năng - Một cách tiếp cận tích hợp mà kết hợp thành phần hoặc hệ thống cho mục đích làm việc sớm với chức năng cơ bản. | Thường được sử dụng ngay sau khi các chức năng được chia nhỏ đã hoàn thiện |
| functional requirement | Là yêu cầu chức năng - Một yêu cầu đặc tả một chức năng mà một thành phần hoặc hệ thống phải thực hiện. | |
| functionality testing | Là kiểm thử chức năng - Kiểm thử dựa trên phân tích đặc tả về chức năng của thành phần hoặc hệ thống. | Ví dụ: Giống kiểm thử hộp đen |
| formal review | Chỉ một cuộc xem xét đặc trưng bởi các thủ tục và yêu cầu được lập thành văn bản. | Ví dụ: kiểm tra sản phẩm lại lần nữa trước khi bàn giao cho khách hàng (lên production). Kiểm tra Log, kiểm tra Tài liệu hướng dẫn sử sụng, kiểm tra bằng chứng dạng video,... |
G
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| glass box testing | Được hiểu kiểm thử hộp thủy tinh | Giống như kỹ thuật kiểm thử hộp trắng |
H
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| high level test case | Là trường hợp kiểm thử cấp cao. Giống như một trường hợp thử nghiệm không có giá trị cụ thể (mức thực hiện) cho dữ liệu đầu vào và kết quả mong đợi. | |
| horizontal traceability | Thuật ngữ mang nghĩa truy xuất nguồn gốc theo chiều ngang | Việc theo dõi các yêu cầu đối với cấp độ thử nghiệm thông qua các lớp của tài liệu thử nghiệm (ví dụ: kế hoạch thử nghiệm, đặc điểm thiết kế thử nghiệm, đặc tả trường hợp thử nghiệm và đặc tả quy trình thử nghiệm). |
| heuristic evaluation | Một kỹ thuật kiểm tra khả năng sử dụng để xác định sự tuân thủ của giao diện người dùng với các nguyên tắc về khả năng sử dụng được công nhận (cái gọi là "phương pháp phỏng đoán"). |
I
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| impact analysis | Là kiểu 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ả. | Thường được sử dụng trong giai đoạn đầu và giữa của việc phát triển phần mềm |
| incremental development model | Được hiểu là mô hình phát triển gia tăng. Một vòng đời phát triển trong đó một dự án được chia thành một loạt các sự gia tăng, một trong số đó cung cấp một phần chức năng trong các yêu cầu dự án chung. Các yêu cầu được ưu tiên và phân phối theo thứ tự ưu tiên theo mức tăng thích hợp. Trong một số phiên bản (nhưng không phải tất cả) của mô hình vòng đời này, mỗi dự án nhỏ tuân theo một ‘mô hình V nhỏ, với các giai đoạn thiết kế, mã hóa và thử nghiệm riêng. | |
| incremental testing | Là kiểm thử tăng dần. Trong đó, 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ử. | |
| incident | Hiểu là sự cố, là sự kiện bất kỳ xảy ra mà được yêu cầu điều tra | |
| incident management | Là quản lý sự cố | Quá trình nhận ra, điều tra, thực hiện hành động và xử lý các sự cố. Nó liên quan đến việc ghi lại các sự cố, phân loại chúng và xác định tác động |
| incident management tool | Là công cụ quản lý sự cố | Một công cụ hỗ trợ ghi lại và theo dõi trạng thái của các sự cố được tìm thấy trong quá trình thử nghiệm. Họ thường có các cơ sở định hướng công việc để theo dõi và kiểm soát việc phân bổ, sửa chữa và kiểm tra lại các sự cố và cung cấp các phương tiện báo cáo. |
| incident report | Là báo cáo sự cố - Một tài liệu báo cáo về bất kỳ sự kiện nào xảy ra trong quá trình thử nghiệm cần điều tra. | Thông thường mỗi tổ chức khi cần quản lý sự cố sẽ đưa ra khuôn mẫu chung nhằm mục đích dễ hiểu, đầy đủ và chính xác |
| Independence of testing | Là 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ử. |
| input | Là đầu vào - Một biến (cho dù được lưu trữ trong một thành phần hoặc bên ngoài) được đọc bởi một thành phần. | |
| input domain | Là thuật ngữ miền đầu vào | Chính là tập hợp từ đó các giá trị đầu vào hợp lệ có thể được chọn .. Xem thêm tên miền. |
| input value | Là giá trị đầu vào | Tùy thuộc vào yêu cầu sẽ có giá trị đầu vào giống hoặc khác nhau |
| integration | Là tích hợp | Đây là quá trình kết hợp các thành phần hoặc hệ thống thành các 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 | Là loại 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 | Loại 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
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| keyword driven testing | Đây được hiểu là Một kỹ thuật kịch bản sử dụng các tệp dữ liệu để chứa không chỉ dữ liệu thử nghiệm và kết quả mong đợi mà còn cả các từ khóa liên quan đến ứng dụng đang được thử nghiệm. Các từ khóa được diễn giải bởi các tập lệnh hỗ trợ đặc biệt được gọi bởi tập lệnh kiểm soát |
L
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| load test | Một loại thử nghiệm liên quan đến việc đo lường hành vi của một thành phần hoặc hệ thống với tải tăng, ví dụ: số lượng người dùng song song và / hoặc số lượng giao dịch để xác định tải nào có thể được xử lý bởi thành phần hoặc hệ thống. | Hiện nay load test gần như được coi là một kỹ thuật kiểm thử bắt buộc đối với những trang web, app có lượt tương tác, dữ liệu lớn. Có rất nhiều tool hỗ trợ QA, Dev trong việc kiểm thử hiệu năng của hệ thống, Ví dụ: Jmeter, ... |
| low level test case | Một trường hợp thử nghiệm với các giá trị cụ thể (mức thực hiện) cho dữ liệu đầu vào và kết quả mong đợi ở một mức độ ưu tiên thấp | Để xác định được test case ở mức độ low thì phụ thuộc vào phần lớn yêu cầu mà hệ thống đang phát triển. Ví dụ, case check font-size, thông thường được đánh ở mức độ low. Tuy nhiên, nếu là màn hình trang chủ, hiển thị thông báo quan trọng mà font-size quá nhỏ, dẫn tới người dùng ko thể nắm bắt được thông tin thì đây được coi là bug khá nghiêm trọng và mức độ của case check fon-size này ko thể được đánh là low |
| learnability | Khả năng của sản phẩm phần mềm cho phép người dùng tìm hiểu ứng dụng của nó. | [ISO 9126] Xem thêm phần khả năng sử dụng. |
M
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| maintenance testing | Kiểm tra các thay đổi đối với hệ thống vận hành hoặc tác động của môi trường thay đổi đến hệ thống vận hành. | Thông thường được sử dụng trong các dự án thuộc mô hình maintenance. Kiểm tra theo kiểu này cần phải thật thận trọng và tỉ mỉ, đòi hỏi người phát triển và QA phải có mức độ am hiểu sâu về hệ thống bởi chỉ một vài chỉnh sửa nhỏ cũng dễ dẫn tới những hậu quả không thể lường trước được |
| management review | Một đánh giá có hệ thống về quá trình mua, cung cấp, phát triển, vận hành hoặc bảo trì phần mềm, được thực hiện bởi quản lý theo dõi tiến độ, xác định trạng thái của kế hoạch và lịch trình, xác nhận các yêu cầu và phân bổ hệ thống người thừa kế hoặc đánh giá hiệu quả của phương pháp quản lý để đạt được mục đích | |
| measure | Số lượng hoặc danh mục được gán cho một thuộc tính của thực thể bằng cách thực hiện phép đo | |
| memory leak | Một khiếm khuyết trong logic của chương trình khiến nó không thể lấy lại bộ nhớ sau khi sử dụng xong, cuối cùng khiến chương trình bị lỗi do thiếu bộ nhớ | |
| monitor | Một công cụ phần mềm hoặc thiết bị phần cứng chạy đồng thời với thành phần hoặc hệ thống được kiểm tra và giám sát, ghi lại và / hoặc phân tích hành vi của thành phần hoặc hệ thống | |
| multiple condition coverage | Tỷ lệ phần trăm kết hợp của tất cả các kết quả điều kiện duy nhất trong một tuyên bố đã được thực hiện bởi một bộ thử nghiệm. Bảo hiểm nhiều điều kiện 100% ngụ ý bảo hiểm xác định điều kiện 100%. | |
| multiple condition testing | Một kỹ thuật thiết kế kiểm thử hộp trắng trong đó các trường hợp kiểm thử được thiết kế để thực hiện kết hợp các kết quả điều kiện đơn (trong một câu lệnh) | |
| mutation analysis | Một phương pháp để xác định tính kỹ lưỡng của bộ thử nghiệm bằng cách đo lường mức độ mà một bộ thử nghiệm có thể phân biệt chương trình với các biến thể nhỏ (đột biến) của chương trình. | |
| milestone | Một thời điểm trong một dự án mà tại đó các sản phẩm và kết quả được xác định (trung gian) phải sẵn sàng. | |
| moderator | Người lãnh đạo và người chịu trách nhiệm chính về một quá trình thanh tra hoặc xem xét khác. | |
| metric | Một thang đo lường và phương pháp được sử dụng để đo lường. [ISO 14598] |
N
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| negative testing | Các thử nghiệm nhằm mục đích cho thấy một thành phần hoặc hệ thống không hoạt động. Thử nghiệm tiêu cực có liên quan đến thái độ của người thử nghiệm chứ không phải là một phương pháp thử nghiệm cụ thể hoặc kỹ thuật thiết kế thử nghiệm. | |
| non-functional requirement | Một yêu cầu không liên quan đến chức năng, nhưng liên quan đến các thuộc tính như độ tin cậy, hiệu quả, khả năng sử dụng, khả năng bảo trì và tính di động. | |
| non-functional testing | Kiểm tra các thuộc tính của một thành phần hoặc hệ thống không liên quan đến chức năng, ví dụ: độ tin cậy, hiệu quả, khả năng sử dụng, khả năng bảo trì và tính di động | |
| non-functional test design techniques | Các phương pháp được sử dụng để thiết kế hoặc chọn thử nghiệm cho thử nghiệm không chức năng. |
O
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| operability | Khả năng của sản phẩm phần mềm cho phép người dùng vận hành và kiểm soát nó | |
| operational environment | Các sản phẩm phần cứng và phần mềm được cài đặt tại người dùng Các trang web của người dùng hoặc khách hàng, nơi các thành phần hoặc hệ thống được thử nghiệm sẽ được sử dụng. Phần mềm có thể bao gồm hệ điều hành, hệ thống quản lý cơ sở dữ liệu và các ứng dụng khác. | |
| operational testing | Thử nghiệm được tiến hành để đánh giá một thành phần hoặc hệ thống trong môi trường hoạt động của nó. | |
| output value | Gía trị đầu ra | Trong một hệ thống, khi có giá trị đầu vào sẽ luôn có giá trị đầu ra |
P
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| pair testing | Kiểm thử theo cặp là một thực hành kiểm thử phần mềm trong đó nhiều hơn hai thành viên cùng làm việc trên cùng một tính năng tại cùng một thời điểm trên cùng một máy tính với sự trao đổi ý kiến và phản hồi liên tục. | Một trong hai người phải là người thử nghiệm và người còn lại có thể là nhà phát triển hoặc nhà phân tích kinh doanh. |
| Pass | Một bài kiểm tra đượ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 | Quy tắc quyết định được sử dụng để xác định xem một mục thử nghiệm (chức năng) hoặc tính năng đã vượt qua hay thất bại một thử nghiệm. | |
| path coverage | Tỷ lệ phần trăm các đường dẫn đã được thực hiện bởi một bộ thử nghiệm. | |
| path testing | Một kỹ thuật thiết kế kiểm tra hộp trắng trong đó các trường hợp kiểm thử được thiết kế để thực hiện các đường dẫn. | |
| performance | Mức độ mà một hệ thống hoặc thành phần hoàn thành các chức năng được chỉ định trong các ràng buộc nhất định về thời gian xử lý và tốc độ thông lượng. | |
| performance testing | Quá trình thử nghiệm để xác định hiệu suất của một sản phẩm phần mềm. | |
| performance testing tool | Một công cụ hỗ trợ kiểm tra hiệu suất và thường có hai phương tiện chính: tạo tải và đo giao dịch thử nghiệm. Tạo tải có thể mô phỏng nhiều người dùng hoặc khối lượng dữ liệu đầu vào cao. Trong quá trình thực hiện, các phép đo thời gian phản hồi được lấy từ các giao dịch được chọn và chúng được ghi lại. Các công cụ kiểm tra hiệu suất thường cung cấp các báo cáo dựa trên nhật ký kiểm tra và biểu đồ tải theo thời gian phản hồi. | |
| phase test plan | Một kế hoạch kiểm tra thường giải quyết một cấp độ kiểm tra. | |
| portability testing | Quá trình thử nghiệm để xác định tính di động của sản phẩm phần mềm. | |
| precondition | Các điều kiện môi trường và trạng thái phải được đáp ứng trước khi thành phần hoặc hệ thống có thể được thực thi với một quy trình thử nghiệm hoặc thử nghiệm cụ thể. | |
| Priority | Mức độ ưu tiên | Thường được sử dụng để đánh mức độ ưu tiên của bộ trường hợp kiểm thử giúp QA có thứ tự ưu tiên để kiểm tra |
| process cycle test | Một kỹ thuật thiết kế kiểm thử hộp đen trong đó các trường hợp kiểm thử được thiết kế để thực hiện các quy trình | |
| project | Dự án là một tập hợp duy nhất các hoạt động được phối hợp và kiểm soát với ngày bắt đầu và kết thúc được thực hiện một mục tiêu phù hợp với các yêu cầu cụ thể, bao gồm các hạn chế về thời gian, chi phí và tài nguyên. | |
| project test plan | Một kế hoạch kiểm tra thường giải quyết nhiều cấp độ kiểm tra. |
Q
| Thuật ngữ | Ý nghĩa | Ghi chú |
|---|---|---|
| quality | Mức độ mà một thành phần, hệ thống hoặc quy trình đáp ứng các yêu cầu cụ thể và / hoặc nhu cầu và mong muốn của người dùng / khách hàng | |
| quality assurance | Một phần của quản lý chất lượng tập trung vào việc cung cấp niềm tin rằng các yêu cầu chất lượng sẽ được đáp ứng | |
| quality management | Các hoạt động phối hợp để chỉ đạo và kiểm soát một tổ chức liên quan đến chất lượng. Định hướng và kiểm soát liên quan đến chất lượng thường bao gồm việc thiết lập chính sách chất lượng và mục tiêu chất lượng, lập kế hoạch chất lượng, kiểm soát chất lượng, đảm bảo chất lượng và cải thiện chất lượng. | |
| quality attribute | Một tính năng hoặc đặc điểm ảnh hưởng đến chất lượng của một mặt hàng. [IEEE 610] |
R
| Thuật ngữ | Ý nghĩa |
|---|---|
| random testing | Một kỹ thuật thiết kế kiểm thử hộp đen trong đó các trường hợp kiểm thử được chọn, có thể sử dụng thuật toán tạo giả ngẫu nhiên, để khớp với hồ sơ hoạt động. Kỹ thuật này có thể được sử dụng để kiểm tra các thuộc tính phi chức năng như độ tin cậy và hiệu suất. |
| recoverability testing | Quá trình thử nghiệm để xác định khả năng phục hồi của sản phẩm phần mềm |
| regression testing | Thử nghiệm chương trình đã được thử nghiệm trước đây sau khi sửa đổi để đảm bảo rằng các lỗi không được giới thiệu hoặc phát hiện trong các khu vực không thay đổi của phần mềm, là kết quả của những thay đổi được thực hiện. Nó được thực hiện khi phần mềm hoặc môi trường của nó bị thay đổi. |
| release note | Một tài liệu xác định các mục kiểm tra, cấu hình của chúng, trạng thái hiện tại và thông tin phân phối khác được phân phối bởi phát triển để kiểm tra và có thể các bên liên quan khác khi bắt đầu giai đoạn thực hiện kiểm tra. |
| reliability testing | Quá trình thử nghiệm để xác định độ tin cậy của sản phẩm phần mềm. |
| requirement | Một điều kiện hoặc khả năng cần thiết của người dùng để giải quyết vấn đề hoặc đạt được mục tiêu phải được đáp ứng hoặc sở hữu bởi một thành phần hệ thống hoặc hệ thống để đáp ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật hoặc tài liệu áp đặt chính thức khác. |
| requirements management tool | Một công cụ hỗ trợ ghi lại các yêu cầu, thuộc tính yêu cầu (ví dụ: ưu tiên, chịu trách nhiệm về kiến thức) và chú thích, và tạo điều kiện truy xuất nguồn gốc thông qua các lớp yêu cầu và quản lý thay đổi yêu cầu. Một số công cụ quản lý yêu cầu cũng cung cấp các phương tiện để phân tích tĩnh, chẳng hạn như kiểm tra tính nhất quán và vi phạm các quy tắc yêu cầu được xác định trước. |
| result | Hậu quả / kết quả của việc thực hiện một bài kiểm tra. Nó bao gồm các kết quả đầu ra cho màn hình, thay đổi dữ liệu, báo cáo và thông điệp truyền thông được gửi đi. Xem thêm kết quả thực tế, kết quả mong đợi. |
| re-testing | Thử nghiệm chạy các trường hợp thử nghiệm thất bại lần cuối chúng được chạy, để xác minh sự thành công của các hành động khắc phục. |
| review | Một đánh giá về tình trạng sản phẩm hoặc dự án để xác định sự khác biệt so với kết quả đã hoạch định và đề xuất cải tiến. Ví dụ bao gồm đánh giá quản lý, đánh giá không chính thức, đánh giá kỹ thuật, kiểm tra và hướng dẫn. |
| risk | Một yếu tố có thể dẫn đến hậu quả tiêu cực trong tương lai; thường được thể hiện như tác động và khả năng. |
S
| Thuật ngữ | Ý nghĩa |
|---|---|
| scalability | Khả năng của sản phẩm phần mềm được nâng cấp để phù hợp với tải tăng. |
| scalability testing | Kiểm tra để xác định khả năng mở rộng của sản phẩm phần mềm. |
| security | Các thuộc tính của các sản phẩm phần mềm có khả năng ngăn chặn truy cập trái phép, dù là vô tình hay cố ý, đối với các chương trình và dữ liệu |
| security testing | Kiểm tra để xác định tính bảo mật của sản phẩm phần mềm |
| simulation | Sự thể hiện các đặc điểm hành vi được lựa chọn của một hệ thống vật lý hoặc trừu tượng bởi một hệ thống khác. |
| simulator | Một thiết bị, chương trình máy tính hoặc hệ thống được sử dụng trong quá trình thử nghiệm, hoạt động hoặc hoạt động giống như một hệ thống nhất định khi được cung cấp một bộ đầu vào được kiểm soát |
| smoke test | Một tập hợp con của tất cả các trường hợp thử nghiệm được xác định / theo kế hoạch bao gồm chức năng chính của một thành phần hoặc hệ thống, để xác định rằng các chức năng quan trọng nhất của chương trình hoạt động, nhưng không bận tâm đến các chi tiết tốt hơn. Một thử nghiệm xây dựng và khói hàng ngày là một trong những thực hành tốt nhất trong ngành |
| specification | Một tài liệu chỉ định, lý tưởng một cách đầy đủ, chính xác và có thể kiểm chứng được, các yêu cầu, thiết kế, hành vi hoặc các đặc điểm khác của một thành phần hoặc hệ thống, và, thường, các thủ tục để xác định xem các điều khoản này có được thỏa mãn hay không |
| stability | Khả năng của sản phẩm phần mềm để tránh các hiệu ứng không mong muốn từ các sửa đổi trong phần mềm |
| state transition testing | Kỹ thuật thiết kế kiểm thử hộp đen trong đó các trường hợp kiểm thử được thiết kế để thực hiện chuyển đổi trạng thái hợp lệ và không hợp lệ |
| statement coverage | Tỷ lệ phần trăm của các báo cáo thực thi đã được thực hiện bởi một bộ thử nghiệm |
| statement testing | Một kỹ thuật thiết kế kiểm tra hộp trắng trong đó các trường hợp kiểm thử được thiết kế để thực hiện các câu lệnh |
| static testing | Kiểm tra một thành phần hoặc hệ thống ở mức đặc tả hoặc mức triển khai mà không thực hiện phần mềm đó, ví dụ: đánh giá hoặc phân tích mã tĩnh |
| statistical testing | Một kỹ thuật thiết kế thử nghiệm trong đó một mô hình phân phối thống kê đầu vào được sử dụng để xây dựng các trường hợp thử nghiệm đại diện |
| Stress testing | Thử nghiệm được tiến hành để đánh giá một hệ thống hoặc thành phần tại hoặc vượt quá giới hạn của các yêu cầu được chỉ định của nó |
| suitability | Khả năng của sản phẩm phần mềm để cung cấp một bộ chức năng phù hợp cho các nhiệm vụ và mục tiêu người dùng được chỉ định |
| system integration testing | Kiểm tra sự tích hợp của các hệ thống và gói; thử nghiệm giao diện cho các tổ chức bên ngoài (ví dụ: Trao đổi dữ liệu điện tử, Internet) |
| system testing | Quá trình thử nghiệm một hệ thống tích hợp để xác minh rằng nó đáp ứng các yêu cầu được chỉ định |
T
| Thuật ngữ | Ý nghĩa |
|---|---|
| technical review | Một hoạt động thảo luận nhóm ngang hàng tập trung vào việc đạt được sự đồng thuận về phương pháp kỹ thuật sẽ được thực hiện. Đánh giá kỹ thuật còn được gọi là đánh giá ngang hàng |
| test approach | Việc thực hiện chiến lược thử nghiệm cho một dự án cụ thể. Nó thường bao gồm các quyết định được đưa ra dựa trên mục tiêu (thử nghiệm) của dự án và đánh giá rủi ro được thực hiện, điểm bắt đầu liên quan đến quá trình thử nghiệm, các kỹ thuật thiết kế thử nghiệm được áp dụng, tiêu chí thoát hiểm và loại thử nghiệm sẽ được thực hiện |
| test automation | Việc sử dụng phần mềm để thực hiện hoặc hỗ trợ các hoạt động kiểm tra, ví dụ: quản lý kiểm tra, thiết kế kiểm tra, thực hiện kiểm tra và kiểm tra kết quả |
| test basis | Tất cả các tài liệu mà từ đó các yêu cầu của một thành phần hoặc hệ thống có thể được suy ra. Các tài liệu mà các trường hợp thử nghiệm được dựa trên. Nếu một tài liệu chỉ có thể được sửa đổi bằng thủ tục sửa đổi chính thức, thì cơ sở thử nghiệm được gọi là cơ sở thử nghiệm cơ bản |
| test case | Một tập hợp các giá trị đầu vào, điều kiện tiên quyết thực hiện, kết quả mong đợi và hậu điều kiện thực hiện, được phát triển cho một mục tiêu cụ thể hoặc điều kiện thử nghiệm, chẳng hạn như để thực hiện một đường dẫn chương trình cụ thể hoặc để xác minh tuân thủ một yêu cầu cụ thể |
| test case specification | Tài liệu chỉ định một tập hợp các trường hợp thử nghiệm (mục tiêu, đầu vào, hành động thử nghiệm, kết quả mong đợi và điều kiện tiên quyết thực hiện) cho một mục thử nghiệm |
| test charter | Một tuyên bố về mục tiêu thử nghiệm, và có thể thử nghiệm ý tưởng. Biểu đồ kiểm tra là một trong những biểu đồ khác được sử dụng trong thử nghiệm thăm dò. Xem thêm thử nghiệm thăm dò |
| test comparator | Một công cụ kiểm tra để thực hiện so sánh kiểm tra tự động |
| test condition | Một mục hoặc sự kiện của một thành phần hoặc hệ thống có thể được xác minh bằng một hoặc nhiều trường hợp thử nghiệm, ví dụ: một chức năng, giao dịch, thuộc tính chất lượng hoặc yếu tố cấu trúc |
| test data | Dữ liệu tồn tại (ví dụ: trong cơ sở dữ liệu) trước khi thử nghiệm được thực thi và gây ảnh hưởng hoặc bị ảnh hưởng bởi thành phần hoặc hệ thống được thử nghiệm |
| test design specification | Tài liệu chỉ định các điều kiện kiểm tra (mục bảo hiểm) cho mục kiểm tra, phương pháp kiểm tra chi tiết và xác định các trường hợp kiểm tra mức cao có liên quan |
| test design tool | Một công cụ hỗ trợ hoạt động thiết kế thử nghiệm bằng cách tạo các đầu vào thử nghiệm từ một đặc tả có thể được giữ trong kho công cụ CASE, ví dụ: công cụ quản lý yêu cầu hoặc từ các điều kiện kiểm tra được chỉ định được giữ trong chính công cụ đó |
| test environment | Một môi trường chứa phần cứng, thiết bị, mô phỏng, công cụ phần mềm và các yếu tố hỗ trợ khác cần thiết để tiến hành kiểm tra |
| test evaluation report | Một tài liệu được tạo ra ở cuối quá trình thử nghiệm tóm tắt tất cả các hoạt động và kết quả thử nghiệm. Nó cũng chứa một đánh giá về quá trình kiểm tra và bài học kinh nghiệm |
| test execution | Quá trình chạy thử nghiệm bởi thành phần hoặc hệ thống được thử nghiệm, tạo ra kết quả thực tế |
| test item | Các yếu tố cá nhân được thử nghiệm. Thường có một đối tượng thử nghiệm và nhiều vật phẩm thử nghiệm. Xem thêm đối tượng thử nghiệm |
| test log | Một bản ghi thời gian của các chi tiết có liên quan về việc thực hiện các bài kiểm tra |
| test manager | Người chịu trách nhiệm kiểm tra và đánh giá một đối tượng thử nghiệm. Cá nhân, người chỉ đạo, kiểm soát, điều hành kế hoạch và điều chỉnh việc đánh giá đối tượng thử nghiệm |
| Test Maturity Model (TMM) | Khung theo giai đoạn năm cấp để cải tiến quy trình thử nghiệm, liên quan đến Mô hình trưởng thành khả năng (CMM) mô tả các yếu tố chính của quy trình thử nghiệm hiệu quả |
| Test Process Improvement (TPI) | Một khung liên tục để cải tiến quy trình thử nghiệm mô tả các yếu tố chính của quy trình thử nghiệm hiệu quả, đặc biệt nhắm vào thử nghiệm hệ thống và thử nghiệm chấp nhận |
| test object | Thành phần hoặc hệ thống được kiểm tra |
| test performance indicator | Một số liệu, nói chung ở mức cao, cho biết mức độ nào một giá trị mục tiêu hoặc tiêu chí nhất định được đáp ứng. Thường liên quan đến các mục tiêu cải tiến quy trình thử nghiệm, ví dụ: Tỷ lệ phát hiện khuyết tật (DDP) |
| test phase | Một tập hợp các hoạt động thử nghiệm riêng biệt được thu thập vào giai đoạn có thể quản lý được của một dự án, ví dụ: các hoạt động thực hiện của một cấp độ thử nghiệm |
| test plan | Một tài liệu mô tả phạm vi, cách tiếp cận, tài nguyên và lịch trình của các hoạt động kiểm tra dự định. Nó xác định trong số các mục kiểm tra khác, các tính năng sẽ được kiểm tra, các nhiệm vụ kiểm tra, ai sẽ thực hiện từng nhiệm vụ, mức độ độc lập của người kiểm tra, môi trường kiểm tra, kỹ thuật thiết kế kiểm tra và kỹ thuật đo kiểm được sử dụng và lý do lựa chọn và bất kỳ rủi ro nào cần lập kế hoạch dự phòng. Nó là một bản ghi của quá trình lập kế hoạch kiểm tra |
| test procedure specification | Một tài liệu chỉ định một chuỗi các hành động để thực hiện một bài kiểm tra. Còn được gọi là kịch bản thử nghiệm hoặc kịch bản thử nghiệm thủ công |
| test process | Quá trình thử nghiệm cơ bản bao gồm lập kế hoạch, đặc điểm kỹ thuật, thực hiện, ghi lại và kiểm tra để hoàn thành |
| test script | Thường được sử dụng để chỉ một đặc tả quy trình thử nghiệm, đặc biệt là quy trình tự động |
| test specification | Một tài liệu bao gồm một đặc tả thiết kế thử nghiệm, đặc tả trường hợp thử nghiệm và / hoặc đặc tả quy trình thử nghiệm |
| test suite | Một tập hợp một số trường hợp thử nghiệm cho một thành phần hoặc hệ thống đang được thử nghiệm, trong đó điều kiện sau của một thử nghiệm thường được sử dụng làm điều kiện tiên quyết cho lần thử nghiệm tiếp theo |
| test tool | Một sản phẩm phần mềm hỗ trợ một hoặc nhiều hoạt động kiểm tra, chẳng hạn như lập kế hoạch và kiểm soát, đặc tả, xây dựng các tệp và dữ liệu ban đầu, thực hiện kiểm tra và phân tích kiểm tra |
| test type | Một nhóm các hoạt động kiểm tra nhằm kiểm tra một thành phần hoặc hệ thống liên quan đến một hoặc nhiều thuộc tính chất lượng liên quan đến nhau. Một loại thử nghiệm được tập trung vào một mục tiêu thử nghiệm cụ thể, tức là thử nghiệm độ tin cậy, thử nghiệm khả năng sử dụng, thử nghiệm hồi quy, v.v. và có thể diễn ra trên một hoặc nhiều cấp độ thử nghiệm hoặc các giai đoạn thử nghiệm |
| tester | Một chuyên gia kỹ thuật lành nghề có liên quan đến việc thử nghiệm một thành phần hoặc hệ thống |
| testing | Quá trình bao gồm tất cả các hoạt động của vòng đời, cả tĩnh và động, liên quan đến việc lập kế hoạch, chuẩn bị và đánh giá các sản phẩm phần mềm và các sản phẩm công việc liên quan để xác định rằng chúng đáp ứng các yêu cầu cụ thể, để chứng minh rằng chúng phù hợp với mục đích và phát hiện lỗi |
| thread testing | Một phiên bản của thử nghiệm tích hợp thành phần trong đó sự tích hợp lũy tiến của các thành phần tuân theo việc thực hiện các tập hợp con của các yêu cầu, trái ngược với việc tích hợp các thành phần theo các cấp bậc |
| top-down testing | Một cách tiếp cận gia tăng để kiểm tra tích hợp trong đó thành phần ở đầu phân cấp thành phần được kiểm tra trước, với các thành phần cấp thấp hơn được mô phỏng bởi các sơ khai. Các thành phần được kiểm tra sau đó được sử dụng để kiểm tra các thành phần cấp thấp hơn. Quá trình được lặp lại cho đến khi các thành phần cấp thấp nhất đã được thử nghiệm |
U
| Thuật ngữ | Ý nghĩa |
|---|---|
| understandability | Khả năng của sản phẩm phần mềm cho phép người dùng hiểu liệu phần mềm có phù hợp hay không và cách sử dụng phần mềm cho các tác vụ và điều kiện sử dụng cụ thể |
| usability | Khả năng của phần mềm được hiểu, học, sử dụng và hấp dẫn người dùng khi được sử dụng trong các điều kiện được chỉ định |
| usability testing | Thử nghiệm để xác định mức độ hiểu sản phẩm phần mềm, dễ học, dễ vận hành và hấp dẫn người dùng trong các điều kiện được chỉ định |
| use case testing | Kỹ thuật thiết kế kiểm thử hộp đen trong đó các trường hợp kiểm thử được thiết kế để thực hiện các kịch bản người dùng |
| user test | Một thử nghiệm trong đó người dùng thực tế tham gia để đánh giá khả năng sử dụng của một thành phần hoặc hệ thống |
V
| Thuật ngữ | Ý nghĩa |
|---|---|
| V-model | Một khung để mô tả các hoạt động vòng đời phát triển phần mềm từ đặc tả yêu cầu đến bảo trì. Mô hình V minh họa cách các hoạt động kiểm thử có thể được tích hợp vào từng giai đoạn của vòng đời phát triển phần mềm |
| validation | Xác nhận bằng cách kiểm tra và thông qua việc cung cấp bằng chứng khách quan rằng các yêu cầu cho mục đích sử dụng hoặc ứng dụng cụ thể đã được đáp ứng |
| variable | Một yếu tố lưu trữ trong máy tính có thể truy cập được bằng chương trình phần mềm bằng cách gọi nó bằng tên |
| verification | Xác nhận bằng cách kiểm tra và thông qua việc cung cấp bằng chứng khách quan cho thấy các yêu cầu cụ thể đã được đáp ứng |
| volume testing | Kiểm tra nơi hệ thống phải chịu khối lượng dữ liệu lớn. Xem thêm kiểm tra sử dụng tài nguyên |
W
| Thuật ngữ | Ý nghĩa |
|---|---|
| walkthrough | Một bài thuyết trình từng bước của tác giả của một tài liệu để thu thập thông tin và thiết lập sự hiểu biết chung về nội dung của nó |
| white box testing | Kiểm tra dựa trên phân tích cấu trúc bên trong của thành phần hoặc hệ thống |
| Wide Band Delphi | Một kỹ thuật ước tính thử nghiệm dựa trên chuyên gia nhằm mục đích đưa ra ước tính chính xác bằng cách sử dụng trí tuệ chung của các thành viên trong nhóm. |
| Work Flow | “Work” có nghĩa là công việc và “flow” là dòng chảy. Hai từ này đi đôi với nhau được hiểu như một luồng công việc hay quy trình công việc, trong đó bao gồm chi tiết những nhiệm vụ được sắp xếp theo trật tự có hệ thống chuẩn hóa. Dựa vào đây mà mọi người có thể theo dõi và nắm bắt rõ vai trò của mình. |
Bổ sung và cập nhật thêm liên tục
Scrolling down / Scrolling up: động từ chỉ hạnh động dùng chuột giữa để di chuyển (lăn) trang web lên và xuống. Example: Go to TOP screen, scrolling down and check contact information.
Click on: Nhấp vào. Example: Click on the “Booking” button to submit the booking request.
Mouse hover + on: rê chuột vào (nhưng không click). Example: At the main Menu, hover on the "Booking" button and check the mouse hover color.
Leave the field blank: bỏ trống / không nhập gì vào trường nào đó. Example: At Contact form, leave all fields blank and click on Submit button.
Leave the field empty: (giống như trên) Example: At Contact form, leave all fields empty and click on Submit button.
Check the validation message: kiểm tra thông báo lỗi. Example: At Contact form, leave all fields blank and click on Submit button. Check the validation message color.
Missing / Lacking of: Thiếu/sót cái gì đó…. Example: Missing (lacking of) the phone number at Contact information.
Are/is inconsistent: không giống nhau, không đồng nhất. Example: Option dropdown color is inconsistent.
Breaking / Broken: vỡ, bung (thường dùng cho layout) Example: The Homepage layout is breaking.
Overlapping / overlaps: chồng chéo, nằm chồng lên nhau. Example: The text overlaps the buttons at Contact form.
Misalignment / Misaligned: không thẳng hàng, bị lệnh. Example: The phone number at the footer is misaligned / Misalignment of the “Share” and “Email” button.
Correspondingly: một cách tương ứng (trạng từ). Example: the Main screen is displayed correspondingly.
Misspelling / Spelling mistake / Typographical error (TYPO): lỗi đánh máy, lỗi chính tả (dùng trong việc check hiển thị của text Example: Misspelling at Contact information / Typo at Contact information / Spelling mistake at Contact information.
UI: user interface (giao diện người dùng) Example: Check the UI of login form.
Drag and drop: kéo thả. Example: Drag and drop your photo into the uploading area.
Redundancy / redundant: dư thừa, không cần thiết, thừa thải. Example: The redundant label should be removed / Data redundancy is the existence of data.
Redirect / Move to + điạ điểm: di chuyển, chuyển đến đâu.... Example: The website is redirecting/moving to the incorrect page.
Duplicated: bị trùng, bị lặp đã có. Example: “Show more” button is duplicated
Scaling up / Scaling down: kéo giãn ra / kéo nhỏ lại. Example: The banner does not scale up to fit the web layout
Responsive: Độ phân giải màn hình. Đây là một từ chỉ một phương pháp design giao diện web để tương thích trên các thiết bị mobile. Example: Check responsive of Mypage screen: 800x1024px.
Crash/Freeze: thường thì người ta không dịch mà hay giữ nguyên các từ này khi log bug. Có thể hiểu nó là khi sử dụng thì ứng dụng bị chết trong khi đang thao tác.
Example: Touch the "booking" button, and the page is frozen. (quá khứ của freeze)Impact/Affact/Effect: Tác động (không tiêu cực)/Tác động (tiêu cực)/Hiệu ứng. Rất nhiều người bị nhầm lẫn giữa các khái niệm này. Mình đưa 3 ví dụ để tiện phân biệt nhé. Example: The temperature affects the battery. Stress test was one major effect of the system's performance. The constant impact of the two activity on each other eventually produced crashing app.
Prototype: bản mẫu/khuôn dạng được thiết kế giúp có cái nhìn tổng quan cho tester/dev/khách hàng. Example: Hope you give me the prototype file soon.
Forbidden: (hành động nào đó) bị cấm Example: it is forbidden for anyone to enter this field.
Vertically/Horizontally: Theo chiều dọc / chiều ngang (rất nhiều người bị nhầm 2 hướng này nên mình vẫn note ra để các bạn rõ hơn). Example: Check the display of default image Vertically/Horizontally.
Enable/Disable: bật/tắt (diễn tả trạng thái của các button chỉ có 2 trạng thái ON/OFF) Example: Setting "Get email automatically" ON --> Confirm: Button "Get email automatically" is enabled.
Active/Inactive: Hoạt động/không hoạt động (diễn tả trạng thái của các button có thể click hoặc không thể click vào nó) Example: "Booking" button is inactive and not able to click it.