一、测试计划：
对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。
二、测试方案：
描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。
三、测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。
四、测试方案是技术层面的文档，从技术的角度度一次测试活动进行规划。
五、测试计划要明确的内容：
1、明确测试组织的组织形式
○1测试组织和其他部门关系，责任划分。
○2测试组织内的机构和责任安排。
2、明确测试的测试对象（明确测试项，用于后面划分任务,估计工作量等）
3、完成测试的需求跟踪
4、明确测试中需要遵守的原则
○1测试通过/失败标准
○2测试挂起和回复的必要条件
5、明确测试工作任务分配是测试计划的核心
○1、进行测试任务划分
○2、进行测试工作量估计
○3、人员资源和物资源分配
○4、明确任务的时间和进度安排
○5、风险的估计和规避措施
○6、明确测试结束后应交付的测试工作产品
六、测试方案的具体内容：
○1、明确策略
○2、细化测试特性（形成测试子项）
○3、测试用例的规划
○4、测试环境的规划
○5、自动化测试框架的设计
○6、测试工具的设计和选择
七、测试方案需要在测试计划的指导下进行，测试计划提出“做啥”，而测试方案明确“咋做”。
八、详见测试计划模板和测试方案模板

“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。
　　 产品基本情况调研：

　　这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。

　　具体的要点有：

　　目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置， 粗略的估计测试大致需要的周期和最终测试报告递交的时间。

　　变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。

　　技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。

　　产品规格：就是制造商和产品版本号的说明。

　　测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。

　　项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。

　　测试需求说明：

　　这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有：

　　功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。

　　设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

　　整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。

　　测试的策略和记录：

　　这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下：

　　公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。

　　测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。

　　特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。

如同代码是程序员的成果之，测试报告是测试人员的丰要成果之一。一个好的测试试报告建立在测试结果的基础之上，不仅要提供必要测试结果的实际数据，同时要对结果进行分析，发现产品中问题的本质，对产品质量进行准确的评估。

   分析的对象和内容：测试的覆盖率、缺陷分析、产品总体质量分析、过程分析等。

    1测试的覆盖率

    ·  语句覆盖率：检测在软件测试时代码语句执行覆盖率。

    ·  分支覆盖率：用于分析被测软件在进行软件测试时分支的执行情况。

    ·  子程序调用覆盖率：判断某一程序是否调用了所有应该调用的子程序，或判断所

        有的子程序是台被调用过。此指标杠系统集成测试时很有用。

    ·  数据值覆盖率：检测程序中变量在测试时是否包含了所有可能值。

    ·  面向对象覆盖率：多态类的覆盖、模式化的覆盖、继承的覆盖。类的状态决定它的行为，需要确认每一个对象独直状态的代码覆盖率，或测试每一个类或子系统独立线程的覆盖率。例如，通信西议类有很多状态：初始化状态、正在连接状态、已连接状态和出错状态等。

    ·  Mc／Dc代码覆盖率：支持RTC‘A DO-178B标准。

    2 bug分析

    ·  №分布：在程序模块的横向分布，在时间上的纵向分布。

    ·  测试的效率：根据丢失的bug数日和发现的总bug数，可以了解测试的效率。也可咀根据执行的总测试用例数，计算H1每发现一个bug所需要的测试用例数、测试时间等，对不同阶段、不唰模块、不同人员等进行对比分析。

    ·  程序的质量：通过对每千行代码所含的bug数分析，了解程序代码质量。

·  开发解决bug的能力或状态。

  3产品总体质量分析

  传统的软件测试，只针对软件产品开展，找到缺陷之后冉加以改正和修补，这是一种“亡羊补牢”的质量管理方式。而针对开发全过程所开展的软件测试和过程度量，则注重事先分析，通过对已发生的数据对比、统计、时间序列等分析，来判断软件产品质量的未来趋势，并提前予以控制和预防，属于一种“防忠于末然”的质量管理方式。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避，这不仅缩短了对缺陷的反馈周期和整个项目的开发周期，而且也会在较大程度七降低软件产品开发用在修正软件缺陷时所支付的成本。对测试的结果进行整理、归纳和分析，一般借助于Excel文件、数据库和_些直方图、圆饼图、趋势图来进行分析和表示。主要的方法有对比分析、根本原因(root cⅫase)查找、问题分类、趋势(时间序列)分析和其他统计分析等。

    ·  对比分析：用软件执行测试结果与标准输出的对比工作，因为可能有部分的输出内容是不能直接对比的(比如，对运行的时间的记录，对运行的路径记录，以及 测试对象的版本数据等)，就要用程序进行处理。

    ·  根本原因查找：“分析”是找出不吻合的地方并指出错误的可能起因。

    ·  问题分类：“分类”包括各种统计上的分项，例如，对应的源程序位置，错误的严重级别(提示、警告、非失效性错误、失效性错误或别的分类方法)，新发现的还是已有记录的错误。

    ·  趋势(时间序列)分析：根据所发现的软件缺陷历史数据进行分析．预测未来情况。

    ·  其他统计分析：通过对缺陷进行分类，然后利用一些成熟的统计方法对已有数据进行分析。因为已了解程序开发中主要问题或产生问题的主要原因，从而比较容易提高软件质量。

4．3 CMM思想和结构体系

  cMM(capabil时M蚰Ⅱ时Model)即软件能力成熟度模型，是向软件组织提供如何增

加对其开发和维护软件过程的控制能力。设计并实施cMM是为了指导软件组织达到以下要求。

    ·  确定当前过程的成熟度等级，识别出对软件质量和过程改进至关重要的问题，选择其过程改进策略。

    ·  通过关注一组有限的活动，并为实现它们而积极工作，组织能稳步地改善其软件过程，使其软件过程能力持续不断地增长。

重新构建和维护是否经济?

　　Maintainability 可维护性

　　-Analyzability可分析性

　　-Changeability可更改性

　　-Stability稳定性

　　-Testability可测试性

　　Portability可移植性

　　-Adaptability适应性

　　-Localizability本地化

　　-Reusability可重用性

　　详细的定义可以从ISO-9126找到。

　　Quality assurance is more than testing

　　质量保证不仅限于测试

　　QA是为了最小化风险和错误并让产品更加优秀而做的所有事情。包括：

　　风险管理

　　顾客参与

　　开发人员的技能

　　过程定义和改进

　　检查和测试

　　基于经验的改进

　　…

　　Testing is hard to do

　　测试不是简单的事情

　　测试很难做，因为你必须预料到你的用户使用的数据、具备的技能、采取的动作、对软件的期待、使用环境等。

　　测试很难做，因为你检查的产品通常具备以下的特性：

　　不可见的

　　不稳定的

　　易变的

　　复杂的

　　不熟悉的

　　测试很难做，因为你要使用的过程通常是：

　　冗长的

　　不明确的

　　不一致的

　　乏味的

　　费力的

　　测试很难做，因为你要找的问题很多是不可想象的。

　　想想下面的工作量：

　　1、各种各样的功能、输入数据、状态

　　2、产品要支持的各种平台

　　3、系统的各种外部因素

　　4、测试的只是所有情况中能够想到的预期的情况

　　5、测试产品的各个版本

　　自动化测试能否解决这些工作量呢?

　　1、 人可以发现更多的问题，更准确地发现问题

　　2、 完整有用的测试自动化是一个大型的软件项目

　　3、 所用的支持工具通常都很昂贵并且古怪

　　4、测试自动化通常是滞后的

　　You can make testing easier to do

　　你可以让测试更简单些

　　既然测试这么复杂，那么开发人员对测试给与必要的尊重外，是否还能做些什么让测试更简单些呢?答案是肯定的。

　　你可以把设计文档化

　　使用内部错误检查

　　在集成之前测试每个单元

　　告诉测试人员增加了什么新特性或者有什么古怪的问题是需要进一步测试判断的

 

　　对于每个构建的版本首先自己测试一下

　　在功能层面上改进产品

　　内建一些可测性接口

　　在某些开发人员眼里，测试很神秘;在某些开发人员眼里，测试很简单;在某些开发人员眼里，测试就是质量。下面是关于测试开发人员需要知道的一些基本的东西。

　　The product is more than software.

　　产品不仅仅是软件本身

　　产品的底层是计算机、操作系统、插件等;产品还需要帮助文档、手册等配套文件;产品往往有多个版本，是新代码、旧代码、框架的融合;产品研制出来了还要有后续的支持，需要安装、技术支持、补丁等。

　　所以说产品不仅仅是软件本身，对于测试人员来说，要考虑的问题不仅仅是软件程序本身。

　　Quality is more than the lack of bugs.

　　质量不仅仅取决于缺陷数量

　　缺陷数量少不意味着质量高，质量包括的范围很广，有些不构成bug，但是也是质量问题。

　　系统工作时是否解决了所有问题?

　　Functionality 功能性

　　-Suitability适宜性

　　-Correctness正确性

　　-Interoperability互用性

　　-Compatibility兼容性

　　-Compliance 规范性

　　-Security 安全性

　　-Installability 可安装性

　　是否实用?

　　Usability 可用性

　　-Understandability 可理解性

　　-Learnability 易学性

　　-Operablility 易操作性

　　-Performance 性能

　　系统是否能持续工作?

　　Raliability 可靠性

　　-Maturity完备性

　　-Fault-tolerance容错性

　　-Integrity完整性

　　-Recoverability可恢复性

　　-Safety 安全性

　　是否充分利用系统资源?

　　Efficiency 效率

　　-Storage 容量

　　-Processing处理能力

今天看文章说微软的文档注重实用主义，搜索了下未搜索到，只能感慨下微软的理念很好，并摘抄几句话留待思考。

微软的测试计划中更注重的是测试思路，或者说这就是一份测试设计文档，而对于其他的诸如测试人员，测试进度，测试方法等等内容却没有介绍，总之他们的测试计划目的是让读者看了就对整个测试区域的测试思路很了解，甚至可以直接由此来组织生成用例，这样看来这份测试计划的使用性就更加强了。加上前些日子在上一个项目写测试报告时候，我所看到的微软测试模板，也是关注的是测试结果和分析，而对于测试的执行，测试人员等一些信息却很少介绍或者没有介绍。这样看来，微软内部文档的实用主义观念是相当深入人心啊，而且个人看来这种实用主义对于测试本身是相当有用的。

另外一张关于书籍整理的帖子在这里：http://bbs.51testing.com/thread-30935-1-1.html

软件测试（第二版）中文//英文版 //有效软件测试：http://bbs.51testing.com/thread-52050-1-1.html

林锐的 软件工程思想漫谈：http://bbs.51testing.com/thread-75272-1-1.html

经典软件测试网站：http://bbs.51testing.com/thread-51985-1-1.html

感谢syanhang和zp19864035共享私藏资料，“05-07软件评测师试卷及答案”及“Loadrunner中参数的设置” 3楼更新

１楼上传软件测试国标文档模板

关注中！ 不定期上传相关资料

9楼有最新更新自动化测试方面资料

LoadRunner自动化测试工具的应用.pdf
软件测试.rar
测试的基本概念.pdf
TesterExam.pdf
软件测试活动.pdf
指南：测试用例.pdf
测试用例设计指南.pdf
测试新手学习宝典.chm
软件测试从这里开始V1[1].0.0.0.pdf
UnitTest.chm
QTP8_Tutorial_cn.pdf
LoadRunner自动化测试工具的应用（讲稿）.rar
测试报告和用例.rar
TD程序员操作手册.pdf
software_test.pdf
测试管理实施方案V2.0.doc
SP-LoadRunner.doc
SP-QuickTestPro.doc
测试用例.pdf
嵌入式软件结构化测试方法.pdf
软件测试月刊.pdf
软件测试专刊.pdf
如何在 LoadRunner 脚本中做关联 (Correlation).doc
性能测试经验.doc
SP短信业务接口功能测试大纲.doc
LoadRunner压力测试实例.pdf
一详细用例.doc
面试题目－测试.doc
白盒测试.rar
Web下的整体测试 .doc
常规测试方法.doc
QuantifyManual_cn.rar
RationalQuantify中文使用说明.zip
QTP8 Tutorial_oldsidney.pdf
WR76_Tutorial_cn.zip
BugFree1.0.zip
bugzilla-2.20-cn-1.0.zip
测试计划模版.doc
常用的功能测试方法！.doc
测试人员考试试题试卷部分答案.doc
QTP学习与实践经验总结1.doc
QTP学习与实践经验总结2.doc
QTP学习与实践经验总结3.doc
QTP学习与实践经验总结4.doc
QTP学习与实践经验总结5.doc
[ebook] addison wesley - effective software testing.pdf
addison wesley - test-driven development by example (2002).chm
2005年上半年软件评测师级试题.pdf
cntesting 测试计划.doc
cntesting 测试用例.doc
软件测试工程师试题发布版.rar
软件测试培训.rar
有效软件测试——提高测试水平的50条建议.php.rar
FD-PE-00-W（测试报告）.doc
软件本地化测试外包流程分析.pdf
软件项目验收测试流程.doc
单元测试用例模板.doc
单元测试用例设计.doc
单元测试用例设计范例.doc
中英文对照表.xls
webservices压力测试总结.rar
Main_Users_Guide[1].part1.rar
手机测试计划.doc
压力测试开始准备工作.doc
软件测试的常识 .doc
测试中的常见问题－测试技术部分.rar
测试中的常见问题－测试流程部分.rar
测试中的常见问题－基础知识部分.rar
测试中的常见问题－其它部分.rar
webservices压力测试总结.rar
用webload进行web系统压力测试.rar
测试工具的选择和使用.doc
功能和性能测试经验谈.doc
SQA方面的:EPIGS_quality_project.doc
          SQAPPT.ppt
          软件SQA PPT.ppt
          QualityManageActivity.pdf