下面先来说说测试计划。测试的目的、定义和范围制定测试计划时，首先必须明确的是测试的目的、定义和范围。
一般来说，测试的目的有三种：防止发生bug 找出bug 保证软件质量找bug的测试用例和保证质量的测试用例是完全不同的。比如，回归测试的目的是防止发生bug，每次产品发布都应该执行，所以应尽量让测试用例能自动执行，减少测试执行的工作量；而为了找出bug，就要尽可能全面地考虑各种特殊值、错误处理、安全问题等；而保证软件质量的测试，则应当模拟完整的业务流程。
至于定义，也许你会觉得，“地球人都知道，有写的必要吗？”你可以去问问你的组员，单元测试、综合测试和系统测试是什么意思，可能十个人会给出十个答案。在里还好些，小公司里这种现象会很严重。所以有必要把大家对测试的认识统一起来。范围也是必须明确的因素。测试整个系统，还是特定的模块？在什么硬件、什么操作系统上测试？这些也都必须事先明确。测试的读者对象接下来还要明确，测试计划是给谁看的？可能你会认为是给测试者看的，那么该计划是否需要给客户看？是否其他项目干系人如上司、公司决策者会关心该计划？测试计划应该根据读者对象，写出读者最想知道的内容。
接下来就是测试环境了。这恐怕是最复杂的因素了：操作系统是XP，Vista，还是Win7？ Linux的话，是RHEL4，5还是CentOS？要不要支持Debian、SuSE等？ 浏览器是IE、Firefox还是Opera？IE的话需要测试什么版本？ 数据库是MySQL，Oracle还是SQLServer？ 硬件配置有什么要求？ 网络环境有什么特殊要求（如IP地址、网络拓扑结构、带宽等）？ 服务器和客户端各需要架设几台？它们之间如何连接？ 安装时使用的序列号是什么？稍有经验的人就会知道，各种测试环境的组合会让测试数量成倍增长。
比如测试网站，操作系统XP + Vista + Win7，浏览器 IE6 + IE7+ IE8 + Firefox，组合起来就是3 x 4 = 12种环境，原本500项测试用例就会膨胀到6000条。这显然是不现实的。因此要找出最有效的组合方式，避免测试用例爆炸。比如这个例子中，我们知道Vista下没有IE6，Win7下没有IE6和IE7，这样就能减少3种环境。
另外，不同操作系统下，只要浏览器相同，表现形式也几乎相同，所以不用测试所有组合情况，只需测试 XP + IE6、Vista + IE7、Win7 + IE8、Vista + Firefox四种环境即可。另外，这些都是客户端的测试，假如500个用例中有200项是服务器端的测试，那么这200项只需在一个环境中测试即可。这样最后的测试数量是 300 x 4 + 200 = 1400，比最初的6000项要少了许多。
此外，测试组的编制和日程计划也必须在计划中明确。谁负责写测试用例，谁负责执行测试，谁负责报告？现有的成员能否在规定的时间内完成？测试人员的能力是否达到要求？编制通常用组织结构图来表现：而任务责任分工可以用TRM(Task Responsibility Matrix，也称RAM——Responsibility AssignmentMatrix）来表现。 TRM中用行表示任务，列表示各个成员，行列交点处使用圆圈、三角等表示不同的责任。最简单的TRM如：日程计划可以用甘特图表现，这个就不再附图了。