经过了一个新年，从蛇年走到了马年，一些之前不确定的事情，也开始慢慢有了答案。
在和领导们进行了真诚的沟通之后，终于得到了理解和支持，可以去寻求新的发展机会。剩下的一段日子中，就是要为自己的第一份工作，也是第一个项目完成属于自己的完整的收尾了。
开始做这份沉甸甸的的工作交接之前，需要让自己沉静下来，想想，作为一名测试人员，需要留下来什么才能让接手这个项目的同事们比较轻松的开始下面的工作。虽然目前的想法还不够完善，不过，还是希望能够和大家分享，也希望得到更多的意见和建议。或许，我的本意只是希望能够抛砖引玉，引起大家的讨论，至少是一点点的思考。
下面是我的这份答卷上面的内容：
1.富有节奏的测试流程
测试的流程和节奏是和开发、版本发布的节奏一致的，这一点一定要和开发团队做好准确的约定，比如：测试的节奏是一周一个小版本，四周一个大版本。小版本只做增量测试，大版本则进行Bug修复的验证和回归测试。
除此之外，还要注意下面几个方面的规范，否则，将会引起开发和测试交互的混乱：
（1）统一的测试版本获取渠道。所有的测试版本必须是直接发布到版本库的，测试人员只能从版本库中获取，开发人员也只能修改版本库里的版本。这样就不会造成无效、冗余的版本，测试出来的bug才是有效的。
（2）完整的冒烟测试。版本发布不能只由开发人员说了算，测试人员在接收之前必须进行冒烟测试，保证该版本是可以用来测试的。具体的冒烟测试用例需要根据产品情况确定，后台的话比如服务器能够正常运行，前台的话比如URL内容能够正常返回等，这一点也是在今后的工作中需要进一步总结和掌握的。
（3）明确的时间规定。版本获取、冒烟测试、功能测试、Bug总结、测试报告等等工作都需要规定明确的时间，而且必须到几点钟这样的精度，这样才能做好项目的协调，不能为了谁等谁这样子来过多的内耗。
2.完整清晰的测试资源库
（1）完整有效的文本资料管理。测试不像开发，几乎可以用代码说明一切，因此，测试的文本资料就至关重要，另外，ISO9000、第三方测试等也都需要丰富而完整的测试资料：需求规格说明书、测试大纲、测试方案、测试用例、测试数据、测试交接单、部署说明、使用手册、测试报告、项目阶段总结、必要的评审记录……这些都是必须的。同时，也要注意，为了保证工作效率，测试切忌以文档为导向，冗余的不必要的文档尽量不要写，另外，中间版本也不要保存在资源库中。PS：有版本控制的资料库是必须的，svn也许是个不错的选择。
（2）可控的测试工程管理。自动化测试、性能测试等都需要有测试源码，对于源码的管理应该比其他的测试文档更为严格，尤其是源码是多个人同时维护的时候，必须有清晰有效的注释和版本控制，这一点git比svn更好用。
3.规范有效的Bug跟踪机制
（1）规范的Bug管理制度。Bug是测试的重要产物，也可以说是测试的目标，但是测试不是为了找Bug。哪些是Bug，Bug等级的评定，这是项目组需要严格控制的。这一点也是我需要一直探索下去的。不过，Bug提交的时间，Bug管理的分类、等级、里程碑等却是比较容易注意并做到的。
（2）好用的Bug管理工具。QC等Bug管理工具，这里就不必多说了，很专业，根据需要选择。不过，需要说明的是Bug管理工具不能只方便测试人员，也要方便开发人员，最好能够和开发人员使用的Wiki对接。这一点，现在的项目组其实做的不错。
（3）严格的Bug跟踪机制。发现Bug只是开始，跟踪确实重头戏，产品的质量保证由此产生。大版本的测试一定要严格保证Bug的跟踪。
4.清晰有序的测试环境管理
（1）一致的测试软件版本。包括系统环境、测试工具、测试对象等都要有统一的版本，必要的时候甚至可以考虑虚拟机来保证统一性，不要为了不必要的环境调试浪费时间和人力。
（2）清晰的环境说明。测试的环境比开发的环境复杂的多，需要同时指挥调度多台服务器，准备N多的系统满足多样功能的实现。此时，一定要有一个清晰的入口，让人一下子就能找到需要的环境和版本，一般来讲，一定要记录下服务器的型号、硬件、系统、用户名、密码、版本所在位置、作用……不需要很复杂，也许excel已经能够满足需求了。
（3）实时有效的环境控制。已经接收的最新版本、对外演示的版本要放在固定的服务器上，方便所有开发和测试随时访问到，既有利于对比测试从而更快发现Bug，也能够保证在需要应付领导和用户的时候找到一个可用的版本。
版权声明：本文出自 hyxsunshine 的51Testing软件测试博客：http://www.51testing.com/?461149
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
