Trong phần thứ hai của loạt bài hướng dẫn tự động hóa thử nghiệm này , tôi sẽ mô tả ngắn gọn các loại thử nghiệm tự động và sau đó quan trọng nhất là tôi sẽ xóa một số hiểu lầm về tự động hóa thử nghiệm.
Các loại thử nghiệm tự động :
Có ba loại kiểm thử phần mềm tự động chính.
Kiểm thử phần mềm đơn vị tự động được viết để kiểm thử ở cấp mã. Lỗi được xác định trong các chức năng, phương pháp và thói quen được viết bởi các nhà phát triển.
Một số công ty yêu cầu các nhà phát triển tự kiểm thử đơn vị và một số thuê tài nguyên tự động kiểm thử chuyên ngành. Các tài nguyên này có quyền truy cập vào mã nguồn và họ viết các bài kiểm thử đơn vị để phá mã sản xuất.
Các loại thử nghiệm tự động :
 |
| Học kiểm thử phần mềm |
Có ba loại kiểm thử phần mềm tự động chính.
# 1 . Kiểm thử đơn vị tự động
Kiểm thử phần mềm đơn vị tự động được viết để kiểm thử ở cấp mã. Lỗi được xác định trong các chức năng, phương pháp và thói quen được viết bởi các nhà phát triển.
Một số công ty yêu cầu các nhà phát triển tự kiểm thử đơn vị và một số thuê tài nguyên tự động kiểm thử chuyên ngành. Các tài nguyên này có quyền truy cập vào mã nguồn và họ viết các bài kiểm thử đơn vị để phá mã sản xuất.
Do sự hiện diện của các thử nghiệm đơn vị, bất cứ khi nào mã biên dịch, tất cả các thử nghiệm đơn vị đều chạy và cho chúng tôi biết kết quả là liệu tất cả các chức năng có hoạt động hay không. Nếu bất kỳ kiểm thử đơn vị nào thất bại, điều đó có nghĩa là hiện tại đã có lỗi trong mã sản xuất.
Một số công cụ phổ biến nhất hiện có trên thị trường là NUnit và JUnit . Microsoft cũng cung cấp khuôn khổ riêng để thử nghiệm đơn vị gọi là MSTest . Đi qua các trang web của các công cụ này và họ sẽ cung cấp các ví dụ và hướng dẫn về cách viết bài kiểm thử đơn vị.
Giao diện lập trình ứng dụng (API) giúp phần mềm có thể nói chuyện với các ứng dụng phần mềm khác. Cũng giống như bất kỳ phần mềm nào khác, API cần phải được kiểm thử . Trong loại thử nghiệm này, GUI thường không liên quan.
Những gì chúng tôi kiểm thử ở đây thường là các vấn đề về chức năng, tuân thủ và bảo mật. Trong các ứng dụng web, chúng tôi có thể kiểm thử Yêu cầu và Phản hồi của ứng dụng của mình xem chúng có an toàn và được mã hóa hay không.
Đây là một trong những ví dụ mà chúng tôi có thể sử dụng Kiểm thử API. Công cụ phổ biến nhất để thử nghiệm API là SOAPUI có cả phiên bản miễn phí và trả phí. Có những công cụ khác, mà bạn có thể sử dụng theo nhu cầu của bạn.
Loại thử nghiệm tự động này là hình thức tự động hóa khó khăn nhất vì nó liên quan đến thử nghiệm giao diện Người dùng của ứng dụng.
Thật khó khăn vì GUI rất có thể thay đổi. Nhưng loại thử nghiệm này cũng gần nhất với những gì người dùng sẽ làm với ứng dụng của chúng tôi.
Một số công cụ phổ biến nhất hiện có trên thị trường là NUnit và JUnit . Microsoft cũng cung cấp khuôn khổ riêng để thử nghiệm đơn vị gọi là MSTest . Đi qua các trang web của các công cụ này và họ sẽ cung cấp các ví dụ và hướng dẫn về cách viết bài kiểm thử đơn vị.
# 2. Dịch vụ web tự động / Kiểm thử API
Giao diện lập trình ứng dụng (API) giúp phần mềm có thể nói chuyện với các ứng dụng phần mềm khác. Cũng giống như bất kỳ phần mềm nào khác, API cần phải được kiểm thử . Trong loại thử nghiệm này, GUI thường không liên quan.
Những gì chúng tôi kiểm thử ở đây thường là các vấn đề về chức năng, tuân thủ và bảo mật. Trong các ứng dụng web, chúng tôi có thể kiểm thử Yêu cầu và Phản hồi của ứng dụng của mình xem chúng có an toàn và được mã hóa hay không.
Đây là một trong những ví dụ mà chúng tôi có thể sử dụng Kiểm thử API. Công cụ phổ biến nhất để thử nghiệm API là SOAPUI có cả phiên bản miễn phí và trả phí. Có những công cụ khác, mà bạn có thể sử dụng theo nhu cầu của bạn.
# 3. Kiểm thử GUI tự động.
Loại thử nghiệm tự động này là hình thức tự động hóa khó khăn nhất vì nó liên quan đến thử nghiệm giao diện Người dùng của ứng dụng.
Thật khó khăn vì GUI rất có thể thay đổi. Nhưng loại thử nghiệm này cũng gần nhất với những gì người dùng sẽ làm với ứng dụng của chúng tôi.
Vì người dùng sẽ sử dụng chuột và bàn phím, các kiểm thử GUI tự động cũng bắt chước hành vi tương tự bằng cách sử dụng chuột và bàn phím để nhấp hoặc ghi vào các đối tượng có trên giao diện người dùng.
Do đó, chúng ta có thể tìm thấy các lỗi sớm và nó có thể được sử dụng trong nhiều tình huống như kiểm thử hồi quy hoặc điền vào các biểu mẫu mất quá nhiều thời gian.
Các công cụ kiểm thử GUI phổ biến nhất là QTP (Hiện được gọi là UFT) , Selenium , Test Complete và Microsoft Coded UI (là một phần của phiên bản cao cấp và cao cấp của Visual Studio).
Trong những năm qua, tôi đã nghe một số quan niệm sai lầm về tự động hóa thử nghiệm. Tôi nghĩ rằng tôi cũng nên xóa chúng trong bài viết này.
Quan niệm sai lầm # 1 . Tự động hóa là ở đây để thay thế người kiểm thử phần mềm thủ công.
Tự động hóa thử nghiệm là để giúp người thử nghiệm thực hiện thử nghiệm nhanh hơn và theo cách đáng tin cậy hơn. Nó không bao giờ có thể thay thế con người.
Hãy nghĩ về tự động hóa thử nghiệm như một chiếc xe hơi. Nếu bạn đi bộ, bạn sẽ mất khoảng 20 phút để đến nhà. Nhưng nếu bạn sử dụng xe hơi, bạn sẽ đạt được trong hai phút.
Các công cụ kiểm thử GUI phổ biến nhất là QTP (Hiện được gọi là UFT) , Selenium , Test Complete và Microsoft Coded UI (là một phần của phiên bản cao cấp và cao cấp của Visual Studio).
Một số quan niệm sai lầm về kiểm thử tự động
Trong những năm qua, tôi đã nghe một số quan niệm sai lầm về tự động hóa thử nghiệm. Tôi nghĩ rằng tôi cũng nên xóa chúng trong bài viết này.
Quan niệm sai lầm # 1 . Tự động hóa là ở đây để thay thế người kiểm thử phần mềm thủ công.
Tự động hóa thử nghiệm là để giúp người thử nghiệm thực hiện thử nghiệm nhanh hơn và theo cách đáng tin cậy hơn. Nó không bao giờ có thể thay thế con người.
Hãy nghĩ về tự động hóa thử nghiệm như một chiếc xe hơi. Nếu bạn đi bộ, bạn sẽ mất khoảng 20 phút để đến nhà. Nhưng nếu bạn sử dụng xe hơi, bạn sẽ đạt được trong hai phút.
Người điều khiển chiếc xe vẫn là bạn, một con người, nhưng .. chiếc xe giúp con người đạt được mục tiêu của mình nhanh hơn. Ngoài ra, phần lớn năng lượng của bạn được tiết kiệm, vì bạn đã không đi bộ. Vì vậy, bạn có thể sử dụng năng lượng này để thực hiện những điều quan trọng hơn.
Tương tự với thử nghiệm tự động hóa. Bạn sử dụng nó để nhanh chóng kiểm thử hầu hết các bài kiểm thử lặp đi lặp lại, dài và nhàm chán của bạn và tiết kiệm thời gian và năng lượng của bạn để tập trung và kiểm thử chức năng mới và quan trọng.
Công cụ không kiểm thử . Chỉ có người kiểm thử . Các công cụ chỉ thực hiện các hành động mà người Viking giúp kiểm thử . Cúc
Công cụ có thể nhấp vào đối tượng. Nhưng nơi để nhấp sẽ luôn được nói bởi một người kiểm thử thủ công. Tôi nghĩ rằng bạn có được quan điểm của tôi bây giờ.
Quan niệm sai lầm # 2 . Mọi thứ dưới ánh mặt trời đều có thể được tự động
Nếu bạn cố gắng tự động hóa 100% các trường hợp thử nghiệm của mình, có thể bạn sẽ có thể làm như vậy, nhưng nếu điều đó bạn có thể làm, thì điểm đầu tiên của chúng tôi trở thành sai. Bởi vì nếu mọi thứ đều tự động, người kiểm thử thủ công sẽ làm gì?
Trên thực tế, vấn đề là, bạn không thể tự động hóa 100% các trường hợp thử nghiệm của mình. Bởi vì chúng tôi, với tư cách là người kiểm thử, tin rằng không có ứng dụng nào có thể được kiểm thử 100%. Sẽ luôn có một số kịch bản mà chúng ta sẽ bỏ lỡ. Sẽ luôn có những lỗi chỉ xuất hiện khi ứng dụng của bạn được khách hàng sử dụng.
Vậy nếu ứng dụng không thể được kiểm kiểm thử phần mềm 100%, làm thế nào bạn có thể hứa tự động hóa 100%?
Ngoài ra, có một cơ hội rất nhỏ rằng bạn sẽ có thể tự động hóa tất cả các trường hợp thử nghiệm hiện tại của bạn. Luôn có những kịch bản khó tự động hóa và dễ thực hiện thủ công hơn.
Ví dụ: Một người dùng sẽ nhập dữ liệu, người dùng thứ hai sẽ phê duyệt dữ liệu, người dùng thứ ba sẽ xem dữ liệu và người dùng thứ tư bị cấm xem dữ liệu. Những kịch bản này có thể được tự động hóa, nhưng chúng sẽ tốn rất nhiều thời gian và công sức. Vì vậy, nó sẽ dễ dàng hơn nếu bạn chỉ làm điều đó bằng tay.
Hãy nhớ rằng, chúng tôi sử dụng ô tô để đi khoảng cách, nhưng có thể có tín hiệu dài trên đường, sẽ có mức tiêu thụ nhiên liệu, sẽ có vấn đề về chỗ đậu xe, phí đỗ xe và đau đầu hơn rất nhiều. Trong một số kịch bản, chúng tôi chỉ cần đi bộ và đạt đến đích của chúng tôi :) .
Vì vậy, bạn không nên cố gắng tự động hóa mọi thứ. Chỉ tự động hóa các kịch bản quan trọng và mất nhiều thời gian để thực hiện thủ công.
Quan niệm sai lầm # 3 . Tự động hóa chỉ liên quan đến ghi âm và phát lại.
Xin đừng sống trong một thế giới giả tưởng. Sự tưởng tượng này thực sự được tạo ra bởi các quảng cáo sai lệch từ các nhà cung cấp công cụ tự động hóa khác nhau. Họ nói rằng bạn chỉ cần ghi lại và phát lại các bước của bạn và các trường hợp thử nghiệm của bạn sẽ được tự động. Chà, đó là một lời nói dối lớn!
Tự động hóa là tất cả mọi thứ, nhưng ghi âm và phát lại. Các kỹ sư tự động hóa thuần túy thường không sử dụng tính năng ghi và phát lại. Ghi và phát lại thường được sử dụng để có ý tưởng về cách công cụ tạo tập lệnh cho các bước của chúng tôi.
Khi biết được kịch bản chúng tôi luôn sử dụng kịch bản để tạo các bài kiểm thử phần mềm tự động. Hãy nhớ rằng, bạn phải biết lập trình nếu bạn muốn làm tự động hóa thử nghiệm . Mặt khác, đừng nản lòng nếu bạn không biết lập trình. Bởi vì giống như bất kỳ nhiệm vụ nào khác, lập trình cũng có thể được học bằng thực tiễn và sự cống hiến.
Tôi đã biết những người, những người thậm chí không đến từ nền tảng khoa học máy tính, nhưng họ học lập trình và bây giờ họ là những kỹ sư tự động hóa tuyệt vời. Tại Microsoft, họ thuê những người thử nghiệm có thể làm lập trình. Chúng được gọi là SDET (Kỹ sư phát triển phần mềm để kiểm thử). Dòng đầu tiên của bản mô tả công việc nói rằng SD SDET viết rất nhiều mã.
Tương tự với thử nghiệm tự động hóa. Bạn sử dụng nó để nhanh chóng kiểm thử hầu hết các bài kiểm thử lặp đi lặp lại, dài và nhàm chán của bạn và tiết kiệm thời gian và năng lượng của bạn để tập trung và kiểm thử chức năng mới và quan trọng.
Như James Bach đã nói một câu trích dẫn tuyệt vời:
Công cụ không kiểm thử . Chỉ có người kiểm thử . Các công cụ chỉ thực hiện các hành động mà người Viking giúp kiểm thử . Cúc
Công cụ có thể nhấp vào đối tượng. Nhưng nơi để nhấp sẽ luôn được nói bởi một người kiểm thử thủ công. Tôi nghĩ rằng bạn có được quan điểm của tôi bây giờ.
Quan niệm sai lầm # 2 . Mọi thứ dưới ánh mặt trời đều có thể được tự động
Nếu bạn cố gắng tự động hóa 100% các trường hợp thử nghiệm của mình, có thể bạn sẽ có thể làm như vậy, nhưng nếu điều đó bạn có thể làm, thì điểm đầu tiên của chúng tôi trở thành sai. Bởi vì nếu mọi thứ đều tự động, người kiểm thử thủ công sẽ làm gì?
Bối rối? Đúng?
Trên thực tế, vấn đề là, bạn không thể tự động hóa 100% các trường hợp thử nghiệm của mình. Bởi vì chúng tôi, với tư cách là người kiểm thử, tin rằng không có ứng dụng nào có thể được kiểm thử 100%. Sẽ luôn có một số kịch bản mà chúng ta sẽ bỏ lỡ. Sẽ luôn có những lỗi chỉ xuất hiện khi ứng dụng của bạn được khách hàng sử dụng.
Vậy nếu ứng dụng không thể được kiểm kiểm thử phần mềm 100%, làm thế nào bạn có thể hứa tự động hóa 100%?
Ngoài ra, có một cơ hội rất nhỏ rằng bạn sẽ có thể tự động hóa tất cả các trường hợp thử nghiệm hiện tại của bạn. Luôn có những kịch bản khó tự động hóa và dễ thực hiện thủ công hơn.
Ví dụ: Một người dùng sẽ nhập dữ liệu, người dùng thứ hai sẽ phê duyệt dữ liệu, người dùng thứ ba sẽ xem dữ liệu và người dùng thứ tư bị cấm xem dữ liệu. Những kịch bản này có thể được tự động hóa, nhưng chúng sẽ tốn rất nhiều thời gian và công sức. Vì vậy, nó sẽ dễ dàng hơn nếu bạn chỉ làm điều đó bằng tay.
Hãy nhớ rằng, chúng tôi sử dụng ô tô để đi khoảng cách, nhưng có thể có tín hiệu dài trên đường, sẽ có mức tiêu thụ nhiên liệu, sẽ có vấn đề về chỗ đậu xe, phí đỗ xe và đau đầu hơn rất nhiều. Trong một số kịch bản, chúng tôi chỉ cần đi bộ và đạt đến đích của chúng tôi :) .
Vì vậy, bạn không nên cố gắng tự động hóa mọi thứ. Chỉ tự động hóa các kịch bản quan trọng và mất nhiều thời gian để thực hiện thủ công.
Quan niệm sai lầm # 3 . Tự động hóa chỉ liên quan đến ghi âm và phát lại.
Xin đừng sống trong một thế giới giả tưởng. Sự tưởng tượng này thực sự được tạo ra bởi các quảng cáo sai lệch từ các nhà cung cấp công cụ tự động hóa khác nhau. Họ nói rằng bạn chỉ cần ghi lại và phát lại các bước của bạn và các trường hợp thử nghiệm của bạn sẽ được tự động. Chà, đó là một lời nói dối lớn!
Tự động hóa là tất cả mọi thứ, nhưng ghi âm và phát lại. Các kỹ sư tự động hóa thuần túy thường không sử dụng tính năng ghi và phát lại. Ghi và phát lại thường được sử dụng để có ý tưởng về cách công cụ tạo tập lệnh cho các bước của chúng tôi.
Khi biết được kịch bản chúng tôi luôn sử dụng kịch bản để tạo các bài kiểm thử phần mềm tự động. Hãy nhớ rằng, bạn phải biết lập trình nếu bạn muốn làm tự động hóa thử nghiệm . Mặt khác, đừng nản lòng nếu bạn không biết lập trình. Bởi vì giống như bất kỳ nhiệm vụ nào khác, lập trình cũng có thể được học bằng thực tiễn và sự cống hiến.
Tôi đã biết những người, những người thậm chí không đến từ nền tảng khoa học máy tính, nhưng họ học lập trình và bây giờ họ là những kỹ sư tự động hóa tuyệt vời. Tại Microsoft, họ thuê những người thử nghiệm có thể làm lập trình. Chúng được gọi là SDET (Kỹ sư phát triển phần mềm để kiểm thử). Dòng đầu tiên của bản mô tả công việc nói rằng SD SDET viết rất nhiều mã.
Không có nhận xét nào:
Đăng nhận xét