软件测试设计 测试用例设计
测试设计是一个很大的课题，测试阶段、测试方法、测试类型、甚至软件类型、性质，以及用户群的不同，其测试设计方法也不同。在此文档中只总结集成测试中功能测试的黑盒测试的设计。针对我们正在测试的指标管理软件，如此也就进一步固定了软件类型、性质，以及用户群，也更有利于阐述测试设计的方法。
就是如此狭义上的测试设计也有许多的设计方法，其中包括用例分析法、逐步精细法、数据驱动法、功能分解组合法等。本文档只总结被广泛接受的RUP内的用例分析法。
测试设计的几个原则
不要测试非常简单的事情
一般来说，对被测试程序的每一个（公共）功能，你都需要有一个测试用例涉及到它。但是对于一些显然不可能出错的地方，设计测试用例几乎没有意义。譬如窗口的关闭，一方面它们实现的功能非常直截了当，另一方面每个人测试时都在不断关闭窗口。当然，如果这些窗口关闭不是非常的直截了当，对它们的操作会触发其他一系列工作，例如分情形打开不同的窗口等，你可能需要为它设计测试用例。
为这些简单、直接、繁琐的功能设计测试用例，不能提高软件质量，同样对增进测试也没有好处。相反，它可能使得测试设计人员厌倦这样的测试设计，测试人员也会丧失对于测试的信心。
测试任何可能出错的地方
XP 的测试原则之一说：“测试任何可能出错的地方”
可能做到吗?更何况80/20规则告诉我们80%的利益来自于20%的活动，为每一种行为的组合写上一个测试不但不可能，同时也是没有实际意义的。
但在很多次读到这样的规则或声明之后，自然就逐渐意识到这句话所含的深意，这一条规则其实想告诉我们不要测试什么！！测试所有可能出错的地方也就是告诉我们不要测试不可能出错的地方，正如前面所说：不要测试非常简单的事情。
这条规则相当容易引起误会。
我们知道要完全达到100%测试是不可能的，0-BUG只是一个理想。况且，对软件不进行充分测试就是犯罪，同样，过分的测试也是一种严重的浪费行为。既然知道不可能，所以问题发生的时候我们并没有太大的压力。
那么什么是这条规则真正要告诉我们的东西呢?
程序功能越复杂，要完全测试它的难度就越大。相反，程序功能越简单，完全测试(我们心目中的理想)它的可能性就越大。
可以得出结论：这条规则告诉我们，应当让程序功能尽可能简单，尽可能容易理解，因此也就更加容易测试，更加不会出错。
反馈到测试设计就是说，当你觉得完全不可能做到这条规则时，你应该考虑当前程序实现的程序功能是否太复杂了，是否包含了太多的责任和状态。是否将多个功能生硬地杂糅到了一起。你也许会建议程序设计人员把这个设计好的功能分为2 个甚至3个功能，让他们更容易测试。也许你会得出更简化实现功能所必须步骤的复杂程度的方法，并建议程序设计人员简化实现功能的步骤；当用户不得不每次按照同样的顺序来完成一个功能，而这些步骤的单独部分没有被其它功能使用，我们也许就应该建议程序设计人员合并这些步骤，以更方便用户的理解以及操作，同时也更避免了出错的可能性，因为程序对于用户封闭的越多，由于用户的误操作引发的错误就越少。从这一点来说，测试促发了程序的合理的设计变更。
测试边界条件
这些地方属于传统的测试角落。对于边界条件，你必须保证考虑到了所有可能出错的地方。集合是否为空？第一个？最后一个？诸如此类的问题必须小心考虑。对于这些边界条件的确定和测试用例编写， 如：
未初始化：程序的参数没有初始化，最好解决方法是要求程序员在定义每个参数都先赋予一个明显没有意义的错误的数据，如此在错误发生的时候，测试立刻可以判断出此处有错误，而不是一个似是而非的数据，例如界面上显示数学成绩的结果为w w，我们立刻可以判断错误出现了，而看到结果为65，但实际上应该85，我估计就很难判断了。此处临时举了一个不恰当例子，本意是能说明问题就好。如果以上不能做到，没有办法，只能是认真详尽检查，同时要求测试设计时也得仔细设计能够让问题发生的用例。
文章来源于领测软件测试网 https://www.ltesting.net/