按照软件设计文档，如何在项目开发过程中的开展测试工作
1. 测试计划：有条件的测试计划，应该是在整个项目的一开始就要着手制定，在后面突然加入的只能算是变化，而不是计划，整个项目的负责人应该有宏观的把控。
a) 测试计划，计划制定的指标，重点在于主要是给测试工作一些指南，不能写成领导看的计划，而是要写成由做事的人看的计划。
b) 包含的内容可能有：
(1)测试团队分析。测试团队人员及分工(要确定当测试时出现缺陷界定、测试环境准备等问题时能找到指定的人员)
(2)测试时限分析。测试开始结束时间(理想情况下，不要安排的太紧，赶工肯定会造成延期或测试不完整，可惜理想和现实的差距被规定为很大)。
(3)测试环境分析。测试环境配置(什么样的硬件条件，是否网络、设备等，系统在什么地址访问，访问权限、使用的测试数据等方面的预计和准备)。
(4)测试内容分析。测试哪些东西要说清楚，这里我建议把简单的测试大纲纳入测试计划中，一方面领导可以看到你的计划写的多详细，另一方面大纲可以很好的成为编写用例的依据。
(5)测试方法分析。怎么测试要说明白，如只做系统测试，那就要写清楚不做集成测试，如果需要集成测试，就需要写明白集成顺序。另外如果需要进行性能、文档、等其他的测试也要在这个计划中写明，虽然一般这个计划都是针对功能测试，但是如果有其他测试，也要写出来并安排时间，相应测试的相关计划等也需要指明。
(6) 测试总结分析。任何的一次测试都是有生命周期，无论从开始到结束，都意味着一次经验的总结，如何摆脱无止境的测试，就得考虑成本与价值的关系，在这个过程中加强对产品生产的、市场表现等各种指标有个了解。测试结束标志(要说明测试达到什么程度可以结束测试，不能等到把所有缺陷都找出来以后才结束，因为那将是一万年)，允许缺陷存留在系统里，我们只需要找到留多少这个度就够了。
2. 测试用例：理论上这个文档是比较重要的，特别是测试工作的前期准备，入门测试领域必须会的一种思维模式，测试用例更多的是培养一种在测试过程中的一种严谨的按步骤执行的能力。但是由于实际工作中，测试用例往往比较耗时，不利于企业的产出相适应，因而，在真实的测试过程中应该减少编写测试用例，而是在空闲的时候，加强对测试用例的学习，才真正的测试过程中，稍微变化，就可以进行测试，这样才不至于测试工作延缓，严重影响到产品的上线。
3. 缺陷记录：是功能测试过程中使用频率最高的文档，用于在测试过程中记录发现的缺陷，并由开发人员作为修改缺陷的依据，以及修改后测试人员进行回测的主要依据
a) 该文当也有助于分析开发人员存在的“错误集群”现象，总结易出错的地方，对缺陷多的部分做更深入的测试，并提醒开发人员避免缺陷
b) 缺陷记录填写指南：
i. 缺陷级别(即严重程度)，一般由公司统一定义，为发现的缺陷进行分类，以便决定修改的缓急
ii. bug分类：区分发生的位置，是功能的，还是性能的，是有效性问题 还是其他问题等，与bug级别一起，用于决定bug的修改要求度
iii.bug状态：是标志bug的当前情况，标识是否被处置(关闭状态)
iv. 上述这些指标一般由公司统一定义(一般标准都大同小异)，也会用于项目的度量
c) 缺陷记录使用时的注意点：
i. 描述bug要有三要素：在哪里，什么情况(前提)下，发生了什么样的问题
ii. 可以借助截图、引用位置、模块等方式来描述bug，目的是让开发人员能够通过您的描述立刻马上能够重现bug，即使不能重现，也能让开发人员了解到错误的所在
iii.缺陷报告要由开发人员和测试人员共同完成，测试人员要督促开发人员填写该表以便测试后续的回测工作
iv. 如果是在执行用例的同时填写bug报告，用例的最后一列一般可以填写用例的执行结果，如果用例发生了非期望的结果，那么就要把问题记录在缺陷记录中，此时可以在缺陷记录中引用该用例的编号
4. 测试总结报告：用于报告和总结项目测试工作的执行结果，列举和统计相关测试数据，对比分析数据即工作中存在的问题为后续工作做出提示，并记录遗留的问题等，总结报告的还有一个功能就是告诉项目组成员该系统已经按照测试计划的要求进行了测试，并已经达到测试计划中说明的“测试结束条件”，可以证明系统已经达到测试计划所期望的质量。