项目案例分析一

分析一：
　　作者：味书生
　　分析内容：
1.首先我们要定义出开发的出口标准，要求非常细致的纪录。
　　测试人员可以早介入，将交互点处理成一个交互式间段，这样就可以有效地促进开发向可测试标准运行，同时作为测试人员可以准确地了解到项目的状况，不至于在测试开始过于被动，还可以根据开发的情况及时调整计划，同时向上层提出报警。一定要做接受测试报告，及时地反应项目的情况。
2.测试组开发组共同建立一个好的合作模型。
　　现实中我们必须处理开发质量低下的问题，而且必须考虑与开发并行的问题，也就是说没有绝对的不介入集成测试，甚至单元测试。所以在前期项目计划时，就要与项目经理达成一致的标准（最高标准，最低标准），最低标准也就是你最差可以接受的情况，增加各个环节的审核，通过多个项目的磨合和总结，得出一些可行的明细标准。
分析二：
　　作者：小蚂蚁
　　分析内容：
　　这个问题我曾经也问过别人，我说的只是和黑盒测试相关的内容,我个人的建议是：
1、在项目前期,测试人员就应该介入,同时针对这个项目的开发流程制定一个测试流程。
2、测试流程里包含了程序测试的入口和出口标准，当然这个标准要得到开发人员以及项目负责人,项目经理的认可。
3、在入口标准里，针对这个项目的黑盒测试制定一套测试点，通过测试点的进入测试人员手里测试,没有经过的打回给开发人员，当然，这个测试点是要对项目比较熟悉或者很有经验的测试人员来做了。入口标准做好了，对后面的测试工作是否有效是有很大影响的。
4、公司领导要重视测试部门的工作，如果工作上不给予理解和支持.建议你跳巢吧！
分析三：
　　作者：baitest
　　分析内容：
1.在项目前期测试人员应当及早介入了解项目的进度安排,并制定一套的流程。
2.项目组应当配一个协调员,随时和开发沟通,同时负责测试程序版本的控制。
分析四：
　　作者：小颖
　　分析内容：
　　开发项目组在建立时，本身就应该包括测试人员，测试人员应作为项目组的成员参加一切关于开发工作的会议，交流及讨论，有利于了解开发的方法及开发的各项信息。
　　对于版本管理，理想状态应存在一名配置管理员，作为测试人员与开发人员的交接点对程序版本进行管理，测试完成版本返回配置管理员，开发修改完成版本也给配置管理员，由配置管理员再交给测试人员；但一般公司不会设立这个岗位，而有即便是设了，也不能充分的发挥作用（我们公司就这样）
我认为的解决方法：
1、测试人员接收程序后，在存放时以程序名称和时间作为标识，并且每一次提交的程序一直到项目结束后再删除
2、开发人员提取修改后程序时，不要直接测试，先查看一下上一次程序错误的位置是否修改（与机器中保留的上一次提交版本核对）。
3、检查后，再开始动手测试，如果真的有没有修改的地方，那就再算一次错误，不能总是替他们想的。
分析五：
　　作者：flygold
　　分析内容：
　　规定deadline，如每日12：00以后，不允许版本更新。
分析六：
　　作者：cissy
　　分析内容：
　　小颖所说的方法与我们公司现在进行的方法比较一致。但个人感觉确实没有很好地得到贯彻实施~~
　　我们公司现在在项目的立项阶段后就由测试部派谴了质保员进行跟踪，但由于级别的不一致，引不起项目组的重视，有时只能是很浅地介入项目组的开发进程，应有的作用没有得到发挥。幸好本部门的部长比较重视，一直在维护质保员的重要性、权威性，希望以后这种情况能得到改善。
　　确实现在这种状态很普遍，也没有什么很好地解决办法。要想真正地有效地体现测试的价值，只有从上头做工作，让高层真正地支持你，给开发人员一定的压力，才能让测试工作真正有效地进行。
分析七：
　　作者：akchenyanjun
　　分析内容：执行CVS
分析八：
　　作者：rosemei
　　分析内容：
　　个人认为 ：开发人员提交测试需代单时，把需要测试的目的描述清楚，其中包括其代码更新部分需要接受验证的内容描述，测试人员根据测试需求单，首先验证其版本更新后的内容，是否通过，以更新内容为接入点，决定是否能够尽快尽早的打回给开发人员。
　　至于其修改后又引发其他地方的错误，这是个无法控制的，只能看开发人员修改BUG的严谨性了，通过奖惩激励的办法，提高开发人员的开发技能是关键。
分析九：
　　作者：spring_post
　　分析内容：
　　项目开始的时候，测试部门是要参与的（原因不用多说了），但是一旦项目处于实现过程时，理想的做法是测试部门定期对成果进行测试（通常是一周一次，由RE将现有成果建立一个BUILD交给测试部门）此时开发和测试是并行的，可用CVS管理各个版本（很好用的噢~）至于BUG的提交、确认、修改也都是同时进行的~当然开发人员有责任对所开发的模块做相应的组件测试~RE在此过程中的作用是相当大的~
分析十：
　　作者：ppent
　　分析内容：
　　个人认为本案例的焦点是如何控制开发人员提交代码、打包版本的质量，而与测试人员何时介入项目是没有很大的联系的，还有楼上说的通过入口标准、检查后再测试，那是事后的补救办法，但还是可以减少测试人员不必要的资源投入。
我的看法：
1.记录每个提交代码、编译打包版本的质量情况，每月/季度进行发布。让大家清楚的看到本阶段的各个版本中谁犯了了“没有更新最新的代码、打包错误、bug没有改好、bug改这个错那个”的错误。有了这样的统计结果，相信以后不管是开发人员还是打包人员都会更加小心的。
2.如果有必要，可以根据上面的结果建立奖惩制度。
3.采用配置管理工具，进行良好的版本管理，防止代码更新遗漏、错误的情况。
4.如果是接近发布的版本，慎重起见为了防止改bug而带来的新的bug，需要评估每个bug修改的难度、优先级、风险等，是否有良好的解决办法，或者在下个发布版本中修改。
分析十一：
　　作者：小胖子
　　分析内容：
　　前面几位的方法在实际的工作中都是使用过的，但是制度是理想的，实施起来就不是很理想。我遇到一个开发人员写的程序，基本上是无法使用没有一点是根据需求规格说明书写的。但是我还是耽误了两周的时间，最后我在例会上向项目经理提出了正式的交涉，才引起公司的注意。最终那个开发人员因为工作能力问题离开了公司。
分析十二：
　　作者：自得其乐
　　分析内容：
　　我们公司现在的做法是在提交测试之前由开发人员先做VT，测试人员拿到新版本后也是先做快速测试，没有大的功能性问题才接受该版本，如果随便点一个功能就报底层的错误，就说明开发VT没有做好，可以打回该版本，由测试员提交delay报告，说明这个版本延迟提交的原因。由管理中心进入来跟踪查找原因，所以长期这样开发人员一般对于提交的版本还是比较谨慎的。
分析十三：
　　作者：chimi
　　分析内容：
　　在我单位，具体操作是这样的：
1.BUG 的跟踪要抓紧，必须有一个BUG的跟踪系统来管理BUG。
2.版本的发布和测试版本的管理，要以BUG 管理系统为依据。
3.新加功能的跟踪也可以用BUG 管理系统那里实现。
4.每次开发人员修改了BUG 或者是 完成了新添加的功能，都必须在BUG 管理系统那里作说明。
5.每天安排一个指定时间来获取最新版本的程序来做测试，当然之前要确认他们都更新了代码，编译服务器也要准时、成功的编译好测试的版本，确认他们对自己的工作都作了记录（记录到BUG 的管理系统）。
6.开始测试新版本的程序。只要其中一环还没有完成，那部分的内容不作为测试考虑。
分析十四：
　　作者：nio
　　分析内容：
　　其实作为测试来讲，没有必要关注这个问题。
　　测试的主要目的是发现问题，至于版本问题，以及BUG有没有修好，那不是我们测试人员要关注的。我们要做得是如实的反应问题。
　　这个问题的出现根源在于测试人员有太多的意见（牢骚），出现这样的问题，我们要做的是告诉开发人员，在这个版本中有些BUG并没有修好，至于为何会出现这样那样的问题，则和测试一点关系也没有。
　　楼上几位的观点，使我认为测试的责职太多……测试其实和版本控制、进度控制等扯不上什么关系吧？一般来说这两个工作是有专人负责的，不是么？