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.
Trang 1Có nhiều lý do để tự động hóa để áp dụng Agile thành công:
• 1 Kiểm thử thủ công mất nhiều thời gian
• 2 Các quy trình thủ công dễ gây lỗi
• 3 Tự động hóa giúp bạn làm việc tốt nhất có thể
• 4 Kiểm thử hồi quy tự động cung cấp mạng lưới an toàn
• 5 Kiểm thử tự động cung cấp phản hồi sớm và thường xuyên
• 6 Các kiểm thử và ví dụ làm cho việc viết mã dễ dàng và nhiều hơn
• 7 Kiểm thử cung cấp tài liệu hướng dẫn
• 8 Tự động mang lại lợi nhuận
13.1.1 Manual testing takes too long
Lý do cơ bản nhất mà nhóm muốn tự động hóa là 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, có thể theo cấp
số nhân, phụ thuộc vào sự phức tạp của AUT (Application Under Test)
Agile teams thường release sản phẩm vào cuối mỗi lần lặp, vì vậy việc chạy các kiểm thử hồi quy là cần thiết Nếu thực hiện kiểm thử hồi quy thủ công nó sẽ mất nhiều thời gian, để kiểm thử kịp với việc viết mã, các lập trình viên phải giúp kiểm thử hoặc phải thuê thêm kiểm thử viên Chắc chắn nợ kỹ thuật và khả năng thất bại sẽ tăng lên
Nếu nhóm không thực hiện kiểm thử hồi quy mức đơn vị, kiểm thử viên sẽ mất nhiều thời gian để nghiên cứu, tái hiện và báo cáo lỗi; nó làm giảm thời gian tìm lỗi nghiêm trọng của hệ thống Ngoài ra, nếu nhóm không thực hiện kiểm thử test-first, thiết kế mã không được kiểm chứng và có thể không cung cấp các chức năng như mong muốn của doanh nghiệp
Kiểm thử thủ công các kịch bản khác nhau có thể chiếm nhiều thời gian, đặc biệt là giao diện người dùng Thiết lập dữ liệu cho một chuỗi các kịch bản phức tạp là một việc quá sức nếu không được tự động hóa Nó có thể làm giới hạn kịch bản kiểm thử và thiếu sót các defects
Trang 213.1.2 Manual Processes Are Error Prone
Kiểm thử thủ công được lặp đi lặp lại, làm cho kiểm thử viên dễ nhàm chán và dễ tạo
ra những sai lầm (mistakes) và bỏ qua lỗi đơn giản Đặc biệt, nếu nhóm bị giới hạn về thời gian, nó dễ gây áp lực và dẫn đến việc bỏ qua một số trường hợp kiểm thử
Tự động quá trình xây dựng, triển khai, kiểm soát phiên bản, giám sát cũng hướng tới giảm thiểu rủi ro và làm cho quy trình phát triển nhất quán hơn Các kiểm thử tự động cũng giới hạn khả năng lỗi (errors), bởi mỗi kiểm thử sẽ được thực hiện chính xác theo cùng một cách ở bất cứ thời điểm nào
Quy trình tự động xây dựng và triển khai cho phép bạn biết chính xác bạn đang kiểm thử cái gì trên môi trường nào
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 được yêu cầu và thiết kế mã phù hợp Tự động kiểm thử đơn vị và kiểm thử hồi quy chức năng sẽ 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 hiện các kịch bản nhàm chán, tăng thời gian để nghĩ về các kịch bản khác, học hỏi thêm về cách ứng dụng hoạt động, … Tự động kiểm thử hồi quy giúp phát hiện ra những thay đổi đối với chức năng hiện tại
và cung cấp phản hồi ngay lập tức là mục tiêu chính của phần này
13.1.4 Automated Regression Tests Provide a Safe Net
Hầu hết những người có chuyên môn trong kinh doanh phần mềm đều cảm thấy sợ hãi khi phải đối mặt với việc sửa lỗi, hay hoàn thành một tính năng mới với mã nguồn được thiết kế nghèo nàn và không được bao phủ bởi các kiểm thử tự động
Nếu mã nguồn được bao phủ bởi các kiểm thử tự động sẽ giúp họ tự tin hơn Chắc chắn, sự thay đổi có thể tạo ảnh hưởng không mong muốn, nhưng nó sẽ bị phát hiện trong vài phút nếu nó ở mức đơn vị, hoặc vài giờ nếu nó ở mức chức năng Tạo thay đổi
ở test-first, có nghĩa thay đổi hành vi trước khi viết mã và viết kiểm thử để xác minh nó,
sẽ làm tăng niềm tin đó
Nhóm có bộ kiểm thử hồi quy tự động tốt sẽ không sợ việc thay đổi mã nguồn Các kiểm thử sẽ cho họ thấy bất cứ điều gì bị ảnh hưởng Họ có thể đi nhanh hơn nhóm dựavào kiểm thử thủ công
13.1.5 Automated Tests Give Feedback, Early, and Often
Chạy kiểm thử tự động mỗi khi có mã nguồn mới giúp đảm bảo các lỗi (bugs) hồi quy
sẽ bị nắm bắt nhanh chóng
Nếu kiểm thử hồi quy không được tự động, nó sẽ không chạy ở mỗi lần lặp Lỗi hồi quy có thể xảy ra vào cuối sản phẩm, nhiều lợi ích từ việc kiểm thử sớm sẽ bị mất đi Các kiểm thử tự động chạy thường xuyên và hoạt động như thiết bị phát hiện thay đổi Chúng cho biết những gì thay đổi kể từ lần build gần nhất Nếu bộ tự động có đủ độ baophủ, nó sẽ dễ dàng nói ra những ảnh hưởng sâu rộng mà các kiểm thử viên không thể tìm thấy
Trang 313.1.6 Tests and Examples that Drive Coding Can Do More
Trong chapter 7, “Technology-Facing Tests that Support the Team”, đã nói về việc sử
dụng kiểm thử và ví dụ để điều hướng việc viết mã Cũng như đã đề cập đến tầm quan trọng của việc điều hướng mã như thế nào đối với kiểm thử đơn vị và kiểm thử của khách hàng Cũng nhấn mạnh nếu kiểm thử đó được tự động, chúng trở nên có giá trị,
và trở thành cơ sở cho một bộ hồi quy vô cùng mạnh.
TDD (Test-Driven Development hay Test-Driven Design) và SDD (Story test-Driven Development) làm cho nhóm nghĩ về test-first Họ thiết kế mã để các kiểm thử có thể pass, vì vậy khả năng kiểm thử không bao giờ là vấn đề Kiểm thử tự động phát triển cùng với mã nguồn cơ 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 là toàn nhóm (Whole-team) thực hành TDD và luôn viết Unit test
Nợ kỹ thuật (Technical debt) giảm, tốc độ (velocity) ổn định và tăng theo thời gian là một trong những lý do các nhà quản lý luôn vui vẻ để nhóm phần mềm dành thời gian hoàn thành các thực hành một cách chính xác
13.1.7 Tests Are Great Documentation
Khi các kiểm thử minh họa ví dụ của hành vi mong muốn được 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 như thế nào
Khi hệ thống thay đổi, chúng ta cần cập nhật lại các kiểm thử tự động, nếu không chúng sẽ bị fail Điều này có nghĩa kiểm thử tự động luôn là bức tranh chính xác cho thấy mã nguồn hiện tại làm việc như thế nào
13.1.8 ROI and Payback
Tự động có nghĩa thêm thời gian cho kiểm thử viên và các thành viên nhóm tập trung vào việc tạo ra sản phẩm chất lượng ra ngoài thị trường một cách kịp thời
Khi các lập trình viên chạy kiểm thử tự động trong môi trường riêng của họ, các kiểm thử hồi quy tự động tìm thấy lỗi trước khi mã nguồn được check-in, do đó có nhiều thời gian để sửa chữa thiết kế Đó là cách giảm nợ kỹ thuật và phát triển mã nguồn vững chắc
13.2 Barriers to Automation - Things that Get in the Way
Vào năm 2001, Bret Pettichord đã liệt kê 7 vấn đề cản trở tự động hóa Chúng vẫn được áp dụng, nhưng dành cho nhóm không kết hợp tự động hóa vào quá trình phát triển của họ
13.2.1 Bret’s List
Danh sách các vấn đề tự động của Bret như 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 thế cao, bởi bạn bị mất bất kỳ kinh nghiệm nào mà bạn có thể có
• Phản ứng tiêu cực là nguyên nhân tại sao tự động hóa được chọn để mang lại
hy vọng hơn là đề nghị thực tế
Trang 4• Miễn cưỡng nghĩ về kiểm thử trong tự động hóa.
• Tập trung vào giải quyết vấn đề công nghệ có thể làm bạn mất khả năng quan sát cho dù kết quả 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 các nhóm Agile và các team khác:
• Thái độ của lập trình viên
• “Hump of Pain” (Sự gồ ghề của nỗi đau)
• Đầu tư ban đầu
• Mã nguồn luô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 trong môi trường truyền thống, có một số khác biệt, QA hầu như thực hiện toàn bộ kiểm thử Một số lập trình viên không quan tâm đến kiểm thử bởi
họ có nhóm QA bắt lỗi trước khi release Theo thời gian, kiểm thử viên làm công việc của họ, lập trình viên sẽ chuyển sang release tiếp theo Các defects đưa vào hàng đợi
để sửa chữa với chi phí rất lớn, và không ai chịu trách nhiệm tạo ra chúng
Ngay cả các lập trình viên đã thực hiện TDD (Test-Driven Development) và tự động kiểm thử đơn vị vẫn không nghĩ cách kiểm thử chấp nhận
Giáo dục là chìa khóa để các lập trình viên và nhóm hiểu được tầm quan trọng của 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 như thế nào để tạo ra lợi nhuận tốt về đầu tư nguồn lực Brian Marick sử dụng một giới hạn để mô tả giai đoạn đầu của tự động hóa và các lập trình viên (và kiểm thử viên) phải vượt qua “Hump of Pain” khi áp dụng tự động hóa
Các nhóm mới thường dự kiến áp dụng TDD và Refactoring, những kỹ thuật khó để tìm hiểu Nếu không có huấn luyện tốt, sẽ mất nhiều thời gian để làm chủ kỹ năng mới
và hỗ trợ quản lý, họ dễ bị nản lòng Nếu họ có thêm trở ngại khi tìm hiểu, như phải làm việc với thiết kế nghèo nàn từ mã nguồn cũ, thì khó có thể kéo họ về kiểm thử tự động “Hump of Pain” xảy ra bởi bạn đang xây dựng khung kiểm thử dựa trên miền xác định hay học công cụ kiểm thử chức năng mới Bạn có thể nhờ một chuyên gia giúp bạn thiếtlập
Nếu team bạn không dễ dàng vượt qua “Hump”, ít nhất phải có quy trình tự nhiên và ngấm vào từng người trong nhóm
Trang 513.2.5 Initial Investment
Tự động hóa đòi hỏi một sự đầu tư lớn Nó mất thời gian và nghiên cứu để quyết định khung kiểm thử được sử dụng và liệu tự xây dựng hay sử dụng công cụ sản xuất bên ngoài Phần cứng và mềm mới có thể được yêu cầu Các thành viên trong nhóm mất một khoảng thời gian để học cách sử dụng
Nếu tổ chức có người có kinh nghiệm về kiểm thử tự động, tổ chức chỉ trả tiền cho nhàcung cấp công cụ capture-playback, đưa cho nó cho nhóm QA và mong nó giải quyết toàn bộ vấn đề tự động hóa Nhưng những kinh nghiệm ít ỏi có thể tạo ra các kiểm thử khó hiểu, khó bảo trì và không hữu dụng lâu dài Vì vậy, nhóm với đào tạo và kỹ năng đầy đủ sẽ 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 được tái cấu trúc, các kiểm thử có khả năng duy trì Thư viện các module kiểm thử và đối tượng kiểm thử được xây dựng theo thời gian và tạo các kiểm thử mới nhanh hơn
Tuy nhiên, không phải dễ dàng để nắm bắt số liệu Như, thời gian để viết và duy trì cáckiể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 trong vài phút phát hiện so với chi phí để tìm và sửa chữa sau khi kết thúc quy trình cũng khá khó Nếu không có các con số chứng minh tự động cần ít nguồnlực hơn và cung cấp nhiều giá trị hơn, nhóm sẽ khó có thể thuyết phục quản lý đầu tư vào tự động hóa, và khó để thay đổi thói quen của 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 thì khó, bởi UI thường thay đổi liên tục trong quá trình phát triển Nó cũng là lý do mà kỹ thuật record và playback khôngphải là lựa chọn tốt cho một dự án Agile
Nếu nhóm khó để tạo thiết kế tốt về logic nghiệp vụ, truy cập cơ sở dữ liệu, và thường xuyên làm lại Nó khó có thể kiểm thử tự động sau GUI ở mức API Trong trường hợp này, lập trình viên và kiểm thử viên cần làm việc với nhau để có được một ứng dụng có thể kiểm thử
Mặc dù mã nguồn và thực hiện thực tế có xu hướng thay đổi liên tục trong phát triển Agile, nhưng mục đích của mã nguồn hiếm khi thay đổi Tổ chức mã kiểm thử bằng mụcđích của ứng dụng, cho phép bạn theo kịp với sự phát triển
13.2.7 Legacy Code
Viết một vài kiểm thử cho mã nguồn hiện tại hoặc không có kiểm thử là một công việc khó khăn Nó hầu như không thể với một nhóm mới với Agile và kiểm thử tự động Nếu bạn muốn tự động các kiểm thử, bạn phải tái cấu trúc một số legacy code, nhưng legacy code không được thiết kế cho khả năng kiểm thử, vì vậy nó khó có thể tự động kiểm thử ngay cả mức đơn vị
13.2.8 Fear
Kiểm thử tự động thực sự khó với ai chưa bao giờ làm chủ nó, kể cả người đã từng sửdụng Các lập trình viên có thể viết mã sản phẩm tốt, nhưng họ không có nhiều kinh nghiệm khi viết các kiểm thử tự động Các kiểm thử viên thì không có nền tảng lập trình
Trang 6tốt, họ không tin vào kỹ năng về kiểm thử tự động của họ.
Kiểm thử viên không có kinh nghiệm lập trình thường nhận được thông điệp rằng họ không có gì để làm trong thế giới Agile Nhưng không lập trình viên nào cần lo lắng về làm thế nào để tự động hóa Nó là vấn đề của nhóm, và thường lập trình viên có thể giúp đỡ họ về mặt lập trình
13.2.9 Old Habits
Khi các lần lặp (iterations) không tiến hành thuận lợi, nhóm không thể hoàn thành toàn
bộ công việc lập trình và kiểm thử vào cuối lần lặp, các 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 về thói quen cũ, kể cả những thói quen này không mang lại kết quả tốt
Đây là con đường đi đến diệt vong Một số kiểm thử thủ công có thể hoàn thành và tìm
ra lỗi nhưng chi phí công ty tăng lên đến hàng ngàn đô la Nếu công việc kiểm thử không thể kết thúc, chúng sẽ được 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 đi lặp lại, trạng thái này tiếp tục xấu đi sau đó
13.3 Can we Overcome These Barriers?
Phương pháp tiếp cận toàn team (Whole-team) là nền tảng để vượt qua thử thách tự động hóa Các lập trình viên mới với Agile có thể cung cấp mã nguồn, cho dù có lỗi hay không, miễn họ đúng hạn TDD (Test-Driven Development) định hướng thiết kế hơn là kiểm thử, vì vậy kiểm thử business-facing phải phụ thuộc vào ý thức họ
Nó là khả năng lãnh đạo (Leadership) và cam kết (commitment) của nhóm về chất lượng để mọi người phải ý thức được việc phải viết, sử dụng và chạy các kiểm thử technology-facing và business-facing
Bắt toàn bộ nhóm tham gia vào quá trình kiểm thử tự động là một thách thức về văn hóa
• Tự động hóa các kiểm thử hồi quy, chạy chúng trong quy trình build tự động và sửa các nguyên nhân gốc của defects làm giảm nợ kỹ thuật và tăng trưởng mã vững chắc
• Tự động hóa các kiểm thử hồi quy và các việc thủ công nhàm chán giải phóng nhóm cho việc quan trọng hơn, như kiểm thử thăm dò
• Nhóm với các kiểm thử tự động và quy trình build tự động làm cho vận tốc ổn định hơn
• Không có kiểm thử hồi quy tự động, kiểm thử hồi quy thủ công sẽ tiếp tục phát
Trang 7triển trong phạm vi và cuối cùng chỉ đơn giản có thể được bỏ qua.
• Văn hóa của nhóm và lịch sử có thể làm cho nó khó khăn đối với lập trình viên
để ưu tiên tự động hóa cho kiểm thử business-facing hơn là viết mã cho các tínhnăng mới Sử dụng các nguyên tắc và giá trị Agile giúp toàn nhóm vượt qua các rào cản đối với kiểm thử tự động
Chapter 14 - An Agile Test Automation Strategy
Chương này giải thích làm thế nào để ứng dụng các giá trị và nguyên tắc Agile vào việc sử dụng và cải tiến năng 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 về mỗi quadrant và mục tiêu kiểm thử của mỗi phần đó Giờ chúng ta đi tìm hiểu khía cạnh khác của nó
Với 2 góc phần tư Q1, Q2 đã được dán nhãn có sử dụng tự động hóa Với Q4, các công cụ được sử dụng để tìm nhược điểm sản phẩm từ góc nhìn kỹ thuật, nó thường yêu cầu các 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ác công cụ có thể hữu dụng trong một số trường hợp, như, tự động giúp thiết lập dữ liệu kiểm thử, kịch bản người dùng, phân thích hoạt động đăng nhập
Sử dụng các góc phần tư giúp xác định các loại công cụ tự động hóa cần thiết trong mỗi dự án hay mỗi lần lặp
Thứ tự các góc không liên quan đến thứ tự kiểm thử Tạo checklist các công cụ cần thiết cho mỗi loại kiểm thử, chúng ta sẽ biết khi nào công cụ tự động hóa sẵn sàng Các góc phần tư giúp chúng ta tìm ra các công cụ cần thiết, nhưng với lựa chọn tự động hóa ở các mức khác nhau, chiến lược thực hiện và tổ chức kiểm thử sẽ khác nhau, Kim tự tháp kiểm thử giúp tối ưu hóa năng lực kiểm thử
14.1.2 Test Automation Pyramid
Kim tự tháp kiểm thử tự động Agile cho thấy 3 lớp khác nhau của kiểm thử tự động
• Lớp thấp nhất là nền tảng hỗ trợ toàn bộ phần còn lại
• Nó chủ yếu tạo các kiểm thử đơn vị mạnh mẽ và các kiểm thử thành phần, kiểm thử technology-facing hỗ trợ nhóm
• Lớp này đại diện số lượng lớn các kiểm thử được tự động hóa
• Chúng được viết cùng một ngôn ngữ với hệ thống, sử dụng công cụ thuộc gia đình xUnit
• Sau khi nhóm làm chủ được công nghệ TDD, các kiểm thử sẽ được tạo ra nhanhnhất và ít tốn kém nhất Chúng cũ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 nhất so với bất kỳ loại kiểm thử nào
Trang 8• Lớp ở giữa kim tự tháp
• Nó gồm hầu hết các kiểm thử business-facing, được viết để hỗ trợ nhóm Các kiểm thử ở lớp này có thể bao gồm kiểm thử ‘Story’, kiểm thử chấp nhận, và các kiểm thử bao trùm tập chức năng lớn hơn lớp kiểm thử đơn vị Những kiểm thử này hoạt động ở lớp API hoặc “Bên dưới GUI”, kiểm thử chức năng trực tiếp mà không thông qua GUI
• Chúng viết các trường hợp kiểm thử, bao gồm thiết lập các đầu vào cho mã sản phẩm, chấp nhận kết quả đầu ra, và so sánh kết quả mong đợi
• Vì các kiểm thử này bỏ qua lớp trình bày, nên chúng ít tốn kém để viết và duy trì hơn các kiểm thử sử dụng GUI
• Cố gắng viết các kiểm thử theo ngôn ngữ xác định để khách hàng có thể hiểu được
• Chúng chạy chậm hơn, bởi mỗi kiểm thử đảm bảo hơn một kiểm thử đơn vị và
có thể phải truy cập dữ liệu hoặc các thành phần khác Phản hồi không nhanh như kiểm thử đơn vị nhưng nhanh hơn kiểm thử qua GUI Do đó, GUI của chúngkhông cao như kiểm thử hình thành ở lớp cơ bản nhưng cao hơn lớp đỉnh của kim tự tháp
• Lớp trên cùng đại diện cho năng lực tự động hóa nhỏ nhất, bởi chúng cung cấp ROI thấp nhất
• Những kiểm thử này được thực hiện thông qua GUI Chúng được viết sau khi
mã nguồn được hoàn thành và nhằm mục đích tìm ra nhược điểm của sản phẩm, chúng được thêm trực tiếp vào bộ kiểm thử hồi quy
• Những kiểm thử này thường mất nhiều chi phí để viết, mặc dù có nhiều công cụ mới giúp giảm thiểu đầu tư cần thiết Bởi các thành phần giao diện hay bị thay đổi, các kiểm thử dễ bị lỗi hơn các kiểm thử mức chức năng và đơn vị
• Các kiểm thử này cung cấp phản hồi quan trọng, nhưng bộ kiểm thử GUI có thể chiếm nhiều giờ để chạy hơn là vài phút chạy bộ kiểm thử đơn vị
• Không vấn đề bao nhiêu kiểm thử được tự động hóa, hầu hết các hệ thống đều cần các hoạt động kiểm thử thủ công, như kiểm thử thăm dò và kiểm thử chấp nhận
Hầu hết các nhóm Agile mới 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, vì vậy nhóm bắt đầu với kiểm thử ở lớp trên cùng
• Nếu hệ thống được thiết kế điều hướng kiểm thử, các kiểm thử chức năng ở lớp giữa sẽ dễ dàng để viết
• Là một nhóm có thể làm chủ TDD và kiểm thử tự động đơn vị, lớp dưới bắt đầu phát triển Khi chúng nhận được lực đẩy, một nhóm sử dụng TDD nhanh chóng xây dựng các kiểm thử ở lớp thấp nhất của kim tự tháp
Kim tự tháp kiểm thử là nơi tốt nhất để bắt đầu tìm hiểu kiểm thử tự động có thể giúp Agile team như thế nào
• Các lập trình viên có xu hướng tập trung vào đáy của kim tự tháp, họ cần nhiều thời gian, đào tạo để vượt qua “hump of pain” và tiếp nhận TDD một cách tự nhiên và nhanh chóng Phương pháp toàn nhóm (Whole-team) được sử dụng bởi Agile team cho phép các kiểm thử viên ghép với lập trình viên để giúp họ
Trang 9thực hiện kiểm thử tốt hơn, từ đó củng cố thêm lớp đáy của kim tự tháp Vì phát triển điều hướng kiểm thử, toàn bộ nhóm luôn thiết kế tối đa khả năng kiểm thử
14.2 What Can We Automate?
14.2.1 Continuous Integration, Builds, and Deploys
Bất kỳ công việc tẻ nhạt và lặp đi lặp lại liên quan đến phát triển phần mềm đều có thể
tự động hóa
Nói về tầm quan trọng của quá trình build tự động
• Bạn không thể xây kim tự tháp kiểm thử tự động mà không có điều này Nhóm cần có phản hồi ngay lập tức từ các kiểm thử đơn vị để tiếp tục theo dõi lên các lớp trên
• Mail từ quá trình build tự động thông báo thay đổi được check-in giúp kiểm thử viên biết được khi nào một build sẵn sàng cho việc kiểm thử
Quá trình triển khai tự động cũng làm tăng tốc kiểm thử và 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 trong việc triển khai bởi nó là quá trình thủ công Nó khá đơn giản, nhưng cô ấy mới vào dự án và chuyển nhầm tập tin đến chỗ sai Một quá trình triển khai tự động sẽ thực hiện những việc cần thiết ngay tại chỗ của Janet Nhóm của Lisa đã tích hợp thành công nó vào khung làm việc và thấy nó khá dễ dàng và mất ít thời gian, mặc dù
nó cần bảo dưỡng và nâng cấp liên tục
Hầu hết các Agile team thấy một build kéo dài lâu hơn 8-10 phút thì không khả thi Ngay cả 15 phút cũng quá dài để chờ phản hồi, bởi các check-in sẽ xếp chồng lên và kiểm thử viên phải chờ một thời gian dài để nhận bản build gần nhất, tốt nhất Các build dài có thể do việc truy cập cơ sở dữ liệu hoặc cố gắng kiểm thử GUI Trong trường hợp này,
• Hãy cố gắng sao chép cơ sở dữ liệu thật và sử dụng bộ nhớ trong thay thế
• Hoặc cấu hình quy trình build để phân phối các kiểm thử trên một vài máy
• Hoặc tìm phần mềm khác để quản lý tài nguyên tốt hơn
• Hoặc nhờ sự giúp đỡ các các chuyên gia bên ngoài
Chìa khó để tăng tốc độ tích hợp liên tục và quá trình build là thực hiện từng bước nhỏ
ở một thời điểm Nó sẽ đưa ra các thay đổi tại mỗi thời điểm, bạn có thể đo lường được thành công và biết bạn đi đúng hướng hay không Lúc bắt đầu, có thể bạn muốn loại bỏ những kiểm thử tốn kém khỏi các bản build để chạy nó vào ban đêm
Tích hợp liên tục và quá trình build chạy nhanh mang lại ROI lớn nhất của bất kỳ năng lực kiểm thử tự động nào Nó là thứ đầu tiên mà mỗi team cần phải tự động
Trang 1014.2.2 Unit and Component Tests
Chúng tôi không thể nhấn mạnh quá mức vào tầm quan trọng của việc tự động hóa kiểm thử đơn vị Nếu lập trình viên đang sử dụng TDD như một tổ chức để viết các kiểmthử của họ, họ không chỉ tạo ra một bộ hồi quy lớn, mà còn 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ử, cơ hội thành công lâu dài rất mong manh Tạo tự động kiểm thử đơn vị và tích hợp liên tục là ư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 nhất là sử dụng một số mẫu tự động hóa
• Janet đã trưởng thành trong team và có thành công trong việc sử dụng Ruby để đọc bảng tính với tất cả hoán vị và sự hợp tác của các biến đầu vào, so sách đầu vào với kết quả mong muốn được lưu trữ trong bảng tính Các kiểm thử điềuhướng dữ liệu này dễ dàng để viết và bảo trì
• Một khách hàng của Janet sử dụng chức năng IRB (Interactive Ruby Shell) của Ruby để kiểm thử Web Services cho phần nghiệm thu Nhóm chia sẻ các kịch bản với khách hàng, nhưng các kiểm thử viên nghiệp vụ thích nhìn thấy những
gì xảy ra nếu đầ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 ra
14.2.4 Testing behind the GUI
Kiểm thử bên dưới GUI thì dễ dàng tự động hơn kiểm thử GUI Bởi các kiểm thử không chịu ảnh hưởng bởi sự thay đổi của lớp trình bày và nó làm việc dựa trên mã nguồn logic nghiệp vụ ổn định hơn
Các công cụ sử dụng cho kiểm thử này thường theo định dạng khai báo, bảng hoặc bảng tính
Các thiết bị lấy mã sản phẩm để thực hiện các đầu vào kiểm thử và trả về kết quả được viết nhanh chóng
Nó được viết chính cho kiểm thử business-facing, dễ hiểu với cả hai khách hàng và lậptrình viên
14.2.5 Testing the GUI
Một GUI với một chút hoặc không có logic nghiệp vụ vẫn phải kiểm thử Trong phát triển Agile, chức năng mới được cung cấp ở mỗi lần lặp, do đó cần một số kiểm thử hồi quy tự động mức GUI trong hầu hết các dự án
Lựa chọn công cụ là chìa khóa thành công của tự động GUI
• Các kịch bản tự động cần sự mềm dẻo và dễ dàng để bảo trì
• Cần thời gian để phát triển các thư viện, để các kiểm thử tự động không phải làm lại hoặc lặp lại mã nguồn Khi thay đổi xảy ra, chỉ việc sửa đổi ở một nơi Làm cho mã nguồn dễ dàng bảo trì và làm tăng ROI
Trang 11Một điểm về khả năng kiểm thử ở đây, chắc chắn lập trình viên đặt tên đối tượng của
họ và gán ID cho chúng Nếu họ dựa vào hệ thống tự động tạo ra các định danh, thì mỗikhi một đối tượng được thêm vào trang, ID sẽ thay đổi, đòi hỏi thay đổi đối với các kiểm thử
Tự động những kiểm thử đơn giản đầu tiên, đừng cố gắng kiểm thử chức năng nghiệp
vụ, nên dành nhiều thời gian cho các thử thách lớn hơn
14.2.6 Load Tests
Một số kiểu kiểm thử không thể thực hiện được mà không có tự động hóa Manual load tests không thể làm được hoặc không chính xác, mặc dù chúng tôi đã cố gắng thựchiện cùng một lúc kịch bản kiểm thử Bạn không thể tạo một cuộc tấn công số lượng lớn
để xác định website có bị hack hay không, hoặc xử lý một lượng tải lớn mà không có khung công cụ nào
• Công ty Lisa cần một vài mẫu mail với phong bì thư đến toàn bộ khách hàng của
họ Lập trình viên không thể tạo mẫu mail, nhưng họ có thể ghép chúng với phong bì thư và đẩy nhanh tốc độ gửi thư
• Kiểm thử viên đồng nghiệp của Lisa, Mike Busse, đã viết một spreadsheet macro
để thực hiện các tính toán phức tạp cho việc phân bổ nguồn vốn mà các nhà quản trị trước đó đã thực hiện thủ công
• Nhiều checklist thủ công cũng có thể được thay thế bởi một kịch bản tự động Tự động hóa không chỉ để cho kiểm thử
14.2.9 Data Creation or Setup
Tự động hóa còn giúp tạo và thiết lập dữ liệu Nếu bạn liên tục thiết lập dữ liệu, hãy tự động quá trình này Nếu bạn cần lặp lại cái gì đó để tái hiện lỗi nhiều lần, nếu có thể tự động hóa, bạn sẽ thu được kết quả tương đồng sau mỗi lần chạy
Làm sạch dữ liệu cũng quan trọng như khi tạo ra nó Bộ công cụ tạo dữ liệu bao gồm
cả cách gỡ bỏ dữ liệu kiểm thử, vì vậy nó không ảnh hưởng đến kiểm thử khác hay
Trang 12ngăn việc chạy lại kiểm thử.
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
Nó có thể tự động nếu đảm bảo GUI không bao giờ thay đổi Nhưng tự động hóa sẽ 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 tiến, phát triển trong tương lai Những kịch bản tự động hóa không thể làm điều này Tuy nhiên, tự động hóa các kiểm thử khác sẽ tạo điều kiện và thời gian để thực hiện Exploratory Testing
14.3.3 Tests that Will Never Fail
Có một lập luận rằng, các kiểm thử không bao giờ lỗi thì không cần kiểm thử tự động Nếu có một yêu cầu rõ ràng thì chỉ có một cách để hoàn thành có, các lập trình viên sẽ luôn biết chính xác nó sẽ làm gì, cơ hội tìm ra defects là rất khó
Nếu bạn đang kiểm thử hệ thống quan trọng sống còn, thậm chí một nguy cơ nhỏ của lỗi hồi quy cũng là quá nhiều Sử dụng phân tích rủi ro để giúp bạn quyết định có nên tự động hóa các kiểm thử hay không
14.3.4 One-Off Tests
Thường kiểm thử thủ công cho các kiểm thử một lần là đủ Đôi khi tự động hóa có giá trị thực hiện cho kiểm thử một lần Các việc tẻ nhạt có giá trị tự động hóa, ngay cả khi không làm nó thường xuyên
Hãy cân nhắc chi phí tự động hóa đối với thời gian đã mất bởi kiểm thử thủ công Nếu
nó dễ dàng để thực hiện thủ công và tự động hóa không nhanh, thì nên giữ nó thủ công
Trang 1314.4 What Might Be Hard to Automate?
Khi mã nguồn không viết test-first, hoặc không được suy nghĩ về tự động kiểm thử, nó
sẽ khó để tự động hóa
Legacy code có thể có I/O, truy cập cơ sở dữ liệu, cũng như logic nghiệm vụ và
presentation code đan xen vào nhau Nó có thể không rõ ràng để lấy mã nguồn để tự động hóa kiểm thử Chắc chắn bạn không thể lên kế hoạch tự động mọi thứ bên dưới GUI, bởi có quá nhiều logic ở presentation layer
Có một số phương pháp tiếp cận khác nhau để khắc phục nó, và sau đó kiểm thử tự động sẽ trở nên dễ dàng
• “Làm việc hiệu quả với Legacy code [2004] của Michael Feathers giải thích làm thế nào để xây dựng khung kiểm thử trên cơ sở mã nguồn hiện tại và tái cấu trúcchúng để thích hợp với tự động hóa Với Legacy code, bạn có thể viết kiểm thử
để tránh những vấn đề mới phát sinh Cách tiếp cận này có thể làm việc ngay cảvới hệ thống thiếu cấu trúc hoặc không hướng đối tượng
• Nhóm của Lisa có cách tiếp cận khác nhưng hiệu quả Các thành viên của nhómbắt đầu “bóp nghẹt - Strangling” Legacy code bằng cách viết toàn bộ tính năng mới với kiến trúc thân thiện với kiểm thử Họ dần thay thế toàn bộ mã cũ bằng
mã đã viết test-first Khi họ làm việc với mã cũ để sửa lỗi, hoặc cần cập nhật, đơn giản họ thêm vào các kiểm thử đơn vị cho toàn bộ 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ảoluận toàn nhóm Khi nhóm nhìn vào các thách thức kiểm thử, bạn sẽ phải xem xét tự động hóa ở đâu cho phù hợp Trước khi bạn tìm kiếm công cụ tự động cụ thể, bạn nên xác định nhu cầu của nhóm
• Nếu bắt đầu từ đầu, hãy tìm kiếm lợi ích lớn nhất Cú đánh lớn nhất vào vấn đề
là xác định các kiểm thử đơn vị mà các lập trình viên có thể thực hiện Thay vì bắt đầu từ đỉnh kim tự tháp kiểm thử, bạn có thể bắt đầu từ đáy, đảm bảo các vấn đề cơ bản được đưa ra Bạn cũng cần xem xét các loại kiểm thử khác mà bạn cần kiểm thử và sau đó bạn sẽ cần một số công cụ để sử dụng
• Giả định, bạn tự động kiểm thử đơn vị và thành phần ở Q1, và tìm kiếm tự tự động Business-facing tests ở Q2,3, hoặc technology-facing tests ở Q4
• Nghĩ về các kỹ năng và kinh nghiệm của nhóm Ai cần tự động hóa và tại sao? Mục tiêu đạt được là gì? Hiểu được một số vấn đề có thể ảnh hưởng đến lựa chọn công cụ và nỗ lực bỏ ra Đá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ãy hỏi nhóm “Chỗ khó khăn nhất là gì?” hoặc
“Chỗ nhàm chán nhất là gì?”, bạn có phải viết mã để triển khai kiểm thử nó không? các 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 nào không?