Làm thế nào để thực hiện Test Automation hiệu quả trong Agile

Tự động hóa trong Agile là rất quan trọng.

Hãy suy nghĩ về nhiều tính năng được thêm vào và phân phối trong mọi Sprint. Phải có một cách để đảm bảo tính năng mới được thêm vào không ảnh hưởng đến chức năng hiện tại.

Do thời gian chạy Sprint thấp, nên thực tế không thể thực hiện toàn bộ bộ sản phẩm mỗi khi sản phẩm được tăng lên ở đầu Sprint. Có một bộ kiểm tra tự động chắc chắn sẽ đóng một vai trò lớn hơn ở đây.

Tuy nhiên, giới thiệu và phát triển vào tự động hóa chắc chắn sẽ mất một thời gian. Thực hiện một khoản đầu tư ban đầu vào việc lập kế hoạch và thiết kế hoạt động tự động hóa chắc chắn sẽ trả hết trong thời gian dài.

Điều gì để Tự động hóa trong Agile? Bất cứ khi nào chúng tôi dự định giới thiệu tự động hoá vào các dự án của chúng tôi, hầu hết chúng ta bỏ phiếu ngay lập tức cho "Smoke Tests suit" hoặc "Regression test suit" là các ứng cử viên tốt nhất cho tự động hóa . Tất nhiên,khi chúng ta nghĩ đến kim tự tháp kiểm tra tự động, chúng ta có thể kết luận rằng đó chỉ là lớp trên cùng của kim tự tháp mà chúng ta đang nói đến.

Ngoài lớp trên, chúng tôi vẫn có lớp dịch vụ và lớp đơn vị quan trọng hơn.

Vì vậy những gì các bài kiểm tra, khác với thử nghiệm Smoke và hồi quy, có thể là ứng cử viên tốt cho tự động hóa?

1) Xây dựng và Triển khai

Trong môi trường truyền thống, chúng tôi đã xác định trước xây dựng có thể được hàng tuần hoặc đôi khi thậm chí hàng tháng. Một trong những lý do là những triển khai này tốn nhiều thời gian. Vấn đề với cách tiếp cận này là chúng ta phải đợi cho ngày xác định trước để có được lỗi cố định hoặc để có được các tính năng mới được thực hiện, do đó sẽ có một sự chậm trễ.

Lý do thứ hai là do người kiểm tra thời gian hoàn thành kiểm tra và phát hiện ra lỗi và lỗi, các lập trình viên đã chuyển sang các phần thực hiện khác nhau và ít quan tâm đến việc giải quyết các lỗi của ứng dụng cũ hơn. Cách tiếp cận này cũng làm chậm thời gian để làm cho tính năng có sẵn trong sản xuất.

Xây dựng và triển khai là các thực thể được lặp đi lặp lại và đôi khi nhàm chán. Cũng có thể mất hàng giờ để triển khai một bản xây dựng, làm chậm trễ việc thử nghiệm và cuối cùng là phản hồi. Là một nhiệm vụ lặp đi lặp lại, triển khai trở thành một ứng cử viên tốt cho tự động hóa.

Một vài lợi ích của việc triển khai tự động xây dựng là:

• Không có cơ hội gây ra lỗi triển khai (có thể tránh được các lỗi của con người như sao chép tập tin sai hoặc sao chép tập tin vào vị trí không chính xác)
• Lỗi / tính năng có sẵn để kiểm tra ngay khi chúng được cố định
• Người kiểm tra có nhiều thời gian để kiểm tra
• Tính năng này đã sẵn sàng để được chuyển sang sản xuất trong thời gian ít hơn
• Phản hồi nhanh

2) Đơn vị kiểm tra / Kiểm tra thành phần

Tôi đã nói về tầm quan trọng của việc tự động hóa lớp đơn vị bằng cách sử dụng phương pháp TDD trong hướng dẫn cuối cùng của tôi .

Điều này tạo thành lớp thấp nhất của kim tự tháp, vì thế nền móng và bất kỳ nền móng nào cần phải là đá cứng. Nhóm phát triển nên cộng tác và làm việc cùng nhau để có thể đáp ứng hầu hết các thử nghiệm trong lớp này.

3) Kiểm tra dịch vụ API / Web

Các dịch vụ Web là môi trường trong đó hai ứng dụng trao đổi dữ liệu hoặc thông tin theo yêu cầu và đáp ứng mà không làm phiền các kiến ​​trúc cơ bản hoặc công nghệ. Nói một cách đơn giản hơn - đưa ra yêu cầu và xác nhận phản hồi là những gì chúng tôi thường làm trong thử nghiệm dịch vụ web.

Kiểm tra các dịch vụ web đòi hỏi phải viết các chương trình để gọi những phương thức dịch vụ web này và xác nhận giá trị mà nó trả về. Chúng tôi thậm chí có thể thử nghiệm các dịch vụ cho hoán vị khác nhau và kết hợp. Có tất cả dữ liệu thử nghiệm trong bảng excel và chương trình của bạn có thể đọc dữ liệu và gọi dịch vụ testable bằng cách truyền dữ liệu thử nghiệm như là một tham số và xác nhận kết quả.

Thử nghiệm đặc biệt này là một phần của lớp giữa của kim tự tháp. Hầu hết các thử nghiệm chức năng có thể được đẩy vào lớp này. Giải quyết các khuyết tật phát sinh trong lớp này trở nên dễ dàng khắc phục và chúng không bị hoãn lại cho đến khi giao diện người dùng có sẵn.

4) Kiểm tra đằng sau GUI

Tự động kiểm tra đằng sau GUI tương đối dễ dàng hơn so với tự động hóa GUI thực tế. Một ưu điểm khác là bất kể sự thay đổi UI, chức năng vẫn còn nguyên vẹn. Ngay cả khi một phần của UI bị thay đổi, chức năng của tính năng này không thay đổi. Kỹ thuật này chủ yếu tập trung vào logic kinh doanh và các quy tắc.

Các trường hợp thử nghiệm chủ yếu được viết bằng định dạng bảng hoặc trong một bảng tính và đoạn mã được ghi nhận chấp nhận đầu vào từ các bảng này và trả về kết quả. Các kết quả được tạo ra ngay lập tức và cung cấp một nền tảng tuyệt vời cho các bên liên quan phi kỹ thuật để chạy thử nghiệm này và có được kết quả mong đợi. Một trong những công cụ được sử dụng để đạt được kỹ thuật này là Fitnesse .

5) Kiểm tra không có chức năng

Đây kỹ thuật kiểm tra không có chức năng cơ bản liên quan đến việc kiểm tra tải, Hiệu suất và Stress. Có nhiều công cụ sẵn có trên thị trường có thể được sử dụng để tự động hóa các bài kiểm tra này.

6) Số liệu So sánh

Nhiều thử nghiệm của chúng tôi yêu cầu chúng tôi so sánh các tệp dữ liệu, bao gồm tệp văn bản, tệp CSV hoặc excel

• Những tệp này có thể được so sánh với các đường cơ sở để thực hiện xác nhận dữ liệu
• So sánh có thể có cùng số liệu nhưng có định dạng khác. Điều này về cơ bản xảy ra khi chúng ta có hai trong số các tập tin tương tự được tạo ra từ hai nguồn khác nhau

Những so sánh này có thể lặp đi lặp lại, do đó tự động.

7) Tìm kiếm

Tìm kiếm một thực thể cụ thể từ một bó lớn các tập tin cũng có thể là tẻ nhạt và giúp chúng tôi nếu đó là một công việc lặp đi lặp lại. Một ví dụ là tìm kiếm thông qua các tập tin đăng nhập. Nếu đây cũng là một công việc tẻ nhạt và lặp đi lặp lại nhiều hơn chúng ta nên suy nghĩ về tự động hóa nó.

8) Nhiệm vụ lặp đi lặp lại

Bất kỳ công việc nào bắt đầu với việc tương tác với người dùng cuối hoặc viết bài báo để phát triển nó, nếu nó lặp đi lặp lại, cần được xem xét trong tự động hóa. Chúng ta nên hiểu rằng tự động hoá không có nghĩa là phải có một công cụ / công nghệ phức tạp liên quan đến nó. Nó có thể là một macro VB đơn giản hoặc một chương trình Java với một Javascript để giải quyết mục đích.

Không có hướng dẫn từng bước nói về nơi bắt đầu tự động hóa. Tự động khởi động cho nhóm đòi hỏi bạn phải suy nghĩ và áp dụng những suy nghĩ sâu sắc về những khía cạnh bạn muốn tự động hoá hoặc mục tiêu cuối cùng của tự động hóa là gì?

Bạn có thể bắt đầu bằng cách:

• Xác định các nhiệm vụ lặp đi lặp lại,
• Xác định các lĩnh vực đau của ứng dụng
• Xác định các thách thức thử nghiệm

Nếu bạn không có tự động hóa trong dự án thì có thể bạn sẽ đi đến một cách tiếp cận đa lớp, nơi các bài kiểm tra đơn vị có thể được nhắm mục tiêu trước tiên để tự động hoá. Điều này sẽ mang lại cho bạn ROI cao nhất.

Đồng thời, người kiểm tra có thể bắt đầu làm việc về kiểm tra khói phù hợp và sau đó là hồi quy. Một khi nhóm đã đạt được các kỹ năng và cảm thấy thoải mái, dần dần di chuyển theo hướng tự động hóa các nhiệm vụ lặp đi lặp lại khác.

Không trực tiếp nhảy vào mua một công cụ mới mà không cần đánh giá nhu cầu của bạn. Như tôi đã nói ở trên, một chương trình đơn giản hoặc một macro có thể giải quyết được mục đích tự động hoá một số nhiệm vụ lặp đi lặp lại. Vì vậy, trước khi quyết định mua một công cụ, hãy làm một POC và đánh giá xem công cụ đó có hiệu quả hay không.

Hãy đi qua các tài liệu mà tôi đã cung cấp thêm chi tiết về làm thế nào để chọn trường hợp kiểm tra chính xác cho tự động hóa và một số hiểu biết về Ước nỗ lực tự động hóa trong các bài viết sau đây hướng dẫn để tự động hóa những thách thức quá trình thử nghiệm và lập dự toán thi của dự án tự động hóa selen.

Khi phạm vi của tự động hóa và công cụ được hoàn thành, tiếp theo là thiết kế khuôn khổ.

Hãy nhớ rằng, trong Agile, khuôn khổ được phát triển. KHÔNG nhắm mục tiêu thiết kế toàn bộ khuôn khổ đầu tiên và sau đó thực hiện. Thiết kế và thực hiện cho MVP (Tối thiểu Sản phẩm Viable) và sau đó nâng cao khuôn khổ hiện tại để bao gồm nhiều tính năng hơn. Bạn cũng cần phải áp dụng tốt mã hóa và phát triển thực tế nếu bạn muốn bộ phần mềm tự động của bạn được mạnh mẽ.

Một số Thực tiễn tốt nhất

• Không nhắm mục tiêu Tự động 100% chỉ một lần. Khởi đầu nhỏ. Nhớ nó là một tiến trình đang tiến triển

• Thực hiện theo các phương thức Agile giống như bạn thực hiện cho bất kỳ phát triển phần mềm nào. Tự động hoá cũng đòi hỏi phải lập kế hoạch và thiết kế hợp lý. Bạn sẽ không muốn tăng nợ kỹ thuật của mình khi bạn tự động hóa

• Tạo thử nghiệm tự động kiểm tra của bạn. Công việc tồn đọng này có thể từ thực hiện một tính năng mới để nâng cao tính năng hiện có. Cho điểm câu chuyện vào các mục đã xác định của bạn và gán nó cho phù hợp. Đưa những vật dụng còn lại vào Sprint của bạn và theo dõi nó bằng cách sử dụng bảng Kanban

• Viết tiêu chí chấp nhận cho các câu chuyện về tự động hóa của bạn. Các tiêu chí chấp nhận này có thể bao gồm:

  • Tích hợp bộ phần mềm kiểm tra với CI
  • Cảng phù hợp với một địa điểm tập trung
  • Gửi kết quả qua email
  • Cung cấp việc gửi các tệp nhật ký lỗi khi kiểm tra không thành công
  • Bất kỳ tiêu chuẩn khác ....

• Đừng lạm dụng thời gian đánh giá một công cụ mới. Bạn có thể tạo một danh sách kiểm tra ưu tiên của những gì bạn muốn từ công cụ mới và quyết định thời gian để đánh giá nó. Nếu bạn không nhìn thấy kết quả của mình trong thời gian quy định, hãy chuyển sang kế tiếp

• Thực hiện một quyết định sáng suốt về những gì để tự động hoá. Không phải mọi phần của tự động hóa đều có hiệu quả và mang lại ROI tích cực. Không tự động hóa chỉ vì lợi ích của tự động hóa

• Sử dụng môi trường phát triển phù hợp. Không giữ mã cho địa phương của bạn. Có kho lưu giữ mã của bạn và tạo thói quen kiểm tra mã của bạn vào cuối ngày

• Tương tự, thử thực hiện các bài kiểm tra tự động của bạn từ một vị trí tập trung. Làm cho người này độc lập. Nó phải là bất cứ ai từ nhóm có thể kích hoạt các tập lệnh từ máy của họ và kết quả thu được qua email

Các nguyên tắc Agile có thể được áp dụng cho tự động hóa là gì?

Một số mẹo rất đơn giản:

• Giữ mọi thứ đơn giản. Làm những gì là cần thiết. Tôi đã nhìn thấy nhiều trường hợp mà chúng tôi cung cấp thực hiện tráng đường mà làm cho tự động hóa phức tạp không cần thiết. Hãy tránh những thứ không cần thiết
• Làm những việc đơn giản không có nghĩa là làm những việc đơn giản nhất. Điều này có nghĩa là thực hiện các bước của em bé để đạt được các mục tiêu tự động hóa của bạn. Bạn có thể thực hiện một tính năng đơn giản để tự động hóa, nhưng có thể xảy ra rằng việc thực hiện tự động hoá hoá ra là một quá trình phức tạp
• Áp dụng cách tiếp cận nhóm toàn bộ . Tôi tin rằng tất cả mọi người là một người thử nghiệm trong một đội nhanh nhẹn. Hãy không hạn chế công việc tự động hóa hoặc chỉ với người kiểm tra hoặc chỉ với các nhà phát triển. Mỗi bộ môn phải bước vào đôi giày của nhau để đạt được tự động hóa cho dự án. Cách tiếp cận này cũng có hiệu quả để giải quyết bất kỳ vấn đề kỹ thuật nào đi kèm với việc thực hiện
• Khung này được phát triển trong Agile . Không cố gắng cung cấp quá nhiều tính năng mà có thể không cần thiết làm cho các mảnh phức tạp tự động hóa
• Dành thời gian để làm điều đó đúng. Dành thời gian để thiết kế nó một cách hợp lý để tránh các khoản nợ kỹ thuật Nhận phản hồi thường xuyên
• Áp dụng các tiêu chuẩn và thực hành mã hóa phù hợp. Thiết kế phải đơn giản, áp dụng các khái niệm OOPS và cố gắng giữ các bài kiểm tra độc lập với nhau. Xem xét các yếu tố như "khả năng bảo trì" của bộ thử

Tôi có thấy bất kỳ thách thức nào trong khi tự động hóa Agile?

Tự động hoá trong thế giới Agile không có những thách thức riêng :

• Chúng ta cần lên kế hoạch thật tốt. Quyết định bộ công cụ, công cụ, khuôn khổ và cách tiếp cận thích hợp, tất cả đều cần một chiến lược thích hợp. Tuy nhiên, chúng ta nên nhớ không kế hoạch. Giữ MVP (sản phẩm tối thiểu) trong tâm trí
• Phá hoại chất lượng của mã bởi vì chúng tôi muốn cung cấp nhanh: Chúng ta phải nhớ rằng các khoản nợ kỹ thuật giữ tốt trong tự động hóa quá
• Nhóm hầu hết các nhóm thời gian không tuân theo "Phương pháp tiếp cận toàn bộ nhóm" và để toàn bộ trách nhiệm mã hóa và duy trì bộ tự động cho người kiểm tra làm tăng trách nhiệm của người kiểm tra
• Tự động kiểm tra chức năng là khó khăn hơn tự động hóa giao diện người dùng

Trong số tất cả những thách thức này, thách thức quan trọng nhất là nâng cao kỹ năng của người kiểm tra.

Thực hiện và duy trì tự động hóa cho một nhóm là một hoạt động lập trình (phát triển) mà các lập trình viên (nhà phát triển) làm. Không chỉ đơn thuần là việc thực hiện mà còn tích hợp tính năng tự động với CI là rất quan trọng và yêu cầu người kiểm tra phải học hỏi và áp dụng các kỹ năng mới và tìm hiểu các công cụ và công nghệ mới.

Một số công cụ mã nguồn mở phù hợp với Agile

• Selenium WebDriver - Dành cho giao diện người dùng
• Selenium Grid - Để thực hiện song song
• Dưa chuột - Đối với BDD
• JMeter - Để kiểm tra hiệu năng
• SoapUI - Đối với các dịch vụ web
• WireMock - Kiểm tra dịch vụ Web khi không có dịch vụ web.
• Appium - dành cho thiết bị di động

Hãy để tôi kết luận với các góc kiểm tra Agile nổi tiếng:

Quadrant 1 là bài kiểm tra Unit và các thành phần có thể được tự động hóa bằng phương pháp TDD.

Quadrant 2 nói về kiểm tra chức năng, nơi chúng ta có thể áp dụng cách tiếp cận BDD.

Quadrant 3 là góc tọa độ duy nhất có phạm vi kiểm tra thủ công.

Quadrant 4 cơ bản nói về việc kiểm tra có thể đạt được bằng một số công cụ. Điều này sẽ chăm sóc các bài kiểm tra Load, Stress thử nghiệm, kiểm tra khối lượng và các bài kiểm tra an ninh.

Phần kết luận

Có rất nhiều phạm vi của tự động hóa ngoài các bài kiểm tra Smoke và hồi quy. Do đó, chúng ta phải thoát khỏi khái niệm về tự động hóa giới hạn cho các loại thử nghiệm này, điều đó có nghĩa là bộ kỹ năng của một người kiểm tra trong Agile đòi hỏi nhiều hơn là chỉ tìm ra lỗi và khuyết điểm.

Người kiểm tra cần phải có sự hợp tác và sắc bén hơn các kỹ năng lập trình / tự động hóa của họ. Nếu nhiều hơn và nhiều hơn nữa các bài kiểm tra được tự động, nó sẽ cung cấp cho các xét nghiệm thêm thời gian để tham gia vào các nhiệm vụ phức tạp hơn và đầy thử thách.

Bài viết được tham khảo tại: http://www.softwaretestinghelp.com/automation-in-agile-world/