Bản dịch của quyển Agile testing A practical guide for testers and Agile teams của Addison Wesley (2009); Software quality has many dimensions, each requiring a different testing approach. How do we know all the different types of tests we need to do? Howdo we know when we’re “done” testing? Who does which tests and how? Inthis part, we explain how to use the Agile Testing Quadrants to make sureyour team covers all needed categories of testing.Of course, testing requires tools, and we’ve included examples of tools to use,strategies for using those tools effectively, and guidelines about when to usethem. Tools are easier to use when used with code that’s designed for testability. These concerns and more are discussed in this part of the book.
Part III - The Agile Testing Quadrants Chapter - The Purpose of Testing 6.1 The Agile Testing Quadrants Là Matrix để tester đảm bảo xem xét loại test cần thiết để giao sản phẩm có giá trị Q1, Q2 hướng đến test để hỗ trợ nhóm Q3, Q4 để đánh giá sản phẩm • Quadrant 1: bao gồm Unit tests, Component tests • Quadrant 2: bao gồm Functional tests, Examples, Story tests, Prototypes, Simulations • Quadrant 3: bao gồm Exploratory testing, Scenarios, Usability Testing,UAT, Alpha/Beta • Quadrant 4: bao gồm Performance & Load testing, Security testing, "ility" testing 6.1.1 Tests that Support the Team Bao gồm loại test thuộc Quadrant Quadrant Các loại test thực Q1 tầm quan trọng • Test để định hướng phát triển (TDD) core viecj phát triển Agile • Thường tự động, người thực developer, theo hướng Developer-facing & technology-facing Các loại test thực Q2 tầm quan trọng • Test định hướng phát triển cao so với Q1 • Nó business-facing test • Hầu hết test cần tự động hóa • Mục đích quan trọng loại test Q2 cung cấp thông tin nhanh, phát sớm issue (troubles) • Nó cần chạy thường xuyên để cung cấp FB sớm, trường hợp thay đổi hành vi không mong đợi • Có vài kiểm thử tự động cần verify UI API • Đôi khi, số kiểm thử dc dùng để validate GUI để kết nối thiết developer trước bắt đầu code Y nghĩa việc test để hộ trợ Team • Định hướng phát triển chức • Tự động hóa cung cấp an toàn để ngăn chặn hệ không mong muốn từ tái cấu trúc source code thêm code • Những loại test Q1, Q2 giúp team bàn giao sản phẩm có giá trị theo yêu cầu khách hàng • Nó verify business logic UI theo ví dụ cung cấp khách hàng 6.1.2 Tests that Critique the Product • Bao gồm loại test thuộc Quadrant Quadrant • Các loại test thực Q3 tầm quan trọng • Kiểm thử thăm dò trung tâm Q3 • Tester vừa thực test design test, sử dụng tư phê phán để phân tích kết • Đưa nhiều hội để học hỏi ứng dụng việc kịch hóa • Nó sâu khó ad hoc testing • Ngay từ bắt đầu dự án story, tester bắt đầu suy nghĩ kịch mà họ muốn test • Nó thực theo hướng người dùng cuối sử dụng hệ thống • UAT: • Người dùng khách hàng thực loại test • Giúp cho KH có hội đưa tính hoạt động tốt giúp họ nhìn thấy họ mong muốn thay đổi tương lai • Usability Testing: hiểu biết cách người dùng sử dụng hệ thống lợi để thực kiểm thử • Các loại test thực trọng Q4 tầm quan trọng • Những loại test hướng technology-facing, thiên kỹ thuật business • Nó kiểm tra đặc tính sản phẩm : Performance, Security, Robustness • Khi lên kế họch cho release hay dự án, thảo luận cần loại test thuộc Q3, Q4 cần hoàn thành Ví dụ không nên để load or usability testing vào cuối muộn để sửa chữa vấn đề • Y nghĩa việc test để " đánh giá " sản phẩm • Các lần lặp ngắn phát triển Agile đưa cho ta hội học hỏi trải nghiệm với loại test khác trong quadrants • Việc sử dung Agile testing quadrant giúp đảm bảo loại test cần thiết thực thời điểm 6.2 Knowing When A Story Is Done • Đối với hầu hết sản phẩm, cần thực hạng mục testing để đảm bảo mang lại giá trị đắn • Chúng ta cần đảm bảo loại test thực Mỗi story thực unit test test tích hợp module • Xác định task cần phải thực technology-facing and business-facing tests để kiểm nghiệm sản phẩm • Kết hợp test từ quadrants cho team biết feature đáp ứng tiêu chuẩn chức chất lượng khách hàng 6.2.1.Shared Responsibility • Team cần có chuyên môn để cover toàn Agile testing quadrants Programmer viết technology- facing test , nhiên họ cần giúp đỡ từ member khác • Tester đảm nhận vai trò business- facing test, đồng hành với khách hàng • Team chịu trách nhiệm Q testing thực Team thành công team mà người tham gia xây dựng sản phẩm , chia sẻ khó khăn nội việc không hướng • • 6.3 Managing Technical Debt (Quản lý "Nợ kỹ thuật") • Technical debt xây dựng lên development team đảm nhận việc fix lỗi nhanh chóng skip việc writing , automation test Code ngày trở nên khó maintance • Chi phí cao, tốc độ lại chậm Developer ngại đưa thay đổi, cố gắng refactor để cải thiện code, ngại phá vỡ code • Mỗi quadrant matrix Agile testing đóng vai trò việc đảm bảo cho vấn đề Technical debt mức quản lý • Technology- facing test support coding, design giúp cho code có khả maintain • Build tự động tích hợp áp dụng cho unit test, việc bắt lỗi mức unit test giúp tester tập trung vào business- facing test , hướng dẫn team cải thiện chất lượng dự án • áp dụng nguyên tắc Agile giúp ích cho loại test mức độ khác giảm Technical debt 6.4 Testing in Context • Chúng ta nhận thấy Agile testing matrix giúp đảm bảo có kế hoạch hoàn thành tất loại testing mà cần.Mỗi tổ chức, sản phẩm team có tình riêng, cần thực theo cách riêng Quadrant cách hữu ích để đảm bảo team lưu ý đến tất khía cạnh testing cần làm • Quadrant giúp đưa ngữ cảnh cho Agile testing thực hành, bạn team phải thích nghi với việc • Tester giúp cung cấp thông tin feedback, giúp team điều chỉnh làm việc tốt • Sử dụng kỹ để cam kết với khách hàng qua iteration release • Luôn có ý thức team cần role kiến thức dựa vào tình trạng hện • Agile Testing Quadrant cung cấp checklist để đảm bảo cover hết việc test , đồng thời cần trả lời câu hỏi sau: • Chúng ta có sử dụng unit test component test để tìm thiết kế cho ứng dụng? • Có quy trình tự động build để chạy unit test tự động get phản hồi nhanh chóng? • Việc thực business facing test giúp cung cấp sản phẩm đáp ứng mong đợi khách hàng? • • • • Chúng ta nắm bắt ví dụ xử lý mà hệ thống mong muốn chưa? Chúng ta cần nhiều không? Chúng ta test dựa ví dụ không? Chúng ta có show prototypes UI report tới khách hàng trước bắt đầu thực code? Người dùng liên tưởng phần mềm hoàn thành làm việc nào? Chúng ta có dự tính đủ thời gian cho test exploratory không? Chúng ta xử trí việc test usability nào? Chúng ta dành đủ quan tâm cho khách hàng chưa? Chúng ta xem xét yêu cầu kỹ thuật performance security đủ sớm vòng đời phát triển không? Chúng ta có sử dụng tool đê thực hện công việc testing ility không? Summary • • • • • Test hỗ trợ team dùng để định hướng yêu cầu Việc test để kiểm nghiệm sản phẩm giúp suy nghĩ khía cạnh chất lượng ứng dụng Sử dụng quadrants để biết bạn làm xong nào, đảm bảo team chia sẻ trách nhiệm cover matrix quadrants Việc quản lý nợ kỹ thuật tảng cần thiết cho nhóm phát triển phần mềm Sử dụng quadrants để nghĩ hướng khác Ngữ cảnh luôn hướng dẫn nguồn lực test Chapter Technology-Facing Tests that Support the Team 7.1 Nền tảng Agile Testing Test theo hướng kỹ thuật để hỗ trợ Team tạo tảng cho phát triển Agile Testing Unit test component test Quadrant loại test viết cho story giúp đường cho việc thiet kế phát triển ( Design and development) Nếu thiếu sở test-driven design, tự động hóa unit component test, quy trình tích hợp liên tục để thực loại test khó để bàn giao sản phẩm giá trị thời hạn 7.1.1 Mục đích test Quadrant Unit test component test đảm bảo chất lượng cách giúp cho programer hiểu xác cần phải code ntn cung cấp hướng dẫn cho việc thiết kế Nó giúp cho team tập trung vào story bàn giao đưa cách tiếp cận đơn giản Việc phát triển unit test trở thành công cụ thiet kế cốt lõi sử dụng TDD Bằng việc xây dựng code theo vòng tăng trưởng nhỏ test-code-test, programer có hội để suy nghĩ sâu chức mà khách hàng cần Họ pair với tester để đảm bảo khía cạnh phần code kết nối chúng test Thuật ngữ “ test-driven development” dẫn đến nhầm lẫn nhiều người, không hiểu ý nghĩa thiên thiêt kế nhiều test Tất hoạt động Quadrant nhằm tới việc tạo phần mềm với chất lượng bên trong(internal quality) cao Khi team thực hành DDD giảm đến mức tối thiểu số lượng bug phát sinh sau Hầu hết bug unit-level ngăn chặn việc test trước code Suy nghĩ sâu thiết kế việc viết unit test có nghĩa hệ thống đáp ứng yêu cầu khách hàng nhiều Bởi vậy, viêc test programmer Quadrant quan trọng Những team agile không áp dụng học không chắn việc thu nhiều lợi ích từ giá trị nguyên tắc Agile 7.1.2 Hỗ trợ sở hạ tầng Kiểm soát source code, quản lý cấu hình, tích hợp liên tục yếu tố cần thiết để thu giá trị từ việc thực test programmer Tích hợp liên tục (CI) cung cấp cho cách để chạy test có source code đưa vào Việc tích hợp liên tục giúp tiết kiệm thời gian tạo động lực cho programmer thực test trước đưa source code lên Dự án thiếu thực hành cốt lõi Agile giống với dự án "miniwaterfall", vòng đời phát triển sản phẩm ngắn code đến với tester chậm Thuật ngữ "waterfall" nghĩa không tốt, code mà thiếu việc thực hành (practices) tool thích hợp process bàn giao code có chất lượng cao 7.2 Tại viết thực loại test 7.2.1 Nó giúp tiến xa làm nhiều Tốc độ mục tiêu cuối Agile, cố gắng làm nhanh để kịp deadline mà không nghĩ đến chất lượng dồn vào "góc", tạo nhiều lỗi cuối dẫn đến không kịp deadline.Tốc độ hiệu mang tính chất lâu dài việc tạo code chất lượng bên cao Việc liên tục build chạy unit test giúp ta nhận vài phút có vấn đề phát sinh bug tìm fix Một mạng lưới an toàn việc tự động hóa kiểm thử đơn vị tích hợp giúp cho programmer refactor code thường xuyên Khi dự án có phần unit test bị lãng, tester lãng phí thời gian để tìm bug level thấp, thời gian tập trung tìm bug level cao nghiệp vụ Code design tốt thường tốt test Khi tester có thời gian để tập trung vào exploratory test Và team master TDD tập trung vào việc chuyển từ ngăn chặn bug tới việc hình dung cách tốt để gợi mở nắm bắt REQ trước code 7.2.2 Làm cho công việc tester dễ dàng Việc programmer phải thực nhiều hoạt động liên quan đến kiểm thử thực hành cốt lõi agile họ dễ dàng hoàn thành Họ làm việc môi trường riêng biệt thêm code không làm ảnh hưởng đến phần người khác Họ không đưa code lên trước pass phần test hồi qui môi trường họ Team suy nghĩ môi trường test liệu test sử dụng Unit test thường sử dụng liệu giả để tăng tốc độ, nhiên programmer phải test lại liệu thật Tester giúp họ tìm liệu test tốt Việc viết test viết code dựa case test hình dùng trước giúp programmer tiếp tục suy nghĩ để tạo code “có thể test được” Toàn team suy nghĩ tìm cách để cải tiến thiết kế giúp cho việc test dễ dàng 7.2.3 Designing with testing in mind Một ưu điểm việc định hướng phát triển thông qua test dòng code viết tập trung vào việc làm cho test case pass Toàn đội phải suy nghĩ từ đầu cách thực test tự động hoá test cho toàn story code Code để “có thể test được” nghe khái niệm đơn giản, thực tế công việc dễ Một cách tiếp cận phổ biến để thiết kế kiến trúc “có thể test được” việc chia thành tầng khác để thực chức khác ứng dụng Bạn team bạn tìm cách để thiết kế cho “khả test được”, điều quan trọng toàn team commit việc test chất lượng sản phẩm Có thể team bạn thời gian để tìm cách làm thích hợp đừng ngần ngại xem lại cấu trúc test tự động hoạt động không đủ mang lại giá trị cho bạn đầu tư 7.2.4 Timely feedback Giá trị lớn unit test tốc độ Feedback Theo quan điểm việc tích hợp liên tục xây dựng process chạy unit test vòng 10 phút Những build test mức unit test chức API hay GUI lâu Bạn có process để run test nhanh, process để run mức chậm Và nên có "build" ngày để chạy toàn mức test chậm Nếu team bạn có qui trình build test thời gian bạn team phân tích nguyên nhân cải thiện tốc độ Việc liên tục xây dựng thử nghiệm quy trình cung cấp thông tin phản hồi liên tục , giống giấc mơ tester Sử dụng regression giúp lỗi phát sớm, dễ để sửa Đây lý tuyệt vời thực technology-facing test 7.3 Technology- Facing Test dừng đâu? Chúng ta thường thấy người ta lo ngại customer - facing test technology-facing bị chồng chéo lên nhau, team tốn nhiều thời gian Business- facing test bao gồm phần giống unit test integration test, chúng có mục đích khác Khi thực Unit test thành công với giá trị kiểm thử tham số không hợp lệ, kết hợp nghiệp vụ, programmer cảm thấy yên tâm chất lượng code Mỗi unit test độc lập thực test theo chiều hướng thời điểm Điều có nghĩa unit fail, programmer nhanh chóng xác định vấn đề giải vấn đề cách nhanh chóng Business-facing tests bao gồm chiều hướng chúng giải từ quan điểm nghiệp vụ Business - facing test bao phủ kịch phức tạp hơn, xác nhận lại end user có trải nghiệm tốt sản phẩm Nên đẩy việc test vào mức thấp lúc bạn xác định test case thực tự động mức unit, gần đầu tư tốt 7.4 What if the team doesn’t these tests?(Phải làm team không thực công việc test) Nhiều tổ chức định thử phát triển theo Agile, kiên định với ý định mà không cần hiểu làm để tạo nên thành công.Khi vai trò tester, mà làm để giúp development team thực TDD, tích hợp liên tục thực hành khác , chìa khóa dẫn tới thành công 7.4.1 What Can Tester Do? (Tester làm việc gì?) Nếu bạn tester Agile team lại không thực automation giai đoạn unit test hệ thống không build liên tục (hoặc phải build hàng ngày) bạn nhanh chóng thất vọng đừng bỏ cuộc, động não để tìm cách để làm thay đổi theo hướng tích cực Hãy đưa ý tưởng cho tất thành viên nhóm Cần tránh để tester viết unit test, điều chủ yếu TDD người code nên viết test trước viết code Programmer có phản hồi từ việc thực unit test tự động Khi tester Agile team , có nhiều việc bạn làm để đóng vai trò tác nhân thay đổi nhiên khả ảnh hưởng bạn bị giới hạn Trong số trường hợp, hỗ trợ người quản lý giỏi chìa khóa để định hướng team tham gia vào hoạt động Quadrant 7.4.2 What Can Managers Do? (Manager làm việc gì?) Nếu bạn quản lý development team, bạn làm nhiều việc để khuyến khích team thực TDD unit test tự động Làm việc với PO để đặt mục tiêu chất lượng truyền đạt lại tiêu chuẩn chất lượng cho team Khuyến khích programmers dành thời gian làm công việc cách tốt thay lo lắng deadline Nếu ngày delivery tình trạng cảnh báo (vd : gần sát ngày), nên thực giảm scope giảm chất lượng Cần phải giải thích với người quản lý nghiệp vụ làm để uu tiên chất lượng , đảm bảo họ nhận business có giá trị Tạo thời gian cho team nghiên cứu, cung cấp chuyên gia đào tạo thực hành Mang tới thuê cho team người có nhiều kinh nghiệm phát triển Agile để họ truyền đạt kỹ Cần có quỹ thời gian cho việc tái cấu trúc, thảo luận cách tiếp cận tốt việc viết unit test, integration test , đánh giá, cài đặt nâng cấp tool Test manager làm việc development managers để khuyến khích việc thực hành, tăng cường khả kiểm thử Test manager đảm bảo tester có thời gian nghiên cứu cách sử dụng test tool tự động, framework mà team định thực 7.4.3 It’s a Team Problem? (đó vấn đề team) Cách tốt team tham gia vào việc giải vấn đề Cần thực retrospectives sau iteration Trong buổi retrospective, cần đưa issue, team giải Cần khuyến khích team thử dùng cách tiếp cận cho vài iterations xem hoạt động Technology-facing tests hỗ trợ quy trình phát triển team tảng quan trọng cho thử nghiệm Nếu nhóm không thực đầy đủ kiểm thử quadrant này, loại test khác trở nên khó nhiều, code thiếu chất lượng bên trong, thứ lâu Technology-facing tests hoàn thành mà không cần tool sở hạ tầng 7.5 Toolkit Không có tool kỳ diệu đảm bảo chắn thành công Tuy nhiên tool giúp đỡ người làm tốt công việc họ Xây dựng sở hạ tầng phù hợp để hỗ trợ technology- facing test quan trọng 7.5.1 Source Code Control (Kiểm soát source code) Source code control biết với tên khác version control revision control, đội phát triển phần mềm thành công Nếu quản lý source code, bạn không chắn thứ bạn test Quản lý source code giúp cho thấy thay đổi module so với module khác Nếu version, chắn phần code release lên production Nên sử dụng quản lý source code cho script test tự động điều quan trọng buộc test tự động gắn với version code tương ứng , giúp ích cho việc test lại version Hệ thống mã nguồn mở cho quản lý source code CVS Subversion (SVN) , IDE dễ dàng để thực hiện, tích hợp Vendor tools IBM Ratio-nal ClearCase and Perforce 7.5.2 IDEs (integrated development environment) IDE hữu ích cho programmers tester Agile team IDE tương tác với hệ thống quản lý source code để ngăn chặn vấn đề với versioning thay đổi khác IDE báo lỗi viết code sai Quan trọng IDEs hỗ trợ cho việc tái cấu trúc Open source IDEs Eclipse, NetBeans sử dụng rộng rãi Agile team Tester sử dụng tool FishEye cho phép truy cập vào đoạn code, IDEs hỗ trợ cho hầu hết ngôn ngữ lập trình 7.5.3 Build Tools Team cần số cách để xây dựng phần mềm Việc thực với tool , nhiên tool có hạn chế nó, vd platform Agile team sử dụng tool Ant, Nant, Maven để xây dựng dự án Các tool không quản lý việc xây dựng mà cung cấp cách dễ dàng cho việc báo cáo, tài liệu hóa kết tích hợp dễ dàng với việc build tự động test tool Chúng tích hợp với IDEs 7.5.4 Build Automation Tools CI thực hành cốt lõi cho Agile team Bạn không xây dựng dự án mà chạy kiểm tra tự động build, đảm bảo bị phá vỡ Việc tự động hóa hoàn toàn build lại chạy nhiều ngày chìa khóa thành công cho Agile team Tool build tự động cung cấp tính email thông báo kết build, tương tác với build tool quản lý source code Thông thường sử dụng tool open source CruiseControl, CruiseControl.net, CruiseControl.rb, and Hudson Nếu trình xây dựng tự đông, bạn có khoảng thời gian khó triển khai cho testing release Quản lý việc xây dựng tool tool build tự động cần thiết cho dự án Agile thành công Hãy đảm bảo bạn có quy trình build sớm, chí trước coding 7.5.5 Unit Test Tools Tools sử dụng cho Unit test phải riêng biệt theo ngôn ngữ mà bạn code Tool “xUnit” thường sử dụng cho Agile team, tool khác dùng cho ngôn ngữ khác VD: JUnit for Java, NUnit for NET, Test::Unit for Perl and Ruby, and PyUnit for Python Phát triển định hướng hành vi test- driven development, sử dụng tool RSpec easyb vài tool hiệu : TestNG, Abbot SWTBot Các công cụ EasyMock Ruby / giúp đỡ Mock với việc thực mục tiêu mock test stubs Các công cụ lập trình sử dụng technology-facing tests cho business-facing tests Mặc dù chúng phù hợp cho mục đích dự án cần tùy theo yêu cầu team khách hàng Summary Trong chương này, giải thích mục đích technology-facing tests, thảo luận thứ mà team cần làm để đạt hiệu • Test Technology-facing hỗ trợ lập trình, giúp cho nhóm cung cấp code có chất lượng cao Chúng tạo thành tảng cho tất loại test khác • Lợi ích từ quadrant’s test nhằm làm cho nhanh hơn, nhiều tốc độ số lượng chẳng mục tiêu cuối • Programmers thực viết technology- facing test, hỗ trợ nhóm mang lại giá trị cho tester cách nâng cao chất lượng bên khả test hệ thống • Team thất bại việc áp dụng học cốt lõi Agile giống “vật lộn” • Legacy system thường trình bày trở ngại lớn để thử nghiệm điều khiển phát triển, vấn đề khắc phục với gia tăng phương pháp tiếp cận • Nếu nhóm bạn không thực công việc test, bạn giúp họ bắt đầu cách khuyến khích thành viên khác tham gia nhận hỗ trợ từ quản lý • Có thể có vài chồng chéo technology-facing tests businessfacing tests, nhiên phải đối mặt với lựa chọn, cần đẩy test vào mức thấp để tối đa hóa ROI • Team nên thiết lập tương tác liên tục, build qui trình test để cung cấp phản hồi cách nhanh chóng • Agile team đòi hỏi tool phục vụ cho nhiệm vụ quản lý source code, test tự động, IDEs, quản lý build để tạo điều kiện cho technology- facing test hỗ trợ team bạn cần cho dự án, nhiều nhóm nhận thấy kiểm thử viên kỹ thuật tốt hay công cụ đảm nhận nhiều việc Nếu nhóm học chuyên ngành kiến thức điều cần thiết ; không, cần đưa tới chuyên gia mà bạn cần Bất kể có hay không nhóm bạn mang lại nguồn lực bổ sung cho loại kiểm thử nhóm bạn chịu trách nhiệm việc bảo đảm thử nghiệm tối thiểu phải thực Các thông tin kiểm thử cung cấp dẫn đến story nhiệm vụ lĩnh vực thay đổi kiến trúc cho khả mở rộng tốt thực giải pháp bảo mật toàn hệ thống Hãy chắn để hoàn tất vòng lặp thông tin phản hồi từ việc kiểm thử để định hướng thay đổi , cải thiện khía cạnh phi chức sản phẩm Chỉ thứ tư bốn testing quadrant Agile nghĩa thử nghiệm mức cuối Nhóm bạn cần phải suy nghĩ việc thực kiểm thử hiệu suất, bảo mật, "ility" để đảm bảo sản phẩm bạn cung cấp giá trị doanh nghiệp phù hợp 11.3 When Do You Do It? Như với functional testing, technology-facing tests hỗ trợ nhóm hoàn thành sớm việc sửa chữa vấn đề tìm thấy rẻ Tuy nhiên, nhiều cross-functional tests đắt khó để thực khối nhỏ Story nói hiệu yêu cầu kiểm thử viết ra, thực với story để viết mã báo cáo lần lặp sau Một số performance tests phải chờ phần lớn ứng dụng build Nếu hiệu độ tin cậy có ưu tiên hàng đầu, bạn cần tìm cách kiểm thử sớm dự án Các story ưu tiên mà ‘steel thread’ thin slice nên hoàn thành sớm Bạn nên tạo thử nghiệm hiệu mà chạy tiếp tục chạy bạn thêm ngày nhiều chức vào flow làm việc điều cho phép bạn nắm bắt vấn đề hiệu sớm thiết kế lại hệ thống kiến trúc cho cải tiến nhiều ứng dụng, chức mà không cần hiệu suất Thời điểm để nghĩ kiểm thử phi chức bạn suốt trình release lên kế hoạch Kế hoạch bắt đầu sớm, giải bước nhỏ cần thiết Với lần lặp, xem nhóm bạn cần thực nhiệm vụ để xác định thiết kế mã có tin cậy (reliable), mở rộng (scalable), hữu dụng (usable) bảo mật (secure) không 11.4 “Ility” Testing 11.4.1 Security Security có ưu tiên hàng đầu tổ chức ngày Mỗi tổ chức cần đảm bảo tính bảo mật toàn vẹn phần mềm họ Hiểu nhu cầu rủi ro bạn trước bạn đầu tư thời gian lực vào kiểm thử Các kiểm thử viên có kĩ security testing thực kiểm thử dựa rủi ro (security risk-base testing) Nó điều hướng việc phân tích rủi ro kiến trúc, mô hình công, hay trường hợp lừa gạt hay lạm dụng Có loạt công cụ tự động giúp xác minh bảo mật • Các công cụ phân tích tĩnh, kiểm tra mã nguồn mà không cần thực thi ứng dụng, phát lỗ hổng bảo mật tiềm mã nguồn không xuất nhiều năm • Các công cụ phân tích động, chạy thời gian thực, kiểm thử lỗ hổng SQL injection cross-site scripting • Manual exploratory testing kiểm thử viên có hiểu biết bảo mật (Knowledgeable security tester) phát vấn đề mà kiểm thử tự động bỏ xót Security testing đòi hỏi phải có đào tạo công cụ để thực tốt công việc Với hầu hết tổ chức, kiểm thử yêu cầu tuyệt đối, Một xâm nhập bảo mật đủ để công ty kinh doanh 11.4.2 Maintainability Khả bảo trì dễ dàng để kiểm thử Các nhóm Agile sử dụng pair programming, built-in liên tục mã review Có cách khác để chắn mã nguồn kiểm thử bảo trì Khuyến khích nhóm phát triển đưa tiêu chuẩn, hướng dẫn mà họ thực mã ứng dụng, khung kiểm thử, tự kiểm thử Các nhóm đưa tiêu chuẩn riêng họ, thiết lập chúng từ nhóm khác Khả bảo trì yếu tố quan trọng cho kiểm thử tự động Vì vậy, tìm công cụ cung cấp hướng dễ dàng để tái cấu trúc, tìm kiếm, thay thế, tiện ích khác làm cho dễ dàng để sửa đổi kịch Bảo trì sở liệu quan trọng Thiết kế sở liệu cần mềm dẻo khả dụng (usable) Sẽ xảy bottleneck thiết kế sở liệu nghèo nàn bị lộn xộn liệu không hợp lệ Khả bảo trì tất khía cạnh ứng dụng, kiểm thử môi trường thực thi cần đánh giá tái cấu trúc trực tiếp kiểm thử 11.4.3 Interoperability (Khả tương tác) Interoperability khả hệ thống tổ chức khác làm việc chia sẻ thông tin Interoperability testing nhìn vào chức đầu cuối (end-toend) hai hay nhiều hệ thống giao tiếp Những kiểm thử thực ngữ cảnh người sử dụng, ý hành vi chức Trong phát triển Agile, interoperability testing thực sớm vòng đời phát triển Nếu hệ thống bạn phải làm việc với hệ thống bên ngoài, bạn đại diện cho tất chúng môi trường kiểm thử Đây tình mà kiểm thử sau phát triển hoàn tất tránh khỏi Bạn phải thời gian môi trường kiểm thử chia sẻ số đội 11.4.4 Compatibility (Khả tương thích) Dự án mà bạn làm việc cần tối thiểu comparibility testing Nếu bạn ứng dụng web khách hàng bạn toàn giới, bạn cần phải suy nghĩ tất trình duyệt hệ điều hành Nếu bạn phân phối ứng dụng doanh nghiệp tùy biến, bạn giảm compatibility testing, bạn theo phiên hỗ trợ Khi bạn bắt đầu chủ đề hay dự án mới, suy nghĩ nguồn lực xác minh tính tương thích Nếu bạn bắt đầu nhánh sản phẩm mới, bạn phải xây dựng phòng kiểm thử cho Hãy chắn nhóm bạn có thông tin phần cứng, hệ điều hành, trình duyệt, phiên người dùng cuối Nếu tỷ lệ sử dụng phiên trình duyệt tăng đủ lớn, thời điểm để bắt đầu phiên compatibility testing bạn 11.4.5 Reliability (Độ tin cậy) Reliability phần mềm khả hệ thống để thực bảo trì chức trường hợp thông thường bất thường Hệ thống phải thực trì chức với tính quán lặp Phân tích độ tin cậy trả lời cho câu hỏi “Nó kéo dài trước bị phá vỡ?” Một số thống kê sử dụng để đo độ tin cậy là: • Mean time to failure: Trung bình hay thời gian hoạt động khởi tạo lần xuất lỗi (failure) hay cố (malfunction) Nói cách khác, hệ thống chạy trước bị lỗi lần đầu tiên? • Mean time between failures: Một thước đo thống kê độ tin cậy, điều tính toán để dự đoán thời gian trung bình lỗi (failure) Càng lâu tốt Để thực reliability test, Đơn giản sử dụng kiểm thử tương tự chạy chúng lặp lặp lại Lý tưởng nhất, bạn sử dụng số liệu thống kê thu thập để thấy cách sử dụng hàng ngày, tạo kịch phản ánh việc sử dụng, chạy build ổn định lâu dài Bạn thể đưa liệu ngẫu nhiên vào kiểm thử để mô sản phẩm đảm bảo ứng dụng không sụp đổ đầu vào không hợp lệ Tất nhiên, bạn muốn phản ánh cách sử dụng cao để đảm bảo xử lý tốt vào lúc cao điểm Bạn tạo stories lần lặp để phát triển kịch thêm chức vào ứng dụng Hỏi nhóm khách hàng tiêu chí tin cậy họ mục tiêu đo lường Điều hướng phát triển với lập trình viên kiểm thử khách hàng tăng cường độ tin cậy ứng dụng, điều thường dẫn đến thiết kế tốt defects 11.4.6 Installability Một tảng Agile team thành công tích hợp liên tục (continuous integration) Nó có nghĩa build sẵn sàng để kiểm thử lúc ngày Nhiều nhóm chọn triển khai hay nhiều builds thành công vào môi trường kiểm thử ngày Tự động hóa triển khai tạo khả lặp làm cho việc triển khai kiện Như với chức khác, rủi ro liên quan đến cài đặt cần đánh giá xác định số lượng kiểm thử phù hợp 11.4.7 “ility” Summary Có “ilities” khác để kiểm thử, phụ thuộc vào lĩnh vực sản phẩm Khả cấu hình (Configurability), khả tra (Auditability), khả di động (Portability), tính vững mạnh (Robustness), khả mở rộng (extensibility) chất lượng mà nhóm bạn cần phải đánh giá với technology-facing tests Sử dụng cách tiếp cận để kiểm thử “ility” Bắt đầu gợi ý yêu cầu khách hàng ví dụ cho mục tiêu họ với lĩnh vực chất lượng cụ thể Viết business-facing tests để chắn mã thiết kế phù hợp với mục tiêu Trong lần lặp đầu tiên, nhóm cần nghiên cứu đưa chiến lược kiểm thử để đánh giá mức độ chất lượng sản phẩm Bước tạo môi trường kiểm thử phù hợp, để nghiên cứu công cụ, hay bắt đầu số kiểm thử thủ công 11.5 Performance, Load, Stress, and Scalability Testing 11.5.1 Scalability (Khả mở rộng) Scalability testing xác nhận ứng dụng đáng tin cậy nhiều người dùng thêm vào Nghe đơn giản, Agile team tự giải Họ phải lấy câu trả lời để giải scalability issues 11.5.2 Performance and Load Testing Performance testing thường thực để giúp xác định bottleneck hệ thống thiết lập baseline để kiểm thử tương lai Nó thực để đảm bảo phù hợp với mục tiêu yêu cầu hiệu năng, giúp stakeholders đưa định liên quan đến chất lượng chung ứng dụng kiểm thử Loading testing đánh giá hành vi hệ thống ngày nhiều người truy cập vào hệ thống lúc Stress testing đánh giá ổn định/vững mạnh ứng dụng sau tải trọng cao dự kiến 11.5.3 Performance and Load Testing Tools Sau bạn định nghĩa mục tiêu hiệu bạn, bạn sử dụng hàng loạt công cụ để đặt tải hệ thống kiểm tra bottleneck Điều thực mức đơn vị, JUnitPerf, httperf, hay khai thác home-grown Apache JMeter, The Grinder, Pounder, ftptt, OpenWebLoad ví dụ công cụ kiểm thử hiệu tải có sẵn thời điểm viết Một số đó, JMeter, sử dụng nhiều máy chủ SOAP, LDAP, POP3 mail Nhiều công cụ thương mại có sẵn NeoLoad, WebLoad, eValid LoadTest, LoadRunner, SOATest Bạn sử dụng công cụ mà nhóm quen thuộc 11.5.4 Baseline Performance tuning (Điều chỉnh hiệu năng) dự án lớn, cần cung cấp baseline để so sách với phiên phần mềm hiệu Thậm chí hiệu mối quan tâm lớn bạn thời điểm đó, đừng bỏ qua Nếu tiêu chí hiệu định nghĩa cho chức xác định, đề nghị thực performance testing phần lần lặp để đảm bảo vấn đề tìm thấy trước muộn để sửa chữa chúng Benchmarking (điểm chuẩn) thực lúc release Nếu chức thêm vào có ảnh hưởng đến hiệu năng, truy vấn phức tạp, chạy lại kiểm thử để chắn tác dụng phụ Bằng cách này, bạn có thời gian để tối ưu truy vấn mã nguồn sớm chu kỳ nhóm phát triển quen với tính 11.5.5 Test Environment Các lần chạy cuối performance tests giúp khách hàng đưa định có chấp nhận sản phẩm không Với kết xác, kiểm thử cần chạy thiết bị tương tự sản phẩm Nhóm thường sử dụng máy nhỏ đưa kết để định hiệu đủ cho nhu cầu nghiệp vụ Điều cần ghi lại rõ ràng báo cáo kết kiểm thử Bất kỳ performance, load, hay stress test ý nghĩa chạy môi trường mô môi trường sản phẩm 11.5.6 Memory Management Bộ nhớ thường mô tả số lượng (thường tối thiểu tối đa) nhớ sử dụng cho RAM, ROM, ổ đĩa cứng, Bạn cần biết cách sử dụng nhớ xem có bị rò rỉ không, chúng gây thất bại nặng nề ứng dụng đưa vào sản xuất thời gian cao điểm Một số ngôn ngữ lập trình dễ mắc phải vấn đề nhớ, hiểu biết điểm mạnh điểm yếu mã nguồn hỗ trợ bạn biết xem Kiểm thử vấn đề nhớ thực phần performance, load, stress testing Garbage collection công cụ sử dụng để giải phóng nhớ trở lại chương trình Tuy nhiên, che khuất vấn đề nhớ nghiêm trọng Khi bạn làm việc với lập trình viên story, hỏi họ mong muốn nhớ Bạn kiểm thử bạn biết khu vực rủi ro Thực performance load tests để xác định vấn đề nhớ Summary Trong chương này, khám phá góc thứ tư Agile testing, “Technologyfacing tests that critique the product” • • • • • Nhóm phát triển đánh giá liệu có, hay mua được, chuyên gia để thực kiểm thử này, hay cần phải lên kế hoạch thuê tài nguyên bên Một tiếp cận tăng trưởng kiểm thử này, hoàn thành công việc lần lặp, đảm bảo thời gian giải vấn đề phát sinh trách vấn đề sản phẩm Nhóm xem xét loạt kiểu kiểm thử “ility”, bao gồm security, maintainability, interoperability, comparibility, realiability, installability testing nên thực kiểm thử thời điểm thích hợp Performance, scalability, stress, load testing nên thực từ đầu dự án Nghiên cứu vấn đề quản lý nhớ ảnh hưởng đến sản phẩm, kế hoạch kiểm thử để xác định ứng dụng không bị bó buộc vấn đề nhớ Chapter 12 Summary of Testing Quadrants Trong chương 6, giới thiệu góc phần tư kiểm thử, chương nói làm để sử dụng khái niệm dự án Agile Trong chương này, mang chúng lại với với ví dụ Agile team sử dụng kiểm thử từ toàn quadrants 12.1 Review of the Testing Quadrants Chúng ta vừa trải qua chương nói quadrants (hình dưới) ví dụ công cụ bạn sử dụng với loại kiểm thử khác Bí biết dự án bạn cần kiểm thử thực chúng Trong chương này, hướng dẫn bạn thông qua ví dụ thực tế dự án Agile mà sử dụng khác kiểm thử từ toàn Agile testing quadrants 12.2 A System Test Example Câu chuyện sau thành công tổ chức việc kiểm thử toàn hệ thống cách sử dụng hàng loạt công cụ home-grown mã nguồn mở Janet làm việc với nhóm anh ấy, Paul Rogers kiến trúc kiểm thử Đây câu chuyện Paul 12.2.1 The Application Hệ thống giải vấn đề giám sát giếng dầu sản xuất khí đốt từ xa Giải pháp kết hợp thiết bị theo dõi từ xa truyền liệu nhận điều chỉnh từ trạm giám sát trung tâm sử dụng giao thức độc quyền kênh truyền hình vệ tinh Hình cho thấy kiến trúc hệ thống giám sát từ xa (Remote Data Monitoring system) Các thiết bị đo lường giếng dầu, Remote Terminal Units (RTU), sử dụng loạt giao thức để liên lạc với thiết bị đo lường Dữ liệu từ RTU truyền qua vệ tinh đến máy chủ đặt văn phòng khách hàng Sau đó, tạo sẵn cho người dùng qua giao diện web Một hệ thống thông báo, qua email, fax, hay điện thoại, sẵn sàng việc đọc nằm giới hạn hoạt động thông thường Một Java Message Service (JMS) feed web services sẵn sàng giúp tích hợp với ứng dụng khác khách hàng Ứng dụng phần mềm hệ thống di sản (legacy system) lớn, có vài kiểm thử đơn vị Nhóm xây dựng lại ứng dụng với công nghệ 12.2.2 The Team and the Process Nhóm gồm bốn software programmers, hai firmware programmers, ba đến bốn testers, product engineer, off-site manager Khách hàng thực nước khác Nhóm phát triển sử dụng thực hành XP, bao gồm pair programming, TDD Nhóm khách hàng sử dụng hệ thống theo dõi lỗi (defect-tracking system) cho backlog, hầu hết khả hiển thị stories thông qua index cards (thẻ mục) Story cards sử dụng iteration planning meetings (cuộc họp lên kế hoạch cho lần lặp), task board (bảng công việc) theo dõi quy trình Scrum sử dụng chế báo cáo đến tổ chức khách hàng Nhóm có tuần lặp phát hành sản phẩm bốn tháng lần Thay đổi phụ thuộc vào chức phát triển Retrospectives tổ chức phần phiên lập kế hoạch lặp, hành động thực ba mục ưu tiên thảo luận hàng đầu Tích hợp liên tục qua CruiseControl cung cấp build liên tục cho kiểm thử viên thuyết minh/giảng dạy thực vào cuối lần lặp Mỗi kiểm thử viên có môi trường cục để kiểm thử ứng dụng web, có ba môi trường kiểm thử có sẵn với hệ thống Đầu tiên dành cho kiểm thử stories, cập nhật cần thiết với build Thứ hai dành cho kiểm thử vấn đề thông báo khách hàng, phát hành phiên tới khách hàng Môi trường thứ ba môi trường độc lập hoàn toàn để kiểm thử toàn triển khai, liên kết truyền thông, phần sụn hệ thống (firmware) phần cứng Chúng ta chạy tải kiểm thử độ tin cậy môi trường 12.3 Tests Driving Development Các kiểm thử điều hướng phát triển bao gồm unit test acceptance tests 12.3.1 Unit Tests Unit tests technology-facing tests, hỗ trợ lập trình Những kiểm thử phát triển phần phát triển điều hướng kiểm thử (test-driven development), không giúp lập trình viên có story mà giúp thiết kế hệ thống Các lập trình viên dự án Remote Data Monitoring thực Test Driven Development (TDD) pair programming Tất chức phát triển kiểm thử cách dùng pair programming Toàn stories giao cho kiểm thử viên, họ hỗ trợ unit tests, vài bugs tìm thấy sau mã nguồn hoàn tất Các bugs tìm thấy thường liên quan đến tích hợp Tuy nhiên, nhóm bắt đầu lần đầu, hệ thống di sản (legacy system) có vài kiểm thử đơn vị (unit test) để hỗ trợ tái cấu trúc Khi quy trình thay đổi hoàn thành, lập trình viên bắt đầu sửa chữa vấn đề Mỗi lần họ nắm phần mã nguồn hệ thống di sản, thêm kiểm thử đơn vị tái cấu trúc mã cần thiết Dần dần, hệ thống di sản trở nên ổn định tái cấu trúc lớn cần thiết Chúng ta có kinh nghiệm sức mạnh kiểm thử đơn vị! 12.3.2 Acceptance Tests Product engineer (Đại diện khách hàng – customer proxy) có quyền tạo acceptance tests Những kiểm thử có định dạng khác phụ thuộc vào story thực Mặc dù anh cố gắng từ lần đầu tiên, product engineer tốt việc đưa kiểm thử đến lập trình viên trước họ bắt đầu viết mã Nhóm tạo mẫu kiểm thử, phát triển theo thời gian, phù hợp với nhu cầu lập trình viên kiểm thử viên Các kiểm thử không viết thức văn bản, chúng bao gồm liệu, yêu cầu thiết lập không rõ ràng lập tức, thay đổi khác quan trọng story, số ví dụ Nhóm tìm thấy ví dụ giúp làm rõ kỳ vọng nhiều stories Nhóm kiểm thử tự động hóa acceptance tests có thể, thường lúc stories phát triển Tất nhiên, product engineer sẵn sàng để trả lời câu hỏi trình phát triển Acceptance test phục vụ ba mục đích Chúng business-facing test hỗ trợ phát triển, chúng trao cho nhóm trước bắt đầu viết mã Thứ hai, chúng sử dụng nhóm kiểm thử sở tự động hóa để đưa vào hồi quy cung cấp ý tưởng kiểm thử thăm dò tương lai Mục đích thứ ba xác nhận việc hoàn thành đủ nhu cầu khách hàng Product engineer thực việc xác minh giải pháp 12.4 Automation Tự động hóa liên quan đến cấu trúc kiểm thử chức năng, dịch vụ web kiểm thử nhúng 12.4.1 The Automated Functional Test Structure Ruby sử dụng với Watir công cụ lựa chọn cho khung tự động chức Nó xác định linh hoạt hội tùy biến yêu cầu cho hệ thống sau kiểm thử Mã kiểm thử tự động bao gồm ba lớp riêng biệt, hình • Lớp thấp Layer 1, bao gồm Watir lớp khác, loggers để viết log files • Lớp thứ hai Layer 2, page access layer, nơi lớp chứa mã truy cập trang web cá nhân Ví dụ, ứng dụng sau web (Application Under Test – AUT) có trang đăng nhập, trang tạo người dùng, trang chỉnh sửa người dùng Các lớp viết Ruby chứa mã thực chức định AUT, lớp đăng nhập vào ứng dụng, lớp để chỉnh sửa người dùng, lớp gán quyền truy cập đến người dùng Những lớp không chứa liệu Ví dụ, lớp đăng nhập username đăng nhập • Lớp thứ ba Layer 3, test layer, chứa liệu cần thiết để thực kiểm thử Nó gọi lớp Layer 2, sau chuyển lệnh gọi Layer Ví dụ, kiểm thử thực tế gọi LogIn pass Janet username Passw0rd password Có nghĩa bạn cung cấp nhiều liệu khác cách dễ dàng LogIn (‘Janet’, ‘Passw0rd’) Layer biết làm để xử lý thông báo lỗi mà ứng dụng tạo Ví dụ, tên không hợp lệ nhập vào trang đăng nhập, lớp đăng nhập phát thông báo lỗi sau đưa vấn đề trở lại kiểm thử Layer Điều có nghĩa lớp thuộc Layer sử dụng cho hai kiểm thử đường hạnh phúc kiểm thử tiêu cực Trong trường hợp tiêu cực, Layer mong đợi Layer trả failure, sau kiểm tra để xem kiểm thử thất bại lý xác cách truy cập thông báo lỗi mà Layer lấy từ trình duyệt Các kiểm thử chức sử dụng Ruby với Watir để kiểm soát DOM trình duyệt truy cập hầu hết đối tượng trang Bộ kiểm thử tự động chạy build vào ban đêm, để cung cấp cho nhóm thông tin phản hồi thống hành vi ứng dụng cấp cao Đây phao cứu sinh (lifesaver) nhóm tiếp tục xây dựng unit test Kiến trúc cung cấp business-facing tests hiệu để hỗ trợ cho nhóm 12.4.2 Web Services Web services sử dụng clients để giao tiếp với số ứng dụng khác họ Nhóm phát triển sử dụng Ruby để viết client để kiểm thử service họ phát triển Với kiểm thử này, khung kiểm thử đơn vụ Ruby, Test::Unit, sử dụng Các kiểm thử Web services mở rộng nhóm kiểm thử với 1,000 trường hợp kiểm thử khác nhau, vài phút để chạy Chúng cung cấp cho nhóm lượng bao phủ đáng kinh nhạc khoảng thời gian ngắn Nhóm chứng minh việc test client cho khách hàng, người định sử dụng hay không Tuy nhiên, sau khách hàng định không làm việc họ, họ bắt đầu viết kiểm thử riêng, có nhiều cách thực adhoc cách sử dụng Ruby Họ sử dụng IRB, giao diện tương tác cung cấp Ruby, cung cấp giá trị phương pháp thăm dò Nó đưa cho khách hàng môi trường tương tác để khám phá làm việc không làm việc Nó giúp họ làm quen với Ruby làm để kiểm thử, đưa cho họ tự tin kiểm thử Phần lớn User Acceptance Testing họ thực cách sử dụng IRB Ba slants (đường nghiêng) khác kiểm thử web services phục vụ ba mục đích khác Lập trình viên sử dụng để giúp kiểm thử client điều hướng phát triển Kiểm thử viên sử dụng để kiểm nghiệm sản phẩm với cách thức tự động hóa hiệu quả, khách hàng kiểm thử web services chuyển giao cho họ cách sử dụng IRB 12.4.3 Embedded Testing Ngoài web interface, hệ thống RDM gồm thiết bị nhúng nhỏ để liên lạc với thiết bị đo cách sử dụng giao thức khác Sử dụng Ruby, kiểm thử khác phát triển để kiểm thử phần giao diện quản trị Giao diện hệ thống dòng lệnh tương tự FTP Những data-driven tests (kiểm thử điều hướng liệu) chứa bảng tính Excel Một kịch Ruby đọc dòng lệnh từ Excel cách sử dụng giao diện OLE gửi chúng đến thiết bị nhúng Kịch sau so sánh phản hồi từ thiết bị với kết mong muốn, lưu bảng tính Các lỗi đánh dấu đỏ Những kiểm thử tự động khoảng tiếng để chạy, thực thủ công kiểm thử tương tự khoảng tám tiếng Trong cung cấp nhiều test coverage, không thực kiểm tra nguyên nhân thiết bị sử dụng, đọc liệu từ RTUs Sự mô biết Ruby với FOX (FXRuby) GUI Điều cho phép giả liệu đưa vào thiết bị Bởi mô điều khiển từ xa, tích hợp vào kiểm thử tự động sử dụng khả thiết bị nhúng để đọc liệu, đáp ứng điều kiện lỗi, tạo cảnh báo dư liệu đầu vào vượt ngưỡng xác định Embedded testing kỹ thuật cao, với sức mạnh cung cấp giả lập, toàn nhóm tham gia vào kiểm thử thiết bị Bộ mô viết để hỗ trợ kiểm thử cho nhóm kiểm thử, lập trình viên cho phần sụn chương trình tìm thấy có giá trị sử dụng để tăng lực phát triển Đó khả ảnh hưởng theo chiều hướng không mong muốn Các kiểm thử Quadrant hỗ trợ nhóm kết hợp loạt công nghệ họ làm dự án 12.5 Critiquing the Product with Business-Facing Tests Các kiểm thử business-facing để kiểm nghiệm sản phẩm trình bày phần 12.5.1 Exploratory Testing Các kiểm thử tự động đơn giản dễ dàng cho người nhóm để sử dụng Các kịch kiểm thử cá nhân chạy để thiết lập điều kiện cụ thể, cho phép kiểm thử thăm dò hiệu thực mà sử dụng nhiều thời gian tự nhập liệu Điều làm việc cho tất ba khung kiểm thử: chức năng, web services, nhúng Nhóm thực kiểm thử thăm dò để bổ sung vào kiểm thử tự động có khả bao phủ tốt Con người tương tác với hệ thống để tìm vấn đề mà tự động hóa không tìm thấy Kiểm thử tính khả dụng (Usability testing) yêu cầu quan trọng với hệ thống, kiểm thử viên theo dõi xem giao diện có ý nghĩa thông suốt không Các kiểm thử viên sử dụng kiểm thử thăm dò rộng lớn để kiểm nghiệm sản phẩm Product engineer sử dụng kiểm thử thăm dò cho kiểm thử xác minh giải pháp anh 12.5.2 Testing Data Feeds Như hình phần 12.2.1, liệu từ hệ thống có sẵn hàng đợi JMS, trình duyệt web Để kiểm thử hàng đợi JMS, nhóm phát triển viết Java proxy Nó kết nối với hàng đợi in liệu lên console (bảng điều khiển) Họ biết Ruby client để nhận liệu qua pipe (ống), có sẵn hệ thống kiểm thử tự động Ruby Email gửi tự động gặp phải điều kiện cảnh báo Các email cảnh báo chứa email văn đơn giản email với file đính kèm Các file đính kèm MIME chứa liệu hữu ích cho việc kiểm thử, đó, Ruby email client hỗ trợ file đính kèm viết 12.5.3 The End-to-End Tests Quadrant bao gồm kiểm thử chức end-to-end để chứng minh hành vi mong muốn phần hệ thống Từ bắt đầu, hiển nhiên hoạt động xác toàn hệ thống điều khiển liệu từ xa (Remote Data Monitoring system) xác định toàn thành phần sử dụng Sau mô phỏng, kiểm thử thiết bị nhúng, kiểm thử web services, kiểm thử ứng dụng viết ra, vấn đề tương đối đơn giản để kết hợp chúng tạo kiểm thử tự động toàn hệ thống Một lần nữa, bảng tính Excel sử dụng để lưu liệu kiểm thử lớp Ruby viết để truy cập liệu kết mong muốn .Các kiểm thử end-to-end trở nên phức tạp đáp ứng khó lường đường truyền vệ tinh Giá trị thời gian chờ định nghĩa từ trước thiết lập, giá trị thực tế kiểm thử không phù hợp với giá trị mong muốn, kiểm thử quay vòng phù hợp đạt thời gian chờ (timeout) Khi hết thời gian chờ, kiểm thử coi thất bại Hầu hết vấn đề truyền dẫn tìm thấy loại bỏ theo cách Nó trở nên không chắn chúng tìm thấy kiểm thử thủ công, chúng vấn đề lẻ tẻ .Bởi kiểm thử end-to-end mong manh, chúng không lưu trữ phần ứng dụng hồi quy tự động Nếu tất thành phần hệ thống bao phủ tốt với kiểm thử hồi quy tự động, kiểm thử end-to-end tự động không cần thiết Tuy nhiên, chất hệ thống này, làm kiểm thử đầy đủ mà không tự động 12.5.4 User Acceptance Testing User Acceptance Testing (UAT) kiểm nghiệm sản phẩm cuối khách hàng, người tham gia dự án từ lúc bắt đầu Trong ví dụ này, khách hàng thực Pháp, cách hàng ngàn dặm so với nhóm phát triển Nhóm phải sáng tạo để có UAT thành công Khách hàng đến làm việc với thành viên nhóm vài lần năm tương tác với đội sớm chút họ chưa gặp Sau nhóm giới thiệu phát triển Agile, Janet đến Pháp để tạo điều kiện UAT nơi khách hàng Nó làm việc tốt, release chấp nhận sau số vấn đề quan trọng sửa chữa Nhóm học nhiều từ kinh nghiệm UAT lần hai thực nhà Để chuẩn bị, nhóm làm việc với khách hàng để phát triển tập kiểm thử mà khách hàng thực để xác minh chức Khách hàng kiểm thử ứng dụng suốt trình phát triển, mà UAT không phát vấn đề Khách hàng đến, chạy kiểm thử kết thúc ngày Chúng nhấn mạnh đủ tầm quan trọng làm việc với khách hàng Mặc dù Product engineer đại diện cho khách hàng, quan trọng để có thời gian đối mặt với khách hàng thực tế Mối quan hệ xây dựng qua thời gian quan trọng với thành công dự án Janet tin tưởng mạnh mẽ UAT thành công khách hàng biết nhóm làm 12.5.5 Reliability Reliability, “ilities” giải kiểm thử Quadrant 4, yếu tố quan trọng hệ thống giám sát site từ xa mà thường tiếp cận, đặc biệt vào mùa đông Bộ mô phát triển cho kiểm thử hệ thống nhúng thiết lập môi trường riêng biệt, chạy vài tuần vào thời điểm đo tính ổn định (chưa phải “ility” khác) toàn hệ thống Việc sửa chữa thiết kế hệ thống lên kế hoạch viết mã cần thiết Đây ví dụ tốt lý bạn không nên chờ đợi kết thúc dự án để thực technology-facing tests để kiểm nghiệm sản phẩm 12.6 Documentation Phương pháp tiếp cận lấy từ tài liệu trình bày phần 12.6.1 Documenting the Test Code Trong thời gian phát triển, trở nên rõ ràng hệ thống tài liệu thức cần thiết cho test code Giải pháp đơn giản sử dụng Rdoc, tương tự Javadoc, cho Ruby Rdoc trích ý kiến đánh dấu từ mã nguồn tạo trang web với chi tiết tập tin, lớp, phương pháp Các Tài liệu tạo tối cách sử dụng batch file sẵn sàng cho nhóm hoàn thành Nó dễ tìm thấy từ đồ đạc kiểm thử tạo Tài liệu test code giúp tài liệu kiểm thử làm cho dễ dàng để tìm kiếm kiểm thử kiểm thử làm Nó mạnh mẽ dễ sử dụng 12.6.2 Reporting the Test Results Mặc dù kiểm thử toàn diện thực hiện, có chứng bên nhóm kiểm thử Các logs tạo trình kiểm thử tự động cung cấp thông tin theo dõi vấn đề tốt không thích hợp cho tập đối tượng rộng lớn Để nâng cao khả hiển thị kiểm thử thực hiện, nhóm kiểm thử phát triển hệ thống khai thác báo cáo sử dụng Apache, PHP, mySQL Khi kiểm thử chạy, nhập kết vào sở liệu Một web front end cho phép người liên quan đến dự án (stakeholders) xác định kiểm thử chạy, tỷ lệ pass/failure, thông tin khác Chúng tin việc tạo khả hiển thị tiến trình (tốt xấu) nhiều tốt Để kết thúc tạo charts graphs đường gửi chúng vào khu vực chung Hình hiển thị số charts mà tạo 12.7 Using the Agile Testing Quadrants Ví dụ chứng minh thực hành kiểm thử từ tất bốn góc phần tư Agile testing, kết hợp đời dự án phát triển phức tạp để đạt bàn giao thành công Kinh nghiệm nhóm cho thấy nhiều nguyên tắc nhấn mạnh Toàn nhóm, bao gồm lập trình viên, kiểm thử viên, đại diện khách hàng (customer proxy), khách hàng thực sự, góp phần lực vào giải các vấn đề tự động Họ thử nghiệm với phương pháp tiếp cận khác Họ kết hợp công cụ home-grown mã nguồn mở với nhiều cách khác để thực kiểm thử tất cấp, từ unit level đến end-to-end system testing UAT Thành công dự án chứng minh thành công phương pháp kiểm thử Như bạn lên kế hoạch cho epic, release, hay iteraction, làm việc với nhóm khách hàng bạn để hiểu ưu tiên thương mại phân tích rủi ro Sử dụng góc phần tư để xác định tất kiểu kiểm thử khác cần thiết chúng thực Performance tiêu chí quan trọng nhất? Ưu tiên cao với khả giao tiếp với hệ thống khác? Tính khả dụng chắn khía cạnh quan trọng nhất? Đầu tư vào kiến trúc kiểm thử, nơi chứa phức tạp hệ thống sau kiểm thử Lên kế hoạch để có nguonf lực cần thiết, chuyên môn thời điểm cho kiểm thử đặc biệt Mỗi loại kiểm thử, nhóm bạn nên làm việc với để chọn công cụ để giải vấn đề kiểm thử Sử dụng retrospectives để liên tục đánh giá nhóm bạn có nguồn lực cần thiết để thành công không, tất kiểm thử cần thiết xác định thời điểm để phục vụ mục đích chúng không, tự động thích hợp chưa End-to-end testing dường làm gì? Nhóm bạn thấy khó để viết unit tests? Khi nhóm Janet thực hiện, tất người thử nghiệm với phương pháp công cụ khác Các góc phần tư cung cấp khung làm việc cho việc động não suy nghĩ (productive brainstorming) theo cách sáng tạo để đạt việc kiểm thử, cho phép nhóm cung cấp giá trị cho doanh nghiệp Summary Trong chương này, mô tả dự án thực sử dụng kiểm thử từ agile testing quadrants để vượt qua thử thách tự động Chúng sử dụng ví dụ từ dự án để đưa Các nhóm thành công với toàn kiểu kiểm thử nào? Một số học quan trọng từ dự án Remote Data Monitoring System là: • • • • • • • • Toàn nhóm nên lựa chọn tạo công cụ để giải vấn đề kiểm thử Kết hợp công cụ thương mại kịch kiểm thử tùy chỉnh cần để thực kiểm thử phức tạp Đầu tư thời gian vào việc xây dựng kiến trúc kiểm thử Tìm cách để khách hàng tham gia vào toàn kiểu kiểm thử, chúng vị trí xa Báo cáo kết kiểm thử đến bên liên quan (stakeholders) để thông báo iteration quy trình hệ thống Đừng quên tài liệu … tài liệu hữu ích Nghĩ toàn quadrants suốt chu kỳ phát triển bạn Sử dụng lessons learned trình kiểm thử để thực nghiệm sản phẩm nhằm thúc đẩy phát triển lần lặp sau [...]... quanh việc REQ trong phát triển Agile sẽ gồm những nội dung gì? REQ cần rõ ràng đến mức nào? Làm sao để khách hàng nói rõ REQ cho chúng ta? 8.2 The Requirements Quandary Phát triển Agile gắn với sự thay đổi, nhưng điều gì sẽ xảy ra nếu REQ thay đổi trong một interaction? Chúng ta sẽ làm thế nào để biết đã thực sự hiểu chi tiết về story trước khi bắt đầu code? Trong phát triển Agile, tính năng mới thường... liệu người dùng sử dụng phần mềm có thực hiện những hành động mà story giả định là đã cung cấp Ngay thời điểm này, chúng ta chỉ cần thực hiện các hoạt động của Q3, Q4 như exploratory testing, usability testing và performance testing sẽ giúp chúng ta tìm ra • • điều này Chúng ta cần phải thực hiện 1 vài customer test để đảm bảo chúng ta nắm bắt được toàn bộ các yêu cầu Bussiness users hoặc PO là những người... mong muốn với các ví dụ: • Checklists • • • • • Mind maps Spreadsheets Mock-ups Flow diagrams Software-based tools Danh sách gồm các công cụ đơn giản, không chỉ sử dụng cho Agile testing, nhưng không nên bỏ qua Trong phát triển Agile, các giải pháp đơn giản luôn là tốt nhất 9.2.1 Checklists Checklist là một cách để PO (Product Owners) đảm bảo việc đánh giá và truyền đạt toàn bộ khía cạnh của một story... cong đào tạo) nhưng được sử dụng cho performance và load testing Bởi nó có thể lặp các hàng trong một Excel spreadsheet hay text file, nó có thể được sử dụng cho data-driven testing Các kiểm thử làm việc ở các lớp dưới lớp trình bày (presentation layer) thích hợp cho việc viết và tự động hóa các kiểm thử định hướng mã nguồn 9.3.2 Tools for Testing through the GUI Làm thế nào chúng ta có thể sử dụng... tốt và bộ kiểm thử được bảo trì dễ dàng Nhiều nhóm Agile thích các công cụ và ngôn ngữ kịch bản giúp họ tạo Domainspecific language (DSL) riêng Điều này làm cho các kiểm thử dễ dàng hơn với các chuyên gia thương mại (business experts) để hiều và viết chúng b Agile Open Source Test Tools Mỗi công cụ trong phần này đều được viết bởi một nhóm phát triển Agile, họ cần công cụ kiểm thử GUI mà không thể tìm... chiến lược để sử dụng chúng, cung cấp business-facing tests hỗ trợ team phát triển những story mới Một trong những công cụ chúng ta thảo luận không mới, hoặc cụ thể cho phát triển Agile, nhưng chúng làm việc tốt trong dự án Agile Chiến lược trong việc lựa chọn công cụ cần dựa vào tập hợp các kỹ năng của nhóm bạn, công nghệ mà ứng dụng đã dùng, mức độ ưu tiên tự động hóa của nhóm, sự ràng buộc về thời... đối thoại giữa khách hàng và thành viên team, agile team thường mở rộng các story cho đến khi họ đủ thông tin để code Tester sẽ giúp gợi ra các ví dụ và ngữ cảnh cho mỗi story và giúp khách hàng viết kịch bản test cho story, những loại test mà sẽ giúp cho programmer viết code và giúp team hiểu khi nào thỏa mãn được điều kiện của khách hàng Trong phát triển agile chúng ta chấp nhận việc sẽ không bao giờ... cách thêm vào REQ càng chi tiết càng tốt Trong những project sử dụng thực hành Agile chúng ta đặt toàn bộ vào các story card và test cái mà khách hàng cũng có thể hiểu được nhằm giúp chúng ta code đúng Những loại test " có thể hiểu được " này là chủ đề của chương này 8.1.Driving development with business-facing tests Trong agile chúng ta bắt đầu interaction với thông tin chỉ trong index card ( story)... hai tuần hoặc 30 ngày, thông tin sẽ được phản hồi ngay lập tức và tự động Các nhóm Agile có kinh nghiệm có thể chấp nhận việc định hướng code bằng test tự động ở mức developer test dễ dàng hơn ở mức customer test Tuy nhiên, nếu không có customer test, programmer mất nhiều thời gian để biết unit test viết những gì • Mỗi Agile team phải tìm ra 1 quy trình viết và chạy tự động businessfacing test để định... để hiển thị những gì mà ứng dụng được hỗ trọ để làm Keyword-driven testing là công cụ khác được sử dụng trong kiểm thử đơn vị, các từ khóa được định nghĩa trước sử dụng để định nghĩa các hành động Các hành động này tương ứng một quy trình liên quan đến ứng dụng Nó là bước đầu tiên trong việc tạo một ngôn ngữ lĩnh vực kiểm thử (domain testing language) Những từ khóa (hay các từ hành động) mô tả một ngôn