100 câu hỏi phỏng vấn hàng đầu năm 2022

Kiểm tra phần mềm liên quan đến việc đánh giá và xác minh chức năng của sản phẩm phần mềm. Về cơ bản, nó kiểm tra xem sản phẩm phần mềm có phù hợp với các yêu cầu dự kiến ​​hay không và đảm bảo nó không có khuyết tật. Có thể nói rằng thử nghiệm nâng cao chất lượng của sản phẩm bằng cách ngăn ngừa lỗi, giảm chi phí phát triển và giảm các vấn đề về hiệu suất. & nbsp;

Bạn có thể kiểm tra phần mềm theo nhiều cách khác nhau. Một số loại thử nghiệm được thực hiện bởi các nhà phát triển phần mềm và một số bởi nhân viên đảm bảo chất lượng chuyên ngành. Dưới đây là một vài loại thử nghiệm phần mềm khác nhau, cùng với một mô tả ngắn gọn về từng loại.

Kiểm tra phần mềm được điều chỉnh bởi bảy nguyên tắc: & NBSP;

• Sự vắng mặt của sai lầm sai lầm: Ngay cả khi phần mềm không có lỗi 99%, không thể sử dụng nếu nó không phù hợp với yêu cầu của người dùng. Phần mềm cần phải không có lỗi 99% thời gian và nó cũng phải đáp ứng tất cả các yêu cầu của khách hàng.Even if the software is 99% bug-free, it is unusable if it does not conform to the user's requirements. Software needs to be bug-free 99% of the time, and it must also meet all customer requirements.
• Kiểm tra cho thấy sự hiện diện của các lỗi: Kiểm tra có thể xác minh sự hiện diện của các lỗi trong phần mềm, nhưng nó không thể đảm bảo rằng phần mềm không có lỗi. Kiểm tra có thể giảm thiểu số lượng khiếm khuyết, nhưng nó không thể loại bỏ tất cả. & NBSP; Testing can verify the presence of defects in software, but it cannot guarantee that the software is defect-free. Testing can minimize the number of defects, but it can't remove them all. 
• Không thể kiểm tra toàn diện: Phần mềm không thể được kiểm tra một cách hoàn toàn, điều đó có nghĩa là tất cả các trường hợp thử nghiệm có thể có thể được bảo hiểm. Kiểm tra chỉ có thể được thực hiện với một vài trường hợp thử nghiệm được chọn và giả định rằng phần mềm sẽ tạo ra đầu ra phù hợp trong mọi trường hợp. Đưa phần mềm qua mọi trường hợp thử nghiệm sẽ tốn nhiều chi phí hơn, nỗ lực nhiều hơn, v.v., điều này làm cho nó không thực tế.The software cannot be tested exhaustively, which means all possible test cases cannot be covered. Testing can only be done with a select few test cases, and it's assumed that the software will produce the right output in all cases. Taking the software through every test case will cost more, take more effort, etc., which makes it impractical.
• Phân cụm khiếm khuyết: Phần lớn các khiếm khuyết thường được tìm thấy trong một số lượng nhỏ các mô -đun trong một dự án. Theo nguyên tắc Pareto, 80% lỗi phần mềm phát sinh từ 20% các mô -đun. The majority of defects are typically found in a small number of modules in a project. According to the Pareto Principle, 80% of software defects arise from 20% of modules.
• Nghịch lý thuốc trừ sâu: Không thể tìm thấy các lỗi mới bằng cách chạy lại các trường hợp thử nghiệm tương tự nhiều lần. Do đó, việc cập nhật hoặc thêm các trường hợp thử nghiệm mới là cần thiết để tìm lỗi mới.It is impossible to find new bugs by re-running the same test cases over and over again. Thus, updating or adding new test cases is necessary in order to find new bugs.
• Thử nghiệm sớm: Kiểm tra sớm là rất quan trọng để tìm lỗi trong phần mềm. Trong giai đoạn đầu của SDLC, các khiếm khuyết sẽ được phát hiện dễ dàng hơn và với chi phí thấp hơn. Kiểm tra phần mềm nên bắt đầu ở giai đoạn phát triển phần mềm ban đầu, đó là giai đoạn phân tích yêu cầu. Early testing is crucial to finding the defect in the software. In the early stages of SDLC, defects will be detected more easily and at a lower cost. Software testing should start at the initial phase of software development, which is the requirement analysis phase.
• Kiểm tra phụ thuộc vào ngữ cảnh: Phương pháp kiểm tra khác nhau tùy thuộc vào bối cảnh phát triển phần mềm. Phần mềm cần được kiểm tra khác nhau tùy thuộc vào loại của nó. Chẳng hạn, một trang web công nghệ ED được kiểm tra khác với ứng dụng Android.The testing approach varies depending on the software development context. Software needs to be tested differently depending on its type. For instance, an ed-tech site is tested differently than an Android app.

Định nghĩa từ điển về hồi quy là hành động quay trở lại vị trí hoặc trạng thái trước đó. Trong phần mềm, hồi quy ngụ ý rằng một tính năng được sử dụng để làm việc đột ngột ngừng hoạt động sau khi nhà phát triển thêm mã hoặc chức năng mới vào phần mềm.

Vấn đề hồi quy có sức lan tỏa trong ngành công nghiệp phần mềm, vì các tính năng mới luôn được thêm vào. Các nhà phát triển không xây dựng các tính năng này một cách cô lập, tách biệt với mã hiện có. Thay vào đó, mã mới tương tác với mã di sản và sửa đổi nó theo nhiều cách khác nhau, giới thiệu các tác dụng phụ, cho dù có dự định hay không.

Do đó, luôn có cơ hội giới thiệu những thay đổi mới có thể ảnh hưởng tiêu cực đến một tính năng làm việc. Điều quan trọng là phải nhớ rằng ngay cả một thay đổi nhỏ cũng có khả năng gây ra hồi quy.

Kiểm tra hồi quy giúp đảm bảo rằng mã hoặc sửa đổi mới cho mã hiện tại không phá vỡ hành vi hiện tại. Nó cho phép người kiểm tra xác minh rằng mã mới chơi tốt với mã di sản.

Hãy tưởng tượng một khách du lịch ở một thành phố nước ngoài. Có hai cách mà họ có thể khám phá thành phố.

• Thực hiện theo bản đồ, hành trình hoặc danh sách các địa điểm họ nên ghé thăm
• Khám phá ngẫu nhiên, đi theo đường phố khi họ dẫn họ đến những nơi mới

Với cách tiếp cận đầu tiên, khách du lịch tuân theo một kế hoạch được xác định trước và thực hiện nó. Mặc dù họ có thể đến thăm những điểm nổi tiếng, họ có thể bỏ lỡ những nơi ẩn giấu, thú vị hơn trong thành phố. Với cách tiếp cận thứ hai, khách du lịch lang thang khắp thành phố và có thể gặp phải những nơi kỳ lạ và kỳ lạ mà hành trình sẽ bỏ lỡ.

Cả hai cách tiếp cận đều có ưu và nhược điểm của họ.

Một người thử nghiệm tương tự như một khách du lịch khi họ đang thử nghiệm phần mềm. Họ có thể tuân theo một tập hợp nghiêm ngặt các trường hợp thử nghiệm và kiểm tra phần mềm theo chúng, với các đầu vào và đầu ra được cung cấp, hoặc họ có thể khám phá phần mềm.

Khi người kiểm tra không sử dụng các tập lệnh kiểm tra hoặc gói kiểm tra được xác định trước và kiểm tra ngẫu nhiên phần mềm, nó được gọi là thử nghiệm khám phá. Như tên cho thấy, người kiểm tra đang khám phá phần mềm như một người dùng cuối. Đó là một hình thức thử nghiệm hộp đen.

Trong thử nghiệm khám phá, người kiểm tra tương tác với phần mềm theo bất kỳ cách nào họ muốn và làm theo hướng dẫn của phần mềm để điều hướng các đường dẫn và chức năng khác nhau. Họ không có kế hoạch nghiêm ngặt trong tay.

Thử nghiệm khám phá chủ yếu tập trung vào thử nghiệm hành vi. Nó có hiệu quả để làm quen với các tính năng phần mềm mới. Nó cũng cung cấp một cái nhìn tổng quan cấp cao về hệ thống giúp đánh giá và nhanh chóng tìm hiểu phần mềm.

Mặc dù có vẻ như ngẫu nhiên, thử nghiệm khám phá có thể mạnh mẽ trong bàn tay của người thử nghiệm có kinh nghiệm và lành nghề. Vì nó được thực hiện mà không có bất kỳ quan niệm định sẵn nào về những gì phần mềm nên và không nên làm, nó cho phép người kiểm tra linh hoạt hơn để khám phá các đường dẫn và vấn đề ẩn dọc theo các đường dẫn đó.

Thử nghiệm kết thúc đến cuối là quá trình thử nghiệm một hệ thống phần mềm từ đầu đến cuối. Người kiểm tra kiểm tra phần mềm giống như người dùng cuối. Ví dụ: để kiểm tra phần mềm máy tính để bàn, người kiểm tra sẽ cài đặt phần mềm như người dùng, mở, sử dụng ứng dụng như dự định và xác minh hành vi. Tương tự cho một ứng dụng web.

Có một sự khác biệt quan trọng giữa thử nghiệm từ đầu đến cuối so với các hình thức thử nghiệm khác được cô lập nhiều hơn, chẳng hạn như thử nghiệm đơn vị. Trong thử nghiệm từ đầu đến cuối, phần mềm được kiểm tra cùng với tất cả các phụ thuộc và tích hợp của nó, chẳng hạn như cơ sở dữ liệu, mạng, hệ thống tệp và các dịch vụ bên ngoài khác.

Kiểm tra đơn vị là quá trình kiểm tra một đơn vị mã theo cách riêng biệt. Đơn vị mã có thể là một phương thức, một lớp hoặc một mô -đun. Kiểm tra đơn vị nhằm mục đích tập trung vào các khối mã xây dựng nhỏ nhất để có được sự tự tin để kết hợp chúng sau này để tạo ra phần mềm hoạt động đầy đủ.

Một bài kiểm tra đơn vị gọi mã và xác minh kết quả với kết quả dự kiến. Nếu kết quả mong đợi và thực tế phù hợp, thì bài kiểm tra đơn vị sẽ vượt qua. Nếu không, nó thất bại.

Một bài kiểm tra đơn vị tốt có các đặc điểm sau:

1. Nó nên kiểm tra một phần chức năng duy nhất.
2. Nó hoàn toàn tự động và lặp lại. & NBSP;
3. Nó nên chạy nhanh chóng và cung cấp phản hồi ngay lập tức.
4. Nó nên được cô lập và không nên tương tác với các phụ thuộc bên ngoài như mạng, cơ sở dữ liệu hoặc hệ thống tệp trừ khi cần thiết. Bạn có thể sử dụng kỹ thuật chế giễu để mô phỏng các phụ thuộc bên ngoài và cô lập mã được kiểm tra.

API là viết tắt của giao diện lập trình ứng dụng. Đó là một phương tiện giao tiếp giữa hai thành phần phần mềm. Một API trừu tượng hóa các hoạt động và độ phức tạp bên trong của chương trình phần mềm và cho phép người dùng API đó chỉ tập trung vào các đầu vào và đầu ra cần thiết để sử dụng nó. & NBSP;

Khi xây dựng phần mềm, các nhà phát triển hiếm khi viết phần mềm từ đầu và sử dụng các thư viện bên thứ ba khác. API cho phép hai thành phần phần mềm nói chuyện với nhau bằng cách cung cấp một giao diện mà họ có thể hiểu.

Một cách sử dụng API khác là cung cấp dữ liệu theo yêu cầu của một ứng dụng. Giả sử bạn đang xây dựng một ứng dụng thời tiết hiển thị nhiệt độ. Thay vì xây dựng công nghệ để tự thu thập nhiệt độ, bạn sẽ truy cập API được cung cấp bởi Viện Khí tượng.

Môi trường thử nghiệm bao gồm một máy chủ/máy tính mà người kiểm tra chạy thử nghiệm của họ. Nó khác với một máy phát triển và cố gắng thể hiện phần cứng thực tế mà phần mềm sẽ chạy; Một khi nó trong sản xuất.

Bất cứ khi nào một bản dựng mới của phần mềm được phát hành, người kiểm tra sẽ cập nhật môi trường thử nghiệm với bản dựng mới nhất và chạy bộ kiểm tra hồi quy. Khi nó đi qua, người kiểm tra chuyển sang thử nghiệm chức năng mới. & NBSP;

Khi phần mềm đang được kiểm tra, phạm vi bảo hiểm mã đo lường số lượng mã nguồn của chương trình được bao phủ bởi kế hoạch kiểm tra. Kiểm tra bảo hiểm mã chạy song song với thử nghiệm sản phẩm thực tế. Sử dụng công cụ bảo hiểm mã, bạn có thể theo dõi việc thực thi các câu lệnh trong mã nguồn của mình. Một báo cáo đầy đủ về các tuyên bố đang chờ xử lý, cùng với tỷ lệ phần trăm bảo hiểm, được cung cấp vào cuối thử nghiệm cuối cùng.

Trong số các loại kỹ thuật bảo hiểm thử nghiệm khác nhau là:

• Tuyên bố/phạm vi bảo hiểm khối: Các biện pháp có bao nhiêu câu trong mã nguồn đã được thực hiện và kiểm tra thành công. Measures how many statements in the source code have been successfully executed and tested.
• Quyết định/phạm vi bảo hiểm chi nhánh: Số liệu này đo lường số lượng cấu trúc kiểm soát quyết định đã được thực hiện và thử nghiệm thành công. This metric measures how many decision control structures were successfully executed and tested.
• Phạm vi bảo hiểm đường dẫn: Điều này đảm bảo rằng các thử nghiệm được thực hiện trên mọi tuyến có thể thông qua một phần của mã.This ensures that the tests are conducted on every possible route through a section of the code.
• Phạm vi bảo hiểm chức năng: Nó đo lường có bao nhiêu chức năng trong mã nguồn đã được thực thi và kiểm tra ít nhất một lần.It measures how many functions in the source code have been executed and tested at least once.

• Kiểm tra hộp đen trong thử nghiệm phần mềm: Trong thử nghiệm hộp đen, hệ thống chỉ được kiểm tra theo hành vi bên ngoài của nó; Nó không xem xét làm thế nào các chức năng phần mềm ở bên trong. Đây là giới hạn duy nhất của thử nghiệm hộp đen. Nó được sử dụng trong thử nghiệm chấp nhận và kiểm tra hệ thống.: In black-box testing, the system is tested only in terms of its external behaviour; it does not consider how the software functions on the inside. This is the only limitation of the black-box test. It is used in Acceptance Testing and System Testing.
• Thử nghiệm hộp trắng trong thử nghiệm phần mềm: Thử nghiệm hộp trắng là phương pháp kiểm tra chương trình có tính đến hoạt động nội bộ của nó như là một phần của đánh giá. Nó được sử dụng trong thử nghiệm tích hợp và thử nghiệm đơn vị. A white-box test is a method of testing a program that takes into account its internal workings as part of its review. It is used in integration testing and unit testing.
• Kiểm tra hộp màu xám trong thử nghiệm phần mềm: Kỹ thuật thử nghiệm hộp màu xám có thể được đặc trưng như sự kết hợp của hộp đen cũng như kỹ thuật thử nghiệm hộp màu trắng được sử dụng trong quy trình thử nghiệm phần mềm. Sử dụng kỹ thuật này, bạn có thể kiểm tra một sản phẩm phần mềm hoặc ứng dụng với sự hiểu biết một phần về cấu trúc bên trong của nó. A Gray Box Testing technique can be characterized as a combination of a black box as well as a white box testing technique used in the software testing process. Using this technique, you can test a software product or application with a partial understanding of its internal structure.

Việc sử dụng thử nghiệm tự động hóa là cực kỳ có lợi khi sử dụng mô hình Agile trong thử nghiệm phần mềm. Nó giúp đạt được phạm vi kiểm tra tối đa trong thời gian nhỏ hơn của Sprint.

• Trường hợp kiểm tra: Các trường hợp kiểm tra là một loạt các hành động được thực hiện trong quá trình phát triển phần mềm để xác minh một tính năng hoặc chức năng cụ thể. Một trường hợp thử nghiệm bao gồm các bước kiểm tra, dữ liệu kiểm tra, điều kiện tiên quyết và các điều kiện hậu được thiết kế để xác minh một yêu cầu cụ thể.Test Cases are a series of actions executed during software development to verify a particular feature or function. A test case consists of test steps, test data, preconditions, and postconditions designed to verify a specific requirement.
• Kịch bản kiểm tra: Thông thường, kịch bản thử nghiệm bao gồm một tập hợp các trường hợp thử nghiệm bao gồm chức năng từ đầu đến cuối của ứng dụng phần mềm. Một kịch bản thử nghiệm cung cấp một cái nhìn tổng quan cấp cao về những gì cần được kiểm tra. Usually, a test scenario consists of a set of test cases covering the end-to-end functionality of a software application. A test scenario provides a high-level overview of what needs to be tested.
• Các tập lệnh kiểm tra: Khi nói đến thử nghiệm phần mềm, tập lệnh kiểm tra đề cập đến tập hợp các hướng dẫn sẽ được tuân thủ để xác minh rằng hệ thống đang được thử nghiệm thực hiện như mong đợi. Tài liệu phác thảo từng bước được thực hiện và kết quả dự kiến. & NBSP;When it comes to software testing, a test script refers to the set of instructions that will be followed in order to verify that the system under test performs as expected. The document outlines each step to be taken and the expected results. 

Một lỗi phần mềm là một lỗi trong phần mềm tạo ra kết quả sai. Một thử nghiệm phần mềm kiểm tra phần mềm để tìm lỗi trong đó.

Ví dụ, có nhiều nguyên nhân gây ra lỗi, thiết kế kém, lập trình cẩu thả, thiếu kiểm soát phiên bản hoặc truyền thông sai. Trong suốt quá trình phát triển, các nhà phát triển giới thiệu hàng trăm hoặc hàng ngàn lỗi trong hệ thống. Mục tiêu của người kiểm tra là khám phá những lỗi đó.

Bạn có thể tìm thấy một lỗi theo nhiều cách khác nhau, bất kể vai trò của bạn. Khi xây dựng phần mềm, nhà phát triển phần mềm có thể nhận thấy lỗi trong một mô -đun khác, được viết bởi một nhà phát triển khác hoặc một mình. Người kiểm tra tích cực cố gắng tìm các lỗi như là một phần của quá trình thử nghiệm thường xuyên. Cuối cùng, người dùng có thể thấy các lỗi khi phần mềm đang được sản xuất.

Tất cả các lỗi, bất kể chúng được tìm thấy như thế nào, được ghi lại vào một hệ thống theo dõi lỗi. Một nhóm Triage tria các lỗi và chỉ định mức độ ưu tiên cho lỗi và gán lỗi cho nhà phát triển phần mềm để sửa nó. Khi nhà phát triển giải quyết vấn đề, họ kiểm tra mã và đánh dấu lỗi đó là sẵn sàng để thử nghiệm. Khi một lỗi đã sẵn sàng để thử nghiệm, nó sẽ đến người kiểm tra, người kiểm tra phần mềm để xác minh xem nó có thực sự được sửa. Nếu có, thì nó đã đóng cửa. Nếu không, họ gán nó cho cùng một nhà phát triển với một mô tả về các bước chính xác để tái tạo lỗi. Một số ví dụ về các hệ thống theo dõi lỗi phổ biến bao gồm Bugzilla, Fogbugz, v.v.

Trivia:

Lỗi phần mềm đầu tiên được phát hiện bởi Đô đốc Grace Hopper, vào ngày 9 tháng 9 năm 1947. Sau khi họ mở một phần cứng bị trục trặc, họ đã tìm thấy một con côn trùng bị mắc kẹt trong rơle. Nguồn hình ảnh: Liên kết

Lỗi và lỗi khác nhau theo các cách sau:

Một kế hoạch kiểm tra về cơ bản là một tài liệu động được giám sát và kiểm soát bởi người quản lý thử nghiệm. Thành công của một dự án thử nghiệm hoàn toàn phụ thuộc vào một tài liệu kế hoạch thử nghiệm được viết tốt mô tả phạm vi và hoạt động thử nghiệm phần mềm. Về cơ bản, nó phục vụ như một kế hoạch chi tiết phác thảo những gì, khi nào, làm thế nào và nhiều hơn toàn bộ quá trình kiểm tra. & Nbsp;

Một kế hoạch kiểm tra phải bao gồm các chi tiết sau: & NBSP;

• Chiến lược kiểm tra & NBSP;
• Kiểm tra mục tiêu & nbsp;
• Phạm vi kiểm tra & NBSP;
• Lý do kiểm tra & nbsp;
• Tiêu chí thoát/hệ thống treo & NBSP;
• Lập kế hoạch tài nguyên & NBSP;
• KIỂM TRA KIỂM TRA. & NBSP;

Báo cáo kiểm tra về cơ bản là một tài liệu bao gồm tổng số tóm tắt các mục tiêu, hoạt động và kết quả kiểm tra. Nó rất cần thiết để phản ánh kết quả kiểm tra và tạo cơ hội để ước tính kết quả kiểm tra một cách nhanh chóng. Nó giúp chúng tôi quyết định xem sản phẩm có sẵn sàng phát hành hay không. Nó cũng giúp chúng tôi xác định tình trạng hiện tại của dự án và chất lượng của sản phẩm. Một báo cáo thử nghiệm phải bao gồm các chi tiết sau: & NBSP;

• Kiểm tra mục tiêu & nbsp;
• Phạm vi kiểm tra & NBSP;
• Defect 
• Tóm tắt kiểm tra

Các sản phẩm kiểm tra, còn được gọi là các tạo tác thử nghiệm, về cơ bản là một danh sách tất cả các tài liệu, công cụ và các thành phần khác được trao cho các bên liên quan của một dự án phần mềm trong SDLC. Việc cung cấp thử nghiệm được duy trì và phát triển để hỗ trợ thử nghiệm. Ở mọi giai đoạn của SDLC, có các sản phẩm khác nhau như được đưa ra dưới đây:

Trước khi thử nghiệm giai đoạn & NBSP; 

• Tài liệu Kế hoạch kiểm tra. & NBSP;
• Các trường hợp kiểm tra Tài liệu & NBSP;
• Thông số kỹ thuật thiết kế thử nghiệm.

Trong giai đoạn thử nghiệm & NBSP; 

• KIỂM TRA KIỂM TRA & NBSP;
• Simulators. 
• Kiểm tra dữ liệu & nbsp;
• Kiểm tra Ma trận truy xuất truy xuất & NBSP;
• Nhật ký lỗi và nhật ký thực thi

Sau khi thử nghiệm giai đoạn & NBSP; 

• Kết quả kiểm tra/báo cáo & nbsp;
• Báo cáo lỗi & NBSP;
• Hướng dẫn cài đặt/ Thử nghiệm Nguyên tắc & NBSP;
• Phát hành ghi chú & nbsp;

Các loại gỡ lỗi khác nhau bao gồm: & nbsp;

• Lực lượng Brute gỡ lỗi & nbsp;
• Backtracking 
• Gây ra loại bỏ & nbsp;
• Chương trình cắt & NBSP;
• Phân tích cây lỗi & nbsp;

Một số sai lầm phổ biến bao gồm: & nbsp;

• Lập kế hoạch kém & NBSP;
• Đánh giá thấp & nbsp;
• Bỏ qua các vấn đề nhỏ & nbsp;
• Không tuân theo quy trình chính xác & nbsp;
• Phân bổ tài nguyên không phù hợp & NBSP;

Tất cả phần mềm có người dùng mục tiêu. Một câu chuyện người dùng mô tả các động lực của người dùng và những gì họ đang cố gắng thực hiện bằng cách sử dụng phần mềm. Cuối cùng, nó cho thấy cách người dùng sử dụng ứng dụng. Nó bỏ qua các chi tiết thiết kế và thực hiện.

Một câu chuyện người dùng nhằm tập trung vào giá trị được cung cấp cho người dùng cuối thay vì các đầu vào chính xác mà họ có thể nhập và đầu ra dự kiến.

Trong một câu chuyện người dùng, người kiểm tra tạo ra người dùng với tên và đặc điểm của người dùng và cố gắng mô phỏng tương tác ngoài đời thực với phần mềm. Một câu chuyện người dùng thường giúp câu cá ra các vấn đề ẩn thường không được tiết lộ bởi các quá trình thử nghiệm chính thức hơn.

1. Selenium: Một công cụ tự động hóa trình duyệt web tự động hóa các bộ thử nghiệm bạn cần chạy trên trình duyệt web.
2. Protractor: Khung thử nghiệm từ đầu đến cuối cho các ứng dụng Angular và AngularJS. Protractor chạy các bài kiểm tra đối với ứng dụng của bạn đang chạy trong trình duyệt thực, tương tác với nó như một người dùng.
3. Cypress: Một công cụ thử nghiệm mặt trước hiện đại được xây dựng cho web hiện đại. Mặc dù nó tương tự như selen và thước đo góc, nhưng nó khác nhau về mặt kiến ​​trúc với chúng.
4. Jasmine: Đây là một khung thử nghiệm JavaScript nguồn mở cho phép bạn viết các bài kiểm tra hướng đến hành vi.
5. Junit và Nunit: Đây là các khung thử nghiệm đơn vị cho các ngôn ngữ lập trình Java và C#, tương ứng.

Kiểm tra A/B là quá trình kiểm tra hai hoặc nhiều phiên bản khác nhau của phần mềm với người dùng để đánh giá hoạt động tốt hơn. Đó là một cách có nguy cơ thấp để kiểm tra các biến thể của một chức năng mới hoặc hiện có.

Bạn có thể chọn một phần người dùng của mình để sử dụng tính năng A. Nhóm khác sử dụng tính năng B. Sau đó, phản hồi và phản hồi của người dùng được đánh giá bằng cách sử dụng kiểm tra thống kê để quyết định phiên bản cuối cùng của tính năng. & NBSP;

Thông thường, thử nghiệm A/B được sử dụng để kiểm tra trải nghiệm người dùng về các giao diện khác nhau. Điều này cho phép nhóm nhanh chóng thu thập phản hồi và kiểm tra giả thuyết ban đầu của họ.

Thuật ngữ khiếm khuyết đề cập đến một lỗi hệ thống ngăn chặn hành động dự định được hoàn thành. Thử nghiệm là quan trọng nhất khi nói đến việc tìm kiếm khiếm khuyết. Thử nghiệm cần bắt đầu sớm trong quá trình phát triển vì các khiếm khuyết có thể được tìm thấy trong suốt. Như được hiển thị trong hình sau, các khiếm khuyết được chia thành ba loại chính:

• SAU: Nó ngụ ý thực hiện không chính xác các yêu cầu. Có một phương sai giữa các thông số kỹ thuật và những gì được mong đợi, dẫn đến khiếm khuyết này. It implies incorrect implementation of requirements. There is a variance between the specifications and what was expected, resulting in this defect.
• Thiếu: Điều này chỉ ra rằng một đặc điểm kỹ thuật chưa được thực hiện hoặc yêu cầu của khách hàng chưa được ghi nhận đúng. This indicates that a specification has not been implemented, or a requirement of the customer has not been properly noted.
• Thêm: Trong trường hợp này, khiếm khuyết được gây ra bởi một yêu cầu được kết hợp vào sản phẩm không được cung cấp bởi người dùng cuối. & NBSP;In this case, the defect is caused by a requirement incorporated into the product that was not provided by the end-user. 

Spice là viết tắt của cải tiến quy trình phần mềm và xác định khả năng. Trong lĩnh vực quy trình phát triển phần mềm, Spice là một khung tiêu chuẩn để đánh giá hiệu quả và hiệu quả của quá trình phát triển. IEC (Ủy ban điện tử quốc tế) và ISO (Tổ chức tiêu chuẩn hóa quốc tế) cùng phát triển gia vị.

• Khiếm khuyết tiềm ẩn: Khiếm khuyết tiềm ẩn là những khiếm khuyết tồn tại nhưng chưa được viện dẫn vì các điều kiện cần thiết để gọi chúng chưa được đáp ứng. Là một lỗ hổng có hệ thống, nó bao gồm toàn bộ quá trình sản xuất của phần mềm, bao gồm tất cả các thử nghiệm tiền sản xuất và thử nghiệm mở rộng. Khi người dùng thực hiện một nhiệm vụ cụ thể trong một tình huống bất thường hoặc hiếm gặp hoặc không có sự hiện diện của các kịch bản thông thường, các khiếm khuyết tiềm ẩn sẽ được tiết lộ.Latent defects are defects that exist but have not yet been invoked because the conditions required to invoke them have not been met. As a systematic flaw, it encompasses the entire production process of the software, including all pre-production testing and extended testing. When users perform a particular task in an unusual or rare situation or without the presence of usual scenarios, latent defects are revealed.
• Khiếm khuyết đeo mặt nạ: Đây là những khiếm khuyết chưa dẫn đến thất bại vì một khiếm khuyết khác che giấu phần mã đó khỏi bị thực thi. Nó chỉ có thể được phát hiện khi lỗi che giấu nó được người dùng tiếp xúc thông qua một hoạt động cụ thể. Có những khiếm khuyết được ẩn hoặc được đánh dấu bởi một khiếm khuyết khác và vẫn ẩn cho đến khi phát hiện lỗi khác. These are the defects that have not yet resulted in a failure since another defect hides that portion of the code from being executed. It can only be discovered when the defect hiding it is exposed by the user through a specific operation. There are defects that are hidden or marked by another defect and remain hidden until the other defect is detected.

Thuật ngữ 'Thử nghiệm tỉnh táo' đề cập đến một tập hợp con của kiểm tra hồi quy. Việc kiểm tra tỉnh táo đảm bảo rằng các thay đổi được thực hiện đối với mã không ảnh hưởng xấu đến hiệu suất của hệ thống. Sau khi nhận được bản dựng phần mềm, một thử nghiệm tỉnh táo được thực hiện để đảm bảo rằng các thay đổi được thực hiện đối với mã đang hoạt động chính xác. Là một điểm kiểm tra, thử nghiệm này được sử dụng để xác định xem bản dựng có thể tiến hành thử nghiệm thêm hay không. Kiểm tra Sanity tập trung vào việc xác nhận chức năng của ứng dụng thay vì thử nghiệm chi tiết.

Đặc trưng

• Nó tập trung vào một phần nhỏ hơn của ứng dụng và là một tập hợp con của thử nghiệm hồi quy.
• Quá trình là không có giấy tờ.
• Kiểm tra tỉnh táo thường không được ghi lại.
• Trong phương pháp này, các chức năng hạn chế được kiểm tra sâu.
• Một người thử nghiệm thường chịu trách nhiệm thực hiện nhiệm vụ này.

Khung Testng cho Java là một khung tự động hóa thử nghiệm nâng cao nguồn mở được thiết kế để mang lại lợi ích cho cả người thử nghiệm và nhà phát triển. Mục đích của Testng là cung cấp một môi trường dễ sử dụng, dễ đọc, có cấu trúc, có thể bảo trì và thân thiện với người dùng cho các thử nghiệm tự động. Ng là viết tắt của 'Thế hệ tiếp theo' trong Testng. Các chú thích cao cấp, chẳng hạn như các nhà cung cấp dữ liệu, giúp kiểm tra trình duyệt chéo dễ dàng hơn vì bạn có thể kiểm tra trên nhiều thiết bị và trình duyệt. Hơn nữa, khung có một cơ chế sẵn có để xử lý các ngoại lệ ngăn chặn chương trình chấm dứt bất ngờ.

Có, bạn có thể bỏ qua một phương thức kiểm tra hoặc mã cụ thể bằng cách đặt tham số 'đã bật' thành ‘sai trong các chú thích thử nghiệm.

@Test (bật = false).

Ưu tiên thứ tự của các phương pháp kiểm tra của bạn có thể được thực hiện bằng cách xác định thứ tự ưu tiên. Do đó, bài kiểm tra sẽ thực thi theo bộ ưu tiên.

Cú pháp: @Test(priority=2)

Ví dụ: Mã sau đây trình bày cách đặt mức độ ưu tiên của trường hợp kiểm tra trong testng.

package TestNG;
import org.testng.annotations.*;
public class SettingPriority {
@Test(priority=0)
public void scalermethod1() {
}
@Test(priority=1)
public void scalermethod2() {
}
@Test(priority=2)
public void scalermethod3() {
}
}

Trình tự thực thi kiểm tra:

ScalerMethod1
ScalerMethod2
ScalerMethod3

Kho lưu trữ đối tượng là một tập hợp các yếu tố web và trình định vị của chúng thuộc về ứng dụng đang được kiểm tra (AUT). QAs duy trì tất cả các trình định vị phần tử trong một tệp riêng biệt được gọi là tệp thuộc tính (. Thuộc tính) trong selen. Trong quá trình thực thi, nó đóng vai trò là phương tiện xác định các đối tượng giữa tập lệnh kiểm tra và ứng dụng.

Các bước sau đây có thể hỗ trợ giải quyết các vấn đề trong quá trình thử nghiệm:

• Ghi lại: Theo dõi bất kỳ vấn đề nào phát sinh và giải quyết chúng.
• Báo cáo: Thông báo cho các nhà quản lý cấp cao hơn về các vấn đề.
• Kiểm soát: Thiết lập một quy trình để quản lý các vấn đề.

Bất kỳ mục tiêu của người kiểm tra phần mềm nào là tìm hiểu càng nhiều lỗi và vấn đề trong hệ thống để khách hàng không phải làm. Do đó, một người kiểm tra phần mềm tốt nên có một con mắt sắc sảo để biết chi tiết. Họ nên biết các phần mềm mà họ đang thử nghiệm và đẩy mọi khía cạnh của phần mềm đến giới hạn của nó, để xác định các lỗi khó tìm thấy sử dụng thường xuyên của phần mềm.

Có kiến ​​thức miền của ứng dụng là rất cần thiết. Nếu người kiểm tra không hiểu các vấn đề cụ thể mà phần mềm đang cố gắng giải quyết, họ sẽ không thể kiểm tra kỹ lưỡng.

Một người thử nghiệm tốt nên ghi nhớ người dùng cuối khi họ đang thử nghiệm. Có sự đồng cảm với người dùng cuối giúp người kiểm tra đảm bảo rằng phần mềm có thể truy cập và có thể sử dụng được. Đồng thời, người kiểm tra nên sở hữu các kỹ năng lập trình cơ bản để suy nghĩ từ quan điểm của nhà phát triển, cho phép họ nhận thấy các lỗi lập trình phổ biến như tham khảo null, lỗi ngoài bộ nhớ, v.v.

Giao tiếp, cả bằng văn bản và bằng lời nói, là một kỹ năng thiết yếu cho người thử nghiệm. Người thử nghiệm sẽ thường xuyên phải tương tác với cả nhà phát triển và quản lý. Họ sẽ có thể giải thích các lỗi và vấn đề được tìm thấy trong quá trình thử nghiệm cho các nhà phát triển. Đối với mỗi lỗi được tìm thấy, một người kiểm tra tốt sẽ cung cấp một báo cáo lỗi chi tiết bao gồm tất cả các thông tin mà một nhà phát triển sẽ cần để khắc phục vấn đề đó. Họ sẽ có thể đưa ra một trường hợp tốt cho quản lý nếu họ không thoải mái phát hành phần mềm nếu nó chứa các vấn đề chưa được giải quyết.

BVA (Phân tích giá trị biên) là một kỹ thuật kiểm tra phần mềm hộp đen sử dụng các giá trị biên để tạo các trường hợp thử nghiệm. Các giá trị đầu vào gần ranh giới có xác suất lỗi cao hơn, do đó BVA được sử dụng để kiểm tra các giá trị biên. BVA bao gồm các giá trị tại các ranh giới trong các trường hợp thử nghiệm. Nếu đầu vào nằm trong phạm vi ranh giới, thì thử nghiệm là dương; Nếu nó rơi ra bên ngoài, thì nó là tiêu cực. Có một số loại giá trị, bao gồm tối đa hoặc tối thiểu, cạnh bên trong hoặc bên ngoài và các giá trị điển hình hoặc lỗi.

Kiểm tra phần mềm đi vào hoạt động vào các thời điểm khác nhau trong các phương pháp phát triển phần mềm khác nhau. Có hai phương pháp chính trong phát triển phần mềm, cụ thể là thác nước và nhanh nhẹn.

Trong một mô hình phát triển phần mềm thác nước truyền thống, các yêu cầu được thu thập trước. Sau đó, một tài liệu đặc tả được tạo dựa trên tài liệu, điều khiển thiết kế và phát triển phần mềm. Cuối cùng, những người thử nghiệm tiến hành thử nghiệm vào cuối vòng đời phát triển phần mềm một khi hệ thống phần mềm hoàn chỉnh được xây dựng.

Một mô hình phát triển phần mềm Agile hoạt động trong các lần lặp nhỏ. Bạn kiểm tra phần mềm song song vì nó đang được xây dựng. Các nhà phát triển xây dựng một chức năng nhỏ theo các yêu cầu. Người thử nghiệm kiểm tra nó và nhận phản hồi của khách hàng, điều này thúc đẩy sự phát triển trong tương lai. & NBSP;

Không thể kiểm tra kỹ lưỡng phần mềm hoặc chứng minh sự vắng mặt của các lỗi, bất kể chiến lược kiểm tra của bạn cụ thể như thế nào.

Một thử nghiệm sâu rộng tìm thấy hàng trăm lỗi không có nghĩa là nó đã phát hiện ra tất cả. Có thể có nhiều lỗi nữa mà bài kiểm tra có thể đã bỏ lỡ. Việc không có lỗi không có nghĩa là không có lỗi và phần mềm là hoàn hảo. Nó có thể dễ dàng có nghĩa là các bài kiểm tra không hiệu quả hoặc không đầy đủ. Để chứng minh rằng một chương trình hoạt động, bạn phải kiểm tra tất cả các đầu vào có thể và các kết hợp của chúng.

Hãy xem xét một chương trình đơn giản lấy một chuỗi làm đầu vào dài mười ký tự. Để kiểm tra nó với từng đầu vào có thể, bạn phải nhập 2610 tên, điều này là không thể. Vì thử nghiệm toàn diện là không thực tế, chiến lược tốt nhất của bạn với tư cách là người thử nghiệm là chọn các trường hợp thử nghiệm có khả năng tìm thấy lỗi nhất. Kiểm tra là đủ khi bạn có đủ sự tự tin để phát hành phần mềm và cho rằng nó sẽ hoạt động như mong đợi.

Các nhà phát triển làm cho người thử nghiệm kém. Dưới đây là một số lý do tại sao:

• Họ cố gắng kiểm tra mã để đảm bảo rằng nó hoạt động, thay vì kiểm tra tất cả các cách mà nó không hoạt động. & NBSP;
• Vì họ đã tự viết nó, các nhà phát triển có xu hướng rất lạc quan về phần mềm và không có thái độ chính xác cần thiết để thử nghiệm: để phá vỡ phần mềm. & NBSP;
• Các nhà phát triển bỏ qua các thử nghiệm tinh vi hơn mà một người thử nghiệm có kinh nghiệm sẽ thực hiện để phá vỡ phần mềm. Họ đi theo con đường hạnh phúc để thực thi mã từ đầu đến cuối với các đầu vào thích hợp, thường không đủ để có được sự tự tin để vận chuyển phần mềm trong sản xuất.

Tuy nhiên, điều đó không có nghĩa là các nhà phát triển không nên kiểm tra phần mềm trước khi gửi cho người thử nghiệm. Kiểm tra nhà phát triển giúp tìm ra nhiều lỗi do lỗi lập trình. Chúng rất khó tìm cho người thử nghiệm vì chúng không phải lúc nào cũng có quyền truy cập vào mã nguồn.

Nói tóm lại, SDLC (vòng đời phát triển phần mềm) cho phép phát triển phần mềm chất lượng cao, chi phí thấp với thời gian phát triển ngắn nhất có thể. Mục tiêu chính của SDLC là sản xuất phần mềm chất lượng cao đáp ứng và vượt quá mong đợi của khách hàng. SDLC cung cấp một kế hoạch chi tiết với một loạt các giai đoạn hoặc giai đoạn, bao gồm các quy trình và sản phẩm của riêng họ. Bằng cách tuân thủ SDLC, các nhà phát triển có thể nâng cao tốc độ của các dự án của họ và giảm thiểu rủi ro và chi phí.

Tương tự như phát triển phần mềm, thử nghiệm có vòng đời của nó. Trong quá trình thử nghiệm, một người thử nghiệm trải qua các hoạt động sau. & nbsp;

1. Hiểu các yêu cầu: Trước khi thử nghiệm phần mềm hoặc tính năng, trước tiên người kiểm tra phải hiểu những gì nó phải làm. Nếu họ không biết phần mềm được cho là hoạt động như thế nào, họ có thể kiểm tra nó một cách hiệu quả. & NBSP; Before testing software or a feature, the tester must first understand what it is supposed to do. If they don’t know how the software is supposed to work, they can’t test it effectively. 
2. Lập kế hoạch kiểm tra và phát triển trường hợp: Một khi người kiểm tra có hiểu biết rõ về các yêu cầu, họ có thể tạo ra một kế hoạch kiểm tra. Nó bao gồm phạm vi thử nghiệm, tức là, một phần của phần mềm đang được kiểm tra và mục tiêu để kiểm tra. Các hoạt động khác nhau tham gia vào việc lập kế hoạch thử nghiệm, chẳng hạn như tạo tài liệu, ước tính thời gian và nỗ lực liên quan, quyết định các công cụ và nền tảng và các cá nhân sẽ thực hiện các thử nghiệm. Once the tester has a clear understanding of the requirements, they can create a test plan. It includes the scope of testing, i.e., part of software under test and objectives for testing. Various activities are involved in planning the test, such as creating documentation, estimating the time and efforts involved, deciding the tools and platforms, and the individuals who will be conducting the tests.
3. Chuẩn bị môi trường thử nghiệm: Sự phát triển xảy ra trong môi trường phát triển, tức là trên máy tính của nhà phát triển có thể không đại diện cho môi trường thực tế mà phần mềm sẽ chạy trong sản xuất. Một người thử nghiệm chuẩn bị một môi trường với dữ liệu thử nghiệm bắt chước môi trường người dùng cuối. Nó hỗ trợ kiểm tra thực tế phần mềm. & NBSP; The development happens in a development environment, i.e., on a developer’s computer that might not represent the actual environment that the software will run in production. A tester prepares an environment with the test data that mimics the end user’s environment. It assists with realistic testing of the software. 
4. Tạo dữ liệu thử nghiệm: Mặc dù không thể kiểm tra toàn bộ phần mềm, người thử nghiệm cố gắng sử dụng dữ liệu thử nghiệm thực tế để cung cấp cho họ sự tự tin rằng phần mềm sẽ tồn tại trong thế giới thực nếu vượt qua các bài kiểm tra. & NBSP; Though it is impossible to do exhaustive testing of the software, the tester tries to use realistic test data to give them the confidence that the software will survive the real world if it passes the tests. 
5. Thực thi thử nghiệm: Khi người kiểm tra có sự hiểu biết đầy đủ về phần mềm và có môi trường thử nghiệm được thiết lập với dữ liệu thử nghiệm, họ thực hiện thử nghiệm. Ở đây, thực thi có nghĩa là người kiểm tra chạy phần mềm hoặc tính năng đang được kiểm tra và xác minh đầu ra với kết quả mong đợi. & NBSP; Once the tester has a complete understanding of the software and has a test environment set up with the test data, they execute the test. Here, execution means that the tester runs the software or the feature under test and verifies the output with the expected outcome. 
6. Đóng thử nghiệm: Vào cuối quá trình thực hiện thử nghiệm, có thể có hai kết quả có thể xảy ra. Đầu tiên, người kiểm tra tìm thấy một lỗi trong một phần của phần mềm được kiểm tra. Trong trường hợp này, họ tạo một bản ghi thử nghiệm/báo cáo lỗi. Thứ hai, phần mềm hoạt động như mong đợi. Cả hai sự kiện này cho thấy sự kết thúc của chu kỳ thử nghiệm. & NBSP; At the end of the test execution, there can be two possible outcomes. First, the tester finds a bug in the part of the software under test. In this case, they create a test record/bug report. Second, the software works as expected. Both these events indicate the end of the test cycle. 

Kiểm tra chức năng là một hình thức kiểm tra hộp đen. Như tên cho thấy, nó tập trung vào các yêu cầu chức năng của phần mềm thay vì thực hiện nội bộ. Một yêu cầu chức năng đề cập đến hành vi cần thiết trong hệ thống, về đầu vào và đầu ra của nó. is a form of black-box testing. As the name suggests, it focuses on the software's functional requirements rather than its internal implementation. A functional requirement refers to required behavior in the system, in terms of its input and output.

Nó xác nhận phần mềm dựa trên các yêu cầu chức năng hoặc đặc điểm kỹ thuật, bỏ qua các thuộc tính phi chức năng như hiệu suất, khả năng sử dụng và độ tin cậy.

Kiểm tra chức năng nhằm mục đích trả lời các câu hỏi sau, đặc biệt:

• Phần mềm có đáp ứng các yêu cầu chức năng của nó không?
• Nó có giải quyết vấn đề của người dùng dự định của nó không?

Kiểm tra phi chức năng kiểm tra các yêu cầu phi chức năng của hệ thống, đề cập đến một thuộc tính hoặc chất lượng của hệ thống được khách hàng yêu cầu rõ ràng. Chúng bao gồm hiệu suất, bảo mật, khả năng mở rộng và khả năng sử dụng.

Thử nghiệm phi chức năng đến sau khi thử nghiệm chức năng. Nó kiểm tra các đặc điểm chung không liên quan đến các yêu cầu chức năng của phần mềm. Kiểm tra phi chức năng đảm bảo rằng phần mềm được bảo mật, có thể mở rộng, hiệu suất cao và sẽ không bị sập dưới tải nặng. & NBSP;

Trong quá trình thử nghiệm, một người kiểm tra ghi lại các quan sát, phát hiện và thông tin khác của họ hữu ích cho các nhà phát triển hoặc quản lý. Tất cả dữ liệu này thuộc về một bản ghi thử nghiệm, còn được gọi là báo cáo lỗi.

Một báo cáo lỗi chi tiết là một tạo tác quan trọng được sản xuất trong quá trình thử nghiệm. Nó giúp các thành viên trong nhóm:

• Hiểu vấn đề,
• Các bước để tái tạo vấn đề,
• Môi trường và các điều kiện cụ thể mà nó xảy ra, và
• Độ phân giải nếu/khi các nhà phát triển khắc phục sự cố.

Dưới đây là một vài thông tin mà một báo cáo lỗi tốt nên chứa. Nguồn hình ảnh: Bugzilla

Ví dụ, đây là hình ảnh của một lỗi được báo cáo trên JIRA, một phần mềm theo dõi lỗi phổ biến. & NBSP;

Các số liệu thử nghiệm cung cấp một cái nhìn tổng quan cấp cao cho ban quản lý hoặc các nhà phát triển về cách dự án đang diễn ra và các bước hành động tiếp theo. & NBSP;

Dưới đây là một số số liệu có nguồn gốc từ một bản ghi của các bài kiểm tra và thất bại:

• Tổng số lỗi được tìm thấy, được đặt hàng bởi mức độ nghiêm trọng của chúng
• Tổng số lỗi đã cố định
• Tổng số vấn đề gây ra bởi một lỗi trong mã nguồn so với cấu hình hoặc các yếu tố môi trường bên ngoài
• Lỗi tìm thấy và sửa lỗi theo thời gian
• Lỗi bởi khu vực sản xuất/tính năng
• Thời gian trung bình được thực hiện bởi một lỗi vì nó đã tìm thấy và cố định. & NBSP;
• Tổng thời gian dành cho phát triển tính năng mới so với thời gian giải quyết các lỗi và thất bại
• Số lượng lỗi chưa thanh toán trước khi phát hành
• Lỗi/thất bại được báo cáo bởi khách hàng so với những người được tìm thấy bởi những người kiểm tra

Phát triển theo hướng thử nghiệm (TDD) là một kỹ thuật phát triển phần mềm phổ biến, được Kent Beck giới thiệu lần đầu tiên trong cuốn sách của ông với cùng tên, xuất bản năm 1999.

Trong TDD, một nhà phát triển làm việc trên một tính năng đầu tiên viết một bài kiểm tra thất bại, sau đó viết đủ mã để thực hiện bài kiểm tra đó. Khi họ có một bài kiểm tra vượt qua, họ thêm một bài kiểm tra thất bại khác và sau đó viết đủ mã để vượt qua bài kiểm tra thất bại. Chu kỳ này lặp lại cho đến khi nhà phát triển có tính năng hoạt động đầy đủ. Nếu mã trong bài kiểm tra có các phụ thuộc bên ngoài như cơ sở dữ liệu, tệp hoặc mạng, bạn có thể chế giễu chúng để cô lập mã. & NBSP;

Lợi ích của TDD:

• Viết các bài kiểm tra trước tiên buộc bạn phải suy nghĩ về tính năng bạn đang cố gắng xây dựng, giúp bạn tạo ra mã tốt hơn. & NBSP;
• Vì bạn luôn có một bộ thử nghiệm làm việc trong tay, một bài kiểm tra thất bại chỉ ra rằng vấn đề là với mã bạn vừa thêm vào, giảm thời gian gỡ lỗi. & NBSP;
• Viết bài kiểm tra giúp nhà phát triển làm rõ các yêu cầu và đặc điểm kỹ thuật. Nó thách thức để viết các bài kiểm tra tốt cho một bộ yêu cầu kém. & NBSP;
• Nó rất khó khăn để sản xuất phần mềm chất lượng cao trừ khi bạn có thể kiểm tra phần mềm sau mỗi lần thay đổi mới. Bạn không bao giờ có thể chắc chắn rằng mã mới của bạn đã không phá vỡ phần mềm làm việc. TDD cung cấp cho bạn sự tự tin để thêm mã mới, vì bạn đã có một bài kiểm tra tại chỗ.

Selenium là một công cụ tự động hóa trình duyệt web tự động hóa các phù hợp thử nghiệm bạn cần chạy trên trình duyệt web.

Một số lợi ích của selen bao gồm:

• Đó là phần mềm nguồn mở, loại bỏ chi phí cấp phép. & NBSP;
• Nó hỗ trợ tất cả các ngôn ngữ chính, chẳng hạn như Java, C#, Python, Ruby, v.v. & NBSP;
• Nó hỗ trợ tất cả các trình duyệt web chính, ví dụ: Google Chrome, Firefox, Safari, v.v. & NBSP;
• Bạn có thể tích hợp nó với các khung và công cụ thử nghiệm khác để xây dựng bộ thử nghiệm toàn diện cho phần mềm của bạn. & NBSP;

Selenium bao gồm các thành phần sau:

• Điều khiển từ xa Selenium (RC).
• Môi trường phát triển tích hợp Selen (IDE).
• Selenium webdriver.
• Lưới selen.

Tất cả các ứng dụng web chạy trong các trình duyệt như Google Chrome, Mozilla Firefox, Internet Explorer, Safari, v.v ... Mặc dù tất cả chúng đều hoạt động chủ yếu trong việc thực hiện các tiêu chuẩn web, có những khác biệt tinh tế trong tất cả chúng. Khi xây dựng phần mềm, nó không phải lúc nào cũng có thể cho nhà phát triển phần mềm kiểm tra tỉ mỉ tính năng trên nhiều trình duyệt, nhận thấy sự không nhất quán tinh tế.

Trong thử nghiệm trình duyệt chéo, trình kiểm tra phần mềm sẽ khởi chạy ứng dụng web trong tất cả các trình duyệt được hỗ trợ và cố gắng kiểm tra chức năng tương tự trên tất cả chúng. Họ lưu ý bất kỳ hành vi bất ngờ nào trong trình duyệt không hoạt động như mong đợi hoặc trông khác nhau; Lưu ý hành vi và tên và phiên bản trình duyệt trong báo cáo thử nghiệm. Điều này giúp lập trình viên sửa chữa hành vi trong tất cả các trình duyệt nơi nó không hoạt động như dự định. & NBSP;

Mã trạng thái HTTP là số ba chữ số cho biết trạng thái của yêu cầu HTTP đến, nghĩa là, nếu yêu cầu đã được hoàn thành hay chưa.

Một máy chủ có thể gửi năm loại phản hồi sau đây cho yêu cầu HTTP.

1. Thông tin (100 - 199): Các mã trạng thái này cung cấp phản hồi tạm thời. Phản hồi bao gồm dòng trạng thái và các tiêu đề tùy chọn và chấm dứt bằng một dòng trống. & NBSP;
2. Thành công (200 - 299): Chỉ ra rằng yêu cầu HTTP đến đã được nhận, hiểu và chấp nhận thành công. & NBSP;
3. Chuyển hướng (300 - 399): Các mã trạng thái này cho thấy các hành động tiếp theo mà khách hàng nên thực hiện để đáp ứng yêu cầu HTTP. Điều đó có thể có nghĩa là tài nguyên được yêu cầu có thể đã di chuyển tạm thời hoặc vĩnh viễn. Nó cũng có thể chuyển hướng khách hàng sang một URL khác. & NBSP;
4. Lỗi máy khách (400 - 499): Cho biết vấn đề với máy khách đã bắt đầu yêu cầu HTTP. & NBSP;
5. Lỗi máy chủ (500 - 599): Mã trạng thái 5xx cho biết sự cố trên máy chủ trong khi xử lý yêu cầu. & NBSP;

Như tên cho thấy, thử nghiệm tự động, còn được gọi là tự động hóa thử nghiệm, là việc thực hiện lập trình các bài kiểm tra. Người thử nghiệm sử dụng một công cụ tự động hóa hoặc phần mềm như selenium để ghi mã thực hiện các tác vụ sau.

1. Tự động chạy phần mềm.
2. Cho dữ liệu đầu vào vào hệ thống.
3. Kiểm tra đầu ra với kết quả mong đợi. & NBSP;
4. Thất bại trong bài kiểm tra nếu kết quả không phù hợp. Nếu không, vượt qua bài kiểm tra.

Khi một bài kiểm tra được tự động hóa, bạn có thể chạy nó thường xuyên như bạn muốn, để kiểm tra xem có bất kỳ mã mới nào đã phá vỡ nó không. Nó cho phép bạn dành thời gian cho các thử nghiệm có giá trị cao khác, chẳng hạn như thử nghiệm khám phá giúp tìm lỗi mà thử nghiệm tự động sẽ bỏ lỡ.

Thử nghiệm tự động có lợi cho thử nghiệm lặp đi lặp lại với các đầu vào không thay đổi thường xuyên. Con người cảm thấy mệt mỏi và chán khi tiến hành các bài kiểm tra tương tự nhiều lần và thấy kết quả tương tự. Nó rất dễ mắc lỗi khi bạn đang thử nghiệm một tính năng trong thời gian thứ hai mươi. Phần mềm tốt hơn nhiều trong việc thực hiện các nhiệm vụ lặp đi lặp lại mà không mệt mỏi hoặc mắc lỗi hơn là một người điều hành con người.

Thành công của thử nghiệm tự động hóa có thể được đo lường bằng các tiêu chí sau:

• Tiết kiệm cho lao động và các chi phí khác.
• Tỷ lệ phát hiện khiếm khuyết.
• Tự động hóa quá trình thực hiện và giảm thời gian phát hành.

Mặc dù nó thay đổi tùy thuộc vào kích thước và cấu trúc của các nhóm phát triển phần mềm, thông thường, một lỗi có thể được chỉ định các loại mức độ nghiêm trọng sau, đi từ thấp đến cao:

Thấp

• Lỗi giao diện người dùng.
• Vấn đề tiếp cận.

Vừa phải

• Trừu tượng bị rò rỉ.
• Phần mềm treo.
• Người dùng không thể thực hiện một hành động cụ thể.
• Điều kiện biên.

Cao

• Tấn công dưới tải cao.
• Logic kinh doanh và/hoặc lỗi tính toán.
• Bất kỳ hành động người dùng nào khiến phần mềm bị sập.
• Phơi bày dữ liệu người dùng nhạy cảm.
• Vấn đề bảo mật.
• Mất dữ liệu.

Các trường hợp thử nghiệm cho thử nghiệm hộp đen thường được viết trước, sau đó là các trường hợp thử nghiệm cho thử nghiệm hộp trắng. Một phác thảo của kế hoạch thiết kế hoặc dự án và tài liệu yêu cầu được yêu cầu để viết các trường hợp thử nghiệm hộp đen. Các tài liệu như thế này có sẵn ở đầu dự án. Giai đoạn ban đầu của một dự án không phải là thời điểm thích hợp để bắt đầu thử nghiệm hộp trắng vì nó đòi hỏi phải làm rõ hơn về kiến ​​trúc chưa có. Do đó, các trường hợp thử nghiệm hộp trắng thường được viết sau khi các trường hợp thử nghiệm hộp đen đã được phát triển.

Trước khi bạn gửi phần mềm cho khách hàng, nhóm thử nghiệm nội bộ thực hiện thử nghiệm alpha. Kiểm tra Alpha là một phần của thử nghiệm chấp nhận người dùng. Mục tiêu của nó là xác định lỗi trước khi khách hàng bắt đầu sử dụng phần mềm.

Khi bạn gửi phần mềm cho khách hàng sau khi thử nghiệm alpha, người dùng thực tế của phần mềm thực hiện thử nghiệm beta trong môi trường sản xuất thực sự. Đây là một trong những thành phần cuối cùng của kiểm tra chấp nhận người dùng. Kiểm tra beta rất hữu ích để nhận phản hồi từ những người thực bằng phần mềm của bạn trong môi trường thực. & NBSP;

Đó là một quá trình tự động kiểm tra chức năng ứng dụng web trong trình duyệt, trong đó chương trình khởi chạy trình duyệt, điều hướng đến ứng dụng và tương tác với giao diện người dùng bằng cách nhấp vào các nút hoặc liên kết, giống như người dùng trung bình.

Sự khác biệt duy nhất là tự động hóa trình duyệt có thể kiểm tra điều này rất nhanh và thường xuyên, trong khi cùng một thử nghiệm sẽ mất một người kiểm tra người trong một thời gian dài. Nó là một phần của thử nghiệm tự động. Một số công cụ thiết yếu để kiểm tra trình duyệt bao gồm selenium, protractor.js và Cypress.

Ma trận thử nghiệm: Nó được gọi là một công cụ thử nghiệm được sử dụng để nắm bắt chất lượng thực tế, nỗ lực, tài nguyên, kế hoạch và thời gian cần thiết để nắm bắt tất cả các giai đoạn kiểm tra phần mềm. Nó chỉ bao gồm giai đoạn thử nghiệm của vòng đời. It is referred to as a testing tool that is used to capture actual quality, effort, resources, plan, and time required to capture all the phases of software testing. It only covers the testing phase of the life cycle.

Ma trận truy xuất nguồn gốc yêu cầu (RTM): Nó được gọi là một tài liệu, thường có trong bảng mẫu, được sử dụng để theo dõi và chứng minh mối quan hệ giữa các yêu cầu và các hiện vật khác của dự án ngay từ đầu đến cuối. Nói một cách đơn giản, nó ánh xạ giữa các trường hợp kiểm tra và yêu cầu của khách hàng. It is referred to as a document, usually present in the form table, that is used to trace and demonstrate the relationship between the requirements and other artifacts of the project right from start to end. In simple words, it maps between test cases and customer requirements.

Các mô hình V, còn được gọi là mô hình xác thực hoặc xác minh, là các mô hình SDLC trong đó quá trình xảy ra tuần tự trong hình chữ V. Phương pháp này bao gồm liên kết giai đoạn thử nghiệm với từng giai đoạn phát triển tương ứng. Vì mỗi hoạt động phát triển đi kèm với một hoạt động thử nghiệm, giai đoạn thử nghiệm tiếp theo chỉ xảy ra sau khi giai đoạn trước đã được hoàn thành.

• Xác nhận: Nó được định nghĩa là một quy trình liên quan đến việc kiểm tra động các sản phẩm phần mềm bằng cách thực thi mã. Quá trình này xác nhận liệu chúng tôi có xây dựng đúng phần mềm đáp ứng yêu cầu của khách hàng đó hay không. Nó liên quan đến các hoạt động khác nhau như kiểm tra hệ thống, kiểm tra tích hợp, kiểm tra chấp nhận người dùng và kiểm tra đơn vị.: It is defined as a process that involves dynamic testing of software products by executing the code. This process validates whether we are building the right software that meets that customer's requirement or not. It involves various activities like system testing, integration testing, user acceptance testing, and unit testing.
• Xác minh: Kỹ thuật liên quan đến phân tích tĩnh (đánh giá) mà không cần chạy mã. Nó được định nghĩa là một quá trình liên quan đến việc phân tích các tài liệu. Quá trình này xác minh xem phần mềm có phù hợp với thông số kỹ thuật hay không. & nbsp; Mục tiêu cuối cùng của nó là đảm bảo chất lượng của các sản phẩm phần mềm, thiết kế, kiến ​​trúc, v.v. & nbsp;: The technique involves static analysis (review) without running the code. It is defined as a process that involves analyzing the documents. This process verifies whether the software conforms to specifications or not.  Its ultimate goal is to ensure the quality of software products, design, architecture, etc.  

Xác nhận: Nó được định nghĩa là một quá trình liên quan đến thử nghiệm động của các sản phẩm phần mềm bằng cách chạy nó. Quá trình này xác nhận liệu chúng tôi có xây dựng đúng phần mềm đáp ứng yêu cầu của khách hàng đó hay không. Nó liên quan đến các hoạt động khác nhau như kiểm tra hệ thống, kiểm tra tích hợp, kiểm tra chấp nhận người dùng và kiểm tra đơn vị. It is defined as a process that involves dynamic testing of software products by running it. This process validates whether we are building the right software that meets that customer requirement or not. It involves various activities like system testing, integration testing, user acceptance testing, and unit testing.

Xác minh: Nó được định nghĩa là một quá trình liên quan đến việc phân tích các tài liệu. Quá trình này xác minh xem phần mềm có phù hợp với thông số kỹ thuật hay không. & nbsp; Mục tiêu cuối cùng của nó là đảm bảo chất lượng của các sản phẩm phần mềm, thiết kế, kiến ​​trúc, v.v. It is defined as a process that involves analyzing the documents. This process verifies whether the software conforms to specifications or not.  Its ultimate goal is to ensure the quality of software products, design, architecture, etc.

Xác minh so với xác thực:

Kiểm tra tĩnh là một kỹ thuật mà bạn kiểm tra phần mềm mà không thực sự thực hiện nó. Nó liên quan đến việc thực hiện các hướng dẫn mã, đánh giá mã, đánh giá ngang hàng hoặc sử dụng các công cụ tinh vi như ESLINT, StyleCop để thực hiện phân tích tĩnh của mã nguồn. Kiểm tra tĩnh thường được thực hiện trong quá trình phát triển phần mềm.

Trái ngược với thử nghiệm tĩnh, thử nghiệm phần mềm động kiểm tra phần mềm khi nó thực hiện. Người kiểm tra chạy phần mềm trong môi trường thử nghiệm và thực hiện tất cả các bước liên quan, nhập vào đầu vào và xác minh đầu ra thực tế với kết quả dự kiến.

Một thử nghiệm xác nhận liên quan đến việc kiểm tra lại một sản phẩm phần mềm để xem liệu các lỗi được báo cáo trước đây đã được sửa. Một lỗi thường được báo cáo bởi những người thử nghiệm khi một thử nghiệm thất bại. Một phiên bản mới của phần mềm được phát hành sau khi nhóm phát triển sửa lỗi. Bây giờ bản dựng phần mềm mới đã được phát hành, nhóm thử nghiệm sẽ kiểm tra lại nó để đảm bảo rằng lỗi được báo cáo thực sự đã được sửa. Nó cũng được gọi là kiểm tra lại.

Vòng đời khiếm khuyết, còn được gọi là vòng đời lỗi, là một vòng đời của các giai đoạn khác nhau mà qua đó một khiếm khuyết đi trong suốt cuộc đời của nó. Vòng đời này bắt đầu ngay khi khiếm khuyết được phát hiện hoặc báo cáo bởi người kiểm tra và kết thúc khi người kiểm tra đảm bảo rằng khiếm khuyết được giải quyết và nó sẽ không xảy ra lần nữa. Vòng đời khiếm khuyết bao gồm các bước như hình dưới đây:

Trong thử nghiệm phần mềm, việc xếp tầng khiếm khuyết là kịch bản trong đó một khiếm khuyết dẫn đến sự xuất hiện của một số khiếm khuyết khác trong một chương trình. Nếu một khiếm khuyết không được chú ý trong quá trình thử nghiệm hoặc nếu nó không được báo cáo, nó có khả năng kích hoạt các vấn đề khác. Kết quả là nhiều khiếm khuyết phát sinh trong các giai đoạn sau của quá trình sản xuất.

Nếu một khiếm khuyết được phát hiện trong giai đoạn ban đầu của dự án, điều quan trọng là khiếm khuyết được loại bỏ trong giai đoạn đó thay vì sau đó. Chi phí sửa chữa một khiếm khuyết tăng lên rất nhiều nếu nó bị trì hoãn cho đến giai đoạn sau trong chu kỳ phát triển. Sau đây là một sơ đồ cho thấy chi phí của một lỗi sửa chữa tăng lên trong các giai đoạn.

Hiệu quả hơn về chi phí để loại bỏ các khiếm khuyết trong giai đoạn thiết kế, nhưng nó trở nên đắt hơn hai mươi lần để làm như vậy trong quá trình bảo trì.

Bàn làm việc là một tài liệu giải thích cách hoàn thành hoạt động. Thông thường, nó được gọi là một bước, pha hoặc nhiệm vụ. Bàn làm việc đóng vai trò là nền tảng để xây dựng và giám sát các cấu trúc công việc của người thử nghiệm. Sử dụng phương pháp này, có thể chia các tác vụ thành từng giai đoạn và đạt được kỳ vọng của khách hàng bằng cách sử dụng dữ liệu ban đầu.

Mỗi bàn làm việc đều có năm nhiệm vụ, như sau:

• Input.
• Execute.
• Check.
• Sản lượng sản xuất.
• Rework.

Khi tên khung và ID khung không khả dụng, chúng ta có thể sử dụng chỉ mục khung. Giả sử có bốn khung trên một trang không có tên khung hoặc định danh khung (ID khung), nhưng chúng ta vẫn có thể chọn chúng với thuộc tính chỉ mục khung (dựa trên không dựa trên). Chẳng hạn, khung đầu tiên sẽ được lập chỉ mục 0, khung thứ hai sẽ ở Index 1, khung thứ ba sẽ ở INDEX 2 và khung thứ tư sẽ ở INDEX 3.

driver.switchTo().frame(int arg0);

Bạn có thể được người phỏng vấn hỏi câu hỏi khó khăn này. Ví dụ, anh ta có thể cung cấp cho bạn một trang web với 20 liên kết và bạn sẽ phải xác định trong số 20 liên kết đó đang hoạt động và cái nào không hoặc bị hỏng.

Xem xét rằng bạn phải xác minh chức năng của từng liên kết, cách giải quyết là gửi các yêu cầu HTTP đến từng liên kết và phân tích phản hồi. Khi bạn điều hướng đến URL bằng phương thức trình điều khiển.get (), bạn sẽ nhận được phản hồi trạng thái 200 - OK. Rõ ràng là liên kết đã thu được và đang hoạt động. Trong trường hợp của bất kỳ trạng thái nào khác, liên kết bị phá vỡ.

Bây giờ hãy hiểu cách làm điều đó.

Bước đầu tiên, chúng ta phải xác định các siêu liên kết khác nhau trên trang web bằng cách sử dụng các thẻ neo. Chúng ta có thể thu được các siêu liên kết cho mỗi thẻ bằng cách sử dụng giá trị 'href' thuộc tính và phân tích phản hồi nhận được bằng phương thức trình điều khiển.get ().