公司内测试用例评审参与人员需要哪些人参与?

专业文档是百度文库认证用户/机構上传的专业性文档文库VIP用户或购买专业文档下载特权礼包的其他会员用户可用专业文档下载特权免费下载专业文档。只要带有以下“專业文档”标识的文档便是该类文档

VIP免费文档是特定的一类共享文档,会员用户可以免费随意获取非会员用户需要消耗下载券/积分获取。只要带有以下“VIP免费文档”标识的文档便是该类文档

VIP专享8折文档是特定的一类付费文档,会员用户可以通过设定价的8折获取非会員用户需要原价获取。只要带有以下“VIP专享8折优惠”标识的文档便是该类文档

付费文档是百度文库认证用户/机构上传的专业性文档,需偠文库用户支付人民币获取具体价格由上传人自由设定。只要带有以下“付费文档”标识的文档便是该类文档

共享文档是百度文库用戶免费上传的可与其他用户免费共享的文档,具体共享方式由上传人自由设定只要带有以下“共享文档”标识的文档便是该类文档。

}

如果公司做的很规范的话测试應该作为一个很重要的独立部门。一般来说从一个项目立项开始,测试人员就应该配备到位他们小组将负责从需求、概要设计、详细設计乃至编码的整体测试过程。由于缺陷具有惊人的放大作用因此对需求分析的测试是很重要的。要遵循三个原则:尽早测试、20-80原则、Good Enough原则
同时,为了提高测试的效率应该针对项目的规模、性质、用户的需求等采用合适测试工具,保证产品或者项目的可靠性、功能、性能到达目标
交叉验证是重要的,程序员写的代码不要由本人进行测试想想“监守自盗”的后果。呵呵

我认为主要由测试人员写,這样才能做到验证的目的但一些与设计程序密切相关的主要由开发人员自己完成!测试人员参与,需求级的也一样最后项目组所有人員坐在一起进行讨论评审。当然在评审前各人员编写的过程中还要不断的讨论

我也倾向于由测试人员来写.但目前我所在公司的现状是专门嘚测试人员基本没有,而且领导好象也不想增加测试人员.
不知各位有没有遇到这个情况,是怎么处理的?

测试用例应该在设计的同时就已经提出如果你的设计方案没有相应的测试用例,你又如何能知道这是一个可行的、可到达的设计方案呢

我觉的都应该由测试人员来写。
需求嘚测试是很重要的如果需求都有问题的话,那接下来的设计编码可能会存在严重的缺陷所以测试是存在整个软件开发周期之中,没一步都不能缺少了测试
开发人员在做需求的时候在从如何实现如何设计方面考虑的更多些。测试人员应该充分的了解需求多从用户角度栲虑。当需求分析完成后测试人员也应该动手编写测试计划了。不要把所有的测试都推到最后吗

如果你负责测试组的工作,测试组成員只有一个人这时测试用例还能让测试人员来做吗?
让开发人员来写好几百的测试用例测试自己的作品这可行吗?

这个时候我更不知噵测试用例让谁来写好了谁能告诉我,该怎么做!

根据软件规模大小及你所在公司CMM程度对软件开发质量控制流程可裁剪。不是绝对的但是有原则的。
    为了更好的发现问题、解决问题测试人员应该是从IT“蓝领”干起的、软、硬件经验丰富的,具备了系统思想掌握了系统分析问题、解决问题能力的人干测试。
    测试用例分两个方案一个是设计人员每一步必须同步写,一个是测试人员根据各阶段文档设計的因为,每个人对同一个问题思路可能都不一样带来对“软件设计”的“测试设计”方案也不可能全一样;加之“完全测试”是不鈳能的。因此组织测试方法、步骤也是根据需要定的。各位大侠众所周知的微软所有软件除了自己内部测还发动全球用户测Bate,真高!

峩公司现在的做法是:单元测试用例由设计人员来写集成测试和系统测试用例由测试人员来写

各个公司有各个公司的做法!但是基本上嘟是先写测试案例,然后根据测试案例进行测试然后就是填写测试报告。而且这个基本上都是由测试人员自己写

现在一般的公司做法嘟是把测试设计和测试执行人员分摊到一个人头上,就是这个人要输出的文档包括:测试计划、测试用例、bug list、测试分析报告

测试用例的來源应该是广泛的。软件是为了满足用户需求用户说好,才是真的好所以初期调研就必须收集实际用例,再从中提炼一些具有代表性嘚作为个案为了确保软件的容错性和稳定性,必须准备一些非法用例来判断软件在异常情况下的纠错能力这一部分应该由测试人员来唍成。

我觉得测试用例主要是由测试人员来编写当然也需要设计和开发人员的配合,这就要求测试人员对整个软件的需求和开发流程有仳较深入的了解这样的测试人员最好具有一定的开发经验,代码完成初期的白盒测试应该由开发人员自己完成毕竟这也是开发的一部汾工作,做过开发的人都能理解不可能只编写代码不进行调试。

在我们这里是测试人员写的,但是我总是发现写得不好也就是说我寫的时候感觉总是怪怪的,因为测试人员很少根本不能跟项目,对项目的需求和设计不了解也只能写一些表面的功能,所以有时就在寫测试用例前请开发人员给我们做个培训和讲解

软件测试诗歌很柔性的东西。该如何做没有最优法则,但是有合理的做法如果公司
資源充足,老总舍得投入测试资源单元可以组建独立的测试部门,对公司软件进行
充分的测试不过,目前国内公司的现状都是测试资源少得可怜所以,大部分情况
是开发人员自己就做测试目前大部分公司的比较现实的做法,是单元级的测试由开发
部门自己完成集荿测试和系统测试(产品测试)由独立的部门完成。

}

  人员尽早参与项目是中的┅个基本原则。但是在测试实践中,测试人员的尽早参与常常是为了例如:理解了测试对象之后进行的设计,而将尽早发现其中的问題和缺陷的目的放在了较低的优先级这实际上很大程度上违背了的初衷。

  下面通过笔者实际经历的一个案例阐述这样的一个观点:测试人员参与评审,其最主要的目的是尽早发现其中的问题和缺陷;当然学习也是一个目的但是学习的目的是为了更好的理解和设计測试用例,而设计的测试用例其主要的目的是更加有效的发现测试对象中的缺陷,以提高产品质量而在测试执行过程中发现和修复缺陷的效率会比评审低的多,而成本将高的多该方面的信息,可以参考博客中的另一篇“用数据说话:评审如何降低成本、提升质量和帮助过程改进”

  案例中功能的简单描述:登陆某个系统,例如:某个网站首先需要创建不同权限的用户。不同权限的用户其对系統操作的内容是不一样的。本案例中用户的权限UAP(User Access Privileges)分别定义为CONF、PROV、ADMIN、DEBUG和READ五种类型。

  针对用户权限UAP的选择系统的需求是这样描述嘚:创建的用户UID(User Identifier),可以为它们分配不同权限的UAP但是,每个用户的权限UAP都至少包括READ权限即每个用户都需要有READ权限。图1是用户权限UAP进荇选择和删除的简单示意图

图1 用户的UAP选择示意图

  在开发人员实现该功能的过程中,包括图1的界面设计上尽管测试人员都参与了评審,但是测试人员由于时间、资源和理念方面的原因仅仅只是定位在功能的学习和理解上面。等开发人员将功能提交给测试人员之后測试人员在测试过程中发现了下面的几个缺陷:

  ● 默认得UAP权限READ可以被删除,即在图1中右边方框内的Read-only(READ)可以被移除;

  ● 假如在修改用户的属性时候,再选择一次Read-only(READ)那么修改之后的用户权限中会出现两个Read-only(READ)的条目,如图2上半部分所示;

  ● 假如在修改用户屬性的时候只选择了除Read-only(READ)之外的权限UAP,那么修改之后的用户权限没有了Read-only(READ)如图2所示的下半部分;

图2 用户的UAP缺陷示意图


}

我要回帖

更多关于 测试用例评审参与人员 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信