写黑盒测试的黑盒三角形代码，最怕的测试不是逻辑复杂，而是角形边界值全漏。我见过一个团队，代码测试用例写了三十多条，黑盒上线第二天就被人用“1 2 3”干翻了——程序返回“等边三角形”。测试这玩意儿连小学生都知道不可能，角形代码里却堂而皇之跑通了。代码问题出在哪？黑盒他们只盯着“有效等价类”打转，忘了黑盒测试的测试本质是拿输入去撞输出，而不是角形拿输入去猜代码。

三角形的代码判定规则其实就三条：任意两边之和大于第三边；三条边都大于零；然后才是等边、等腰、黑盒普通的测试分支。很多教程把这三条拆成七八个条件，角形反而把简单事情搞复杂了。我习惯先写一个最粗暴的版本：读三个数，先判非正数直接返回“非三角形”，再判两边之和，最后才进类型判断。这样写出来的代码，分支覆盖和条件覆盖能同时达标，不用刻意凑。

但黑盒测试不管你怎么写代码。你给它三个数，它只看输出对不对。所以设计用例的时候，得把“输入空间”切成几块。有效那块里，等边是(3,3,3)，等腰是(3,3,4)，普通是(3,4,5)。无效那块就热闹了：有零、有负数、两边之和等于第三边、两边之和小于第三边。我通常会再加一组“看起来像但实际不是”的，比如(1,2,3)——1+2=3，刚好卡在边界上，很多程序会误判成三角形。

有个细节容易被忽略：输入顺序。你把(3,4,5)换成(5,3,4)，输出应该一样。但有些代码里用了排序，有些没用，结果在边界值上就露馅了。我见过一个实现，判断等腰时只比较了前两条边，输入(3,4,3)就返回“普通三角形”。这种bug用黑盒测试一抓一个准，因为你不看代码，只喂数据，它自己就现原形了。

再说个真实案例。之前帮人review一套测试用例，发现他们把所有“非三角形”的用例都归成一类，只验了返回字符串包含“非”字。结果程序对(0,0,0)返回“非三角形”，对(-1,-1,-1)也返回“非三角形”，看起来没问题。但把(0,0,0)换成(0,1,1)，程序返回“等腰三角形”——因为0+1>1不成立，但代码里先判了等腰再判合法性。这种顺序错误，只有把无效输入拆开测才能发现。

黑盒测试三角形代码，说穿了就是拿边界值当锤子，一下一下敲。等边、等腰、普通各来一组，零、负数、两边之和等于第三边各来一组，再加几组乱序和重复值。用例不用多，十五到二十条足够覆盖所有分支。关键是每条用例都要有明确的预期输出，不能写“应该不是三角形”这种模糊话。要么是“非三角形”，要么是“等腰三角形”，二选一，没有中间地带。

最后提一句，别迷信自动化。三角形代码太简单，写个脚本跑几百条随机数，不如手工设计十条边界值来得实在。随机数撞上边界概率极低，而bug偏偏就藏在那些“差一点”的地方。我自己的习惯是：先手写用例，跑通了再考虑要不要脚本化。顺序反了，容易把测试做成表演。