1、测试进度及时跟踪、及时调整
XX项目建立每日例会制度，测试组长每天早晨总结前一天工作进度；检查工作量统计表、问题单、测试过程跟踪表；测试组成员反馈问题；测试组组长根据进度状况、反馈的问题决定是否调整资源和进度安排。
2、做好资源的规划，降低风险
XX项目由于资源的原因，主要是计算机硬件资源的缘故，两次设备故障，导致进度拖延。资源不充分，导致测试执行工作不能并行完成。资源是测试组将要面临的风险，在测试规划中必须考虑，并制定对策。
3、测试环境一定要与需求规格相符
XX项目管理器的开发一直在WIN2000上开发，并且开发人员在向测试组发布之前做过充分的测试，但是测试环境严格依照规格，在WIN98环境测试，发现管理器安装运行出现严重问题。
4、测试版本要受控
在测试过程中出现发现的错误导致后续测试无法进行的情况，需要问题更改错误之后再进行测试。由于要保证三套测试环境的一致和测试结果的有效性，测试版本的更新由测试组长控制，避免随意的更新。也不允许开发组更改测试机上的测试版本。
5、测试例的完备需要时间和经验的积累
XX项目的测试例设计经过三次大的整改：第一次是解决测试例可执行性问题，细化测试例以及测试数据；第二次是在第一轮功能测试完毕，通过与开发组的集中讨论，增加了大量测试例；第三次是在第二轮功能测试完毕。
6、随时增加新的测试例
在测试执行过程中，有时发现使用测试例之外的方法会发现一些问题，因此必须及时记录下这些方法，并补充到测试例文档中。XX项目使用测试过程文档进行记录和跟踪。
7、经常与开发组沟通促进测试的深入
经常有组织的与开发组沟通讨论测试方案。
测试小组要养成沟通和讨论的习惯。
8、测试执行过程中对问题要及时记录
避免口头问题汇报，导致问题没有记录，而没有进行问题的回归测试。
9、养成记录和跟踪的习惯
对任何需要记录的事项进行记录。XX项目对每次例会需要跟踪的事项进行记录；每次讨论进行记录；同行检视结果进行记录；并对问题的解决结果进行跟踪。
10、测试程序的编制也是开发活动
测试程序也必须经过分析、设计、编码、测试的阶段才能用于测试。
测试程序也必须有设计文档和使用说明
11、测试程序的编制不要从头开始
测试程序往往可以通过修改开发代码生成，不必一切从头开始。
12、测试工作产品必须进行管理
测试组的文档、各种记录、问题单、工作量统计表、测试程序、测试数据等必须进行良好的管理，并且测试组所有成员能够方便的访问到这些工作产品。XX项目主要按照版本、功用和时间来划分测试工作产品的存放结构。
13、测试环境准备需要占用大量的时间
从XX项目的工作量分布数据看，测试环境的准备与测试例执行时间在整个测试执行阶段是1：1的比例。这种比例与预期的时间要高。因此测试环境在测试规划中是必须要考虑的风险 。
14、版本发布延迟对测试组的影响
XX项目向测试组发布版本的时间推迟了几天，为了保证后续的测试进度，测试组先使用了中间版本调试测试例、测试数据、脚本。版本发布延迟是测试组工作规划的风险之一，在规划中必须考虑并制定对策。
15、软件的可测试性对测试组的影响
–XX项目本身是一个产品框架，不是一个拿来就可以用的完整的产品，在实际交付用户使用时，还需要做很多客户化的工作，或称为二次开发，如配置交易脚本，开发实际对帐签到签退程序，开发系统函数库等，在测试的过程中，为了执行测试，需要做一部分客户化的工作，模拟一个实际环境；在模拟客户化的过程中出现错误，而测试中不知道是配置的问题还是软件本身的问题，会影响测试的结果。该问题可以通过开发者培训测试人员的方法部分解决。
–XX项目服务器上的各个模块关联性强，依赖性强，独立性不好，比如，有的模块依赖于别的模块初始化一些环境参数（共享内存中），才能够启动，测试时，必须先测初始化模块，测试中不易定位问题。
–XX项目有些模块虽然功能独立，但想通过手工模拟一些场景来单独测试非常困难，必须依赖别的模块来测试，比如P–CODE执行器模块，原计划单独测试，由于上述原因，最后将它放在交易处理模块中来测试，测试覆盖性无法保证。
- XX项目的配置参数很多，相互间有很多依赖关联关系，而配置操作界面上是分别独立配置的，没有体现逻辑关系，容易产生不一致性，对配置人员要求高。
16、团队合作精神
–人力资源的重新分配，工作任务的重新划分
–测试环境资源的协调利用
–沟通与协作
–集体奋斗
–测试组长的核心作用
后记：这是若干年前写的东西了，翻出来了。但愿还有启发作用。
版权声明：本文出自 shiningredstar 的51Testing软件测试博客：http://www.51testing.com/?7622
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。