按照产出的文档，介绍项目开发过程中的
工作步骤
1．
测试计划：这个计划，我
个人觉得应该在详细设计确定后，代码开始编写的时候进行制定，因为我是“提早开始测试工作”思路的忠实fans，虽然现在项目里都只有我一个人在这么早开始工作。。。-_-///
a) 测试计划，主要是给后面的测试工作一些指南，不能写成领导看的计划，而是要写成由做事的人看的计划
b) 包含的内容可能有：
i. 测试团队人员及分工（要确定当测试时出现缺陷界定、测试环境准备等问题时能找到指定的人员）
ii. 测试开始结束时间（理想情况下，不要安排的太紧，赶工肯定会造成延期或测试不完整，可惜理想和现实的差距被规定为很大）
iii. 测试环境配置（什么样的硬件条件，是否网络、设备等，系统在什么地址访问，访问权限、使用的测试数据等方面的预计和准备）
iv. 测试哪些东西要说清楚，这里我建议把简单的测试大纲纳入测试计划中，一方面领导可以看到你的计划写的多详细，另一方面大纲可以很好的成为编写用例的依据
v. 怎么测试要说明白，如只做系统测试，那就要写清楚不做集成测试，如果需要集成测试，就需要写明白集成顺序。另外如果需要进行性能、文档、等
其他的测试也要在这个计划中写明，虽然一般这个计划都是针对
功能测试，但是如果有其他测试，也要写出来并安排时间，相应测试的相关计划等也需要指明
vi. 测试结束标志（要说明测试达到什么程度可以结束测试，不能等到把所有缺陷都找出来以后才结束，因为那将是一万年），允许缺陷存留在系统里，我们只需要找到留多少这个度就够了
2．
测试用例：这个文档，主要描述具体的测试步骤，但实际应用中，至少目前我的项目里，由于时间的原因，很少有写的，就算写了的，也基本没有用到测试里，在这边的很多项目大都是直接来测，全凭我个人的经验来检查（在此感谢领导们对于我二把刀
技术的信任_@_）。但是我想说其实他很重要，也许你不需要写的很详细，但是绝对需要通过这样的步骤来理顺思路，这个文档的好坏和实用程度，直接可以决定你是否能“用最少的工作（量和时间），尽早的发现尽可能多的缺陷”，写这个文档需要用到一些测试方法理论，如等价类划分、边界值、这个表那个表（汗。。。忘记了）
3． 缺陷记录：是功能测试过程中使用频率最高的文档，用于在测试过程中记录发现的缺陷，并由开发人员作为修改缺陷的依据，以及修改后测试人员进行回测的主要依据
a) 该文当也有助于分析开发人员存在的“错误集群”现象，总结易出错的地方，对缺陷多的部分做更深入的测试，并提醒开发人员避免缺陷
b) 缺陷记录填写指南：
i. 缺陷级别（即严重程度），一般由公司统一定义，为发现的缺陷进行分类，以便决定修改的缓急
ii. bug分类：区分发生的位置，是功能的，还是性能的，是有效性问题 还是其他问题等，与bug级别一起，用于决定bug的修改要求度
iii. bug状态：是标志bug的当前情况，标识是否被处置（关闭状态），
iv. 上述这些指标一般由公司统一定义（一般标准都大同小异），也会用于项目的度量
c) 缺陷记录使用时的注意点：
i. 描述bug要有三要素：在哪里，什么情况（前提）下，发生了什么样的问题
ii. 可以借助截图、引用位置、模块等方式来描述bug，目的是让开发人员能够通过您的描述立刻马上能够重现bug，即使不能重现，也能让开发人员了解到错误的所在
iii. 缺陷报告要由开发人员和测试人员共同完成，测试人员要督促开发人员填写该表以便测试后续的回测工作
iv. 如果是在执行用例的同时填写bug报告，用例的最后一列一般可以填写用例的执行结果，如果用例发生了非期望的结果，那么就要把问题记录在缺陷记录中，此时可以在缺陷记录中引用该用例的编号
4． 测试总结报告：用于报告和总结项目测试工作的执行结果，列举和统计相关测试数据，对比分析数据即工作中存在的问题为后续工作做出提示，并记录遗留的问题等
a) 总结报告的还有一个功能就是告诉项目组成员该系统已经按照测试计划的要求进行了测试，并已经达到测试计划中说明的“测试结束条件”，可以证明系统已经达到测试计划所期望的质量
b) 这份测试总结需要记录项目所有测试的结果情况，除了功能测试外，
性能测试也会被包含在内。
