软件测试Web测试经验

软件测试Web测试经验   Web测试工具

这个测试项目记录了包括重复在内的：200个偏差。大约有150个偏差报告给了开发人员，其中65个被接受，剩下的偏差不得不推迟到“下一个版本”，因此系统必须变成功能有限的产品——推迟了3个月。因此项目小组把测试看作是成功的。我们没让一个有太多“故障”的系统变成产品而把问题留给客户。

    我们在前面提到的类比意思是说每个人在某个时候或其他时候都用过某种形式的探索性或双人组技术。但是要把事情做对需要一定的技巧。那么它需要什么技巧?我们获得了什么样的有用经验呢?

    有些人会说什么也没有，他们会争辩说这个项目太小了，而且太“紧迫”。我们很少有时间为双人组做准备。我们并没有一个定义好的、能衡量覆盖率的方法。我们把探索性技术当作一条“出路”，因为我们并没有足够的信息来用传统的测试脚本a因此从这个项目中并不能够得出结论。

    其他一些人说我们确实学到了很多：探索性测试、双人测试和管理高速的缺乏文档的Web项目。很不幸，这种情况出现得比较频繁，因为上市时间是所有客户都关心的问题。这也是我们第一次尝试测试的一种概念，在这个测试中，双人组和探索性技术被“正式化，’了，不仅仅是项目的附属，或临时的测试方法。在很多方面它给予我们的比我们想要的还要多。

    就像James Bach陈述的那样，在进行探索性测试的时候，测试人员需要提前进行探索性测试的。r培训”。幸运的是，我们的测试人员在测试之前就已经完成了为期两天的学习指导课程。为了确保尽可能全面，在第一天我们还或多或少地进行了正式的功能性测试。这不仅使测试人员对软件有了更好的理解，而且还向他们指出了系统中错误可能发生的地方。这是很重要的，因为探索性测试就是使用您所知道的东西。确实会出现的一个问题是当在软件的一小部分中发现错误的时候，所有的双人组都开始检查那个部分。由于双人组没有进行过探索性测试的培训，因此我们需要在不同的方向上指引他们以提高测试的覆盖率。也许在计划阶段就应该考虑到这个问题。

    同事提出了许多问题，他们不知道我们如何控制这样一个非结构化的测试。在发现“故障”的时候，我们如何保证填写了偏差报告?如何能知道测试人员是否坚持了测试计划?如何确保他们是完全具有工作能力的?我们是否会不断地在房间里转来转去?我们不是在一个房间里转，而是在三个不同的房间里“跑”(因为我们把Windows 95、2000和NT放在不同的房间里了)。困难的事情不是让测试人员进行测试，而是让他们不要测试计划以外的内容。当我们在几个房间里穿梭的时候，我们脑子里会得到一幅测试人员工作的画面(只有14个人，因此并不那么令人疲惫不堪)。只要我们看到有一组没有在计划区域内工作或是出现了别人已经报告过的错误，我们一般会给他们一些小的暗示。比如“您试过这个了吗”或“如果您那样做会发生什么?”为了使每个人都不脱离。r正轨”，我们这样做就可以了。在分组工作时，其中一个测试人员总是负责填写偏差报表。这是一个很容易填写的表，但是使故障重现已经足够了。在每

个暂停阶段(在每次90分钟的测试后)，如果可能的话我们与项目经理一起通读所有的. 报告，以确保我们理解所记录的东西以及确保我们有足够的信息来重现故障。此外在每个暂停阶段，我们常与所有人交流并且一天三次地把所有人聚集到一个房间里

原文转自：http://www.ltesting.net