|
产品发布前的故事
http://www.51testing.com/?action_viewnews_itemid_19087.html
编写测试用例方法心得体会
http://www.51testing.com/?action_viewnews_itemid_18664.html
测试人员能力的基本要求
http://www.51testing.com/?action_viewnews_itemid_18406.html
测试管理之责任
http://www.51testing.com/?action_viewnews_itemid_18681.html
有时候,优秀的开发人员是被优秀的测试人员调教出来的
http://www.51testing.com/?action_viewnews_itemid_18662.html
产品发布前的故事
产品发布前的故事不想说什么规则、流程,因为相对来说我们公司的流程还是可以的,但是总有那么多事情无法避免。对于在发布产品之前的忙碌,我希望用文字描述出来一些场景,来借鉴、备忘、总结,一切都为了将来做的更好。
项目背景:
我们这个项目周期比较长,我是半途加入的,至今即将2年了,而这之前都已经启动了快1年了。运行组织结构是开发、测试、需求三权分立,微软好像也是这样。需求给出定义,开发做出东西,测试检查质量。如果发现需求没有的则提交需求bug促使需求新建或变更原有内容,互相促进。总的来说运转还不错,当然过程中也有很多问题,解决了不少,但总还是有问题的。这里就不多说了,毕竟要说产品发布前的故事嘛 :)
我们定下了最近的一个日期发布产品(具体日期不便透露),所以大家都比较忙碌、紧张,作为测试部分的一员,我们已经好几周晚上和周六加班了。下面就这里开始故事。
故事一,突然增加的需求。
大约还有1个月的时候,市场部突然提出此次发布的版本一定要有用户认证功能,主要是收集用户信息。似乎时间还够,但实际上对我们来说是不够的。首先我们要保证当前每周2个版本功能稳定,其次需求要重新根据要求制定详细到出错的每个提示。再有需要与其他部门配合(提供服务器数据库) 事实上因为拖延,该项需求负责人弄出的需求内容还不如开发与测试提出的疑问多,这就半个月过去了;与其他部门的配合工作也没有个总协调人来跟进,互相之前都在假设别人的工作做好的前提下进行的;除了在线认证还有离线认证,这部分的接口人和工作流程还没有确定。等等一系列问题需要解决,作为具体测试,坚决把所有可能出现的问题(包括需求没有明确的)一一提出来,这时候是没有测试用例的,你对界面规范、用户操作的习惯、当前功能的目的等等的理解就是你工作的保证。
最终结果还好,虽然还有一些不如人意的地方(有时候为了向市场或开发的部分妥协,如果坚持可能会付出更大代价),总算这个功能稳定了下来,出现的bug数量大约70多个。
故事二,与其他部门产品的矛盾。
因为公司的其他产品是依赖我们这个产品的,就是说如果我们的卖不掉,其他的跟进产品也无法生存,有时候我们的产品甚至是搭送的。 这次因为我们最新版本做出了一些标准化的东西,另一个部门解析我们文件的产品就需要我们进行保护,即我们的软件输出的文件只有他们部门的产品解析,但这样一来我们的文件就不是那么标准了。另外因为我们这次新增加的一个功能可能绕过另外一个部门的产品,这就会影响他们的销售。
可能还有一些,这些矛盾可能影响产品的发展策略,影响产品的功能变更,虽然测试可以不用管这些,但是从公司、产品、项目角度来看,值得我们思考的问题。
故事三,没有得到通知的功能变更。
上周五是计划确定版本的日子,一段时间以来各个功能都比较稳定。大家思维估计都僵硬了,简单看过基本功能后,我用了一下别组的功能,非常简单的一个操作,忽然发现多了个提示信息,与功能对应不上,马上咨询别组的负责人,她说不知道,然后找开发、需求,转了一圈原来是之前要做,但是没说这时候做,开发把这个做完认为没什么大问题就把代码放进来了,结果出问题。
测试任何东西都不要依据以前的测试结果来判断当前的状况,但是可以作为参考。不要认为任何稳定的东西就不会出错,因为我们不确定这其中发生了什么。
故事四,即将定版本时发现加密方案要改变。
接上面的,几个问题改好后,连续给了几个版本,整个产品功能表现出了一片稳定的态势,到晚上7点多的时候我们已经认为就是这个版本了,都开始谈论下周可以轻松过了,至少不用加班了。忽然接到一个邮件说,为了加强加密能力,加密锁方案变更,所有我们正在用的加密锁全部要升级。一片绝倒,早干什么去了?
抱怨是没用的,这样版本确定就拖延到了周一(7月30日),天晓得周一会发生什么。开发负责人又保证说只改这个地方对功能影响不大,保证周一没问题,我看肯定是有问题才对,因为每次他进行保证后都会出问题,这都成规律了,呵呵。
对测试来说,这些突发事情很难预测,也希望做项目的朋友能对各个方面进行考虑。发布产品并不只是发布程序软件那么简单,还包括很多东西,一切都在公司发展策略这个大棋盘上。
故事五,重新来过后出现了一些新问题?
周一的早上,我们更新了所有加密锁,如愿拿到了新版本。在冒烟测试的时候发现了很多新问题,原因是加密方案改了,但是某个解释程序挂接的还是之前的版本。开发负责人的保证果然让版本出现了问题,呵呵。一直到现在还在等待版本中......
系列故事会待续发展,直到产品发布。希望这些能给大家一点提示,一点体会,哪怕是一个新方法。
编写测试用例方法心得体会
最后一个问题了,我尽量少写些,文字太多了大家看的也累,我写的也累。嘿嘿。^_^
你对黑盒测试用例的编写的体会是什么?有什么好的版本或者标准吗?
我的体会:
1、测试用例要根据测试大纲来编写
2、测试用例也要分测试项进行归类,这样比较好分析和阅读。如:业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
3、编写测试用例要考虑各种情况,精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
4、熟悉系统,对编写测试用例很有帮助。
5、即使对测试很熟悉了,在时间非常紧的时候,编写测试用例还是很有必要和好处的。
今天就想到那么些了,以后想到了在补充上了。我把我用的模板给你们粘贴一份上来,只能给你们做些参考,具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了,因为每个公司的都不太一样。
在我的个人邮箱和MSN上,通常同行都问我类似下面这样的问题:
1、一个测试用例要写到什么程度才比较好?
2、刚开始做测试的时候,你是怎么学习写测试用例的?
3、你对黑盒测试用例的编写的体会是什么?有什么好的版本或者标准吗?
对于测试用例,而我目前正在思考的问题是:怎么写出对公司有价值的测试用例,对公司来说,怎么测试才是最有价值的测试?
下面先来分析第一个问题吧:一个测试用例要写到什么程度才比较好?
这个问题,没有定语,没有说是在什么样的一个情况下,因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿,大家要有耐心看才行哈。^_^
在我测试工作中,碰上的测试类型我自己划分成这么4种:项目的测试,产品的测试,产品个性化的测试,第三方验收测试。项目的测试指的是我所测试的软件是一个项目,是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品,是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时,提出了特殊的功能,针对这些新功能,对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了,这里就不需要做解释了。
对项目、产品的测试,测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司,通常项目开发时间都很短4到5个月,然而测试通常都是在开发即将结束的时候才真正介入。测试就是1个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下,我都是先熟悉系统的业务,把握重点业务和功能后,参考需求,把测试需求、测试计划和测试大纲给制定好。由于时间关系,测试用例都是先写重点的业务,也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。
由于测试用例是本人执行,所以测试用例可以写的简单些,但是一定要开发人员能够看明白。可惜我所在的公司,都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的bug通常不是在写测试用例的时候发现的,而是在测试软件的过程中,我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力,有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好,我觉的只要你所写的测试用例在你的公司能够顺利的执行,不影响你的测试执行工作就可以了。因为测试用例写的太详细,你要花费时间和人力成本,这样出来的测试用例是最好的也是最贵的,一旦需求变更,也需要修改,这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗,别人看不懂,不能执行,那你要花费你的时间去解释,这就加大了测试的工作量。这也不是好的方法。
第二个问题,刚开始做测试的时候,你是怎么学习写测试用例的?
我之所以选择测试这个工作是因为:我毕业后,在第一家公司做技术支持,产品的问题很多,导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的,我选择了做测试,到了现在的公司。我刚做测试的时候,对测试一无所知,什么测试流程阿、文档阿都不知道,公司的测试和管理也不规范。对测试,大家都认为不就是拿个鼠标点来点去,谁都可以来做。为此,我经常上网查测试的资料,看看自己到底适合不适合做测试,测试到底是什么样的一个职业,怎么去规划自己的个人发展。其实要做好测试,真是不容易。不喜欢,真是不能做这个职业。
现在想想自己刚开始写测试用例的时候,真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板,综合了几个,就形成了。我之所以不用公司原有的测试用例模板,是因为太不适用了。还好,公司没有严格要求必须要那个模板,只要适用就行。模板找好了,可是写就费劲了。对于刚做测试的新人,看似简单的一个填表工作,要写好真是不简单。一开始写的比较不自然,有些生搬硬套,而且还很慢。没有办法,那时候没有人指导我,全靠自己自学和领悟,所以那段日子很苦阿!多写几次后,就知道和领悟了,测试用例要根据测试大纲来写,测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向,而测试用例是指导怎么去执行测试。还好,我有编程的经验,所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例,才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多,不知道这样的回答是否是回答了这个问题。
最后一个问题了,我尽量少写些,文字太多了大家看的也累,我写的也累。嘿嘿。
你对黑盒测试用例的编写的体会是什么?有什么好的版本或者标准吗?
我的体会:
1、测试用例要根据测试大纲来编写
2、测试用例也要分测试项进行归类,这样比较好分析和阅读。如:业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
3、编写测试用例要考虑各种情况,精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
4、熟悉系统,对编写测试用例很有帮助。
5、即使对测试很熟悉了,在时间非常紧的时候,编写测试用例还是很有必要和好处的。
今天就想到那么些了,以后想到了在补充上了。我把我用的模板给你们粘贴一份上来,只能给你们做些参考,具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了,因为每个公司的都不太一样。 |
|