Tôi có một ứng dụng PHP rất lớn. Thường có 2-3 nhà phát triển làm việc trên toàn thời gian và chúng tôi đang đi đến điểm mà chúng tôi đang thực hiện các thay đổi và tạo ra các lỗi (tính năng ho!). Phần mềm không phức tạp mỗi lần nói, chỉ có rất nhiều điều đang diễn ra (35 ~ bộ điều khiển, về cùng một mô hình, v.v.).

Ngay cả việc cẩn thận cũng dễ dàng thay đổi quan điểm này (điều chỉnh id trên một phần tử) để phá hỏng truy vấn ajax xảy ra trong một số điều kiện đặc biệt (đăng xuất khi đứng bằng một chân).

Các bài kiểm tra đơn vị là điều đầu tiên nảy ra trong đầu, nhưng chúng tôi đã thử những điều này trên một ứng dụng khác và thật dễ dàng để quên chúng / hoặc dành nhiều thời gian hơn để viết bài kiểm tra sau đó làm bài kiểm tra. Chúng tôi có một môi trường dàn dựng nơi mã được kiểm tra trước khi đẩy trực tiếp.

Có lẽ chúng ta cần một người bán thời gian Q / A?

Bất cứ ai có bất kỳ đề nghị / suy nghĩ.

Có, bạn cần Q / A nhân viên. Một số trong nhiều lý do bao gồm

• Một người kiểm tra chuyên dụng tốn tiền, nhưng thường ít tiền hơn một nhà phát triển, vì vậy lợi ích của việc không sử dụng hết thời gian của bạn lớn hơn chi phí bổ sung.
• Một người kiểm tra chuyên dụng biết cách kiểm tra mọi thứ, đặc biệt là những thứ không rõ ràng về cách tự động hóa. Lái thử nghiệm tự động để tương tác với một hệ thống thông qua trình duyệt là một môn học có phần lông nhưng được thiết lập tốt. Nếu bạn nhận được một người đã biết cách thực hiện, bạn không cần phải dành nhiều thời gian hơn để học các công cụ và thiết lập tốt.
• Một người kiểm tra chuyên nghiệp biết làm thế nào để thực sự tìm thấy khuyết điểm. Họ có nhiều khả năng nghĩ giống như người dùng ứng dụng sẽ nghĩ, và do đó thực hiện những trạng thái trong hệ thống sẽ thực sự xuất hiện trong sản phẩm, điều đó có nghĩa là những lỗi đó có thể thấy rõ sẽ có xu hướng được tìm thấy sớm hơn , tiết kiệm cho bạn sự bối rối và chi phí cho các bản vá cực kỳ khẩn cấp.
• Tổng quát hóa điều đó, một người thử nghiệm không nghĩ như một nhà phát triển . Thật khó để truyền tải sự khác biệt này sẽ tạo ra bao nhiêu nếu bạn chưa từng trải qua. Có ý thức hay không, một nhà phát triển không muốn tìm lỗi. Họ biết cách hệ thống hoạt động và có xu hướng tránh các dữ liệu hoặc dữ liệu vô nghĩa điển hình (đối với họ) gây rắc rối trong cuộc sống thực. Nếu một cái gì đó hoạt động một cách bất ngờ, họ biết cách làm việc xung quanh nó và có xu hướng không xem đây là một khiếm khuyết. Họ không bao giờgặp khó khăn trong việc hiểu ý nghĩa của hệ thống, bởi vì họ đã viết chúng, mặc dù đây là nguyên nhân chính gây ra sự cố trong hầu hết các hệ thống thực. Tóm lại: lập trình viên có xu hướng xấu khi gặp phải những vấn đề điển hình mà người dùng gặp phải, bởi vì họ là những chuyên gia được đào tạo cao. Một người kiểm tra có một thời gian dễ dàng hơn nhiều để thực hiện các bài kiểm tra có liên quan nhất.

Điều đó nói rằng, không có gì đánh bại sự hợp tác hiệu quả giữa một nhà phát triển và một người thử nghiệm để lái chất lượng hệ thống qua mái nhà. Một nhà phát triển thường nhận thấy các triệu chứng rằng có gì đó không đúng trước khi người thử nghiệm thực hiện. Một nhà phát triển thường có thể tư vấn cho người kiểm tra cách tái tạo vấn đề hiệu quả hơn nhiều và cách viết báo cáo vấn đề phù hợp, tức là bao gồm các chi tiết thực sự cần thiết để tìm ra vấn đề. Nhưng tất cả điều đó đòi hỏi ít nhất một người thử nghiệm mà bạn có thể làm việc cùng.

Rất có thể bạn cần các bài kiểm tra hồi quy nhiều hơn hoặc tốt hơn (không phải kiểm tra đơn vị cụ thể ). Những loại xét nghiệm nào bạn nên tự phân tích, nhưng chúng sẽ phát hiện ra các lỗi bạn đang nói đến. Tôi khuyên bạn nên bắt đầu lập kế hoạch kiểm tra và ưu tiên các thử nghiệm đó - và khi bạn thực hiện việc này, ban đầu đừng nghĩ quá nhiều về tự động hóa thử nghiệm.

Sau đó, hãy tự hỏi nếu bạn có thể tự động hóa một số hoặc hầu hết các bài kiểm tra với nỗ lực hợp lý. Nếu câu trả lời là có, thì bạn nên lập trình chúng. Nếu câu trả lời là "không" và bạn nghĩ rằng "Q / A người bán thời gian" rẻ hơn, thì đó phải là obviuos những gì bạn cần. Trong hầu hết các trường hợp, nên có cả hai - một người Q / A để thử nghiệm thủ công và phát minh ra các thử nghiệm mới, và rất nhiều thử nghiệm hồi quy tự động, quá.

Thuê một QA chuyên nghiệp

Điều này nên được thực hiện nếu bạn đang phát triển một dự án thương mại. Có một sản phẩm sẵn sàng mà không có một chiến lược thử nghiệm mạnh mẽ sẽ khiến bạn tốn nhiều tiền hơn với các sửa lỗi. Ngoài ra, việc có được khách hàng mới hoặc giữ chân họ cũng sẽ phụ thuộc vào mức độ ứng dụng của bạn được kiểm tra.

Nói chung, kiểm thử đơn vị nên được áp dụng cho cơ sở mã của bạn, tuy nhiên kiểm thử tích hợp và kiểm tra thủ công không nên bị loại bỏ.

Kiểm thử đơn vị là một ý tưởng thực sự tốt, đặc biệt nếu dự án của bạn đang phát triển. Nếu viết bài kiểm tra đơn vị trở thành thói quen, nó sẽ giảm bớt công việc của bạn rất nhiều. Có một video trên youtube về cách viết mã sạch, dễ bảo trì và kiểm tra hơn.

Kỹ sư QA là phải, quá. Một người kiểm tra QA tốt sẽ không chỉ tìm thấy các lỗi trong chức năng, mà còn kiểm tra xem ứng dụng có thân thiện với người dùng hay không (gần như không thể tự kiểm tra). Dưới đây là một bài viết hay giải thích cách nhóm QA sẽ giúp bạn tiết kiệm thời gian và tiền bạc và giúp cung cấp phần mềm tốt hơn.

15 bộ điều khiển và mô hình không lớn lắm. Phải mất một thời gian để biến bài kiểm tra viết thành thói quen, đá nhau về phía nó (theo cách thân thiện trước tiên) giúp ích rất nhiều.

Có các công cụ có thể kiểm soát phạm vi kiểm tra đến một số mở rộng. Công cụ bảo hiểm mã cho PHP