Chúng ta có thể giả định trong khi kiểm tra phần mềm rằng người dùng sẽ không thực hiện những hành động ngớ ngẩn như vậy trên phần mềm không?

Ví dụ: Trong khi thực hiện kiểm tra chức năng của một biểu mẫu trong ứng dụng web, chúng tôi sẽ kiểm tra các trường bằng cách nhập các loại giá trị đầu vào ngẫu nhiên khác nhau.

Nói chung, chúng tôi với tư cách là người dùng ứng dụng web không thực sự nhập các giá trị ngẫu nhiên vào các trường.

Vì vậy, việc sử dụng kết hợp tất cả các testcase có thể / có thể không dẫn đến lỗi là gì, khi xác suất xuất hiện các loại vấn đề này trong sản xuất là cách ít hơn?

Lưu ý: Ví dụ trên chỉ là một trường hợp mẫu; những vấn đề như vậy có thể xảy ra trong bất kỳ loại tính năng / mô-đun.

Tôi chỉ hỏi câu hỏi này để biết liệu có bất kỳ thực hành tiêu chuẩn nào được thực hiện hay không hoàn toàn phụ thuộc vào sản phẩm, tên miền và tất cả các yếu tố khác.

Bạn có thể không nhập các giá trị ngẫu nhiên vào các trường của một ứng dụng web, nhưng chắc chắn có những người ở ngoài đó làm điều đó.

Một số người nhập ngẫu nhiên một cách tình cờ và những người khác cố tình phá vỡ ứng dụng. Trong cả hai trường hợp, bạn không muốn ứng dụng bị sập hoặc thể hiện hành vi không mong muốn khác.
Đối với loại người dùng đầu tiên, bạn không muốn điều đó bởi vì nó mang lại cho họ trải nghiệm tồi tệ và có thể khiến họ bỏ đi.
Đối với loại người dùng thứ hai, họ thường không có ý định danh dự và bạn không muốn cho phép họ truy cập vào thông tin mà họ không thể truy cập hoặc cho phép họ từ chối người dùng chính hãng truy cập vào dịch vụ của bạn.

Thực hành tiêu chuẩn để kiểm tra là để xác minh không chỉ trường hợp thời tiết tốt mà còn các trường hợp cạnh bất thường được khám phá để tìm ra các vấn đề tiềm ẩn và để tin rằng kẻ tấn công không thể dễ dàng truy cập vào hệ thống của bạn. Nếu ứng dụng của bạn gặp sự cố với đầu vào ngẫu nhiên, bạn không muốn biết kẻ tấn công có thể làm gì với đầu vào được chế tạo đặc biệt.

Không bao giờ giả sử bất cứ điều gì

Bạn không thể cho rằng bất kỳ người dùng nào sẽ không làm điều gì đó "ngớ ngẩn" với phần mềm của bạn một cách tình cờ hoặc cố ý. Người dùng có thể vô tình nhấn nhầm nút, con mèo có thể đi qua bàn phím, hệ thống có thể gặp trục trặc, máy tính của họ có thể bị tấn công bởi phần mềm độc hại, v.v.

Hơn nữa, bản thân người dùng có thể độc hại, cố tình tìm cách phá vỡ phần mềm của bạn với hy vọng rằng họ có thể tìm cách khai thác phần mềm này thành lợi thế của họ. Ngay cả khi họ tìm thấy một lỗi mà họ không thể khai thác, bất cứ điều gì họ tìm thấy đều có thể thúc đẩy họ thăm dò hệ thống của bạn để tìm thứ gì đó mà họ có thể tấn công, biết rằng các quy trình QA của bạn đang thiếu.

Đối với thử nghiệm có liên quan, rất hữu ích để bảo vệ chống lại đầu vào ngẫu nhiên, tuy nhiên việc chọn đầu vào thử nghiệm hoàn toàn ngẫu nhiên (nghĩa là không có sự xem xét cụ thể đối với bất kỳ trường hợp sử dụng hoặc trường hợp cạnh nào) đều vô dụng. Mục đích của kiểm tra là xác nhận giải pháp của bạn theo các yêu cầu và mong đợi của chủ lao động / khách hàng / người dùng của bạn; điều này có nghĩa là bạn cần tập trung vào việc nhắm mục tiêu tất cả các trường hợp cạnh và điều kiện biên, cũng như bất kỳ trường hợp 'thoái hóa' nào không phù hợp với quy trình làm việc dự kiến ​​của người dùng.

Tất nhiên, bạn có thể chạy các bài kiểm tra phát hiện ra các lỗi mà sau đó bạn quyết định không đáng để sửa; điều này có thể vì tất cả các lý do - lỗi có thể quá đắt để khắc phục liên quan đến tác động của nó đối với người dùng hoặc bạn có thể phát hiện ra các lỗi trong các tính năng không ai sử dụng hoặc lỗi có thể đã được cài đặt sẵn trong hệ thống. Người dùng đang coi nó như một tính năng.

Ngoài ra, bạn có thể đang viết một số phần mềm bespoke có đối tượng người dùng 'chuyên gia' bị hạn chế rất nhiều khi không có lợi ích thương mại để dành thời gian sửa lỗi, vì những người dùng đó có khả năng thực hiện công việc của họ với phần mềm lỗi (ví dụ: công cụ chẩn đoán được sử dụng bởi nhóm CNTT nội bộ sẽ không mang lại bất kỳ doanh thu nào, vì vậy nếu thỉnh thoảng nó gặp sự cố, thì không ai có khả năng muốn trả tiền cho thời gian cần thiết để khắc phục - thay vào đó họ sẽ nói với nhóm CNTT sống với các lỗi) .

Tuy nhiên, bạn chỉ có thể đưa ra các quyết định này nếu bạn biết về các lỗi này. Ví dụ: người dùng có thể nhập dữ liệu độc hại để xóa toàn bộ cơ sở dữ liệu - nếu bạn không được bảo vệ và kiểm tra rõ ràng cho kịch bản này, thì không có cách nào bạn có thể chắc chắn liệu điều này có thể xảy ra hay không. Nguy cơ để lại các lỗi chưa được phát hiện trong hệ thống có nghĩa là bạn có khả năng để mình gặp vấn đề thực sự nếu một trong những lỗi đó xuất hiện trong thế giới thực và có tác động lớn đến người dùng của bạn.

Vì vậy, trong khi quyết định có sửa lỗi có thể yêu cầu một số đầu vào từ chủ sở hữu phần mềm (thường là bất kỳ ai trả lương cho bạn), quyết định về việc có nên kiểm tra lỗi hay không và trường hợp nào cần kiểm tra là vấn đề kỹ thuật cần phải có được xem xét trong các ước tính và lập kế hoạch dự án, trong đó mục tiêu nên dành cho một cái gì đó gần với phạm vi bảo hiểm đầy đủ nhất có thể với các ràng buộc về thời gian / tiền bạc / tài nguyên.

Có một số yếu tố cần tính đến. Để minh họa những điểm đó, tôi sẽ sử dụng một ví dụ về trường mà người dùng nên nhập tỷ lệ phần trăm trong ngữ cảnh hạn ngạch được xác định cho một tác vụ cụ thể về mặt dung lượng mà tác vụ có thể sử dụng. 0% có nghĩa là tác vụ sẽ không thể ghi bất cứ điều gì vào đĩa; 100% có nghĩa là tác vụ có thể lấp đầy tất cả không gian đĩa. Giá trị ở giữa có nghĩa là những gì họ có nghĩa.

Là nhà phát triển, có lẽ bạn đang xem xét rằng các giá trị có thể chấp nhận là [0, 1, 2, 3, ⋯ 99, 100] và mọi thứ khác đều ngớ ngẩn. Chúng ta hãy xem tại sao người dùng vẫn có thể tham gia vào các giá trị đó.

Typose

%^

Người dùng đã nhập giá trị 56, nhưng nhấn nhầm Shifttrong khi nhập chúng (ví dụ vì trên bàn phím tiếng Pháp, bạn phải nhấn Shiftđể nhập chữ số và người dùng liên tục chuyển đổi giữa bàn phím tiếng Pháp và QWERTY).

Theo cùng một cách, bạn có thể nhận được một số, với một cái gì đó sau hoặc trước nó hoặc ở giữa:

56q

Ở đây, người dùng có thể đã nhập các chữ số, theo sau là một tab để chuyển sang trường tiếp theo. Thay vì nhấn   ⇆  , người dùng nhấn phím hàng xóm.

Hiểu lầm và giải thích sai

Một đầu vào trống có lẽ là bình thường nhất. Người dùng tưởng tượng rằng trường này là tùy chọn hoặc không biết nên đặt gì trong trường này.

56.5

Người dùng nghĩ rằng giá trị dấu phẩy động là chấp nhận được. Người dùng sai và ứng dụng nên giải thích một cách lịch sự tại sao chỉ chấp nhận các giá trị nguyên hoặc các yêu cầu ban đầu là sai và việc cho phép người dùng nhập các giá trị dấu phẩy động là hợp lý.

none

Người dùng đã hiểu nhầm rằng khi được yêu cầu dung lượng mà tác vụ có thể thực hiện, ứng dụng sẽ mong đợi một con số. Điều này có thể chỉ ra một giao diện người dùng kém. Chẳng hạn, hỏi người dùng, nhiệm vụ cần bao nhiêu dung lượng đĩa? 'Mời mời loại đầu vào này, trong khi một trường có ký hiệu phần trăm theo sau sẽ nhận được ít hơn loại đầu vào đó, bởi vì không ai %% không thực hiện nhiều ý nghĩa.

150

Người dùng đã hiểu nhầm phần trăm có nghĩa là gì trong trường hợp này. Có thể người dùng muốn nói rằng tác vụ có thể chiếm 150% dung lượng hiện đang sử dụng, vì vậy nếu trên đĩa 2 TB, 100 GB được sử dụng, tác vụ có thể sử dụng 150 GB. Một lần nữa, một giao diện người dùng tốt hơn có thể giúp đỡ. Chẳng hạn, thay vì có một trường đầu vào trống với ký hiệu phần trăm được gắn vào nó, người ta có thể có điều này:

[____] % of disk space (2 TB)

Khi người dùng bắt đầu nhập, nó sẽ thay đổi văn bản một cách nhanh chóng để trở thành thế này:

[5___] % of disk space (102.4 GB of 2 TB)

Đại diện

Số lớn hoặc số có điểm nổi có thể được biểu diễn khác nhau. Chẳng hạn, một số 1234.56 có thể được viết như thế : 1,234.56. Tùy thuộc vào văn hóa, cách trình bày văn bản của cùng một số sẽ khác nhau. Trong tiếng Pháp, cùng một số sẽ được viết như thế này : 1 234,56. Hãy xem, một dấu phẩy mà bạn không mong đợi và một khoảng trắng.

Luôn mong đợi một định dạng cụ thể bằng cách sử dụng một ngôn ngữ cụ thể sẽ sớm khiến bạn gặp rắc rối, bởi vì người dùng từ các quốc gia khác nhau sẽ có thói quen viết số, ngày và thời gian khác nhau, v.v.

Con người so với máy tính

Twenty-four

Người thường không nghĩ giống như máy tính. Số hai mươi bốn mươi là một con số thực tế, độc lập với những gì PC sẽ nói với bạn.

Mặc dù (1) hầu hết các hệ thống không xử lý tất cả các loại đầu vào này và (2) gần như mọi người dùng sẽ không tưởng tượng việc nhập một số được viết bằng chữ đầy đủ, điều đó không có nghĩa là đầu vào đó là ngớ ngẩn. Trong About Face 3 , Alan Cooper đưa ra quan điểm rằng việc không xử lý các đầu vào như vậy là dấu hiệu cho thấy máy tính không thể thích ứng với con người và lý tưởng nhất là giao diện có thể xử lý các đầu vào đó một cách chính xác.

Điều duy nhất tôi phải thêm vào cuốn sách của Alan Cooper là trong nhiều trường hợp, các con số được viết bằng chữ số do nhầm lẫn . Việc các máy tính mong muốn người dùng của họ mắc lỗi (và sẽ không tha thứ cho người dùng viết đúng) gây khó chịu.

Unicode

5𝟨

Unicode bảo lưu những bất ngờ của riêng nó: các ký tự có thể trông giống nhau không giống nhau. Không thuyết phục? Sao chép-dán "5𝟨" === "56"vào các công cụ phát triển của trình duyệt của bạn và nhấn Enter.

Lý do mà các chuỗi đó không bằng nhau là ký tự Unicode 𝟨không giống với ký tự 6. Điều này sẽ tạo ra một tình huống mà một khách hàng tức giận sẽ gọi, nói rằng ứng dụng của bạn không hoạt động, cung cấp ảnh chụp màn hình của đầu vào có vẻ hợp pháp và ứng dụng của bạn cho rằng đầu vào không hợp lệ.

Tại sao mọi người sẽ nhập một ký tự Unicode trông giống như một chữ số, bạn sẽ hỏi? Mặc dù tôi không mong muốn người dùng nhập vào một cách vô ý, nhưng việc sao chép từ một nguồn khác nhau có thể gây ra điều đó và tôi đã gặp trường hợp người dùng thực sự thực hiện việc sao chép chuỗi đó có chứa ký tự Unicode sẽ không xuất hiện trên màn hình.

Phần kết luận

Đó là những trường hợp bạn nhận được cho một trường nhập số cơ bản. Tôi sẽ cho bạn tưởng tượng những gì bạn có thể phải xử lý đối với các hình thức phức tạp hơn, chẳng hạn như ngày hoặc địa chỉ.

Câu trả lời của tôi tập trung vào những gì bạn gọi là đầu vào của silly. Kiểm tra không phải là kiểm tra các con đường hạnh phúc; đó cũng là về việc kiểm tra xem ứng dụng của bạn không bị hỏng khi người dùng độc hại cố tình xâm nhập vào những thứ lạ, cố gắng phá vỡ nó. Điều này có nghĩa là khi bạn yêu cầu tỷ lệ phần trăm, bạn cũng phải kiểm tra xem điều gì sẽ xảy ra khi người dùng phản hồi bằng chuỗi chứa 1.000.000 ký tự hoặc số âm hoặc bảng bợm .

Có rất nhiều câu trả lời hay ở đây mô tả lý do tại sao điều này lại quan trọng, nhưng không có nhiều lời khuyên về cách bảo vệ hợp lý ứng dụng của bạn. "Thực hành tiêu chuẩn" là sử dụng xác nhận đầu vào mạnh mẽ, trên cả máy khách và máy chủ. Đầu vào không nhạy cảm là dễ dàng để bảo vệ chống lại; bạn chỉ cần từ chối bất cứ điều gì không có ý nghĩa trong bối cảnh cụ thể đó. Ví dụ, số an sinh xã hội chỉ bao gồm dấu gạch ngang và chữ số; bạn có thể từ chối một cách an toàn bất cứ điều gì khác mà người dùng nhập vào trường số an sinh xã hội.

Có hai loại thử nghiệm nên diễn ra trên mỗi ứng dụng bạn viết và mỗi loại đều có mục đích khác nhau. Các thử nghiệm bạn làm trên ứng dụng của riêng bạn là thử nghiệm tích cực; Mục đích của nó là để chứng minh rằng chương trình hoạt động. Việc kiểm tra những gì người kiểm tra bổ sung làm trên ứng dụng của bạn là kiểm tra âm tính; Mục đích của nó là để chứng minh rằng chương trình của bạn không hoạt động. Tại sao bạn cần điều này? Bởi vì bạn không phải là người tốt nhất để kiểm tra phần mềm của riêng bạn. Rốt cuộc, bạn đã viết điều đó, vì vậy rõ ràng nó đã hoạt động, phải không?

Khi bạn viết xác nhận đầu vào, bạn sẽ sử dụng các thử nghiệm tích cực để chứng minh rằng xác thực của bạn hoạt động. Người kiểm tra sẽ sử dụng đầu vào ngẫu nhiên để cố gắng chứng minh rằng nó không hoạt động. Lưu ý rằng không gian vấn đề cho các đầu vào ngẫu nhiên về cơ bản là không giới hạn; Mục tiêu của bạn không phải là kiểm tra mọi hoán vị có thể, mà là giới hạn không gian vấn đề bằng cách từ chối đầu vào không hợp lệ.

Cũng lưu ý rằng người dùng cuối không phải là người duy nhất cung cấp đầu vào cho chương trình của bạn. Mỗi lớp bạn viết đều có API riêng và các ràng buộc riêng về những gì được coi là đầu vào hợp lệ, do đó, xác thực mạnh mẽ (tức là "hợp đồng mã") cũng quan trọng đối với các lớp của bạn. Ý tưởng là làm cứng phần mềm của bạn để hành vi không mong muốn là hiếm hoặc không tồn tại ở mức tối đa có thể.

Cuối cùng, quy trình làm việc là quan trọng. Tôi đã thấy các ứng dụng bị đổ, không phải vì người dùng đã nhập một cái gì đó không nhạy cảm, mà bởi vì họ đã làm những điều trong ứng dụng theo thứ tự không mong muốn. Ứng dụng của bạn nên nhận thức được khả năng này và xử lý các luồng công việc đột xuất một cách duyên dáng hoặc yêu cầu người dùng thực hiện các thao tác theo thứ tự được chỉ định của bạn.

Thông thường các giá trị 'ngẫu nhiên' không phải là ngẫu nhiên. Bạn đang cố gắng để nắm bắt các trường hợp cạnh, "không xác định".

Ví dụ: ký tự # sẽ đánh sập ứng dụng của bạn. Bạn không biết trước điều này và sẽ không thể viết trường hợp kiểm tra cho mọi đầu vào có thể. Nhưng chúng ta có thể viết một bài kiểm tra "¬!"£$%^&*()_+-=[]{};'#:@~,./<>?|\"và xem nếu nó phá vỡ

Tôi đã từng viết một chương trình, mà tôi đã thử nghiệm trực tiếp trong phòng thí nghiệm với 60 sinh viên. Tôi đang đứng sau 60 màn hình máy tính và thấy họ sử dụng nó. Số lượng những điều lố bịch mà họ đã làm là nuôi tóc. Tôi ướt đẫm mồ hôi khi nhìn "sự sáng tạo" của họ. Họ đã làm nhiều hơn bất kỳ cá nhân đơn lẻ nào có thể tưởng tượng trong vòng một đời. Tất nhiên một trong số họ đã phá vỡ nó.

Sau đó tôi làm theo một cách tiếp cận: if "a very specific use case" do, else show error

Nếu tôi có một vài trường hợp sử dụng, tôi xác định nghiêm ngặt chúng và xâu chuỗi các mục trên.

Những gì bạn đang mô tả là Kiểm tra Fuzzing hoặc Fuzz : ném đầu vào ngẫu nhiên và không hợp lệ vào một hệ thống và xem điều gì sẽ xảy ra. Bạn không làm điều này bởi vì bạn mong đợi một người dùng sẽ làm điều đó. Bạn làm điều đó để phơi bày những giả định và thành kiến ​​của riêng bạn để nhấn mạnh các cạnh của hệ thống của bạn để xem điều gì sẽ xảy ra.

Đầu vào kiểm tra bình thường được viết bởi một người với sẽ đi kèm với các giả định và thành kiến. Những sai lệch này có thể là một số loại lỗi nhất định không bao giờ được tìm thấy thông qua thử nghiệm.

Ví dụ: nếu hầu hết đầu vào của bạn nằm trong phạm vi Unicode an toàn ASCII, các giả định về mã hóa ký tự trong mã không được thực hiện. Hoặc có thể nó luôn ở dưới một kích thước nhất định, do đó, trường hoặc bộ đệm có kích thước cố định không bị ảnh hưởng. Hoặc có thể có những ký tự đặc biệt được diễn giải theo những cách đáng ngạc nhiên cho thấy đầu vào của người dùng đang được đưa vào trình bao hoặc được sử dụng để xây dựng truy vấn theo cách không an toàn. Hoặc có thể chỉ có quá nhiều thử nghiệm "con đường hạnh phúc" và không đủ nỗ lực để thực hiện xử lý lỗi.

Fuzzing không có định kiến ​​như vậy về đầu vào. Nó sẽ thực hiện một cách tàn nhẫn hệ thống của bạn với bất kỳ sự kết hợp có thể nào của đầu vào "hợp lệ". Unicode, ASCII, lớn, nhỏ, và rất nhiều lỗi. Hệ thống của bạn sẽ đáp ứng duyên dáng cho tất cả chúng. Nó sẽ không bao giờ sụp đổ. Người dùng phải luôn luôn nhận được một số thông điệp hợp lý về những gì đã sai và cách khắc phục nó. Đó không phải là Rác vào / Rác ra, đó là Rác vào / Lỗi ra .

Mặc dù người ta có thể loại bỏ các vụ nổ kết quả vì "không có người dùng thực sự sẽ làm điều đó", nhưng điều đó làm mất điểm của bài tập. Fuzzing là một cách rẻ tiền để loại bỏ sự thiên vị của bạn về các đầu vào có thể. Đó là một cách rẻ tiền để ném tất cả những điều kỳ lạ mà người dùng sẽ cố gắng thực hiện vào hệ thống của bạn. Là kỹ sư, công việc của bạn đảm bảo hệ thống của bạn thất bại một cách duyên dáng.

Hơn nữa, "đầu vào" mờ không chỉ là về người dùng. Nó có thể là kết quả của một truy vấn API đến dịch vụ của bên thứ 3, nếu điều đó bắt đầu gửi kết quả sai thì sao? Làm thế nào để hệ thống của bạn đối phó với điều đó? Một hệ thống phù hợp sẽ cảnh báo cho quản trị viên rằng một thành phần đã bị hỏng. Một hệ thống không phù hợp sẽ lặng lẽ từ chối truy vấn xấu, hoặc tệ hơn, chấp nhận nó là dữ liệu tốt.

Cuối cùng, một số người dùng là độc hại. Nếu bạn không kiểm tra hệ thống của mình, người khác sẽ làm. Họ sẽ thăm dò các cạnh của hệ thống của bạn cho các lỗi phổ biến và cố gắng sử dụng chúng làm lỗ hổng bảo mật. Thử nghiệm Fuzz có thể mô phỏng điều này, ở một mức độ nào đó, và bạn có thể đối phó với bất kỳ lỗ hổng bảo mật nào có thể được phát hiện trước khi chúng trở thành vấn đề.

Nếu mục đích của bạn là tạo ra một sản phẩm chất lượng thì hãy kiểm tra mọi loại đầu vào có thể mà người dùng sẽ có thể gửi. Mặt khác, bạn chỉ chờ đợi một ngày khi ai đó gửi một loại đầu vào mà bạn không cảm thấy cần thử nghiệm.

Trong một cuộc biểu tình lớn về phần mềm đấu giá điện tử mới tại một cơ quan địa phương nơi tôi làm việc, người quản lý của tôi đã quyết định (thừa nhận với một số trò tinh quái) rằng anh ta cảm thấy cần phải xem điều gì đã xảy ra nếu anh ta đặt giá thầu đấu giá có giá trị âm. Thật ngạc nhiên, phần mềm đấu giá cho phép đấu thầu vô nghĩa này và toàn bộ quá trình đấu giá bị đình trệ. Loại đấu giá đang được chứng minh không bao giờ nên cho phép số tiền âm được gửi.

Một số nhóm lớn các nhân viên tài chính và mua sắm lắp ráp đã cảm thấy khó chịu với người quản lý của tôi vì đã gửi một giá trị vô nghĩa. Nhưng những người khác, bao gồm cả tôi, đã cảm thấy khó chịu với các nhà phát triển phần mềm vì đã không kiểm tra và từ chối một loại đầu vào không hợp lệ rõ ràng như vậy. Tôi chỉ có thể tưởng tượng phần mềm phải yếu như thế nào khi làm chệch hướng các loại đầu vào không hợp lệ khác (các nỗ lực tiêm mã, các ký tự kỳ lạ không thể biểu thị trong bảng cơ sở dữ liệu, v.v.).

Theo tôi, tôi đã trả lại phần mềm và cho rằng nó không phù hợp với mục đích. Sự khác biệt giữa một sản phẩm phần mềm yếu và mạnh là mức độ thử nghiệm mà nó phải chịu.

Ví dụ: Trong khi thực hiện kiểm tra chức năng của một biểu mẫu trong ứng dụng web, chúng tôi sẽ kiểm tra các trường bằng cách nhập các loại giá trị đầu vào ngẫu nhiên khác nhau.

Đúng. Đây là một loại thử nghiệm nhưng nó không phải là thử nghiệm chức năng . Đây là những gì được gọi là thử nghiệm căng thẳng . Đó là hành động gây áp lực lên một hệ thống để xem liệu nó có thể xử lý nó hay không.

Vì vậy, việc sử dụng kết hợp tất cả các testcase có thể / có thể không dẫn đến lỗi là gì, khi xác suất xuất hiện các loại vấn đề này trong sản xuất là cách ít hơn?

Khi bạn đang căng thẳng kiểm tra phần mềm, bạn đang cố gắng khám phá ranh giới của giới hạn của phần mềm.

Các bài kiểm tra là một cách toàn diện của tự nhiên. Nơi bạn cần khám phá giới hạn sử dụng, điểm dừng, kiểm tra tất cả các nhánh logic hoặc xem các lỗi một phần ảnh hưởng đến toàn bộ hệ thống.

Bạn có thể vượt qua tất cả các bài kiểm tra chức năng của mình, nhưng vẫn thất bại trong việc kiểm tra căng thẳng .

Tôi chỉ hỏi câu hỏi này để biết liệu có bất kỳ thực hành tiêu chuẩn nào được thực hiện hay không hoàn toàn phụ thuộc vào sản phẩm, tên miền và tất cả các yếu tố khác.

Vâng, đây là một thực hành tiêu chuẩn.

Phần mềm kiểm tra là về việc đặt câu hỏi về hành vi dự kiến và khi tất cả các bài kiểm tra vượt qua, phần mềm này hoạt động như dự định. Đây là lý do tại sao các bài kiểm tra tạo điều kiện tiên quyết tốt cho việc triển khai các bản cập nhật.

Kiểm tra căng thẳng không cung cấp các chỉ số vượt qua hoặc thất bại cụ thể rõ ràng. Kết quả có nhiều thông tin hơn. Nó cho bạn biết những gì hệ thống của bạn có thể xử lý và bạn đưa ra quyết định từ thông tin đó.

Bạn có thể xác định các mục tiêu cụ thể để kiểm tra căng thẳng phải được thông qua để tiếp tục giai đoạn phát triển tiếp theo. Chúng có thể được đưa vào như một phần của quy trình đảm bảo chất lượng của bạn, nhưng những thay đổi trong môi trường có thể thay đổi kết quả của một bài kiểm tra căng thẳng. Vì vậy, mọi người chạy các bài kiểm tra căng thẳng vào các thời điểm khác nhau để xem hệ thống xử lý các điều kiện thay đổi như thế nào.

Ý tôi là bạn không thể chạy kiểm tra căng thẳng mỗi khi bạn triển khai phiên bản mới của phần mềm và cho rằng điều này có nghĩa là mọi thứ sẽ vượt qua kiểm tra căng thẳng sau này.