对于文档中没有明确描述的特性，该如何定义预期结果？
今天有同事提到一种情况：对于一个查询，如果没有任何文档对当所有查询条件取值为空时，是该提示用户输入条件，还是该查询到所有的记录做出描述，那么在执行测试时，一旦出现了其中的一种，该如何判断实际结果同预期结果是否一致？同时，这位同事也提出了她自己的一种看法：类似于这种测试，因为用户并没有明确的预期，所以可以把预期结果作为一个集合来处理，例如上面两种情况都表示系统对输入做出了处理，而没有抛出异常或者出现严重的缺陷，并且根据常识来说，这两种情况都使可以接收的。那么当出现其中的一种时，都可以认为是通过了。
最终讨论的结果，明确这种情况作为与设计或实现有关的特性，是应该被明确定义并被测试明确验证的，因为这是测试人员的职责所在。但是，上面的这个例子作为一个特例，在特定的情况下，把预期结果作为一个结果集来处理的方法也是可以接受的。
原文出处：http://www.cnblogs.com/jackei/archive/2005/05/27/163743.html
欢迎大家一起讨论。 楼主说的情况比较特殊，说说我个人的看法，SPec不可能写的面面俱到，细节是魔鬼。那有人会问，对于没有提到的细节应该如何做测试，标准是什么？我想这个大家可以参考市场上同类产品的做法，如登陆页面，一定要有忘记密码如何处理的功能。但是取回密码怎么取，可以是让用户输入用户名，密码提示问题和答案，炎症后直接给出或者通过注册的邮件发送等。
我个人认为，在Spec没有说明白或者说到的地方，软件测试人员应该自己明确这个功能应该是什么样，其实和楼主的观点差不多，只是尽量不要做一个集合，这样的选择太大。测试人员觉得可以接受就ok了，否则就说出你的理由，报Bug。
听棠.NET 朋友在我Blog的留言，放过来大家一起讨论
其实楼主说的，是在纯逻辑思想上的，这也是软件开发人员所惯用的思维方式，可以相信，在逻辑上你的情况都是正确的。但我们要明白一点，系统不是为程序们员开发的，而是给客户用的，因此，至于在绝大部分情况下应该是什么，客户最清楚，如果没有客户支持，那么设计员要尽可能站在客户的角度去想象情况，这就是设计员所要考虑的问题，而不是程序员们在考虑的问题。
因此，你的问题，应该从业务的实际情况去思考，如果从纯技术角度考虑，是得不出结果的。 不错，应该从业务的实际情况去思考！ 我觉得这种情况下就应该考虑软件的用途是什么?面向的广大客户是哪类?根据软件要实现的具体功能以及实际的业务知识等多方面来定义这个预期结果.
希望能和大家一起探讨!sdlkfj5 sdlkfj7 楼主 我也有同感 sdlkfj2 是的，这种情况下，只有站在客户的角度去思考sdlkfj5
回复 #1 jackei 的帖子
这种情况我觉得最好的办法是跟客户沟通，看他们的需求。 sdlkfj8 sdlkfj8补充下
跟客户沟通是需要的,但是客户就一定能知道自己确切的需求吗?当客户也搞不清楚他所要的需求时,我们就要先自己从各个方面去替客户考虑,考虑他们的实际需求和隐含需求,尽可能的完善需求,并且整理成文档.然后再和客户去沟通,沟通一个双方确认的结果. sdlkfj4 看起来好难·～～学习了。 sdlkfj3 ganxuie
回复 #1 jackei 的帖子
非常受用，谢谢楼主
页:
[1]
