Thực tiễn tốt nhất để kiểm tra hồi quy Trang web WordPress?


22

Chào mọi người,

Tôi muốn nghe những gì người khác đang cung cấp các giải pháp phi blog phức tạp cho khách hàng với WordPress như một nền tảng mà họ đang sử dụng để Kiểm tra hồi quy tự động ?

Đối với những người không quen thuộc với thuật ngữ "kiểm tra hồi quy" Wikipedia định nghĩa nó là:

Kiểm tra hồi quy là bất kỳ loại kiểm thử phần mềm nào tìm cách phát hiện ra lỗi phần mềm sau khi thay đổi chương trình (ví dụ: sửa lỗi hoặc chức năng mới) đã được thực hiện, bằng cách kiểm tra lại chương trình. Mục đích của kiểm tra hồi quy là để đảm bảo rằng một thay đổi, chẳng hạn như một lỗi, không đưa ra các lỗi mới.

Nói nhiều hơn với Wikipedia cho biết những điều sau đây chính xác là những gì tôi đang trải nghiệm trong một dự án ngay bây giờ:

Kinh nghiệm đã chỉ ra rằng khi phần mềm được sửa chữa, sự xuất hiện của lỗi mới và / hoặc tái xuất hiện các lỗi cũ là khá phổ biến. Đôi khi sự tái xuất hiện xảy ra do một bản sửa lỗi bị mất thông qua các thực tiễn kiểm soát sửa đổi kém (hoặc lỗi đơn giản của con người trong kiểm soát sửa đổi). Thông thường, một bản sửa lỗi cho một vấn đề sẽ "dễ vỡ" ở chỗ nó khắc phục sự cố trong trường hợp hẹp khi nó được quan sát lần đầu nhưng không phải trong các trường hợp tổng quát hơn có thể phát sinh trong suốt vòng đời của phần mềm. Thông thường, việc khắc phục sự cố ở một khu vực vô tình gây ra lỗi phần mềm ở khu vực khác. Cuối cùng, thông thường là khi một số tính năng được thiết kế lại, một số lỗi tương tự đã xảy ra trong quá trình triển khai ban đầu của tính năng đã được thực hiện trong thiết kế lại.

Với tính chất toàn cầu của các hành động và bộ lọc, tôi thấy rằng sự phức tạp bắt đầu tăng lên khi tôi thêm nhiều chức năng do khách hàng yêu cầu và thật khó để có một plugin phức tạp ổn định, đặc biệt là nếu nó sử dụng nhiều cuộc gọi đến WP_Queryvà cập nhật cơ sở dữ liệu rất nhiều .

Giải pháp trong đầu tôi là thiết lập thử nghiệm hồi quy với một loạt "trường hợp thử nghiệm" để bao gồm một "bộ thử nghiệm". Về khái niệm, không khó lắm khi bạn đang kiểm tra đầu ra HTML của các yêu cầu HTTP GET. Nhưng nó phức tạp hơn một chút khi bạn phải kiểm tra mọi thứ khi đăng nhập thông qua bảng điều khiển quản trị và / hoặc để kiểm tra các tương tác jQuery.

Tôi đang thiết lập trang này như một wiki cộng đồng với hy vọng chúng ta có thể thu thập các thực tiễn tốt nhất ở đây nhưng tôi thực sự lo lắng khi nghe các quy trình nếu có bất kỳ chuyên gia WordPress nào khác đang sử dụng.


Tôi giả sử bạn đang nói về việc kiểm tra mã của riêng bạn (chủ đề / plugin)? Khi bạn tạo mã mới hoặc khi bạn cập nhật "môi trường" (WP, các plugin khác)? Hoặc cả hai? Tôi nghĩ Pro Webmaster cũng có thể chứa lời khuyên tốt về cách kiểm tra các ứng dụng web (Selenium và các thứ) - có thể đăng bài chéo là một ý tưởng tốt?
Jan Fabry

@Jan Fabry - Vâng, kiểm tra mã của riêng tôi. Ý tưởng tốt về đăng bài chéo, tôi sẽ làm điều đó sớm thôi.
MikeSchinkel

Câu trả lời:


10

PHPUnit sẽ xuất hiện trong tâm trí, nếu bộ kiểm thử WP không bị hỏng và nếu WP được thiết kế và viết theo cách mà nó thực sự có thể được kiểm tra đúng cách. ;-)

Nghiêm trọng hơn, bạn có thể kiểm tra các plugin của mình tất cả những gì bạn muốn từ quan điểm chức năng của chúng bằng các bài kiểm tra đơn vị và tương tự. Vấn đề là các thử nghiệm này sẽ không đảm bảo rằng chúng sẽ nắm bắt các cơ hội tinh tế được giới thiệu bởi các bản nâng cấp WP, chứ chưa nói đến việc chúng sẽ tiếp tục hoạt động sau khi cắm vào bản cài đặt WP tùy chỉnh.

Trong số những điều đầy màu sắc tôi đã thấy xảy ra:

  • Một thay đổi tinh tế trong API WP ảnh hưởng đến chức năng của plugin của bạn, ví dụ: hook bạn đang sử dụng để lấy id thuật ngữ và giờ đây nó nhận được id phân loại thuật ngữ. (Rất có thể là các điều khoản kiểm tra của bạn thuận tiện có cùng một id cho cả hai).

  • Một thay đổi tinh tế trong API WP dẫn đến việc bạn nhận được một WP_Errorđối tượng thay vì giá trị dự kiến ​​trước đó falselà đầu vào xấu.

  • Plugin của bạn được thêm từ trong thư mục mu-plugins, dẫn đến một luồng mã khác biệt tinh tế.

  • Plugin của bạn hoạt động tốt cho đến khi memcached hoặc một số cửa hàng liên tục khác được kích hoạt.

  • Plugin của bạn hoạt động tốt cho đến khi switch_to_blog () bị coi thường được gọi.

  • Một plugin thay đổi hook mà nó cư trú khi được gọi và vô tình làm gián đoạn nó như một tác dụng phụ.

  • Một plugin (un?) Cố tình làm rối tung dữ liệu đầu vào hoặc đầu ra của bạn đến mức mọi thứ bị hỏng ngay cả khi bạn không có lỗi.

Tôi có thể mở rộng danh sách trên và trên, nhưng đó sẽ là những mục chính phá vỡ các plugin của riêng tôi. Hai mặt hàng được cho là có thể bắt được với các bài kiểm tra đơn vị. Hai người tiếp theo cũng vậy, nếu bạn đủ kiên nhẫn, nhưng tôi cho rằng WP không nên thay đổi cách mọi thứ hoạt động khi chúng xảy ra. Không có số lượng thử nghiệm nào sẽ hoạt động xung quanh việc triển khai lỗi của switch_to_blog (). Và hai người cuối cùng là vô vọng không thể kiểm chứng.

Ồ, và ... thậm chí đừng để tôi bắt đầu với sự tấn công của các tệp đính kèm, bản nháp tự động, sửa đổi, các mục menu và những thứ không được lưu trữ trong bảng bài viết.

Chúc may mắn... :-)


2
Câu trả lời tốt đẹp, cảm ơn cho tất cả các chi tiết bạn bao gồm. FWIW Tôi đang tìm kiếm thử nghiệm "hồi quy" nhiều hơn thử nghiệm "đơn vị" . Tôi biết có rất nhiều sự trùng lặp nhưng vấn đề lớn nhất của tôi hiện tại là xác minh rằng trang web không bị hỏng. Có đơn vị kiểm tra một plugin có thể nắm bắt được hầu hết các vấn đề nhưng phải mất nhiều thời gian và công sức hơn để có được phạm vi bảo hiểm đầy đủ trong các thử nghiệm đơn vị (có nghĩa là tôi có thể không nhận được bảo hiểm đầy đủ) trong khi kiểm tra toàn bộ trang được yêu cầu ít chi tiết hơn.
MikeSchinkel

1
Trên thực tế, lưu ý rằng có các công cụ trong một số khung nhất định (Symfony2 và Li3 để đặt tên nhưng hai) cho phép kiểm tra một trang web thực tế, sử dụng trình duyệt giả tưởng. Các thành phần trong câu hỏi có thể tái sử dụng cho những thứ khác. Do đó, bạn thực sự có thể thao túng màn hình quản trị trang web của mình và xác minh rằng những gì bạn đang làm có kết quả như mong đợi.
Denis de Bernardy

7

Bạn nên xem xét mạnh mẽ Selenium .

Nó cho phép bạn ghi lại các hành động (ví dụ: nhập dữ liệu vào biểu mẫu, nhấp vào liên kết) và sau đó bạn có thể thực hiện các xác nhận. Nó cũng tích hợp với PHPUnit. Tôi rất khuyên bạn nên kiểm tra bản demo hai phút.


Cảm ơn về lời đề nghị, tôi đã nghe về nó trước đây. Bạn đã thực sự sử dụng cho các dự án WordPress? Chỉ tò mò thôi.
MikeSchinkel

Vâng. Tôi đã sử dụng nó để thử nghiệm một plugin tôi đang làm việc. Ở kiếp trước, chúng tôi đã sử dụng nó để kiểm tra các ứng dụng EDC cho nghiên cứu lâm sàng.
Ethan Seifert

1

Selenium có thể có thể sử dụng được nhưng tôi nghĩ rằng trong thời hiện đại, bạn sẽ thấy Codecellect trở nên tốt hơn và dễ sử dụng hơn. Đối với thử nghiệm hồi quy trực quan đơn giản nhất , nó thậm chí còn có một tiện ích mở rộng sẽ chụp ảnh màn hình và tự động so sánh chúng cho bạn.

Tất nhiên, các bài kiểm tra Codecellect WebDriver có thể tiến xa hơn và thực hiện các bài kiểm tra hồi quy chức năng . Bạn có thể điền và gửi biểu mẫu, nhấp vào nút và liên kết trên trang web, thực thi bất kỳ JS, v.v. Bạn có thể sử dụng trình duyệt thực tế như Firefox hoặc Chrome trong các thử nghiệm của mình hoặc bạn có thể thực hiện kiểm tra không đầu với PhantomJS . Điều đó có nghĩa là bạn thậm chí có thể chạy thử nghiệm WebDriver cho plugin của mình như một phần của quy trình xây dựng trên Travis CI nếu bạn muốn.

Thậm chí còn có một số thư viện dành riêng cho WordPress để giúp bạn bắt đầu:


1
Selenium và Codecellect không độc quyền. Bạn có thể sử dụng WP-Browser để lái Selenium [điều khiển một trình duyệt thực tế như Chrome], Phantom [là một trình duyệt không có gui hỗ trợ JS] hoặc thậm chí là PHPBrowser là trình duyệt câm lặng [rất nhanh nhưng không có JS. tức là kiểm tra API]. WP-Browser có thể lái bất kỳ trong số họ.
Jim Maguire
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.