testing - UI（文本框的最大长度）上的“边界条件测试”是个好主意吗？

Question

我知道边界条件测试在软件测试中是一件好事。但在我看来，我认为用边界条件测试来测试文本框的最大长度并不是一个好主意。

例如，我有一个将限制设置为 10 个字符的文本框。是否有必要使用以下所有测试进行测试？

1. 输入一个 5 字符的文本并期望它会通过。
2. 输入 10 个字符的文本并期望测试通过。
3. 输入一个 11 字符的文本，并期望他们不能这样做。

我试图搜索有关在 UI 上应用边界条件测试的信息，但我发现的信息很少。

Answer 1

You're missing a technique called Equivalence Class Partitioning. Let's take your example. There are a few different EC's you could use to evaluate the limit on a text field. Here's a table:

    +------------+------------------+-------------------+-------------------+
    | Factor:    | Factor:          | Risk:             | Risk:             |
    | Size       | Characters       | Downstream        | Upstream          |
    |            |                  |                   |                   |
    +-----------------------------------------------------------------------+
    | 0          | A-Z              | Are there any     | Ditto.            |
    | 1          | a-z              | things that are   | Is there anything |
    | >1         | Any UTF-8        | affected down-    | affected by your  |
    | 10         | Any UTF-16       | stream? Does      | input after the   |
    | >10        | etc.             | any of the other  | fact? For instance|
    |            |                  | conditions cause  | a login form might|
    |            |                  | problems for      | have a "Name"     |
    |            |                  | other functions?  | with a length of  |
    |            |                  |                   | 9 somewhere else  |
    |            |                  |                   | in the application|
    |            |                  |                   |                   |
    +------------+------------------+-------------------+-------------------

Based on this table, you can try variations of the input (from more than just BVA) and see what makes sense. Look at the risks and see if anything you did had an effect upstream or downstream in the application.

Now, if you get to a point where the combinations are too many, use another technique called All-pairs testing. This will limit the combinations you have.

At the end of the day, its not about exhaustive testing, its about making sure the risks are properly explored and tested appropriately.

Here's a little 3 minute video which is also a good resource and elaborates on the fact that BVA and EC go hand-in-hand.

To answer your specific question:

Is “boundary condition testing” on UI (TextBox's max length) a good idea? Is it necessary to test with all below tests?

Yes. Those are some pretty basic boundaries, although you're missing 2 cases IMO:

• Null case: does it matter if the field is null?
• 0 case: is 0 significant? Zero can mean the numeric "0", or it could mean passing in characters that aren't really there from an end-user perspective; for instance, using spaces. Zero is different than null, since you can pass in spaces, etc into a field too. Maybe you can pass in 11 spaces and your application is happy? I don't know, but it is a boundary worth exploring.

Based on what your application does, you'll need to evaluate other risk factors and come up with tests associated with those risks.