都来谈谈 处于这样的情况下，测试人员该如何做？

风起河边

现在正在做的项目，已经做好了一个模块（这个模块相对独立，可以单独使用），测试介入的时候，是功能基本都已经做好的时候，边测边了解需求，虽然也有需求和概要等文档，但是都写的比较笼统，或者说根本就比较简单，具体的需求还是测试的时候直接和开发人员交流得到。当时的测试，没有什么流程，边测边改，往往每天都要进行一次程序更新，有时因为一个功能，导致一天之内都要频繁更新程序。现在项目开始做其他模块，此时开发人员在之前的需求了解基础上，继续做需求，写详细设计文档，同时其他开发人员边进行开发。而我，根据他们写好的详细设计写测试用例。他们开发好一个功能模块，就集成到系统中来，然后测试就对新做好的功能模块进行测试，导致测试对开发的依赖太严重了，而且这个时候测试只能进行功能的测试，业务流程的测试还不可能。测试没有计划，因为开发计划都没有定出来，测试计划就更不用说了。我想知道处于这样的情况下，测试该如何进行？这个项目只有两个测试人员，有的时候，如果开发没有新的功能做出来，而之前提交的问题又没有修改好的话，测试根本不知道要干什么。

风起河边

up !!!!!!!!!!!!!!!!!!!!

风起河边

郁闷，没人啊。。。

DreamLink

呵呵，這種很正常啊，我也和你差不多，正在想該怎么安排自己的工作呢

风起河边

今天和项目经理谈了下，已经做好的功能还是要继续测试，碰到重大问题（影响流程）的话要开发人员立即修改，测试的密度不要太大，测试的空余就看看需求什么的。

wendiwu

其实测试人员不应该太过于依赖开发，应该对需求有自己的理解；
当然，楼主的这种情况对于测试人员应该是普遍存在的问题，这就要求我们测试人员更加努力做功课了~~
加油：）

风起河边

项目用JAVA开发，之前已经开发好了几个模块，所以现在开发出来的功能直接就集成到系统上来了，而开发那边根本不做单元测试和集成测试，所以测试这边对于新开发出来的功能的测试，问题会很多，而开发人员根本没有时间去修改，他们每天的任务都很多，完不成就要加班，如果来修改的话导致他们要加班，这个时候测试真不好做。跟项目经理说了这样的情况，他说测试还是要测，但是碰到大问题就要开发人员改，要修改的问题先跟开发负责人说，这样给具体的开发人员下任务会好做点。

我感觉，测试不是没地位，而是很多时候开发那边如果没有负责人的话，测试和开发之间的工作衔接就很难。所以现在我碰到问题都会先跟开发负责人交流或者和项目经理说。

wuchunying

流程，公司需要QA，先把需求写出来，开发和测试以此为依据就好多了

风起河边

还有个问题就是，现在写测试用例是根据需求和详细设计的，而且我对整个系统的流程还不是很明确，我想知道这个时候，测试用例该写到什么程度。我这里写测试用例是根据每个模块的功能点来的，基本的增删改查基本都是有的。但是具体的涉及到数据流或者说业务流的东西很难写。或者说只能写功能测试用例，而业务流程测试用例还很难考虑。

ypc001

楼主说的，跟我之前在公司有点类似。
1、你们的需求文档比较笼统简单，是不是需求直接来自于客户，项目组里没有专门对客户需求进行分析和编写srs的人员？
2、软件功能代码编写好以后，没有经过单元测试、集成测试， 直接编译后提交到测试人员测试，这个测试人员定位应该是黑盒测试人员。
   不知道是不是你们公司项目组里对测试人员是这么定位的？
3、作为黑盒测试人员，他需要深入了解软件需求说明书（需要询问需求编制人员），而且也要知道在软件功能的是如何实现的（公司里没有概要设计、详细设计，只能询问开发人员）。
4、你在做功能测试时候，你可能提交bug还没有被修改好，而目前软件中又没有新bug发现，这个时候你可能处于一个没有事情可做的状态。你能否在平时中引入其他测试方法和自动化测试工具
   来辅助自己的测试工作？因为你提交的bug被开发人员修改后，提交给你测试。这个时候需要做回归测试，你不可能仅仅只对当前修改的bug进行测试，因为不能保证这个bug修改过程中，是否牵动
   其他代码和功能，导致他们报错。所以你必须对之前通过测试用例也要进行完全性或则重复性测试。自动化工具可以帮你在回归测试，减少不必要人工重复性劳动。
5、你们公司是如何管理测试用例和缺陷，整个测试流程是由哪个工具管理的
   你可以对现在编写测试用例和发现bug数进行软件度量，说明多少bug是应该在需求阶段可以避免的，多少bug是应该在概要设计可以避免，多少bug是应该在详细设计阶段避免的，多少bug是应该在单元测试阶段
   避免的.......。你到时候拿着数据跟项目经理看一下，让他参考一下。

风起河边

需求倒不是直接来自客户,而是做了半年的需求调研过来的文档,概要设计也是有的,主要是表结构的定义.详细设计开始没有做,现在在补.
程序一般就是我自己从ECLIPSE上导出一个war包放到tomcat下,数据倒是自己的.
基本上测试和开发是同步的,边开发,边测试,所以根本也谈不上什么版本控制,重要的BUG当时和开发人员说,不严重的基本一天提交一次.
我现在也在开始用QC等对测试用例进行管理,BUG管理是用JIRA,自动化测试的话也想做,但是能力有限,脚本的录制都还有困难,一直没有去做,对于这些,项目组的人是不管的,他只管你每天有没有测试出BUG.
" 你可以对现在编写测试用例和发现bug数进行软件度量，说明多少bug是应该在需求阶段可以避免的，多少bug是应该在概要设计可以避免，多少bug是应该在详细设计阶段避免的，多少bug是应该在单元测试阶段"  这个还不是很懂,BUG分析一直都没做过,不过我可以尝试着去弄弄.

hdtest001

规范下流程吧

mmj331

个人觉得还是应该先规范需求，如果没有一个正式的需求文档，再好的流程规划都无法真正实现