Thực đơn
trang chủTrình duyệt

Kiểm tra kỹ thuật. Các bài kiểm tra để xác định khả năng kỹ thuật. Yêu cầu và ca kiểm thử Ma trận dấu vết


Kiểm thử phần mềm là một quá trình nghiên cứu phần mềm nhằm xác định lỗi và xác định sự tương ứng giữa hành vi thực tế và mong đợi của phần mềm, được thực hiện trên cơ sở một tập hợp các thử nghiệm được chọn lọc theo một cách nhất định. Theo nghĩa rộng hơn, kiểm thử phần mềm là một kỹ thuật để kiểm soát chất lượng của sản phẩm phần mềm, bao gồm thiết kế kiểm thử, thực hiện kiểm thử và phân tích kết quả thu được.

Rất thường xuyên, các sản phẩm phần mềm hiện đại được phát triển trong thời gian ngắn và với ngân sách dự án hạn chế. Lập trình ngày nay đã chuyển từ thể loại nghệ thuật sang thể loại thủ công cho hàng triệu chuyên gia. Nhưng thật không may, trong sự vội vàng như vậy, các nhà phát triển thường bỏ qua nhu cầu đảm bảo tính bảo mật cho sản phẩm của họ, từ đó khiến người dùng gặp phải những rủi ro phi lý. Kiểm soát chất lượng (kiểm thử) được coi là quan trọng trong quá trình phát triển phần mềm vì nó đảm bảo tính an toàn, tin cậy và tiện lợi của sản phẩm được tạo ra. Hiện nay, có rất nhiều cách tiếp cận và kỹ thuật để giải quyết vấn đề kiểm thử phần mềm, nhưng kiểm thử hiệu quả các hệ thống phần mềm phức tạp là một quy trình sáng tạo không tuân theo các quy tắc nghiêm ngặt và rõ ràng.

cấp độ kiểm tra

Kiểm tra đơn vị là một quy trình nghiên cứu phần mềm trong đó thành phần nhỏ nhất có thể, chẳng hạn như một lớp hoặc một chức năng, được thử nghiệm. Kiểm thử đơn vị thường được thực hiện bởi các nhà phát triển phần mềm.

  • Wikipedia. Kiểm tra đơn vị.
  • Đơn vị kiểm tra mã Visual C# trong ứng dụng Windows Store.

Thử nghiệm hội nhập là một quy trình nghiên cứu phần mềm nhằm kiểm tra giao diện giữa các thành phần hoặc hệ thống con.

  • Wikipedia. Thử nghiệm hội nhập.

Thử nghiệm hệ thống là một quá trình nghiên cứu phần mềm trong đó một hệ thống tích hợp được thử nghiệm để đảm bảo nó đáp ứng được yêu cầu của khách hàng. Thử nghiệm Alpha và Beta là các hạng mục con của thử nghiệm hệ thống.

Phân loại các loại thử nghiệm

Có một số tiêu chí thông thường để phân loại các loại thử nghiệm. Thông thường những điều sau đây được phân biệt:

Bằng đối tượng kiểm tra

Thử nghiệm chức năng- Kiểm thử phần mềm nhằm kiểm tra tính khả thi của các yêu cầu chức năng. Kiểm thử chức năng kiểm tra khả năng của phần mềm trong việc thực hiện chính xác các tác vụ mà người dùng yêu cầu.

  • Wikipedia. Thử nghiệm chức năng.
  • StackOverflow. Kiểm tra đơn vị so với Kiểm tra chức năng.

Kiểm tra năng suất- kiểm thử phần mềm, cho phép bạn đánh giá hiệu suất của một sản phẩm phần mềm dưới một tải nhất định. Kiểm tra hiệu suất được thực hiện trước và sau khi tối ưu hóa để xác định những thay đổi về hiệu suất. Nếu tối ưu hóa không thành công và hiệu suất giảm, lập trình viên có thể từ bỏ tối ưu hóa không thành công. Nếu có sự cải thiện về hiệu suất, mức độ cải thiện có thể được so sánh với kết quả mong đợi để đảm bảo rằng việc tối ưu hóa thành công. Mục đích của kiểm tra hiệu suất là xác định mức tăng và giảm hiệu suất để có thể tránh được việc nâng cấp không thành công.

  • Wikipedia. Kiểm tra năng suất.

Kiểm tra tải- kiểm thử phần mềm, cho phép đánh giá hiệu suất của một sản phẩm phần mềm theo kế hoạch, mức tăng và tải cao điểm. Việc thực hiện kiểm tra tải trước khi đưa hệ thống vào sản xuất cho phép bạn tránh được những tổn thất không mong muốn về hiệu suất từ ​​sáu tháng đến một năm sau, khi hệ thống chứa đầy dữ liệu.

  • Wikipedia. Bài kiểm tra về áp lực .

Bài kiểm tra về áp lực- kiểm tra phần mềm, đánh giá độ tin cậy và tính ổn định của hệ thống khi vượt quá giới hạn hoạt động bình thường. Đây là việc kiểm tra chương trình trong những tình huống căng thẳng như sự hiện diện của một lượng lớn tham số đầu vào, thiếu dung lượng ổ đĩa hoặc bộ xử lý có công suất thấp.

Kiểm tra căng thẳng được thiết kế để kiểm tra giải pháp và nhóm máy chủ được định cấu hình nhằm phục vụ đồng thời một số lượng lớn người dùng. Với thử nghiệm như vậy, không chỉ nhóm máy chủ được kiểm tra mà còn cả tác động của cài đặt đối với hiệu suất của toàn bộ hệ thống và khả năng chịu lỗi của nó. Để tiến hành thử nghiệm như vậy, cần phải có một bộ máy tính mô phỏng công việc của các nhóm người dùng.

  • Wikipedia. Kiểm tra căng thẳng phần mềm.

Kiểm tra độ ổn định/độ bền/ngâm- kiểm thử phần mềm, kiểm tra chức năng của phần mềm trong quá trình thử nghiệm dài hạn với mức tải trung bình.

Kiểm tra bảo mật- kiểm tra phần mềm để kiểm tra phản ứng thực tế của các cơ chế phòng thủ được tích hợp trong hệ thống trước sự xâm nhập của những kẻ xâm nhập.

  • Wikipedia. Kiểm tra an ninh.
  • Ochir Abushinov: Các tính năng của kiểm tra bảo mật phần mềm.

Kiểm tra khả năng tương thích- kiểm thử phần mềm, kiểm tra chức năng của phần mềm trong một môi trường nhất định.

Dựa trên kiến ​​thức về hệ thống

Kiểm tra hộp đen- kiểm tra phần mềm, trong đó người kiểm tra chỉ có quyền truy cập vào phần mềm thông qua giao diện của khách hàng hoặc thông qua giao diện bên ngoài cho phép máy tính hoặc quy trình khác kết nối với hệ thống để kiểm tra. Cách tiếp cận này vẫn là phổ biến nhất trong thực tế hàng ngày, nhưng nó có một số nhược điểm. Ví dụ: một số lỗi xảy ra khá hiếm và do đó rất khó tìm và tái tạo.

  • Wikipedia. Kiểm thử bằng chiến lược hộp đen.

Kiểm thử hộp trắng- kiểm thử phần mềm, trong đó người kiểm thử có quyền truy cập vào mã nguồn của chương trình và có thể viết mã liên kết với các thư viện của phần mềm đang được kiểm thử. Kiểm thử hộp trắng bao gồm các kỹ thuật sau: đọc chương trình, xem chính thức chương trình, kiểm tra. Phương pháp này cho phép bạn nhìn vào bên trong hộp đen và tập trung vào thông tin bên trong xác định hành vi của chương trình. Thách thức chính là khó khăn trong việc theo dõi tính toán thời gian chạy. Khi kiểm tra một chương trình, tính logic của chương trình sẽ được kiểm tra. Trong trường hợp này, thử nghiệm hoàn chỉnh sẽ dẫn đến việc liệt kê tất cả các đường dẫn có thể. Ngay cả đối với các chương trình có độ phức tạp trung bình, số lượng đường dẫn như vậy có thể lên tới hàng chục nghìn.

  • Wikipedia. Chiến lược kiểm thử hộp trắng.

Theo thời gian thử nghiệm

Thử nghiệm alpha- đây là quá trình mô phỏng công việc thực tế của các nhà phát triển với một sản phẩm phần mềm hoặc công việc thực sự của người dùng tiềm năng với hệ thống.

Thử nghiệm beta- đây là việc phân phối các phiên bản có giới hạn cho một nhóm người nhất định, nhằm kiểm tra nội dung về số lỗi tối thiểu có thể có trong một sản phẩm phần mềm.

Kiểm tra hồi quy- kiểm tra phần mềm, bao gồm việc kiểm tra các lỗi được tìm thấy trước đó cũng như kiểm tra chức năng cơ bản. Theo quy định, nó được thực hiện trên mỗi phiên bản mới của sản phẩm phần mềm. Kiểm tra hồi quy là giai đoạn kiểm tra quan trọng nhất ngay trước khi kết thúc công việc trên sản phẩm, vì ngay trước khi phát hành sản phẩm, bắt buộc phải kiểm tra không chỉ chức năng chính mà còn không có lỗi nào được tìm thấy trước đó lặp lại trong phiên bản cuối cùng. Là một phần không thể thiếu của kiểm tra chức năng, kiểm tra hồi quy giúp đảm bảo rằng các thay đổi để sửa lỗi không tác động tiêu cực đến các lĩnh vực chức năng khác của ứng dụng.

  • Wikipedia. Kiểm tra hồi quy.

Kiểm tra khói- kiểm thử phần mềm, trong đó một tập hợp các kiểm thử được thực hiện, sau đó chúng ta có thể nói rằng sản phẩm phần mềm đã được tung ra. Nếu không có lỗi khởi động nào xảy ra, thử nghiệm khói được coi là đã đạt. Nếu chương trình không vượt qua bài kiểm tra khói, nó sẽ được gửi để sửa đổi. Thực tế là các nhà phát triển viết các thành phần riêng lẻ của một ứng dụng, nhưng khi các thành phần này được kết hợp với nhau, chúng thường không thể hoạt động cùng nhau, do đó, việc thử nghiệm toàn bộ sản phẩm sẽ chẳng ích gì.

  • Wikipedia. Kiểm tra khói.

Theo mức độ tự động hóa

Kiểm tra bằng tay- kiểm thử trong đó phần mềm không được sử dụng để thực hiện kiểm thử và kiểm tra kết quả thực hiện.

  • Kiểm tra: Thủ công hay tự động?

Kiểm tra tự động- kiểm tra trong đó phần mềm được sử dụng để thực hiện kiểm tra và xác minh kết quả thực hiện. Kiểm thử tự động chắc chắn mang lại lợi ích và tiết kiệm thời gian, nguồn lực cho công ty.

Trong quá trình phát triển, thường xảy ra trường hợp một phiên bản mới đã sửa lỗi được phát hành hàng ngày và đôi khi vài lần trong ngày. Smoke testing trước hết phải được tự động hóa, vì ngay sau khi xây dựng phiên bản mới của chương trình, chúng ta cần đảm bảo rằng chương trình chạy nhanh nhất có thể. Quá trình kiểm tra tự động sẽ xử lý nhiệm vụ như vậy trong vài giây và quá trình lắp ráp có thể được coi là thành công. Nếu một người làm điều này thì sẽ mất nhiều thời gian hơn để kiểm tra. Vì vậy, tự động hóa thử nghiệm khói là một cách tiết kiệm thời gian tốt cho bộ phận thử nghiệm.

Có một số lượng lớn các ứng dụng để tự động hóa thử nghiệm. Phổ biến nhất trong số đó: HP LoadRunner, HP QuickTest Professional, HP Quality Center, .

Tự động hóa nói chung không chỉ tiết kiệm thời gian phát triển mà còn tăng độ tin cậy và an toàn của sản phẩm được tạo ra. Lợi ích dành cho người thử nghiệm cũng rất rõ ràng: độ tin cậy của việc thử nghiệm sản phẩm tăng lên, thời gian thử nghiệm giảm xuống và công việc của người thử nghiệm trở nên ít căng thẳng hơn. Tất nhiên, kiểm thử tự động không bao giờ có thể thay thế con người, nhưng chúng có thể giúp công việc của kỹ sư kiểm thử phần mềm trở nên dễ dàng hơn.

  • Kiểm tra: Thủ công hay tự động?

Phân tích mã động và tĩnh

Khi dự án tiến triển, chi phí sửa lỗi phần mềm có thể tăng theo cấp số nhân. Các công cụ phân tích tĩnh và động giúp ngăn ngừa các chi phí này bằng cách phát hiện sớm các lỗi phần mềm trong vòng đời phần mềm.

Phân tích thời gian chạy- một phương pháp phân tích chương trình trực tiếp trong quá trình thực hiện nó. Trong phân tích động, các vấn đề được tìm thấy trong mã nguồn khi chúng xảy ra. Quá trình phân tích có thể được chia thành nhiều giai đoạn - chuẩn bị dữ liệu ban đầu, tiến hành chạy thử chương trình, thu thập các tham số cần thiết và phân tích dữ liệu thu được.

Vì vậy, bạn đã quyết định bắt đầu thử nghiệm phần mềm. Lựa chọn tuyệt vời! Bước đầu tiên hướng tới việc lựa chọn (hoặc thay đổi) một nghề nghiệp đã được thực hiện. Bước hợp lý thứ hai sẽ là nghiên cứu phần lý thuyết - không có phần lý thuyết thì không có cách nào trong bất kỳ hoạt động kinh doanh nào. Không quan trọng bạn có trình độ học vấn kỹ thuật hay nhân đạo, dù bạn có kinh nghiệm làm việc hay là sinh viên - bạn cần bắt đầu bằng việc tích lũy kiến ​​​​thức lý thuyết. Hôm nay chúng tôi mời bạn tìm hiểu những loại thử nghiệm phần mềm hiện có.

Có một số cách tiếp cận để phân loại các loại kiểm thử phần mềm. Chúng ta hãy nhìn vào những cái phổ biến nhất.

1. Các loại thử nghiệm theo mục đích

Tùy thuộc vào mục tiêu bạn đang theo đuổi khi thử nghiệm ứng dụng hoặc chương trình này hay ứng dụng kia, thử nghiệm có thể là:

  • Chức năng;
  • Không có chức năng.

Kiểm tra chức năng nhằm mục đích kiểm tra chức năng nào của sản phẩm phần mềm được triển khai và chúng được triển khai chính xác như thế nào.

Phi chức năng – kiểm tra hoạt động chính xác của các yêu cầu phi chức năng. Loại thử nghiệm này thay vì kiểm tra CÁCH sản phẩm phần mềm hoạt động và bao gồm các loại sau:

  • Kiểm tra năng suất– kiểm tra cách một sản phẩm phần mềm hoạt động dưới một tải nhất định. Kiểm tra bao gồm:> Tải– xác định cách chương trình thực hiện dưới tải dự kiến.

    > Căng thẳng– xác định hiệu suất của sản phẩm phần mềm ở mức tải tối đa.

    > Kiểm tra độ ổn định– kiểm tra xem sản phẩm phần mềm có thể chịu được tải lâu dài hay không.

    > Cấu hình– xác định cách sản phẩm phần mềm sẽ hoạt động trong điều kiện thay đổi cấu hình (nền tảng, trình điều khiển, máy tính).

  • Kiểm tra giao diện người dùng– xác định khả năng sử dụng của giao diện người dùng (nút, màu sắc, căn chỉnh, v.v.).
  • Kiểm tra khả năng sử dụng– kiểm tra xem sản phẩm phần mềm có dễ sử dụng hay không.
  • Kiểm tra bảo mật– xác định mức độ an toàn khi sử dụng sản phẩm phần mềm, tức là. Sản phẩm phần mềm có được bảo vệ khỏi các cuộc tấn công của tin tặc, truy cập trái phép vào dữ liệu, v.v.
  • Kiểm tra cài đặt– kiểm tra xem có vấn đề phát sinh khi cài đặt, gỡ cài đặt hoặc cập nhật sản phẩm phần mềm hay không.
  • Kiểm tra khả năng tương thích– kiểm tra hoạt động của một sản phẩm phần mềm trong một môi trường cụ thể.
  • Kiểm tra độ tin cậy– kiểm tra hoạt động của ứng dụng dưới tải dự kiến ​​trung bình dài hạn.
  • Thử nghiệm bản địa hóa– thử nghiệm phiên bản bản địa hóa của sản phẩm phần mềm (khía cạnh ngôn ngữ và văn hóa).

2. Theo mức độ tự động hóa

Tùy thuộc vào việc người kiểm tra có sử dụng các công cụ phần mềm bổ sung để kiểm tra ứng dụng hoặc chương trình hay không, việc kiểm tra có thể là:

  • Thủ công– kiểm thử một sản phẩm phần mềm mà không sử dụng phần mềm bổ sung, tức là Kiểm tra bằng tay.
  • tự động– kiểm thử một sản phẩm phần mềm bằng phần mềm (chi tiết hơn trong phần mô tả).

3. Theo tính tích cực của kịch bản

Tùy thuộc vào mức độ tích cực của tình huống, thử nghiệm có thể là:

  • Tích cực– kiểm tra sản phẩm phần mềm xem có tuân thủ hành vi dự kiến ​​hay không. Loại thử nghiệm đầu tiên cần được thực hiện vì nhiệm vụ chính của thử nghiệm là kiểm tra xem chương trình có hoạt động chính xác hay không.
  • Tiêu cực– kiểm tra xem sản phẩm phần mềm có hoạt động hay không khi hành vi của người dùng khác với những gì được mong đợi.

4. Bằng cách truy cập vào mã sản phẩm phần mềm

Trong quá trình kiểm thử, người kiểm thử có thể làm việc với một sản phẩm phần mềm mà không cần truy cập vào mã của nó hoặc có thể xác định hoạt động chính xác bằng cách xem mã. Dựa vào việc truy cập vào mã sản phẩm phần mềm, việc kiểm thử được chia thành:

  • Kiểm thử hộp trắng– kiểm tra một sản phẩm phần mềm có quyền truy cập vào mã.
  • Kiểm tra hộp đen– thử nghiệm mà không cần truy cập vào mã sản phẩm.
  • Kiểm thử hộp xám– kiểm thử dựa trên kiến ​​thức hạn chế về cấu trúc bên trong của sản phẩm phần mềm. Người ta thường nói rằng đó là sự kết hợp giữa kiểm thử hộp trắng và hộp đen, nhưng điều này hoàn toàn sai. Trong trường hợp này, người kiểm thử không làm việc với mã của sản phẩm phần mềm nhưng anh ta quen với cấu trúc bên trong của chương trình hoặc ứng dụng và sự tương tác giữa các thành phần.

5. Theo cấp độ

Theo mức độ kiểm tra, có:

  • Kiểm thử đơn vị/đơn vị– kiểm tra hoạt động chính xác của từng đơn vị trong hệ thống sản phẩm phần mềm. Loại thử nghiệm này có thể được thực hiện bởi chính các nhà phát triển.
  • Thử nghiệm hội nhập– kiểm tra sự tương tác giữa một số đơn vị của một sản phẩm phần mềm.
  • mang tính hệ thống– kiểm tra hoạt động của toàn bộ hệ thống xem có tuân thủ các yêu cầu đã nêu đối với sản phẩm phần mềm hay không.

6. Theo nghệ sĩ

Có thể bạn đã nghe nói về thử nghiệm alpha và beta. Và bạn có thể tham gia vào một trong số đó ngay cả khi không phải là người thử nghiệm. Vì vậy, theo người thực hiện, thử nghiệm được chia thành:

  • Thử nghiệm alpha– thử nghiệm một sản phẩm phần mềm ở giai đoạn phát triển muộn. Được thực hiện bởi các nhà phát triển hoặc người thử nghiệm.
  • Thử nghiệm beta– thử nghiệm một sản phẩm phần mềm trước khi đưa vào thị trường bởi những người bình thường - tình nguyện viên, người được chuyển giao phiên bản sơ bộ của sản phẩm (phiên bản beta). Phản hồi của họ được thu thập, phân tích và tính đến khi thực hiện thay đổi đối với sản phẩm.

7. Bằng hình thức

Về mặt hình thức, thử nghiệm là:

  • Kiểm tra bằng các bài kiểm tra– kiểm tra bằng cách sử dụng các trường hợp kiểm thử được viết sẵn.
  • Thử nghiệm thăm dò– đồng thời phát triển các thử nghiệm và thực hiện chúng.
  • Kiểm tra miễn phí– thử nghiệm mà không phát triển thử nghiệm, không có tài liệu. Dựa trên trực giác và kinh nghiệm của người thử nghiệm.

8. Theo tầm quan trọng

Theo mức độ quan trọng của các chức năng được kiểm thử, kiểm thử được chia thành:

  • Kiểm tra khói– kiểm tra chức năng quan trọng nhất của sản phẩm phần mềm.
  • Kiểm tra đường dẫn quan trọng– kiểm tra chức năng được người dùng thông thường sử dụng trong hoạt động hàng ngày của họ.
  • Kiểm tra nâng cao– xác minh tất cả các chức năng đã khai báo.

Các loại thử nghiệm và cách tiếp cận để phân loại thử nghiệm khác nhau tùy theo tác giả. Không có lựa chọn đúng duy nhất.

Chúng tôi hy vọng rằng bài viết này sẽ giúp bạn định hướng ngay từ đầu hành trình kiểm thử phần mềm.

Tại sao bạn quyết định trở thành một người thử nghiệm?
- Làm ơn cài nút cổ áo lại.

Sách

  • (PDF) Kiểm thử phần mềm (Svyatoslav Kulikov, 2018). Mặc dù khóa học được định vị là “cơ bản” nhưng nội dung chủ đề lại được mô tả chuyên sâu, rõ ràng và có nhiều ví dụ.
  • (PDF) Cách họ kiểm tra tại Google (James Whittaker, 2012; bản dịch tiếng Nga 2014 - ed. "Peter"), cuốn sách mức giữa không chỉ về kinh nghiệm của họ trong việc cải cách các quy trình thử nghiệm trong công ty mà còn về các phương pháp quản lý và phát triển, những gì được mô tả sẽ hữu ích hơn cho các công ty rất lớn đang phát triển “cho chính họ” (chẳng hạn như Yandex, ABBYY, Kaspersky Lab, chẳng hạn) , nhưng những suy nghĩ thú vị và có nhiều kỹ thuật
  • (PDF) Các quy trình kiểm tra chính (Rex Black, 2004; bản dịch tiếng Nga 2006 - ed. "Lori").
    Các vấn đề về tổ chức, tiến hành khảo nghiệm trong khu phức hợp được xem xét, đọc có chọn lọc;
  • (PDF) Thử nghiệm linh hoạt (Lisa Crispin và Janet Gregory, 2009; bản dịch tiếng Nga 2010 - Williams ed.)
    , về thực hành kiểm thử trong phát triển linh hoạt (Agile)

Liên kết

  • Thử nghiệm hình cầu trong chân không: Nó như thế nào, nó phải như thế nào, nó sẽ như thế nào
  • Tài liệu kiểm thử sản phẩm phần mềm

Kiểm tra: QC VÀ QA

Mục tiêu kiểm thử (mục tiêu kiểm thử, mục tiêu kiểm thử) hoặc mục đích phát triển và thực hiện các thử nghiệm:
  • đảm bảo rằng phần mềm không có lỗi ở mức chấp nhận được (bạn không thể cung cấp phạm vi bao phủ 100% nhưng bạn nên cố gắng hết sức và đảm bảo rằng các lỗi rõ ràng được khắc phục);
  • đảm bảo rằng phần mềm đáp ứng các yêu cầu và thông số kỹ thuật ban đầu;
  • mang lại niềm tin về độ tin cậy của phần mềm (đối với người dùng, khách hàng, v.v.).

Nhiệm vụ QC (Kiểm soát chất lượng, kiểm soát chất lượng)điều này nhằm kiểm soát và ghi lại chất lượng của các hiện vật, hay nói cách khác là kết quả trung gian và cuối cùng của công việc. Mục đích của nó là tìm ra những khiếm khuyết và đảm bảo chúng được sửa chữa. Vì vậy kiểm tra là một phần không thể thiếu của kiểm soát chất lượng.
Thuật ngữ ở đây rất phù hợp xác minh với câu hỏi "Chúng ta đang xây dựng sản phẩm có đúng không?" - chúng ta đang làm ra sản phẩm đúng không?, việc tuân thủ các kế hoạch, thông số kỹ thuật, thiết kế, quy tắc mã và đoạn văn được kiểm tra. Kiểm tra SỰ ĐÚNG.

QA (Đảm bảo chất lượng, đảm bảo chất lượng)- ISO9000 định nghĩa đảm bảo chất lượng phần mềm là một phần của quản lý chất lượng tập trung vào việc tạo niềm tin rằng các yêu cầu sửa lỗi sẽ được đáp ứng. Mục đích của QA là đảm bảo rằng sản phẩm sẽ đáp ứng được mong đợi về chất lượng của khách hàng. Nó bao gồm các quy trình/hoạt động nhằm đảm bảo chất lượng phát triển sản phẩm ở từng giai đoạn của nó. Những hoạt động này thường diễn ra trước quá trình phát triển sản phẩm và tiếp tục trong quá trình phát triển. Bản thân QA chịu trách nhiệm phát triển và triển khai các quy trình và tiêu chuẩn để cải thiện vòng đời phát triển và mang lại niềm tin rằng các quy trình này được tuân thủ. Trọng tâm của QA là ngăn ngừa các khiếm khuyết ở tất cả các giai đoạn thực hiện và cải tiến liên tục.
Thuật ngữ ở đây rất phù hợp Thẩm định với câu hỏi "Chúng ta có đang xây dựng đúng sản phẩm không?" - Chúng ta có đang tạo ra sản phẩm phù hợp không? sản phẩm có đáp ứng được nhu cầu của người sử dụng hay không. Kiểm tra SỰ HOÀN THÀNH.

Để các dịch vụ được cung cấp có giá trị, việc kiểm tra phải nhằm mục đích xác nhận các tính năng:

  • có ý nghĩa quan trọng đối với Khách hàng/Người dùng
  • ảnh hưởng đến ý kiến ​​của người dùng về cách làm việc với hệ thống
  • giảm thiểu rủi ro chi phí tiềm ẩn
Việc kiểm tra các phần không thiết yếu của hệ thống sẽ tạo ra niềm tin sai lầm về hoạt động chính xác của hệ thống và tiêu tốn một lượng thời gian ấn tượng đối với Nhà phát triển và Người kiểm tra.

1. Phân tích thử nghiệm

Phân tích thử nghiệm= quá trình tìm kiếm/xem xét những gì có thể được sử dụng để có được thông tin cần thiết cho việc kiểm tra. Những thứ kia. thông tin cần thiết cho việc soạn thảo - hoặc cơ sở kiểm tra. Và thông thường, cơ sở kiểm thử là một tập hợp các tài liệu bao gồm các yêu cầu, thông số kỹ thuật, mô tả kiến ​​trúc, giao diện tích hợp, v.v.

Nói chung cần xác định:

Xác định phạm vi kiểm thử (phạm vi/khối lượng kiểm thử)

Yêu cầu và ca kiểm thử Ma trận dấu vết

Ma trận truy xuất nguồn gốc yêu cầu (Ma trận truy xuất nguồn gốc yêu cầu) = bảng hai chiều chứa sự tương ứng giữa các yêu cầu (yêu cầu của người dùng/doanh nghiệp, yêu cầu phần mềm) và các yêu cầu được chuẩn bị sẵn (các trường hợp kiểm thử).
Mục đích chính của nó là hiển thị mức độ bao phủ các yêu cầu.

Ví dụ về ma trận vết:

(tải xuống ở định dạng XLSX)

Theo các phương pháp hay nhất, Yêu cầu Kinh doanh phải được phân tách càng nhiều càng tốt và được đánh số theo quy tắc sau: BR001, BR002, v.v.
Đối với mỗi Yêu cầu nghiệp vụ sẽ có một hoặc nhiều Yêu cầu chức năng, phải tuân theo quy ước đánh số cho yêu cầu nghiệp vụ tương ứng: FR001.01, FR001.02, FR001.03, FR002, v.v. Các yêu cầu chức năng cũng nên được phân tách càng nhiều càng tốt.

(tải xuống lược đồ ở dạng XML)

Nếu bạn sử dụng trình theo dõi tác vụ Jira, Zephyr của Jira cho tài liệu kiểm tra và hệ thống quản lý yêu cầu Confluence thì tất cả các thực thể sẽ được đồng bộ hóa và khả năng truy xuất nguồn gốc này cho phép bạn:

  • hình dung hiện trạng thực hiện;
  • chia nhỏ các yêu cầu thành các yêu cầu đơn giản hơn và cấu trúc chúng;
  • theo dõi xem có những yêu cầu nào mà việc phát triển chưa được lên kế hoạch hay không (bỏ qua việc thực hiện);
  • theo dõi xem yêu cầu hiện có được thực hiện hay không;
  • theo dõi xem trường hợp kiểm thử có đáp ứng được yêu cầu hay không (bỏ qua kiểm thử);
  • hiển thị rõ ràng mức độ ưu tiên của các yêu cầu.

Tỷ lệ ràng buộc Yêu cầu và có thể là:

  • 1 đến 1 (yêu cầu nguyên tử được đề cập trong một trường hợp thử nghiệm, trường hợp thử nghiệm này chỉ bao gồm yêu cầu này);
  • 1 đến n (một yêu cầu được đề cập trong một số trường hợp thử nghiệm, các trường hợp thử nghiệm này chỉ bao gồm yêu cầu này);
    Khi một yêu cầu trong ma trận truy xuất nguồn gốc được bao phủ bởi một số thử nghiệm, điều này có thể cho thấy sự dư thừa trong thử nghiệm. Trong trường hợp này, cần phải phân tích xem yêu cầu nguyên tử như thế nào.
  • n đến n (một yêu cầu được đề cập trong một số trường hợp thử nghiệm, các trường hợp thử nghiệm này bao gồm yêu cầu này và các yêu cầu khác).

Rủi ro chất lượng

Rủi ro chất lượng- loại lỗi tiềm ẩn, cách thức hoạt động của hệ thống trong đó có khả năng không đáp ứng được những kỳ vọng hợp lý về chất lượng của hệ thống mà người dùng hoặc khách hàng có. Đây là một kết quả tiềm năng, không phải là một kết quả bắt buộc.

Các loại rủi ro chất lượng chung
Chức năng Sự cố khiến các tính năng cụ thể không hoạt động
Các vấn đề về xử lý tải cao điểm dự kiến ​​khi nhiều người dùng làm việc song song
Độ tin cậy, ổn định Sự cố hệ thống bị treo quá thường xuyên hoặc mất nhiều thời gian để khôi phục
Quá tải, xử lý lỗi và phục hồi Các vấn đề phát sinh do vượt quá tải tối đa có thể chấp nhận được hoặc do xử lý các điều kiện không được chấp nhận (ví dụ: tác dụng phụ của việc cố tình đưa ra lỗi)
Thời gian và ngày xử lý Lỗi trong các phép toán với ngày và giờ, trong định dạng của chúng, trong các sự kiện đã lên lịch và các phép toán phụ thuộc vào thời gian khác
Chất lượng dữ liệu Lỗi trong quá trình xử lý, truy xuất và lưu trữ dữ liệu
Hiệu suất Sự cố về thời gian hoàn thành nhiệm vụ dưới mức tải dự kiến
Bản địa hóa Các vấn đề liên quan đến bản địa hóa sản phẩm, bao gồm xử lý trang ký tự, hỗ trợ ngôn ngữ, sử dụng ngữ pháp, sử dụng từ điển, thông báo lỗi và tệp trợ giúp
Sự an toàn các vấn đề trong việc bảo vệ hệ thống và dữ liệu được bảo vệ khỏi việc sử dụng gian lận và độc hại
Cài đặt/chuyển giao các lỗi ngăn cản việc phân phối hệ thống
Tài liệu lỗi trong hướng dẫn cài đặt và vận hành cho người dùng và quản trị viên hệ thống
Điều này cũng dẫn đến kết luận rằng điều quan trọng là phải nghiên cứu các yêu cầu của khách hàng, tuân thủ chúng và ý thức chung (khách hàng không phải lúc nào cũng đúng, đôi khi rất hữu ích khi gợi ý cho anh ta về những rủi ro tiềm ẩn do thực hiện bất kỳ yêu cầu phù phiếm nào của anh ta).

Rủi ro thử nghiệm

Rủi ro chính của thử nghiệm:

  1. Dự án - liên quan đến thông tin liên lạc của các thành viên trong nhóm, cơ sở hạ tầng:
    - thay đổi phạm vi thử nghiệm sau khi kiểm tra các trường hợp thử nghiệm chính
    ...
  2. Sản phẩm - chỉ liên quan đến chức năng đang được thử nghiệm và môi trường thử nghiệm:
    - thiếu vùng thử nghiệm với cấu hình nhất định (cơ sở dữ liệu chậm, cơ sở dữ liệu ẩn danh (im), thiếu bất kỳ dữ liệu thử nghiệm nào)
    - thời gian không thể chấp nhận được để chờ Quản trị viên chuẩn bị khu vực thi
    ...

Quan điểm

Quyết định quan điểm về hệ thống (Quan điểm).
Nó phụ thuộc vào vấn đề chúng ta đang giải quyết và chính xác những gì chúng ta đang phân tích.

Phương pháp phân tích và ký hiệu đồ họa để trực quan hóa

Có nhiều phương pháp phân tích khác nhau và các ký hiệu đồ họa khác nhau để trực quan hóa kết quả phân tích. Sự lựa chọn của họ phụ thuộc vào quan điểm mà chúng ta chọn.

2. Kế hoạch thử nghiệm và dự toán chi phí nhân công

Kế hoạch kiểm tra= một tài liệu mô tả toàn bộ phạm vi công việc kiểm thử, bắt đầu từ mô tả đối tượng, chiến lược, lịch trình, tiêu chí bắt đầu và kết thúc kiểm thử, đến thiết bị cần thiết trong quy trình, kiến ​​thức đặc biệt cũng như đánh giá rủi ro với các tùy chọn cho độ phân giải của họ.

Nói chung, một kế hoạch kiểm tra được thiết kế để trả lời các câu hỏi sau:

Ước tính nỗ lực

  1. Những gì chúng tôi đánh giá:
    • Kỹ năng con người: kiến ​​thức và kinh nghiệm của các thành viên trong nhóm. Có tác động lớn đến xếp hạng.
    • Nguồn lực: con người, kỹ thuật, v.v.
    • Thời gian
    • Chi phí: ngân sách.
  2. Ai có thể đưa ra đánh giá?
    • Nhà phân tích thử nghiệm
    • Kiểm thử
  3. Các phương pháp ước tính chi phí nhân công:

Theo kinh nghiệm của riêng tôi: để tính đến thời gian khi lập kế hoạch, sẽ rất hữu ích khi xác định và tính toán thời gian mà người thử nghiệm thường dành cho:

  • cào thư và người đưa tin Augean
  • hiểu biết về thông số kỹ thuật/nhiệm vụ
  • đặt câu hỏi và chờ câu trả lời từ Bộ biên dịch TOR/FT
  • biên soạn/cập nhật/thêm các trường hợp thử nghiệm cho Nhiệm vụ (trong trường hợp không có Nhà phân tích)
  • chuẩn bị/kiểm tra các điều kiện tiên quyết/đặt trước trong Hệ thống (trong trường hợp không có Quản trị viên hệ thống)
  • nhiệm vụ kiểm tra
  • tổng hợp các báo cáo lỗi về các lỗi/thiếu sót đã xác định
  • Đang chờ sửa lỗi cho các lỗi đã xác định và báo cáo. (lần này có thể làm song song, nếu bạn vướng 1 task nào đó, chúng tôi sẽ báo cáo và thực hiện task tiếp theo trong khi đang ở chế độ chờ sửa lỗi)
  • đang thử nghiệm các lỗi đã sửa
  • chuẩn bị báo cáo thử nghiệm
  • hỗ trợ đồng nghiệp trong hội thảo, tư vấn với họ về các vấn đề công việc
  • các sự kiện trong bộ phận kiểm tra - các cuộc họp, cuộc mít tinh, đào tạo, ngày nghỉ, v.v.
  • các sự kiện bên ngoài bộ phận kiểm tra - các cuộc họp về các dự án khác, trình diễn, đào tạo, nghỉ lễ, v.v.
Phần lớn những việc trên, ngoài việc phân tích thực tế Vấn đề và thử nghiệm nó, có thể “ngốn” một phần đáng kể thời gian làm việc.

3. Thiết kế và phạm vi kiểm thử

Tài nguyên

Bản chất

Thiết kế thử nghiệm= giai đoạn thiết kế và tạo ra (, trường hợp kiểm thử, trường hợp - “trường hợp” pháp lý), phù hợp với tiêu chí chất lượng và mục tiêu kiểm thử đã xác định trước đó.
Vai trò chịu trách nhiệm thiết kế thử nghiệm:

  • Nhà phân tích kiểm thử - xác định "Kiểm thử CÁI GÌ?"
  • Người thiết kế thử nghiệm - xác định "LÀM THẾ NÀO để thử nghiệm?"

Kỹ thuật thiết kế thử nghiệm

  • Phân chia tương đương(Phân vùng tương đương - EP). Ví dụ: nếu bạn có một phạm vi giá trị hợp lệ từ 1 đến 10, bạn phải chọn một giá trị đúng bên trong khoảng, giả sử là 5 và một giá trị không chính xác ngoài khoảng, 0.
  • Phân tích giá trị biên(Phân tích giá trị biên - BVA). Nếu lấy ví dụ trên, chúng tôi sẽ chọn giới hạn tối thiểu và tối đa (1 và 10) làm giá trị cho thử nghiệm dương tính và các giá trị lớn hơn và nhỏ hơn giới hạn (0 và 11). Phân tích giá trị biên có thể được áp dụng cho các trường, bản ghi, tệp hoặc bất kỳ loại thực thể bị ràng buộc nào.
  • Nguyên nhân/Kết quả(Nhân/Quả - CE). Theo quy định, đây là việc nhập kết hợp các điều kiện (lý do) để nhận được phản hồi từ hệ thống (Hiệu ứng). Ví dụ: bạn đang thử nghiệm khả năng thêm khách hàng bằng cách sử dụng một màn hình cụ thể. Để thực hiện việc này, bạn sẽ cần nhập một số trường như "Tên", "Địa chỉ", "Số điện thoại" và sau đó nhấp vào nút "Thêm" - đây là "Lý do". Sau khi nhấp vào nút "Thêm", hệ thống sẽ thêm khách hàng vào cơ sở dữ liệu và hiển thị số của khách hàng đó trên màn hình - đây là "Điều tra".
  • Dự đoán lỗi(Lỗi Đoán - EG). Đây là khi nhà phân tích kiểm thử sử dụng kiến ​​thức của mình về hệ thống và khả năng diễn giải thông số kỹ thuật để “dự đoán” trong những điều kiện đầu vào nào hệ thống có thể bị lỗi. Ví dụ: thông số kỹ thuật cho biết "người dùng phải nhập mã." Người phân tích thử nghiệm sẽ nghĩ: “Nếu tôi không nhập mã thì sao?”, “Nếu tôi nhập sai mã thì sao?”, v.v. Đây là dự đoán lỗi.
  • Kiểm tra toàn diện(Kiểm tra toàn diện - ET) là một trường hợp cực đoan. Trong kỹ thuật này, bạn nên kiểm tra tất cả các kết hợp có thể có của các giá trị đầu vào và về nguyên tắc, điều này sẽ tìm ra tất cả các vấn đề. Trong thực tế, việc sử dụng phương pháp này là không thể do số lượng giá trị đầu vào quá lớn.

Trường hợp thử nghiệm

Trường hợp thử nghiệm= một tạo phẩm mô tả một tập hợp các bước, điều kiện cụ thể và tham số cần thiết để kiểm tra việc triển khai chức năng đang được thử nghiệm hoặc một phần của chức năng đó.
Ví dụ về thiết kế: http://www.protesting.ru/documentation/test_case_example.zip
Từ nguyên của từ trường hợp quay trở lại luật học. Trường hợp - trường hợp, trường hợp.
Về bản chất, trong thử nghiệm, chúng tôi với sự trợ giúp của các trường hợp thử nghiệm cung cấp cho chúng tôi bằng chứng và sự kiện, hỗ trợ các lập luận, biện minh cho các tuyên bố rằng Hệ thống, Phần mềm hoặc Sản phẩm đang được thử nghiệm đáp ứng các yêu cầu.

(tải xuống lược đồ ở dạng XML)

cấp độ kiểm tra

(tải xuống lược đồ ở dạng XML)

Kiểm tra đơn vị

Kiểm tra đơn vị (Kiểm tra đơn vị) = thử nghiệm một mô-đun mã(thường là một hàm hoặc một lớp trong trường hợp mã OOP) trong một môi trường biệt lập. Nó có nghĩa là:
  • nếu mã sử dụng một số lớp của bên thứ ba thì các lớp sơ khai sẽ được chèn thay thế: mô phỏng và sơ khai. Sơ khaiđược thiết kế để có được những gì bạn cần tình trạngđối tượng đang được thử nghiệm, và Mô phỏngđược sử dụng để kiểm tra những gì được mong đợi hành viđối tượng đang được kiểm tra.
  • mã sẽ không hoạt động với mạng (và máy chủ bên ngoài), tệp, cơ sở dữ liệu (nếu không, chúng tôi không kiểm tra chính chức năng hoặc lớp mà còn cả đĩa, cơ sở dữ liệu, v.v.)

Thông thường, một bài kiểm tra đơn vị sẽ chuyển nhiều đầu vào khác nhau cho một hàm và xác minh rằng nó trả về kết quả mong đợi. Ví dụ: nếu chúng tôi có chức năng kiểm tra số điện thoại, chúng tôi sẽ cung cấp cho nó các số được chuẩn bị trước và kiểm tra xem nó có nhận dạng chính xác hay không. Nếu chúng ta có một hàm để giải phương trình bậc hai, chúng ta sẽ kiểm tra xem nó có trả về các nghiệm đúng hay không (để làm điều này, chúng ta lập trước một danh sách các phương trình có đáp án).

Thử nghiệm hội nhập

Thử nghiệm hội nhập (Thử nghiệm hội nhập) = kiểm tra truyền thông giữa các mô-đun mã (thành phần) cũng như sự tương tác với các bộ phận khác nhau của hệ thống (hệ điều hành, phần cứng hoặc giao tiếp giữa các hệ thống khác nhau). Ví dụ, nếu chúng ta so sánh với việc thử nghiệm một động cơ máy bay, thì thử nghiệm đơn vị là thử nghiệm các bộ phận, van, bộ giảm chấn riêng lẻ và thử nghiệm tích hợp là khởi động động cơ đã lắp ráp trên băng ghế.
Thường được thực hiện bởi các nhà phát triển .

Thử nghiệm hệ thống

Thử nghiệm hệ thống (Thử nghiệm hệ thống) = quá trình thử nghiệm toàn bộ hệ thốngđể xác minh rằng nó tuân thủ các Thông số kỹ thuật yêu cầu phần mềm (SRS) đã thiết lập.
Đảm bảo rằng Hệ thống có thể chấp nhận một số dữ liệu từ nhà cung cấp, xử lý dữ liệu đó, truyền dữ liệu đến người tiêu dùng, tất cả điều này theo đúng trình tự và định dạng. Chúng tôi không quan tâm đến số phận tiếp theo của dữ liệu. Điều chính là hệ thống của chúng tôi hoạt động chính xác trong môi trường phù hợp.
Điều này xác định các lỗi như: sử dụng tài nguyên hệ thống không chính xác, kết hợp dữ liệu cấp độ người dùng ngoài ý muốn, không tương thích với môi trường, trường hợp sử dụng ngoài ý muốn, chức năng bị thiếu hoặc không chính xác, sự bất tiện khi sử dụng, v.v.
Để giảm thiểu rủi ro liên quan đến hoạt động của hệ thống trong một môi trường cụ thể, trong quá trình thử nghiệm, nên sử dụng môi trường càng gần với môi trường mà sản phẩm sẽ được cài đặt sau khi phát hành càng tốt.
Được thực hiện bởi người thử nghiệm.

Kiểm tra chấp nhận

Kiểm tra chấp nhận (Kiểm tra chấp nhận) hoặc Kiểm tra chấp nhận (PSI) - một quy trình thử nghiệm chính thức nhằm xác minh sự tuân thủ của hệ thống với các yêu cầu của Doanh nghiệp/Người dùng và được thực hiện với mục đích: xác định xem hệ thống có đáp ứng các tiêu chí chấp nhận hay không, đưa ra quyết định của khách hàng hoặc người được ủy quyền khác xem ứng dụng có phù hợp hay không được chấp nhận hay không. Được thực hiện dựa trên một tập hợp các trường hợp thử nghiệm điển hình và các kịch bản được phát triển dựa trên các yêu cầu đối với một ứng dụng nhất định.
Được thực hiện bởi người thử nghiệm.

Kiểm tra đầu cuối

Kiểm tra đầu cuối (Từ đầu đến cuối, E2E hoặc Kiểm tra dây chuyền) = kiểm tra không chỉ môi trường của chúng tôi mà còn kiểm tra tất cả các hệ thống được kết nối với nhau mà qua đó dữ liệu được hệ thống của chúng tôi nhận hoặc gửi đi qua. Và điều này có nghĩa là chúng ta sẽ phải kết hợp một số “kim tự tháp thử nghiệm” này với nhau. Thử nghiệm E2E không chỉ là sự chấp nhận (thử nghiệm người dùng) mà khách hàng sẽ thực hiện, mà nó đang xây dựng một cầu nối, có tính đến tất cả các tình huống có thể xảy ra, theo đó khách hàng sẽ bước đi và dẫn dắt người dùng từng bước.
Được thực hiện bởi người thử nghiệm.
Đối với các kịch bản từ đầu đến cuối, với xác suất cao, các thử nghiệm đã phát triển trước đó sẽ được sử dụng cho từng hệ thống có trong chuỗi (kịch bản) của Quy trình kinh doanh. Tất cả các bộ thử nghiệm hoàn chỉnh của một công ty có thể được biểu diễn dưới dạng ma trận thưa thớt, trong đó các thử nghiệm cho từng hệ thống được phân bổ theo cột (để đơn giản, thử nghiệm hệ thống) và các quy trình kinh doanh được phân bổ theo hàng. Nghĩa là, đối với một số quy trình kinh doanh nhất định, bạn cần chọn/tạo các thử nghiệm bao gồm quy trình kinh doanh và thiết lập các mối quan hệ. Nếu không có phạm vi bao phủ, đây là lý do để lấp đầy các khoảng trống trong mô hình thử nghiệm hoặc để đảm bảo rằng chất lượng được đảm bảo bởi các cấp độ thử nghiệm khác (xem xét mã và chạy nó thông qua máy phân tích).

(tải xuống lược đồ ở dạng XML)

Các loại thử nghiệm

Kiểm thử chức năng dựa trên các chức năng và tính năng, cũng như sự tương tác với các hệ thống khác và có thể được trình bày ở tất cả các cấp độ kiểm thử: (Thử nghiệm thành phần/đơn vị), (Thử nghiệm tích hợp), (Thử nghiệm hệ thống) và (Thử nghiệm chấp nhận). Các loại thử nghiệm chức năng kiểm tra hành vi bên ngoài của hệ thống.

Kiểm thử phi chức năng mô tả các thử nghiệm cần thiết để xác định các đặc tính của phần mềm có thể được đo bằng nhiều đại lượng khác nhau. Nhìn chung, đây là thử nghiệm "cách" hệ thống hoạt động.

Thử nghiệm chức năng

Thử nghiệm chức năng xem xét hành vi được chỉ định trước và dựa trên phân tích các thông số kỹ thuật về chức năng của thành phần hoặc toàn bộ hệ thống.

Kiểm tra chức năng dựa trên các chức năng được hệ thống thực hiện và có thể được thực hiện ở tất cả các cấp độ kiểm tra (thành phần, tích hợp, hệ thống, chấp nhận). Thông thường, các chức năng này được mô tả trong yêu cầu, thông số kỹ thuật chức năng hoặc dưới dạng trường hợp sử dụng.

Kiểm tra chức năng có thể là:

  • "Tích cực" (thử nghiệm tích cực)-- đây là thử nghiệm trên dữ liệu hoặc kịch bản tương ứng với hành vi bình thường (tiêu chuẩn, dự kiến) của hệ thống.
    Mục đích chính của thử nghiệm "tích cực" là để xác minh rằng hệ thống có thể thực hiện những gì nó được thiết kế để làm.
  • "Thử nghiệm tiêu cực"-- đây là thử nghiệm trên dữ liệu hoặc kịch bản tương ứng với hành vi bất thường của hệ thống đang được thử nghiệm - các thông báo lỗi khác nhau, các tình huống ngoại lệ, trạng thái "ngoài giới hạn", v.v.
    Mục đích chính của thử nghiệm “tiêu cực” là kiểm tra khả năng chống lại các loại ảnh hưởng khác nhau của hệ thống, xác thực tập dữ liệu không chính xác và kiểm tra việc xử lý các tình huống đặc biệt (cả trong việc triển khai các thuật toán phần mềm và logic của các quy tắc kinh doanh). ).

Thử nghiệm tích cực quan trọng hơn nhiều, nhưng điều này không có nghĩa là các thử nghiệm "âm tính" có thể bị bỏ qua.

Tìm hiểu thêm về xét nghiệm dương tính/âm tính: https://www.guru99.com/ Positive-vs- Negative-testing.html

Kiểm tra kiểm soát truy cập và bảo mật

Kiểm tra bảo mật là một chiến lược thử nghiệm được sử dụng để kiểm tra tính bảo mật của hệ thống, cũng như phân tích các rủi ro liên quan đến việc cung cấp cách tiếp cận toàn diện để bảo vệ ứng dụng trước các cuộc tấn công của tin tặc, vi rút, truy cập trái phép vào dữ liệu bí mật.

Quét lỗ hổng: Được thực hiện bằng các chương trình quét lỗ hổng đặc biệt.

Quét bảo mật: Liên quan đến việc xác định các điểm yếu của mạng và hệ thống, sau đó cung cấp các giải pháp để giảm thiểu những rủi ro đó. Quá trình quét có thể được thực hiện ở cả chế độ thủ công và tự động.

Kiểm tra thâm nhập: Mô phỏng cuộc tấn công của kẻ tấn công. Thử nghiệm này bao gồm việc phân tích một hệ thống cụ thể để kiểm tra lỗ hổng tiềm ẩn trước các nỗ lực tấn công từ bên ngoài.

Đánh giá rủi ro: Liên quan đến việc phân tích các rủi ro bảo mật được quan sát thấy trong tổ chức. Rủi ro được phân loại là thấp, trung bình và cao. Loại thử nghiệm này đề xuất các phương pháp để kiểm soát và giảm thiểu rủi ro.

Kiểm tra hiệu suất hoặc kiểm tra tải

Kiểm tra năng suất= thử nghiệm tự động mô phỏng công việc của một số lượng người dùng nhất định trên một số tài nguyên (được chia sẻ) chung. Mục đích của kiểm tra hiệu năng là xác định khả năng mở rộng của ứng dụng đang tải và xảy ra những điều sau:
  • đo thời gian thực hiện các thao tác đã chọn ở cường độ nhất định của các thao tác này
  • xác định số lượng người dùng đồng thời làm việc với ứng dụng
  • xác định ranh giới của hiệu suất chấp nhận được khi tải tăng (với sự gia tăng cường độ của các hoạt động này)
  • nghiên cứu hiệu suất ở mức tải cao, cực đoan, căng thẳng

Bài kiểm tra về áp lực= thử nghiệm một ứng dụng dưới mức tải cực lớn, xác định khả năng xử lý lưu lượng truy cập hoặc xử lý dữ liệu ở mức cao. Mục tiêu là xác định điểm bùng phát của ứng dụng.

Nhiệm vụ kiểm tra độ ổn định/độ tin cậy- là để kiểm tra chức năng của ứng dụng trong quá trình thử nghiệm dài hạn (nhiều giờ) với mức tải trung bình. Thời gian thực hiện thao tác có thể đóng vai trò thứ yếu trong loại thử nghiệm này. Trong trường hợp này, vị trí đầu tiên là không có rò rỉ bộ nhớ, máy chủ khởi động lại khi đang tải và các khía cạnh khác ảnh hưởng cụ thể đến sự ổn định của hoạt động.

Kiểm tra độ bền= niềm tin rằng ứng dụng có thể chạy an toàn dưới tải trọng cao trong thời gian dài.

Kiểm tra khối lượng= nhận được đánh giá về hiệu suất khi tăng khối lượng dữ liệu trong cơ sở dữ liệu ứng dụng.

Kiểm tra khả năng sử dụng

Kiểm tra khả năng sử dụng là một phương pháp thử nghiệm nhằm mục đích thiết lập mức độ dễ sử dụng, “khả năng học hỏi”, tính dễ hiểu và tính hấp dẫn đối với người sử dụng sản phẩm đang được phát triển trong bối cảnh các điều kiện nhất định.

Tiện lợi (Thân thiện với người dùng):

  • quản lý và làm việc với hệ thống được tổ chức một cách rõ ràng, không cần đào tạo đặc biệt;
  • sự sắp xếp và hình thức thẩm mỹ của nội dung, màu sắc, biểu tượng;
  • sự hiện diện của một phần trợ giúp;
Hiệu quả:
  • Người dùng sẽ mất bao nhiêu thời gian và các bước để hoàn thành các tác vụ chính của ứng dụng, chẳng hạn như đăng một mục tin tức, đăng ký, mua hàng, v.v.? (ít hơn là tốt hơn);
  • tính phổ biến của định dạng cửa sổ/trang trong ứng dụng/trang web;
Sự chính xác:
  • không có lỗi ngữ pháp hoặc cú pháp, không có dữ liệu lỗi thời hoặc không chính xác được hiển thị;
  • không có liên kết bị hỏng;

Kiểm tra chuyển đổi dự phòng và phục hồi

Kiểm tra chuyển đổi dự phòng và phục hồi kiểm tra sản phẩm được kiểm tra về khả năng chịu đựng và phục hồi thành công sau các lỗi có thể xảy ra do lỗi phần mềm, lỗi phần cứng hoặc sự cố truyền thông (ví dụ: lỗi mạng). Mục đích của loại thử nghiệm này là để kiểm tra các hệ thống khôi phục (hoặc các hệ thống sao chép chức năng chính), trong trường hợp xảy ra lỗi, sẽ đảm bảo tính an toàn và tính toàn vẹn của dữ liệu của sản phẩm đang được thử nghiệm.
Kiểm tra lỗi và khắc phục là rất quan trọng đối với các hệ thống hoạt động 24×7, chẳng hạn như cửa hàng trực tuyến, hệ thống ERP.

Đối tượng kiểm tra trong hầu hết các trường hợp là các vấn đề vận hành có khả năng xảy ra cao, chẳng hạn như:

  • mất điện trên máy chủ;
  • mất điện trên máy khách;
  • chu trình xử lý dữ liệu không đầy đủ (gián đoạn bộ lọc dữ liệu, gián đoạn đồng bộ hóa);
  • khai báo hoặc đưa vào các phần tử không thể có hoặc có sai sót trong mảng dữ liệu;
  • lỗi phương tiện lưu trữ.

Kiểm tra GUI

  1. kiểm tra tất cả các thành phần GUI về kích thước, vị trí và sự chấp nhận các chữ cái và số. Ví dụ: trong tất cả các trường đầu vào, có thể nhập
  2. đảm bảo rằng giao diện đồ họa cho phép bạn triển khai đầy đủ tất cả chức năng của ứng dụng
  3. kiểm tra xem thông báo cảnh báo và lỗi có được hiển thị chính xác không
  4. kiểm tra khả năng đọc của các phông chữ được ứng dụng sử dụng, căn chỉnh, màu sắc của chúng
  5. kiểm tra hiển thị và vị trí của hình ảnh
  6. kiểm tra bố cục của các thành phần giao diện ở các độ phân giải màn hình khác nhau

Kiểm tra khả năng tương thích

Phần cứng: Tương thích với nhiều cấu hình phần cứng khác nhau.
Hệ điều hành: khả năng tương thích với nhiều hệ điều hành khác nhau: Windows, *nix, Mac OS, v.v.
Phần mềm: Tương thích với nhiều phần mềm khác nhau. Ví dụ: MS Word tương thích với MS Outlook, MS Excel, VBA, v.v.
Mạng lưới:Đánh giá hiệu suất hệ thống trên mạng với các thông số thay đổi như thông lượng, tốc độ vận hành, dung lượng. Kiểm tra khả năng sử dụng ứng dụng với các giá trị khác nhau của các tham số này.
Trình duyệt: kiểm tra tính tương thích của trang web với các trang phổ biến nhất: Firefox, Google Chrome, Internet Explorer, Opera, Safari.
Thiết bị: khả năng tương thích với nhiều thiết bị khác nhau: máy in, máy quét, thông tin liên lạc không dây, thiết bị USvoid.
Thiêt bị di động: tương thích với các nền tảng di động như Android, iOS, v.v.
Các phiên bản phần mềm: Tương thích với các phiên bản phần mềm khác nhau. Ví dụ: khả năng tương thích của Microsoft Word với Windows 10, Windows 8, Windows 7, Windows XP, Windows XP SP2, v.v.

Kiểm tra khói

Smoke test được thực hiện mỗi khi chúng tôi nhận được bản dựng (phiên bản) mới của dự án (hệ thống) để thử nghiệm, đồng thời coi nó là tương đối không ổn định. Chúng ta cần đảm bảo rằng các chức năng quan trọng của Ứng dụng/Hệ thống hoạt động như mong đợi. Ý tưởng của loại thử nghiệm này là xác định các vấn đề nghiêm trọng càng sớm càng tốt và từ chối bản dựng này (trả lại để sửa đổi) ở giai đoạn đầu thử nghiệm, để không đi sâu vào các thử nghiệm dài và phức tạp, từ đó tránh lãng phí thời gian trên phần mềm rõ ràng là bị lỗi.

Kiểm tra lại

Nó được thực hiện nếu tính năng/chức năng đã có lỗi và những lỗi này đã được sửa chữa gần đây.

Kiểm tra sự tỉnh táo

Được sử dụng mỗi khi chúng tôi nhận được bản dựng phần mềm tương đối ổn định để xác định hiệu suất một cách chi tiết. Nói cách khác, nó đang xác nhận rằng các phần quan trọng của chức năng hệ thống hoạt động theo yêu cầu ở mức độ thấp.

Kiểm tra hồi quy

Đây là điều chiếm phần lớn thời gian và tại sao tự động hóa thử nghiệm lại tồn tại. Kiểm tra hồi quy của Ứng dụng/Hệ thống được thực hiện khi cần đảm bảo rằng các chức năng ứng dụng mới (đã thêm)/các lỗi cố định không ảnh hưởng đến chức năng hiện tại, hiện có đã hoạt động (và đã thử nghiệm) trước đó.

Ví dụ giải thích sự khác biệt giữa các lần kiểm tra sau khi thay đổi

Chúng tôi có một dịch vụ web với giao diện người dùng và API RESTful. Là người thử nghiệm, chúng tôi biết:

  • Rằng nó có 10 điểm vào, để đơn giản, trong trường hợp của chúng tôi nằm trên cùng một IP
  • tất cả đều chấp nhận yêu cầu GET cho đầu vào, trả về một số dữ liệu ở định dạng json

Sau đó, một số tuyên bố có thể được đưa ra về loại thử nghiệm nào nên được sử dụng vào thời điểm nào:

  • Bằng cách thực hiện một yêu cầu NHẬN đơn giản tới một trong những điểm vào này. Nếu nhận được phản hồi từ dịch vụ ở định dạng JSON, tức là. không trả về lỗi 4xx hay 5xx hay gì đó mơ hồ thì không “hút thuốc”. Tại thời điểm này, chúng ta có thể nói rằng bài kiểm tra “khói” đã được thông qua. Để kiểm tra xem giao diện người dùng có hoạt động theo cách tương tự hay không, bạn chỉ cần mở trang một lần trong trình duyệt.
  • Kiểm tra vệ sinh trong trường hợp này sẽ bao gồm việc thực hiện yêu cầu tới tất cả 10 điểm đầu vào API.
  • Thử nghiệm lại trong ví dụ này là kiểm tra từng điểm một, chẳng hạn như một điểm truy cập bị hỏng trong API trong bản dựng tiếp theo sẽ hoạt động như dự kiến.
  • Các thử nghiệm hồi quy sẽ bao gồm Smoke + Sanity + UI chạy cùng nhau trong một đống:
    • Thực hiện yêu cầu tới tất cả 10 điểm nhập API, kiểm tra JSON đã nhận với điểm dự kiến, cũng như sự hiện diện của dữ liệu cần thiết trong đó
    • kiểm tra xem việc thêm điểm vào thứ 11 có bị hỏng không, chẳng hạn như khôi phục mật khẩu.

(tải xuống lược đồ ở dạng XML)

Phương pháp: thủ công và tự động

Kiểm tra bằng tay= Người kiểm tra thực hiện thủ công các kịch bản kiểm thử và trường hợp kiểm thử.

Hướng tới thử nghiệm tự động hóa Có các cách tiếp cận chính sau:

Một số công cụ tự động hóa thử nghiệm

  • Dòng phần mềm Selenium

bài viết hữu ích

  • Kiểm tra chức năng tự động
  • Làm thế nào để trở thành một chuyên gia tự động hóa thử nghiệm?
  • Hướng dẫn KIỂM TRA TỰ ĐỘNG: Quy trình, Lập kế hoạch & Công cụ
  • https://Gist.github.com/codedokode/a455bde7d0748c0a351a - Kiểm tra tự động
  • Các mô hình kiểm thử phần mềm (kiểm thử đơn vị, kiểm thử tích hợp)

Báo cáo lỗi

Báo cáo lỗi(báo cáo lỗi) = một tài liệu mô tả một tình huống hoặc chuỗi hành động dẫn đến hoạt động không chính xác của đối tượng thử nghiệm, cho biết lý do và kết quả mong đợi.

Bạn nên cố gắng soạn nó sao cho dựa vào tên hoặc mô tả ngắn gọn về lỗi (tóm tắt), nhà phát triển hiểu được vấn đề là gì và sau khi đọc mô tả chi tiết về lỗi (mô tả), anh ta đại khái biết. anh ta cần tìm ra lỗi ở thành phần nào hoặc thậm chí một phần của nó.

Ý nghĩa/mức độ nghiêm trọng của lỗi
0 tắt hệ thống máy chủ ngừng hoạt động dừng hệ thống
1 Mất dữ liệu mất dữ liệu Mất dữ liệu người dùng, nhà điều hành, hệ thống
2 Mất chức năng mất chức năng Chặn chức năng cơ bản. Có thể bao gồm các vấn đề phi chức năng, chẳng hạn như vấn đề về hiệu suất, gây ra sự chậm trễ không thể chấp nhận được trong việc sử dụng các tính năng
3 Lỗ hổng bảo mật mất an ninh
4 Mất chức năng với cách giải quyết mất chức năng nhưng tồn tại đường dẫn thay thế Chặn chức năng cốt lõi nhưng có cách giải quyết hợp lý cho người dùng
5 Mất một phần chức năng mất chức năng một phần Chặn sử dụng một số chức năng không cần thiết
6 Lỗi thẩm mỹ lỗi thẩm mỹ Những thiếu sót đáng kể trong giao diện người dùng hoặc khả năng đáp ứng yêu cầu của hệ thống

Người kiểm thử phải bảo vệ chất lượng và ý kiến ​​của người dùng về hệ thống. Nhưng họ không nên làm điều này bằng cách đóng vai trò là đối thủ cạnh tranh với các lập trình viên, khiếu nại cá nhân hoặc theo cách không mang tính xây dựng. Sẽ tốt hơn nếu chúng ta thực hiện việc này theo cách kết hợp thực tế kinh doanh với việc phát triển và bảo trì hệ thống.

Quy tắc định dạng tên (chủ đề) của báo cáo lỗi

"Trình chỉnh sửa danh mục: Xóa - yêu cầu người dùng xóa danh mục nếu người dùng xóa tất cả sản phẩm khỏi danh mục" là tên halal kosher Chính thống chính xác.
“Người tổ chức”, “Trang thuộc tính danh mục” - đối với những cái tên như vậy, các nhiệm vụ đã được gửi đến cổ phần chỉ 400 năm trước.

Cấu trúc của tên nhiệm vụ chính xác:
<Где (название страницы)> : <Какой элемент/функция страницы> - <суть ошибки/задания>
Mẫu:
Trình chỉnh sửa danh mục: Sao chép - không phải tất cả các danh mục hiện có đều được hiển thị trong hộp tổ hợp "chọn danh mục"
Thư viện danh mục -> Danh mục trùng lặp - Nếu tùy chọn "Sử dụng đối tượng" được đánh dấu, dữ liệu "Được chia sẻ với" phải được sao chép sang danh mục mới

Mẫu nội dung báo cáo lỗi

LÀM: ("HÀNH ĐỘNG", "BƯỚC SINH SẢN")
Cho biết trình tự hành động, cho chúng tôi biết chính xác bạn đã làm gì để đạt được trạng thái hệ thống mà bạn gặp phải lỗi

KẾT QUẢ: ("KẾT QUẢ:")
Mô tả hậu quả hành động của bạn, cho chúng tôi biết điều gì đã xảy ra, khi đạt đến “điểm không thể quay lại” và lỗi biểu hiện như thế nào

KẾT QUẢ DỰ KIẾN: ("KẾT QUẢ DỰ KIẾN:")
Mô tả về hành vi dự kiến ​​của hệ thống khi người dùng thực hiện các bước được chỉ định trong "DO". Kết quả mong đợi phải đáp ứng các yêu cầu của khách hàng được mô tả trong tài liệu hoặc lẽ thường. Nhà phát triển phải biết mình cần làm gì.

THÔNG TIN BỔ SUNG:
Để làm cho một báo cáo lỗi hay trở nên tuyệt vời, hãy tận dụng mọi cơ hội để bổ sung vào đó, chẳng hạn như:

  • Thêm ảnh chụp màn hình (lưu ý những vị trí quan trọng trên chúng, nếu cần).
  • Thêm nhật ký máy chủ hoặc văn bản thông báo lỗi (nếu thông tin này có sẵn).
  • Thêm suy nghĩ và giả định của bạn về lỗi bạn gặp phải (ngắn gọn, nếu có).

Ví dụ về báo cáo lỗi

Số liệu đảm bảo chất lượng

Số liệu (số liệu QA) là một thang đo và phương pháp định lượng có thể được sử dụng để đo lường.

Việc giới thiệu và sử dụng các số liệu là cần thiết để cải thiện việc kiểm soát quá trình phát triển, đặc biệt là quá trình thử nghiệm.

Mục đích của kiểm soát thử nghiệm là thu thập phản hồi và trực quan hóa quá trình thử nghiệm. Thông tin cần thiết cho việc kiểm soát được thu thập (cả thủ công và tự động) và được sử dụng để đánh giá trạng thái cũng như đưa ra các quyết định như phạm vi (ví dụ: phạm vi yêu cầu hoặc mã có kiểm tra) hoặc tiêu chí thoát (ví dụ: tiêu chí kết thúc kiểm tra). Các số liệu cũng có thể được sử dụng để đánh giá tiến độ thực hiện công việc theo kế hoạch và ngân sách.

Để rõ ràng, bạn có thể nhóm các số liệu theo loại thực thể liên quan đến đảm bảo chất lượng và kiểm thử phần mềm, cụ thể là:

  • Số liệu theo trường hợp thử nghiệm
  • Số liệu về lỗi/khiếm khuyết
  • Chỉ số theo nhiệm vụ

Số liệu cho các trường hợp thử nghiệm

Số liệu lỗi


Các số liệu "Lỗi mở/đóng", "Lỗi theo mức độ nghiêm trọng" và "Lỗi theo mức độ ưu tiên" trực quan hóa rõ mức độ mà sản phẩm đang tiến gần đến việc đạt được tiêu chí chất lượng cho lỗi.
Số liệu "Lỗi đã mở lại/đã đóng" và "Lỗi bị từ chối/đã mở" nhằm mục đích theo dõi công việc của từng thành viên trong nhóm phát triển và thử nghiệm.

Chỉ số theo nhiệm vụ

Tên Sự miêu tả
Nhiệm vụ triển khai Số liệu này hiển thị số lượng và kết quả cài đặt ứng dụng. Nếu số lượng phiên bản bị nhóm thử nghiệm từ chối cao đến mức nghiêm trọng, bạn nên khẩn trương phân tích và xác định nguyên nhân, cũng như giải quyết vấn đề hiện tại càng sớm càng tốt.
Nhiệm vụ vẫn mở Số liệu này cho thấy số lượng vấn đề vẫn còn tồn tại. Đến cuối dự án, tất cả các nhiệm vụ phải được hoàn thành. Theo nhiệm vụ, chúng tôi muốn nói đến các loại công việc sau: viết tài liệu (kiến trúc, yêu cầu, kế hoạch), triển khai các mô-đun mới hoặc thay đổi mô-đun hiện có dựa trên yêu cầu thay đổi, công việc thiết lập gian hàng, các nghiên cứu khác nhau và hơn thế nữa.

Số liệu cho các nhiệm vụ có thể khác nhau, chúng tôi chỉ đưa ra hai trong số đó. Số liệu về thời gian hoàn thành nhiệm vụ và nhiều số liệu khác cũng có thể thú vị.

Lựa chọn người thử nghiệm

Khi tuyển dụng, chúng ta phải trả lời câu hỏi “Người này có thể giúp chúng ta kiểm tra chất lượng sản phẩm phần mềm không?” Câu hỏi này khác với việc hỏi "Người này có thể viết mã được không?" hoặc “Người này có hiểu các vấn đề kinh doanh mà hệ thống giải quyết không?” - mặc dù một người kiểm thử có trình độ thường sẽ có cả kiến ​​thức kỹ thuật và kiến ​​thức về lĩnh vực.

Điều quan trọng nhất đối với một người thử nghiệm được thuê:

  • muốn học
  • Sự độc lập
  • không xung đột và linh hoạt. Người kiểm tra phải cố gắng ủng hộ và bảo vệ chất lượng theo cách hợp lý và trong bối cảnh kinh doanh nhưng phải thực hiện một cách chắc chắn và thuyết phục. Nếu một người thử nghiệm chuẩn bị một báo cáo lỗi mà nhà phát triển không thích và phải đối mặt với lập trình viên "không vui", anh ta không cần phải cúi đầu, đút tay vào túi và ngoan ngoãn lẩm bẩm: "Được rồi, được rồi." , Tôi nghĩ tôi sẽ rút lại báo cáo lỗi này." . Thay vào đó, người kiểm tra nên ngồi thẳng, lắng nghe lập luận của lập trình viên, sau đó nói những điều như thế này: “Đúng, nhưng nếu tôi là khách hàng và nhìn thấy hành vi này của hệ thống, tôi sẽ không có lý do gì để phấn khích”. Tính cách vững vàng nhưng linh hoạt là yêu cầu của một người thử nghiệm giỏi.
  • khả năng làm việc chăm chỉ và tập trung. Phải có sự hiểu biết về các ưu tiên chính và thử nghiệm mục tiêu để tuân theo chúng. Điều này khó thực hiện vì các ưu tiên thường xuyên thay đổi. Có những người kiểm tra, do không thể tập trung sự chú ý, đã gặp khó khăn trong việc hoàn thành các nhiệm vụ được giao với mức chất lượng phù hợp và trong khung thời gian thích hợp. Mặc dù họ có kiến ​​thức kiểm tra tốt, nhưng khoảng cách này trong tính cách của họ đã hạn chế tiềm năng của họ. người thử nghiệm nên báo cáo tin xấu cho nhóm phát triển. Người thử nghiệm thỉnh thoảng gặp phải sự kháng cự và phòng thủ, đóng vai trò là người mang tin xấu. Cả hai hiện tượng này đều tạo thêm căng thẳng trong cuộc sống của người thử nghiệm. Những người thử nghiệm giỏi buộc bản thân phải làm việc trong điều kiện mà vai trò của họ bị đánh giá thấp và những người tham gia dự án khác không hiểu rõ.

Điều quan trọng không kém là tìm hiểu ý định của người thử nghiệm được thuê - anh ta dự định phát triển theo hướng nào với tư cách là một chuyên gia, anh ta muốn học gì. Đó là một điều khi anh ấy quan tâm đến sự phát triển trong lĩnh vực thử nghiệm và một điều khác khi anh ấy dự định chuyển sang lĩnh vực lập trình.

Những người thử nghiệm mới bắt đầu tốt nhất thuộc các loại sau:

  • sinh viên hoặc sinh viên mới tốt nghiệp các trường đại học kỹ thuật;
  • các chuyên gia đã lựa chọn con đường sự nghiệp mới, trong đó có quân nhân đã nghỉ hưu;
  • cựu chuyên gia hỗ trợ kỹ thuật.

Một số công ty có thói quen sử dụng nhóm thử nghiệm làm nơi để các nhân viên mới, đặc biệt là những người có ý định lập trình, dành một khoảng thời gian. Có ý kiến ​​​​cho rằng cách tiếp cận này có lợi cho toàn bộ công ty, nhưng có ba điểm cần lưu ý.

Đầu tiên, cách tiếp cận này nâng cao kiến ​​thức về lĩnh vực và chuyên môn kỹ thuật, vốn là chìa khóa để kiểm thử hiệu quả, nhưng lại giảm thiểu các kỹ năng cụ thể về kiểm thử.

Thứ hai, khá khó để thuyết phục một người thử nghiệm dự định trở thành nhà phát triển cải thiện kỹ năng thử nghiệm của mình, vì sự phát triển của những kỹ năng này không tương ứng với nguyện vọng nghề nghiệp của anh ta.

Thứ ba, việc luân chuyển liên tục trong nhóm thử nghiệm sẽ tạo thêm những vấn đề mới cho người quản lý thử nghiệm, người vốn đã khá bận rộn. Để phương pháp này có hiệu quả, toàn bộ công ty phải làm việc cùng nhau để tìm ra giải pháp cho những vấn đề này, không chỉ người quản lý kiểm thử.

Vấn đề thứ tư, không thực sự cụ thể đối với thực tiễn này, nhưng phát sinh bất cứ khi nào nhóm thử nghiệm trở thành vùng nước đọng hoặc đầm lầy đối với những nhân viên bị các bộ phận khác của công ty từ chối. Đây đương nhiên là tình huống khó giải quyết nhất đối với người thử nghiệm trưởng hoặc người quản lý thử nghiệm khi xây dựng nhóm thử nghiệm. Thông điệp ngầm ở đây là "Chúng ta cần làm việc với những người bị coi là không mong muốn vì nhiều lý do khác nhau; chúng ta cần thử nghiệm trong những điều kiện hiện hành." Một số người trong số này hóa ra là những người thử nghiệm xuất sắc, trong khi những người khác lại trở thành nguồn gốc của vô số vấn đề.

Để duy trì động lực, công việc mà mỗi người kiểm thử làm phải phù hợp với nguyện vọng nghề nghiệp của họ.

Giảm xung- giảm tần suất hoạt động của thiết bị.

Lỗi (khiếm khuyết)- sự thiếu sót trong một thành phần hoặc hệ thống có thể dẫn đến hỏng một chức năng cụ thể.

Mức độ ưu tiên của lỗi - tầm quan trọng của một lỗi phần mềm cụ thể:

  • Tầm thường là một vấn đề mỹ phẩm, tế nhị.
  • Minor là một vấn đề nhỏ, hiển nhiên.
  • Chính là một vấn đề quan trọng.
  • Quan trọng - một vấn đề cản trở các chức năng chính của phần mềm.
  • Blocker là sự cố làm gián đoạn hoạt động của phần mềm.

Báo cáo lỗi- tài liệu mô tả tình huống hoặc chuỗi hành động dẫn đến hoạt động không chính xác của đối tượng thử nghiệm, nêu rõ lý do và kết quả mong đợi.

Thẩm định- xác định xem phần mềm đang được phát triển có đáp ứng được mong đợi, nhu cầu của người dùng và yêu cầu hệ thống hay không.

xác minh- quá trình đánh giá một hệ thống hoặc các thành phần của nó để xác định xem kết quả của giai đoạn phát triển hiện tại có đáp ứng các điều kiện được hình thành ở đầu giai đoạn này hay không.

Sự chỉ rõ- mô tả chi tiết về cách thức hoạt động của phần mềm.

Hệ thống theo dõi lỗi (Tiếng Anh hệ thống theo dõi lỗi) - chương trình kiểm soát và/hoặc kiểm soát lỗi:

  • Atlassian JIRA
  • Bugzilla
  • YouTrack
  • Redmine

Kiểm tra- quá trình kiểm tra sự tuân thủ các yêu cầu được công bố đối với một sản phẩm có chức năng được triển khai thực tế, được thực hiện bằng cách quan sát hoạt động của nó trong các tình huống được tạo ra một cách giả tạo và trên một tập hợp các thử nghiệm giới hạn được chọn theo một cách nhất định.

Đảm bảo chất lượng (QA)- một tập hợp các hoạt động bao gồm tất cả các giai đoạn công nghệ phát triển, phát hành và vận hành phần mềm

Gỡ lỗi (Gỡ lỗi tiếng Anh) là một quy trình cho phép bạn có được phần mềm hoạt động với các đặc điểm cần thiết trong một vùng dữ liệu đầu vào nhất định.

Lỗi (Tiếng AnhLỗi) – một hành động tạo ra kết quả không chính xác.

Tai nạn (Tiếng Anh: Thất bại) – sự khác biệt giữa kết quả thực tế của một thành phần hoặc hệ thống và kết quả mong đợi.

Phân loại theo loại thử nghiệm:
Thử nghiệm di động- thử nghiệm các ứng dụng di động.
Kiểm tra bảng điều khiển— thử nghiệm các ứng dụng dành cho bảng điều khiển.
Kiểm tra web(Kiểm tra trình duyệt) - kiểm tra các ứng dụng trình duyệt.

Phân loại theo mã chạy để thực thi:
Kiểm tra tĩnh(Tiếng Anh) Kiểm tra tĩnh) - kiểm tra mà không chạy mã để thực thi.
Thử nghiệm động (Tiếng Anh Thử nghiệm động) - thử nghiệm bằng cách chạy mã để thực thi.

Phân loại theo quyền truy cập vào mã và kiến ​​trúc phần mềm:
Hộp đen (Tiếng Anh Hộp đen) — người kiểm tra không biết hệ thống được kiểm tra được cấu trúc như thế nào.
hộp trắng (Tiếng Anh hộp trắng) — người kiểm tra biết tất cả các chi tiết về việc triển khai hệ thống đang được kiểm tra.
Hộp màu xám (Tiếng Anh Hộp màu xám) - người thử nghiệm chỉ biết một số tính năng thiết kế của hệ thống được thử nghiệm.

Phân loại theo mức độ tự động hóa:
Kiểm tra bằng tay (Tiếng Anh Kiểm tra bằng tay) - kiểm tra phần mềm với tư cách là người dùng.
Kiểm tra tự động (Tiếng Anh Kiểm tra tự động) — kiểm thử phần mềm bằng các chương trình đặc biệt.

Phân loại theo nguyên tắc làm việc với ứng dụng:
Thử nghiệm tích cực (Tiếng Anh Thử nghiệm tích cực) - kiểm tra phần mềm để xác định xem nó sẽ hoạt động như thế nào.
Xét nghiệm âm tính (Tiếng Anh Xét nghiệm âm tính) - kiểm tra phần mềm để xác định xem nó không hoạt động như thế nào.

Phân loại theo mức độ chi tiết của ứng dụng:
Thử nghiệm hội nhập- kiểm tra sự tương tác và kết nối của một số thành phần ứng dụng.
Thử nghiệm hệ thốngđang thử nghiệm toàn bộ ứng dụng từ đầu đến cuối.
Kiểm tra đơn vị- thử nghiệm ở cấp độ thành phần chức năng riêng lẻ của ứng dụng.

Phân loại theo mục đích và mục tiêu:
Thử nghiệm chức năng- kiểm tra hoạt động chính xác của chức năng ứng dụng.
Kiểm tra phi chức năng- kiểm tra các tính năng phi chức năng của ứng dụng (dễ sử dụng, tương thích, hiệu suất, bảo mật).
Kiểm tra cài đặt- kiểm tra tiến độ của giai đoạn cài đặt ứng dụng.
Kiểm tra hồi quy- kiểm tra các lỗi gây ra bởi những thay đổi trong ứng dụng.
Kiểm tra lại- Thực hiện các trường hợp kiểm thử đã phát hiện lỗi trước đó để xác nhận việc loại bỏ lỗi.
Kiểm tra chấp nhận- thử nghiệm nhằm mục đích kiểm tra ứng dụng theo quan điểm của người dùng/khách hàng cuối
Kiểm tra khả năng sử dụng- thử nghiệm nhằm mục đích nghiên cứu mức độ rõ ràng của người dùng cuối trong cách làm việc với sản phẩm cũng như mức độ họ thích sử dụng sản phẩm.
Kiểm tra khả năng truy cập- thử nghiệm nhằm mục đích kiểm tra sự phù hợp của sản phẩm để người khuyết tật sử dụng
Kiểm tra giao diện- thử nghiệm nhằm mục đích kiểm tra các giao diện của ứng dụng hoặc các thành phần của nó.
Kiểm tra bảo mật- thử nghiệm nhằm mục đích xác minh khả năng của ứng dụng chống lại các nỗ lực độc hại nhằm giành quyền truy cập vào dữ liệu hoặc chức năng
Thử nghiệm quốc tế hóa- thử nghiệm nhằm mục đích kiểm tra tính sẵn sàng của sản phẩm để hoạt động bằng các ngôn ngữ khác nhau và có tính đến các đặc điểm văn hóa và quốc gia khác nhau.
Thử nghiệm bản địa hóa- thử nghiệm nhằm mục đích kiểm tra tính chính xác và chất lượng thích ứng của sản phẩm để sử dụng bằng một ngôn ngữ cụ thể, có tính đến các đặc điểm văn hóa và quốc gia.
Kiểm tra khả năng tương thích- thử nghiệm nhằm mục đích kiểm tra khả năng hoạt động của ứng dụng trong môi trường được chỉ định (trình duyệt, thiết bị di động, v.v.).
Kiểm tra dữ liệu và cơ sở dữ liệu- thử nghiệm nhằm mục đích nghiên cứu các đặc điểm dữ liệu như tính đầy đủ, tính nhất quán, tính toàn vẹn, cấu trúc, v.v.
Kiểm tra việc sử dụng tài nguyên- một tập hợp các loại thử nghiệm để kiểm tra tính hiệu quả của việc sử dụng các tài nguyên có sẵn của ứng dụng và sự phụ thuộc của kết quả của ứng dụng vào số lượng tài nguyên có sẵn cho nó.
Kiểm tra so sánh- thử nghiệm nhằm mục đích phân tích so sánh các ưu điểm và nhược điểm của sản phẩm đang được phát triển so với các đối thủ cạnh tranh chính.
thử nghiệm demo- quá trình chính thức chứng minh sản phẩm cho khách hàng để xác nhận rằng sản phẩm đáp ứng tất cả các yêu cầu đã nêu.
Kiểm tra quá mức- kiểm tra ứng dụng với tất cả các kết hợp có thể có của tất cả dữ liệu đầu vào có thể có trong tất cả các điều kiện thực thi có thể có.
Kiểm tra độ tin cậy- kiểm tra khả năng ứng dụng thực hiện các chức năng của nó trong các điều kiện quy định.
Kiểm tra khả năng phục hồi- kiểm tra khả năng của ứng dụng trong việc khôi phục các chức năng và mức hiệu suất nhất định, cũng như khôi phục dữ liệu trong trường hợp nghiêm trọng.
Kiểm tra khả năng chịu lỗi- thử nghiệm, bao gồm mô phỏng hoặc thực sự tạo ra các tình huống quan trọng để kiểm tra khả năng ứng dụng sử dụng các cơ chế ngăn chặn sự gián đoạn chức năng, hiệu suất và hỏng dữ liệu.
Kiểm tra năng suất- nghiên cứu các chỉ số về tốc độ phản hồi của ứng dụng trước các tác động bên ngoài dưới các tải trọng có tính chất và cường độ khác nhau.
Bài kiểm tra về áp lực- nghiên cứu khả năng của ứng dụng trong việc duy trì các chỉ số chất lượng được chỉ định khi tải trong giới hạn chấp nhận được và vượt quá các giới hạn này một chút/
Kiểm tra khả năng mở rộng- nghiên cứu khả năng của ứng dụng trong việc tăng các chỉ số hiệu suất phù hợp với sự gia tăng số lượng tài nguyên có sẵn cho ứng dụng.
Kiểm tra khối lượng- nghiên cứu hiệu suất ứng dụng khi xử lý khối lượng dữ liệu khác nhau (thường là lớn).
Bài kiểm tra về áp lực- nghiên cứu hành vi ứng dụng khi tải thay đổi bất thường vượt quá mức tính toán đáng kể.
Thử nghiệm cạnh tranh- nghiên cứu hành vi của một ứng dụng trong tình huống nó phải xử lý một số lượng lớn các yêu cầu đến đồng thời, gây ra sự cạnh tranh giữa các yêu cầu về tài nguyên (cơ sở dữ liệu, bộ nhớ, liên kết dữ liệu, hệ thống con đĩa, v.v.)
Kiểm tra tiêu điểm (Tiếng Anh Kiểm tra tiêu điểm) - thử nghiệm được thực hiện để thu được phản ứng ban đầu của người chơi. Cần thiết để đánh giá khả năng sử dụng và mức độ chấp nhận sản phẩm của đối tượng mục tiêu hoặc bên thứ ba.

Sự thất bại- lỗi (và không nhất thiết là lỗi phần cứng) trong hoạt động của một thành phần, toàn bộ chương trình hoặc hệ thống.

trải nghiệm người dùng (Tiếng Anh Trải nghiệm người dùng - trải nghiệm người dùng) là cảm giác của người dùng khi sử dụng sản phẩm kỹ thuật số.

giao diện người dùng (Tiếng Anh Giao diện người dùng - giao diện người dùng) là một công cụ cho phép tương tác giữa người dùng và ứng dụng.

Phân tích giá trị biên (Tiếng Anh Phân tích giá trị biên - BVA). Phân tích giá trị biên có thể được áp dụng cho các trường, bản ghi, tệp hoặc bất kỳ loại thực thể bị ràng buộc nào.

Kiểm tra khói (Tiếng Anh Kiểm tra khói) là một loạt các thử nghiệm ngắn để xác nhận rằng sau khi lắp ráp mã (mới hoặc cố định), ứng dụng sẽ khởi động và thực hiện các chức năng cơ bản.

Thử nghiệm thăm dò (đặc biệt) là việc phát triển và thực hiện các thử nghiệm cùng một lúc, điều này trái ngược với cách tiếp cận theo kịch bản.

Kiểm tra cấu hình (Tiếng Anh Kiểm tra cấu hình) - một loại thử nghiệm đặc biệt nhằm kiểm tra hoạt động của phần mềm trong các cấu hình hệ thống khác nhau (nền tảng được khai báo, trình điều khiển được hỗ trợ, cấu hình máy tính khác nhau, v.v.)

Ma trận tuân thủ yêu cầu (Tiếng Anh Ma trận truy xuất nguồn gốc) là bảng hai chiều chứa sự tương ứng giữa các yêu cầu chức năng của sản phẩm và các ca kiểm thử đã chuẩn bị.

Thử nghiệm vận hành (Tiếng Anh Thử nghiệm phát hành). Ngay cả khi một hệ thống đáp ứng tất cả các yêu cầu, điều quan trọng là phải đảm bảo rằng nó đáp ứng được nhu cầu của người dùng và hoàn thành vai trò của nó trong môi trường vận hành như được xác định trong mô hình kinh doanh của hệ thống.

Dự đoán lỗi (Tiếng Anh Lỗi Đoán - EG). Đây là khi nhà phân tích kiểm thử sử dụng kiến ​​thức của mình về hệ thống và khả năng diễn giải thông số kỹ thuật để “dự đoán” trong những điều kiện đầu vào nào hệ thống có thể bị lỗi.

Nguyên nhân/Kết quả (Tiếng Anh Nguyên nhân/Hậu quả - CE). Theo quy định, đây là việc nhập kết hợp các điều kiện (lý do) để nhận được phản hồi từ hệ thống (Hiệu ứng).

Kiểm tra vệ sinh- đây là thử nghiệm tập trung ở phạm vi hẹp đủ để chứng minh rằng một chức năng cụ thể hoạt động theo các yêu cầu được nêu trong đặc tả.

sự nghiêm túc (Tiếng Anh Mức độ nghiêm trọng) là thuộc tính mô tả tác động của lỗi đến hiệu suất của ứng dụng.

Các giai đoạn phát triển phần mềm- đây là những giai đoạn mà nhóm phát triển phần mềm phải trải qua trước khi chương trình được cung cấp cho nhiều người dùng.

Tiền alpha (Tiếng Anh Tiền alpha) - giai đoạn phát triển ban đầu. Khoảng thời gian từ khi bắt đầu phát triển cho đến khi phát hành giai đoạn Alpha. Đây cũng là tên được đặt cho các chương trình đã vượt qua giai đoạn phát triển để đánh giá ban đầu về chức năng đang hoạt động.

Thử nghiệm alpha (Tiếng Anh Thử nghiệm alpha) - bắt chước công việc thực tế với hệ thống của các nhà phát triển toàn thời gian hoặc công việc thực tế với hệ thống của người dùng/khách hàng tiềm năng ở giai đoạn đầu phát triển sản phẩm, nhưng trong một số trường hợp, nó có thể được sử dụng cho một sản phẩm hoàn chỉnh dưới dạng chấp nhận nội bộ thử nghiệm.

Thử nghiệm beta (Tiếng Anh Thử nghiệm beta) - sử dụng nhiều phiên bản gần như hoàn thiện của sản phẩm để xác định số lượng lỗi tối đa trong hoạt động của sản phẩm nhằm loại bỏ chúng sau đó trước khi đưa sản phẩm cuối cùng ra thị trường cho người tiêu dùng đại chúng.

Phát hành ứng viên hoặc RC (Tiếng Anh Phát hành ứng viên), Tiền phát hành, đôi khi là "phiên bản gamma" - giai đoạn ứng viên để trở nên ổn định.

Phát hành hoặc RTM (Tiếng Anh Phát hành vào sản xuất - phiên bản công nghiệp) - xuất bản một sản phẩm sẵn sàng để nhân rộng.

Sau phát hành hoặc Hậu RTM (Tiếng Anh Sau khi đưa vào sản xuất) là việc phát hành một sản phẩm có một số điểm khác biệt so với RTM và được đánh dấu là giai đoạn phát triển đầu tiên của sản phẩm tiếp theo.

Bảng quyết định (Tiếng Anh Bảng quyết định) là một công cụ để tổ chức các yêu cầu nghiệp vụ phức tạp phải được triển khai trong một sản phẩm.

Thiết kế thử nghiệm (Tiếng Anh Thiết kế thử nghiệm) là một giai đoạn của quy trình kiểm thử phần mềm trong đó các trường hợp kiểm thử (test case) được thiết kế và tạo ra.

kế hoạch kiểm tra (Tiếng Anh Kế hoạch kiểm tra) là tài liệu mô tả toàn bộ phạm vi công việc kiểm thử cũng như đánh giá rủi ro cùng với các phương án giải quyết.

Kiểm tra tương tác (Tiếng Anh Kiểm tra khả năng tương tác) là thử nghiệm chức năng nhằm kiểm tra khả năng tương tác của ứng dụng với một hoặc nhiều thành phần hoặc hệ thống.

Kiểm tra bản dựng (Tiếng Anh Kiểm tra xác minh bản dựng) - thử nghiệm nhằm xác định sự tuân thủ của phiên bản đã phát hành với các tiêu chí chất lượng để bắt đầu thử nghiệm.

Kiểm tra giao diện người dùng (Tiếng Anh Kiểm tra giao diện người dùng) - thử nghiệm được thực hiện để xác định xem một số đối tượng nhân tạo (chẳng hạn như trang web, giao diện người dùng hoặc thiết bị) có phù hợp với mục đích sử dụng của nó hay không.

Trường hợp thử nghiệm (Tiếng Anh Trường hợp thử nghiệm) là một tạo phẩm mô tả một tập hợp các bước, điều kiện cụ thể và tham số cần thiết để kiểm tra việc triển khai chức năng đang được kiểm tra hoặc một phần của nó.

Danh mục (Tiếng Anh Danh mục) là tài liệu mô tả những gì cần được kiểm tra.

Phân chia tương đương (Tiếng Anh Phân vùng tương đương - EP). Ví dụ: nếu bạn có một phạm vi giá trị hợp lệ từ 1 đến 10, bạn phải chọn một giá trị đúng bên trong khoảng, giả sử là 5 và một giá trị không chính xác ngoài khoảng, 0.

xung đột Z (Tiếng Anh chiến đấu với Z) - chồng các họa tiết lên nhau.

Ép xung (Tiếng Anh Ép xung) là quá trình tăng tần số (và điện áp) của một bộ phận máy tính ngoài các chế độ tiêu chuẩn nhằm tăng tốc độ hoạt động của nó.

Chủ yếu - tìm hiểu càng nhiều càng tốt về một người người đang ngồi trước mặt bạn: anh ta có kỹ năng kinh doanh không, anh ta có thể gây ấn tượng với cấp trên và khách hàng bằng trí thông minh của mình không, anh ta có thể kiềm chế cảm xúc của mình không, anh ta sẽ giao tiếp với đồng nghiệp như thế nào.

Để làm điều này, họ sử dụng một phương pháp gọi là thử nghiệm.

Bạn có biết rằng lần đầu tiên một điều đặc biệt thử nghiệm đã được thực hiện vào thời cổ đại. Và nhà khoa học Hy Lạp cổ đại Pythagoras đã đưa ra những vấn đề giúp ta có thể biết được học sinh đó ngu hay thông minh. Ông lập luận rằng “không phải cây nào cũng có thể khắc được vào Sao Thủy”.

Việc kiểm tra được thực hiện như thế nào?

Bạn bước vào văn phòng và ngồi đối diện với một người bạn vẫn chưa quen, người này đang rất lo lắng.

Bạn bắt đầu nói chuyện với anh ta và hiểu rằng người nộp đơn đã sẵn sàng làm bài kiểm tra, điều đó có thể bóp méo tính hợp lệ của kết quả.

Bước thứ hai là kiểm tra:

  1. Phát bài kiểm tra với các câu hỏi và bài tập, phiếu trả lời.
  2. Giải thích cho mục đích gì bạn sẽ được thử nghiệm.
  3. Đọc to hướng dẫn hoặc đưa cho tôi bản in.
  4. Các thử nghiệm nên bao gồm 20-25 nhiệm vụ.
  5. Chỉ định điều đó cho mỗi nhiệm vụ đưa ra một phút mỗi lần. Khi hết thời gian, việc kiểm tra sẽ dừng ngay lập tức.
  6. Nếu một người không hiểu, cho một ví dụ thực hiện các nhiệm vụ tương tự.
  7. Trả lời câu hỏi của ứng viên.
  8. Nhận con nuôi câu trả lời và sự xác minh của họ. Ứng viên có thể làm quen với kết quả của quá trình xử lý, nhưng điều này không bắt buộc.

Tải xuống ví dụ và bài kiểm tra mẫu với câu trả lời và nhận xét, bạn có thể theo các liên kết sau.

Các bài kiểm tra việc làm khác có đáp án có thể được tìm thấy trên Internet.

Các loại

Kiểm tra việc làm được chia thành nhiều loại: chuyên nghiệp, cá nhân, trí tuệ, toán học, logic, lời nói, sự chú ý, trí thông minh, khả năng học tập, cơ khí và phổ biến nhất trong các tổ chức thương mại, “Cách bán một cây bút”.

Chúng ta hãy xem xét kỹ hơn về từng người trong số họ.

Chuyên nghiệp

Để xác định tính chuyên nghiệp của người nộp đơn, các chuyên gia sử dụng bài kiểm tra đặc biệt. For – nhiệm vụ về kiến ​​thức kế toán; Vì thư ký- vượt qua bài kiểm tra về khả năng nắm vững các kiến ​​thức cơ bản của công việc văn phòng, kiểm tra khả năng đọc viết, chú ý đến chi tiết, tốc độ đánh máy, truy xuất thông tin nhanh và hiệu quả; Vì chuyên gia thuế- vượt qua các bài kiểm tra thuế, cho luật sư và nhà kinh tế- kiểm tra kiến ​​thức pháp luật hoặc kinh tế, trình độ hiểu biết về ngoại ngữ, trình độ thành thạo các chương trình máy tính, v.v.

đặt câu hỏi và một số phương án trả lời: có, không, trong một số trường hợp.

Trong trường hợp này nó được đưa ra diễn dịch câu trả lời.

Với những lời giải thích như vậy, bạn có thể thấy ngay câu trả lời.

Và sử dụng các phím làm sẵn cho bài kiểm tra, hãy xác định số lượng câu trả lời đúng và đưa ra quyết định của mình.

Nhà tuyển dụng có thể đưa ra một bài kiểm tra để ứng viên kiểm tra kiến ​​thức của họ về một số kỹ thuật Excel.

Người nộp đơn có kinh nghiệm, nắm vững lý thuyết và trả lời được hầu hết các câu hỏi đều có cơ hội nhận được vị trí đáng mơ ước.

Cá nhân hoặc tâm lý

Thông minh

Nếu làm việc đòi hỏi đầu tư tinh thần, thì người sử dụng lao động có quyền biết khả năng trí tuệ của nhân viên mình cao đến mức nào.

Vì mục đích này mà loại thử nghiệm này được sử dụng để đánh giá một cách khách quan đánh giá trình độ trí tuệ (IQ) người nộp đơn.

Để lựa chọn đúng nhiệm vụ, cuốn sách của nhà tâm lý học người Anh là phù hợp G. Eysenck.

Bạn có thể sử dụng bài kiểm tra amthauer. Nó xác định mức độ khả năng tinh thần bằng cách sử dụng chín tiêu chí.

Dựa trên kết quả, bạn có thể xác định chính xác tư duy toán học của một ứng viên hoặc một nhà nhân văn và thậm chí xác định ngành nghề nào trong số 49 ngành nghề phù hợp.

Bạn có thể làm bài kiểm tra trí thông minh trực tuyến.

Toán học

Nhà toán học vĩ đại không tìm kiếm việc làm mà tự mình tìm thấy nó. Nhưng người đứng đầu công ty hay người đứng đầu công ty cần kế toán viên chuyên nghiệp hoặc nhà kinh tế người không chỉ có thể đếm mà còn có thể thực hiện các phép toán phức tạp.

Đưa ra một bài kiểm tra từ 20 đến 30 nhiệm vụ đơn giản và phức tạp, bao gồm tìm tỷ lệ, phân số, tính hiệu, cộng nhiều số, hiểu sơ đồ, hình vẽ, đồ họa, làm việc với các số liệu. Người nộp đơn cần nhanh chóng hiểu những con số nào nên được sử dụng để hoạt động.

Dựa trên kết quả kiểm tra sẽ rõ ràng Liệu một chuyên gia có thể giải quyết được các vấn đề toán học?ở một vị trí mới.

Bạn có thể làm bài kiểm tra toán trực tuyến.

trêu ghẹo não

Các bài kiểm tra logic cho việc làm nhằm mục đích mức độ thông minh của ứng viên, là trung tâm của nhiều ngành nghề. Chúng là một công cụ tuyệt vời để phát hiện hành vi của con người trong một tình huống xa lạ.

Các thử nghiệm logic cho hoạt động thoạt nhìn có vẻ vô lý. Một trong những vấn đề nói rằng một số con ốc là núi. Núi yêu mèo. Điều này có nghĩa là tất cả các loài ốc đều yêu mèo.

Điều quan trọng nhất đối với người làm bài thi là phải tập trung, xây dựng một chuỗi logic, giải thích đi, không để ý đến ốc sên và mèo. Chuyên gia phải hiểu liệu nhân viên tương lai có thể suy luận logic và suy nghĩ sáng tạo hay không.

Bài kiểm tra logic có thể được thực hiện trực tuyến.

bằng lời nói

Kiểm tra bằng lời nói rất hữu ích cho việc kiểm tra công việc giáo viên, dịch giả hoặc thư ký.

Tạo cơ hội để đánh giá kỹ năng của ứng viên làm việc với văn bản: hiểu, phân tích, đánh giá thông tin, rút ​​ra kết luận.

Ứng viên có cơ hội đạt được vị trí như mong muốn nếu thông thạo tiếng mẹ đẻ, nói năng logic, thành thạo và có vốn từ vựng phong phú.

Để thực hiện một bài kiểm tra bằng lời nói thường nhiều thời gian hơn được đưa ra hơn là số. Câu trả lời bao gồm các chữ cái hoặc một từ. Bạn cần phải chọn từ một số phương án hoặc tự mình đưa ra câu trả lời.

Nhưng có một loại bài kiểm tra nói mà bạn cần đọc một đoạn văn bản thông tin ngắn và một vài câu. Người xin việc phải tiết lộ sự thật hay giả dối của tuyên bố này.

Bài kiểm tra bằng lời nói giúp nhà tuyển dụng hiểu được liệu bài phát biểu của ứng viên có ngắn gọn hay không, liệu anh ta có thể thuyết phục và chứng minh bằng lời nói hay không.

Bạn có thể làm bài kiểm tra nói trực tuyến.

Đối với khả năng học tập

Nhiều ứng viên trẻ viết: “Sẵn sàng học.” Nhưng những người có nhiều kinh nghiệm và kinh nghiệm không muốn đào tạo lại, nghĩ rằng kiến ​​thức họ tích lũy được là đủ. Để làm được điều này, một bài kiểm tra ngắn được sử dụng để đánh giá khả năng học tập (khả năng xử lý và tiếp nhận thông tin mới).

Cơ học

Kiểm tra cơ học được cung cấp tới một nhóm chuyên gia hẹp, chủ yếu dành cho các ứng viên thuộc chuyên ngành thể chất và ngành kỹ thuật.

Các bài kiểm tra kiểm tra tư duy không gian, kiến ​​thức và kinh nghiệm, đồng thời xác định khả năng làm việc với các bản vẽ, thiết bị cơ khí và thiết bị phức tạp. Đây là những bài kiểm tra bao gồm các câu hỏi đơn giản nhưng Chỉ người hiểu cơ khí mới trả lời được.

Thử nghiệm trực tuyến về cơ học được cung cấp.

Trên máy đo đa giác

Các công ty lớn sử dụng hệ thống phần cứng di động khi tuyển dụng.

Người sử dụng lao động có thể nộp đơn không máy phát hiện nói dối?

Luật pháp không cấm điều đó.

Bộ luật Lao động cho phép bạn có được thông tin về một nhân viên mà không nghi ngờ gì. Nhưng ứng viên có quyền từ chối kiểm tra thành thật nếu anh ta coi đây là một sự sỉ nhục đối với phẩm giá con người của mình.

Quá trình thử nghiệm là gì? Ba loại câu hỏi: điều chỉnh, khắc phục phù hợp thực tế.

Nếu hai câu trả lời cuối cùng là trung thực thì các thông số sinh lý của một người đều giống nhau. Họ biến đổi nếu một người nói dối. Điều này được thiết bị ghi lại.

Sức hấp dẫn của việc uống rượu không thể che giấu khỏi “Polygraph”; ma túy, trộm cắp, nghiện cờ bạc, bất kỳ khoản vay nào, tiền án tiền sự và thậm chí cả những người thân đã bị kết án; liệu một người có khả năng gây tổn hại cho công ty hay không.

Các câu trả lời được đưa ra đánh giá không thể nhầm lẫn về ứng cử viên. Khi kết thúc cuộc kiểm tra, nhà tuyển dụng sẽ quyết định xem ứng viên có làm việc hay không.

"Bán bút đi"

Đối với những ứng viên muốn làm việc trong lĩnh vực thương mại, các chuyên gia sẽ tiến hành bài kiểm tra phổ biến"Bán cho tôi một cây bút."

Bất kỳ mặt hàng nào được cung cấp: bút, bút chì, sổ ghi chú, giá được gọi. Không thể trao đổi hoặc tặng quà. Anh ta phải bán mặt hàng này trong vòng năm phút. Nhà tuyển dụng lên tiếng với tư cách là người mua.

Tình huống này gây căng thẳng cho ứng viên vì nó gần với tình huống bán hàng thực tế. Bài kiểm tra được thực hiện nhiều lần trong vô số cuộc phỏng vấn. Kết quả là người sử dụng lao động nhận được một cái nhìn khách quan về kỹ năng và kỹ thuật giám đốc bán hàng tương lai.

Bản tóm tắt

Vậy có đáng để thử sử dụng các bài kiểm tra khi tuyển dụng nhân sự không?

Đội ngũ nhân viên chuyên nghiệp- đây là giai đoạn rất quan trọng trong việc quản lý một tổ chức, là sự đảm bảo cho sự thành công, là báu vật cần được bảo vệ.

Nếu lựa chọn đúng thì nó sẽ tăng lên năng suất, hiệu quả toàn bộ nhân viên của tổ chức.

Sai lầm là tốn kém. Khả năng tuyển dụng là một tài năng thực sự không thường thấy.