Tài liệu tham khảo môn Kiểm thử phần mềm - Nguyễn Văn Hiệp có nội dung trình bày một số thuật ngữ dùng trong quá trình kiểm thử phần mềm, giới thiệu các kĩ thuật hỗ trợ phát hiện lỗi và một số kĩ thuật để quản lý hoạt động kiểm thử phần mềm. Mời các bạn tham khảo nội dung chi tiết.
Chương Tổng quát kiểm thử phần mềm 1.1 Qui trình phát triển phần mềm RUP P hases C o r e W o r k flo w s I n ce p tion Elaboration Construction Tr a n s ition Requirements An iteration i n th e elaboration p h as e Analysis Design Implementation Test Preliminary Iteration(s) iter #1 iter #2 iter #n iter #n+1 iter #n+2 iter #m iter #m +1 I t e r a t io n s Chu kỳ phần mềm ₫ược tính từ lúc có yêu cầu (mới nâng cấp) ₫ến lúc phần mềm ₫áp ứng ₫úng yêu cầu ₫ược phân phối Trong chu kỳ, người ta tiến hành nhiều cơng ₫oạn : khởi ₫ộng, chi tiết hóa, thực chuyển giao Mỗi công ₫oạn thường ₫ược thực theo chế lặp nhiều lần ₫ể kết ngày hoàn hảo Trong bước lặp, thường thực nhiều workflows ₫ồng thời (₫ể tận dụng nguồn nhân lực hiệu nhất) : nắm bắt yêu cầu, phân tích chức năng, thiết kế, thực kiểm thử Sau lần lặp thực công việc ₫ó, ta phải tạo kết (artifacts), kết bước/công việc liệu ₫ầu vào bước/công việc khác Nếu thông tin không tốt ảnh hưởng nghiêm trọng ₫ến kết bước/hoạt ₫ộng sau ₫ó Một số vấn ₫ề thường gặp phát triển phần mềm : tính tốn khơng ₫úng, hiệu chỉnh sai liệu trộn liệu khơng ₫úng Tìm kiếm liệu sai u cầu Xử lý sai mối quan hệ liệu Coding/hiện thực sai qui luật nghiệp vụ Hiệu suất phần mềm thấp Kết hiệu suất phần mềm không tin cậy Hỗ trợ chưa ₫ủ nhu cầu nghiệp vụ Giao tiếp với hệ thống khác chưa ₫úng hay chưa ₫ủ Kiểm soát an ninh phần mềm chưa ₫ủ 1.2 Vài ₫ịnh nghĩa kiểm thử phần mềm Kiểm thử phần mềm qui trình chứng minh phần mềm khơng có lỗi Mục ₫ích kiểm thử phần mềm phần mềm thực ₫úng chức mong muốn Kiểm thử phần mềm qui trình thiết lập tin tưởng việc phần mềm hay hệ thống thực ₫ược ₫iều mà hỗ trợ Kiểm thử phần mềm qui trình thi hành phần mềm với ý ₫ịnh tìm kiếm lỗi Kiểm thử phần mềm ₫ược xem qui trình cố gắng tìm kiếm lỗi phần mềm theo tinh thần "hủy diệt" Các mục tiêu kiểm thử phần mềm : Phát nhiều lỗi tốt thời gian kiểm thử xác ₫ịnh trước Chứng minh sản phẩm phần mềm phù hợp với ₫ặc tả yêu cầu Xác thực chất lượng kiểm thử phần mềm ₫ã dùng chi phí nỗ lực tối thiểu Tạo testcase chất lượng cao, thực kiểm thử hiệu tạo báo cáo vấn ₫ề ₫úng hữu dụng Kiểm thử phần mềm thành phần lĩnh vực rộng hơn, ₫ó Verification & Validation (V &V), ta tạm dịch Thanh kiểm tra Kiểm ₫ịnh phần mềm Thanh kiểm tra phần mềm qui trình xác ₫ịnh xem sản phẩm cơng ₫oạn qui trình phát triền phần mềm có thoả mãn yêu cầu ₫ặt cơng ₫oạn trước khơng (Ta có ₫ang xây dựng ₫úng ₫ắn sản phẩm không ?) Thanh kiểm tra phần mềm thường hoạt ₫ộng kỹ thuật dùng kiến thức artifacts, yêu cầu, ₫ặc tả rời rạc phần mềm Các hoạt ₫ộng Thanh kiểm tra phần mềm bao gồm kiểm thử (testing) xem lại (reviews) Kiểm ₫ịnh phần mềm qui trình ₫ánh giá phần mềm cuối chu kỳ phát triển ₫ể ₫ảm bảo lòng sử dụng khách hàng (Ta có xây dựng phần mềm ₫úng theo yêu cầu khách hàng ?) Các hoạt ₫ộng kiểm ₫ịnh ₫ược dùng ₫ể ₫ánh giá xem tính chất ₫ược thực phần mềm có thỏa mãn yêu cầu khách hàng theo dõi với yêu cầu khách hàng không ? Kiểm ₫ịnh phần mềm thường phụ thuộc vào kiến thức lĩnh vực mà phần mềm xử lý 1.3 Kiểm thử : worker qui trình Test Engineer Component Engineer chịu trach nhi m v ̀ Integration Tester System Tester chịu trach nhi m v ̀ chịu trach nhi m v ̀ Test Model Test Test Plan Test case Test Test Procedure Evaluation Component Test defect Kỹ sư kiểm thử : người chuyên IT, chịu trách nhiệm nhiều hoạt ₫ộng kỹ thuật liên quan ₫ến kiểm thử ₫ịnh nghĩa testcase, viết ₫ặc tả thủ tục kiểm thử phân tích kết quả, báo cáo kết cho người phát triển quản lý biết Người quản lý kiểm thử : Thiết lập chiến lược qui trình kiểm thử, tương tác với người quản lý hoạt ₫ộng khác project, giúp ₫ỡ kỹ sư kiểm thử thực công việc họ Plan test Test Engineer Evaluate test Design test Perform Integration Test Integration tester Perform System Test System Tester Component Engineer Implement Test Tự ₫ộng số hoạt ₫ộng kiểm thử Kiểm thử phần mềm tốn nhiều chi phí nhân cơng, thời gian Trong số dự án, kiểm thử phần mềm tiêu hao 50% tổng giá phát triển phần mềm Nếu cần ứng dụng an tồn hơn, chi phí kiểm thử cịn cao Do ₫ó mục tiêu kiểm thử tự ₫ộng hóa nhiều có thể, nhờ ₫ó mà giảm thiểu chi phí nhiều, tối thiểu hóa lỗi người gây ra, ₫ặc biệt giúp việc kiểm thử hồi qui dễ dàng nhanh chóng Tự ₫ộng hóa việc kiểm thử dùng phần mềm ₫iều khiển việc thi hành kiểm thử, so sánh kết có ₫ược với kết kỳ vọng, thiết lập ₫iều kiện ₫ầu vào, kiểm soát kiểm thử chức báo cáo kết Thí dụ tiện ích phục vụ tự ₫ộng kiểm thử : Stress Test, Selenium, TestComplete, IBM Rational Functional Tester 1.4 Các mức ₫ộ kiểm thử phần mềm Kiểm thử ₫ơn vị (Unit Testing) : kiểm thử thực chi tiết ₫ơn vị nhỏ (hàm, class, ) có hoạt ₫ộng ₫úng khơng ? Kiểm thử module (Module Testing) : kiểm thử dịch vụ module có phù hợp với ₫ặc tả module ₫ó khơng ? Kiểm thử tích hợp (Integration Testing) : kiểm thử xem phân hệ phần mềm có ₫ảm bảo với ₫ặc tả thiết kế phân hệ ₫ó khơng ? Kiểm thử hệ thống (System Testing) : kiểm thử yêu cầu không chức phần mềm hiệu suất, bảo mật, làm việc môi trường căng thẳng, Kiểm thử ₫ộ chấp nhận người dùng (Acceptance Testing) : kiểm tra xem người dùng có chấp thuận sử dụng phần mềm không ? Kiểm thử hồi qui : ₫ược làm có hiệu chỉnh, nâng cấp phần mềm với mục ₫ích xem phần mềm có ₫ảm bảo thực ₫úng chức trước hiệu chỉnh không ? 1.5 Testcase Mỗi testcase chứa thông tin cần thiết ₫ể kiểm thử thành phần phần mềm theo mục tiêu xác ₫ịnh Thường testcase gồm thông tin {tập liệu ₫ầu vào, trạng thái thành phần phầm mềm, tập kết kỳ vọng} Tập liệu ₫ầu vào (Input): gồm giá trị liệu cần thiết ₫ể thành phần phầm mềm dùng xử lý Tập kết kỳ vọng : kết mong muốn sau thành phần phần mềm xử lý liệu nhập Trạng thái thành phần phần mềm : ₫ược tạo giá trị prefix postfix Tập testcase : tập hợp testcase mà ta có ý ₫ịnh dùng ₫ể kiểm thử thành phần phần mềm ₫ể minh chứng TPPM có ₫úng hành vi mong muốn Các phương pháp thiết kế testcase Bất kỳ sản phẩm kỹ thuật (phần mềm ngoại lệ) ₫ều ₫ược kiểm thử cách : Kiểm thử hộp ₫en (Black box testing) : theo góc nhìn sử dụng Không cần kiến thức chi tiết thiết kế thực bên Kiểm thử dựa yêu cầu ₫ặc tả sử dụng TPPM Kiểm thử hộp trắng (White box testing) : theo góc nhìn thực cần kiến thức chi tiết thiết kế thực bên Kiểm thử dựa vào phủ lệnh, phủ nhánh, phủ ₫iều kiện con, Kiểu kiểm thử Kỹ thuật kiểm thử ₫ược dùng Unit Testing White Box, Black Box Integration Testing Black Box, White Box Functional Testing Black Box System Testing Black Box Accceptance Testing Black Box 1.6 Các nguyên tắc kiểm thử Thông tin thiết yếu testcase kết hay liệu xuất kỳ vọng Nếu kết kỳ vọng testcase không ₫ược ₫ịnh nghĩa rõ ràng, người ta giải thích kết sai (plausible) thành kết ₫úng tượng “the eye seeing what it wants to see.” => test case phải chứa thành phần thiết yếu : ₫ặc tả ₫iều kiện liệu nhập ₫ặc tả xác kết ₫úng chương trình tương ứng với liệu nhập Việc kiểm thử ₫ịi hỏi tính ₫ộc lập : lập trình viên nên tránh việc kiểm thử TPPM viết Các issues tâm lý : Chương trình chứa lỗi lập trình viên hiểu sai ₫ặc tả/phát biểu vấn ₫ề Tổ chức lập trình khơng nên kiểm thử chương trình tổ chức viết Thanh tra cách xuyên suốt kết kiểm thử Phải thiết kế ₫ủ test case cho trường hợp : liệu ₫ầu vào hợp lệ liệu ₫ầu vào khơng hợp lệ chờ ₫ợi Xem xét chương trình xem khơng thực ₫iều mong muốn, xem có làm ₫iều khơng mong muốn ? Tránh testcase "throwaway" chương trình thật "throwaway" Không nên lập kế hoạch nỗ lực kiểm thử dựa giả ₫ịnh ngầm phần mềm khơng có lỗi Xác xuất xuất nhiều lỗi section phần mềm tỉ lệ thuận với số lỗi ₫ã phát ₫ược section ₫ó Kiểm thử tác vụ thách thức ₫òi hỏi sáng tạo trí tuệ Kiểm thử phần mềm nên bắt ₫ầu từ thành phần nhỏ ₫ơn giản ₫ến thành phần ngày lớn Kiểm thử theo kiểu vét cạn Nên hoạch ₫ịnh qui trình kiểm thử trước bắt ₫ầu thực kiểm thử 1.7 Các ý tưởng không ₫úng kiểm thử Ta kiểm thử phần mềm ₫ầy ₫ủ, nghĩa ₫ã vét cạn hoạt ₫ộng kiểm thử cần thiết Ta tìm tất lỗi kỹ sư kiểm thử làm tốt công việc Tập testcase tốt phải chứa nhiều testcase ₫ể bao phủ nhiều tình Testcase tốt ln testcase có ₫ộ phức tạp cao Tự ₫ộng kiểm thử thay kỹ sư kiểm thử ₫ể kiểm thử phần mềm cách tốt ₫ẹp Kiểm thử phần mềm ₫ơn giản dễ dàng Ai làm, khơng cần phải qua huấn luyện Chi phí quản lý field earmark không cao : Các thành viên ₫ội phát triển phải thống qui tắc tạo ₫ọc mã Thường ₫ặc tả phần mềm, ta dùng mã ₫ể nhận dạng module, class, hàm chức năng, mã dùng làm mã earmark cho lỗi tìm ₫ược Các thành viên ₫ội phát triển phải ₫iền giá trị ₫úng vào field cho lỗi bảng theo dõi lỗi mà tester tạo (sau họ sửa lỗi này) Phương pháp phân tích nguyên nhân gốc (root cause analysis) phương pháp tốn học lĩnh vực thống kê ₫ược trình bày phổ biến sách toán thống kê Người ta ₫ã dùng nhiều phương pháp ₫ể phân tích danh sách lỗi phát dự án phần mềm Ý tưởng phương pháp phân tích lỗi phát giúp tìm kiếm xác ₫ịnh chùm lỗi lớn (buggiest) : tính số lượng lỗi/tỉ lệ lỗi theo mã earcode lập thứ tự từ cao xuống thấp Phương pháp hữu dụng khoảng thời gian từ 1/3 tới 1/2 thời gian kế hoạch kiểm thử lúc phần mềm có ₫ộ ổn ₫ịnh thấp, nên cần nhiều sửa chữa cập nhật Kết phân tích nguyên nhân gốc dự án phần mềm giai ₫oạn ₫ầu công ₫oạn thực, lúc ₫ội phát triển ₫ã sửa ₫ược 2000 lỗi Phân tích số liệu bảng slide trước, ta thấy : cần thiết phải xem lại ₫oạn code bảng thiết kế liên quan gây nhóm lỗi AP234, AP745 GL106 (vì chúng chiếm tới 45.5% lỗi) trước tiến hành bước thực Lưu ý thêm nhóm lỗi AP234, AP745 có mối quan hệ khắng khích chúng thuộc module chức cịn lỗi thuộc nhóm AR218 có tỉ lệ tương ₫ối thấp nên ₫ược xem xét hay khơng tùy thuộc vào ₫ội kiểm thử ₫ã tìm hiểu nắm vững vùng code gây lỗi chưa Có thể bỏ qua việc xem lại vùng code chứa lỗi thuộc nhóm cịn lại chúng chiếm tỉ trọng nhỏ Sở dĩ xuất nhóm lỗi chứa nhiều lỗi : thiết kế khơng xác với chức thiết kế chưa ₫ầy ₫ủ viết code chưa ₫ủ debug code chưa ₫ủ dùng chuẩn lập trình khơng tốt người lập trình chưa thơng thạo nắm vững khả ngơn ngữ lập trình người lập trình chưa nắm vững giải thuật phức tạp ₫ược dùng ₫ể giải chức Việc xem lại vùng code chứa nhiều lỗi tốn thời gian (thí dụ tuần) làm cho bước bị delay, nhiên lợi lớn nhiều : việc xem lại vùng code/bảng thiết kế, ta tìm ₫ược số nguyên nhân gốc gây ₫ồng thời nhiều lỗi, cần sửa cập nhật nguyên nhân gốc nhiều lỗi ₫ã ₫ược sửa kiểm thử lại, số lỗi thuộc vùng code liên quan giảm thiểu lớn Thí dụ ta phát 50 lỗi (so với 1500 lỗi lần kiểm thử trước) lỗi tìm ₫ược có xu hướng khơng phải lỗi nặng ₫ược ₫ưa vào danh sách lỗi chưa sửa nên khơng cần sửa gắp chúng, ₫ể cho bước phát triển sau ₫ó thực Ta lặp lại việc phân tích nguyên nhân gốc dự án phần mềm giai ₫oạn sau ₫ó, thí dụ giai ₫oạn cuối phát triển phần mềm, ₫ội phát triển ₫ã sửa ₫ược 1500 lỗi Bây ta thấy : nhóm lỗi quan trọng chiếm tỉ lệ nhỏ (4.7%), ₫iều nói lên phần mềm ₫ã ổn ₫ịnh nhóm lỗi quan trọng bước trước AP234 GL106 danh sách, với tỉ lệ nhỏ Điều cho thấy tính hiệu việc dùng mã earmark việc xem xét lại vùng code tương ứng nhóm lỗi quan trọng chiếm tỉ lệ nhỏ nên việc phân tích ngun nhân gốc bước khơng có tác dụng lớn lúc trước Mặc dù vậy, thông tin earmark hữu dụng cho việc quản lý danh sách lỗi chưa sửa (backlog) 10.5 Dùng mẫu phát lỗi project trước Việc tiên ₫oán số lỗi mà ₫ội kiểm thử phát ₫ược dự án hành quan trọng, giúp ta ₫ưa kế hoạch, chuẩn bị tài nguyên kiểm thử hiệu Nếu không dựa thông tin nào, chưa có phương pháp giúp ta tiên ₫ốn xác ₫ược Tuy nhiên, có số phương pháp dựa vào yếu tố lịch sử giúp ta tiên ₫ốn với ₫ộ xác nằm phạm vi lệch 10% Phương pháp tiên ₫oán dựa vào yếu tố lịch sử ₫ặc biệt thích hợp cho công ty phần mềm lâu ₫ời, họ ₫ã phát triển thành cơng nhiều phần mềm với nhiều kích cở khác theo thời gian Càng có nhiều thơng tin record miêu tả lỗi project trước cho ta tiên ₫ốn với ₫ộ xác cao Chúng ta bắt ₫ầu thông tin record lỗi : mã lỗi ngày phát Đường biểu diễn lỗi phát project 200KLOC, ₫ược kiểm thử 24 tuần Đường cong miêu tả việc phát lỗi project trước cho thông tin chung cho hầu hết project phần mềm : lúc ₫ầu số lỗi phát ₫ược thường nhiều lên nhanh tới ₫ỉnh thời ₫iểm khoảng 1/3 thời gian phát triển phần mềm (giai ₫oạn ₫ầu ₫ộ ổn ₫ịnh phần mềm thấp) sau ₫ó số lỗi ₫ược phát giảm dần phần mềm ngày hoàn chỉnh ổn ₫ịnh ₫iểm A miêu tả số lỗi ₫ược phát nhiều (là 749 lỗi) ₫iểm B miêu tả tuần phát lỗi nhiều (là tuần 10) ₫iểm C miêu tả tuần kết thúc việc phát triển phần mềm (tuần 24) vùng C ₫ường cong (diện tích vùng) miêu tả tổng số lỗi tìm ₫ược dự án phần mềm (11,497) Có nhiều nghiên cứu nói : ta tìm ₫ược lỗi nhiều sớm lỗi ₫ược phát khách hàng sau Lưu ý chi phí sửa lỗi khách hàng phát ₫ược lớn Nghiên cứu cịn nói ta nội suy ₫ường biểu diễn lỗi phát phía phải trục x ₫ến tiếp xúc trục x vùng nới rộng (vùng D) xỉ số lỗi mà khách hàng phát ₫ược sau ₫ó Biểu ₫ồ nới rộng ₫ược vẽ slide kế cho ta thấy ₫iểm D tiếp xúc với trục x tuần 36, số lỗi vùng D 487 lỗi 10.6 Sử dụng biểu ₫ồ phân loại nhóm lỗi Nếu record thơng tin lỗi ₫ược phát project trước có thêm field miêu tả mức ₫ộ tầm trọng lỗi (1-4), ta xây dựng sử dụng biểu ₫ồ phân loại nhóm lỗi sau : Từng chu kỳ (tuần), tính số lượng lỗi thuộc mức nặng/nhẹ phát ₫ược (ta dùng mức) Xếp tầng số lỗi thuộc mức nặng/nhẹ tuần vẽ thành cột cho tuần ₫ó Dựa vào kết biểu ₫ồ ta rút ₫ược kết luận : Các lỗi có mức ₫ộ nặng thường xảy ₫ược phát sớm lúc project chưa có ₫ộ ổn ₫ịnh cao Mức ₫ộ lỗi phát giảm dần sau project ngày ổn ₫ịnh 10.7 Độ tương quan lỗi khách hàng phát Trong khoảng thời gian từ lúc project trước ₫ã hoàn thành ₫ến lúc project sau ₫ược phát triển, ta có thêm nhiều thơng tin khác Một thông tin quan trọng số lượng lỗi tính chất lỗi ₫ược phát phản hồi phận HelpDesk khách hàng Ta dùng ₫ộ tương quan lỗi khách hàng phát sau : Tỉ lệ lỗi tiên ₫oán/lỗi ₫ược khách hàng phát thực tế 487/70 = 6.9 Nhờ ₫ộ tương quan mà ta tiên ₫oán ₫ược số lượng lỗi mà khách hàng phát ₫ược sử dụng project phần mềm phát triển Dựa vào số lượng lỗi mà ta qui hoạch tương ₫ối xác số lượng thời lượng làm việc nhân viên phận hỗ trợ (Support) giúp ₫ỡ (HelpDesk) người dùng ⇒ dự tốn xác chi phí sửa lỗi Bảng theo dõi lỗi ₫ược phản ánh khách hàng phận giúp ₫ở khách hàng ghi nhận phận phát triển phân loại nhóm lỗi Bắt ₫ầu project Lúc ta ₫ã có : số lượng hàng lệnh số lỗi project trước (₫ược thể ₫ường cong miêu tả số lỗi phát ₫ược) mức ₫ộ tầm trọng lỗi cách phân phối chúng theo thời gian (₫ược thể biểu ₫ồ phân phối mức ₫ộ lỗi project trước) So sánh với số lượng hàng lệnh project ₫ang phát triển, ta tính số lượng lỗi cho project này, từ ₫ó kế hoạch hóa việc kiểm thử, chuẩn bị tài nguyên phù hợp cho việc kiểm thử Trong chu kỳ kiểm thử, ta tổng kết vẽ số lượng lỗi phát trực tiếp lên ₫ường biểu diễn project trước ₫ể dễ dàng so sánh nội suy thông tin cần Do project có qui mơ tính chất khác nhau, số lượng lỗi phát tuần ₫ầu khác Thí dụ Project hành A có số lỗi phát ₫ược nhiều project cũ tốc ₫ộ phát lỗi tuần ₫ầu cao nhiều so với project cũ Đây xu mà ta mong muốn Điều ₫ặt câu hỏi : ta kiểm thử hiệu trước ? Câu trả lời ta dùng nhiều tools kiểm thử tự ₫ộng trước Thí dụ Project hành B có số lỗi phát ₫ược project cũ tốc ₫ộ phát lỗi chậm so với project cũ Đây xu mà ta không mong muốn Điều ₫ặt câu hỏi : ta kiểm thử hiệu trước ? Câu trả lời ta bỏ ₫i hay làm thiếu số hoạt ₫ộng mà project trước ₫ã làm Sau xác ₫ịnh ₫ược nguyên nhân rõ ràng, ta khắc phục ₫ể việc kiểm thử hiệu cho tuần lại Khi project tiếp tục Tiếp tục kiểm soát vẽ ₫ường cong biểu diễn lỗi phát cột mốc trình phát triển phần mềm Tới lúc ₫ó, thường khoảng 1/3 thời gian phát triển phần mềm, tốc ₫ộ phát lỗi (số lỗi phát hiện/trên tuần) ₫ạt ngưỡng bắt ₫ầu giảm xuống Điểm uốn ₫iểm neo quan trọng cho hầu hết hoạt ₫ộng phân tích kết lỗi : Project A có ₫iểm ngưởng tuần với số lượng 1213 lỗi ⇒ Project A ₫ược kiểm thử hiệu project cũ Project B có ₫iểm ngưỡng tuần 12 với số lượng 607 lỗi ⇒ Project B ₫ược kiểm thử hiệu project cũ project A Khi project kết thúc Tiếp tục kiểm thử vẽ kết theo thời gian Mỗi lần vẽ ₫iểm vào ₫ồ thị, ta phân tích ₫iểm có bất thường khơng ? Nếu có ₫ặt câu hỏi tạo từ ₫ó có biện pháp khắc phục Khi project kết thúc (giả sử theo kế hoạch tuần 24 biểu ₫ồ), ta nội suy nới rộng ₫ồ thị sang phải cho ₫ến tiếp xúc trục x Một số tiên ₫oán ước lượng : Project A chứa 14 lỗi ₫ược tiên ₫oán khách hàng tìm ₫ược nên có lỗi mà khách hàng thực tìm → chi phí sửa 2*14000 = 28000$ (giảm ₫ược 952000$ so với project trước) Project B chứa 1377 lỗi ₫ược tiên ₫ốn khách hàng tìm ₫ược nên có 196 lỗi mà khách hàng thực tìm → chi phí sửa 196*14000 = 2744000$ (tăng 1746000$ so với project trước) 10.8 Đường cong Rayleight - Gunsight cho mẫu phát lỗi Làm biết ₫ược tốc ₫ộ phát lỗi project công nghiệp hãng lớn ? Nhờ ₫ó so sánh, ₫ánh giá hoạt ₫ộng kiểm thử project ? Rất tiếc, ta khó lịng có ₫ược thơng tin xác thực cơng ty phần mềm có khuynh hướng dấu nhẹm, khơng cơng bố (vì ảnh hướng lớn ₫ến hình ảnh cơng ty) Hiện nguồn cung cấp chủ yếu ứng dụng ₫ường cong Rayleight Đây cơng thức tốn học cho phép ta tái tạo ₫ường cong chuẩn dựa vào ₫iểm ngưỡng (gunsight) Đường cong chuẩn sai lệch so với giá trị thật nhiều dự án phần mềm năm gần ₫ây 10% 10.9 Các thước ₫o khác theo dõi lỗi Các thước ₫o hoạt ₫ộng phát triển phần mềm : mã lỗi phát triển ngày phát lỗi phát triển mức ₫ộ trầm trọng lỗi phát triển ngày sửa lỗi phát triển mã earcode lỗi phát triển Các thước ₫o hoạt ₫ộng HelpDesk : mã lỗi khách hàng ngày phát lỗi khách hàng mức ₫ộ trầm trọng lỗi khách hàng ngày sửa lỗi khách hàng mã earcode lỗi khách hàng Thước ₫o khác : ODC (Orthogonal Defect Classifi cation) hãng IBM 10.10 Kết chương Chương ₫ã giới thiệu số thuật ngữ ₫ược dùng hoạt ₫ộng quản lý trình kiểm thử phần mềm Chúng ta ₫ã giới thiệu số kỹ thuật phổ dụng ₫ể hỗ trợ việc phát lỗi phát lỗi dựa vào lỗi ₫ã phát ₫ược, phát lỗi dựa vào backlog, phát lỗi dựa vào chùm lỗi Chúng ta ₫ã giới thiệu số kỹ thuật ₫ể quản lý hoạt ₫ộng kiểm thử phần mềm dùng ₫ường cong phát lỗi project trước, dùng biểu ₫ồ phân loại nhóm lỗi project trước, dùng ₫ường cong Rayleight ... Vài ₫ịnh nghĩa kiểm thử phần mềm Kiểm thử phần mềm qui trình chứng minh phần mềm khơng có lỗi Mục ₫ích kiểm thử phần mềm phần mềm thực ₫úng chức mong muốn Kiểm thử phần mềm qui trình thiết... không ₫úng ₫ắn kiểm thử phần mềm, hạn chế hoạt ₫ộng kiểm thử phần mềm Chương Qui trình & Kế hoạch kiểm thử phần mềm 2.1 Giới thiệu Qui trình kiểm thử phần mềm ? Chế ₫ộ kiểm thử ₫ược ₫ịnh nghĩa... kiểm thử phần mềm, thuật ngữ hoạt ₫ộng kiểm thử phần mềm Chương ₫ã giới thiệu vai trị worker qui trình kiểm thử phần mềm, mức ₫ộ kiểm thử phần mềm khác nhau, nguyên tắc kiểm thử phần mềm Chương