Chúng tôi đang dành nhiều thời gian để thực hiện kiểm tra chức năng hơn là tự thực hiện hệ thống, điều này có bình thường không?


12

Về cơ bản, chúng tôi có ba dự án chính, hai trong số đó là các dịch vụ web và hai là một ứng dụng web. Mặc dù tôi hài lòng với việc cung cấp các dịch vụ web của mình nhiều nhất có thể bằng các thử nghiệm chức năng (cả ba dự án đều có các thử nghiệm đơn vị phù hợp), các thử nghiệm chức năng cho ứng dụng web đang mất rất nhiều thời gian để nhà phát triển triển khai. Ý tôi là rất nhiều lần, hoặc đôi khi nhiều hơn, thời gian cần thiết để thực hiện chức năng đang được thử nghiệm với kiểm tra đơn vị đi kèm.

Chính sách của người quản lý là kiểm tra mọi chức năng đơn lẻ mà chúng tôi thêm vào, ngay cả khi không phải là vấn đề quan trọng trong kinh doanh (tức là CRUD mới).

Tôi đồng ý với việc kiểm tra tất cả các chức năng của dịch vụ web, vì khó kiểm tra thủ công chúng, đồng thời, kiểm tra này chạy nhanh và không mất nhiều thời gian để thực hiện.

Vì vậy, giá trị của việc dành nhiều thời gian để viết bài kiểm tra chức năng, hơn là viết mã hệ thống, kiểm tra đơn vị và sửa lỗi QA là gì? Điều này có bình thường không? Chúng ta không nên viết các bài kiểm tra chức năng chỉ cho chức năng quan trọng và để QA thực hiện kiểm tra hồi quy không có chức năng quan trọng?

Lưu ý: chúng tôi không phát triển phần mềm y tế hoặc phần mềm NASA hoặc không có gì quan trọng.


14
Chúng tôi không có bài kiểm tra. Chúng tôi dành một lượng lớn thời gian để sửa chữa mọi thứ sau khi thực tế. "Bạn có thể trả tiền cho tôi ngay bây giờ, hoặc bạn có thể trả tiền cho tôi sau." Nó sau này và nó không đẹp.
MetalMikester

3
Có - một phần của bức tranh chắc chắn là một bộ kiểm tra được duy trì tốt sẽ giảm thời gian cần thiết để thực hiện thực tế.
Michael Borgwardt


Câu trả lời:


16

Kiểm tra chức năng là rất quan trọng. Vâng, họ mất thời gian để viết nhưng nếu bạn đang viết đúng bài kiểm tra chức năng, họ sẽ có giá trị hơn nó.

Có một vài lý do tốt để thực hiện các bài kiểm tra chức năng tự động trên một ứng dụng.

  • Khi một tính năng mới được thêm vào trang web của bạn, nó sẽ cho bạn biết ngay nếu những thay đổi được thực hiện cho tính năng mới đó phá vỡ mọi chức năng khác trên trang web của bạn.
  • Đó là tài liệu kiến ​​thức về cách ứng dụng chạy và làm việc cùng nhau để đạt được các yêu cầu kinh doanh.
  • Khi đến lúc cập nhật thư viện của bên thứ 3, bạn có thể cập nhật nó và chạy bộ kiểm tra chức năng của mình để xem có gì bị hỏng không. Thay vì phải tự mình đi qua từng trang, bạn có thể có một máy tính làm điều đó cho bạn và đưa cho bạn một danh sách tất cả các bài kiểm tra đã bị hỏng.
  • Tải thử nghiệm! Bạn có thể mô phỏng hàng ngàn người dùng đồng thời tất cả truy cập trang web của bạn cùng một lúc và bạn có thể thấy trang web của mình chậm lại và oằn xuống dưới áp lực. Bạn có thể thấy trang web của bạn hoạt động như thế nào lâu trước khi bạn nhận được một cuộc gọi đêm khuya rằng trang web đã bị sập.
  • Kiểm tra chức năng cần có thời gian để làm thủ công. Có, phải mất nhiều thời gian để viết các trường hợp, nhưng nếu bạn phải ngồi xuống với một cuốn sổ có 500 trang bài kiểm tra mà bạn phải hoàn thành trước khi bạn có thể gửi sản phẩm bạn muốn bạn có các bài kiểm tra tự động!
  • Tài liệu kiểm tra ra khỏi ngày nhanh chóng. Khi một tính năng mới được thêm vào, bạn phải đảm bảo cập nhật tài liệu thử nghiệm chính. Nếu ai đó bỏ qua một số bài kiểm tra, bạn sẽ bất ngờ gặp lỗi khi vào các trang được "thực hiện và kiểm tra". Tôi hiện đang làm việc trong một môi trường như vậy và tôi có thể đảm bảo với bạn, đó là một cơn ác mộng.

Cuối cùng, có thời gian để viết những trường hợp này, nhưng bạn nên tự hào khi viết chúng. Đó là cách bạn chứng minh, vượt ra khỏi sự nghi ngờ rằng mã của bạn hoạt động và nó hoạt động với tất cả các tính năng khác ngoài kia. Khi QA đến gặp bạn và nói có lỗi, bạn sửa nó và sau đó thêm nó vào bộ kiểm tra của bạn để cho thấy rằng nó đã được sửa và đảm bảo nó không bao giờ xảy ra nữa.

Đây là mạng lưới an toàn của bạn. Khi ai đó đi vào và chiếm quyền điều khiển được lưu trữ và thực hiện một thay đổi nhỏ để nó hoạt động với mã của họ, bạn sẽ thấy rằng nó đã phá vỡ 3 tính năng khác trong quy trình. Bạn sẽ bắt được nó đêm đó và không đêm trước thời hạn!

Đối với việc viết các bài kiểm tra chức năng cho các chức năng quan trọng của hệ thống. Điều đó sẽ không cung cấp cho bạn toàn bộ hình ảnh và nó sẽ cho phép các con bọ lén lút. Tất cả chỉ cần cho một tính năng nhỏ được thêm vào không phải là hệ thống quan trọng, nhưng tương tác gián tiếp với chức năng quan trọng của hệ thống và bạn có khả năng gặp lỗi.


cảm ơn câu trả lời của bạn. Tôi nhận thức được tầm quan trọng và lợi ích của các xét nghiệm chức năng, mối quan tâm của tôi là về lợi ích chi phí của việc thử nghiệm TẤT CẢ. Chúng tôi đã phát triển thử nghiệm chức năng trong ba năm qua, nhưng bây giờ trong dự án này, tôi cảm thấy rằng chi phí thực hiện thử nghiệm TẤT CẢ nhiều hơn nhiều so với việc tìm ra lỗi trong sản xuất, tăng vé và sửa chữa nó ... Tôi tự hỏi liệu tồn tại một số trường hợp trong đó KHÔNG thực hiện kiểm tra chức năng là tốt hơn (về lợi ích chi phí) so với không thực hiện và tôi tự hỏi nếu chúng ta ở trong hoàn cảnh như vậy, thì tốt hơn nên chọn cách nào để kiểm tra.
Pablo Lascano

@donsenior ~ nếu bạn cảm thấy mất quá nhiều thời gian để kiểm tra, thì hãy xem các công cụ bạn đang sử dụng. Bạn đang sử dụng chúng đúng cách? Bạn thậm chí đang sử dụng các công cụ tiết kiệm thời gian? Viết bài kiểm tra mất nhiều thời gian hơn viết mã b / c bạn có nhiều mã để viết. Đó là bản chất của thử nghiệm. Nếu bạn bắt đầu chọn và chọn những gì để viết bài kiểm tra, thì sẽ đến lúc không ai sẽ viết bài kiểm tra, hoặc những bài kiểm tra đó sẽ cẩu thả.
Tyanna

ý tưởng của tôi để chọn những gì cần kiểm tra, không phải là một lựa chọn ngẫu nhiên, nhưng chọn chức năng kinh doanh quan trọng nhất (và đây không phải là quyết định của nhà phát triển, mà là của người quản lý). Và tôi nghĩ ngược lại, các nhà phát triển có xu hướng viết bài kiểm tra cẩu thả ngay bây giờ vì họ phải kiểm tra tất cả, thậm chí chức năng đó mất năm phút để QA kiểm tra và hai ngày để nhà phát triển tự động hóa. Tôi đồng ý rằng có lẽ các công cụ chúng tôi đang sử dụng không phải là tốt nhất để thử nghiệm ứng dụng web của chúng tôi (fitnesse và java). Tôi e rằng chúng ta đang tiếp cận điểm viết và duy trì kiểm tra chức năng nhiều hơn hệ thống
Pablo Lascano

@donsenior ~ Chắc chắn, phải mất 5 phút QA để kiểm tra một trường hợp, nhưng phải mất một máy tính ít hơn một giây để kiểm tra nó. Bạn nên hỏi "Tại sao phải mất 2 ngày để viết một cái gì đó mất 5 phút để kiểm tra bằng tay"? Một lần nữa, nhìn vào công cụ của bạn. Có lẽ QA cũng nên viết một số trường hợp thử nghiệm? Vấn đề không phải là viết trường hợp kiểm thử cho hệ thống của bạn, đó là cách các trường hợp kiểm thử đó được viết.
Tyanna

tốt, các bài kiểm tra này mất nhiều hơn một giây để chạy (hãy nhớ rằng đây là các bài kiểm tra chức năng, không phải bài kiểm tra đơn vị). Nhưng đó không phải là vấn đề, họ chạy vào ban đêm. Tôi nghĩ bạn cũng đúng khi nói rằng QA cũng nên viết một số trường hợp thử nghiệm, nhưng thật đáng buồn đó không phải là quyết định mà tôi có thể đưa ra. Cảm ơn rất nhiều vì câu trả lời của bạn, tôi đã đánh dấu câu này là được chấp nhận!
Pablo Lascano

7

Hơn 2 lần ... có vẻ hơi nhiều với tôi. Bạn có thể muốn phân tích lý do cho việc này, chúng có thể bao gồm:

  • hỗ trợ công cụ xấu để tạo và bảo trì các bài kiểm tra

  • hợp đồng của các dịch vụ web không được mô tả đầy đủ trong thiết kế. Các nhà phát triển cần phải thực hiện các hợp đồng trong khi thử nghiệm, thường là quá trình căn chỉnh tốn thời gian.

Nói chuyện với các nhà phát triển của bạn.

Giả sử bạn đang phát triển trong các lần chạy nước rút, có các bài kiểm tra chức năng này nếu chỉ là một phần của lần chạy nước rút. Nó không được thực hiện mà không có các xét nghiệm này. Nếu bạn không có nó, thời gian của bạn để thử nghiệm tích hợp sau giai đoạn phát triển có thể tăng gấp đôi.


Tôi đồng ý, có lẽ chúng tôi không sử dụng đúng công cụ để kiểm tra ứng dụng web. Không có vấn đề về thử nghiệm dịch vụ web của chúng tôi mặc dù. Dù sao, bên cạnh việc đúng hay sai về cách chúng tôi thực hiện các bài kiểm tra, tôi lo ngại về các chi phí. Tôi nghĩ rằng tại thời điểm này, tốt hơn (về chi phí / lợi ích) để cho một số thử nghiệm cho bộ phận QA và sửa các lỗi ngay cả khi chúng được tìm thấy trong sản xuất.
Pablo Lascano

Bạn bỏ các lớp được thiết kế kém là lý do có thể khiến bạn mất quá nhiều thời gian để kiểm tra. Đây là lý do phổ biến nhất mà tôi thấy khi mọi người mất kiểm tra mãi mãi mã của họ.
Dunk

4

Là dành nhiều thời gian để thực hiện kiểm tra chức năng hơn là thực hiện hệ thống bình thường?

Chắc chắn rồi. Viết các bài kiểm tra thực sự tốt có thể sẽ chiếm phần lớn thời gian trong nhiều cửa hàng (tốt).
Vì vậy, tỷ lệ 2-1 là tốt. Bản thân các nhà phát triển ít kinh nghiệm thường không dành toàn bộ thời gian cho các bài kiểm tra.


2

Có luật giảm lợi nhuận. Giả sử bạn viết các bài kiểm tra cho mã rủi ro nhất trước tiên, giá trị được tạo ra bởi các bài kiểm tra tiếp theo sẽ giảm dần theo thời gian.

Kiểm thử đơn vị là mã, vì vậy chúng sẽ chứa lỗi (giống như tất cả các mã khác). Sửa những lỗi đó cần có thời gian.

Theo kinh nghiệm của tôi, các bài kiểm tra đơn vị chứa nhiều lỗi hơn nhiều so với hệ thống mà chúng đang kiểm tra và việc sửa chúng là một gánh nặng liên tục.


1

Đây là về chất lượng.

Nếu bạn cần có được thị trường - bạn sẽ phát triển ứng dụng của mình càng nhanh càng tốt. Bạn thậm chí có thể không có bài kiểm tra tự động nào cả =) nhưng bạn sẽ cung cấp ứng dụng của mình cho thính giác trước đối thủ cạnh tranh.

Nhưng nếu bạn biết rằng thính giác của bạn sẽ không biến mất, bạn sẽ làm bất cứ điều gì bạn không thể làm họ thất vọng. Mỗi vé lỗi sẽ làm giảm danh tiếng của bạn. Hãy tưởng tượng rằng một lỗi sẽ loại bỏ 50 phần trăm danh tiếng của bạn, phần tiếp theo - 25 phần trăm khác và một phần khác. Vì vậy, có thể có quá nhiều bài kiểm tra?


Vâng, tôi không thực sự chắc chắn nếu tại thời điểm này chúng tôi thực sự đang giảm vé. Có thể chúng tôi đã giảm (nhưng không nhiều) vé QA, nhưng tỷ lệ lỗi được tìm thấy trong thử nghiệm này không đủ lớn (theo quan điểm của tôi) để chứng minh chi phí như vậy khi có 2/3 thời gian phát triển phần mềm kiểm tra chức năng.
Pablo Lascano

0

Nếu "bình thường", bạn hỏi nó có phổ biến không, chắc chắn là không. Rất nhiều nhóm phát triển có các bài kiểm tra kém (tôi thuộc về một) và thậm chí cả những cuốn sách chất lượng mà tôi đã đọc lời khuyên nên dành thời gian mã hóa chức năng nhiều hơn so với các bài kiểm tra. Nếu bình thường bạn hỏi nó có khỏe không thì còn tùy, nhưng xét nghiệm nhiều hơn hai lần thì tốt hơn là không kiểm tra.

Nó không phải là quan trọng . Khi bạn kiểm tra một chức năng, bạn kiểm tra một cái gì đó hữu ích cho người dùng cuối và bạn có trách nhiệm phải biết (và không đoán) đó là tất cả thời gian hoạt động chính xác. Nếu bạn cần nhiều hơn hai lần cho mục tiêu đó, thì nó nên được thực hiện theo cách đó - nếu có thể.

Cũng có thể chính sách của bạn quá nghiêm ngặt đối với các bài kiểm tra tự động, nhưng thật khó để nói mà không biết chất lượng mà họ đang nhắm đến, nguồn tài nguyên của họ và những gì họ có thể sắp xếp nó.

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.