请问，测试偏离测试计划怎么办呢？

饭钵

目前在测试一个项目，过程中，遇到很多问题，深感困扰，希望论坛里的各位高手前辈 能够帮忙解答~~
1 版本控制问题。
项目每月上线一次，针对这种情况，每个开发人员在完成自己开发部分功能后就提交到测试环境。就导致测试版本问题，可能每天都发布好几个版本（这几个版本包括　测试已经提交的功能发现严重ｂｕｇ，开发人员提交新的和更改部ｂｕｇ的程序）。但是我们的测试版本只记录每天一个版本，不会记录中间发布的这些版本，象这种混乱的情况怎么解决呢？ 是不是该详细记录每个具体的小版本呢？

２测试任务分配问题。
　项目负责人完全没有项目经验，制定的测试计划总是与实际执行偏差很大。例如计划做两轮，实际过程只做一轮，并且不是在同一个版本上的一轮。象这种测试任务分配上应该怎样斟酌呢？怎样使得执行能够ｃｏｖｅｒ到计划呢？

另外管理流程比较乱，没有要求作回归测试。我们就是自己提交的ｂｕｇ自己得记着点自己去回归，上线前主功能下什么的。

怎么去制定个言之可行的测试计划呢？并且在执行过程中怎么应对突发的情况？（例如出现重大问题，某开发人员改ｂｕｇ不力，或者开发人员没有按约定时间点提交测试这种情况呢？）

３　测试用例评审
各位有没有比较高校的用例评审的方法呢？我们是将案例写在qc里头，每个检查点就写成一个用例模块，评审就是测试人员相互去看彼此的用例；同时QA也会检查我们的案例，但是都没有反馈信息。
各位有什么好的建议吗？

希望管理高手们，多多赐教~~~ 感激不尽那~~

oscarli

项目主管没有做项目进度计划并且不是按计划进度进行有效控制，如果工期紧，出现你这种现象很正常。
我想做测试的人都多多少少遇到这种情况。以下是一些建议，希望有你有用：
1.明确你的质量控制目标和范围，核心一定要控制好，全面覆盖是不可能的
2.有测试团队，建议做模块分工
3.版本要做差异化控制，一定要及时搞清楚，研发人员修改了什么，添加了什么新功能，修改的部分要做质量风险评估（一般让很有经验人把关）
4.加强各团队之间的沟通，合作是解决问题的基础。

archonwang

楼主的团队可能没有良好的进行过版本控制。每天发数个版本应该只出现在项目初期构建的时候。
从你的表述上看得出整个团队的范围控制得并不是太好，以至于无法准确估算测试工作量值

那么逐个说明
1。 版本控制
测试环境发布必须指定独立的个体完成，该成员统筹发布的相关事宜，记录版本，任何与测试环境相关的增删改处理必须由此人统一完成，其他开发人员未经授权不得对该环境更新。每天测试版本的发布最多一次，以确保对最重要功能进行验证和新功能及修改的确认
第三，需要注意在更新提交时务必填写注释内容，可以通过相关的版本控制工具强制要求处理
第四，任何一次的更新发布必须有记录，并要求注明哪个版本要求进行测试。如果pm说每个版本都需要进行测试，则必须给予一定的资源然后再处理。

此外，必须控制好每个修改人的基础一致。简单来说，就是确保修改对象的一致性，即每个人的基础代码是一致的。具体的做法是要求每日更新提交，每次更新处理前必须先从服务器上获取最新代码。

archonwang

2。 测试任务分配
这个事情按说由测试负责人实施，项目负责人确认。测试计划偏差很正常，及时修正就可以了。一开始的时候是无法承诺的。很多错误的理解是计划就是确定的承诺，实际上完全不是这样——计划是有变更的存在风险的承诺。
至于说到版本，这句话就很明确。如果测试计划没有针对特定的内容，比如版本及功能范围或是开发进度挂钩，就完全不符合计划本身的要求——脱离基础。
我的建议是明确每一次发布后的测试实施周期和范围，而不是一竿子捅到底——实施过程中有很多的风险及不确定因素，最终结果将影响项目目标的实现。

archonwang

3。关于用例评审
不知道你的项目里有多少tester和需求分析及设计人员？如果tester的人数少于3个，且没有分析或设计人员参与，这类的评审直接在测试组内部完成就行了，但是一定要带上之前进行需求调研的同志，确认用例对于需求而言没有理解上的偏差。
你所说的qa参与更多的是检查是否存在该用例，至于符合不符合业务的定义，qa很难判断。tester互检是个方法，但是如果没有详细的需求分析或是需求调研人员的参与，则可信度并不高。

饭钵

回复 5# archonwang

感谢您这么仔细的逐一解答呢~~

饭钵

回复 2# oscarli

您说得很对，我们就是工期紧，并且不能明确确定具体上线功能点。

饭钵

回复 3# archonwang


    您说的我能理解了，就是说版本控制上，每次更新发布的版本都必须详细记录更新范围，影响功能点。然后每个版本是否需要重新全部测试，还是继续由上个版本继续测试，需要项目负责人决定，然后告知测试部门。
是这样吧？

饭钵

回复 4# archonwang


    测试任务分配上我一直有个疑问，就是由于我们的系统上线一个功能需要其余部门同事的支持，例如提供接口什么的。所以很多我们这月列到计划里头去了，但最后却一直拖着无法开发或者测试。
并且由于是1月就上线1次，这些功能都一开始就列到了测试计划里头分到了每个测试人员头上进行用例设计。最后在实施过程中这个计划就完全被打乱了，这个时候是不是就应该及时更新测试计划了？ 更新最终测试内容，还有更新测试人员任务分配。还是保留测试计划内容，在测试报告中描述这些情况呢？

langztest

从这些可以看出，整个公司的质量体系不够完善，这也不是一时能够都改变好的，需要测试人员大家一起努力外加公司领导层大力支持，测试人员腰杆子直了，自然办事方便快捷多了。这样才能从根本上解决问题，要不然测试一直会很被动、很疲惫。

以上纯属个人意见！

饭钵

回复 10# langztest


    恩，我们就是要在废墟上开辟出王国的人那~   刚刚认可成立 质控部。
   并且没规范。这种情况下，公司的意愿就是我们能订出来的切实可行的流程就上升成执行流程。

archonwang

回复 8# 饭钵

是的。最好做到，对于整个项目而言，这种方式相对比较好些，具备可控性。否则全凭运气和经验了。

archonwang

回复 9# 饭钵

业界有这种说法，文档是用来修改的，计划是时刻修正的，不知道你是否听过。

计划被打乱是意料中的事情，跟进变化而作调整比较关键。另外，变更必须要及时地需要告知你的上级。

Jackc

文档是用来修改的，计划是时刻修正的

至理名言

饭钵

回复 13# archonwang


    呵呵，确实很名言阿~~
感谢您仔细耐心的回复~~指导了我和千万个正在迷茫中的人那~~~~

饭钵

感谢顶帖阿~~ 我也顶顶~~

刘顺

出现这种情况的原因是，测试部门没有自己的测试流程到导致的。
需要测试部门领导根据公司的实际情况，指定一套符合公司现状的流程，使得这个流程通过公司高层领导的审核，测试相关人员的认可，让大家完全按照这个流程来执行就不会出现这中情况了。

饭钵

回复 18# 刘顺


    您说的很对呢 ，努力完善流程中~~~感谢回复！