我们公司为什么要软件测试？软件是我公司的产品，既然是产品，理论上未经检验的产品是不允许投入市场，把我们的客户当做测试人员，把客户的机器和客户的厂房当做巨大的试验场，一旦出现bug，轻则反复远程，更严重的则是我公司人员到现场维护，这不但导致了我部门人力物力的无谓消耗，增加了公司的成本，同时也是对我公司多年来一辈一辈创业者积累下的口碑的无形损害。

在我公司从事的行业，口碑比技术更重要，做软件其实做的就是口碑。

因此，我公司需要测试部门在产品发布之前，进行反复细致专业的检测和DEBUG一个规范化的软件测试过程通常须包括以下基本的测试活动。

·拟定软件测试计划·编制软件测试大纲·设计和生成测试用例·实施测试·生成软件问题报告对整个测试过程进行有效的管理实际上,软件测试过程与整个软件开发过程基本上是平行进行的。

测试计划早在需求分析阶段即应开始制定,其它相关工作,包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等也应在测试阶段之前进行。

充分的准备工作可以有效地克服测试的盲目性,缩短测试周期,提高测试效率,并且起到测试文档与开发文档互查的作用。

此外,软件测试的实施阶段是由一系列的测试周期(Test Cycle)组成的。

在每个测试周期中,软件测试工程师将依据预先编制好的测试大纲和准备好的测试用例,对被测软件进行完整的测试。

测试与纠错通常是反复交替进行的。

当使用专业测试人员时,测试与纠错甚至是平行进行的,从而压缩总的开发时间。

更重要的是,由于专业测试人员丰富的测试经验、所采用的系统化的测试方法、全时的投入,特别是独立于开发人员的思维,使得他们能够更有效地发现许多单靠开发人员很难发现的错误和问题。

制定成功的测试计划“工欲善其事，必先利其器”。

专业的测试必须以一个好的测试计划作为基础。

尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。

测试的计划应该作为测试的起始步骤和重要环节。

一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。

产品基本情况调研：这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。

对于大的测试项目，还要包括测试的目的和侧重点。

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

变更：说明有可能会导致测试计划变更的事件。

包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。

技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。

每一个部分是怎么实现数据更新的。

还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。

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

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

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

测试需求说明：这一部分要列出所有要测试的功能项。

凡是没有出现在这个清单里的功能项都排除在测试的范围之外。

万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。

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

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

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

测试的策略和记录：这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。

要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下：公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。

测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。

测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。

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

经验判断：对以往的测试中，经常出现的问题加以考虑。

设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。

测试资源配置：项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。

计划表：测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。

问题跟踪报告：在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。

问题描述尽可能是定量的，分门别类的列举，问题有几种：1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。

2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。

3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。

测试计划的评审：又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。

结果：计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。

报告软件测试错误的规范报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误，从而有利于分析错误产生的原因，定位错误，然后修正之。

因此，报告软件测试错误的基本要求是准确、简洁、完整、规范。

需要掌握的报告技术归纳如下。

1. 描述 (Description)，简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置描述要准确反映错误的本质内容，简短明了。

为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。

例如记录对话框的标题、菜单、按钮等控件的名称。

2. 明确指明错误类型：布局、翻译、功能、双字节根据错误的现象，总结判断错误的类型。

例如，即布局错误、翻译错误、功能错误、双字节错误，这是最常见的缺陷或错误类型，其他形式的缺陷或错误也从属于其中某种形式。

3. 短行之间使用自动数字序号，使用相同的字体、字号、行间距。

短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。

4. UI要加引号，可以单引号，推荐使用双引号。

UI加引号，可以容易区分UI与普通文本，便于分辨、定位缺陷或错误。

5. 每一个步骤尽量只记录一个操作保证简洁、条理井然，容易重复操作步骤。

6. 确认步骤完整，准确，简短保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。

7. 根据缺陷或错误类型，选择图象捕捉的方式为了直观的观察缺陷或错误现象，通常需要附加缺陷或错误出现的界面，以位图的形式作为附件附着在记录的“附件”部分。

为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。

为了迅速定位、修正缺陷或错误位置，通常要求附加中英文对照图。

8. 附加必要的特殊文档和个人建议和注解如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。

有时，为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。

9. 检查拼写和语法错误在提交每条缺陷或错误之前，检查拼写和语法，确保内容正确，正确的描述错误。

10. 尽量使用业界惯用的表达术语和表达方法使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。

11. 通用UI要统一、准确错误报告的UI要与测试的软件UI保持一致，便于查找定位。

12. 尽量使用短语和短句，避免复杂句型句式软件错误管理数据库的目的是便于定位错误，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。

13. 每条错误报告只包括一个错误每条错误报告只包括一个错误，可以使错误修正者迅速定位一个错误，集中精力每次只修正一个错误。

校验者每次只校验一个错误是否已经正确修正。

以上概括了报告测试错误的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。

此外，经常阅读、学习高级测试工程师的测试错误报告，结合自己以前的测试错误报告进行对比和思考，可以不断提高技巧。

软件测试的对象是什么？软件测试并不等于程序测试。

软件测试应该贯穿整个软件定义与开发整个期间。

因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。

在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来。

软件测试的任务是什么？第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。

第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。

第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。

如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。

因此软件测试的第三个目的是保证整个软件开发过程是高质量的。

1．寻找Bug；2．避免软件开发过程中的缺陷；3．衡量软件的品质；4．关注用户的需求。

总的目标是：确保软件的质量。

软件测试的原则是什么？结合我公司业务实际，我提出我部门未来软件测试工作的构想测试小组最好有两人以上构成，对测试错误的结果一定要有一个确认的过程，A测试出来的结果，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。