云层 发表于 2004-8-30 15:04:01

测试人员面临的10大“人际“挑战

10 获得软件测试培训
9 与开发人员保持良好关系
8 无测试工具
7 使管理人员了解测试
6 与客户保持交流
5 分配测试时间
4 测试“仍过墙“的软件
3 满足不断变化的需求
2 解决两难问题
1 学会如何说不

zz 《软件测试求生法则》 清华大学出版社

瓦上阳光 发表于 2004-8-30 15:16:30

8和 10都是我面前最深有体会的挑战!

yi3310 发表于 2004-8-30 16:35:48

测试有和客户交流的机会吗?
我怎么觉得好象很少,反正我现在还没有机会和客户交流的!

Fuli 发表于 2004-8-30 17:14:07

8和10需要解决!

钟花花 发表于 2004-8-30 19:15:03

谁给解释解释下面两点

4 测试“仍过墙“的软件
   什么是仍过墙?
2 解决两难问题
   哪两难?

archonwang 发表于 2004-8-30 22:53:11

几乎都碰到过。尽量自己想办法解决。实在不行,只好走人。唉~~

lesley 发表于 2004-8-31 08:53:31

789体会很深啊!

东方一华 发表于 2004-8-31 11:17:51

3.5是需要注意的地方

云层 发表于 2004-8-31 13:43:33

4 测试“仍过墙“的软件
   什么是仍过墙?
一般公司开发人员和测试人员是相对独立的,作为工作,开发人员将版本发给测试人员,测试人员完成测试后将报告发给开发人员。
这种直接将各自“成果“抛来抛去的做法简称“仍过墙“。

2 解决两难问题
   哪两难?
一方面开发人员要保证进度,另外一方面做为测试人员要保证质量,怎么在其中找到一个平衡点,是非常困难的,在这两难中如何平衡,如何解决呢?

原文稍做修改

wangnan 发表于 2004-8-31 14:09:43

任何的问题,都需要沟通这个解决因素;
而所有的沟通都需要建立在真诚、信任、理解的基础上;
当面对责任互分,利益互斥时
当然难以解决,所以最好的方法
是如何将互斥转为互利,这将是个永久的问题!

云层 发表于 2004-8-31 14:43:29

测试“仍过墙“的软件

抱歉这里打错了一个字,应该是测试“扔过墙"的软件

迷茫中... 发表于 2004-8-31 15:01:51

我对3真的是好头疼

hxf 发表于 2004-8-31 17:25:25

我对3很有感触,并且,不断的变化,我还不知道,这样对测试人员来说,更是一个挑战。

云层 发表于 2004-9-1 10:28:32

有关
挑战10和挑战9的培训ppt

wghong 发表于 2004-9-1 11:29:54

对3 真的很头痛。还有5,测试时间测试进度的安排,真的不容易~~

with_moon 发表于 2004-9-2 09:13:00

做测试难,做个好测试员难上加难

云层 发表于 2004-9-2 09:24:37

如果不难,怎么能够体现我们的价值呢?

BS-Phoenix 发表于 2004-9-2 15:57:26

将时间和质量尽量完美的结合,这是不是软件开发的根本呢?

jacky 发表于 2004-9-3 09:43:22

转一篇关于3的文章,作者是谁不记得了,:P

如何在软件频繁改变时测试?
    就像一句古老的谚语中说得:“唯一不变的是改变”。
    在软件开发模型中,曾被认为最优秀的瀑布模型的一个缺陷就是假定很少或者没有改变,而现实世界是每天都在改变的。也因为如此,其他的开发模型比如“快速应用开发(Rapid Application Development,RAD)”逐渐发展成可以接收改变,并通过计划好的迭代过程利用这些改变来改进软件的开发模型。
    虽然RAD可以帮助软件开发人员加快开发的速度,但是却也让测试人员非常头痛。因为每一次改变都有可能产生新的缺陷,而要想找到新的缺陷只有一个办法——进行全面的回归测试——对所有原来已经测试通过的部分再次测试,对返回值进行比较并找出不同的地方。

    这里有两个问题需要注意:

    1)在软件频繁改变的时候,可能进行全面测试吗?

    实际上这是不可能的。不过,这个问题本身就有问题^_^,因为很多时候甚至都不可能在一个完全稳定的环境中测试软件。这个问题其实是想问:“在软件频繁变化的时候,能否进行有效的测试?”我们能否期望通过更好的使用人力和其他资源来完成这种测试?我们能否找到所期望的那么多缺陷?
    通过对使用RAD方法的项目的观察,我发现软件测试过程对于发现缺陷是非常重要的,不同的过程会表现出不同的效果。因为大多数时候我们的开发过程都不是简单的重复,所以在RAD环境中就不能象其他环境那样——尝试着用各种方法到处看看能不能找到一些缺陷。

    2)在软件频繁改变的时候,有哪些策略可以使用?

    应该花些时间学习怎样在不同的环境下开展工作,不过在软件频繁改变的时候有些一般的策略还是可以参考的。
    .首先,你必须接受这个事实——你不可能有6周的时间对一个每天都在变化的软件进行测试——或者说你的老板不会允许你在每次软件改变后都用这么长的周期来进行测试。唯一的办法是你要定义一个可以快速有效的完成测试任务的过程。
    .进行风险评估。能够区分不同测试对象的风险级别是非常重要的,因为这样你就可以通过对不同的测试对象排列优先级,在那些很简单的问题上只花费较少的时间,而对更高的风险则给予更高的优先级和更多的时间以及其他资源。
    .必须有一个确定的工作版本(基线版本),以便于你在将来进行测试的时候可以进行比较。
    .自动化测试。使用捕捉/回放工具可以借助一些自动化特性帮助你来对软件进行回归测试。应该考虑花些时间和资金把一些工具融入到你的团队中,让大家都学会如何使用这些工具会对你的工作有所帮助。对于一个不愿引入新技术的组织——比如自动化测试工具——是很难在软件频繁改变期间完成测试的。这就像盖一座房子,手头上必须要有些合适的工具才行。
    .自动化工具只能对你的操作进行记录和回放,这是不够的。你必须明确业务需求,设计测试用例和测试过程,制定测试计划。另外,如果人们想在长期工作过程中获得比短期工作更多的好处,就需要考虑测试用例和测试脚本。

    在软件频繁改变的时候进行测试不是不可能的,但是需要快速的响应、努力工作和维护对改变的跟踪。
    在软件频繁改变时进行测试同样需要一个有创新思维的团队和过程,工具自己不会工作,只有在工作中由最优秀的人员在合适的时机使用才会产生最好的效果。使工具、人员和过程达到一个最理想的结合是一件非常有挑战性的事情。

云层 发表于 2004-9-3 20:30:29

我也记得看过楼上的这篇文章,不过忘了那里看到的了
页: [1] 2 3 4 5 6
查看完整版本: 测试人员面临的10大“人际“挑战