本文以一个工作流测试项目为例， 总结了在测试过程中积累的经验，探讨了目前国内软件开发企业在软件测试过程中遇到的问题以及解决的方法。测试项目背景和实施情况工作流在某公司软件产品线中占有重要地位。

Workflow项目是5系列中的一个小版本，主要增加了任务代办、任务代理、以及任务交接等功能，同时还修复了一些易用性和功能性的Bug。下面，我们大概介绍一下这个项目的实施情况：

● 项目规模与测试人员配置：

○ 项目代码行数：5万行

○ 开发人员配置：开发人员5名、实习生1名

○ 测试人员配置：测试设计人员1名、测试执行人员2名、实习生1名

● 项目测试时的系统部署情况:

● 测试预期与测试执行情况整个测试项目是比较成功的，项目的时间执行情况和预期的测试指标度量都比较接近。发现Bug总数和缺陷密度都达到了要求的标准。当然，测试周期的实际值比计划值晚了两周，原?因是在系统测试后期，为了满足PSO部门提出的定时器需求造成了一定的延期。回顾整个项目的测试过程，我有几点小小的感悟，愿在此和大家一起分享。

测试如何尽早介入

基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格按照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和（很多测试人员无所事事），而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点地工作。但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如：

● 测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。

● 测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。那么，在这个XXX5.2 Workflow项目中我们是怎么做的呢？实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如：

● 评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求是测试设计的基础。

项目管理者联盟，项目管理问题。

● 在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案是测试用例的保证。

● 和项目团队中的集成组和开发组协?商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。

● 开发人员每天下午4：30之前提交所有可编译的代码，每天晚上进行日编译； ● 开发经理根据版本稳定情况，每周提交测试申请单。

● 测试人员根据测试进度需要，提取测试版本。

● 提前准备测试环境，包括数据库环境，操作系统和web应用服务器，以及复杂集群环境。

● 如果项目需要，还可以在此阶段研究一下自动测试工具，包括一些准备外包测试的工作。根据产品的成熟度调整测试策略开发测试一盘棋。测试经理应该有大局观，保持测试策略总与开发的进展相一致，保证最终的软件成果最佳（而不是测试部发现Bug数最多）。在这个XXX5.2 Workflow项目过程中，我们合理制定了不同阶段的测试策略，收到了很好的效果。

产品开发期同情的测试

要忍！要在这个能够发现大批Bug的黄金时段学会做减法。就现实而言，这个阶段的产品，大多难以满足系统测试的条件。如果进行穷兵黩武式的测试，无疑会加重开发人员的焦虑心情，甚至对测试产生逆反心理。另一方面，测试工作不应停滞，特别是不少测试人员对产品的了解还流于皮毛，抓紧时间进行“测试练兵”非常有必要。因此，“产品开发期”的测试切忌生硬。其实，此时程序人员也知道产品还不成熟，所以要告诉测试执行人员：

● 这个阶段不要提交界面简单错误和易用性方面的Bug（可以先记录下来到项目末期提交），否则会使开发人员质疑测试人员只会发现简单的Bug。

● 换位思考，了解此时开发人员最关心的是功能是否能正确运行，多对基本功能进行测试。

产品成熟期积极的测试

随着产品的不断成熟，主要功能的实现已经趋于完善，关键路径的测试已经不成问题。此时的程序员们，压力已经大大减轻，他们的工作重点也从“构建”转移到了“修复Bug”，这个阶段程序人员对于Bug的接受程度是最高的，对Bug的修复和反馈也非常积极。于是，此时的测试工作应对整个产品的细节和所有路径进行覆盖测试，保证测试的全面性，层层深入地测试产品值得测试的各个部分，尽可能多的发现并报告Bug。

产品稳定期多样的测试

在这个阶段，可以尽情的向开发人员报告产品易用性和界面的Bug；可以充分发挥每个测试人员的想象力，根据以往的测试经验来搭建测试场景，构造测试数据；可以通过不同业务场景的不同操作，通过特殊的测试数据，以及相对复杂的集群测试环境来进行多样化测试。为什么？因为此时必须测试得更加深入，才能发现更深层次的Bug，于是多样性的测

试、探索式的测试必不可少。产品发布期谨慎的测试在临近产品发布的日子，包括测试在那的很多工作都变得谨慎起来：代码的提交权限受到了控制，只保留开发经理一个入口；测试的重点更加具有防御性，要仔细测试每个变更，还可以组织“结对测试”来增加测试的保障。测试经理应知人善任为了保证测试工作的质量，首当其冲地就是应该有专业的测试团队。在很多小的软件项目中，往往没有专门的测试团队。这样一来，到了代码基本完成之时，就只能从客户支持部门或研发部门抽调一些人手临时拼凑出“测试团队”进行几周的测试工作，测试质量难以保证。我们则会尽早规划测试团队的人员结构，完善测试团队的配置。每个测试人员的特点和强项常常不尽相同，例如，擅长测试数据质量的测试员，未必能胜任系统环境配置复杂的测试任务。总之，对测试经经理而言，做到知人善任非常重要。同时，在项目测试过程中及时进行调整有时也很必要。此次测试的工作流系统，要求测试人员不仅应掌握一定的工作流业务知识，还需要有较强的逻辑思维能力。而在此项目测试过程中，笔者发现一位测试人员对功能的细节过分关注，而对整个工作流程总是理解不到位。显然，其设计出的测试用例不能适应工作流测试的要求。于是，立即进行人员分工和测试任务的调整，保证了测试工作顺利进行。坚持立场，规范流程我们公司有严格的测试流程，所有提交测试的软件版本，在提交之前，都要完成必需的冒烟测试（Smoking Test）。冒烟测试是一种测试包，其目标是检查版本的基本功能。这个测试包是由测试人员根据测试用例中级别为“基本”的测试用例抽取出来的，如果该版本没有通过冒烟测试，则就可以说明该版本不太稳定，不值得提交测试人员进行系统测试。有的公司冒烟测试是由测试人员手工或者自动测试。在我们这个项目中，为了保证每个可测试版本的冒烟测试质量，是由开发人员负责完成的。他们知道，如果程序不能通过冒烟测试，测试小组就会拒绝该版本。因此，他们会填写一份提交测试申请表来申请进行系统测试。在这份表格中，不仅会明确版本号，修改或新增的功能详细说明，还会给测试人员提供此版本的测试重点，以及可能会影响到的功能。这些内容对测试人员都是至关重要和大有裨益的。

在项目测试过程中，我们也出现过打回某个版本的情况，拒绝测试。总结起来，基本上有以下几种情况：

● 由于任务查询的技术难度比较大，开发进度已经延期了5天，测试人员正在焦急的等待这部分的功能测试。可是，新提交的可测试版本中，这个功能根本就不能使用，如果进一步测试就是浪费时间，我们立即打回了这个测试版本。

● 新增了代办的功能，可是以往的代理功能中的增加代理人功能却不能正常使用，而增加代理人功能又是代办功能的基础，也就是说，在这个版本中，及时代办功能完全能够测试，可离开了增加代理人功能，代办测试是没有意义的。

● 在回归测试阶段，可测试版本的提交是比较频繁的。开发人员一旦解决了一部分bug就会提交一个可测试版本，如果此时测试人员并不急需更换版本，并且得知另一个版本会在几个小时之后就会完成，我们可以不测试这个版本。为了能更好的完成冒烟测试这个关键阶段，测试人员积极与开发人员配合：

● 负责提供冒烟测试案例。

● 如果测试人员处于版本等待阶段，主动和开发人员一起做冒烟测试。开展有效测试，提高测试效率有效的测试用例是软件测试成功的关键，有助于提高测试效率和测试覆盖率。在这个工作流软件测试项目中，我们从测试模型（Test Model）入手，结合丰富的测

试经验和专业知识，从繁多的测试用例中挑选出有效的用例，用尽可能少的测试输入，覆盖尽可能多的软件需求。主要采用了状态机模型和组合模型，并结合了正交设计技术和组合覆盖技术，完成了对整个系统的测试设计。详细内容可以参考笔者在《程序员》杂志20xx年第4期上的文章《基于模型的有效测试用例设计——工作流系统测试实战》一文。知己知彼，合力制胜提供服务使测试人员有机会赢得程序员的信任，同时也有机会展示自己的才能。同时，带来的回报是得到了开发人员对我们的帮助。在整个项目过程中，我们获得了很好的回报，比如：开发人员讲解设计思路、算法流程；和测试人员一起构造测试数据；积极参加每日测试例会，主动解决问题等。这样良好的合作状态与测试人员的主动努力是分不开的，主要体现在：

● 获取程序员信任，及时沟通不要与被测程序的开发人员形成不必要的敌对关系。如果能与打交道的程序员共享信息，比如他们的计划、设计文档的早期草案和早期原型等，测试工作会更加有效。越早与程序员接触，情况就越好。尽早提出你的意见和反馈，了解程序员提交前完成的工作。

● 主动出击，提供服务 ○ 在测试前期，直接向开发人员提供服务；这不仅可以建立信任，而且还可以证明测试人员是能够与之合作的人。我们在项目过程中提供给开发人员的服务：○ 对工作流的运算逻辑?构件进行了测试，方便了后期开发工作流客户端应用的使用。○ 对内部版本和原?型进行测试。○ 对需求文档的可测试性进行评审。开发人员和测试人员一样，对模棱两可的要求很头疼，他们非常希望测试人员的介入。○ 帮助程序员建立测试环境，方便程序员进行测试。

● 耳目作用

○ 在项目过程中，测试人员有机会能够发现很多存在的问题，比如：需求和设计以及开发的不一致性，项目计划中工作任务的缺失等等。测试人员不要仅局限于测试命令链本身，及时验证和发现项目环节中的问题。总之，测试项目能否成功，与整个项目组的精诚合作是密不可分的。测试人员是一种服务角色，要乐于接受这种角色，只有这样，才能得到被服务的人的帮助和支持，以及认可

第二篇：软件测试经验

一、有逆向思维的能力

我曾经接触过一些软件测试工程师，他们干了一段时间软件测试工作后返回去又开始去做开发工作了，问他们为啥？答案是软件测试工作太难了，开发是顺向思维，而测试是逆向思维，老要找一些稀奇古怪的思路去操作软件。软件的使用者千差万别，软件在使用过程中遇到的各种现象也是千差万别的，所以要求软件测试工程师需要具有一些逆向思维的能力，想别人所不想，测别人所不测，这样才可以找到更多的软件中的错误。这是作为一名优秀的软件测试工程师最基本的素质。

善于同软件开发人员沟通沟

通是当今软件项目中需要掌握的最关键技术之一。软件测试人员要善于同软件开发人员沟通，软件测试人员与开发人员搞好关系，使测试人员不成为开发人员的眼中钉，这对于提高整个软件项目质量是十分重要的。沟通主要包括：

讨论软件的需求，设计：

通过这样的沟通，你可以更好的了解所测试的软件系统，以至于尽可能少的测试出软件中不是错误的“错误”，从而降低给软件开发人员带来的压力。

报告好的测试结果：

作为一个测试人员，发现错误往往是测试人员最愿意而且引以自豪的结果，但是一味地给开发人员报告软件错误，会给他们造成厌恶感，降低整个软件的质量和开发进度。所以作为一名软件测试工程师，当你测试的模块没有严重的错误或者错误很少的时候，你不妨跑到开发人员那里告诉他们这个好消息，这会给你带来意想不到的结果。

讨论一些与工作无关的事情：

作为一个测试人员经常和开发人员讨论一些与工作无关的事情，比如大家可以谈谈新闻，趣事，家庭?这样可以加强相互间的默契程度，许多统计表明，这样可以更好的提高软件工作质量。

善于同领导沟通

测试人员往往是领导的眼和耳，领导根据测试人员的测试结果可以了解公司的产品质量，从而调整其他的工作。领导工作一般比较繁忙，所以作为一名优秀的测试人员要学会把测试结果进行总结，最好以图表的形势给领导看。

掌握一些自动化测试工具

测试工作往往是比较繁琐，枯燥无味的工作，测试人员长期处于重复的手工工作，会降低测试效率，并且对于测试质量也往往是不利的；况且许多测试不使用测试工具是不可以进行的，比如性能测试，压力测试等等。目前市场上有许多测试工具供你使用，你可以根据自己的需要选择一些测试工具来辅助你的测试。但是要记住一点，不是说有了测试工具就不要人工测试了，测试工具不是万能的。

善于学习的能力

软件测试技术随着时间的变化也在做一些提高和改进，作为一名优秀的测试人员要善于利用书籍，网站，论坛，交流等各种途径不断提高自己的软件测试水平。

提高自己的表达能力

软件测试人员当发现软件中存在缺陷的时候，往往要书写缺陷报告，缺陷报告要写得详尽清楚，使开发人员能够尽快定位错误，修改错误，所以作为一名优秀的测试人员提高自己的写作能力是非常必要的。

了解业务知识

更好的了解你说测试软件的业务知识是非常重要的，对业务知识了解得越深入，越能够找出更深入，更关键，更隐蔽的软件错误

二、软件测试还有一个很重要的问题 –

何时应当停止测试？对于许多企业来说，终止测试的时间往往是随产品的预定发布时间或交付时间来定的。甚至有的地方产品发布或交付前一周还在写新功能。每一个测试人员都在叫测试时间不够，但又没有谁能说出到底多少时间才算够。

其实问题也很简单，一个合理的测试终止条件只能来源于一个清晰的测试目标。如果测试的目标是找到所有的缺陷，那么无论多少时间都是不够的。而要从测试的两个经济目标来看，合理的终止条件应当是由以下两点组成：

测试是为了保证软件的质量，而软件的质量标准是由用户来决定的。这个标准应当在软件开发初期由用户需求调查所得，如果每一需求项都列出了可测试的、被共同利益者认可的标准和写入测试计划之中的测试用例，这样软件测试结束的第一个必要条件就是所有在测试计划中所列出的测试项和标准（常见的有：必要及重要的功能通过测试，某种公认的认证

测试用例包测试通过，连续无故障运行超过一定时间等）都被通过。

通常来说，早期找到并排除的缺陷越多，总的售后服务的成本就越少，但密集的测试就会导致测试成本的增高。而对测试来说，随着旧的缺陷不断地被找到并修复，软件的质量也就越来越好，后继的服务成本就越来越低，相应地，新缺陷也就越来越难找，即测试成本越来越难高。

当找到并解决的缺陷占总缺陷的比例达到 T E

时，可终止测试。因为再要通过测试去发现一个缺陷成本比发布后再去维护的成本要高了。其实从企业利润的角度来看，就要使这两部分的成本之和最小。当然在实际情况下，这两条曲线是无法准确估计的。人们往往按拇指规则，即假设残留的缺陷数与最后一阶段排除的缺陷数相等，启用这样一个较为合理的中止条件

：

当一段时间内（通常是一个星期）测试不出的新缺陷时，就可中止寻找缺陷了；或按本文提出的测试效益规则，即当找到的新缺陷的实际价值低于相同时间的测试运行费用、或测试成本与维护成本之和达最小值时、或经

3 至 5 倍企业同类软件开发项目的平均单位缺陷测试时间内测试不出的新缺陷时就可中止找缺陷了。

三、软件测试的经济目的

事实上，作为软件开发企业来说，投入人力，资金搞软件测试的最终目的还是离不开经济效益。而对与测试项目的管理也不能离开这个大前提。软件测试的经济效益主要来自以下两个方面。一是满足用户需求，提高产品的竞争力，最终提高产品的销售量。二是尽早发现缺陷，降低售后服务成本。而软件测试的最终目的就是使它带来的经济效益最大化。

满足用户需求，提高产品的竞争力，最终提高产品的销售量。

一个学生编写程序可能是为了学习语言，算法，技巧等知识。一个科研人员编写程序可能是为了验证某个理论，计算某个结果，或实现某个算法。而一个软件企业生产一个软件则只有一个目的

–

盈利。同其他所有企业一样，要盈利，首先要把用户当作上帝。只有满足了用户的需求，并能使用户用的方便、用的放心，用户才会心甘情愿地掏钱。所以作为软件品质的最后把关者，软件测试要把用户的想法放在第一位。从设计测试计划到构造测试用例，从实际进行测试到跟踪缺陷处理，都要从用户的角度去考虑每一个问题。

首先，用户花钱购买软件实际上是购买软件的功能。所以软件测试首先要保证用户所

需的功能都能正确而可靠地实现。在设计测试计划时应从用户实际可能使用本软件的基本流程或典型使用脚本出发，分析各个功能的重要性和相关性，再根据现有资源及时间构造和筛选测试用例。

其次，要想保住老用户、吸引新用户，产品的质量是关键。对于一个传统工业企业来说，一个产品的质量也许可以用一连串的行业指标来界定；而对软件企业来说，一个软件的质量是完全由用户来评价的。用户对软件质量的评价通常包含下列五个方面：

? 可靠性

? 安全性

? 性能

? 易用性

? 外观

因而软件测试也要针对这几个方面构造相应的测试用例。

四、什么是软件测试

在《 The Art of Software Testing

》一书中表述的观点：

① 程序测试是为了发现错误而执行程序的过程；

② 测试是为了证明程序有错，而不是证明程序无错误；

③ 一个好的测试用例是在于它能发现至今未发现的错误；

④ 一个成功的测试是发现了至今未发现的错误的测试。

但是软件测试 决不等同于找 BUG 。

不幸的是，仅凭字面意思理解这些观点，认为发现错误似乎是软件测试的唯一目的，这样就可能会产生一些误导。认为查找不出错误的测试就是没有价值了；一些软件企业在制定对测试组（人员）的业绩考核标准时，简单地把捕捉到缺陷个数作为主要考核指标。然而事实并非如此简单。那些把寻找缺陷当作是软件测试的唯一目的的测试管理人员往往会陷入一个又一个测试管理误区。

以下列出是作者总结的六个值得业界重视的误区。

误区一：忽视对正常输入的测试。

软件缺陷最常见的地方是哪里？一般来说软件缺陷最为密集的地方就是当用户输入非正常输入组合时。一方面软件设计人员较容易忽略一些极难发生的情况，另一方面设计与开发人员往往会把更多的精力用在功能实现上，容错与错误处理往往是开发上的薄弱环节。所以当测试人员将测试目标订在缺陷数量上时，重点测试非正常输入显然就是最好的手段。

然而对于用户来说，真正影响使用的却是正常输入组合激发的缺陷。而这种缺陷，一个就已经太多了。

例如对于一个记事本软件，也许没有人会去注意为什么将字体大小设置到大于 49151

的正整数时，每个字会突然变成一个小点。也许很少人会去在乎若将字体大小设置到超过窗口高度时右方的滚动卷标不能滚动到一个能让你看到某一个字的下半截的位置。但若使用一般的剪贴功能会将一段话搞成乱码，那每一个用户就都会跳起来了。

误区二：忽视设计阶段的参与与评估

在多数企业里，软件的设计阶段往往没有软件测试人员的参与，甚至有些企业在编码几乎完成了才开始组织测试团队。原因无他，设计还没定型呢，怎么找缺陷哪？

事实上设计上的缺陷往往是耗用成本最高，也是最难在开发后期修复的缺陷。而一个软件的质量与它有多大的设计缺陷有着密不可分的联系。而有经验的测试人员的质量意识，安全意识，对用户需求的了解及分析能力，对于打造高品质的软件设计都有着不可忽视的作用。

同时对于技术可行性与用户需求之间的设计妥协，测试人员也必须要有充分的评估和理解。这样在最紧张的开发后期，才不会把大量的（测试及开发人员的）宝贵时间用于记录和处理那些已在设计阶段确定放弃的功能。

误区三：忽视测试计划与测试文档的建立及维护。

设计测试计划与建立测试文档常常会被看作是浪费时间。即使做了也只是为了交差，要么敷衍了事，要么找个范本一抄，略作修改便万事大吉。真正测试起来还是全靠灵感与直觉。

但软件测试的另一个重要目的是确认及评估一个软件是否能够符合用户的需求。而对软件质量的保证不能只是靠测试人员一开金口，而要靠详细的测试计划以及完整的测试结果来取得用户的信任。

误区四：忽视缺陷的分析，报告及跟踪。

找到缺陷本身并不能提高软件的质量。只有缺陷被正确修复了才能真正提高软件的质量。作为一个好的测试人员不仅仅要善于发现缺陷，同时还要善于描述缺陷的表现特征，并积极跟踪缺陷的处理过程，确保缺陷被正确诊断及修复。不负责任的缺陷报告常常会给软件开发人员带来很多不必要的麻烦甚至误导。这会严重影响开发人员对测试人员的信任与尊重。

误区五：错误的测试目标及测试终止条件。

没有缺陷的软件是不存在的。同时也没有方法可以知道一个软件中到底有多少个缺陷。一个简单的文本处理软件经过三个月的测试找到了 100

个缺陷，那说明这个软件总共有多少缺陷呢？也许是 101 个，你找到了 99% 的缺陷，也许是 10000 个你只找到 1%

的缺陷。又或连着两个星期只找到一两个缺陷，那么说是软件质量已达到较高水平了呢，还是你的测试方法走进了死胡同呢？谁也说不清。

误区六：不懂得合理调配使用测试人员的知识技能结构。

除去发现缺陷的洞察力外，好的测试人员还应该拥有很好的组织能力，准确的表达能力，严密的逻辑推理能力，以及对软件开发过程，软件使用对象，软件开发技术等的较深入地了解。同时具备所有素质的测试人员也许比凤毛麟角还要难找。所以在构建一个测试团队的时候就一定要合理搭配拥有各种能力的测试人员，并在使用的时候注意发挥各自的特长。如果让所有测试人员一心一意地找

BUG ，那不仅仅是压制了其他方面的人才，整个测试团队的实际绩效必然会大打折扣，甚至会影响到整个软件产品的顺利开发。

五、测试的原则及其它概念

测试的原则---GoodEnough

对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

Good-enough原则就是一种权衡投入 /

产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。

4、 测试的规律----木桶原理和80-20原则

1） 木桶原理。

在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

2） Bug的80-20原则。

一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

5、传统测试流程遇到的挑战和对策----问题发现得越早，解决的代价就越小

对于测试理论，主要依据软件生命周期V字模型

可见软件测试贯穿了软件开发周期的大半，其各级测试的依据是对应开发阶段的各种详细文档。测试目前主要依赖于：测试人员的经验和素质；产品说明文档和项目组的技术咨询；测试工具的使用；测试计划的设计。

6、测试分类

按功能分：

–白盒测试(Whitetest)

–黑盒测试(BlackTest)

按测试时间来分：

–单元测试(UnitTest)

–集成测试(IntegrateTest)

–确认测试(ValidationTest)

–系统测试(SystemTest)

按运行状态来分：

–静态测试(StaticTest)

–动态测试(DynamicTest)

按方向来分：

–正向测试

–逆向测试

7、测试策略：

测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、覆盖测试等）。

测试策略包括:

1、要使用的测试技术和工具；

2、测试完成标准；

3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。测试计划最关键的一步就是将软件分解成单元，按照需求编写测试计划。

把软件分解成单元有几个好处：