Kiểm thử phần mềm - Hướng dẫn nhanh

Thử nghiệm là gì?

Kiểm tra là quá trình đánh giá một hệ thống hoặc (các) thành phần của nó với mục đích tìm xem liệu nó có đáp ứng các yêu cầu đã chỉ định hay không. Nói một cách dễ hiểu, kiểm thử là thực thi một hệ thống để xác định bất kỳ khoảng trống, lỗi hoặc yêu cầu nào bị thiếu trái với yêu cầu thực tế.

Theo tiêu chuẩn ANSI / IEEE 1059, Kiểm thử có thể được định nghĩa là - Một quá trình phân tích một mục phần mềm để phát hiện sự khác biệt giữa các điều kiện hiện có và điều kiện bắt buộc (đó là các khiếm khuyết / lỗi / lỗi) và để đánh giá các tính năng của mục phần mềm.

Ai làm thử nghiệm?

Nó phụ thuộc vào quá trình và các bên liên quan của (các) dự án. Trong ngành CNTT, các công ty lớn có một nhóm chịu trách nhiệm đánh giá phần mềm được phát triển theo các yêu cầu nhất định. Hơn nữa, các nhà phát triển cũng tiến hành thử nghiệm được gọi làUnit Testing. Trong hầu hết các trường hợp, các chuyên gia sau đây tham gia vào việc thử nghiệm một hệ thống trong phạm vi năng lực của họ -

Phần mềm thử nghiệm
Người phát triển phần mềm
Trưởng nhóm / Quản lý dự án
Người dùng cuối

Các công ty khác nhau có các chỉ định khác nhau cho những người kiểm tra phần mềm dựa trên kinh nghiệm và kiến thức của họ, chẳng hạn như Người kiểm tra phần mềm, Kỹ sư đảm bảo chất lượng phần mềm, Nhà phân tích QA, v.v.

Không thể kiểm tra phần mềm bất kỳ lúc nào trong chu kỳ của nó. Hai phần tiếp theo cho biết khi nào nên bắt đầu kiểm tra và khi nào thì kết thúc trong SDLC.

Khi nào bắt đầu thử nghiệm?

Việc bắt đầu thử nghiệm sớm giúp giảm chi phí và thời gian để làm lại và tạo ra phần mềm không có lỗi được giao cho khách hàng. Tuy nhiên, trong Vòng đời phát triển phần mềm (SDLC), việc kiểm thử có thể được bắt đầu từ giai đoạn Thu thập yêu cầu và tiếp tục cho đến khi triển khai phần mềm.

Nó cũng phụ thuộc vào mô hình phát triển đang được sử dụng. Ví dụ, trong mô hình Waterfall, thử nghiệm chính thức được tiến hành trong giai đoạn thử nghiệm; nhưng trong mô hình tăng dần, kiểm tra được thực hiện ở cuối mỗi lần tăng / lặp và toàn bộ ứng dụng được kiểm tra ở cuối.

Thử nghiệm được thực hiện ở các hình thức khác nhau ở mọi giai đoạn của SDLC -

Trong giai đoạn thu thập yêu cầu, việc phân tích và xác minh các yêu cầu cũng được coi là thử nghiệm.
Xem xét lại thiết kế trong giai đoạn thiết kế với mục đích cải thiện thiết kế cũng được coi là thử nghiệm.
Thử nghiệm do nhà phát triển thực hiện khi hoàn thành mã cũng được phân loại là thử nghiệm.

Khi nào thì dừng thử nghiệm?

Rất khó để xác định khi nào nên dừng thử nghiệm, vì thử nghiệm là một quá trình không bao giờ kết thúc và không ai có thể khẳng định rằng một phần mềm đã được thử nghiệm 100%. Các khía cạnh sau đây sẽ được xem xét để dừng quá trình thử nghiệm:

Thời hạn kiểm tra
Hoàn thành việc thực thi trường hợp thử nghiệm
Hoàn thành phạm vi chức năng và mã đến một điểm nhất định
Tỷ lệ lỗi giảm xuống dưới một mức nhất định và không có lỗi có mức độ ưu tiên cao nào được xác định
Quyết định quản lý

Xác minh & Xác thực

Hai thuật ngữ này rất khó hiểu đối với hầu hết mọi người, những người sử dụng chúng thay thế cho nhau. Bảng sau đây nêu bật sự khác biệt giữa xác minh và xác thực.

Sr.No.	xác minh	Thẩm định
1	Xác minh giải quyết mối quan tâm: "Bạn có đang xây dựng nó đúng không?"	Xác thực giải quyết mối quan tâm: "Bạn có đang xây dựng đúng không?"
2	Đảm bảo rằng hệ thống phần mềm đáp ứng tất cả các chức năng.	Đảm bảo rằng các chức năng đáp ứng hành vi dự định.
3	Việc xác minh diễn ra trước tiên và bao gồm việc kiểm tra tài liệu, mã, v.v.	Việc xác nhận xảy ra sau khi xác minh và chủ yếu liên quan đến việc kiểm tra tổng thể sản phẩm.
4	Do các nhà phát triển thực hiện.	Thực hiện bởi người thử nghiệm.
5	Nó có các hoạt động tĩnh, vì nó bao gồm thu thập đánh giá, hướng dẫn và kiểm tra để xác minh một phần mềm.	Nó có các hoạt động động, vì nó bao gồm việc thực thi phần mềm theo yêu cầu.
6	Đó là một quá trình khách quan và không cần quyết định chủ quan để xác minh một phần mềm.	Đó là một quá trình chủ quan và liên quan đến các quyết định chủ quan về cách thức hoạt động của một phần mềm.

Dưới đây là một số lầm tưởng phổ biến nhất về kiểm thử phần mềm.

Lầm tưởng 1: Thử nghiệm quá đắt

Reality- Có một câu nói rằng, trả ít hơn cho việc kiểm thử trong quá trình phát triển phần mềm hoặc trả nhiều hơn cho việc bảo trì hoặc sửa chữa sau này. Thử nghiệm sớm giúp tiết kiệm cả thời gian và chi phí về nhiều mặt, tuy nhiên, việc giảm chi phí mà không thử nghiệm có thể dẫn đến việc thiết kế ứng dụng phần mềm không phù hợp khiến sản phẩm trở nên vô dụng.

Lầm tưởng 2: Thử nghiệm tiêu tốn thời gian

Reality- Trong các giai đoạn SDLC, kiểm tra không bao giờ là một quá trình tốn thời gian. Tuy nhiên, chẩn đoán và sửa chữa các lỗi được xác định trong quá trình kiểm tra thích hợp là một hoạt động tốn nhiều thời gian nhưng hiệu quả.

Lầm tưởng 3: Chỉ những sản phẩm được phát triển đầy đủ mới được kiểm tra

Reality- Không nghi ngờ gì nữa, việc kiểm thử phụ thuộc vào mã nguồn nhưng việc xem xét các yêu cầu và phát triển các trường hợp kiểm thử là độc lập với mã đã phát triển. Tuy nhiên, cách tiếp cận lặp đi lặp lại hoặc tăng dần như một mô hình vòng đời phát triển có thể làm giảm sự phụ thuộc của việc kiểm thử vào phần mềm được phát triển đầy đủ.

Lầm tưởng 4: Có thể hoàn thành thử nghiệm

Reality- Nó trở thành một vấn đề khi khách hàng hoặc người kiểm tra nghĩ rằng việc kiểm tra hoàn chỉnh là có thể. Có thể nhóm đã kiểm tra tất cả các đường dẫn nhưng không bao giờ có thể xảy ra thử nghiệm hoàn chỉnh. Có thể có một số kịch bản không bao giờ được thực thi bởi nhóm kiểm thử hoặc khách hàng trong vòng đời phát triển phần mềm và có thể được thực hiện khi dự án đã được triển khai.

Lầm tưởng 5: Phần mềm được kiểm tra không có lỗi

Reality - Đây là một lầm tưởng rất phổ biến mà khách hàng, người quản lý dự án và nhóm quản lý tin tưởng. Không ai có thể khẳng định chắc chắn rằng một ứng dụng phần mềm là 100% không có lỗi ngay cả khi một người kiểm thử với kỹ năng kiểm thử tuyệt vời đã kiểm tra ứng dụng đó .

Lầm tưởng 6: Sai sót bị bỏ sót là do Người kiểm tra

Reality- Việc đổ lỗi cho người thử nghiệm đối với các lỗi vẫn còn trong ứng dụng không phải là một cách tiếp cận đúng đắn ngay cả khi đã thực hiện thử nghiệm. Huyền thoại này liên quan đến các Ràng buộc thay đổi về Thời gian, Chi phí và Yêu cầu. Tuy nhiên, chiến lược kiểm tra cũng có thể dẫn đến việc nhóm kiểm thử bỏ sót lỗi.

Quan niệm 7: Người kiểm tra chịu trách nhiệm về chất lượng sản phẩm

Reality- Một cách hiểu sai rất phổ biến rằng chỉ những người kiểm tra hoặc nhóm kiểm tra mới phải chịu trách nhiệm về chất lượng sản phẩm. Trách nhiệm của người kiểm thử bao gồm việc xác định lỗi cho các bên liên quan và sau đó họ sẽ quyết định xem họ sẽ sửa lỗi hay phát hành phần mềm. Việc phát hành phần mềm vào thời điểm đó gây áp lực nhiều hơn cho người kiểm tra, vì họ sẽ bị đổ lỗi cho bất kỳ lỗi nào.

Quan niệm 8: Tự động hóa kiểm tra nên được sử dụng bất cứ khi nào có thể để giảm thời gian

Reality- Đúng, đúng là Tự động hóa kiểm thử giảm thời gian kiểm thử, nhưng không thể bắt đầu tự động hóa kiểm thử bất cứ lúc nào trong quá trình phát triển phần mềm. Tự động kiểm tra nên được bắt đầu khi phần mềm đã được kiểm tra thủ công và ổn định ở một mức độ nào đó. Hơn nữa, tự động hóa thử nghiệm không bao giờ có thể được sử dụng nếu các yêu cầu liên tục thay đổi.

Lầm tưởng 9: Bất kỳ ai cũng có thể kiểm tra một ứng dụng phần mềm

Reality- Những người ngoài ngành CNTT nghĩ và thậm chí tin rằng ai cũng có thể kiểm thử một phần mềm và kiểm thử không phải là một công việc sáng tạo. Tuy nhiên những người thử nghiệm biết rất rõ rằng đây là một huyền thoại. Suy nghĩ về các tình huống thay thế, cố gắng phá hủy một phần mềm với mục đích khám phá các lỗi tiềm ẩn là điều không thể đối với người phát triển nó.

Lầm tưởng 10: Nhiệm vụ duy nhất của Tester là tìm ra lỗi

Reality- Tìm lỗi trong một phần mềm là nhiệm vụ của người kiểm thử, nhưng đồng thời họ cũng là chuyên gia miền của phần mềm cụ thể. Các nhà phát triển chỉ chịu trách nhiệm về thành phần hoặc khu vực cụ thể được giao cho họ nhưng người kiểm thử hiểu được hoạt động tổng thể của phần mềm, các phần phụ thuộc là gì và tác động của một mô-đun này lên mô-đun khác.

Kiểm tra, Đảm bảo Chất lượng và Kiểm soát Chất lượng

Hầu hết mọi người đều bối rối khi nói đến sự khác biệt giữa Đảm bảo chất lượng, Kiểm soát chất lượng và Thử nghiệm. Mặc dù chúng có mối quan hệ với nhau và ở một mức độ nào đó, chúng có thể được coi là những hoạt động giống nhau, nhưng tồn tại những điểm phân biệt khiến chúng trở nên khác biệt. Bảng sau liệt kê các điểm phân biệt QA, QC và Kiểm tra.

Đảm bảo chất lượng	Kiểm soát chất lượng	Thử nghiệm
QA bao gồm các hoạt động đảm bảo thực hiện các quy trình, thủ tục và tiêu chuẩn trong bối cảnh xác minh phần mềm đã phát triển và các yêu cầu dự kiến.	Nó bao gồm các hoạt động đảm bảo xác minh một phần mềm được phát triển đối với các yêu cầu được lập thành văn bản (hoặc không trong một số trường hợp).	Nó bao gồm các hoạt động đảm bảo xác định lỗi / lỗi / khiếm khuyết trong phần mềm.
Tập trung vào các quy trình và thủ tục hơn là tiến hành thử nghiệm thực tế trên hệ thống.	Tập trung vào kiểm tra thực tế bằng cách thực thi phần mềm nhằm mục đích xác định lỗi / lỗi thông qua việc thực hiện các quy trình và quy trình.	Tập trung vào thử nghiệm thực tế.
Các hoạt động hướng theo quy trình.	Các hoạt động định hướng sản phẩm.	Các hoạt động định hướng sản phẩm.
Các hoạt động phòng ngừa.	Đó là một quá trình sửa chữa.	Đó là một quá trình phòng ngừa.
Nó là một tập hợp con của Vòng đời kiểm tra phần mềm (STLC).	QC có thể được coi là tập hợp con của Đảm bảo chất lượng.	Kiểm tra là tập hợp con của Kiểm soát chất lượng.

Kiểm toán và Kiểm tra

Audit- Là một quá trình có hệ thống để xác định cách thức tiến hành quá trình thử nghiệm thực tế trong một tổ chức hoặc một nhóm. Nói chung, nó là một cuộc kiểm tra độc lập các quy trình liên quan trong quá trình thử nghiệm một phần mềm. Theo IEEE, đó là việc xem xét các quy trình được lập thành văn bản mà các tổ chức thực hiện và tuân theo. Các loại hình kiểm toán bao gồm Kiểm toán tuân thủ pháp luật, Kiểm toán nội bộ và Kiểm toán hệ thống.

Inspection- Đây là một kỹ thuật chính thức liên quan đến việc xem xét kỹ thuật chính thức hoặc không chính thức đối với bất kỳ hiện vật nào bằng cách xác định bất kỳ lỗi hoặc lỗ hổng nào. Theo IEEE94, kiểm tra là một kỹ thuật đánh giá chính thức, trong đó các yêu cầu, thiết kế hoặc mã phần mềm được kiểm tra chi tiết bởi một người hoặc một nhóm không phải tác giả để phát hiện lỗi, vi phạm tiêu chuẩn phát triển và các vấn đề khác.

Các cuộc họp kiểm tra chính thức có thể bao gồm các quy trình sau: Lập kế hoạch, Chuẩn bị Tổng quan, Họp Kiểm tra, Làm lại và Theo dõi.

Kiểm tra và gỡ lỗi

Testing- Nó liên quan đến việc xác định lỗi / lỗi / khiếm khuyết trong phần mềm mà không cần sửa chữa nó. Thông thường các chuyên gia có nền tảng đảm bảo chất lượng sẽ tham gia vào việc xác định lỗi. Thử nghiệm được thực hiện trong giai đoạn thử nghiệm.

Debugging- Nó liên quan đến việc xác định, cô lập và sửa chữa các vấn đề / lỗi. Các nhà phát triển viết mã phần mềm sẽ tiến hành gỡ lỗi khi gặp lỗi trong mã. Gỡ lỗi là một phần của Kiểm thử hộp trắng hoặc Kiểm thử đơn vị. Gỡ lỗi có thể được thực hiện trong giai đoạn phát triển trong khi tiến hành Kiểm thử đơn vị hoặc trong các giai đoạn trong khi sửa các lỗi được báo cáo.

Nhiều tổ chức trên toàn cầu phát triển và thực hiện các tiêu chuẩn khác nhau để cải thiện nhu cầu chất lượng của phần mềm của họ. Chương này mô tả ngắn gọn một số tiêu chuẩn được sử dụng rộng rãi liên quan đến Kiểm tra và Đảm bảo Chất lượng.

ISO / IEC 9126

Tiêu chuẩn này đề cập đến các khía cạnh sau để xác định chất lượng của một ứng dụng phần mềm:

Mô hình chất lượng
Các chỉ số bên ngoài
Chỉ số nội bộ
Chỉ số chất lượng đang sử dụng

Tiêu chuẩn này trình bày một số tập hợp các thuộc tính chất lượng cho bất kỳ phần mềm nào như:

Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

Các thuộc tính chất lượng nêu trên được chia thành các yếu tố phụ, bạn có thể nghiên cứu khi nghiên cứu chi tiết tiêu chuẩn.

ISO / IEC 9241-11

Phần 11 của tiêu chuẩn này đề cập đến mức độ mà một sản phẩm có thể được sử dụng bởi những người dùng cụ thể để đạt được các mục tiêu cụ thể với Hiệu lực, Hiệu quả và Sự hài lòng trong một bối cảnh sử dụng cụ thể.

Tiêu chuẩn này đề xuất một khuôn khổ mô tả các thành phần khả năng sử dụng và mối quan hệ giữa chúng. Trong tiêu chuẩn này, khả năng sử dụng được xem xét ở khía cạnh hiệu suất và sự hài lòng của người sử dụng. Theo ISO 9241-11, khả năng sử dụng phụ thuộc vào bối cảnh sử dụng và mức độ khả dụng sẽ thay đổi khi bối cảnh thay đổi.

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005 thường được biết đến là tiêu chuẩn cung cấp các hướng dẫn về Yêu cầu và Đánh giá Chất lượng Phần mềm (SQuaRE). Tiêu chuẩn này giúp tổ chức và nâng cao quy trình liên quan đến các yêu cầu chất lượng phần mềm và các đánh giá của chúng. Trên thực tế, ISO-25000 thay thế hai tiêu chuẩn ISO cũ là ISO-9126 và ISO-14598.

SQuaRE được chia thành các phần phụ như -

ISO 2500n - Bộ phận quản lý chất lượng
ISO 2501n - Bộ phận Mô hình Chất lượng
ISO 2502n - Bộ phận đo lường chất lượng
ISO 2503n - Bộ phận yêu cầu chất lượng
ISO 2504n - Bộ phận đánh giá chất lượng

Nội dung chính của SQuaRE là -

Thuật ngữ và định nghĩa
Mô hình Tham chiếu
Hướng dẫn chung
Hướng dẫn phân chia cá nhân
Tiêu chuẩn liên quan đến Kỹ thuật Yêu cầu (tức là quy trình đặc tả, lập kế hoạch, đo lường và đánh giá)

ISO / IEC 12119

Tiêu chuẩn này đề cập đến các gói phần mềm được giao cho khách hàng. Nó không tập trung hoặc giải quyết quá trình sản xuất của khách hàng. Nội dung chính liên quan đến các mục sau:

Tập hợp các yêu cầu cho gói phần mềm.
Hướng dẫn kiểm tra gói phần mềm được phân phối so với các yêu cầu được chỉ định.

Điều khoản khác

Một số tiêu chuẩn khác liên quan đến quy trình QA và Kiểm tra được đề cập dưới đây:

Sr.No	Tiêu chuẩn & Mô tả
1	IEEE 829 Một tiêu chuẩn cho định dạng của tài liệu được sử dụng trong các giai đoạn khác nhau của kiểm thử phần mềm.
2	IEEE 1061 Phương pháp luận để thiết lập các yêu cầu chất lượng, xác định, thực hiện, phân tích và xác thực quy trình và sản phẩm của các chỉ số chất lượng phần mềm.
3	IEEE 1059 Hướng dẫn cho Kế hoạch xác minh và xác thực phần mềm.
4	IEEE 1008 Một tiêu chuẩn để kiểm tra đơn vị.
5	IEEE 1012 Một tiêu chuẩn để xác minh và xác thực phần mềm.
6	IEEE 1028 Một tiêu chuẩn để kiểm tra phần mềm.
7	IEEE 1044 Một tiêu chuẩn để phân loại các dị thường của phần mềm.
số 8	IEEE 1044-1 Hướng dẫn phân loại các dị thường của phần mềm.
9	IEEE 830 Hướng dẫn phát triển các đặc tả yêu cầu hệ thống.
10	IEEE 730 Một tiêu chuẩn cho các kế hoạch đảm bảo chất lượng phần mềm.
11	IEEE 1061 Một tiêu chuẩn cho các phương pháp và số liệu chất lượng phần mềm.
12	IEEE 12207 Một tiêu chuẩn cho các quy trình vòng đời phần mềm và dữ liệu vòng đời.
13	BS 7925-1 Từ vựng các thuật ngữ được sử dụng trong kiểm thử phần mềm.
14	BS 7925-2 Một tiêu chuẩn để kiểm tra thành phần phần mềm.

Phần này mô tả các kiểu kiểm tra khác nhau có thể được sử dụng để kiểm tra phần mềm trong quá trình SDLC.

Kiểm tra bằng tay

Kiểm thử thủ công bao gồm kiểm tra một phần mềm theo cách thủ công, tức là không sử dụng bất kỳ công cụ tự động nào hoặc bất kỳ tập lệnh nào. Trong loại này, người kiểm tra đảm nhận vai trò của người dùng cuối và kiểm tra phần mềm để xác định bất kỳ hành vi hoặc lỗi không mong muốn nào. Có các giai đoạn khác nhau để kiểm thử thủ công như kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận người dùng.

Người kiểm thử sử dụng kế hoạch kiểm thử, trường hợp kiểm thử hoặc kịch bản kiểm thử để kiểm tra phần mềm nhằm đảm bảo tính hoàn chỉnh của kiểm thử. Kiểm tra thủ công cũng bao gồm kiểm tra khám phá, khi người kiểm tra khám phá phần mềm để xác định lỗi trong đó.

Kiểm tra tự động hóa

Kiểm thử tự động, còn được gọi là Kiểm thử tự động, là khi người kiểm thử viết các kịch bản và sử dụng một phần mềm khác để kiểm tra sản phẩm. Quy trình này liên quan đến việc tự động hóa quy trình thủ công. Kiểm thử tự động được sử dụng để chạy lại các kịch bản kiểm tra đã được thực hiện theo cách thủ công, nhanh chóng và lặp đi lặp lại.

Ngoài kiểm thử hồi quy, kiểm thử tự động hóa cũng được sử dụng để kiểm tra ứng dụng từ quan điểm tải, hiệu suất và căng thẳng. Nó làm tăng phạm vi kiểm tra, cải thiện độ chính xác và tiết kiệm thời gian và tiền bạc so với kiểm tra thủ công.

Tự động hóa cái gì?

Không thể tự động hóa mọi thứ trong một phần mềm. Các khu vực mà người dùng có thể thực hiện các giao dịch như biểu mẫu đăng nhập hoặc biểu mẫu đăng ký, bất kỳ khu vực nào mà số lượng lớn người dùng có thể truy cập phần mềm đồng thời nên được tự động hóa.

Hơn nữa, tất cả các mục GUI, kết nối với cơ sở dữ liệu, xác thực trường, v.v. có thể được kiểm tra hiệu quả bằng cách tự động hóa quy trình thủ công.

Khi nào thì tự động hóa?

Tự động hóa kiểm tra nên được sử dụng bằng cách xem xét các khía cạnh sau của phần mềm:

Các dự án lớn và quan trọng
Các dự án yêu cầu kiểm tra các khu vực giống nhau thường xuyên
Yêu cầu không thay đổi thường xuyên
Truy cập ứng dụng để tải và hiệu suất với nhiều người dùng ảo
Phần mềm ổn định liên quan đến kiểm tra thủ công
Thời gian có sẵn

Làm thế nào để tự động hóa?

Tự động hóa được thực hiện bằng cách sử dụng một ngôn ngữ máy tính hỗ trợ như VB script và một ứng dụng phần mềm tự động. Có rất nhiều công cụ có sẵn có thể được sử dụng để viết các kịch bản tự động hóa. Trước khi đề cập đến các công cụ, chúng ta hãy xác định quy trình có thể được sử dụng để tự động hóa quy trình thử nghiệm -

Xác định các khu vực trong một phần mềm để tự động hóa
Lựa chọn công cụ thích hợp để tự động hóa kiểm tra
Viết kịch bản thử nghiệm
Phát triển các bộ quần áo thử nghiệm
Thực thi các tập lệnh
Tạo báo cáo kết quả
Xác định bất kỳ lỗi tiềm ẩn hoặc sự cố hiệu suất nào

Công cụ kiểm tra phần mềm

Các công cụ sau có thể được sử dụng để kiểm tra tự động hóa:

HP Quick Test Professional
Selenium
Bộ kiểm tra chức năng hợp lý của IBM
SilkTest
TestComplete
Kiểm tra mọi nơi
WinRunner
LoadRunner
Visual Studio Test Professional
WATIR

Có nhiều phương pháp khác nhau có thể được sử dụng để kiểm thử phần mềm. Chương này mô tả ngắn gọn các phương pháp có sẵn.

Kiểm tra hộp đen

Kỹ thuật kiểm tra mà không có bất kỳ kiến thức nào về hoạt động bên trong của ứng dụng được gọi là kiểm tra hộp đen. Người kiểm tra không biết gì về kiến trúc hệ thống và không có quyền truy cập vào mã nguồn. Thông thường, trong khi thực hiện kiểm tra hộp đen, người kiểm tra sẽ tương tác với giao diện người dùng của hệ thống bằng cách cung cấp đầu vào và kiểm tra đầu ra mà không cần biết cách thức và vị trí hoạt động của đầu vào.

Bảng dưới đây liệt kê những ưu điểm và nhược điểm của kiểm thử hộp đen.

Ưu điểm	Nhược điểm
Phù hợp và hiệu quả cho các phân đoạn mã lớn.	Phạm vi giới hạn, vì chỉ một số kịch bản thử nghiệm được chọn được thực hiện thực sự.
Truy cập mã là không cần thiết.	Kiểm tra không hiệu quả, do thực tế là người kiểm tra chỉ có kiến thức hạn chế về ứng dụng.
Phân tách rõ ràng quan điểm của người dùng với quan điểm của nhà phát triển thông qua các vai trò được xác định rõ ràng.	Phạm vi bảo hiểm mù, vì người kiểm tra không thể nhắm mục tiêu các phân đoạn mã cụ thể hoặc các khu vực lỗi.
Một số lượng lớn người kiểm tra có kỹ năng vừa phải có thể kiểm tra ứng dụng mà không cần kiến thức về triển khai, ngôn ngữ lập trình hoặc hệ điều hành.	Các trường hợp kiểm thử rất khó để thiết kế.

Kiểm tra hộp trắng

Kiểm thử hộp trắng là điều tra chi tiết về logic và cấu trúc bên trong của mã. Thử nghiệm hộp trắng còn được gọi làglass testing hoặc là open-box testing. Để trình bàywhite-box thử nghiệm trên một ứng dụng, người thử nghiệm cần biết hoạt động bên trong của mã.

Người kiểm tra cần phải xem bên trong mã nguồn và tìm ra đơn vị / đoạn mã nào đang hoạt động không phù hợp.

Bảng sau liệt kê những ưu điểm và nhược điểm của thử nghiệm hộp trắng.

Ưu điểm	Nhược điểm
Vì người kiểm tra có kiến thức về mã nguồn, nên rất dễ dàng tìm ra loại dữ liệu nào có thể giúp kiểm tra ứng dụng một cách hiệu quả.	Do thực tế là cần một người kiểm tra có tay nghề cao để thực hiện kiểm tra hộp trắng, chi phí sẽ tăng lên.
Nó giúp tối ưu hóa mã.	Đôi khi không thể nhìn vào mọi ngóc ngách để tìm ra những lỗi tiềm ẩn có thể tạo ra vấn đề, vì nhiều con đường sẽ không được kiểm tra.
Có thể loại bỏ các dòng mã bổ sung có thể gây ra các khuyết tật tiềm ẩn.	Rất khó để duy trì thử nghiệm hộp trắng, vì nó đòi hỏi các công cụ chuyên dụng như máy phân tích mã và công cụ gỡ lỗi.
Do kiến thức của người thử nghiệm về mã, mức độ phù hợp tối đa đạt được trong quá trình viết kịch bản thử nghiệm.

Thử nghiệm hộp xám

Kiểm thử hộp xám là một kỹ thuật để kiểm tra ứng dụng với kiến thức hạn chế về hoạt động bên trong của ứng dụng. Trong kiểm thử phần mềm, cụm từ bạn càng biết nhiều thì càng có nhiều sức nặng trong khi kiểm thử một ứng dụng.

Việc nắm vững miền của hệ thống luôn mang lại cho người thử nghiệm lợi thế hơn người có kiến thức về miền hạn chế. Không giống như kiểm thử hộp đen, nơi người kiểm tra chỉ kiểm tra giao diện người dùng của ứng dụng; trong thử nghiệm hộp xám, người thử nghiệm có quyền truy cập vào tài liệu thiết kế và cơ sở dữ liệu. Có kiến thức này, người kiểm tra có thể chuẩn bị dữ liệu kiểm tra tốt hơn và các kịch bản kiểm tra trong khi lập kế hoạch kiểm tra.

Ưu điểm	Nhược điểm
Cung cấp các lợi ích kết hợp của thử nghiệm hộp đen và hộp trắng bất cứ khi nào có thể.	Vì quyền truy cập vào mã nguồn không khả dụng, nên khả năng xem qua mã và kiểm tra phạm vi bị hạn chế.
Người kiểm tra hộp màu xám không dựa vào mã nguồn; thay vào đó chúng dựa vào định nghĩa giao diện và các đặc tả chức năng.	Các bài kiểm tra có thể dư thừa nếu nhà thiết kế phần mềm đã chạy một trường hợp kiểm thử.
Dựa trên thông tin hạn chế có sẵn, trình kiểm tra hộp xám có thể thiết kế các kịch bản kiểm tra tuyệt vời, đặc biệt là xung quanh các giao thức truyền thông và xử lý kiểu dữ liệu.	Việc kiểm tra mọi luồng đầu vào có thể có là không thực tế vì nó sẽ mất một khoảng thời gian không hợp lý; do đó, nhiều đường dẫn chương trình sẽ không được kiểm tra.
Thử nghiệm được thực hiện từ quan điểm của người dùng chứ không phải của nhà thiết kế.

So sánh các phương pháp kiểm tra

Bảng sau liệt kê các điểm phân biệt kiểm tra hộp đen, kiểm tra hộp xám và kiểm tra hộp trắng.

Kiểm tra hộp đen	Thử nghiệm hộp xám	Kiểm tra hộp trắng
Không cần biết các hoạt động bên trong của một ứng dụng.	Người thử nghiệm có kiến thức hạn chế về hoạt động bên trong của ứng dụng.	Tester có đầy đủ kiến thức về hoạt động bên trong của ứng dụng.
Còn được gọi là thử nghiệm hộp kín, thử nghiệm theo hướng dữ liệu hoặc thử nghiệm chức năng.	Còn được gọi là thử nghiệm trong mờ, vì người thử nghiệm có kiến thức hạn chế về nội dung của ứng dụng.	Còn được gọi là thử nghiệm hộp rõ ràng, thử nghiệm cấu trúc hoặc thử nghiệm dựa trên mã.
Được thực hiện bởi người dùng cuối và cả người thử nghiệm và nhà phát triển.	Được thực hiện bởi người dùng cuối và cả người thử nghiệm và nhà phát triển.	Thường được thực hiện bởi người thử nghiệm và nhà phát triển.
Kiểm tra dựa trên kỳ vọng bên ngoài - Hành vi bên trong của ứng dụng là không xác định.	Việc kiểm tra được thực hiện trên cơ sở sơ đồ cơ sở dữ liệu cấp cao và sơ đồ luồng dữ liệu.	Các hoạt động bên trong đã được biết đầy đủ và người thử nghiệm có thể thiết kế dữ liệu thử nghiệm cho phù hợp.
Nó là hoàn chỉnh và ít tốn thời gian nhất.	Một phần là mất thời gian và mệt mỏi.	Loại thử nghiệm toàn diện và tốn thời gian nhất.
Không phù hợp để kiểm tra thuật toán.	Không phù hợp để kiểm tra thuật toán.	Thích hợp để kiểm tra thuật toán.
Điều này chỉ có thể được thực hiện bằng phương pháp thử và sai.	Các miền dữ liệu và ranh giới bên trong có thể được kiểm tra, nếu biết.	Miền dữ liệu và ranh giới bên trong có thể được kiểm tra tốt hơn.

Có các mức độ khác nhau trong quá trình thử nghiệm. Trong chương này, mô tả ngắn gọn được cung cấp về các cấp độ này.

Các cấp độ kiểm thử bao gồm các phương pháp luận khác nhau có thể được sử dụng trong khi tiến hành kiểm thử phần mềm. Các cấp độ chính của kiểm thử phần mềm là -

Thử nghiệm chức năng
Kiểm tra phi chức năng

Thử nghiệm chức năng

Đây là một loại kiểm thử hộp đen dựa trên các thông số kỹ thuật của phần mềm sẽ được kiểm tra. Ứng dụng được kiểm tra bằng cách cung cấp đầu vào và sau đó kết quả được kiểm tra xem cần phải phù hợp với chức năng mà nó dự kiến. Kiểm tra chức năng của một phần mềm được tiến hành trên một hệ thống tích hợp, hoàn chỉnh để đánh giá sự tuân thủ của hệ thống với các yêu cầu cụ thể của nó.

Có năm bước liên quan trong khi kiểm tra một ứng dụng về chức năng.

Các bước	Sự miêu tả
Tôi	Việc xác định chức năng mà ứng dụng dự kiến sẽ thực hiện.
II	Việc tạo ra dữ liệu thử nghiệm dựa trên các thông số kỹ thuật của ứng dụng.
III	Kết quả dựa trên dữ liệu thử nghiệm và các thông số kỹ thuật của ứng dụng.
IV	Việc viết các kịch bản kiểm thử và thực hiện các trường hợp kiểm thử.
V	So sánh kết quả thực tế và kết quả mong đợi dựa trên các trường hợp thử nghiệm đã thực hiện.

Một thực hành kiểm thử hiệu quả sẽ thấy các bước trên được áp dụng cho các chính sách kiểm thử của mọi tổ chức và do đó nó sẽ đảm bảo rằng tổ chức duy trì các tiêu chuẩn nghiêm ngặt nhất về chất lượng phần mềm.

Kiểm tra đơn vị

Loại thử nghiệm này được thực hiện bởi các nhà phát triển trước khi thiết lập được bàn giao cho nhóm thử nghiệm để chính thức thực hiện các trường hợp thử nghiệm. Kiểm thử đơn vị được thực hiện bởi các nhà phát triển tương ứng trên các đơn vị riêng lẻ của các khu vực được chỉ định mã nguồn. Các nhà phát triển sử dụng dữ liệu thử nghiệm khác với dữ liệu thử nghiệm của nhóm đảm bảo chất lượng.

Mục tiêu của kiểm thử đơn vị là cô lập từng phần của chương trình và chỉ ra rằng các phần riêng lẻ là đúng về yêu cầu và chức năng.

Hạn chế của Kiểm thử đơn vị

Kiểm tra không thể bắt từng lỗi trong một ứng dụng. Không thể đánh giá mọi đường dẫn thực thi trong mọi ứng dụng phần mềm. Điều này cũng xảy ra với kiểm thử đơn vị.

Có giới hạn về số lượng kịch bản và dữ liệu thử nghiệm mà nhà phát triển có thể sử dụng để xác minh mã nguồn. Sau khi đã hết tất cả các tùy chọn, không có lựa chọn nào khác ngoài việc dừng thử nghiệm đơn vị và hợp nhất đoạn mã với các đơn vị khác.

Thử nghiệm hội nhập

Kiểm thử tích hợp được định nghĩa là kiểm tra các phần kết hợp của một ứng dụng để xác định xem chúng có hoạt động chính xác hay không. Kiểm thử tích hợp có thể được thực hiện theo hai cách: Kiểm thử tích hợp từ dưới lên và Kiểm thử tích hợp từ trên xuống.

Sr.No.	Phương pháp kiểm tra tích hợp
1	Bottom-up integration Thử nghiệm này bắt đầu với thử nghiệm đơn vị, sau đó là thử nghiệm kết hợp cấp độ cao hơn dần dần của các đơn vị được gọi là mô-đun hoặc bản dựng.
2	Top-down integration Trong thử nghiệm này, các mô-đun cấp cao nhất được kiểm tra đầu tiên và dần dần, các mô-đun cấp thấp hơn được kiểm tra sau đó.

Trong môi trường phát triển phần mềm toàn diện, kiểm tra từ dưới lên thường được thực hiện trước, sau đó là kiểm tra từ trên xuống. Quá trình kết thúc với nhiều thử nghiệm của ứng dụng hoàn chỉnh, tốt nhất là trong các tình huống được thiết kế để bắt chước các tình huống thực tế.

Thử nghiệm hệ thống

Kiểm thử hệ thống kiểm tra toàn bộ hệ thống. Khi tất cả các thành phần được tích hợp, toàn bộ ứng dụng sẽ được kiểm tra nghiêm ngặt để đảm bảo rằng nó đáp ứng các Tiêu chuẩn chất lượng được chỉ định. Loại thử nghiệm này được thực hiện bởi một nhóm thử nghiệm chuyên biệt.

Kiểm tra hệ thống rất quan trọng vì những lý do sau:

Kiểm thử hệ thống là bước đầu tiên trong Vòng đời phát triển phần mềm, nơi ứng dụng được kiểm tra tổng thể.
Ứng dụng được kiểm tra kỹ lưỡng để xác minh rằng nó đáp ứng các thông số kỹ thuật và chức năng.
Ứng dụng được thử nghiệm trong một môi trường rất gần với môi trường sản xuất nơi ứng dụng sẽ được triển khai.
Kiểm tra hệ thống cho phép chúng tôi kiểm tra, xác minh và xác nhận cả các yêu cầu nghiệp vụ cũng như kiến trúc ứng dụng.

Kiểm tra hồi quy

Bất cứ khi nào một thay đổi trong ứng dụng phần mềm được thực hiện, rất có thể các khu vực khác trong ứng dụng đã bị ảnh hưởng bởi thay đổi này. Kiểm tra hồi quy được thực hiện để xác minh rằng một lỗi đã sửa không dẫn đến vi phạm chức năng hoặc quy tắc kinh doanh khác. Mục đích của kiểm tra hồi quy là để đảm bảo rằng một thay đổi, chẳng hạn như sửa lỗi sẽ không dẫn đến một lỗi khác được phát hiện trong ứng dụng.

Kiểm tra hồi quy rất quan trọng vì những lý do sau:

Giảm thiểu khoảng trống trong quá trình kiểm thử khi một ứng dụng có các thay đổi được thực hiện phải được kiểm tra.
Kiểm tra các thay đổi mới để xác minh rằng các thay đổi được thực hiện không ảnh hưởng đến bất kỳ khu vực nào khác của ứng dụng.
Giảm thiểu rủi ro khi kiểm tra hồi quy được thực hiện trên ứng dụng.
Phạm vi kiểm tra được tăng lên mà không ảnh hưởng đến các mốc thời gian.
Tăng tốc độ tiếp thị sản phẩm.

Kiểm tra chấp nhận

Đây được cho là loại thử nghiệm quan trọng nhất, vì nó được tiến hành bởi Nhóm đảm bảo chất lượng, người sẽ đánh giá xem ứng dụng có đáp ứng các thông số kỹ thuật dự kiến và đáp ứng yêu cầu của khách hàng hay không. Nhóm QA sẽ có một tập hợp các kịch bản được viết sẵn và các trường hợp kiểm thử sẽ được sử dụng để kiểm tra ứng dụng.

Nhiều ý tưởng hơn sẽ được chia sẻ về ứng dụng và nhiều bài kiểm tra hơn có thể được thực hiện trên nó để đánh giá độ chính xác của nó và lý do tại sao dự án được bắt đầu. Các bài kiểm tra chấp nhận không chỉ nhằm mục đích chỉ ra các lỗi chính tả đơn giản, lỗi thẩm mỹ hoặc lỗ hổng giao diện mà còn để chỉ ra bất kỳ lỗi nào trong ứng dụng có thể dẫn đến sự cố hệ thống hoặc các lỗi lớn trong ứng dụng.

Bằng cách thực hiện các kiểm thử chấp nhận trên một ứng dụng, nhóm kiểm thử sẽ giảm bớt cách ứng dụng sẽ hoạt động trong quá trình sản xuất. Ngoài ra còn có các yêu cầu pháp lý và hợp đồng để chấp nhận hệ thống.

Thử nghiệm alpha

Thử nghiệm này là giai đoạn đầu tiên của thử nghiệm và sẽ được thực hiện giữa các nhóm (nhóm phát triển và QA). Kiểm thử đơn vị, kiểm tra tích hợp và kiểm tra hệ thống khi kết hợp với nhau được gọi là kiểm tra alpha. Trong giai đoạn này, các khía cạnh sau sẽ được kiểm tra trong ứng dụng:

Lỗi đánh vần
Liên kết bị hỏng
Chỉ đường có mây
Ứng dụng sẽ được thử nghiệm trên các máy có thông số kỹ thuật thấp nhất để kiểm tra thời gian tải và mọi vấn đề về độ trễ.

Thử nghiệm Beta

Thử nghiệm này được thực hiện sau khi thử nghiệm alpha đã được thực hiện thành công. Trong thử nghiệm beta, một mẫu đối tượng dự kiến sẽ kiểm tra ứng dụng. Thử nghiệm beta còn được gọi làpre-release testing. Các phiên bản thử nghiệm beta của phần mềm được phân phối lý tưởng cho nhiều đối tượng trên Web, một phần để cung cấp cho chương trình một thử nghiệm "trong thế giới thực" và một phần để cung cấp bản xem trước của bản phát hành tiếp theo. Trong giai đoạn này, khán giả sẽ thử nghiệm những điều sau:

Người dùng sẽ cài đặt, chạy ứng dụng và gửi phản hồi của họ cho nhóm dự án.
Lỗi đánh máy, luồng ứng dụng khó hiểu và thậm chí là treo máy.
Nhận được phản hồi, nhóm dự án có thể khắc phục sự cố trước khi phát hành phần mềm cho người dùng thực tế.
Bạn càng khắc phục được nhiều vấn đề giải quyết được các vấn đề của người dùng thực thì chất lượng ứng dụng của bạn càng cao.
Có một ứng dụng chất lượng cao hơn khi bạn phát hành nó ra công chúng sẽ làm tăng sự hài lòng của khách hàng.

Kiểm tra phi chức năng

Phần này dựa trên việc kiểm tra một ứng dụng từ các thuộc tính phi chức năng của nó. Kiểm thử phi chức năng liên quan đến việc kiểm tra một phần mềm từ các yêu cầu về bản chất là phi chức năng nhưng quan trọng như hiệu suất, bảo mật, giao diện người dùng, v.v.

Một số loại kiểm thử phi chức năng quan trọng và thường được sử dụng được thảo luận dưới đây.

Kiểm tra năng suất

Nó chủ yếu được sử dụng để xác định bất kỳ tắc nghẽn hoặc các vấn đề về hiệu suất hơn là tìm lỗi trong một phần mềm. Có những nguyên nhân khác nhau góp phần làm giảm hiệu suất của phần mềm -

Mạng trễ
Xử lý phía máy khách
Xử lý giao dịch cơ sở dữ liệu
Cân bằng tải giữa các máy chủ
Kết xuất dữ liệu

Kiểm tra hiệu suất được coi là một trong những loại kiểm tra quan trọng và bắt buộc xét về các khía cạnh sau:

Tốc độ (tức là Thời gian phản hồi, kết xuất và truy cập dữ liệu)
Capacity
Stability
Scalability

Kiểm tra hiệu suất có thể là định tính hoặc định lượng và có thể được chia thành các loại phụ khác nhau như Load testing và Stress testing.

Kiểm tra tải

Nó là một quá trình kiểm tra hành vi của một phần mềm bằng cách áp dụng tải tối đa về phần mềm truy cập và thao tác dữ liệu đầu vào lớn. Nó có thể được thực hiện ở cả điều kiện tải bình thường và cao điểm. Loại thử nghiệm này xác định dung lượng tối đa của phần mềm và hành vi của nó vào thời gian cao điểm.

Hầu hết thời gian, kiểm tra tải được thực hiện với sự trợ giúp của các công cụ tự động như Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, v.v.

Người dùng ảo (VUsers) được xác định trong công cụ kiểm tra tự động và tập lệnh được thực thi để xác minh kiểm tra tải cho phần mềm. Số lượng người dùng có thể được tăng hoặc giảm đồng thời hoặc tăng dần tùy theo yêu cầu.

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

Kiểm tra căng thẳng bao gồm kiểm tra hành vi của một phần mềm trong các điều kiện bất thường. Ví dụ: nó có thể bao gồm việc lấy đi một số tài nguyên hoặc áp dụng tải vượt quá giới hạn tải thực tế.

Mục đích của kiểm thử căng thẳng là kiểm tra phần mềm bằng cách áp dụng tải lên hệ thống và tiếp quản các tài nguyên được sử dụng bởi phần mềm để xác định điểm đứt. Thử nghiệm này có thể được thực hiện bằng cách thử nghiệm các tình huống khác nhau như -

Tắt hoặc khởi động lại các cổng mạng ngẫu nhiên
Bật hoặc tắt cơ sở dữ liệu
Chạy các quy trình khác nhau tiêu tốn tài nguyên như CPU, bộ nhớ, máy chủ, v.v.

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

Kiểm tra khả năng sử dụng là một kỹ thuật hộp đen và được sử dụng để xác định (các) lỗi và các cải tiến trong phần mềm bằng cách quan sát người dùng thông qua việc sử dụng và vận hành của họ.

Theo Nielsen, khả năng sử dụng có thể được định nghĩa theo năm yếu tố, tức là hiệu quả sử dụng, khả năng học hỏi, khả năng ghi nhớ, lỗi / an toàn và sự hài lòng. Theo ông, khả năng sử dụng của một sản phẩm sẽ tốt và hệ thống có thể sử dụng được nếu nó sở hữu những yếu tố trên.

Nigel Bevan và Macleod cho rằng khả năng sử dụng là yêu cầu chất lượng có thể được đo lường như kết quả của các tương tác với hệ thống máy tính. Yêu cầu này có thể được đáp ứng và người dùng cuối sẽ hài lòng nếu các mục tiêu dự kiến đạt được một cách hiệu quả với việc sử dụng các nguồn lực thích hợp.

Molich năm 2000 đã tuyên bố rằng một hệ thống thân thiện với người dùng phải đáp ứng được năm mục tiêu sau, tức là dễ học, dễ nhớ, hiệu quả để sử dụng, dễ sử dụng và dễ hiểu.

Ngoài các định nghĩa khác nhau về khả năng sử dụng, có một số tiêu chuẩn và mô hình chất lượng và phương pháp xác định khả năng sử dụng ở dạng thuộc tính và thuộc tính phụ như ISO-9126, ISO-9241-11, ISO-13407 và IEEE std. 610.12, v.v.

Kiểm tra giao diện người dùng và khả năng sử dụng

Kiểm tra giao diện người dùng bao gồm việc kiểm tra Giao diện người dùng đồ họa của Phần mềm. Kiểm tra giao diện người dùng đảm bảo rằng GUI hoạt động theo yêu cầu và được kiểm tra về màu sắc, căn chỉnh, kích thước và các thuộc tính khác.

Mặt khác, kiểm tra khả năng sử dụng đảm bảo một GUI tốt và thân thiện với người dùng có thể dễ dàng xử lý. Kiểm tra giao diện người dùng có thể được coi là một phần phụ của kiểm tra khả năng sử dụng.

Kiểm tra bảo mật

Kiểm tra bảo mật liên quan đến việc kiểm tra một phần mềm để xác định bất kỳ lỗ hổng và lỗ hổng nào theo quan điểm bảo mật và lỗ hổng bảo mật. Dưới đây là các khía cạnh chính mà kiểm tra bảo mật cần đảm bảo:

Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
Phần mềm được bảo mật trước các lỗ hổng đã biết và chưa biết
Dữ liệu phần mềm được bảo mật
Phần mềm tuân theo tất cả các quy định bảo mật
Kiểm tra đầu vào và xác nhận
Các cuộc tấn công chèn SQL
Sai sót tiêm
Các vấn đề về quản lý phiên
Các cuộc tấn công kịch bản trên nhiều trang web
Bộ đệm làm tràn lỗ hổng
Các cuộc tấn công truyền tải thư mục

Kiểm tra tính di động

Kiểm tra tính khả chuyển bao gồm kiểm tra một phần mềm với mục đích đảm bảo khả năng tái sử dụng của nó và nó cũng có thể được di chuyển từ một phần mềm khác. Sau đây là các chiến lược có thể được sử dụng để kiểm tra tính di động -

Chuyển một phần mềm đã cài đặt từ máy tính này sang máy tính khác.
Xây dựng tệp thực thi (.exe) để chạy phần mềm trên các nền tảng khác nhau.

Kiểm thử tính khả chuyển có thể được coi là một trong những phần phụ của kiểm thử hệ thống, vì loại kiểm thử này bao gồm kiểm tra tổng thể một phần mềm liên quan đến việc sử dụng nó trong các môi trường khác nhau. Phần cứng máy tính, hệ điều hành và trình duyệt là trọng tâm chính của kiểm tra tính di động. Một số điều kiện trước để kiểm tra tính di động như sau:

Phần mềm phải được thiết kế và mã hóa, lưu ý các yêu cầu về tính di động.
Kiểm thử đơn vị đã được thực hiện trên các thành phần liên quan.
Kiểm tra tích hợp đã được thực hiện.
Môi trường thử nghiệm đã được thiết lập.

Tài liệu kiểm tra liên quan đến tài liệu về các tạo tác cần được phát triển trước hoặc trong quá trình kiểm tra Phần mềm.

Tài liệu về kiểm thử phần mềm giúp ước tính nỗ lực kiểm thử cần thiết, phạm vi kiểm tra, theo dõi / truy tìm yêu cầu, v.v. Phần này mô tả một số hiện vật được lập thành văn bản thường được sử dụng liên quan đến kiểm thử phần mềm như -

Kế hoạch kiểm tra
Kịch bản thử nghiệm
Trường hợp thử nghiệm
Ma trận truy xuất nguồn gốc

Kế hoạch kiểm tra

Kế hoạch kiểm thử phác thảo chiến lược sẽ được sử dụng để kiểm tra một ứng dụng, các tài nguyên sẽ được sử dụng, môi trường kiểm thử mà việc kiểm thử sẽ được thực hiện, các hạn chế của kiểm thử và lịch trình của các hoạt động kiểm thử. Thông thường, Trưởng nhóm Đảm bảo Chất lượng sẽ chịu trách nhiệm viết Kế hoạch Kiểm tra.

Một kế hoạch kiểm tra bao gồm những điều sau:

Giới thiệu về tài liệu Kế hoạch kiểm tra
Các giả định trong khi kiểm tra ứng dụng
Danh sách các trường hợp thử nghiệm được bao gồm trong việc thử nghiệm ứng dụng
Danh sách các tính năng sẽ được kiểm tra
Loại phương pháp tiếp cận nào để sử dụng trong khi kiểm tra phần mềm
Danh sách các sản phẩm cần được kiểm tra
Các tài nguyên được phân bổ để kiểm tra ứng dụng
Mọi rủi ro liên quan trong quá trình thử nghiệm
Lịch trình các nhiệm vụ và các mốc quan trọng cần đạt được

Kịch bản thử nghiệm

Nó là một câu lệnh một dòng thông báo khu vực nào trong ứng dụng sẽ được kiểm tra. Các kịch bản kiểm tra được sử dụng để đảm bảo rằng tất cả các luồng quy trình đều được kiểm tra từ đầu đến cuối. Một khu vực cụ thể của ứng dụng có thể có từ một kịch bản thử nghiệm đến vài trăm kịch bản tùy thuộc vào mức độ và độ phức tạp của ứng dụng.

Thuật ngữ 'kịch bản thử nghiệm' và 'trường hợp thử nghiệm' được sử dụng thay thế cho nhau, tuy nhiên một kịch bản thử nghiệm có một số bước, trong khi một trường hợp thử nghiệm có một bước duy nhất. Nhìn từ góc độ này, các kịch bản thử nghiệm là các trường hợp thử nghiệm, nhưng chúng bao gồm một số trường hợp thử nghiệm và trình tự mà chúng phải được thực thi. Ngoài ra, mỗi bài kiểm tra phụ thuộc vào kết quả của bài kiểm tra trước đó.

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

Các trường hợp kiểm thử bao gồm một tập hợp các bước, điều kiện và đầu vào có thể được sử dụng trong khi thực hiện các nhiệm vụ kiểm tra. Mục đích chính của hoạt động này là đảm bảo một phần mềm vượt qua hay thất bại về chức năng và các khía cạnh khác của nó. Có nhiều loại trường hợp kiểm thử như trường hợp kiểm thử chức năng, tiêu cực, lỗi, trường hợp logic, trường hợp kiểm thử vật lý, trường hợp kiểm thử giao diện người dùng, v.v.

Hơn nữa, các trường hợp kiểm thử được viết để theo dõi phạm vi kiểm thử của một phần mềm. Nói chung, không có mẫu chính thức nào có thể được sử dụng trong quá trình viết test case. Tuy nhiên, các thành phần sau luôn có sẵn và được bao gồm trong mọi trường hợp thử nghiệm -

ID trường hợp thử nghiệm
Mô-đun sản phẩm
Phiên bản sản phẩm
Lịch sử sửa đổi
Purpose
Assumptions
Pre-conditions
Steps
Kết quả dự kiến
Kết quả thực tế
Post-conditions

Nhiều trường hợp thử nghiệm có thể bắt nguồn từ một kịch bản thử nghiệm duy nhất. Ngoài ra, đôi khi nhiều trường hợp kiểm thử được viết cho một phần mềm duy nhất được gọi chung là bộ kiểm thử.

Ma trận truy xuất nguồn gốc

Ma trận xác định nguồn gốc (còn được gọi là Ma trận xác định nguồn gốc yêu cầu - RTM) là một bảng được sử dụng để theo dõi các yêu cầu trong Vòng đời phát triển phần mềm. Nó có thể được sử dụng để truy tìm phía trước (tức là từ Yêu cầu đến Thiết kế hoặc Mã hóa) hoặc ngược lại (tức là từ Mã hóa đến Yêu cầu). Có nhiều mẫu do người dùng xác định cho RTM.

Mỗi yêu cầu trong tài liệu RTM được liên kết với trường hợp thử nghiệm liên quan của nó để việc thử nghiệm có thể được thực hiện theo các yêu cầu đã đề cập. Hơn nữa, Bug ID cũng được bao gồm và liên kết với các yêu cầu liên quan và trường hợp thử nghiệm của nó. Các mục tiêu chính cho ma trận này là -

Đảm bảo phần mềm được phát triển theo các yêu cầu đã đề cập.
Giúp tìm ra nguyên nhân gốc rễ của bất kỳ lỗi nào.
Giúp truy tìm các tài liệu được phát triển trong các giai đoạn khác nhau của SDLC.

Estimating the efforts required for testing is one of the major and important tasks in SDLC. Correct estimation helps in testing the software with maximum coverage. This section describes some of the techniques that can be useful in estimating the efforts required for testing.

Functional Point Analysis

This method is based on the analysis of functional user requirements of the software with the following categories −

Outputs
Inquiries
Inputs
Internal files
External files

Phân tích điểm kiểm tra

Quá trình ước lượng này được sử dụng để phân tích điểm chức năng cho hộp đen hoặc thử nghiệm chấp nhận. Các yếu tố chính của phương pháp này là: Quy mô, Năng suất, Chiến lược, Giao diện, Độ phức tạp và Tính đồng nhất.

Phương pháp Mark-II

Đây là một phương pháp ước tính được sử dụng để phân tích và đo lường ước tính dựa trên chế độ xem chức năng của người dùng cuối. Quy trình cho phương pháp Mark-II như sau:

Xác định điểm nhìn
Mục đích và loại số đếm
Xác định ranh giới của số lượng
Xác định các giao dịch hợp lý
Xác định và phân loại các loại thực thể dữ liệu
Đếm các loại phần tử dữ liệu đầu vào
Đếm kích thước chức năng

Điều khoản khác

Bạn có thể sử dụng các kỹ thuật ước tính phổ biến khác như -

Kỹ thuật Delphi
Ước tính dựa trên tương tự
Ước tính dựa trên kê khai trường hợp thử nghiệm
Ước tính dựa trên Nhiệm vụ (Hoạt động)
Phương pháp IFPUG