Tìm hiểu về Testing

Testing là gìLà quá trình thực hiện một chương trình (hay một phần của một chương trình) để tìm ra lỗiLà pha quan trọng trong quá trình phát triển hệ thống giúp cho người xây dựng hệ thống và khác hàng đã thấy được hệ thống mới đã thoả mãn yêu cầu đề ra chưaTest phần mềm là vấn đề kỹ thuật thách thức hơn cả việc xây dựng phần mềmTầm quan trọng của nó đối với ngành phần mềmMột phần mềm được làm ra không ai có thể đảm bảo nó không có lỗiTesting sẽ tìm và phát hiện lỗi (mang tính ứng dụng hoặc thậm chí mang tính công nghệ) với mục đích cuối cùng là bảo đảm sản phẩm đến tay người dùng phải là tốt nhất, nhanh nhất, ổn định nhátHoạch định chiến lược nghiên cứu và ứng dụng, đảm bảo sp làm ra đạt tiêu chí và kỹ thuật đề raGhi nhận các ý kiến, đề xuất hoặc báo cáo hỏng hóc từ người dùngCác phương pháp testingBlack box testWhite box testBlack-box Test – Khái niệmBlack box test: hay còn gọi là test hộp đenTest dựa trên hoạt động của chức năng, không đòi hỏi kiến thức về các mã phần mềm hoặc cấu trúcPhương pháp này quan tâm tới việc thực hiện các chức năng (hành vi), dữ liệu đầu vào và kết quả đầu ra ra sao  fải chuẩn bị và sử dụng các khả năng có thể xảy ra của dữ liệu InputBlack-box Test – Phương phápĐể thực hiện phương pháp này cần dựa trên:Yêu cầu của phần mềmCác trạng thái Các trường hợp sử dụng (use case)Kiểm tra các giá trị biênPhân lớp tương đươngTest cú phápTest luồng dữ liệu (dữ liệu được lấy từ đặc tả yêu cầu)White box Test – Khái niệmQuan tâm tới cấu trúc và logic bên trong của đoạn mã.  cần có kiến thức về cấu trúc phần mềmĐược định nghĩa bởi: Programming styleControl methodLanguageDatabase designCoding detailsWhite box Test – Kỹ thuậtTest cấu trúcTest nhánhLuồng dữ liệu testTest điều kiện nhánhTest điều kiện nhánh tích hợpTest các điều kiện thay đổiCác giai đoạn testSoftware V&V PlanSystem Test PlanIntegration Test PlanUnit Test PlanAcceptance Demonstration PlanSoftware Development PhasesTest Planning PhaseTest Execution PhaseProject PlanRequirements SpecArchitectural Design SpecCodeSystemTestAcceptanceDemonstrationIntegrationTestInstallUnitTestDetailed Design SpecCác giai đoạn testUnit TestIntergration TestSystem TestAcceptance TestUnit Test – Khái niệm Một Unit là thành phần nhỏ nhất của phần mềm, như là: Function, Procedure, Class, MethodLà kỹ thuật kiểm nghiệm các hoạt động của mọi chi tiết mã với một quy trình tách biệt với QT PTPM giúp phát hiện sai sót kịp thời trước khi đưa ra test Unit Test – Đặc điểmTest ở mức thấp nhấtSử dụng phương pháp test hộp trắngKiểm tra độc lập từng thành phầnThường được thực hiện bởi lập trình viênCó giá trị khi phát hiện các vấn đề tiềm ẩn hoặc lỗi kỹ thuậtIntergration test – Khái niệmLà test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thànhMục đíchPhát hiện lỗi giao tiếp xảy ra giữa các UnitTích hợp các Unit đơn lẻ thành các hệ thống nhỏ và cuối cùng là nguyên hệ thống hoàn chỉnhIntergration test - TypeKiểm tra cấu trúc (structure): Tương tự White Box Test, chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình Kiểm tra chức năng (functional): Tương tự Black Box Test, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuậtKiểm tra hiệu năng (performance): Kiểm tra vận hành của hệ thốngKiểm tra khả năng chịu tải (stress): Kiểm tra giới hạn của hệ thốngIntergration test - PlanCần được thực hiện tương đương với giai đoạn thiết kế kiến trúcThứ tự tích hợp được xác định theo thứ tự xây dựngCác thành phần hoàn thành đúng thời hạnPhát triển các thành phần và test tích hợp được thực hiện song songIntergration - GuidelinesMỗi thành phần sẽ được tích hợp 1 lần(tích hợp theo hướng tăng dần Baseline 0: test thành phần Baseline 1: 2 thành phần Baseline 2: 3 thành phần)Tích hợp từng mục nhỏ của từng thành phần tại một thời điểmCác thành phần chính hoặc thành phần có khả năng nhiều lỗiKết hợp các thành phần liên quan đơn giản Intergration-Approaches Top-downBottom-downBig-bang Intergration-ApproachesTop-DownCác module cấp trên được kiểm thử trướcBaselines:baseline 0: component abaseline 1: a + bbaseline 2: a + b + cbaseline 3: a + b + c + dEtcabcdefghijklmnoabcdefghijIntergration-ApproachesƯu điểm Top-downPhát hiện sớm các lỗi thiết kếCó phiên bản hoạt động sớmNhược điểmKhó có thể mô phỏng được các chức năng của module cấp thấp phức tạpKhông kiểm thử đầy đủ các chức năng Intergration-ApproachesBottom-upCác module cấp thấp được kiểm tra trước abcdefghijklmnoabcdefghijBaselines: baseline 0: component baseline 1: n + ibaseline 2: n + i + obaseline 3: n + i + o + dEtc.Intergration-ApproachesƯu điểm Bottom-upThuận tiện cho phát triển các mô đun thứ cấp dùng lại đượcNhược điểmPhát hiện chậm các lỗi thiết kếChậm có phiên bản thực hiện được của hệ thốngIntergration-ApproachesBig-bangTất cả các module được kết hợp trong 1 bướcLà phương pháp tích hợp thông thườngLà phương pháp ít hiệu quả nhấtHạn chế dùng Big-bangRất khó tìm ra nguồn gốc của vấn đềKhông biết nơi nào để xem xétKhông ngoại trừ recommended cho các hệ thống rất nhỏSystem test – Khái niệmLà kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay khôngLà Black box testĐược thực hiện độc lập bởi một nhóm test (test hệ thống)System test – Khái niệmVề chức năng, thỏa mãn:Requirements-based testingCác yêu cầu là điều kiện đầu tiên cho việc testPhân tích rủi ro để xác định thành phần quan trọng nhấtBusiness process-based testingNgười sử dụng mong đợi: cái gì được sử dụng thường xuyên và quan trọng nhất cho việc kinh doanhThực hiện các giao dịch kinh doanh qtrọngSystem test – Khái niệmYêu cầu phi chức năng:UsabilitySecurityStorageVolumeConfiguration/installationReliability/qualitiesBack-up/recoveryPerformance, load, stressFunctionalAcceptance testĐược thực hiện sau giai đoạn System test, do khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ 3 thực hiện)Mục đích: chứng minh phần mềm thỏa mãn tất cả các yêu cầu của khách hàngĐối với những PM bán rộng rãi trên thị trường, cần thực hiện: Alpha test và Beta TestAcceptance testAlpha test: người sử dụng kiểm tra phần mềm ngay tại nơi PTPM, lập trình viên ghi nhận lỗi hoặc phản hồi và lên kế hoạch sửa chữaBeta test: PM được gửi tới cho người sử dụng để kiểm tra ngay trong môi trường thực, lỗi, hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửaProcess Test TestPlanningTestSpecificationTestReportingĐầu vào/ đầu ra cho testingĐầu vàoYêu cầu của khách hàng, các tiêu chuẩnCác yêu cầu thay đổiSRSTài liệu thiết kế (ADD, DDD)Chương trìnhĐầu raTài liệu: test plan, test case và procedures List lỗiBáo cáo testTest Plan Khái niệmMô tả các module cần kiểm tra, phương pháp kiểm tra (black box hoặc white box)Xác định các yêu cầu dựa trên các yêu cầu người dùngXác định chiến lược test: test type, stage, toolsXác định nguồn lực và trách nhiệm, xác định hệ thống (phần cứng, phần mềm)Xác định những yêu tố, module quan trọngTest Plan-Hoạt độngPhạm vi test: Trạng thái và loại test?Xác định yêu cầu cho test: Test sẽ làm gì?Xác định chiến lược test: Thực hiện như thế nào?Xác định nguồn lực và môi trườngLập lịch trình Test.Tổng hợp thông tin, lập kế hoạch TestXem xét và thông qua kế hoạch Test.Tiêu chuẩn hoàn thành.Công cụ sẽ sử dụng để TestĐánh giá rủi ro và lập mức độ rủi ro cho các yêu cầu.Chuyển giao test.Test Plan – Nội dungĐịnh nghĩa tài liệuGiới thiệuTest các mục nhỏCác đặc trưng cần testĐưa ra các phương phápĐưa ra các tiêu chuẩn đánh giá một mục là pass hay failLập kế hoạch cho các tiêu chuẩn bị dừng lại và các yêu cầu được bắt đầu lạiPhân chia công việc cần testCác task vụ cần thực hiện testMôi trường cần thực hiệnPhân công người chịu trách nhiệm cho các task vụ Nhân công và việc đào tạo Lịch biểuRủi ro và các sự việc xảy ra khách quanPhê duyệt và chuyển giao sản phẩm.Test SpecificationTest designCải tiến phương pháp testXác định các vấn đề (feature) cần phải cover khi thực hiện testXác định các test caseĐặc tả rõ các tiêu chuẩn nào pass/ fail cho mỗi vấn đề (feature) đưa raTest SpecificationTest caseTài liệu các giá trị input thực tế và kết quả mong đợi cho mỗi test case được thực hiện.Định nghĩa các ràng buộc dựa trên các thủ tục test.Việc định nghĩa các test case là độc lập với việc thiết kế test để có thể sử dụng lại một cách đễ dàng.Test procedureĐịnh nghĩa tất cả các bước thực hiện testChạy hệ thốngThực hiện các testcaseĐưa ra các chỉ dẫnTest Design-Nội dungĐịnh nghĩa tài liệu testCác vấn đề cần được testCác phương pháp yêu cầuĐịnh nghĩa các trường hợp testTiêu chuẩn đánh giá các tiêu chuẩn pass/failTest case, Procedure – Nội dungTest caseĐịnh nghĩa tài liệu testTest itemsĐặc tả các dữ liệu input Đặc tả dữ liệu out putMôi trườngCác yêu cầu đặc biệtTest ProcedureĐịnh nghĩa tài liệuMục đíchCác yêu cầu đặc biệtProcedure steps (thực hiện từng hiện)Test ReportTest Item Transmittal ReportĐịnh dạng phần mềm được chuyển giao tới các nhóm test độc lập.Sử dụng trong trường hợp mà các mẫu ban đầu của việc test được đưa ra.Test LogSử dụng cho những người tham gia vào việc quản lý các kết quả tesMục đích là ghi lại những gì xảy ra trong suốt quá trình test.Test Incident ReportMô tả một vài sự kiện xuất hiện trong suốt quá trình test mà trong đó mong muốn được phát triển xa hơn.Ví dụ như:Thiết bị, công cụ lỗiCác sự kiện, phần không được rõ ràng, chính xác.Các bất thường xảy ra.Test Log, Test Incident – Nội dungTest LogĐịnh nghĩa tài liệuMô tảCác sự kiện và hoạt động (Activity and event entries)Test IncidentDocument identifierSummaryIncident descriptionImpactTest Report – Nội dungĐịnh nghĩa các tài liệuTổng kếtChỉ ra các mâu thuẫn, thay đổiĐánh giá một cách toàn diệnTóm tắt sơ lược kết quảƯớc lượng/Tổng kết các hoạt độngPhê chuẩn.KT viết TC hiệu quảMột testcase được cho là hiệu quả:Test case hiệu quả là test case mà tìm thấy bug.Tìm được nhiều bug khó.Chỉ ra được những điểm ban đầu mà khi thực hiện test không tìm ra vấn đềTuân theo đúng các con số thống kê bugTheo dõi các lỗi theo các trường hợp đã được tìm thấyKT viết TC hiệu quảFor each identified requirement; define test cases.Test CasesFor Req. #1Requirement #1Requirement #2Requirement #3Test CasesFor Req. #2KT viết TC hiệu quảEquivalence class partitioningControl flow testingData flow testingTransaction testingDomain testingLoop testingSyntax testingFinite state machine testingLoad and stress testingEquivalence class partitioningXác định một nhóm các yêu cầu hệ thống, functions, behaviorsPhân các testcase vào các class. Mỗi class là một nhóm các testcase tương tự nhauTrong mỗi class chọn test chỉ một vài testcasePhân các test case theo nhóm các TestCase cùng loại, gọi là class hay lớp các TestCaseCác class lại có thể xếp vào 2 nhómPositive tests (clean tests)Test dựa trên defined requirementsTest những trường hợp, hoàn cảnh sử dụng thông thườngNegative tests (dirty tests)Test nhằm tìm ra lỗiTest những trường hợp, hoàn cảnh sử dụng đặc biệt, bất thường (như invalid input, vượt giá trị biên, chịu stress)Control FlowLà kỹ thuật test căn bảnSử dụng luồng xử lý để thiết lập các phương pháp testLà sơ đồ mô hình hóa hành vi của hệ thống, (không mô tả các câu lệnh trong code)Áp dụng được cho hầu hết các phần mềm, có hiệu quảÁp dụng được trong mọi testing stagesMỗi rẽ nhánh trong luồng xử lý là 1 TestCaseControl Flow Testing Strategy - SummaryKiểm tra các mô hình system or sub-systemĐịnh nghĩa đối tượngĐịnh nghĩa các mối quan hệIndetify the weightsIdentify paths through the model to cover objectsIdentify paths through the model to cover linksEach path is a test caseĐưa ra các điều kiện đầu vào và kết quả mong đợi cho mỗi testcaseData FollowÁp dụng cho các hệ thống “data-intensive”, ví dụ:HT sản sinh báo cáo, thống kêHT có tính toán thay đổi số liệuPhương pháp xây dựng testcase:Lập sơ đồ luồng dữ liệu (data flow)Lần theo từng đường dẫn trong sơ đồBắt đầu từ node outputLần ngược lại tới khi gặp node input Phân tích các TestCase theo sơ đồ mô hình luồng dữ liệu Transaction testingÁp dụng cho các hệ thống xử lý giao dịch (như đặt vé máy bay, đặt phòng khách sạn)Sử dụng mô hình xử lý của hệ thống, chú trọng đến điểm bắt đầu, điểm kết thúc của từng xử lý, chú trọng tới hành đợi (queu)Tương tự như data flow, nhưng bao gồm các khái niệm:Birth:nó bắt đầu khi nàoDeath:hoàn thành khi nàoQueues: tuần tự các giao dịch đợi đến lượt Transaction Flow Testing StrategyPhân loại TC theo loại các giao dịch, chú trọng việc xácđịnh điểm khởi đầu, kết thúc và hàng đợi các điểm giaodịch cần xử lýXác định tất cả các loại giao dịch.Xác định nguồn gốc và điểm kết thúc cho mỗi loại giao dịch.Xác định queues (nơi mà các giao dịch chờ đợi để được xử lý)Xác định các thành phần (nhưng không nhất thiết phải phù hợp với các thành phần phần mềm)Xây dựng mô hìnhXác định hướng đi (paths)Domain testÁp dụng cho các xử lý mà có xác định phạm vi giá trị dữ liệuChú trọng test các giá trị biên On, OffTìm ra những nơi mà phần mềm cho giá trị khác nhau -- Phân loại TC theo vùng giá trị của biến, đặc biệt chú trọng các TC quanh biên ranh giới, nơi hệ thống có những xử lý khác nhau so với các giá trị biến khácTesting TechniqueTìm các giá trị biên độc lậpKiểm tra một điểm trên biên và độc đáoChọn “off point” một giá trị gần với giá trị biênLoop TestNói về việc lặp trong cấu trúc, or white box, testingÁp dụng trong Black box test: quan tâm đến vòng lặp trong hành vi của hệ thống chứ không quan tâm đến vòng lặp trong codePhân loại các TC theo số giá trị từng lần rẽ nhánh các vòng lặp Ví dụ: khi hệ thống fari tìm ra tất cả các bản ghi thỏa mãn một tiêu chí tìm kiếm nào đó Giả sử khả năng hệ thống có thể hỗ trợ tối đa Max vòng lặp, chỉ cần chọn thực hiện những testcase sau là đủ: - 0 lần, 1 lần, 2 lần qua vòng lặp - X lần, - Max-1, Max, Max + 1 lầnLoops – Test Cases To UseThực hiện vòng lặp 0 lầnLặp 1 lầnLặp 2 lầnMột số đặc trưng các lần lặpThực hiện việc test lặp với số lượng maxium-1 lầnThực hiện việc test lặp với maxium lầnThực hiện với maxium + 1 lần lặpSyntax TestingRất hữu ích cho Test Các câu lệnh có sẵnCác trường thực thể có cấu trúc khuôn dạng, định dạng trước hoặc theo một quy định nào đó Ví dụ:Ngày thángĐịa chỉ EmailSố điện thoạiMailing addressesSyntax Testing - TechniqueThiết kế các Test case xác thực rõ ràng (dữ liệu valid)bằng cách sử dụng kỹ thuật phân lớp tương đương.Thiết kế các testcase tiêu cực (negative)với lớp dữ liệu InvalidThực hiện các Test CaseState Machine TestingLà một chiến lược test khá hoàn hảoÁp dụng khi:Các ứng dụng được thực hiện qua nhiều các trạng thái khác nhauHệ thống được thiết kế sử dụng phương pháp hướng đối tượngMột vài phần mềm có lược đồ chuyển trạng tháiState CState AState BState DState machine : phương phápCác TC được phân loại từ việc lập các biểu đồchuyển trạng thái của hệ thốngVẽ một sơ đồ chuyển đổi trạng thái cho đối tượng cần testPositive tests: thiết kế test cases cho từng lần chuyển đổi trạng tháiNegative tests: thiết kế các testcases nhằm cố chuyển đổi trạng thái một cách bất hợp lýLoad testingTùy thuộc vào từng loại hệ thống – bắt hệ thống phải chịu tải lớn.Số lượng lớn các giao dịch cần thực hiện.Các file lớn.Số lượng lớn các file.Số lượng lớn các client cùng truy nhập.Các vận hành lặp đi lặp.Thực hiện việc này yêu cầu một số tool tự động. Stress Test Bắt hệ thống hoạt động trong điều kiện bất thường:Dung lượng bộ nhớ bị giới hạn.Mạng lưới hệ thống:Hoạt động với một số lượng nhỏ các node.Kết nối mạng bị ngắt khi đang vận hành.Kết nối CSDL bị ngắt khi đang vận hành.Ưu tiên testDanh sách các ưu tiên test - “where to focus testing”Những vùng quan trọng nhất của phần mềmNhững vùng phần mềm hay được dùng nhấtNhững vùng có đặc trưng riêng, khác biệt hẳn với các vùng khác của phần mềmNhững vùng phần mềm dễ bị ảnh hưởng nhất của các thay đổi vừa có (khi regression test)Những lỗi dễ xảy ra nhấtNhững lỗi (người dùng) dễ nhìn thấy nhấtNhững loại lỗi khó fix nhấtNhững loại lỗi mà tester biết rõ nhấtNhững loại lối mà tester biết lờ mờ nhấtPositive test trước, negative test sau (test các trường hợp hợp lệ trước, các trường hợp không hợp lệ sau)Ưu tiên sắp xếp test theo quality dimensionSố 1: thường là Function testing, và phải bao quát được bussines cycle của hệ thống.Số 2: Usability testing, chú ý test GUI, đảm bảo đúng syntax, theo standards và user friendly.