第13贴【2004－5－22】：什么是测试需求？
Brian Marick
测试需求的概念比较简单。例如，比方说一个计算平方根的程序，如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数，程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求。
在一个更加复杂的程序中，你可以将打算测试的项目做成一个列表。但是，这些测试需求都不会确定具体的测试数据。例如，一个银行交易程序，一个测试需求是试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在，等等。你有一系列这样的测试需求，它们并没有指出具体的数值或数据，如客户的姓名。
测试的下一步是选择满足这些测试需求的输入值/测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求，当然是最理想的情况，但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降。
这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求：
1）插入一个新的条目
2）插入失败－条目已经存在
3）插入失败－表已满
4）哈希表在插入前为空
这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。
这应该只是对测试需求的一个方面的理解
测试需求应该包含两个方面的内容：
1、确定测什么，就是上面这位仁兄所说。
2、测试对产品的需求，解决需要产品为测试提供什么特性，可以更好的去测试的问题，就是我们常说的可测试性需求。
第14贴【2004－5－30】：GUI测试
Roger S. Pressman
图形用户界面（GUI）对软件测试提出了有趣的挑战，因为GUI开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时，GUI的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在GUI设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见GUI测试的指南：
窗口：
·窗口是否基于相关的输入和菜单命令适当地打开？
·窗口能否改变大小、移动和滚动？
·窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
·当被覆盖并重新调用后，窗口能否正确地再生？
·需要时能否使用所有窗口相关的功能？
·所有窗口相关的功能是可操作的吗？
·是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？
·显示多个窗口时，窗口的名称是否被适当地表示？
·活动窗口是否被适当地加亮？
·如果使用多任务，是否所有的窗口被实时更新？
·多次或不正确按鼠标是否会导致无法预料的副作用？
·窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
·窗口是否正确地被关闭？
文章来源于领测软件测试网 https://www.ltesting.net/