关于改善测试工作的讨论——欢迎同行向我扔鸡蛋
刚进入某个新项目（BSS），无测试流程和规范。有个大概的想法如下，欢迎大家给我提意见，同时不知道以何种方式来提出来，也请大家给我提建议，谢谢！我只是初步完成了下面的文档：关于改善测试工作的讨论
通过这段时间在各位同事的帮助下，我逐步熟悉了公司工作流程，同时我个人的工作水平也有所提高，在测试工作过程中存在几点困难如下：
目前存在的困难：
1.项目中缺少缺陷管理工具。目前项目中发现的bug，和开发人员沟通后修改可能存在遗漏，且不利于bug的跟踪，沟通成本大增且测试效率不高。
2.测试人员对项目（背景、计划、进度、需求及业务知识、架构等方面）了解不够。由于对项目和真实需求的认识不够，无法规划整个测试阶段，测试工作成了验证香港bug和确认开发的实现，主动性非常小。
3.无专门的测试环境或提供的测试环境不稳定。提供测试的版本，在提交测试后还可能被修改，测试过程软件的变化，会对测试结果造成影响。
4.转测试流程不规范。当有新版本，测试人员获取的信息非常有限，不清楚修改了哪些问题，而且没有测试建议来指导新版本测试，目标不明确会导致测试效率低下。
5.测试过程无用例指导。随着需求不断更新，软件的功能和结构越来越复杂，香港同事的用例文档已不能指导测试，由于缺少用例，测试就没有逻辑性是盲目的测试。不断更新的需求，也不能及时记录，很多问题会慢慢丢失。
6.目前Bug解决流程不明确。比如测试人员新发现一个bug，若某一问题涉及好几位开发人员修改时，除了不知道该由谁修改，同时问题的责任不明确，给测试造成极大沟通成本甚至问题无法解决或解决不彻底。
针对以上问题，我提几点意见如下：
1.尽快在项目试用缺陷管理工具。BugFree是开源的缺陷管理工具，除了管理、跟踪和分析缺陷外，还可以和SVN整合，将文件的更新信息同BugFree中被fix的Bug有机的结果，用于指导测试。目前BugFree已部署到项目组服务器还未在组内推广。
2.开展项目相关培训。测试人员迫切需要项目相关培训，了解项目的背景、计划及进度、架构、需求及业务知识等等，帮助规划和实现整个测试阶段。项目的业务培训尤其重要，可以指导形成正确的测试思想，并且帮助项目组成员信息同步，避免因不同步导致的问题。
3.通过硬件或技术手段保证提交测试的版本的独立和稳定性。若一轮测试软件前后代码不一致，会导致测试的效果无效，效率大大降低。每轮测试都需要有一个独立的不受影响的环境来配置软件版本，测试过程才能持续和有效进行。
4.逐步建立和完善转测试流程。最初可用书面方式（邮件或文档或通讯工具）通知测试，列明测试的对象及修改的内容（包括修改了哪些bug，影响的功能、测试建议等等）。
5.在测试组内尽快开展测试用例设计工作。测试用例需要统一的模板，由测试人员设计各自负责模块的用例，并需要测试组内、开发人员的评审，通过后方可归档。这个过程既是测试人员熟悉整个项目交流经验的过程，也是开发和测试人员对于项目的认识同步过程。同时可用于指导往后的测试工作，交叉测试等。
6.在缺陷管理工具适用前，建立简单的bug处理流程。该流程用于明确Bug的处理责任及义务，方便发现的bug得以高效率解决。比如可以采用，测试新发现的问题全部提交开发经理，由开发经理指派相关人员解决，被指派开发人员有义务负责和推动bug的解决。某模块内（前台、后台以及DB开发人员）的bug责任及义务也需要划分清楚。
如各位同事有其他意见或对我提出的问题有疑问，欢迎一起探讨，祝各位工作愉快！ 偶也是菜鸟。就对3.4.5提出小想法。
3.测试环境，就是测试人员自己在测试前就需要搭建好的。如果有问题，说明你没有满足最基本的测试条件。对于测试版本的问题，我也碰到过好几次，最终的解决方案是，让PM，TL签字画押后，证明所送侧的版本跟CVS里面的是相对应的。那样，TM，或者RD想偷偷换掉也有迹可寻。把头头都绑定了，看谁敢乱换。
4.我们软件送测的时候，都有送测单。里面有，基本的测试环境说明，修改的bug，需求的变动，甚至是注意事项等等，可以说，很全面。建议你们采用。
5.testcase也要与时俱进。尤其是，客户中途提出对原有功能修改后，你只能重新设计testcase，否则，就不能保证你测试的针对性和覆盖率了。
6.碰到类似的情况。我们的解决方法是，如果你对解决人有疑问，就把皮球踢给PM，然后PM会重新指定解决人，毕竟，他更了解，即使不了解，他也更容易跟RD沟通解决。
:lol :lol :lol 我来公司10个月了，很多都开始完善了。 感谢Imutou的建议，很有个人想法，我已经采纳，谢谢:lol
页:
[1]
