关于测试基准点的设置

[gdkevin]

在测试过程中，大家很容易遇到这样的问题
如果寄希望于通过测试脚本来完成测试，那么你就需要取得许多的标准信息，譬如说正确的返回结果（这个也是xp编成所崇尚的），那么这个期望值是什么呢？经常的改动会导致测试脚本的失效，维护测试脚本成了一件非常巨大的任务（一般情况下录制的脚本都很长）
这样必将导致测试人员无心去维护脚本，如果项目周期较短的话，还真不如手动测试来得快。
欢迎大家来讨论，嘿嘿
gdkevin([e-mail])

[xiterator]

我也是刚刚学习一些测试的内容，不当之处请指正。

标准信息：可以从软件需求、软件设计中获得，如：某一功能的执行结果（要求该需求是可测试的原因之一），用户性能需求（for 性能测试)等。

测试脚本：就黑盒测试而言，是对待开发软件的需求的功态验证，本身就是一个软件设计问题，测试脚本做为一个程序应考虑如何适应待开发软件的变化，就像OO一样应封装变化，一种方法是将一个end to end的脚本分隔成多个子脚本，将可能的变化约束在部分的子脚本中，在总体上通过scenario来组织。

[sunshy]

>>一种方法是将一个end to end的脚本分隔成多个子脚本，将可能的变化约束在部分的子脚本中，在总体上通过scenario来组织。

楼上的这个方法比较适用
而且这样也可以是脚本运行趋于独立化，减少前后干扰。

[davy_chen]

前面提到的将脚本分段的方法确实对于脚本顺利运行和修改很有效，不过我想gdkevin (小丹尼)其实真正想知道的是如何实现自动判断脚本运行的程序运行的是否正确。我有两个观点供参考：
1、不是所有的项目用工具都是好的，所以如果项目周期很短确实可以考虑直接手动测试，而不采用工具。或者仅用工具做一部分的工作；
2、对于运行的验证，实际上确实有很大的局限性，仅通过需求往往是不行的，不仅是因为需求经常达不到测试需要的详细程度要求，而且即使真的已经写的很好也不会覆盖程序的所有特性，加上需求是可能变化的，所以都会导致验证部分脚本的更改。就我的实际做法是屏幕截图。如果我们是手工测试，我们如何判断程序运行的正确与否，实际上是看运行后的屏幕输出或声音等，其中主要的是屏幕输出。因此我们只要在想知道当时屏幕上显示的是什么的时候增加上抓屏语句，然后测试脚本运行完成后，我们到指定的存储图片的路径处看一下所截图片就可以知道是否出现了问题，虽然此方法看起来没能达到完全的自动化，但却是一种简单而且行之有效的方法。

简单描述设计思想：
我做了一个抓屏的函数，这样当我需要抓屏的时候直接调用函数就可以了，函数实现的功能是判断指定存放图片的目录是否存在，如果不存在则建立，抓屏，为了避免被保存的图片出现同名现象，因此自动按照系统时间命名。
这种方式尤其对于概率性出现的问题的验证很有效，例如100次操作中出现3次的错误等。这种方法也同样适用于一些难以验证的地方，例如界面/图片/LOGO等的显示（虽然很多自动测试软件可以完成对于图片是否变动的检测，但实际效果不是很好，经常出现图片虽然没有变化，但是工具比较的结果是不同的。）建议还是自己体会一下吧。

[ldkk]

需求不稳定时或者测试前期，建议采用手工测试，同时做好测试用例，为测试自动化做准备。后期可以针对测试用例利用工具将执行自动化，但注意要选择结果好验证的，复杂结果的验证我想还得靠人工。

[dragonchen2002]

学习，up