实际工作中测试用例的应用程度调查

胖英

我们公司的软件按照测试用例,那发现的BUG是很少的,也是很基本的,但往往BUG又是在不断的反复的进行中发现,这样的情况让用例怎么写,同时,人的思想是在不断变化的.但我知道一个专业的测试肯定是离不开测试用例的.
   测试用例想说爱你不容易呀

zsp_123zhang

最近公司在要求我们在写测试用例,还没用呢,现在主要靠个人的经验和能力

chm_1223

原帖由 bredri945 于 2007-9-21 11:09 发表
中国测试业还不成熟，乃至软件业。test case的编写，除非公司管理层的投入，大多公司都是只编写了基本的测试用例，根据情况有时按测试用例执行测试，测试用例效果一般

感觉我现在在的公司就是这样的

yhhbqaz

由于目前国内对需求管理水平较低，会导致用例设计效率不高，加上工期限制，对用例的维护力度自然不够。

jacyxu

顺便问问，测试用例写了，碰到经常行的需求变更，有更新的么？

langchaogc

我越来越觉得，测试只需做到“good enough”，因为测试也要服从公司目标，公司目标是盈利，这是大前提。
我觉得很多时候可以说很多道理，测试如何重要，用例必须如何写，但是现实中很多东西是没有道理的，至少不是书上说的理论那些道理。最讽刺的就是：很多教材上对好的测试用例的定义——发现了至今没有发现的缺陷的用例。这样的用例定义有价值么？ 如果是做外包，测试用例很重要，但是我们看看自主研发项目，测试用例你们是怎么做的，单元测试是怎么做的。。。。大家心里清楚。
   我并不认为“测试用例是测试的精华所在”。他就是软件开发过程中的一个普通文档，用来说明本系统在什么条件下，输入什么，会有什么结果。测试人员不可能有时间吧用例穷举，也不可能写那么多文档，公司舍得投入那么多人，写那么多文档么。所以我建议，对于用例最多的功能测试，还是要多学学业务，用例的设计思维要在心中，测试时要 认真，细致，也就够了。
  我所在的公司维护是一个可以卖的产品，所以如果一个缺陷也没有，那这个产品就卖不好；如果有缺陷，我们派人去，马上给他解决，客户最喜欢这样，觉得我们把他放在心上，所以我建议把客服做好，可能对一个公司的形象更好。
  测试只要做到够好，基本操作，基本功能不会出错，不会轻易死机。。。。
  个人意见，请各位批评

◎了了

222

jiang860718

测试用例其实挺好的，只是现在来说用的太少了，苦恼啊！

xhzhou_cll

1：刚开始从事测试的时候，我们是严格按照需求编写测试用例的，但是一到真正测试的时候，基本上是不按照测试用例来执行的，而是想到想测到哪。
2：后来自己想出了一个应对回归测试的办法。就是采用EXCEL维护好基础数据及业务数据，然后在执行测试的时候，将基础数据输入进去，及通过相应的操作产生业务数据。
3：等到下一版本发布时，再将上一版本测试时输入的基础数据与业务数据用SQL脚本删除，再次输入已维护好的测试数据以验证BUG是否修复。所以，我认为写测试用例，还不如维护好一套测试数据来的实用一些。
以上为个人经验！

[ 本帖最后由 xhzhou_cll 于 2008-3-19 16:28 编辑 ]

zhongshch

个人觉得测试用例是很重要的，原因有以下两点：
1  提高测试的覆盖性，降低测试风险。有效的测试用例设计可减少遗漏测试点的可能性，当然也可以减少测试用例的重复性。
2 在一些领域，例如手机，新款手机很多情况下都是在上一款手机的基础上加上一些新的功能和对原来功能的充实来进行开发。当测试用例被有效的管理和利用那么可以减少很多的测试工作量。

但是工作中维护测试用例的确花很多时间，特别是每次开发组改动了文档的时候，我们的测试用例也必须跟着变更。

mli@dtri.com

没有我要选择的项，我选择测试用例详细，但是不按照测试用例执行，而是按照测试要点和自由测试为主。我觉得测试用例要尽量详细，但执行时并不需要每轮都严格按照用例执行，要根据实际情况而定。

junlingliu

原帖由 vickiren 于 2007-4-25 17:25 发表
学习了

对阿，一样的感受！

vxiaoqiangs

个人感觉测试用例必须要写，而且要写的细且全面，这样在测试的时候会节省一定的时间。
当然也有写不到的地方，这个时候就要根据用例和程序把测试工作扩展一下。用例写的好坏除了测试思路之外，更主要的是看你对项目的需求是否特别的熟悉了

vxiaoqiangs

哈，上面只是说了下功能测试，其他的如自动化和性能还不太熟悉

1qazse4

2.  编写了比较详细的测试用例，严格按测试用例执行测试，但执行效果没有预期的好

judyhu_2008

我们公司的测试都要先用例，再用例评审，再根据用例测试。
有时候一个小小的需求变更，我们又要忙半天。
而且还有一个问题，需求变更对应的升级测试用例往往没有调整到集成测试用例中
从而存在这样的情况：一段时间以后，程序已经跟集成测试用例不匹配了

sunnisun

我现在在做的项目，测试用例是我来写的，写了2周左右的用例后，来51看到了这个帖子，谈下感受：
1、测试用例不可能写得太详细，特别是在项目刚开始的时候，很多需求还是在变更中，比如页面某个tab的名称、位置等都不确定，这时连开发都不知道页面的一些细节该是怎样的，就更不用说是测试人员了，想用语言详细说明很难。
2、测试用例不宜写得太详细，设计者和执行者只需要在测试执行前沟通好，对于被测功能达成共识，设计者把测试的要点写清楚，而执行者在此基础上需要开拓思路，进行用例执行，这样调动了双方的积极性，实际效果会更好。
3、对于用例的维护，是执行者和设计者共同的事情。在用例执行的过程中，执行者把他所依据的测试数据归纳并提交给设计者，再统一提交到配置库中，如果需求变更，设计者设计出新的需要添加或改变的用例，执行人员再未这类用例设计测试输入数据进行测试。维护的流程基本如此。每个变更之后用例被更新一次。

zrlcj

我个人认为首先应编写基本的测试用例，在测试之初对测试有个大概的方向，然后根据自己的发挥，在测试过程中对用例进行完善，目前我是这样进行的，感觉还可以。

happyfyw

我们从来没有测试用例

elisly

我投了第三种情况，其实很多项目都是第四种