Câu hỏi 1.1: Lỗi phần mềm gì? Nguyên nhân gây lỗi phần mềm? - Lỗi phần mềm(Software Error) phần code sai lôi cú pháp, logic hoăc lỗi phân tích, thiết kế - Nguyên nhân gây lỗi: Lỗi định nghĩa yêu cầu Quan hệ Client-developer tồi Sai phạm có chủ ý với yêu cầu phần mềm Lỗi thiết kế logic Lỗi lập trình Không tuân thủ hướng dẫn viết tài liệu code Thiếu sót trình kiểm thử Lỗi giao diện người dùng thủ tục Lỗi tài liệu Câu hỏi 1.4: Kể độ đo đặc trưng chất lượng McCall? Giải thích nội dung nó? McCall có 11 tiêu chí; chia thành nhóm – Tiêu chí vận hành sản phẩm + Tính đắn – Correctness : Đặc tả độ sác, tính toàn vẹn, thời gian outputs + Tính tin cậy – Reliability : Định tỉ lệ lỗi cho chức hệ thống + Tính hiệu - Efficiency : Tài ng phần cứng cần để thực chức phần mềm + Tính toàn vẹn – Integrity : Bảo mật hệ thống, ngăn truy cập trái phép + Tính khả dụng - Usability : Tính dễ học, dễ dùng, hiệu – Tiêu chí sửa đổi sản phẩm + Tính bảo trì – Maintainability : Mức công sức cần đề tìm nguyên nhân+ sửa + xác nhận sửa đc failures.(Liên quan đến cấu trúc modul, kiến trúc , thiết kế tài liệu) + Tính linh hoạt – Flexibility : Bảo trì cải tiến dễ dàng + Tính kiểm thử – Testability : Có lưu lại kq trung gian để hỗ trợ test? Có tạo file log, backup? – Tiêu chí chuyển giao sản phẩm + Khả di động – Portability : Cài môi trường (phần cứng khác, hệ điều hành khác,…) mà trì môi trường cũ + Khả tái sử dụng – Reusability : Có thể tái sử dụng phần phần mềm cho ứ/dụng khác + Khả tương thích – Interoperability : phần mềm có cần interface với hệ thống có Câu hỏi 1.6: Trình bày kỹ thuật Walkthrough • Walkthrough: Kỹ thuật đánh giá không thức(nên ko có ng quản lý, giám đốc dự án) Những người tham gia phải xem tài liệu trước họp (ít vài ngày) Tác giả giải thích tài liệu/ sản phẩm cho nhóm (tác giả, điều phối viên, giám định viên, đại diện ng dùng, chuyên gia bảo trì) + Mọi người đặt câu hỏi cho ý kiến bổ sung số lĩnh vực để bảo đảm chất lượng kỹ thuật tài liệu sản phẩm + Buổi giám định xảy vào lúc đâu việc phát triển sản phẩm phần mềm Mục đích họp giám định để tìm lỗi nhanh, ko tìm giải pháp Sau giám định, tác giả phải làm lại sửa lỗi Câu hỏi 1.7: Trình bày kỹ thuật Inspection • Inspection: Kỹ thuật đánh giá thức Tài liệu, sản phẩm người tác giả trực tiếp liên quan(Ngươi kiểm duyệt, tác giả, tester, thiết kế, coder) kiểm tra cách chi tiết để phát lỗi, vi phạm tiêu chuẩn, vấn đề khác (nếu có) + Về bản, tổ chức thực chặt chẽ walkthrough Vai trò người tham gia phân định rõ ràng Tài liệu chuẩn bị cho việc xem xét chuẩn bị trước chu đáo + Quá trình duyệt thảo bắt đầu sau giai đoạn code unit test Sau buổi họp lỗi tìm đc đc sửa lại, đem duyệt thảo lại đạt tiêu chuẩn kết thúc trình Câu hỏi 1.10: Trình bày tóm tắt SQA tiêu chuẩn IEEE std1028 Chất lượng phần mềm là: (1) Mức độ mà hệ thống, thành phần, hay tiến trình đáp ứng đặc tả yêu cầu (2) Mức độ mà hệ thống, thành phần, hay tiến trình đáp ứng nhu cầu/mong muốn khách hàng/người dùng - Lập kế hoạch cài đặt cách hệ thống! - Chỉ tiến độ và truyền tải tin cậy phần mềm phát triển - Với tiến trình phát triển phần mềm phương pháp luận; cách thức để làm; - Với đặc tả yêu cầu kỹ thuật phải có - SQA bao gồm tiến trình phát triển bảo trì dài hạn Do vậy, ta cần xem xét vấn đề chất lượng cho phát triển bảo trì SQA Hành động SQA phải bao gồm lập lịch lập ngân sách - SQA phải vấn đề nảy sinh không đáp ứng ràng buộc thời gian– bỏ bớt chức năng? Ràng buộc ngân sách thoả hiệp nguồn lực phân bổ bị không đủ cho phát triển và/hoặc bảo trì SQA là: "Tập hoạt động có hệ thống cung cấp chứng khả qui trình phần mềm tạo sản phẩm phần mềm khớp với việc sử dụng Do hội tụ SQA giám sát liên tục toàn thể vòng đời phát triển phần mềm để đảm bảo chất lượng sản phẩm chuyển giao Điều yêu cầu giám sát qui trình sản phẩm Trong đảm bảo qui trình, SQA cung cấp việc quản lí với phản hồi khách quan liên quan tới tuân thủ kế hoạch, thủ tục, chuẩn phân tích chấp thuận Các hoạt động đảm bảo sản phẩm hội tụ vào mức độ thay đổi chất lượng sản phẩm bên pha vòng đời, yêu cầu, thiết kế, viết mã kế hoạch kiểm thử Mục tiêu nhận diện khử bỏ khiếm khuyết toàn vòng đời sớm được, giảm chi phí kiểm thử bảo trì Câu hỏi 1.11: Trình bày mức tiêu chuẩn CMM? Khởi đầu: Quy trình sản xuất phần mềm có đặc điểm tự phát, thành công dựa vào nỗ lực cá nhân tài Lặp: Các quy trình quản lý dự án thiết lập để kiểm soát chi phí, kế hoạch khối lượng hoàn thành Nguyên lý quy trình hình thành nhằm đạt thành công phần mềm tương tự Xác lập: Quy trình phần mềm cho hoạt động quản lý sản xuất tài liệu hóa, chuẩn hóa tích hợp vào quy trình phần mềm chuẩn nhà sản xuất Các dự án sử dụng quy trình phần mềm hiệu chỉnh phê duyệt dựa quy trình chuẩn nhà sản xuất để phát triển bảo trì sản phẩm phần mềm Kiểm soát: Thực đo lường chi tiết quy trình phần mềm chất lượng sản phẩm Cả quy trình sản xuất sản phẩm phần mềm kiểm soát theo định lượng Tối ưu: Quy trình liên tục cải tiến dựa ý kiến phản hồi từ việc sử dụng quy trình, thí điểm ý tưởng quản lý công nghệ - CMMI viết tắt cho Capability Maturity Model Integration - Mô hình trưởng thành lực tích hợp - khuôn khổ cho cải tiến qui trình phần mềm Nó dựa khái niệm thực hành tốt kĩ nghệ phần mềm giải thích kỉ luật mà công ty dùng để cải tiến qui trình họ - CMM bao gồm levels 18 KPAs (Vùng quy trình quan trọng - Key Process Area) Level 1: Khởi đầu (lộn xộn, không theo chuẩn) KPAs Level 2: Lặp (quản lý dự án, tuân thủ quy trình) có KPAs Level 3: Xác lập (thể chế hóa) có KPAs Level 4: Kiểm soát (định lượng) có KPAs Level 5: Tối ưu (cải tiến quy trình) có KPAs Level 1: Initial(Ban đầu): Level bước khởi đầu CMM, doanh nghiệp, công ty phần mềm, cá nhóm, cá nhân đạt Ở lever CMM chưa yêu cầu tính Ví dụ: không yêu cầu quy trình, không yêu cầu người, miễn cá nhân, nhóm, doanh nghiệp… làm phầm mềm đạt tới CMM Đặc điểm mức 1: - Hành chính: Các hoạt động lực lượng lao động quan tâm hàng đầu thực cách vỗi vã hấp tấp Không thống nhất: Đào tạo quản lý nhân lực nhỏ lẻ chủ yếu dựa vào kinh nghiệp cá nhân - Quy trách nhiệm: Người quản lý mong phận nhân điều hành kiểm sóat hoạt động lực lượng lao động Quan liêu: Các hoạt động lực lượng lao động đáp ứng mà không cần phân tích ảnh hưởng Doanh số thường xuyên thay đổi: Nhân viên không trung thành với tổ chức Level 2: Repeatable (được quản lý): Mục tiêu(Goal): hoạt động đề xuất dự án phần mềm phải lên kế hoạch viết tài liệu đầy đủ Có KPA (Key Process Area) bao gồm sau - Requirement Management ( Lấy yêu cầu khách hàng, quản lý yêu cầu đó) - Software Project Planning ( Lập kế hoạch cho dự án) - Software Project Tracking (Theo dõi kiểm tra tiến độ dự án) - Software SubContract Managent ( Quản trị hợp đồng phụ phần mềm) - Software Quality Assurance (Đảm bảo chất lượng sản phẩm) - Software Configuration Management (Quản trị cấu hình sản phẩm=> yêu cầu khách hàng không) Các KPA( Key Process Areas) trọng tới thành phần sau : + Chế độ đãi ngộ + Đào tạo + Quản lý thành tích + Phân công lao động + Thông tin giao tiếp + Môi trường làm việc Để đạt Level người quản lý phải thiết lập nguyên tắc quản lý hoạt động diễn Họ có trách nhiệm quản lý đội ngũ Level 3: Defined (được định ra) Các vùng tiến trình chủ chốt mức nhằm vào hai vấn đề dự án tổ chức, tổ chức (công ty) tạo nên cấu trúc hạ tầng thể chế trình quản lý sản xuất phần mềm hiệu qua tất dự án - KPA trọng tới yếu tố sau : + Văn hóa cá thể + Công việc dựa vào kỹ + Phát triển nghiệp - + Hoạch định nhân + Phân tích kiến thức kỹ Để đạt level người quản lý phải biến đổi cải tiến hoạt động diễn ra, cải tiến môi trường làm việc Level 4: Managed (được quản lý định lượng) Các vùng tiến trình chủ yếu mức tập trung vào thiết lập hiểu biết định lượng trình sản xuất phần mềm sản phẩm phần mềm xây dựng Đó Quản lý trình định lượng (Quantitative Process Management) Quản lý chất lượng phần mềm (Software Quality Management) Các KPA level trọng tới: + + + + + Chuẩn hóa thành tích tổ chức Quản lý lực tổ chức Công việc dựa vào cách làm việc theo nhóm Xây dựng đội ngũ chuyên nghiệp Cố vấn Để đạt level phải đo lường chuẩn hóa Đo lường hiệu đáp ứng công việc, chuẩn hóac phát triển kỹ năng, lực cốt lõi Level trọng vào người đứng đầu công ty, họ có khả quản lý công việc Level 5: Optimising (tối ưu) Các vùng tiến trình chủ yếu mức bao trùm vấn mà tổ chức dự án phải nhắm tới để thực hoàn thiện trình sản xuất phần mềm liên tục, đo đếm Đó Phòng ngừa lỗi (Defect Prevention), Quản trị thay đổi công nghệ (Technology Change Management), Quản trị thay đổi trình (Process Change Management) Để đạt Level doanh nghiệp phải liên tục cải tiến hoạt động tổ chức, tìm kiếm phương pháp đổi để nâng cao lực làm việc lực lượng lao động tổ chức, hỗ trợ nhân phát triển sở trường chuyên môn Chú trọng vào việc quản lý, phát triển lực nhân viên, Huấn luyện nhân viên trở thành chuyên gia Câu hỏi 1.12: Mục tiêu SQA gì? Các hoạt động đảm bảo chất lượng phần mềm hoạt động nào? - Đảm bảo chất lượng phần mềm hoạt động nhằm mục tiêu sản xuất phần mềm có chất lượng cao o Mục tiêu hoạt động SQA phát triển phần mềm  Đảm bảo mức độ tin cậy chấp nhận phần mềm tuân thủ yêu cầu kỹ thuật chức  Đảm bảo mức độ tin cậy chấp nhận phần mềm tuân thủ yêu cầu quản lý thời gian tài  Khởi đầu quản lý hoạt động để phát triển phần mềm hoạt động SQA cải thiện đạt hiệu cao o Mục tiêu hoạt động SQA bảo trì phần mềm  Đảm bảo mức độ tin cậy chấp nhận hoạt động bảo trì phần mềm tuân thủ yêu cầu kỹ thuật chức  Đảm bảo mức độ tin cậy chấp nhận hoạt động bảo trì phần mềm tuân thủ yêu cầu quản lý thời gian tài  Khởi đầu quản lý hoạt động để bảo trì phần mềm hoạt động SQA cải tiến hiệu - Có hoạt động chính: (1) Áp dụng công nghệ kĩ thuật hiệu (phương pháp, công cụ) (2) Tiến hành rà soát kỹ thuật thức (3) Thực kiểm thử nhiều tầng (4) Tuân theo chuẩn phát triển (5) Kiểm soát tài liệu PM thay đổi chúng (6) Thực đo lường (7) Báo cáo bảo quản lý báo cáo Câu hỏi 1.13: Khảo sát nhu cầu SQA gồm nội dung gì? Nhằm trả lời câu hỏi gì? - Gồm ba nội dung nhằm trả lời ba câu hỏi + Kiểm kê sách SQA: sách, thủ tục, chuẩn có pha phát triển? + Đánh giá vai trò kỹ nghệ phần mềm, bảo đảm chất lượng tổ chức có quyền lực đến đâu? + Đánh giá mối quan hệ SQA: Giao diện chức SQA với đơn vị khác nào? Với người thực rà soát kỹ thuật thức, quản lý cấu hình thử nghiệm - Nếu có nhu cầu SQA cần phải tiến hành đánh giá cẩn thận quy tắc bỏ phiếu Câu hỏi 1.15: Ca kiểm thử gì? Mục tiêu thiết kế ca kiểm thử? - Một ca kiểm thử (test case) công nghệ phần mềm tập hợp điều kiện hay biến để theo thử nghiệm xác định xem ứng dụng hệ thống phần mềm làm việc cách xác hay không - Mục đích: + Muốn tìm nhiều sai với nỗ lực thời gian nhỏ + Chứng minh tồn lỗi + Không chứng minh lỗi Câu hỏi 1.16: Kiểm thử hộp trắng gì? Nêu đặc trưng nó? - Là hình thức kiểm thử mà kiểm thử viên biết cấu trúc bên chương trình (mã nguồn, xử lý liệu, …) Việc kiểm thử dựa phân tích cấu trúc bên thành phần/hệ thống Kiểm tra mã nguồn chi tiết thủ tục (thuật toán), đường logic (luồng điều khiển), trạng thái chương trình (dữ liệu) - Đặc trưng: + Kiểm thử hộp trắng dựa vào thuật giải cụ thể, vào cấu trúc liệu bên đơn vị phần mềm cần kiểm thử để xác địnhđơn vị phần mềm có thực không + Người kiểm thử hộp trắng phải có kỹ năng, kiến thức định để hiểu chi tiết đoạn code cần kiểm thử + Thường tốn nhiều thời gian công sức mức độ kiểm thử nâng lên cấp kiểm thử tích hợp hay kiểm thử hệ thống + Do kỹ thuật chủ yếu dùng để kiểm thử đơn vị Trong lập trình hướng đối tượng, kiểm thử đơn vị kiểm thử tác vụ class chức + Có hoạt động kiểm thử hộp trắng: Kiểm thử luồng điều khiển kiểm thử dòng liệu Câu hỏi 1.17: Kiểm thử hộp đen gì? Nêu đặc trưng nó? - Kiểm thử hộp đen (Black-box Testing): Là hình thức kiểm thử mà kiểm thử viên không cần biết đến cách thức hoạt động, mã nguồn, xử lý liệu bên thành phần/hệ thống Công việc cần làm nhập liệu đầu vào (input) kiểm tra kết trả có mong muốn hay không - Đặc trưng: + Cơ sở: đặc tả, điều kiện vào/ra cấu trúc liệu + Nhằm thuyết minh chức phần mềm đủ vận hành + Thực phép thử qua giao diện + Thường phát lỗi đặc tả yêu cầu, thiết kế + Dễ dàng thực + Chi phí thấp + Được sử dụng để kiểm thử phần mềm mức: modul, tích hợp, hàm, hệ thống + Đơn giản hoá kiểm thử mức độ đánh giá khó kiểm thử + Khó đánh giá giá trị chưa kiểm thử hay không + Ít ý tới cấu trúc logic nội Câu hỏi 1.18: Có loại công cụ tự động trợ giúp kiểm thử, mô tả nội dung loại? - Công cụ kiểm thử tự động (Testing Tools) chia thành nhóm chính: Design, GUI(Graphical User Interface), Load and Performance, Management, Implementation, Evaluation (Sự đánh giá), Static Analysis (Phân tích tĩnh)và có : Defect Tracking, Websites Miscellaneous(Hỗn Hợp) Test Design Tools + Các công cụ giúp bạn định “test” cần để thực thi Kiểm thử liệu kiểm thử trưởng hợp (Test data and test case) sinh ra(generators) + Test design tools giúp tạo “Test case”, số đầu vào test tối thiểu (là phần test case) + Có tổng cộng khoảng 15 Tools GUI Test Tools + Các công cụ tự động thực thi kiểm thử (Test) cho “products” với giao diện người dùng Graphic Công cụ tự động kiểm tra Client/Server, bao gồm load testers + GUI Testing trinh kiểm thử giao diện người dùng ứng dụng phát chức xác ứng dụng Load and Performance Tools + Load testing trình đặt nhu cầu hệ thống thiết bị đo phản ứng Load testing thực để xác định hành vi hệ thống theo điều kiện tải bình thường mong đợi Nó giúp để xác định khả hoạt động tối đa ứng dụng vướng mắc xác dịnh yếu tố gây suy thoái + Performance testing thực để xác định hệ thống có đáp ứng yêu cầu ổn định khối công việc cụ thể Nó phục vụ việc kiểm tra, đo lường, xác minh chất lượng thuộc tính hệ thống, chẳng hạn khả mở rộng, độ tin cậy sử dụng tài nguyên Test Management Tools + Test managerment tools sử dụng để lưu trữ thông tin trình kiểm thử làm việc nào, kế hoạch hoạt động kiểm thử báo cáo tình hình hoạt động đảm bảo chất lượng phần mềm Test Implementation Tools + Dụng cụ khác giúp bạn thực kiểm tra Ví dụ, công cụ tự động tạo thói quen sơ khai đây, công cụ mà Câu hỏi 3.11: Hàm bên trả số phần tử cuối x có giá trị Nếu không tồn tại, trả giá trị -1 int lastZero(int[] x){ for (int i = 0; i < x.length; i++){ if (x[i] == 0) return i; } return -1; } Cho đầu vào ca kiểm thử đây: t1= (x={5}) t2= (x={0}) t3= (x={5,-2,5,7,0}) t4= (x={-1,2,0,5,-9}) t5= (x={0,-2,3,7,9}) a.Vẽ đồ thị luồng điều khiển b Chỉ đường đồ thị luồng điều khiển tương ứng với đầu vào ca kiểm thử c Tìm tập đầu vào ca kiểm thử nhỏ để bao phủ hết câu lệnh d Tìm tập đầu vào ca kiểm thử nhỏ để bao phủ hết ngã rẽ e Tìm tập đầu vào ca kiểm thử nhỏ để bao phủ hết đường với số phần tử mảng x = f Liệu tất đường tương ứng e có khả thi hay không? Nếu không đường không khả thi Câu hỏi 3.15: public void foo2(int a, int b, int x) { if (a>1 && b==0) { x=x/a; } for ( int i = 1; i < 3; i++){ if true x=x+1; } } a Vẽ đồ thị luồng điều khiển b Từ đồ thị luồng điều khiển, xác định tập đường từ đầu vào tới đầu để bao phủ toàn ngã rẽ (branch) : có đường tất 1-2-5-6-end 1-2-5-6-7-8-6-end 1-2-3-5-6-end 1-2-3-6-7-8-6-end 1-2-3-4-5-6-end 1-2-3-4-5-6-7-8-6-end c Liệu tất đường có khả thi hay không? Nếu không đường không khả thi d Xác định test case tương ứng với đường khả thi Câu hỏi 3.19: Chương trình SquaresLoopRange(start-number, stop-number) hiển thị bình phương dãy số từ start-number tới stop-number Nếu start-number lớn stop-number error message cần hiển thị: Startlimit greater than stop-limit!Sq a Viết chương trình b Thiết kế test cases c Viết code JUnit tương ứng a code public class Squares { int startNum; int stopNum; public Squares(int startNum, int stopNum) { this.startNum = startNum; this.stopNum = stopNum; } public String show(){ if(startNum [...]... mới, sửa chữa hoặc cố định phần mềm, để đảm bảo rằng những cung cấp mới nhất đã không phá hủy bất cứ điều gì và toàn bộ phần mềm vẫn còn hoạt động một cách chính xác Câu hỏi 1.29: Test plan là gì, gồm những nội dung gì? - Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào nỗ lực kiểm thử phần mềm Quá trình chuẩn bị test... mã • Muốn nhìn thấy phần mềm như là một phần tử của hệ thống hoạt động (xem sản phầm) • Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này (hiệu quả) • Có kế hoạch tốt nâng cao chất lượng cho suốt quá trình phát triển (giải pháp) - Tầm quan trọng của kiểm thử phần mềm: • Chi phí của kiểm thử chiếm: 40% tổng công sức phát triển ≥ 30% tổng thời gian phát triển • Với phần mềm ảnh hưởng tới... lỗi Phát hiện lỗi phân tích, thiết kế Câu hỏi 2.3: Giải thích sự khác nhau giữa failure, error, và fault - Lỗi phần mềm( Software Error) là các phần code sai do lôi cú pháp, logic hoăc lỗi do phân tích, thiết kế + Thường là chỉ một lỗi của con người trong quá trình xây dựng phần mềm - Sai sót(Software Fault)là các errors dẫn tới hoạt động không chính xác của phần mềm Không phải error nào cũng gây ra... test: số lượng máy chủ, máy trạm; việc chia tách các server, các máy trạm, việc cài đặt các domain … Thông thường, trong Unit test có thể sử dụng viếc thiết lập như khi lập trình, nhưng khi System test trở đi, phải chú ý thiết lập sao cho gần giống mô hình sẽ chạy trong thực tế nhất Câu hỏi 2.1: Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? - Lý do cần kiểm thử phần mềm: • Kiểm thử phần mềm là... tiềm tàng khác tại giao diện phần mềm - Báo cáo các kết quả kiểm thử để làm chứng cớ phòng ngừa đổ lỗi cho nhau - Những người tham gia vào trong việc hoạch định và thiết kế các kiểm thử hệ thống để bảo đảm rằng phần mềm được kiểm thử đầy đủ Việc kiểm thử hệ thống thực tế là một loạt các bước kiểm thử khác nhau có mục đích chính là thử đầy đủ hệ thống dựa trên máy tính Câu hỏi 1.26: Khi nào nên dùng test... bảo trì các script để thực hiện kiểm tra tự động + Khó bảo trì, khó mở rộng các script + Đòi hỏi KTV phải có kỹ năng tạo script kiểm tra tự động + Không áp dụng được trong việc tìm lỗi mới của PM Câu hỏi 1.27: Kể tên một vài test tools cho kiểm thử chức năng, hiệu năng? Test tools cho kiểm thử chức năng: • QuickTest Professional: phần mềm kiểm soát việc kiểm thử tự động các chức năng của sản phẩm phần. .. ứng với điểm kết thúc của đơn vị chương trình - Mục tiêu của phương pháp kiểm thử luồng điều khiển là đảm bảo mọi đường thi hành của đơn vị phần mềm cần kiểm thử đều chạy đúng Rất tiếc trong thực tế, công sức và thời gian để đạt mục tiêu trên đây là rất lớn, ngay cả trên những đơn vị phần mềm nhỏ Câu hỏi 1.20: Đồ thị luồng dữ liệu gồm những yếu tố nào? Đồ thị luồng dữ liệu dùng để làm gì? Định nghĩa:Đồ... dụng cho phần mềm đại trà (đóng gói sẵn để bán) như là một hình thức kiểm thử mức chấp nhận nội bộ trước khi phần mềm chính thức đi vào giai đoạn kiểm thử Beta - Beta testing: (sau khi kiểm thử Alpha) là một hình thức mở rộng của kiểm thử mức chấp nhận của người dùng Các phiên bản của phần mềm, gọi là phiên bản beta, được phát hành cho một đối tượng hạn chế bên ngoài của nhóm lập trình Phần mềm này... định) + Cung cấp thêm các chỉ số độ tin cậy và chỉ số về chất lượng phần mềm nói chung (thẩm định) Câu hỏi 2.9: Giải thích sự khác nhau giữa kiểm thử hộp trắng và kiểm thử hộp đen? - Kiểm thử hộp đen (Black-box Testing): Là hình thức kiểm thử mà kiểm thử viên không cần biết đến cách thức hoạt động, mã nguồn, xử lý dữ liệu bên trong một thành phần/ hệ thống Công việc cần làm là nhập dữ liệu đầu vào (input)... tra cấu hình (Configuration Test) Kiểm tra khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống Kiểm tra khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến Acceptance Test - Kiểm tra chấp nhận