测试项目问题总结.docVIP

测试项目问题总结 测试项目问题总结 首先，我们抛开外界不合理、不规范因素，从自身找问题： 测试设计阶段： 通过讨论，大家都意识到测试设计特别重要，目前我们对设计准备不够充分，对系统功能的理解不够准确，没能很好利用时间，体现在设计阶段的一个主要文档Test Case Summary上，以往我们的Test Case Summary只是分配给谁就由谁自始至终负责，而且写完后就很少有改动，因此难免有偏颇。 解决方案：〈集思广益〉 对开发语言、应用平台、相关技术有所了解、精通，无项目时自己多多充电； 如果有可能，前期就参与开发设计； 熟悉本人负责的模块功能； 尽可能多的了解整个系统的逻辑流程； 讲解并讨论系统，设计测试方案、确立客户真实使用环境； 对设计不完善处提交开发部门； 按一定规则写Test Case Summary，准备测试数据，形式可以多样； 公用测试用例另备一文档，根据不同项目从中提取需要的部分； 相互Review、借鉴、指正； 修改Test Case Summary，力求简单、明了、清晰。 Leader分配任务、模块不太合适也是导致测试不很到位的原因之一。 解决方案：Leader对每个成员的特点、个性有所了解，最大限度发挥其能力或Member主动告诉Leader你适合做什么。 一轮测试时间的定制也很重要。 解决方案：根据具体项目，征求开发部门意见，科学定时。 测试执行阶段： 没能按原定Test Case Summary设计思路走，执行顺序混乱，容易漏掉某些Case，导致漏掉一些bug；功能变动了，Test Case Summary却没能及时更新。 解决方案：严格按照Test Case Summary步骤执行，可采用矩阵形式记录执行情况，不提倡跳跃式测试；及时更新相关文档；不再让“时间不够”成为理由。 测试不够科学，更象手工作坊。 解决方案：敢于用新工具，接受新技术。 安装测试与实际情况结合不够，太过细致没有必要。 解决方案：具体项目定适合的测试点。 压力测试还是个盲点。 解决方案：成立专门小组，对项目的开发平台、底层的东西有更深入的了解。 单个模块测试强度还可以，整个系统贯穿起来测试不够，会遗留一些隐含的bug。 解决方案：首轮测试一定保证能测的模块都测到，按正常流程过一遍；保证至少有一轮模拟客户真实环境、真实操作过程的测试。对于较大的系统、模块，可以采用分解测试案例的方法，如：10个测试要点，一轮测5个，这样既能保证质量，又解决了时间问题。 不合理的给定错误级别，偏高，会影响开发人员情绪；偏低，会耽误错误的及时解决。 解决方案：更深入理解系统，与开发人员沟通，制定测试优先级（测试重点），更客观地提PTM。[另：用DefectTracker填写PTM时，PTM与bug的关系是一一对应的，即一张PTM只填一个bug。] 沟通很重要：与开发人员沟通，有利于部门间的合作，更好理解被测项目；与客户沟通，能知道客户真正关心的是什么，帮助我们确立测试重点；本部人员沟通，可以取长补短,互通有无。 解决方案：直接同开发人员沟通，或汇总到Leader处；组内沟通可采用定期例会的方式；如果你负责的地方有问题，如太多、太复杂，规定时间里不能完成，或你发现其他人负责的地方有问题，及时通报Leader或你的同事；沟通技巧则需通过看相关书籍，学习他人好的方法，不断积累。——“把‘不’说的跟‘是’那样亲切。” 摆正自己的位置，清楚自己的职责： 我们的职责是帮助开发部门把关，最终当系统提交给客户时，将错误降到最低；把开发部门当作我们的客户。 这就要求我们： 提的问题通俗易懂，写PTM的语言规范； 态度诚恳、友好、认真、仔细 有怀疑精神，不仅仅能听得进，还得动脑筋想； 对于测试时间较长的项目，几轮下来，恐怕需要的是更多的耐心； 对客户也不能有求必应，对于开发人员的质疑，有足够的自信去让他明白你提的的确是个需要解决的问题，他得重视；这自信源自你对系统的了解、对技术的掌握、对客户需求的认识； 每一个新包到了，Leader应承担可测性评估。 在过去的几个项目实施过程中，开发人员的某些情绪、话语会影响到我们的心态，这也应尽量避免，当然还需要不断的磨练。 测试结束： 测试过程中记录下遇到的问题，项目结束，及时总结，也是为了积累经验。 其次，部门间接口制度有待完善，这与公司整体制度有关，咱们的代言人单宏已多次向上反映了，不过需要时间和机遇。在现有体制下，我们该做的就是提高自己，适应公司，如果在条件艰苦时能做的很好，那体制完善时就更不在话下。 最后，留下几个议题，大家思考一下，有什么好主意提出来共享： FVT和UIT的定义，执行时的先后，人员是否相同？ C/S架构测试方法？ 报表测试如何开展？ 压力测试工具？原码？孰重孰轻？