Agile testing automation testing (phần 4)

Bản dịch của quyển Agile testing A practical guide for testers and Agile teams của Addison Wesley (2009); Test automation is a core agile practice. Agile projects depend on automation.Goodenough automation frees the team to deliver highquality code frequently. It provides a framework that lets the team maximize its velocity whilemaintaining a high standard. Source code control, automated builds and testsuites, deployment, monitoring, and a variety of scripts and tools eliminatetedium, ensure reliability, and allow the team to do its best work at all times.Automation is also a vast topic. It includes tasks like writing simple shellscripts, setting up session properties, and creating robust automated tests.The range and number of automated tools seem to grow exponentially as welearn about better ways to produce software. Happily, the number of excellent books that teach ways to automate appears to grow just as fast.

Part IV - Automation Kiểm thử tự động thực hành cốt lõi Agile Các dự án Agile phụ thuộc vào tự động hóa Nó cung cấp khung làm việc giúp nhóm tối đa tốc độ phát triển đảm bảo chất lượng sản phẩm Kiểm thử tự động đảm bảo độ tin cậy tạo điều kiện để nhóm làm việc tốt Chapter 13 - Why We Want to Automation Tests and What Holds Us Back 13.1 Why Automate? Có nhiều lý để tự động hóa để áp dụng Agile thành công: • Kiểm thử thủ công nhiều thời gian • Các quy trình thủ công dễ gây lỗi • Tự động hóa giúp bạn làm việc tốt • Kiểm thử hồi quy tự động cung cấp mạng lưới an toàn • Kiểm thử tự động cung cấp phản hồi sớm thường xuyên • Các kiểm thử ví dụ làm cho việc viết mã dễ dàng nhiều • Kiểm thử cung cấp tài liệu hướng dẫn • Tự động mang lại lợi nhuận 13.1.1 Manual testing takes too long Lý mà nhóm muốn tự động hóa kiểm thử thủ công chiếm nhiều thời gian để hoàn thành Khi ứng dụng lớn hơn, thời gian để kiểm thử tăng, theo cấp số nhân, phụ thuộc vào phức tạp AUT (Application Under Test) Agile teams thường release sản phẩm vào cuối lần lặp, việc chạy kiểm thử hồi quy cần thiết Nếu thực kiểm thử hồi quy thủ công nhiều thời gian, để kiểm thử kịp với việc viết mã, lập trình viên phải giúp kiểm thử phải thuê thêm kiểm thử viên Chắc chắn nợ kỹ thuật khả thất bại tăng lên Nếu nhóm không thực kiểm thử hồi quy mức đơn vị, kiểm thử viên nhiều thời gian để nghiên cứu, tái báo cáo lỗi; làm giảm thời gian tìm lỗi nghiêm trọng hệ thống Ngoài ra, nhóm không thực kiểm thử test-first, thiết kế mã không kiểm chứng không cung cấp chức mong muốn doanh nghiệp Kiểm thử thủ công kịch khác chiếm nhiều thời gian, đặc biệt giao diện người dùng Thiết lập liệu cho chuỗi kịch phức tạp việc sức không tự động hóa Nó làm giới hạn kịch kiểm thử thiếu sót defects 13.1.2 Manual Processes Are Error Prone Kiểm thử thủ công lặp lặp lại, làm cho kiểm thử viên dễ nhàm chán dễ tạo sai lầm (mistakes) bỏ qua lỗi đơn giản Đặc biệt, nhóm bị giới hạn thời gian, dễ gây áp lực dẫn đến việc bỏ qua số trường hợp kiểm thử Tự động trình xây dựng, triển khai, kiểm soát phiên bản, giám sát hướng tới giảm thiểu rủi ro làm cho quy trình phát triển quán Các kiểm thử tự động giới hạn khả lỗi (errors), kiểm thử thực xác theo cách thời điểm Quy trình tự động xây dựng triển khai cho phép bạn biết xác bạn kiểm thử môi trường 13.1.3 Automation Frees People to Do Their Best Work Viết mã test-first giúp lập trình viên hiểu yêu cầu thiết kế mã phù hợp Tự động kiểm thử đơn vị kiểm thử hồi quy chức có nhiều thời gian để kiểm thử thăm dò Tự động hóa giúp bạn giảm thời gian thực kịch nhàm chán, tăng thời gian để nghĩ kịch khác, học hỏi thêm cách ứng dụng hoạt động, … Tự động kiểm thử hồi quy giúp phát thay đổi chức cung cấp phản hồi mục tiêu phần 13.1.4 Automated Regression Tests Provide a Safe Net Hầu hết người có chuyên môn kinh doanh phần mềm cảm thấy sợ hãi phải đối mặt với việc sửa lỗi, hay hoàn thành tính với mã nguồn thiết kế nghèo nàn không bao phủ kiểm thử tự động Nếu mã nguồn bao phủ kiểm thử tự động giúp họ tự tin Chắc chắn, thay đổi tạo ảnh hưởng không mong muốn, bị phát vài phút mức đơn vị, vài mức chức Tạo thay đổi test-first, có nghĩa thay đổi hành vi trước viết mã viết kiểm thử để xác minh nó, làm tăng niềm tin Nhóm có kiểm thử hồi quy tự động tốt không sợ việc thay đổi mã nguồn Các kiểm thử cho họ thấy điều bị ảnh hưởng Họ nhanh nhóm dựa vào kiểm thử thủ công 13.1.5 Automated Tests Give Feedback, Early, and Often Chạy kiểm thử tự động có mã nguồn giúp đảm bảo lỗi (bugs) hồi quy bị nắm bắt nhanh chóng Nếu kiểm thử hồi quy không tự động, không chạy lần lặp Lỗi hồi quy xảy vào cuối sản phẩm, nhiều lợi ích từ việc kiểm thử sớm bị Các kiểm thử tự động chạy thường xuyên hoạt động thiết bị phát thay đổi Chúng cho biết thay đổi kể từ lần build gần Nếu tự động có đủ độ bao phủ, dễ dàng nói ảnh hưởng sâu rộng mà kiểm thử viên tìm thấy 13.1.6 Tests and Examples that Drive Coding Can Do More Trong chapter 7, “Technology-Facing Tests that Support the Team”, nói việc sử dụng kiểm thử ví dụ để điều hướng việc viết mã Cũng đề cập đến tầm quan trọng việc điều hướng mã kiểm thử đơn vị kiểm thử khách hàng Cũng nhấn mạnh kiểm thử tự động, chúng trở nên có giá trị, trở thành sở cho hồi quy vô mạnh TDD (Test-Driven Development hay Test-Driven Design) SDD (Story test-Driven Development) làm cho nhóm nghĩ test-first Họ thiết kế mã để kiểm thử pass, khả kiểm thử không vấn đề Kiểm thử tự động phát triển với mã nguồn bản, cung cấp mạng lưới an toàn cho việc cải tiến mã nguồn liên tục Quan trọng toàn nhóm (Whole-team) thực hành TDD viết Unit test Nợ kỹ thuật (Technical debt) giảm, tốc độ (velocity) ổn định tăng theo thời gian lý nhà quản lý vui vẻ để nhóm phần mềm dành thời gian hoàn thành thực hành cách xác 13.1.7 Tests Are Great Documentation Khi kiểm thử minh họa ví dụ hành vi mong muốn tự động hóa, chúng trở thành tài liệu “sống”, hướng dẫn hệ thống làm việc Khi hệ thống thay đổi, cần cập nhật lại kiểm thử tự động, không chúng bị fail Điều có nghĩa kiểm thử tự động tranh xác cho thấy mã nguồn làm việc 13.1.8 ROI and Payback Tự động có nghĩa thêm thời gian cho kiểm thử viên thành viên nhóm tập trung vào việc tạo sản phẩm chất lượng thị trường cách kịp thời Khi lập trình viên chạy kiểm thử tự động môi trường riêng họ, kiểm thử hồi quy tự động tìm thấy lỗi trước mã nguồn check-in, có nhiều thời gian để sửa chữa thiết kế Đó cách giảm nợ kỹ thuật phát triển mã nguồn vững 13.2 Barriers to Automation - Things that Get in the Way Vào năm 2001, Bret Pettichord liệt kê vấn đề cản trở tự động hóa Chúng áp dụng, dành cho nhóm không kết hợp tự động hóa vào trình phát triển họ 13.2.1 Bret’s List Danh sách vấn đề tự động Bret sau: • Chỉ sử dụng thời gian rảnh để tự động hóa kiểm thử, không tập trung cần thiết • Thiếu mục tiêu rõ ràng • Thiếu kinh nghiệm • Có tốc độ thay cao, bạn bị kinh nghiệm mà bạn có • Phản ứng tiêu cực nguyên nhân tự động hóa chọn để mang lại hy vọng đề nghị thực tế • • Miễn cưỡng nghĩ kiểm thử tự động hóa Tập trung vào giải vấn đề công nghệ làm bạn khả quan sát cho dù kết phù hợp với yêu cầu kiểm thử 13.2.2 Our List Dựa vào kinh nghiệm làm việc với nhóm Agile team khác: • Thái độ lập trình viên • “Hump of Pain” (Sự gồ ghề nỗi đau) • Đầu tư ban đầu • Mã nguồn thay đổi • Hệ thống di sản • Sự sợ hãi • Thói quen cũ 13.2.3 Programmers’ Attitude - “Why Automate?” Các lập trình viên làm việc môi trường truyền thống, có số khác biệt, QA thực toàn kiểm thử Một số lập trình viên không quan tâm đến kiểm thử họ có nhóm QA bắt lỗi trước release Theo thời gian, kiểm thử viên làm công việc họ, lập trình viên chuyển sang release Các defects đưa vào hàng đợi để sửa chữa với chi phí lớn, không chịu trách nhiệm tạo chúng Ngay lập trình viên thực TDD (Test-Driven Development) tự động kiểm thử đơn vị không nghĩ cách kiểm thử chấp nhận Giáo dục chìa khóa để lập trình viên nhóm hiểu tầm quan trọng tự động hóa 13.2.4 The “Hump of Pain” (The Learning Curve) Thật khó để học kiểm thử tự động, đặc biệt học để tạo lợi nhuận tốt đầu tư nguồn lực Brian Marick sử dụng giới hạn để mô tả giai đoạn đầu tự động hóa lập trình viên (và kiểm thử viên) phải vượt qua “Hump of Pain” áp dụng tự động hóa Các nhóm thường dự kiến áp dụng TDD Refactoring, kỹ thuật khó để tìm hiểu Nếu huấn luyện tốt, nhiều thời gian để làm chủ kỹ hỗ trợ quản lý, họ dễ bị nản lòng Nếu họ có thêm trở ngại tìm hiểu, phải làm việc với thiết kế nghèo nàn từ mã nguồn cũ, khó kéo họ kiểm thử tự động “Hump of Pain” xảy bạn xây dựng khung kiểm thử dựa miền xác định hay học công cụ kiểm thử chức Bạn nhờ chuyên gia giúp bạn thiết lập Nếu team bạn không dễ dàng vượt qua “Hump”, phải có quy trình tự nhiên ngấm vào người nhóm 13.2.5 Initial Investment Tự động hóa đòi hỏi đầu tư lớn Nó thời gian nghiên cứu để định khung kiểm thử sử dụng liệu tự xây dựng hay sử dụng công cụ sản xuất bên Phần cứng mềm yêu cầu Các thành viên nhóm khoảng thời gian để học cách sử dụng Nếu tổ chức có người có kinh nghiệm kiểm thử tự động, tổ chức trả tiền cho nhà cung cấp công cụ capture-playback, đưa cho cho nhóm QA mong giải toàn vấn đề tự động hóa Nhưng kinh nghiệm ỏi tạo kiểm thử khó hiểu, khó bảo trì không hữu dụng lâu dài Vì vậy, nhóm với đào tạo kỹ đầy đủ mang lại lợi nhuận đầu tư tự động hóa Thiết kế kiểm thử đơn giản, tốt, liên tục tái cấu trúc, kiểm thử có khả trì Thư viện module kiểm thử đối tượng kiểm thử xây dựng theo thời gian tạo kiểm thử nhanh Tuy nhiên, dễ dàng để nắm bắt số liệu Như, thời gian để viết trì kiểm thử tự động so với thời gian chạy kiểm thử hồi quy thủ công Tương tự, chi phí để sửa chữa defects vài phút phát so với chi phí để tìm sửa chữa sau kết thúc quy trình khó Nếu số chứng minh tự động cần nguồn lực cung cấp nhiều giá trị hơn, nhóm khó thuyết phục quản lý đầu tư vào tự động hóa, khó để thay đổi thói quen nhóm 13.2.6 Code that’s Always in Flux Các kiểm thử tự động thông qua giao diện người dùng khó, UI thường thay đổi liên tục trình phát triển Nó lý mà kỹ thuật record playback lựa chọn tốt cho dự án Agile Nếu nhóm khó để tạo thiết kế tốt logic nghiệp vụ, truy cập sở liệu, thường xuyên làm lại Nó khó kiểm thử tự động sau GUI mức API Trong trường hợp này, lập trình viên kiểm thử viên cần làm việc với để có ứng dụng kiểm thử Mặc dù mã nguồn thực thực tế có xu hướng thay đổi liên tục phát triển Agile, mục đích mã nguồn thay đổi Tổ chức mã kiểm thử mục đích ứng dụng, cho phép bạn theo kịp với phát triển 13.2.7 Legacy Code Viết vài kiểm thử cho mã nguồn kiểm thử công việc khó khăn Nó với nhóm với Agile kiểm thử tự động Nếu bạn muốn tự động kiểm thử, bạn phải tái cấu trúc số legacy code, legacy code không thiết kế cho khả kiểm thử, khó tự động kiểm thử mức đơn vị 13.2.8 Fear Kiểm thử tự động thực khó với chưa làm chủ nó, kể người sử dụng Các lập trình viên viết mã sản phẩm tốt, họ nhiều kinh nghiệm viết kiểm thử tự động Các kiểm thử viên tảng lập trình tốt, họ không tin vào kỹ kiểm thử tự động họ Kiểm thử viên kinh nghiệm lập trình thường nhận thông điệp họ để làm giới Agile Nhưng không lập trình viên cần lo lắng làm để tự động hóa Nó vấn đề nhóm, thường lập trình viên giúp đỡ họ mặt lập trình 13.2.9 Old Habits Khi lần lặp (iterations) không tiến hành thuận lợi, nhóm hoàn thành toàn công việc lập trình kiểm thử vào cuối lần lặp, thành viên nhóm rơi vào trạng thái hoảng sợ Khi họ rơi vào trạng thái này, họ dễ quay thói quen cũ, kể thói quen không mang lại kết tốt Đây đường đến diệt vong Một số kiểm thử thủ công hoàn thành tìm lỗi chi phí công ty tăng lên đến hàng ngàn đô la Nếu công việc kiểm thử kết thúc, chúng chuyển sang lần lặp tiếp theo, làm giảm giá trị kinh doanh mang lại Nếu lặp lặp lại, trạng thái tiếp tục xấu sau 13.3 Can we Overcome These Barriers? Phương pháp tiếp cận toàn team (Whole-team) tảng để vượt qua thử thách tự động hóa Các lập trình viên với Agile cung cấp mã nguồn, cho dù có lỗi hay không, miễn họ hạn TDD (Test-Driven Development) định hướng thiết kế kiểm thử, kiểm thử business-facing phải phụ thuộc vào ý thức họ Nó khả lãnh đạo (Leadership) cam kết (commitment) nhóm chất lượng để người phải ý thức việc phải viết, sử dụng chạy kiểm thử technology-facing business-facing Bắt toàn nhóm tham gia vào trình kiểm thử tự động thách thức văn hóa Summary Trong chương này, tóm lược toàn tác nhân liên quan đến tự động kiểm thử: • Chúng ta cần tự động để cung cấp mạng lưới an toàn, cung cấp phản hồi cần thiết, tối thiểu hóa nợ kỹ thuật giúp điều hướng việc viết mã • Sự sợ hãi, thiếu kinh nghiệm, kinh nghiệm tiêu cực khứ với tự động hóa, tốc độ thay đổi mã nguồn mã di sản cản trở tự động hóa • Tự động hóa kiểm thử hồi quy, chạy chúng quy trình build tự động sửa nguyên nhân gốc defects làm giảm nợ kỹ thuật tăng trưởng mã vững • Tự động hóa kiểm thử hồi quy việc thủ công nhàm chán giải phóng nhóm cho việc quan trọng hơn, kiểm thử thăm dò • Nhóm với kiểm thử tự động quy trình build tự động làm cho vận tốc ổn định • Không có kiểm thử hồi quy tự động, kiểm thử hồi quy thủ công tiếp tục phát • triển phạm vi cuối đơn giản bỏ qua Văn hóa nhóm lịch sử làm cho khó khăn lập trình viên để ưu tiên tự động hóa cho kiểm thử business-facing viết mã cho tính Sử dụng nguyên tắc giá trị Agile giúp toàn nhóm vượt qua rào cản kiểm thử tự động Chapter 14 - An Agile Test Automation Strategy Chương giải thích làm để ứng dụng giá trị nguyên tắc Agile vào việc sử dụng cải tiến lực tự động hóa 14.1 An Agile Approach to Test Automation 14.1.1 Automation Test Categories Trong phần Agile Testing Quadrants, nói quadrant mục tiêu kiểm thử phần Giờ tìm hiểu khía cạnh khác Với góc phần tư Q1, Q2 dán nhãn có sử dụng tự động hóa Với Q4, công cụ sử dụng để tìm nhược điểm sản phẩm từ góc nhìn kỹ thuật, thường yêu cầu công cụ tự động hóa Trong thực tế, Q3 không cần sử dụng tự động hóa; Tuy nhiên, công cụ hữu dụng số trường hợp, như, tự động giúp thiết lập liệu kiểm thử, kịch người dùng, phân thích hoạt động đăng nhập Sử dụng góc phần tư giúp xác định loại công cụ tự động hóa cần thiết dự án hay lần lặp Thứ tự góc không liên quan đến thứ tự kiểm thử Tạo checklist công cụ cần thiết cho loại kiểm thử, biết công cụ tự động hóa sẵn sàng Các góc phần tư giúp tìm công cụ cần thiết, với lựa chọn tự động hóa mức khác nhau, chiến lược thực tổ chức kiểm thử khác nhau, Kim tự tháp kiểm thử giúp tối ưu hóa lực kiểm thử 14.1.2 Test Automation Pyramid Kim tự tháp kiểm thử tự động Agile cho thấy lớp khác kiểm thử tự động • Lớp thấp tảng hỗ trợ toàn phần lại • Nó chủ yếu tạo kiểm thử đơn vị mạnh mẽ kiểm thử thành phần, kiểm thử technology-facing hỗ trợ nhóm • Lớp đại diện số lượng lớn kiểm thử tự động hóa • Chúng viết ngôn ngữ với hệ thống, sử dụng công cụ thuộc gia đình xUnit • Sau nhóm làm chủ công nghệ TDD, kiểm thử tạo nhanh tốn Chúng cung cấp phản hồi nhanh nhất, làm cho chúng có giá trị cao Chúng có ROI lớn so với loại kiểm thử • • • • • • • • • • • Lớp kim tự tháp Nó gồm hầu hết kiểm thử business-facing, viết để hỗ trợ nhóm Các kiểm thử lớp bao gồm kiểm thử ‘Story’, kiểm thử chấp nhận, kiểm thử bao trùm tập chức lớn lớp kiểm thử đơn vị Những kiểm thử hoạt động lớp API “Bên GUI”, kiểm thử chức trực tiếp mà không thông qua GUI Chúng viết trường hợp kiểm thử, bao gồm thiết lập đầu vào cho mã sản phẩm, chấp nhận kết đầu ra, so sánh kết mong đợi Vì kiểm thử bỏ qua lớp trình bày, nên chúng tốn để viết trì kiểm thử sử dụng GUI Cố gắng viết kiểm thử theo ngôn ngữ xác định để khách hàng hiểu Chúng chạy chậm hơn, kiểm thử đảm bảo kiểm thử đơn vị phải truy cập liệu thành phần khác Phản hồi không nhanh kiểm thử đơn vị nhanh kiểm thử qua GUI Do đó, GUI chúng không cao kiểm thử hình thành lớp cao lớp đỉnh kim tự tháp Lớp đại diện cho lực tự động hóa nhỏ nhất, chúng cung cấp ROI thấp Những kiểm thử thực thông qua GUI Chúng viết sau mã nguồn hoàn thành nhằm mục đích tìm nhược điểm sản phẩm, chúng thêm trực tiếp vào kiểm thử hồi quy Những kiểm thử thường nhiều chi phí để viết, có nhiều công cụ giúp giảm thiểu đầu tư cần thiết Bởi thành phần giao diện hay bị thay đổi, kiểm thử dễ bị lỗi kiểm thử mức chức đơn vị Các kiểm thử cung cấp phản hồi quan trọng, kiểm thử GUI chiếm nhiều để chạy vài phút chạy kiểm thử đơn vị Không vấn đề kiểm thử tự động hóa, hầu hết hệ thống cần hoạt động kiểm thử thủ công, kiểm thử thăm dò kiểm thử chấp nhận Hầu hết nhóm Agile thường bắt đầu ngược với kim tự tháp • Các công cụ kiểm thử GUI thường dễ học, nhóm bắt đầu với kiểm thử lớp • Nếu hệ thống thiết kế điều hướng kiểm thử, kiểm thử chức lớp dễ dàng để viết • Là nhóm làm chủ TDD kiểm thử tự động đơn vị, lớp bắt đầu phát triển Khi chúng nhận lực đẩy, nhóm sử dụng TDD nhanh chóng xây dựng kiểm thử lớp thấp kim tự tháp Kim tự tháp kiểm thử nơi tốt để bắt đầu tìm hiểu kiểm thử tự động giúp Agile team • Các lập trình viên có xu hướng tập trung vào đáy kim tự tháp, họ cần nhiều thời gian, đào tạo để vượt qua “hump of pain” tiếp nhận TDD cách tự nhiên nhanh chóng Phương pháp toàn nhóm (Whole-team) sử dụng Agile team cho phép kiểm thử viên ghép với lập trình viên để giúp họ • • thực kiểm thử tốt hơn, từ củng cố thêm lớp đáy kim tự tháp Vì phát triển điều hướng kiểm thử, toàn nhóm thiết kế tối đa khả kiểm thử kim tự tháp phát triển hình dạng Các lập trình viên làm cặp với kiểm thử viên để tự động hóa kiểm thử chức năng, làm đầy lớp kim tự tháp Các lập trình viên tìm cách giảm chi phí tự động hóa kiểm thử GUI lớp có nhiều lợi ích, lập trình viên hiểu “bức tranh lớn” hệ thống kiểm thử viên học cách tạo mềm dẻo kiểm thử GUI 14.2 What Can We Automate? 14.2.1 Continuous Integration, Builds, and Deploys Bất kỳ công việc tẻ nhạt lặp lặp lại liên quan đến phát triển phần mềm tự động hóa Nói tầm quan trọng trình build tự động • Bạn xây kim tự tháp kiểm thử tự động mà điều Nhóm cần có phản hồi từ kiểm thử đơn vị để tiếp tục theo dõi lên lớp • Mail từ trình build tự động thông báo thay đổi check-in giúp kiểm thử viên biết build sẵn sàng cho việc kiểm thử Quá trình triển khai tự động làm tăng tốc kiểm thử giảm thiểu lỗi • Trong thực tế, ngày Janet chỉnh sửa chương này, cô sai lầm việc triển khai trình thủ công Nó đơn giản, cô vào dự án chuyển nhầm tập tin đến chỗ sai Một trình triển khai tự động thực việc cần thiết chỗ Janet Nhóm Lisa tích hợp thành công vào khung làm việc thấy dễ dàng thời gian, cần bảo dưỡng nâng cấp liên tục Hầu hết Agile team thấy build kéo dài lâu 8-10 phút không khả thi Ngay 15 phút dài để chờ phản hồi, check-in xếp chồng lên kiểm thử viên phải chờ thời gian dài để nhận build gần nhất, tốt Các build dài việc truy cập sở liệu cố gắng kiểm thử GUI Trong trường hợp này, • Hãy cố gắng chép sở liệu thật sử dụng nhớ thay • Hoặc cấu hình quy trình build để phân phối kiểm thử vài máy • Hoặc tìm phần mềm khác để quản lý tài nguyên tốt • Hoặc nhờ giúp đỡ các chuyên gia bên Chìa khó để tăng tốc độ tích hợp liên tục trình build thực bước nhỏ thời điểm Nó đưa thay đổi thời điểm, bạn đo lường thành công biết bạn hướng hay không Lúc bắt đầu, bạn muốn loại bỏ kiểm thử tốn khỏi build để chạy vào ban đêm Tích hợp liên tục trình build chạy nhanh mang lại ROI lớn lực kiểm thử tự động Nó thứ mà team cần phải tự động 14.2.2 Unit and Component Tests Chúng nhấn mạnh mức vào tầm quan trọng việc tự động hóa kiểm thử đơn vị Nếu lập trình viên sử dụng TDD tổ chức để viết kiểm thử họ, họ không tạo hồi quy lớn, mà sử dụng chúng để thiết kế mã nguồn chất lượng cao, mạnh mẽ Nếu nhóm không tự động kiểm thử, hội thành công lâu dài mong manh Tạo tự động kiểm thử đơn vị tích hợp liên tục ưu tiên hàng đầu 14.2.3 API or Web Services Testing Kiểm thử API hay ứng dụng Web Services dễ dàng sử dụng số mẫu tự động hóa • Janet trưởng thành team có thành công việc sử dụng Ruby để đọc bảng tính với tất hoán vị hợp tác biến đầu vào, so sách đầu vào với kết mong muốn lưu trữ bảng tính Các kiểm thử điều hướng liệu dễ dàng để viết bảo trì • Một khách hàng Janet sử dụng chức IRB (Interactive Ruby Shell) Ruby để kiểm thử Web Services cho phần nghiệm thu Nhóm chia sẻ kịch với khách hàng, kiểm thử viên nghiệp vụ thích nhìn thấy xảy đầu vào bị thay đổi Chạy kiểm thử theo phương pháp bán tự động (semi-automated) cho phép điều xảy 14.2.4 Testing behind the GUI Kiểm thử bên GUI dễ dàng tự động kiểm thử GUI Bởi kiểm thử không chịu ảnh hưởng thay đổi lớp trình bày làm việc dựa mã nguồn logic nghiệp vụ ổn định Các công cụ sử dụng cho kiểm thử thường theo định dạng khai báo, bảng bảng tính Các thiết bị lấy mã sản phẩm để thực đầu vào kiểm thử trả kết viết nhanh chóng Nó viết cho kiểm thử business-facing, dễ hiểu với hai khách hàng lập trình viên 14.2.5 Testing the GUI Một GUI với chút logic nghiệp vụ phải kiểm thử Trong phát triển Agile, chức cung cấp lần lặp, cần số kiểm thử hồi quy tự động mức GUI hầu hết dự án Lựa chọn công cụ chìa khóa thành công tự động GUI • Các kịch tự động cần mềm dẻo dễ dàng để bảo trì • Cần thời gian để phát triển thư viện, để kiểm thử tự động làm lại lặp lại mã nguồn Khi thay đổi xảy ra, việc sửa đổi nơi Làm cho mã nguồn dễ dàng bảo trì làm tăng ROI 14.4 What Might Be Hard to Automate? Khi mã nguồn không viết test-first, không suy nghĩ tự động kiểm thử, khó để tự động hóa Legacy code có I/O, truy cập sở liệu, logic nghiệm vụ presentation code đan xen vào Nó không rõ ràng để lấy mã nguồn để tự động hóa kiểm thử Chắc chắn bạn lên kế hoạch tự động thứ bên GUI, có nhiều logic presentation layer Có số phương pháp tiếp cận khác để khắc phục nó, sau kiểm thử tự động trở nên dễ dàng • “Làm việc hiệu với Legacy code [2004] Michael Feathers giải thích làm để xây dựng khung kiểm thử sở mã nguồn tái cấu trúc chúng để thích hợp với tự động hóa Với Legacy code, bạn viết kiểm thử để tránh vấn đề phát sinh Cách tiếp cận làm việc với hệ thống thiếu cấu trúc không hướng đối tượng • Nhóm Lisa có cách tiếp cận khác hiệu Các thành viên nhóm bắt đầu “bóp nghẹt - Strangling” Legacy code cách viết toàn tính với kiến trúc thân thiện với kiểm thử Họ dần thay toàn mã cũ mã viết test-first Khi họ làm việc với mã cũ để sửa lỗi, cần cập nhật, đơn giản họ thêm vào kiểm thử đơn vị cho toàn mã nguồn mà họ thay đổi Một GUI smoke test cho chức quan trọng Legacy system kiểm thử đơn vị 14.5 Developing an Automation Strategy - Where Do We Start? Đơn giản, tiếp cận bước thích hợp với chiến lược tự động hóa Nhưng Agile Testing, định bắt đầu tự động từ đâu đòi hỏi suy nghĩ thảo luận toàn nhóm Khi nhóm nhìn vào thách thức kiểm thử, bạn phải xem xét tự động hóa đâu cho phù hợp Trước bạn tìm kiếm công cụ tự động cụ thể, bạn nên xác định nhu cầu nhóm • Nếu đầu, tìm kiếm lợi ích lớn Cú đánh lớn vào vấn đề xác định kiểm thử đơn vị mà lập trình viên thực Thay đỉnh kim tự tháp kiểm thử, bạn đáy, đảm bảo vấn đề đưa Bạn cần xem xét loại kiểm thử khác mà bạn cần kiểm thử sau bạn cần số công cụ để sử dụng • Giả định, bạn tự động kiểm thử đơn vị thành phần Q1, tìm kiếm tự tự động Business-facing tests Q2,3, technology-facing tests Q4 • Nghĩ kỹ kinh nghiệm nhóm Ai cần tự động hóa sao? Mục tiêu đạt gì? Hiểu số vấn đề ảnh hưởng đến lựa chọn công cụ nỗ lực bỏ Đánh giá công cụ lựa chọn 14.5.1 Where Does It Hurt the Most? Để tìm nơi tập trung nguồn lực tự động, hỏi nhóm “Chỗ khó khăn gì?” “Chỗ nhàm chán gì?”, bạn có phải viết mã để triển khai kiểm thử không? thành viên nhóm có tự tin với việc thay đổi mã nguồn không? họ có mạng lưới an toàn không? Chỗ khó khăn nơi để bắt đầu tự động hóa • Nếu nhóm vật lộn với việc phân phối mã, bạn cần thực quy trình build tự động • Nếu hiệu làm cho tồn tổ chức bị nguy hiểm, kiểm thử hiệu cần ưu tiên hàng đầu Kiểm thử tự động tuyệt vời phát triển nơi • Tính hợp liên tục chạy kiểm thử đơn vị bước đầu hướng tới tự động kiểm thử khác mã nguồn tái cấu trúc liên tục để bảo trì thiết kế tốt giúp ROI tự động hóa tăng Tái cấu trúc thực kiểm thử đơn vị tốt • Những thực hành phát triển nên áp dụng cho kịch kiểm thử chức tự động 14.5.2 Multi-Layered Approach Sử dụng công cụ thích hợp cho loại yêu cầu • Công cụ làm việc tốt cho kiểm thử đơn vị, không phù hợp với kiểm thử chức • Kiểm thử GUI, Load, Performance, Security yêu cầu công cụ, công cụ khác Nội dung kim tự tháp Mike Cohn giúp nhóm đặt nguồn lực tự động vào nơi họ thực tốt Tối đa hóa kiểm thử để thu ROI tốt Nếu kiến trúc hệ thống thiết kế cho khả kiểm thử kiểm thử tự động tốn đặc biệt lớp đơn vị • Các kiểm thử GUI thường có ROI thấp nhất, phải thực chúng Hãy lựa chọn số kiểm thử đơn giản để thực trước nhất, kiểm thử GUI lại tốt kiểm thử dựa vào tương tác người (ví dụ, kiểm thử thủ công) • Ở lớp giữa, kiểm thử chức làm việc trực tiếp với mã nguồn sản phẩm, không cần GUI Nếu nhóm kinh nghiệm để kiểm thử đơn vị với công cụ thích hợp cho phép chúng có ROI tốt Các kiểm thử viết ngôn ngữ mà chuyên gia thương mại hiểu giá trị chúng • Có nhiều lớp khác ứng dụng kiểm thử độc lập Trong xUnit Test Patterns [2007], Gerard Meszaros đề cập đến điều Layer Test Pattern Ông cảnh báo rằng, cố gắng kiểm thử toàn lớp ứng dụng, phải xác minh lớp kết nối cách xác đòi hỏi kiểm thử business logic thông qua presentation layer Nếu đánh giá dựa hoàn vốn nguồn lực tự động hóa • Hãy xem xét khía cạnh rõ ràng công cụ có thúc đẩy hợp tác nhóm kỹ thuật nhóm khách hàng không • Một lý đáng để viết kiểm thử giúp hướng dẫn phát triển Nếu kết trình viết kiểm thử tự động thể hiểu biết thấu đáo yêu cầu nghiệp vụ, điều chứa payback 14.5.3 Think about Test Design and Maintenance Nghĩ kiểm thử thủ công mà bạn viết, có phải bạn không hy vọng toàn chúng tự động hóa? bạn không dễ dàng để thực hiện? Chắc chắn toàn kiểm thử tự động hóa, bắt đầu chuyển đổi kiểm thử thủ công trở nên dễ dàng để tự động Nếu nhóm có hàng chục, hàng trăm trường hợp kiểm thử cần bảo trì? công cụ không phù hợp với thay đổi tại, kiểm thử tự động đau đầu Kiểm thử đầu cuối đặc biệt khó khăn chúng có khả cần bảo trì quy tắc nghiệp vụ bị thay đổi Làm để cân nhua cầu tự động hóa chi phí? a Test Design Chọn test pattern cẩn thận Tự động hóa toàn test cases mà bạn cần, không nhiều hơn, tự động hóa chúng mức thấp Giới hạn phạm vi test case từ điều kiện kiểm thử hay quy tắc nghiệp vụ Hiểu mục tiêu kiểm thử Tránh phụ thuộc kiểm thử, phức tạp khiến chi phí bảo trì tăng lên b Consider Options Đẩy kiểm thử tự động xuống kim tự tháp bạn • Nếu kiểm thử đơn vị tích hợp đảm bảo, không cần tự động nhiều kiểm thử chức • Với việc đảm bảo kiểm thử mức thấp hơn, đủ để thực thủ công kiểm thử đầu cuối để xác minh hành vi hệ thống Sử dụng phân tích rủi ro để giúp bạn định c User Interface Giao diện người dùng cần phải kiểm thử Trong số tình huống, kiểm thử tự động GUI quan trọng Nếu phân tích rủi ro ROI hỗ trợ tự động hóa GUI, đầu tư cho Nếu bạn thực tự động hóa mức cao hơn, đừng tự động toàn đường qua hệ thống Bạn tự động toàn kiểm thử hồi quy, xem xét cân thời gian build hội tìm defects Tập trung nguồn lực vào việc đảm bảo đường quan trọng thông qua mã nguồn mức đơn vị, tích hợp chức Bạn nhận payback tốt d Strike a Balance Striking a balance nguyên tắc Agile, cảm giác bình thường Bạn cần giải pháp đủ tốt không cần hoàn hảo • Công cụ có cung cấp kết mà bạn cần không? • Nó có cung cấp thống kê đầy đủ nguồn lực mà bạn cần cho tự động hóa không? • Liệu công cụ có phù hợp với tình hình bạn không? Bạn sử dụng trước, sau tìm kiếm giải pháp thay thế, bạn cải tiến khung kiểm thử theo thời gian Bạn cần giải pháp không gia tăng technical debt cho nhóm Tìm cân “Nó tìm lỗi mà cần biết mà không chi phí nhiều cho việc trì” “Đây giải pháp tốt mà tìm thấy” 14.5.4 Choosing the Right Tools Thật tốt có nhiều công cụ giúp giải vấn đề tự động hóa Nhưng đừng nhu cầu bạn Công cụ Record/Playback có số nhược điểm, chúng thích hợp số hoàn cảnh phù hợp Bạn sử dụng cho số lý sau: Có thể Legacy code thực có kiểm thử tự động tạo công cụ đó, nhóm bạn có nhiều kinh nghiệm công cụ này, hay quản lý bạn muốn bạn sử dụng số lý Record/Playback thích hợp với Legacy systems, thiết kế theo cách khó để tạo kiểm thử đơn vị kịch kiểm thử viết lại từ đầu tốn Một số Agile team thấy giá trị từ công cụ kiểm thử thương mại hay mã nguồn mở, người khác thích phương pháp tiếp cận tùy biến Nhiều kiểm thử viên thấy giá trị từ ngôn ngữ kịch Ruby hay Shell, để tự động hóa công việc nhàm chán cần thiết, tạo liệu kiểm thử hay điều khiển công cụ khác Nếu bạn kiểm thử viên tảng lập trình mạnh mẽ, bạn nên chọn sách, tìm hướng dẫn trực tuyến, tham gia vào lớp ngôn ngữ kịch bản, thấy dễ dàng để viết kịch hữu dụng Tóm lại, bạn sử dụng nhiều công cụ khác Nhìn vào vấn đề mà bạn cố gắng giải định theo nhóm dễ dàng hiệu để lựa chọn công cụ phù hợp Dành thời gian để khám phá công cụ mới, xem chúng lấp đầy thiếu sót thay công cụ không xứng đáng Nếu nhóm bạn phát triển Agile, thực dự án hoàn toàn mới, bạn đối mặt với lựa chọn công cụ thiết lập môi trường kiểm thử Sẽ nhiều thời gian cho công cụ đánh giá, thiết lập quy trình build, thực nghiệm với phương pháp kiểm thử khác 14.6 Applying Agile Principles to Test Automation Mỗi nhóm, dự án tổ chức có tình độc đáo với thử thách tự động hóa khác Nó có văn hóa, lịch sử, nguồn lực, áp lực kinh doanh kinh nghiệm riêng Không vấn đề tình team bạn gì, bạn sử dụng nguyên tắc giá trị Agile để giúp bạn tìm giải pháp Các khái niệm lòng cam đảm, thông tin phản hồi, đơn giản, giao tiếp, cải tiến liên tục ứng phó với thay đổi quan điểm Agile – Chúng phẩm chất toàn team thành công 14.6.1 Keep It Simple Phương trâm Agile “Do the simplest thing that could possibly work” áp dụng cho kiểm thử mã nguồn Giữ thiết kế kiểm thử đơn giản, phạm vi tối thiểu, sử dụng công cụ đơn giản để làm việc Đơn giản giá trị cốt lõi Agile Tuy nhiên, đơn giản nghĩa làm điều dễ dàng Nó liên quan đến mà bạn cần làm tiến hành bước nhỏ để đạt điều Bằng cách giữ thứ đơn giản, bạn đưa lựa chọn xấu, bạn không xa trước nhận sai lầm Giống tất khía cạnh khác kiểm thử dự án phát triển agile, để theo kịp làm yêu cầu tối thiểu Sử dụng công cụ đơn giản để thực Trong kim tự tháp kiểm thử, customer-facing test dễ dàng tự động mức đơn vị, thực 14.6.2 Iterative Feedback Các lần lặp cho phép thực nghiệm phương pháp tiếp cận tự động, đánh giá kết quả, thay đổi khóa học cách nhanh chóng cần thiết Cam kết sử dụng nguồn lực vào tự động hóa cho vài lần lặp, tự phát triển khung kiểm thử, thực công cụ mã nguồn mở Sau lần lặp, tìm xem làm việc, không làm việc Hãy suy nghĩ ý tưởng khắc phục vấn đề cố gắng thực lần lặp Nếu giải pháp hợp lý, thử cách khác lần lặp Sử dụng lần lặp tạo điều kiện cho cách tiếp bước Nếu ý tưởng bạn không hợp lý, bạn nhanh chóng nhìn thấy có hội để thử khác Đừng ngại để tìm kiếm, không nên tìm kiếm giải pháp hoàn hảo, nên cố gắng thực đầy đủ nhu cầu bạn 14.6.3 Whole-Team Approach Phát triển Agile làm việc mà tự động hóa Phương pháp tiếp cận whole-team, nghĩa phạm vi rộng lớn kỹ năng, nguồn lực để tìm kiếm thực chiến lược tự động có ích Cả nhóm làm có nghĩa có nhiều khả mã nguồn thiết kế cho khả kiểm thử Lập trình viên, kiểm thử viên, thành viên khác nhóm hợp tác để kiểm thử, mang lại nhiều quan điểm kỹ cho nhóm Phương pháp Whole-team giúp vượt qua rào cản sợ hãi Biết người với kỹ kinh nghiệm khác giúp thêm cam đảm Với kiểm thử technology-facing Security hay Load Testing yêu cầu chuyên gia bên Một số công ty có đội ngũ chuyên gia sẵn sàng chia sẻ cho nhóm Ngay có sẵn nguồn lực này, Agile team phải chịu trách nhiệm cho việc đảm bảo kiểm thử thực Một số tổ chức có đội ngũ kiểm thử độc lập để kiểm thử sau Họ kiểm thử để đảm bảo phần mềm tích hợp với hệ thống khác, tiến hành kiểm thử khác Performance testing Các nhóm phát triển làm việc chặt chẽ với nhóm khác, sử dụng phản hồi từ nhiều nguồn để cải thiện thiết kế mã tạo điều kiện cho kiểm thử tự động 14.6.4 Taking the Time to Do It Right Để giải vấn đề thực giải pháp cần có thời gian Chúng ta nên giúp quản lý hiểu đủ thời gian để làm việc xác, technical debts tăng velocity giảm Thực theo hướng nhiều thời gian phía trước, tiết kiệm thời gian lâu dài Quản lý thường quan tâm đến kết sản phẩm nhanh Nếu quản lý miễn cưỡng cho nhóm thời gian thực tự động hóa, giải thích cho họ hiểu lợi ích mà mang lại Chúng ta cảm thấy áp lực giới hạn thời gian Sự cán dỗ từ việc quay lại cách làm cũ, không hoạt động hiệu Không đủ thời gian để quay lại sửa chữa Trong Planning Meeting, đưa thời gian để thực tự động hóa cần thiết Hãy làm việc với nhịp (Sustainable Pace) Hãy dành thời gian để tái cấu trúc bạn đến bạn kết thúc lộn xộn cuối Bạn có nhiều việc để làm học công cụ hay cố gắng tự động kiểm thử mới, đừng nên đa nhiệm, tìm khoảng thời gian tập trung vào Nếu business stakeholders không kiên nhẫn với nhóm Hãy giải thích với họ • Các rủi ro xảy gì? • Mất chi phí cho vấn đề sản phẩm? • Lợi ích việc phát hành quick hack gì? • Nó technical debt thêm vào? • Thiết kế vững hỗ trợ cho kiểm thử tự động? • Phương pháp tiếp cận ảnh hưởng đến lợi nhuận công ty hài lòng khách hàng nào? • Những chi phí vô hình, làm việc với chất lượng ảnh hưởng đến tinh thần nhóm nào? 14.6.5 Learn by Doing Mọi người học theo nhiều cách khác nhau, bạn định cách tự động kiểm thử nào, bắt đầu thực In Everyday Scripting with Ruby for Teams, Testers, and You [2007], Brian Marick khuyên bạn nên tìm hiểu chương trình cách viết Tạo mistakes, bạn học nhiều Hãy cặp với người đó, giúp bạn tăng tốc trình học Nếu bạn để cặp cùng, nói “Rubber ducky”: Hãy tưởng tượng bạn mô tả vấn đề với đồng nghiệp Đơn giản đọc lớn kiểm thử, giúp bạn tìm điểm yếu 14.6.6 Apply Agile Coding Practices to Tests Các kiểm thử có giá trị mã nguồn sản phẩm Hãy đối xử với kiểm thử theo cách bạn đối xử với toàn mã nguồn Giữ công cụ kiểm soát mã nguồn với mã sản phẩm, bạn xác định phiên kịch kiểm thử phiên mã nguồn riêng biệt Ghép nối, tái cấu trúc, thiết kế đơn giản, thiết kế module, hướng đối tượng, tiêu chuẩn, giữ kiểm thử độc lập - Chất lượng mã nguồn tốt chất lượng kiểm thử tự động tốt Kiểm thử tự động nỗ lực nhóm Kinh nghiệm, kỹ thay đổi, hoàn cảnh thành viên nhóm khác làm việc để đưa phương pháp tốt để tự động hóa Đổi - sáng tạo 14.7 Supplying Data for Tests Không vấn đề công cụ sử dụng để tự động kiểm thử gì, kiểm thử cần liệu để xử lý Lý tưởng nhất, liệu phù hợp với liệu sản phẩm Tuy nhiên, sở liệu sản phẩm chứa nhiều, nhiều liệu, chúng có độ phức tạp cao Ngoài ra, truy cập sở liệu làm chậm kiểm thử theo cấp số nhân 14.7.1 Data Generation Tools Có vài công cụ sinh liệu kiểm thử cho toàn trường đầu vào điều kiện biên Các công cụ mã nguồn mở thương mại Data Generator, databene benerator, testgen, Datatect, Turbo Data tạo tập tin rõ ràng hay tạo liệu trực tiếp từ bảng liệu Các công cụ sinh lượng lớn kiểu liệu khác tên địa Nó dễ dàng để sinh liệu kiểm thử với kịch tự viết, cách sử dụng ngôn ngữ kịch Ruby hay Python, công cụ Fit FitNesse, hay shell script Các kịch công cụ để sinh liệu kiểm thử phức tạp Ví dụ, PerlClip sinh văn vào clipboard Windows để paste vào nơi cần thiết 14.7.2 Avoid Database Access Lựa chọn để kiểm thử nên cố gắng để kiểm thử chạy nhớ (in-memory) Truy cập sở liệu có nghĩa I/O đĩa vốn chậm Mỗi đọc sở liệu làm trình chạy kiểm thử bạn Nếu mục tiêu bạn đưa phản hồi nhanh chóng, bạn muốn kiểm thử chạy nhanh Một fake object sở liệu nhớ giúp kiểm thử thực cần làm đưa phản hồi Truy cập sở liệu góp phần lớn làm chậm kiểm thử Hãy thực bước nhỏ để giả sở liệu nơi bạn có thể, tạo kiểm thử không liên quan đến sở liệu nhiều tốt Nếu khó, đánh giá lại kiến trúc hệ thống, tổ chức cho kiểm thử tốt Nếu kiểm thử logic nghiệp vụ, thuật toán, phép tính mã, bạn thấy kịch mã nguồn không cần quan tâm liệu đến từ đâu cho kết định Hãy xây dựng liệu kiểm thử phần kiểm thử truy cập từ nhớ Mô truy cập sở liệu đối tượng, tập trung vào mục đích kiểm thử Không kiểm thử chạy nhanh hơn, mà chúng viết bảo trì dễ dàng Khi tạo liệu cho kiểm thử, sử dụng giá trị phản ánh mục đích kiểm thử Trừ phi, bạn hoàn toàn tin kiểm thử độc lập tạo giá trị cho kiểm thử Khi bạn cần lượng lớn liệu, cố gắng tạo liệu ngẫu nhiên, gỡ bỏ cuối kiểm thử Đôi khi, kiểm thử cần loại liệu đặc biệt, liệu ngẫu nhiên làm hỏng mục đích kiểm thử, nên sử dụng ngẫu nhiên cho kiểm thử có đầu vào độc 14.7.3 When Database Access Is Unavoidable or Even Desirable Nếu hệ thống kiểm thử chủ yếu dựa sở liệu Nếu mã nguồn kiểm thử đọc and/or vào sở liệu, bạn muốn có vài kiểm thử hồi quy để xác minh lớp sở liệu mã nguồn a Setup/Teardown Data for Each Test Phương pháp ưa thích kiểm thử thêm liệu cần thiết đến đồ hình kiểm thử, hoạt động liệu đó, xác minh kết sở liệu, sau xóa toàn liệu kiểm thử để kiểm thử chạy lại mà không ảnh hưởng đến kiểm thử b Canonical Data Một thay đổi khác có giản đồ kiểm thử làm nhanh chóng với liệu từ Canonical Seed database Lý tưởng seed data mẫu đại điện liệu sản phẩm thực tế Bởi lượng nhỏ liệu, xây dựng lại nhanh chóng có kiểm thử hồi quy cần chạy Phương pháp làm tăng thời gian cần để chạy kiểm thử, vài phút từ lúc bắt đầu hồi quy Các kiểm thử chậm kiểm thử không truy cập sở liệu, chúng nhanh kiểm thử phải truy cập vào hàng bảng Canonical data có nhiều công dụng Các kiểm thử viên lập trình viên có giản đồ kiểm thử riêng để làm theo ý muốn Họ thực với hai kiểm thử tự động thủ công mà không cần bước vào kiểm thử Nếu liệu lựa chọn cẩn thận, liệu thực tế so với số lượng liệu hạn chế kiểm thử build Tất nhiên, có nhược điểm Canonical data khó nâng cao Khi bạn cần kịch kiểm thử mới, bạn phải xác định liệu sản phẩm, tạo liệu bạn cần thêm seed schema Mỗi lần bạn thêm bảng hay cột vào sở liệu sản phẩm, bạn nên cập nhật lại giản đồ kiểm thử cho phù hợp Bạn phải lựa chọn cẩn thận bảng cần làm bảng không cần làm mới, bảng tra cứu Nếu bạn phải thêm liệu để tăng độ bao phủ kiểm thử, làm nhiều thời gian, tăng thời gian trình tạo Điều quan trọng build tự động cung cấp phản hồi cách kịp thời, sở liệu làm kéo dài chu kỳ phản hồi bạn Bạn không độc lập kiểm thử với Canonical data, kiểm thử thất bại, khác c Production-Like Data Khả kiểm thử hệ thống giống với sản phẩm quan trọng với hầu hết nhóm phát triển phần mềm Stress, Performance, Load testing tự động chuyên sâu, cần môi trường mô gần giống sản phẩm để cung cấp kết chuyển đến hoạt động thực tế Usability, Security Reliability ví dụ kiểm thử cần production-like system, chúng không liên quan nhiều đến tự động hóa Luôn có cân (trade-off); sở liệu sản phẩm bạn lớn, đắt chậm, cung cấp liệu kiểm thử xác d Data Migration Data Migration phải kiểm thử sở liệu thực tế Các kịch nâng cấp sở liệu cần phải chạy liệu thực tế tiến hành release cuối giản đồ sở liệu 14.7.4 Understand Your Needs Hiểu mục đích kiểm thử, bạn đánh giá thứ bạn cần tốt Khi bạn cần mô môi trường sản phẩm thực tế, tạo toàn sở liệu cần thiết Phản hồi nhanh chóng mục tiêu, cân kịch kiểm thử thực tế với việc tìm defects hiệu 14.8 Evaluation Automation Tools Bước việc lựa chọn công cụ tự động tạo danh sách công cụ cần thiết cho bạn Hãy xem xét bạn định yêu cầu công cụ kiểm thử bạn nào? 14.8.1 Identifying Requirements for your Automation Tool Sau định dựa thách thức tự động cần giải quyết, nghĩ nhu cầu công cụ bạn • Bạn có công cụ nào? Nếu bạn cần bổ sung, bạn muốn tích hợp kiểm thử sở hạ tầng phát triển Bạn cần công cụ dễ dàng tích hợp vào trình build liên tục? Phần cứng bạn có hộ trợ tự động hóa không? Thiết lập trình build thứ hai để chạy kiểm thử chức cần máy móc bổ sung • Ai sử dụng công cụ kiểm thử? Không lập trình viên viết test cases? Các lập trình viên muốn có công cụ phù hợp? Bạn liên hệ với thành viên cần hợp tác chưa? • Ai tự động hóa trì kiểm thử? Các kỹ nhóm bạn quan trọng Mất thời gian để bạn cài đặt công cụ học làm để sử dụng nó? Những thành viên nhóm có kinh nghiệm với công cụ cụ thể không? Có nhóm kiểm thử riêng biệt có chuyên môn công cụ không? Nếu bạn bắt đầu trình chuyển đổi sang phát triển Agile, bạn nên có nhóm kiểm thử tự động, tận dụng chuyên môn tiếp tục sử dụng công cụ mà họ biết Các yêu cầu công cụ bạn phụ thuộc vào môi trường phát triển • Nếu bạn kiểm thử ứng dụng Web, công cụ bạn chọn không hỗ trợ SSL hay AJAX, bạn gặp vấn đề • Không phải công cụ kiểm thử kiểm thử ứng dụng dịch vụ web Kiểm thử hệ thống nhúng cần công cụ khác Tất nhiên, loại kiểm thử tự động chìa khóa • Security testing cần công cụ chuyên môn cao • Có nhiều công cụ mã nguồn mở nhà công cụ cho performance, việc lựa chọn khó khăn • Ví dụ, đưa cho nhóm Lisa vài năm để phát triển kiểm thử hồi quy mạnh mẽ mức đơn vị, tích hợp chức Performance testing phạm vi đau đầu họ Bài học kinh nghiệm từ nguồn lực tự động hóa trước giúp họ làm việc tốt việc xác định yêu cầu cho công cụ kiểm thử, chẳng hạn dễ dàng để báo cáo kết quả, khả tương thích với khung làm việc ngôn ngữ kịch Viết checklist liệt kê yêu cầu công cụ bạn Một số chúng xung đột mâu thuẫn với – “Công cụ cần dễ dàng để khách hàng định kiểm thử” “Các kiểm thử dễ dàng tự động hóa” 14.8.2 One Tool at a Time Bạn cần công cụ khác phục vụ cho mục đích khác Bắt đầu với công cụ nghiên cứu cách sử dụng chúng Chỉ thử công cụ thời điểm, vị trí khó khăn bạn; sau xem xét đánh giá nó; làm việc tốt, chuyển sang công cụ vị trí khó khăn Thử nhiều công cụ tốt số tình huống, công nghệ đòi hỏi quan tâm đầy đủ Khi định công cụ để giải yêu cầu đặc biệt, xem thử thách gì? công cụ lựa chọn cho thể đáp ứng nhu cầu không, hay bắt đầu trình lựa chọn khác? Nếu bạn định nhìn tổ chức bạn cho công cụ, bước tìm thời gian để thử số bên Bắt đầu với số tìm kiếm: Các tìm kiếm Internet, báo ấn phẩm khác công cụ, danh sách mailing nơi tốt để đưa ý tưởng Biên soạn danh sách công cụ để xem xét Nếu nhóm bạn sử dụng wiki diễn đàn trực tuyến (online forum), gửi thông tin công cụ bắt đầu thảo luận ưu nhược điểm Ngân sách thời gian cho việc đánh giá công cụ Khi bạn có danh sách công cụ đáp ứng yêu cầu bạn, thu hẹp khả xuống hai, tìm hiểu làm để sử dụng người đủ để cố gắng làm vài mũi nhọn: Thử kịch đơn giản đại diện thứ bạn vứt bỏ Đánh giá kết so với yêu cầu Sử dụng retrospectves để xem xét ưu nhược điểm Chọn ứng viên hàng đầu bạn cam kết cố gắng khoảng thời gian – đủ dài để thấy khả Trong Retrospectives, nhìn vào làm không làm Cởi mở ý tưởng không bạn phải bỏ bắt đầu lại Đừng cảm thấy bạn phải tiếp tục với công cụ bạn đầu tư nhiều vào 14.8.3 Choosing Tools Có phạm vi rộng lớn phát triển công cụ để chọn từ: home-grown, mã nguồn mở, công cụ nhà cung cấp, kết hợp bất kỳ, tất lựa chọn thay khả thi Tìm thời gian để thử công cụ để xem chúng có phù hợp với yêu cầu bạn Nó khó khăn để đánh giá ROI cho giải pháp, cách tiếp cận lặp để đánh giá chúng giúp có hướng a Should You Grow Your Own Ứng dụng bạn có thách thức kiểm thử độc đáo Nhóm có kỹ năng, thời gian xu hướng viết khung kiểm thử riêng xây dựng dựa công cụ mã nguồn mở công cụ home-grown phù hợp Trong phát triển Agile, nhiều lập trình viên có hiểu biết kiểm thử, có nhiều công cụ ngôn ngữ làm cho khung kiểm thử dễ dàng Nếu nhóm bạn viết khung làm việc tự động riêng cho nó, chúng tùy chỉnh xác với nhu cầu nhóm khách hàng nhóm phát triển bạn, tích hợp với trình build sở hạ tầng khác – bạn làm cho chúng dễ dàng để thực thi giải thích kết bạn cần .Home-grown nghĩa miễn phí Một tổ chức lớn với yêu cầu đặc biệt đật nhóm chuyên gia tự động, người hợp tác với kiểm thử viên, khách hàng, lập trình viên người khác Nếu yêu cầu bạn đặc biệt mà không công cụ hỗ trợ chúng, home-grown lựa chọn bạn b Open Source Tools Bởi công cụ viết lập trình viên thích kiểm thử (test-infected) mà nhu cầu không đáp ứng công cụ nhà cung cấp, chúng thường nhẹ thích hợp với phát triển Agile Nhiều công cụ phát triển cho test-first, bạn tải kiểm thử với mã nguồn, tạo tùy biến dễ dàng an toàn Không phải toàn công cụ mã nguồn mở có tài liệu tốt đào tạo vấn đề Tuy nhiên, thấy hội thảo (seminars) hướng dẫn (tutorials) cách sử dụng công cụ nhiều hội nghị họp nhóm người sử dụng Một số công cụ mã nguồn mở có hướng dẫn sử dụng tuyệt vời chí có hướng dẫn trực tuyến lớp học theo lịch trình có sẵn c Vendor Tools Các công cụ thương mại coi vụ đánh cược an toàn Nó khó để trích để lựa chọn công cụ tiếng năm Họ cung cấp tài liệu, hỗ trợ đào tạo Cho kiểm thử viên hay người dùng khác thiếu tảng kỹ thuật, dốc ban đầu lên nhanh Một số mạnh giàu tính nâng Công ty bạn sở hữu có đội ngũ chuyên gia biết sử dụng Mặc dù chúng thay đổi theo thời gian, công cụ nhà cung cấp có lịch sử không thân thiện với lập trình viên Chúng có xu hướng sử dụng ngôn ngữ kịch độc quyền mà lập trình viên không muốn dùng thời gian để học Chúng nặng Các kịch kiểm thử trở nên mỏng manh, dễ bị phá vỡ thay đổi nhỏ ứng dụng, tốn để trì Hầu hết công cụ ghi lại kịch để phát lại sau Các kịch record/playback có tiếng tốn từ góc độ bảo trì 14.8.4 Agile-Friendly Tools Elisabeth Hendrickson [2008] liệt kê số đặc điểm công cụ kiểm thử tự động Agile hiệu Những công cụ sẽ: • Hỗ trợ lực kiểm thử tự động lập tức, cách sử dụng phương pháp test-first • Tách chất kiểm thử từ chi tiết thực • Hỗ trợ khuyến khích thực hành lập trình tốt cho phần mã kiểm thử tự • • động Hỗ trợ viết mã nguồn kiểm thử tự động cách sử dụng ngôn ngữ thực sự, với IDEs thực Kích lệ hợp tác 14.9 Implementing Automation Trong bạn đánh giá công cụ, suy nghĩ yêu cầu tự động ưu tiên hàng đầu bạn nhanh chóng giải Bạn nhận hỗ trợ từ đâu để giúp hoàn thành nó? Nhóm cần đào tạo lâu để thực nó? Bạn phải đẩy nhanh công cụ nào? Bạn xây dựng nguồn lực tự động hóa bạn theo bước Nhiều nhóm trải qua nỗ lực không thành công trước tìm thấy kết hợp xác công cụ, kỹ sở hạ tầng Thiết kế hướng đối tượng tốt chìa khóa để xây dựng kiểm thử tự động Bạn cần chạy kiểm thử thường xuyên đủ để lấy phản hồi mà nhóm bạn cần Các công cụ lựa chọn phải làm việc tảng chúng tôi, phải chia sẻ chơi tốt với công cụ khác Cần giữ môi trường kiểm thử độc lập, không bị ảnh hưởng thay đổi lập trình viên Xây dựng sở hạ tầng kiểm thử dự án lớn, điều mà nhóm Agile cần phải làm để nhảy vào tự động kiểm thử Phần cứng, phần mềm công cụ cần phải xác định thực Phụ thuộc vào tài nguyên công ty bạn, dự án dài hạn 14.10 Managing Automated Tests Chúng ta cần cách để tìm kiểm thử xác minh kịch cụ thể, để hiểu kiểm thử thực để biết xác phần ứng dụng Các kiểm thử tự động cần phải trì kiểm soát theo hướng tương tự mã nguồn sản phẩm Khi bạn đánh dấu mã nguồn sản phẩm bạn cho việc phát hành, kiểm thử xác minh chức cần phải phần thẻ 14.10.1 Organizing Tests Quản lý kiểm thử giúp team bạn trả lời câu hỏi sau: • Các tình kiểm thử tự động? • Trường hợp cần tự động? • Kiểm thử chạy phần hồi quy? • Kiểm thử bao phủ vùng chức nâng gì? • • • Tính XYZ thiết kế để làm việc nào? Ai người viết trường hợp kiểm thử này? Khi nào? Ai người thay đổi cuối cùng? Bao lâu kiểm thử phần hồi quy? Bởi lý mà viết kiểm thử để hướng dẫn phát triển, cần phải tổ chức kiểm thử cho người nhóm tìm thấy kiểm thử thích hợp cho story dễ dàng xác minh kiểm thử bao phủ chức Khi kiểm thử thất bại (fail), bạn cần xác minh vấn đề nhanh chóng Bạn cần biết thay đổi thực gần đến kịch kiểm thử, dễ dàng với lịch sử có sẵn hệ thống kiểm soát mã nguồn Các hệ thống quản lý kiểm thử, giống kiểm thử, nên khuyến khích giao tiếp hợp tác thành viên nhóm team khác 14.10.2 Organizing Test Results Mọi người liên quan đến việc cung cấp phần mềm cần dễ dàng truy cập đến kiểm thử kết kiểm thử Một khía cạnh khác quản lý kiểm thử theo dõi kiểm thử từ lần lặp trước phải vượt qua, so với kiểm thử điều hướng phát triển lần lặp không thông qua Một tích hợp liên tục quy trình build chạy kiểm thử thông tin phản hồi nhanh chóng tiến độ bắt lỗi hồi quy (failures) Hình cho thấy ví dụ báo cáo kết kiểm thử, dễ hiểu nháy Một kiểm thử thất bại, nguyên nhân lỗi nêu rõ Với công cụ kiểm thử tự động nào, bạn giải vấn đề quản lý kiểm thử với hệ thống home-grown, mã nguồn mở, hay thương mại Quản lý kiểm thử khu vực khác nơi mà giá trị nguyên tắc Agile với phương pháp toàn team (whole-team) áp dụng Bắt đầu đơn giản, thử nghiệm bước nhỏ bạn tìm thấy kết hợp kiểm soát mã nguồn, kho lưu trữ quản lý build mà giữ kiểm thử mã nguồn đồng Đánh giá phương pháp quản lý kiểm thử bạn thường xuyên, chắn chứa tất người sử dụng kiểm thử khác Xác định làm việc, bị thiếu sót, có kế hoạch công việc stories để thử công cụ khác hay quy trình để điền khoảng chống Hãy nhớ nên giữ quản lý kiểm thử nhẹ dễ trì để người sử dụng 14.11 Go Get Started Yếu tố quan trọng thành công cần bắt đầu Như với nhiều khía cạnh Agile Testing, cải tiến bước nhỏ chìa khóa để thành công Summary Trong chương này, xem xét làm để sử dụng giá trị, nguyên tắc, thực hành Agile để phát triển chiến lược tự động hóa Chúng thảo luận theo chủ đề liên quan đến tự động sau: • Sử dụng agile testing quadrants để xác định nơi bạn cần kiểm thử bạn cần • Test automation pyramid giúp nhóm tạo khoản đầu tư xác vào tự động hóa • Áp dụng giá trị, nguyên tắc thực hành Agile giúp nhóm bạn đẩy mạnh kiểm thử hóa • Các việc lặp lặp lại, tích hợp liên tục quy trình build, unit tests, functional tests, load tests data creation toàn ứng viên tốt tự động hóa • Các kiểm thử Quadrant Usability testing Exploratory testing hưởng lợi từ số tự động thiết lập kịch kiểm thử, phân tích kết quả; Nhưng người, tư phê phán quan sát tự động • Đơn giản, tiếp cận toàn nhóm, sử dụng phản hồi lặp dùng đủ thời gian giúp bạn bắt đầu giải pháp tốt • Khi phát triển chiến lược tự động, bắt đầu tạo vùng “đau” lớn nhất, xem xét multi-layered approach cố gắng tiếp tục xem lại, cải tiến chiến lược bạn đạt hoàn hảo từ đầu • Xem xét rủi ro ROI định tự động • Danh thời gian để vừa học vừa làm; áp dụng thực hành Agile coding để kiểm thử • Quyết định bạn build vào nhớ trong, hay bạn cần production-style data sở liệu • Cung cấp liệu kiểm thử cho phép kiểm thử độc lập, chạy lại nhanh • Sử dụng công cụ cần thiết thời điểm, xác định yêu cầu, định kiểu công cụ chọn hay build phù hợp với nhu cầu bạn • Sử dụng thực hành phát triển tốt cho kiểm thử tự động, dành thời gian cho thiết kết kiểm thử • Các công cụ kiểm thử cần phù hợp với sở hạ tần phát triển nhóm • Version-control tự động kiểm thử với mã nguồn sản phẩm mà chúng xác minh • Quản lý kiểm thử tốt đảm bảo kiểm thử cung cấp tài liệu hướng dẫn hệ thống quy trình phát triển hiệu • Hãy bắt đầu kiểm tử tự động hôm [...]... khía cạnh của Agile Testing, cải tiến từng bước nhỏ là chìa khóa để thành công Summary Trong chương này, chúng tôi xem xét làm thế nào để sử dụng các giá trị, nguyên tắc, thực hành Agile để phát triển chiến lược tự động hóa Chúng tôi đã thảo luận theo các chủ đề liên quan đến tự động như sau: • Sử dụng agile testing quadrants để xác định nơi bạn cần kiểm thử và khi nào bạn cần nó • Test automation pyramid... bỏ lỡ một vài vấn đề trực quan ngoài khả năng của con người 14.3.2 Exploratory Testing Tương tự như vậy, Exploratory Testing có thể tăng tốc với các kịch bản tạo dữ liệu kiểm thử, và bỏ qua một số bước thiết lập, nhưng nó yêu cầu một kiểm thử viên có kỹ năng thiết kế và thực thi kiểm thử Mục tiêu chính của Exploratory Testing là tìm hiểu thêm về sản phẩm làm ra và sau đó sử dụng thông tin đó để cải... mã nguồn mà họ đã thay đổi Một GUI smoke test cho các chức năng quan trọng của Legacy system không có kiểm thử đơn vị 14.5 Developing an Automation Strategy - Where Do We Start? Đơn giản, tiếp cận từng bước một thích hợp với chiến lược tự động hóa Nhưng trong Agile Testing, quyết định bắt đầu tự động từ đâu và như thế nào đòi hỏi suy nghĩ và thảo luận toàn nhóm Khi nhóm nhìn vào các thách thức kiểm... các công cụ không xứng đáng Nếu nhóm của bạn mới phát triển Agile, hoặc đang thực hiện dự án hoàn toàn mới, bạn sẽ đối mặt với lựa chọn công cụ và thiết lập môi trường kiểm thử Sẽ mất nhiều thời gian cho các công cụ đánh giá, thiết lập quy trình build, thực nghiệm với các phương pháp kiểm thử khác nhau 14.6 Applying Agile Principles to Test Automation Mỗi nhóm, mỗi dự án và mỗi tổ chức có một tình... của team bạn là gì, bạn có thể sử dụng các nguyên tắc và giá trị Agile để giúp bạn tìm ra giải pháp Các khái niệm như lòng cam đảm, thông tin phản hồi, đơn giản, giao tiếp, cải tiến liên tục và ứng phó với thay đổi thì không phải quan điểm của Agile – Chúng là phẩm chất của toàn bộ các team thành công 14.6.1 Keep It Simple Phương trâm Agile “Do the simplest thing that could possibly work” áp dụng cho... 14.3 What Shouldn’t We Automate? Một số kiểm thử cần ánh mắt, tai nghe và trí thông minh của con người Usability và Exploratory Testing là hai loại đó Những kiểm thử không cần đầu tư tự động hóa như kiểm thử một lần hoặc không bao giờ lỗi 14.3.1 Usability Testing Usability Testing đòi hỏi một người nào đó sử dụng thực sự phần mềm Tự động hóa chỉ hữu dụng trong việc thiết lập các kịch bản kiểm thử ... xác vào tự động hóa • Áp dụng các giá trị, nguyên tắc và thực hành Agile giúp nhóm bạn đẩy mạnh kiểm thử hóa • Các việc lặp đi lặp lại, tích hợp liên tục và các quy trình build, unit tests, functional tests, load tests và data creation là toàn bộ ứng viên tốt của tự động hóa • Các kiểm thử Quadrant 3 như Usability testing và Exploratory testing được hưởng lợi từ một số tự động như thiết lập các kịch bản... kịch bản kiểm thử thực tế với việc tìm defects hiệu quả nhất có thể 14.8 Evaluation Automation Tools Bước đầu tiên trong việc lựa chọn công cụ tự động là tạo danh sách các công cụ cần thiết cho bạn Hãy xem xét bạn có thể quyết định trên các yêu cầu công cụ kiểm thử của bạn thế nào? 14.8.1 Identifying Requirements for your Automation Tool Sau khi quyết định dựa trên thách thức tự động tiếp theo cần giải... nhiên, loại kiểm thử đang tự động cũng là chìa khóa • Security testing cần các công cụ chuyên môn cao • Có nhiều công cụ mã nguồn mở và của nhà công cụ cho performance, vì vậy việc lựa chọn không phải khó khăn • Ví dụ, đưa cho nhóm của Lisa một vài năm để phát triển các bộ kiểm thử hồi quy mạnh mẽ ở mức đơn vị, tích hợp và chức năng Performance testing vẫn là phạm vi đau đầu của họ Bài học kinh nghiệm từ... kém để duy trì Hầu hết các công cụ này ghi lại kịch bản để phát lại sau đó Các kịch bản record/playback có tiếng là tốn kém từ góc độ bảo trì 14.8.4 Agile- Friendly Tools Elisabeth Hendrickson [2008] liệt kê một số đặc điểm của các công cụ kiểm thử tự động Agile hiệu quả Những công cụ này sẽ: • Hỗ trợ bắt đầu từ những năng lực kiểm thử tự động ngay lập tức, bằng cách sử dụng phương pháp test-first • Tách