51Testing软件测试论坛

标题: 测试路上：测试流程的规范及其困惑 [打印本页]

作者: Ade_Huang 时间: 2010-5-6 13:08
标题: 测试路上：测试流程的规范及其困惑
首先，介绍下我的工作环境：
我们项目组公共7-9个人，开发人员4个，项目经理1个，测试2个，其中1个是兼任与客户谈需求。项目组全部都在客户的公司进行项目的开发和测试。项目组是基于一个原始的老系统的二次开发，和客户边谈需求，边改，然后边测试；
测试方面的情况：文档就一份需求文档，其他的测试计划、方案、用例之类的都没有，另外还有个jira缺陷系统。（测试时，有bug就直接上交缺陷系统，通知开发改善，改善完毕，开发人员通知测试人员复测，复测通过bug生命终止。）
我的困惑：
1、对整体的系统上测试都是围绕着需求说明书来进行的，这个没有异议，刚开始的时候还行。但是在这种需求变动的非常快的这种开发测试模式下，在需求变动比较多的时候，一个礼拜天天都有或多或少的变动，导致需求文档还没有修正完毕，就得测试开发出来的新需求的功能。日复一日，需求已不再是测试所需要的那份需求说明书了，最终需求也就被忽略了。
2、在这种开发测试模式下，一般都是新功能开发完毕，马上发版进行新功能的测试，有时间的话就会整体测试一遍（这里一遍指的是其他的主要业务功能，因为时间上不允许所有功能点都去验证新功能有没有带来其他错误）。这种情况会导致在新版本发布后有些主要业务功能会被忘记，导致测试的覆盖率不是很好。
问题：前辈们都知道这种情况，最好是写下测试用例，把主要业务功能的用例都写上，到时候新版本发布的时候可以把整个测试用例都走完一遍，就会达到不遗忘的地方了。我想这种开发模式下的，写测试用例时间上是不允许的。现在我解决的方法就是写一个小小文档记录那些测试和未测试的主要业务功能。
3、这种开发测试模式，需求文档、测试计划、测试方案、测试用例是不是可以不用，如果要进行的话，我该怎么办？（最近也只是自己变成这些文档练练手，在实际工作上运用起来难度太大，如果一运用，说不定下个版本这些都已经被淘汰完毕了。）
4、不知道这种情况是不是属于敏捷开发模式？还望前辈们分析分析，给个答案，谢谢了。
5、另外这种开发测试模式适合不适合自动化功能测试？因为最近才刚开始学习，打算走这个测试方向。现在我个人的观点是，这种开发测试模式，需求变动很大，加上功能有时候会变更比较大，测试用例会变更比较多，从而导致测试脚本进行大量修改，不过在其他比较稳定的模块还是比较适合自动化测试的。只是主要业务上功能上的自动化估计实现起来就会比较耗人力和物力吧。
以上是我最近工作的体会和困惑，希望有相同经验的前辈们指点迷津，把知道的教教我，让我走出来。谢谢了！！
经过版主的解答，另外加上一个困惑：
在敏捷测试过程中，基本上都是手工测试，而对于测试新人的我学习最多的估计也就是业务上的知识以及沟通上应该注意的细节，在测试的技术方面估计会涉及很少，那么怎么样才能在这样的环境中完善提升自己的测试技巧了。就打比方说：现在没有测试计划、测试方案、测试用例，自己在业余空闲时间完善它，虽然它无法再现在的实际环境中运用，就当练练手，提升自己。除此之外,在敏捷测试环境，作为新人的我还可以从哪里开始学习，注重哪些要点方面？另外还有其他的方法提升测试技术么？

[ 本帖最后由 Ade_Huang 于 2010-5-6 14:37 编辑 ]

作者: msnshow 时间: 2010-5-6 13:33
标题: 回复 1# 的帖子
从楼主的介绍，我觉得这应该就是敏捷的范筹，
在这种条件下，
1、需求文档往往是没多少参考价值，需求的获取得通过与开发和需求方沟通得到
2、测试用例肯定是没时间写的，但可以把重要的功能点列出来，作为每次回归测试的范围，以保证重要功能没问题
3、自动化测试估计很难，因为你连写测试用例的时间都没有，怎么有时间去做自动化测试（并且得看你的项目是否适合做自动化测试）

作者: Ade_Huang 时间: 2010-5-6 13:57
标题: 回复 2# 的帖子
谢谢msnshow版主的指点和帮助。
1、这里需求文档估计就以后版本最终确定后，有时间修订完善做一个里程碑用吧。确实在需求的获取方面需求人员和客户探讨后，再由需求和开发及测试人员沟通，比较大的需求，或者异议比较大，应该开发、测试、客户都在一起沟通解决。要不然有时候需求人员会在传达上出现错误或者测试和开发人员上理解上错误。
而目前项目的情况就是需求和客户沟通后，然后与开发、测试沟通，有时候就导致了传达上错误，浪费的好多时间。个人觉得还是应该开发、测试、需求、客户一起讨论，然后项目组的再次讨论研究，虽然会花费比较多的时候，但是这样可以避免以后的错误。
2、发版太多，回归测试进行的很频繁，有时候这都还没有回归完毕，就得再次发版了。看来还得适应适应
3、我是测试新人，在测试用例上的经验不错，而现在也恰恰没有这个环境，始终都是有空的时候练练而已。关于自动化我还问版主个问题，如果业务参数之类的模块功能，是不是可以系统的部分自动化，减轻手工测试的压力，目前也是想想呵呵，因为最近在新学习自动化

作者: twinsczl 时间: 2010-5-6 17:05
2个测试，何谈流程

作者: peag 时间: 2010-5-6 18:48
开发人员4个，项目经理1个，测试2个....比我的好了

作者: Ade_Huang 时间: 2010-5-6 19:12
标题: 回复 4# 的帖子
呵呵也是，谈测试流程有点太过牵强了，我也想测试上走的规范一点，自己提升快一点

作者: Ade_Huang 时间: 2010-5-6 19:13
标题: 回复 5# 的帖子
现在就一个测试的啦，项目到后期了，就留守我一个测试了

作者: zhangting85 时间: 2010-5-6 22:14
需求文档不完整可以把和需求方的沟通结果记录下来让需求方approve，
test case可以简化为check list，也就是只列要测什么和有没有pass
回归来不及跑完可以划分测试优先级来解决，
自动化完全不适合如此多变的系统，花时间自动化你不如花时间在需求的整理上，
就这样，很简单。

作者: Ade_Huang 时间: 2010-5-7 09:09
标题: 回复 8# 的帖子
恩，谢谢前辈。
我问个问题，现在有需求的人了，谈需求现在也轮不到我，现在感觉在这种开发环境中，都是手工测试，时间长了，人也枯燥了，我也是规划好了，打算在测试这方面发展。在前面有帖子，前辈也说了要培养兴趣，说实话这样下去确实会非常无聊，那如果是你，你怎么来提升自己，在测试技术方面？（现在基本上都是学习业务上的知识）

作者: zhangting85 时间: 2010-5-7 10:19
标题: 回复 9# 的帖子
技术上提升自己，首先你要有一个技术的方向，然后你就可以朝这个方向发展。
像我一个同学目标是往自动化测试方向发展，那她在做的事情就是自己开发一个web自动化测试框架。当然也可以做其他的研究，比如同样是自动化测试方向，可以研究QTP的应用。这个就要根据自己的实际水平来决定了。可以发展的技术方向太多了，除了QTP，LR的应用大家都有所了解了，还可以走数据仓库，商业智能，搜索引擎，分布式系统等等很多专精的方向。
然后，确定了方向之后就去找该领域的文献资料，加入一些国际上的mailing list，等等，你要真的想提升技术，在国内的论坛上能找到的资料是很有限的。

至于我的话，技术上我的目标目前是成为黑盒测试专家，如果你也想这个方向深入的话我推荐可以看看Cem Kaner 的文章和讲座

作者: Ade_Huang 时间: 2010-5-7 18:47
标题: 回复 10# 的帖子
非常感谢zhangting85前辈，让我了解了很多，特别是黑盒测试还有更多的发展地方，只是现在都是手工测试，被反复不断的测试蒙蔽了眼睛，再次感谢
在以前是打算学习学习自动化及性能测试，走这个方面发展发展，但是由于现有的敏捷开发环境，让我无法开展，整天都是手工的黑盒测试，人生顿时困惑起来了。其实也知道很多人都对黑盒测试不重视，也看不起它，其中也包括我。那是因为好多人都不知道黑盒测试有很多研究的地方罢了。我想就以现在的测试环境倒是可以考虑考虑研究黑盒测试方面。
具体还待自己去实践探究，如有困难和自己解答不了地方，还请前辈传教哦，谢了！！

作者: Ade_Huang 时间: 2010-5-7 18:50

原帖由 twinsczl 于 2010-5-6 17:05 发表
2个测试，何谈流程

这个是谈不了呵呵，但是我们可以做到实际无流程，心中创建它个流程出来哈哈。
唉，这一切都是不怨谁了，中国还处于测试的初级阶段吧。好多公司都无规范的测试流程

作者: peag 时间: 2010-5-7 19:33
标题: 回复 7# 的帖子
那么悲剧，我的现在还两个，不过开发的6个，~~

作者: hueslife 时间: 2010-5-11 17:35
真的不错呀
楼主很有想法，受教了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)