2010-06-15 38 views
19

Thử nghiệm có thể được phân loại chủ yếu vào thử nghiệm thủ công và tự động. Đối với những câu hỏi nhất định này, hãy nhớ.Thử nghiệm thủ công Vs Thử nghiệm tự động

Chúng bao gồm:

  • sự khác biệt cơ bản giữa hai loại xét nghiệm là gì?

  • Các yếu tố của thách thức tham gia vào cả thử nghiệm thủ công và tự động là gì?

  • Các kỹ năng khác nhau đặt được yêu cầu bởi trình kiểm tra phần mềm để kiểm tra thủ công và tự động tương ứng là gì?

  • khác nhau triển vọng việc và các cơ hội tăng trưởng trong kiểm thử phần mềm người làm kiểm tra thủ công tự động kiểm tra tương ứng là gì?

  • Kiểm tra thủ công có được xếp hạng theo số để tự động kiểm tra (các) trường hợp không? Nếu có, làm thế nào?

  • Trình kiểm tra thủ công được xử lý như thế nào so với những người thử nghiệm tự động trong thế giới của công ty? (Nếu họ thực sự được phân biệt trong bất kỳ điều khoản như vậy)

Trả lời

14

Thử nghiệm tự động là bất kỳ loại thử nghiệm nào mà bạn đang sử dụng một đoạn mã/chương trình để kiểm tra một đoạn mã/chương trình khác. Đây có thể là thử nghiệm đơn vị như mô tả ở trên, hoặc nó có thể thông qua một công cụ tự động hóa cụ thể, như TestComplete, QTP, Selenium, vv .. Các bài kiểm tra đơn vị có xu hướng được tạo và thực hiện bởi nhà phát triển mã được đề cập, trong khi tự động hóa GUI sẽ có thể được thực hiện bởi một chuyên gia QA phần mềm. Một số loại thử nghiệm nhất định, chẳng hạn như kiểm tra hiệu suất và hồi quy, rất phù hợp với tự động hóa, trong khi các loại khác, chẳng hạn như kiểm tra khả năng sử dụng, thì không.

Kiểm tra thủ công là một quá trình mà một người trực tiếp kiểm tra một phần mềm, thường bằng cách thực hiện loại hành động và người dùng cuối có thể thực hiện. Nhiều người thử nghiệm chuyên nghiệp, chẳng hạn như những người tham gia thử nghiệm thăm dò, sẽ đề nghị bạn trong khi thử nghiệm đơn vị có hiệu quả về chi phí, việc kiểm tra thủ công cũng quan trọng và hiệu quả về chi phí.

Để biết một số thông tin chi tiết tuyệt vời về những cạm bẫy của thử nghiệm tự động, bạn nên đọc Linda Wilkinsons recent blog. Các tài nguyên hữu ích khác để đọc bao gồm các cuộc thảo luận từ the software testing clubautomated testing part of SQAForums.

Nếu bạn chưa làm như vậy, SQAforums cũng đáng tham gia để đặt bất kỳ câu hỏi nào liên quan đến những gì liên quan đến thử nghiệm, cũng như cho triển vọng công việc.

+0

Hi Shane .. Cảm ơn bạn đã trả lời .. Tôi xin lỗi vì đã trả lời muộn bài đăng của bạn .. Cũng rất cám ơn các liên kết .. :) .. chúng thực sự hữu ích .. – boddhisattva

4

Automated kiểm tra (kiểm tra đơn vị đặc biệt là tự động) là tốt vì nó có nghĩa là bạn có thể kiểm tra trước đó trong chu kỳ phát triển và bạn có thể giữ kiểm tra thường xuyên; nó cho phép các nhà phát triển xác định nơi họ đã mắc lỗi trước khi liên quan đến nhóm QA. Nhưng điều đó không có nghĩa là QA là không cần thiết. Ngoài vấn đề đảm bảo rằng các bài kiểm tra tự động là bản thân họ thích hợp, cũng có vấn đề làm việc cho dù ứng dụng đang làm những gì nó cần; khá hiếm khi được hiểu hoàn toàn.

Cũng rất khó để tự động kiểm tra giao diện người dùng. Ví dụ, đánh giá liệu một biểu tượng có ý nghĩa và có vị trí phù hợp hay không là một vấn đề đối với người không phải máy tính, bởi vì máy tính không quan tâm nhưng người dùng thực hiện.

+0

Xin chào Donal Sir .. cảm ơn vì những hiểu biết của bạn về kiểm tra tự động. – boddhisattva

+0

Để ghi lại và chỉ ra tần suất bạn nên chạy thử nghiệm đơn vị, mỗi lần tôi biên dịch (tốt, biên dịch thành công) chạy lại các bài kiểm tra đơn vị của tôi. Khi tôi có một bản dựng mà tôi khá hài lòng, tôi chạy lại các bài kiểm tra tích hợp của mình (tôi có một chương trình riêng cho điều đó khi nó xảy ra). Những người khác chạy thử nghiệm chấp nhận của người dùng; sau khi tất cả, câu hỏi không có cho dù * tôi * hạnh phúc với họ, nhưng cho dù * họ *. –

-2

Để trả lời chỉ là câu hỏi đầu tiên của bạn: sự khác biệt cơ bản là kiểm tra thủ công giống như thử nghiệm, trong khi thử nghiệm tự động (thường) đang thử nghiệm. Nếu bạn không thể viết một đặc tả đầy đủ và chi tiết của các bài kiểm tra để chạy thì bạn không thực sự thử nghiệm. Và nếu bạn có thể làm thử nghiệm tự động. Điều này đúng cho dù kịch bản thử nghiệm của bạn được thực thi bởi một chương trình hay dạng sống dựa trên carbon theo sau nó một cách cứng nhắc.

Tôi sẽ để bạn giải thích các câu trả lời của tôi cho các câu hỏi còn lại từ tiền đề cơ bản mà tôi đã đề ra.

+0

Không phải bất kỳ đặc điểm kỹ thuật nào có thể được chạy bởi một máy tính. Ví dụ: "đảm bảo rằng các màu sắc phù hợp" vẫn được kiểm tra tốt hơn bằng carbon sau đó là silicon. – SWeko

+1

@SWeko: 'đảm bảo rằng màu sắc phù hợp' không phải là một thử nghiệm, nó là một cuộc thi sắc đẹp nhưng nó minh họa một trong những chi tiết tôi đã không chỉ ra: trừ khi bạn có thể làm cho mục tiêu kiểm tra của bạn, họ không kiểm tra. –

+2

Vì vậy, khả năng sử dụng không phải là một vấn đề trong phần mềm? Vì nó là một khái niệm hoàn toàn chủ quan? Hoặc chúng tôi có thể làm cho một số chỉ số làm đẹp màn hình :) Có rất nhiều điều đó là tầm thường có thể kiểm tra bằng tay, nhưng không thể tự động kiểm tra. Đôi khi cảm giác của bản thân phần mềm chỉ đơn giản là sai. – SWeko

6

Vâng, tôi chỉ có thể nói về ý kiến ​​và kinh nghiệm của tôi, và tôi chỉ là một nhà phát triển đã làm việc khá nhiều với các kỹ sư kiểm tra và QA. Dù sao, 2c của tôi:

Sổ tay khác biệt cơ bản nhất được thực hiện bằng tay, và tự động được thực hiện bằng máy tính :) Kết quả là quá trình kiểm tra thủ công có thể chậm hơn một mức tự động. Mặt khác, các thử nghiệm tự động chỉ có thể phát hiện các vấn đề mà chúng có nghĩa là phát hiện và không thể phát hiện hành vi cơ bản mới của một hệ thống.Điều đó về cơ bản có nghĩa là các bài kiểm tra tự động là lý tưởng cho việc kiểm tra hồi quy, khi nó được biết rõ những gì nên được thực hiện, làm thế nào, và những gì các kết quả đầu ra nên được.

Đối với các kỹ năng, kiểm tra thủ công về cơ bản có thể được thực hiện bởi bất kỳ ai trong suy nghĩ đúng, trong khi kiểm tra tự động phải được thực hiện bởi một người có ít nhất một số kinh nghiệm của nhà phát triển. Có những khuôn khổ cho phép dễ dàng ghi lại các bài kiểm tra web tự động, ví dụ, nhưng thường cần phải tinh chỉnh các kịch bản được ghi lại để phù hợp hơn với nhu cầu của thử nghiệm. Tất nhiên, các kỹ năng cơ bản cần thiết để thử nghiệm cũng phải có mặt ở bất cứ ai muốn có một công việc trong QA, như kiên nhẫn, chú ý đến từng chi tiết, khả năng tổ chức tuyệt vời, khả năng giao tiếp tuyệt vời, ...

Và cuối cùng, tôi không ' Tôi nghĩ rằng thử nghiệm thủ công được đánh giá thấp, nếu có, tôi nghĩ rằng thử nghiệm tự động không được sử dụng trong hầu hết các môi trường công ty mà tôi đã nhìn thấy. Nhưng, vâng, một số người (chủ yếu là các nhà quản lý, phải trung thực) giải thích đoạn trước của tôi là "bất kỳ ai cũng có thể làm các bài kiểm tra thủ công".

1

Sự khác biệt cơ bản nhất là cách kiểm tra được xác minh. Nó được thực hiện thông qua một kiểm tra lập trình hoặc là có một kiểm tra con người thực hiện?

Thách thức lớn với thử nghiệm tự động là nhận được các kiểm tra thủ công được tự động hóa và đảm bảo rằng không có nhu cầu giải thích về kết quả của con người, ví dụ: nếu một chương trình liên quan đến đầu ra âm thanh hoặc video, điều này có thể rất khó xác minh chính xác.

Cả hai yêu cầu sự chú ý đến kỹ năng chi tiết, kiên nhẫn và tổ chức để có uy tín khi nói, "Có, đây là sản phẩm/dịch vụ chất lượng cao". Sự khác biệt có thể đến nơi thử nghiệm tự động sử dụng phần mềm đặc biệt thường.

Kiểm tra thủ công có thể tốn kém vì có ai đó đang xem thử nghiệm đang chạy trong khi kiểm tra tự động thường có thể chạy mà không ai đó xem. Tuy nhiên, thử nghiệm thủ công có thể được đánh giá thấp khi nói đến những lĩnh vực mà mọi thứ có thể rất chủ quan như tạo kiểu trang web hoặc bài hát này có hiệu quả như thế nào nếu chúng ta thực hiện những thay đổi này? Đó sẽ là nơi tôi thấy một con người được ưa thích hơn một cỗ máy.

Đối với con đường sự nghiệp và cơ hội việc làm, đây là một mức độ nào đó là một câu hỏi mở. Vì không phải mọi nơi thuê người thử nghiệm và đôi khi người thử nghiệm chỉ được đưa vào khi cần thiết cho các dự án, có những quan điểm khác nhau về thử nghiệm.Điều này là không đưa vào câu hỏi bao nhiêu nhà phát triển nên viết các bài kiểm tra của riêng mình và thực hiện điều này cũng làm cho nhà phát triển trở thành người thử nghiệm không? Tôi cho rằng điều này không trả lời câu hỏi của bạn bởi vì tôi đang xem xét điều này ở quy mô lớn hơn của những người đang thực hiện thử nghiệm vì đó là điều gì đó khác để xem xét ở đây.

+0

Hi JB King ..: Cảm ơn bạn đã trả lời ngay cả những câu hỏi này .. Câu trả lời của bạn thực sự hữu ích ... Btw của bạn khá nhiều quyền mà câu trả lời của bạn trong một số cách không phải là chăm sóc câu hỏi về tăng trưởng, triển vọng công việc và câu hỏi cuối cùng cũng .. Nhưng anyways cảm ơn nhiều vì đã chia sẻ kinh nghiệm của bạn Sir .. Tôi xin lỗi vì đã trả lời muộn bài đăng của bạn .. – boddhisattva

0

Cách duy nhất để viết tất cả các bài kiểm tra khách quan là để lại một phần đáng kể các chi tiết cần thiết để thực sự đảm bảo phần mềm phù hợp với mục đích. Kết quả là phần mềm luôn là phần mềm mà bạn phải trả cho ai đó một tỷ lệ hàng giờ để sử dụng.

Điều này có thể không phải lúc nào cũng là vấn đề, nhưng tập hợp các trường hợp nó là một phần khá lớn của ngành công nghiệp phần mềm.

4
  • Lợi thế chính với thử nghiệm tự động là bạn có thể kiểm tra hồi quy nhanh chóng. Nhà phát triển có thể xác minh chức năng trước đó hoặc không sau khi thêm chức năng mới vào Hệ thống.
  • Vì vậy, khi bạn đang làm việc với thời hạn chặt chẽ, bằng cách sử dụng công cụ Tự động hóa, bạn có thể giảm nỗ lực thử nghiệm của mình .. do đó bạn chỉ phải kiểm tra những chức năng mà bạn chưa tạo tập lệnh thử nghiệm tự động. (Giống như kiểm tra thông báo Email/SMS, Khả năng tương thích trình duyệt/Giao diện người dùng, v.v.)
  • Ngày nay nhiều công ty đang sử dụng các công cụ tự động nguồn mở (như Selenium, OpenSTA, JMeter v.v.). Vì vậy, tốt hơn nếu bạn biết cách thử nghiệm một ứng dụng bằng cách sử dụng các công cụ phần mềm miễn phí này thay vì các công cụ được trả tiền.
Các vấn đề liên quan