俗话说：凡事预则立，不预则废！软件测试同样，在测试项目之初就要制定相应的测试计划。接下来谈下如何编写测试计划问题。

一．首先了解以下几个问题：

1． 为什么要编写测试计划？

１）领导能够根据测试计划做宏观调空，进行相应资源配置等；

２）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；

3）便于其他人员了解测试人员的工作内容，进行有关配合工作

2． 什么时间开始编写测试计划？

（测试需求分析前总体测试计划书／测试需求分析后详细测试计划书）

3． 由谁来编写测试计划？

具有丰富经验的项目测试负责人

4． 测试计划编写6要素？（5W1H）

1）why——为什么要进行这些测试；

2) what—测试哪些方面，不同阶段的工作内容；

3) when—测试不同阶段的起止时间；

4) where—相应文档，缺陷的存放位置，测试环境等；

5) who—项目有关人员组成，安排哪些测试人员进行测试

6) how—如何去做，使用哪些测试工具以及测试方法进行测试。

二．测试计划主要内容：

１．引言

１．１项目背景

１．２参考资料（计划编写依据：可行性分析报告／软件需求定义／软件概要设计／软件详细设计／用户使用说明书／……）

１．３测试术语

１．４有关项目人员组成以及联系方式（开发人员／版本控制人员／测试人员／软、硬、结构、营销人员等）

２．任务概述

２．１测试范围

２．２测试目标

２．３广义上还包含测试需求分析／测试用例编写／测试环境搭建／测试培训／测试执行等

３．测试策略

３．１测试人员需求、分工

３．２测试方法（自动化测试／手动测试；白盒测试／黑盒测试；中断测试／临界测试／压力测试等）

３．３工具引用及测试培训（内训／外训）

３．４测试阶段计划（工作内容、人员安排、起止时间等）

３．５测试停止及恢复条件

３．６测试文档及缺陷提交管理等

３．７测试环境

４．测试资源

４．１硬件资源需求

４．２软件资源需求

４．３测试环境需求

４．４测试人员需求

４．５其他（仪器、服务器等）

５．风险评估

５．１人力方面；

５．２时间方面；

５．３环境方面；

５．４资源方面

５．５部门合作方面

6．其他内容

除以上内容有关项外，还要包括测试计划制定者、日期、修改记录、评审人员（开发负责人／测试负责人／项目经理）等信息

三．编写测试计划注意事项：

１．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况；

２．测试计划一旦制定下来，并不就是一层不变的，世界万事万物时时刻刻都在变化，软件需求、软件开发、人员流动等都在时刻发生着变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．

３．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．

四．评审总结

1.计划评审

测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审，评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。

2.计划总结

项目完成后，应该对计划的执行情况进行评审，看有哪些不合理的地方，以便为编写下一个项目测试计划做经验积累。

今天学习在VSTS上做单元测试，感觉还是比较简单的，也不需要多少编程知识，系统已经自动帮我们建好了测试环境，我感觉也许搞清楚如何做测试用例，然后就可以直接用用例里的数据初始化单元测试里的输入和期望值就OK了。我还顺便学习了在VSTS如何看代码覆盖率。也许下个学习的目标就是怎么做测试用例了，对这个没什么印象，感觉挺麻烦的，不知道没有基础的我能不能学好。

另外我也了解到这个单元测试就是白箱测试啦，请大家不要笑我无知哦，也许这些东西对你们来说就象小学生的1+1那么简单，但我现在就是小学生，一切从头开始学，惨就惨在没人教我，我周围的同事现在估计连软件测试是啥都不明白呢。

下午学习了测试流程，如下：

测试流程
第一步：制定测试计划。该计划被批准后转向第二步。
第二步：设计测试用例。该用例被批准后转向第三步。
第三步：如果满足“启动准则” ，那么执行测试。
第四步：撰写测试报告。
第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。

那么我下面的学习计划就从学制定测试计划开始吧，先到网站上收集测试计划的资料先

看了一些关于黑箱测试和白箱测试的话题，得出的初步概念是：所谓黑箱白箱，是指软件测试设计的方法，不是软件测试的方法！注意“设计”二字。黑箱测试是不需要了解程序编码，对模块进行的功能测试，只要验证结果是否符合客户的需求就行了，而白箱测试则需要进行代码分析，从代码逻辑来分析来代码是否正确，从这里也可以看出来白箱测试通过并不意味着黑箱测试也能通过，打个比方，一般情况下，我们的逻辑是先用黑箱测试来测试模块，看看结果是否符合客户的需求，比如一个工资模块，简单点，应发工资=岗位工资+加班工资-工会费，输入的数据是后面3项，输出结果是应发工资，我们设计一个测试用例，用黑箱测试，这就有2种可能，一种是测试用例通过，一种是不通过（好像是废话，呵呵），通过的话满足客户需求，不通过那就是程序代码有问题了。也许是开发人员粗心大意，在程序种计算应发工资的公式搞错了，比如变成：应发工资=岗位工资+加班工资+工会费，那么我们接着应该做白箱测试，查看程序中哪里出错了。

在新版本上运行所有已通过的测试用例以验证有没有“退化”情况发生，这个过程就是一个“Regression Test”。如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因），那么测试用例的基准就要修改，以和新的功能保持一致。回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。

计划阶段：

1. 制定测试计划，特别是测试总纲
   • 主要说明产品是什么，要做什么样的测试，时间安排如何，谁负责什么方面，各种资源在哪里，等等。
2. 写测试设计规格说明书（TDS）
   • 功能是什么
   • 要测试哪些方面？有没有预期的bug比较多的地方？
   • 如何去测试？
   • 功能如何和系统集成，如何测试这一方面？
   • 什么才叫测试好了？
3. 写测试用例（Test Case）
   • 测试用例描述了如何设置测试前的环境，如何操作，预期的结果是什么？
4. 写程序错误报告（Bug Report）
   • Bug的标题，要简明的说明问题。
   • bug的内容要写在Descrīption中。
   • 其它补充材料，如日志文件、截屏等，都要保存在bug相应的附件或链接中。
   • 还要设置bug的严重程度、功能区域等。
5. 测试报告（Test Report）
   • 多少测试用例通过
   • 多少测试用例失败
   • 多少测试用例未完成
   • 多少测试用例之外的bug被发现