Chương I: Những nguyên tắc cơ bản của kiểm thử ( Fundamentals of Testing) Trong phần này chúng ta sẽ tìm hiểu các nguyên tắc cơ bản của kiểm thử : • Tại sao kiểm thử là cần thiết • Định nghĩa kiểm thử • Bẩy nguyên tắc kiểm thử • Quy trình kiểm thử cơ bản • Tâm lý học của kiểm thử 1.1. Tại sao kiểm thử là cần thiết Trước khi tìm hiểu chi tiết phần này chúng ta cần phải hiểu được các định nghĩa sau: • Bug : Nhìn thấy các khiếm khuyết (defect) • Defect : Một lỗ hổng trong một thành phần hoặc hệ thống khiến các thành phần hoặc hệ thống không thực hiện các chức năng cần thiết. • Error : Do hành động của con người tạo ra kết quả không chính xác • Failure : Sai lệch của thành phần hoặc hệ thống với kết quả mong đợi • Fault : Nhìn thấy kiếm khuyết (defect) • Mistake : Nhìn thấy lỗi (error) • Chất lượng - Quality : Mức độ mà thành phần, hệ thống hoặc quy trình đáp ứng các yêu cầu quy định và nhu cầu , mong đợi của người dùng/ khách hàng. • Rủi ro - Risk :Một yếu tố có thể dẫn đến kết quả tiêu cực trong tương lai thường được biểu hiện như tác động (impact) và khả năng (likelihood).
Chương I: Những nguyên tắc kiểm thử ( Fundamentals of Testing) Trong phần tìm hiểu nguyên tắc kiểm thử : • Tại kiểm thử cần thiết Định nghĩa kiểm thử Bẩy nguyên tắc kiểm thử Quy trình kiểm thử • Tâm lý học kiểm thử • • • 1.1 Tại kiểm thử cần thiết Trước tìm hiểu chi tiết phần cần phải hiểu định nghĩa sau: • • • • • • • • Bug : Nhìn thấy khiếm khuyết (defect) Defect : Một lỗ hổng thành phần hệ thống khiến thành phần hệ thống không thực chức cần thiết Error : Do hành động người tạo kết không xác Failure : Sai lệch thành phần hệ thống với kết mong đợi Fault : Nhìn thấy kiếm khuyết (defect) Mistake : Nhìn thấy lỗi (error) Chất lượng - Quality : Mức độ mà thành phần, hệ thống quy trình đáp ứng yêu cầu quy định nhu cầu , mong đợi người dùng/ khách hàng Rủi ro - Risk :Một yếu tố dẫn đến kết tiêu cực tương lai thường biểu tác động (impact) khả (likelihood) 1.1.1: Phạm vi hệ thống phần mềm Hệ thống phần mềm phần thiếu sống, từ ứng dụng kinh doanh tới sản phẩm tiêu dùng Phần mềm không làm việc cách xác dẫn đến nhiều vấn đề bao gồm việc tiền, thời gian, uy tín doanh nghiệp , chí gây chấn thương tử vong 1.1.2: Nguyên nhân khiếm khuyết phần mềm • • Con người làm lỗi(error - mistake) , tạo khiếm khuyết mã chương trình tài liệu Khiếm khuyết phần mềm, thống tài liệu dẫn đến thất bại, tất khiếm khuyết Nguyên nhân người tạo khiếm khuyết: o Áp lực thời gian o Các đoạn mã phức tạp Sự phức tạp sở hạ tầng Công nghệ thay đổi o Có nhiều tương tác hệ thống o o • Thất bại gây điều kiện môi trường 1.1.3: Vai trò kiểm thử phát triển phần mềm, bảo trì vận hành • Kiểm thử nghiêm ngặt hệ thống tài liệu, tìm thấy khiếm khuyết sửa chữa chúng trước phát hành để sử dụng giúp làm giảm rủi ro vấn đề xảy trình vận hành nâng cao chất lượng hệ thống phần mềm 1.1.4: Kiểm thử chất lượng • Kiểm thử đo lường chất lượng phần mềm khiếm khuyết tìm thấy (cả yêu cầu phần mềm chức phi chức năng) đặc tính: o Độ tin cậy o Khả sử dụng Hiệu Bảo trì o Tính di động o o • Kiểm thử tạo niềm tin vào chất lượng phần mềm tìm thấy lỗi Cải thiện chất lượng hệ thống tương lai cách rút học từ dự án trước Hiểu nguyên nhân gốc khiếm khuyết tìm thấy dự án • Kiểm thử hoạt động đảm bảo chất lượng • 1.1.5: Bao nhiêu kiểm thử đủ? • Bao nhiêu kiểm thử đủ nên dựa vào mức độ rủi ro, bao gồm rủi ro kinh doanh, bảo mật, kỹ thuật hạn chế dự án thời gian ngân sách • Kiểm thử nên cung cấp đầy đủ thông tin cho bên liên quan để định việc phát hành phần mềm hệ thống sau kiểm thử 1.2 Kiểm thử gì? Trong phần cần hiểu số định nghĩ sau : • • • Gỡ lỗi - Debugging : Quá trình tìm , phân tích loại bỏ nguyên nhân gây thất bại phần mềm Yêu cầu - Requirement: Một điều kiện cần thiết để người phát triển giải vấn đề đạt mục tiêu phải đáp ứng để đáp ứng hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật Đánh giá - Review: Đánh giá tình trạng sản phẩm dự án để xác định khác biệt từ kế dự định đề nghị cải tiến Bao gồm đánh giá quản lý, đánh giá thông tin, đánh giá kỹ thuật, kiểm tra (inspection) walkthrough • • • Trường hợp kiểm thử - Test case: Một tập giá trị đầu vào, thực điều kiện tiên quyết, kết mong đợi, phát triển cho mục tiêu cụ thể điều kiện kiểm thử Kiểm thử -Testing : Quá trình bao gồm tất vòng đời hoạt động, bao gồm kiểm thử tĩnh kiểm thử động, liên quan đến việc lập kế hoạch, chuẩn bị đánh giá hoạt động phần mềm sản phẩm để xác định đáp ứng yêu cầu quy định, chứng minh phù hợp với mục đích để phát khuyết tật Mục tiêu kiểm thử - Test objective: : Lý mục đích cho việc thiết kế thực hiển kiểm thử Định nghĩa : Kiểm thử trình bao gồm: • • Lập kế hoạch, chuẩn bị đánh giá hoạt động phần mềm sản phẩm Kiểm thử tĩnh kiểm thử động o Xác định đáp ứng yêu cầu quy định o Chứng minh phù hợp với mục đích o Phát khiếm khuyết Hoạt động kiểm thử tồn trước sau thực kiểm thử, bao gồm hoạt động sau: • • • • • • Lập kế hoạch kiểm soát Lựa chọn điều kiện kiểm thử Thiết kế thực trường hợp kiểm thử Kiểm tra kết Đánh giá tiêu chuẩn hoàn thành Báo cáo trình kiểm thử hệ thống sau kiểm thử • Hoàn thành hoạt động kiểm kết thúc kiểm thử sau giai đoạn kiểm thử hoàn thành Đánh giá tài liệu ( bao gồm mã nguồn(souce code) • Phân tích tĩnh • Kiểm thử có mục tiêu sau: • Tìm khiếm khuyết(defects) Đạt tin tưởng chất lượng Cung cấp thông tin để đưa định • Ngăn ngừa khiếm khuyết • • Mục tiêu kiểm thử giai đoạn khác • • • • Phát triển kiểm thử: Các khiếm khuyết xác định sửa chữa Kiểm thử chấp nhận: Xác nhận hệ thống hoạt động mong đợi đạt tin tưởng, phần mềm đáp ứng yêu cầu Bảo trì : Đảm bảo không xuất khiếm khuyết thay đổi phần mềm Vận hành: Đánh giá đặc điểm hệ thống độ tin cậy tính sẵn có 1.3 Bảy nguyên tắc kiểm thử Trong phần có định nghĩa sau: • Kiểm thử toàn - exhaustive testing : Một phương pháp tiếp cận kiểm thử kiểm thử chứa tất kết hợp giá trị đầu vào điều kiện tiên Nguyên tắc 1: Kiểm thử cho thấy diện khiếm khuyết Kiểm thử cho thấy có mặt khiếm khuyết, chứng minh phần mềm khiếm khuyết Kiểm thử giảm xác suất khiếm khuyết chưa tìm thấy phần mềm Nguyên tắc 2: Kiểm thử toàn Kiểm thử thứ không thực , trừ bao gồm số trường hợp bình thường Thay kiểm thử toàn , việc phân tích rủi ro dựa mức độ ưu tiên để tập trung lỗ lực kiểm thử vào số điểm cần thiết Nguyên tắc 3: Kiểm thử sớm Để tìm khiếm khuyết sớm, hoạt động kiểm thử nên bắt đầu sớm tốt vòng đời phát triển phần mềm hệ thống Nguyên tắc – Sự tập trung lỗi Nỗ lực kiểm thử nên tập trung cách cân đối vào mật độ lỗi dự kiến lỗi phát sau mô-đun Một số mô-đun thường chứa nhiều lỗi không phát lúc kiểm thử trước phát hành (release), chịu trách nhiệm cho hầu hết lỗi hoạt động phần mềm Để hiểu rõ nguyên tắc này, ta cần xem xét điều sau: Nguyên tắc tổ gián: chỗ có vài gián xung quanh có tổ gián -> có nhiều gián -> chỗ có vài bug xung quanh, gần gần chỗ có nhiều bug Nguyên tắc 80/20: thông thường 20% chức quan trọng chương trình gây đến 80% tổng số bug phát chương trình Kiểm thử toàn không thể(nguyên tắc thứ 2): cần phải ananlysis (phân tích) + priorities (tính toán mức độ ưu tiên) để định tập trung vào test chỗ => Test kỹ chức quan trọng => tìm bug => test liên quan chức gần để tìm bug nhiều Nguyên tắc – Nghịch lý thuốc trừ sâu Nếu việc kiểm thử tương tự lặp lặp lại nhiều lần, cuối có số trường hợp kiểm thử (ca kiểm thử - test case) không tìm thấy lỗi Để khắc phục "nghịch lý thuốc trừ sâu" này, trường hợp kiểm thử cần phải xem xét sửa đổi thường xuyên, cần phải viết test case khác để thực nhiều phần khác phần mềm hệ thống để tìm lỗi tiềm ẩn nhiều Nguyên tắc giống việc trừ sâu nông nghiệp, phun loại thuốc với nồng độ giống khoảng thời gian dài có số sâu quen dần cuối việc phun thuốc giống tắm chúng (bị lờn thuốc) => lúc diệt chúng Do vậy, để diệt sâu cách hiệu quả, người ta thường thay đổi loại thuốc trừ sâu, loại dùng khoảng thời gian ngắn Nguyên tắc – Kiểm thử theo ngữ cảnh độc lập Nguyên tắc việc kiểm thử phụ thuộc vào ngữ cảnh, kiểm thử nhiều ngữ cảnh khác Để hiểu rõ xem ví dụ sau: Ví dụ, với chương trình calculator có nhiều chức năng, nhưng: • Nếu test chương trình cho mẫu giáo cần test cộng trừ OK Nếu test chương trình cho cấp cộng trừ nhân chia • Nếu test chương trình cho đại học tích phân, đạo hàm, v.v • Nguyên tắc – Sự sai lầm việc lỗi Việc tìm sửa chữa lỗi không giúp hệ thống xây dựng xong dùng không đáp ứng nhu cầu mong đợi người dùng (Nghĩa sau code, test fix bug, làm đủ tất trường hợp cuối cho sản phẩm không mong đợi không đáp ứng nhu cầu khách hàng dự án phần mềm coi thất bại test xong) 1.4 Quy trình kiểm thử Các định nghĩa : • • • • Kiểm thử xác nhận - Confirmation testing : Xem lại kiểm thử Kiểm thử lại - Re-testing : Kiểm thử chạy trường hợp kiểm thử (test cases) thất bại để xác nhận thành công hoạt động khắc phục lỗi Tiêu chí hoàn thành - Exit criteria : Thiết lập điều kiện chung cụ thể , thỏa thuận với bên liên quan, cho phép trình hoàn thành Tiêu chí hoàn thành sử dụng để lập báo cáo kế hoạch dừng kiểm thử Kiểm thử hồi quy - Regression testing : Kiểm thử chương trình kiểm thử trước đó, để đảm bảo khiếm khuyết (lỗi) xuất • • • • • • • • • • phần thay đổi phần mềm Kiểm thử hồi quy thực phần mềm môi trường thay đổi Cơ sở kiểm thử - Test basis : Tất tài liệu mà từ yêu cầu thành phần hệ thống suy Các trường hợp kiểm thử(test cases) dựa tài liệu Kiểm tra điều kiện - Test condition : Một mục kiện thành phần hệ thống xác nhận nhiều test cases Kiểm tra liệu - Test data : Dữ liệu tồn (trong sở liệu) trước thử nghiệm thực thi, liệu có ảnh hưởng bị ảnh hưởng thành phần hệ thống thử nghiệm Thực kiểm tra -Test execution: Các trình chạy thử nghiệm thành phần hệ thống, tạo kết thực tế Kiểm tra log - Test log : Một ghi lịch sử chi tiết liên quan đến việc thực thử nghiệm Kế hoạch kiểm tra -Test plan : Một tài liệu mô tả phạm vi , phương pháp, nguồn lực tiến độ hoạt động thử nghiệm dự định Xác định mục kiểm tra, tính kiểm tra, nhiệm vụ kiểm thử, xác định người làm nhiệm vụ, mức độ độc lập người kiểm thử , môi trường thử nghiệm, kỹ thuật thiết kế thử nghiệm, lý lựạ chọn , kế hoạch dự phòng rủi ro Chính sách kiểm tra - Test policy : Tài liệu mức độ cao mô tả nguyên tắc, phương pháp mục tiêu tổ chức kiểm thử Bộ kiểm tra -Test suite : Một tập hợp nhiều trường hợp kiểm thử cho thành phần hệ thống kiểm thử Tóm tắt báo cáo kiểm tra -Test summary report : Một tài liệu tổng kết hoạt động kiểm thử kết Testware : Hiện vật tạo trình thử nghiệm để lập kế hoạch, thiết kế thực kiểm tra tài liệu , kịch bản, đầu vào, kết mong đợi, tập tin, sở liệu, môi trường phần mềm bổ sung trình tiện ích sử dụng kiểm thử Quy trình kiểm thử bao gồm hoạt động sau: 1.4.1: Lập kế hoạch giám sát - Test Planning and Control • Kế hoạch kiểm thử hoạt động xác định mục tiêu kiểm thử đặc điểm kỹ thuật hoạt động kiểm thử để đáp ứng mục tiêu nhiệm vụ • Giám sát kiểm thử hoạt động liên tục so sánh tiến độ thực tế với kế hoạch báo cáo tình trạng, bao gồm sai lệch so với kế hoạch Các hoạt động kiểm thử nên theo dõi suốt dự án 1.4.2: Phân tích thiết kế -Test Analysis and Design • • • • • • Là hoạt động mà mục tiêu kiểm thử chuyển thành điều kiện kiểm thử trường hợp kiểm thử Hoạt động phân tích thiết kế có nhiệm vụ chủ yếu sau: Xem xét kiểm thử bản(như yêu cầu,mức độ rủi ro, phân tích báo cáo rủi ro, kiến trúc , thiết kế đặc tả giao diện) Đánh giá mức độ khả dụng sở kiểm thử đối tượng kiểm thử Xác định độ ưu tiên điều kiện kiểm thử dựa việc phân tích đặc điểm kỹ thuật, hành vi cấu trúc phần mềm Thiết kế đánh giá trường hợp kiểm thử có mức độ ưu tiên cao 2.1.1 V-model ( mô hình phát triển tuần tự) - V-model (Sequential Development Model) V-model framework để mô tả hoạt động vòng đời phát triển phần mềm từ yêu cầu đặc tả để bảo trì V- model mô tả làm hoạt động kiểm thử tích hợp vào giao đoạn vòng đời phát triển phần mềm • Bốn mức độ kiểm thử sử dụng V-model: o Kiểm thử thành phần( đơn vị) o Kiểm thử tích hợp o Kiểm thử hệ thống o Kiểm thử chấp nhận • Bắt đầu sớm Thực trước kết thúc giai đoạn coding Thực song song • Các lỗi thường tìm thấy tài liệu, sở kiểm thử(test basis) • • Trong thực tế V-model có nhiều , mức độ khác phát triển kiểm thử , tùy thuộc vào dự án sản phẩm phần mềm Ưu điểm • Đơn giản dễ sử dụng • Có hoạt động, kế hoạch cụ thể cho trình test Tiết kiệm thời gian, có hội thành công cao waterfall • Chủ động việc phát bug, sớm tìm bug từ bước đầu • Nhược điểm • • • Độ linh hoạt tồn cứng nhắc Nó thể chỗ sau step lại phải có - công đoạn test, yêu cầu dự án không phức tạp dễ hiểu, việc thực nhiều công đoạn test tốn thời gian Giống với waterfall, sản phẩm dự án xuất tất bước hoàn thành xong, nguyên mẫu từ ban đầu Không đáp ứng yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm Nếu có thay đổi kỹ thuật nửa chừng, phải quay lại bước đầu tiên, thực lại, update lại tài liệu Áp dụng cho dự án • • • Dự án có kích thước nhỏ, trung bình, yêu cầu dự án rõ ràng, cố định Khi team phát triển có đội ngũ kỹ thuật tốt, có nguồn tài nguyên phong phú, sẵn có để đảm bảo yêu cầu, đọc nhanh, test nhanh coding nhanh Nếu khách hàng có tự tin cao yêu cầu thiết kế (nghĩa thay đổi, dao động) V model lựa chọn cần thiết 2.1.2: Mô hình phát triển Iterative-incremental Mô hình phát triển Iterative-incremental trình xây dựng yêu cầu, thiết kế, xậy dựng kiểm thử hệ thống loạt chu kỳ phát triển ngắn Ví dụ : nguyên mẫu (prototyping), Phát triển ứng dụng nhanh (RAD), Rational Unified Process (RUP) mô hình phát triển agile • • • • Phân chia thành số gia (increments ) xây dựng (builds) Các số gia ban đầu có sở hạ tầng cần thiết Các số gia kiểm thử với nhiều mức lần lặp Các công việc thực với số gia (Subsequent increments): o Kiểm thử chức o Kiểm thử hồi quy chức có o • Kiểm thử tích hợp phần phần cũ Xác minh xác nhận hợp lệ thực số gia Ưu điểm: • Sớm cung cấp thị trường Đơn giản để quản lý Giảm đầu tư ban đầu • Nhận thông tin phản hồi sớm • • 2.1.3 ; Kiểm thử mô hình vòng đời - Testing within a Life Cycle Model Trong mô hình vòng đời, có số đặc điểm kiểm thử tốt đây: • Mỗi hoạt động phát triển có hoạt động kiểm thử tương ứng • • • Mỗi cấp độ kiểm thử có mục tiêu kiểm thử cụ thể Phân tích thiết kế kiểm thử cho mức độ kiểm thử nên bắt đầu hoạt động phát triển tương ứng Tester nên tham gia vào việc xem xét tài liệu sau có tài liệu vòng đời phát triển phần mềm 2.2: Các mức kiểm thử - Test levels Trong phần có định nghĩa sau: • • • • • • • Alpha testing : Mô kiểm thử hoạt động thực tế người dùng/ khách hàng đội kiểm thử độc lập trang web nhà phát triển, bên đội phát triển Beta testing : Kiểm thử hoạt động người dùng tại/ khách hàng trang web bên không tham gia với người phát triển để xác định có hay không thành phần hệ thống đáp ứng nhu cầu khách hàng phù hợp với quy trình nghiệp vụ Beta testing thường sử dụng hình thức kiểm thử chấp nhận bên cho phần mềm off-the-shelf để có phản hồi từ thị trường Kiểm thử thành phần - Component testing : Kiểm thử thành phần phần mềm riêng lẻ Driver : Một thành phần phần mềm công cụ kiểm thử thay thành phần giám sát gội đến thành phần hệ thống Yêu cầu chức - Functional requirement : Một yêu cầu mà định chức mà thành phần hệ thống phải thực Tích hợp - Integration : Quá trình kết hợp thành phần hệ thống vào tập hợp lớn Kiểm thử tích hợp - Integration testing : Thực kiểm thử để lỗi giao diện tương tác thành phần tích hợp hệ thống • • • • • • • Yêu cầu phi chức - Non-functional requirement : Yêu cầu không liên quan đến chức liên quan đến thuộc tính độ tin cậy, tính hiệu quả, tính sử dụng , bảo trì tính di động Kiểm thử độ bền - Robustness testing : Kiểm thử xác định độ bền sản phẩm phần mềm Stub : Thực mục đích đặc biệt thành phần phần mềm, sử dụng để phát triển thử nghiệm thành phần mà gọi đến mục đích bị phụ thuộc vào Nó thay cho thành phần gọi Kiểm thử hệ thống - System testing : Quá trình kiểm thử hệ thống tích hợp để xác định đáp ứng yêu cầu quy định Kiểm thử môi trường -Test environment : Một môi trường có chứa phần cứng, thiết bị đo, thiết bị mô , công cụ phần mềm, thành phần hỗ trợ khác cần để tiến hành kiểm thử Mức độ kiểm thử - Test level : Một nhóm hoạt động kiểm thử tổ chức quản lý với nhau.Một mức độ kiểm thử có liên quan đến trách nhiệm dự án Phát triển định hướng kiểm thử - Test-driven development : Một cách phát triển phần mềm mà test cases phát triển thường tự động hóa trước phần mềm phát triển để chạy test case 2.2.1 : Kiểm thử thành phần - Component Testing • Cơ sở kiểm thử : o Các yêu cầu thành phần o Thiết kế chi tiết o • Code Đối tượng kiểm thử o Các thành phần o Chương trình o Chuyển đổi liệu , thay đổi chương trình o Mô hình sở liệu • • Kiểm thử thành phần ( gọi kiểm thử đơn vị, mô-đun, chương trình) tìm kiếm lỗi kiểm tra chức năng, module phần mềm, chương trình, đối tượng, lớp(class) Nó thực biệt lập với phần lại hệ thống, phụ thuộc vào vòng đời phát triển hệ thống Sơ khai (stubs), trình điều khiển, trình mô sử dụng Kiểm thử thành phần bao gồm : o Kiểm thử chức kiểm thử phi chức vận hành tài nguyên (tìm kiếm lỗ hổng nhớ) kiểm thử độ bền , kiểm thử cấu trúc ( bao phủ định) o Các trường hợp kiểm thử bắt nguồn từ sản phẩm công việc đặc điểm kỹ thuật thành phần, thiết kế phần mềm mô hình liệu • Kiểm thử thành phần thực truy cập vào code Người thực kiểm thử lập trình viên viết code • Phương pháp tiếp cận kiểm thử thành phần chuẩn bị tự động hóa trường hợp kiểm thử trước coding 2.2.2 : Kiểm thử tích hợp - Integration Testing • Cơ sở kiểm thử : o Thiết kế hệ thống phần mềm o Kiến trúc o Luồng công việc o • Các trường hợp sử dụng Đối tượng kiểm thử o Các hệ thống o Cơ sở liệu o Cơ sở hạ tầng o Giao diện o Cấu hình hệ thống cấu hình liệu • • Kiểm thử tích hợp kiểm tra giao diện thành phần, tương tác với phần khác hệ thống hệ điều hành, hệ thống file, phần cứng giao diện hệ thống Có nhiều mức độ kiểm thử tích hợp thực đối tượng quy mô khác sau: o Kiểm thử tích hợp thành phần, kiểm tra tương tác thành phần phần mềm thực sau kiểm thử thành phần o • • • • Kiểm thử tích hợp hệ thống, kiểm tra tương tác hệ thống khác phần cứng phần mềm Được thực sau kiểm thử hệ thống Kiểm thử tích hợp dựa kiến trúc hệ thống ( top-down bottomup), nhiệm vụ chức năng, trình tự xử lý giao dịch vài khía cạnh hệ thống phần mềm Để dễ dàng sữa lỗi phát lỗi sớm phương pháp kiểm thử tích hợp thường dùng “big bang” Kiểm thử tích hợp bao gồm kiểm thử phi chức (như kiểm thử hiệu suất) Tester người thực kiểm thử tích hợp Cả hai phương pháp tiếp cận chức ( functional) cấu trúc (structural) sử dụng Kiểm thử tích hợp lên kế hoạch trước thành phần hệ thống xây dựng 2.2.3: Kiểm thử hệ thống - System Testing • Cơ sở kiểm thử o Yêu cầu đặc tả phần mềm hệ thống o Các trường hợp sử dụng o Đặc tả chức o • Báo cáo phân tích rủi ro Đối tượng kiểm thử o Hệ thống, người sử dụng, hướng dẫn hoạt động o Cấu hình hệ thống cấu hình liệu • • • • • Kiểm thử hệ thống có liên quan với hành vi hệ thống/sản phẩm Trong kiểm thử hệ thống, môi trường kiểm thử phải tưng ứng với mục tiêu môi trường sản xuất để giảm thiểu rủi ro cố môi trường không tìm thấy kiểm thử Kiểm thử hệ thống bao gồm kiểm tra dựa rủi ro yêu cầu đặc tả, quy trình nghiệp vụ, trường hợp sửa dụng, mô hình hành vi hệ thống, tương tác với hệ điều hành tài nguyên hệ thống Kiểm thử hệ thống kiểm tra yêu cầu chức phi chức đặc tính chất lượng liệu Kiểm thử chức sử dụng kỹ thuật kiểm thử hộp đen Kiểm thử phi chức sử dụng kỹ thuật kiểm thử hộp trắng Một đội kiểm thử độc lập thường thực kiểm thử hệ thống 2.2.4 : Kiểm thử chấp nhận - Acceptance Testing • Cơ sở kiểm thử o Các yêu cầu người dùng o Các yêu cầu hệ thống o Các trường hợp sử dụng o Quy trình nghiệp vụ o • Đối tượng kiểm thử o Các quy trình nghiệm vụ hệ thống tích hợp đầy đủ o Quá trình vận hành bảo trì o Các dạng(forms) o Báo cáo o • • Báo cáo phân tích rủi ro Cấu hình liệu Kiểm thử chấp nhận thường thực khách hàng, người sử dụng hệ thống bên liên quan khác Mục đích kiểm thử chấp nhận để tạo niềm tin vào hệ thống, phận hệ thống đặc tính phi chức hệ thống Tìm lỗi • trọng tâm kiểm thử chấp nhận Kiểm thử chấp nhận không thiết phải mức cuối kiểm thử Kiểm thử chấp nhận xảy vào thời điểm khác vòng đời phát triển phần mềm, ví dụ : o Một sản phẩm phần mềm COTS kiểm thử chấp nhận cài đặt tích hợp o Kiểm thử chấp nhận kiểm tra tính tiện ích thành phần thực kiểm thử đơn vị o • Kiểm thử nâng cấp chức thực trước kiểm thử hệ thống Kiểm thử chấp nhận bao gồm hình thức đây: Người dùng kiểm thử chấp nhận Xác nhận phù hợp cho việc dụng hệ thống người dùng Vận hành kiểm thử Sự chấp nhận hệ thống quản trị viên hệ thống , bao gồm: • Kiểm thử lưu phục hồi • Khắc phục thảm họa • Quản lý người dùng • Các nhiệm vụ bảo trì • Tải liệu nhiệm vụ chuyển đổi • Kiểm tra định kỳ lỗ hổng bảo mật Hợp đồng quy chế kiểm thử chấp nhận • Hợp đồng kiểm thử chấp nhận thực theo tiêu chí chấp nhận hợp đồng Tiêu chí chấp nhận phải xác định bên thỏa thuận hợp đồng Quy chế kiểm thử chấp nhận thực phải tôn trọng quy định phủ 2.3: Các loại kiểm thử - Test types Các định nghĩa • Kiểm thử hộp đen - Black-box testing : Kiểm thử chức phi chức năng, không tham chiếu đến cấu trúc bên thành phần hệ thống • Độ bao phủ mã - Code coverage : Một phương pháp nhằm xác định phận phần mềm thực kiểm thử(test suite) phần không thực Ví dụ : bao phủ câu lệnh (statement coverage), bao phủ định (decision coverage) bao phủ điều kiện (condition coverage) • Kiểm thử chức - Functional testing : Kiểm thử dựa phân tích đặc điểm kỹ thuật chức , thành phần hệ thống • Kiểm thử khả tương tác - Interoperability testing : Quá trình kiểm thử để xác định khả tương tác sản phẩm phần mềm • Kiểm thử độ tải - Load testing : Một loại kiểm thử hiệu thực để đánh giá hành vi thành phần hệ thống với việc tăng độ tải (load) ví dụ: số người sử dụng, số giao dịch, để xác định tải mà xử lý thành phần hệ thống • Kiểm thử bảo trì - Maintainability testing : Các trình kiểm thử để xác định khả bảo trì sản phẩm phần mềm • Kiểm thử hiệu - Performance testing : Quá trình kiểm thử để xác định hiệu sản phẩm phần mềm • Kiểm thử tính di động - Portability testing : Quá trình kiểm thử để xác định tính di động sản phẩm phần mềm • Kiểm thử độ tin cậy - Reliability testing : Quá trình kiểm thử để xác định độ tin cậy sản phẩm phần mềm • Kiểm thử bảo mật - Security testing : Kiểm thử để xác định tính bảo mật sản phẩm phần mềm • Stress testing : Một loại kiểm thử hiệu thực để đánh giá hệ thống thành phần vượt giới hạn dự kiến độ tải công việc yêu cầu, giảm nguồn tài nguyên truy cập vào nhớ máy chủ (server) • Kiểm thử tính khả dụng - Usability testing : Kiểm thử để xác định phạm vi mà sản phẩm phần mềm hiểu rõ, dễ dàng tìm hiểu, dễ dàng hoạt động thu hút người sử dụng điều kiện quy định • Kiểm thử hộp trắng - White-box testing : Kiểm thử dựa phân tích cấu trúc nội thành phần hệ thống Có loại kiểm thử : • Kiểm thử chức • Kiểm thử phi chức • Kiểm thử cấu trúc/ kiến trúc phần mềm • Kiểm thử liên quan đến thay đổi 2.3.1 : Kiểm thử chức - Testing of Function (Functional Testing) • Kiểm thử chức kiểm thử "cái gì" mà hệ thống thực • Các chức mà hệ thống , hệ thống thành phần thực mô tả trong: o Các yêu cầu đặc điểm kỹ thuật (Requirements specification) o Các trường hợp sử dụng (use cases) o Một đặc tả chức o Hoặc tài liệu • Kiểm thử chức dựa chức tính ( mô tả tài liệu hiểu người kiểm thử ( testter)) khả tương tác tester với hệ thống • Được thực tất mức độ kiểm thử ( test levels) • Các kỹ thuật dựa đặc tả yêu cầu kỹ thuật sử dụng để lấy điều kiện kiểm thử trường hợp kiểm thử từ chức phần mềm hệ thống • Kiểm thử chức xem xét hành vi bên phần mềm Kỹ thuật phổ biến sử dụng kiểm thử chức kiểm thử hộp đen ( black-box testing) • Một loại kiểm thử chức kiểm thử bảo mật, điều tra chức liên quan đến việc phát mối đe dọa vius Một loại khác kiểm thử chức kiểm thử tương tác để đánh giá khả sản phẩm phần mềm tương tác với nhiều thành phần cụ thể hệ thống 2.3.2: Kiểm thử phi chức đặc tính phần mềm - Testing of Non-functional Software Characteristics • Kiểm thử phi chức kiểm thử “ làm nào” hệ thống làm việc tốt nhanh • Kiểm thử phi chức bao gồm o Kiểm thử hiệu (performance testing) o Kiểm thử độ tải (load testing) o Kiểm thử stress (stress testing) o Kiểm thử tính khả dụng (usability testing) o Kiểm thử bảo trì (maintainability testing) o Kiểm thử độ tin cậy (reliability testing) o Kiểm thử tính di động (portability testing) • Kiểm thử phi chức thực tất mức độ kiểm thử Nó mô tả kiểm thử cần thiết để đo lường đặc tính hệ thống phần mềm thời gian trả lời hệ thống • Kiểm thử phi chức xem xét hành vi bên phần mềm 2.3.3: Kiểm thử cấu trúc/ kiến trúc phần mềm - Testing of Software Structure/Archit cture (Structural Testing) • Kiểm thử cấu trúc ( white -box) thực tất mức độ kiểm thử • Kỹ thuật kiểm thử cấu trúc sử dụng tốt sau kỹ thuật dựa đặc điểm kỹ thuật( specification-based) Giúp đo lường kỹ lưỡng kiểm thử thông qua đánh giá độ bao phủ loại cấu trúc • Độ bao phủ phạm vi mà cấu trúc thực kiểm thử, tính theo phần trăm mục bao phủ Nếu độ bao phủ 100% kiểm thử thiết kế để kiểm tra mục bị bỏ lỡ để tăng độ bao phủ • Kiểm thử cấu trúc thực tất mức độ kiểm thử, đặc biệt kiểm thử thành phần (component testing) kiểm thử tích hợp thành phần • Phương pháp kiểm thử cấu trúc áp dụng mức độ kiểm thử tích hợp hệ thống kiểm thử chấp nhận • Kỹ thuật sử dụng : Kỹ thuật dựa vào cấu trúc mô hình luồng điều khiển thường sử dụng để hỗ trợ 2.3.4: Kiểm thử liên quan đến thay đổi - Testing Related to Changes: Re-testing and Regression Testing • Sau lỗi phát sửa chữa, phần mềm nên kiểm thử lại để xác nhận lỗi ban đầu xóa bỏ thành công gọi kiểm thử xác nhận (Confirmation testing) • Kiểm thử hồi quy kiểm thử lặp lặp lại chương trình kiểm thử, sau sửa đổi • o Việc phát lỗi coi kết việc thay đổi Các lỗi phần mềm kiểm thử, thành phần phần mềm liên quan không liên quan o Kiểm thử hồi quy thực phần mềm môi trường thay đổi o Phạm vi kiểm thử hồi quy dựa rủi ro lỗi không tìm thấy phần mềm làm việc trước Kiểm thử hồi quy thực tất mức độ kiểm thử , bao gồm kiểm thử chức năng, phi chức kiểm thử cấu trúc 2.4: Kiểm thử bảo trì - Maintenance Testing Định nghĩa : Kiểm thử thay đổi tới hoạt động hệ thống tác động thay đổi môi trường tới hoạt động hệ thống • Sau triển khai, hệ thống phần mềm thường phục vụ nhiều năm nhiều thập kỷ Trong thời gian cấu hình liệu môi trường hệ thống thường sửa chữa, thay đổi mở rộng Việc lập kế hoạch phiên phát hành trước quan trọng cho kiểm thử bảo trì thành công • Kiểm thử bảo trì thực hệ thống tồn tại, thực có thay đổi, di chuyển rút lui phần mềm hệ thống o Kiểm thử bảo trì cho việc thay đổi : Bao gồm việc lập kế hoạch cải tiến thay đổi lập kế hoạch nâng cấp sở liệu, hệ điều hành o Kiểm thử bảo trì cho việc di chuyển : Bao gồm kiểm tra hoạt động môi trường , phần mềm thay đổi Kiểm thử di chuyển ( kiểm thử chuyển đổi) cần thiết liệu từ ứng dụng khác di chuyển vào hệ thống bảo trì o Kiểm thử bảo trì cho việc rút lui hệ thống : Bao gồm kiểm thử chuyển đổi liệu lưu trữ liệu • Kiểm thử bảo trì bao gồm kiểm thử hồi quy đến phận thay đổi hệ thống • Phạm vi kiểm thử bảo trì liên quan đến rủi ro việc thay đổi , kích thước hệ thống có, kích thước thay đổi • Kiểm thử bảo trì thực tất mức độ kiểm thử tất loại kiểm thử • Kiểm thử bảo trì khó khăn đặc điểm kỹ thuật lỗi thời biến or người kiểm thử sẵn kiển thức miền (domain) [...]... một thứ tự cụ thể và bao gồm các thông tin cần thi t cho việc thực thi kiểm thử, môi trường được thi t lập và kiểm thử được chạy Thực hiện và thực thi có nhiệm vụ chủ yếu dưới đây: Hoàn thi n , thực hiện và đánh giá độ ưu tiên các trường hợp kiểm thử(bao gồm việc xác định dữ liệu kiểm thử) Phát triển và đánh giá độ ưu tiên các thủ tục kiểm thử, tạo dữ liệu kiểm thử, tùy chọn(optionally), chuẩn bị khai... Component Testing • Cơ sở kiểm thử : o Các yêu cầu thành phần o Thi t kế chi tiết o • Code Đối tượng kiểm thử o Các thành phần o Chương trình o Chuyển đổi dữ liệu , thay đổi chương trình o Mô hình cơ sở dữ liệu • • Kiểm thử thành phần ( còn gọi là kiểm thử đơn vị, mô-đun, chương trình) tìm kiếm các lỗi và kiểm tra các chức năng, module phần mềm, chương trình, đối tượng, các lớp(class) Nó có thể được thực... nhà phân tích, người thi t kế và các nhà phát triển Test leader và tester cần có kỹ năng giao tiếp tốt để truyền đạt thông tin thực tế về lỗi, tiến độ và rủi ro Đối với tác giả của phần mềm hoặc tài liệu, thông tin về lỗi có thể giúp họ cải thi n kỹ năng Lỗi được tìm thấy và sửa chữa trong thời gian kiểm thử sẽ tiết kiệm thời gian , tiền bạc và giảm thi u rủi ro Một số cách để cải thi n giao tiếp và...• • • Xác định các dữ liệu kiểm thử cần thi t Thi t kế và cài đặt môi trường kiểm thử , xác định cơ sở hạ tầng và các công cụ cần thi t Tạo ra định hướng truy tìm nguồn gốc giữ cơ sở kiểm thử và các trường hợp kiểm thử 1.4.3: Thực hiện và thực thi - Test Implementation and Execution • • • • • • • • • • • • Là hoạt động mà các thủ tục... within a Life Cycle Model Trong bất kỳ mô hình vòng đời, có một số đặc điểm của kiểm thử tốt như dưới đây: • Mỗi hoạt động phát triển có một hoạt động kiểm thử tương ứng • • • Mỗi cấp độ kiểm thử có mục tiêu kiểm thử cụ thể Phân tích và thi t kế kiểm thử cho một mức độ kiểm thử nên bắt đầu trong các hoạt động phát triển tương ứng Tester nên tham gia vào việc xem xét các tài liệu ngay sau khi có tài. .. và phân tích chúng để tìm ra nguyên nhân gây lỗi (ví dụ : lỗi trong code, dữ liệu đặc tả, tài liệu test, hoặc mistake trong khi kiểm thử được thực thi) Lặp đi lặp lại các hoạt động kiểm thử 1.4.4: Đánh giá tiêu chí hoàn thành và báo cáo - Evaluating Exit Criteria and Reporting • • • • • Là hoạt động mà các hoạt động thực thi kiểm tra được đánh giá dựa trên các mục tiêu xác định Nên được thực hiện đối... trường hợp sử dụng (use cases) o Một đặc tả chức năng o Hoặc có thể không có tài liệu • Kiểm thử chức năng được dựa trên các chức năng và tính năng ( được mô tả trong tài liệu hoặc được hiểu bởi những người kiểm thử ( testter)) và khả năng tương tác của tester với hệ thống • Được thực hiện ở tất cả các mức độ kiểm thử ( test levels) • Các kỹ thuật dựa trên đặc tả yêu cầu kỹ thuật có thể được sử dụng... cấp cơ sở dữ liệu, hệ điều hành o Kiểm thử bảo trì cho việc di chuyển : Bao gồm kiểm tra hoạt động của môi trường mới , các phần mềm đã thay đổi Kiểm thử di chuyển ( kiểm thử chuyển đổi) cũng cần thi t khi dữ liệu từ một ứng dụng khác sẽ được di chuyển vào hệ thống đang được bảo trì o Kiểm thử bảo trì cho việc rút lui của một hệ thống : Bao gồm kiểm thử chuyển đổi dữ liệu hoặc lưu trữ dữ liệu • Kiểm... ghi thay đổi cho bất kỳ những cái còn lại vẫn mở Lập tài liệu chấp nhận của hệ thống Hoàn thành và lưu trữ testware, môi trường kiểm thử và cơ sở hạ tầng kiểm thử Bàn giao testware cho bộ phận bảo trì Phân tích bài học kinh nghiệm để xác định những thay đổi cần thi t cho bản phát hành và các dự án trong tương lai Sử dụng thông tin thu thập để cải thi n kiểm thử 1.5 Tâm lý học của kiểm thử - The Psychology... độ của tính độc lập được định nghĩa từ thấp đến cao như dưới đây: o Các kiểm thử được thi t kế bởi những người viết phần mềm o Các kiểm thử được thi t kế bởi người khác (ví dụ như đội phát triên) o Các kiểm thử được thi t kế bởi người từ một nhóm tổ chức khác nhau hoặc chuyên gia kiểm thử o • • • • Các kiểm thử được thi t kế bởi người từ một tổ chức hoặc công ty khác nhau Tìm kiếm những thất bại trong