摘要：程序被修改后，要保证程序能正常运行并且修改不能给程序质量带来任何负面影响，
回归测试是必要的。大型软件系统结构复杂，构成要素多，如何做到不遗漏功能点同时降低软件回归测试代价，本文结合业务规则模型、修改影响分析和成本风险管理等技术提出了一种自动化回归测试方法。
关键词：回归测试风险管理修改影响分析
1、引言
在软件测试过 程中，由于需要对软件进行修改，修改后的程序必须重新测试，以确保程序的修改是否达到了目的和是否引入了新的错误，这种测试就是回归测试。软件的变化可能 是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所包含的错误被发现时，如果对错误的跟踪管理系统不够完善，可能会 遗漏对这些错误的修改；而开发人员对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，没有修改错误本身，甚至可能产生副作用，从而导致 软件未被修改的部分又产生新的问题，使本来正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对 原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。 因此需要进行回归测试。
回归测试是一种代价较高，比较耗时的测试方法，然而又是必不可少的。大型软件通常规模大，系统结构复杂，构成要 素多、层次多，在渐进和快速迭代开发中，新版本的连续发布使回归测试的实施更加频繁。因此，通过选择正确的回归测试策略来改进回归测试的效率和效果，减小 回归测试代价是非常有意义的。
2、大型软件回归测试面临的问题
大型软件回归测试面临两个重大难题：一是系统变更引起的回归测试范围无法准确界定；二是参数组合引起的测试用例急剧膨胀，无法在较短时间内以合理成本完成最低覆盖率要求的回归测试。而且大型软件回归测试往往受到测试时间和测试环境条件的约束，而测试的工程性质又决定了它不可能达到理论上的完整。
在有限的时间和资源条件下，为了更合理的规划和安排测试工作，在测试计划的制定阶段需要一个决策机制能够在资源约束，如时间、人力、成本的前提下基于风险管理和测试成本预算进行决策。
随着软件生命周期的推进，软件的开发与回归测试反复迭代，规则的表达逐渐完善，测试用例库越来越丰富，回归测试的实施效率将越来越高。
3、大型软件回归测试方法
通过构建回归测试决策支持平台可以为大型软件的回归测试提供可行的解决方案。
3.1 业务规则
业务规则是定义和约束业务结构与业务行为的规定或规范，是业务运作和管理决策所依赖的重要资源。建立大型软件业务规则模型正是要继承资深测试专家所积累 的业务知识，使事实上得到使用的规则有一种显式的表达。在此基础上，结合测试理论和规则的整合以及用例优化算法，建立自动化用例生成系统。
业务规则的来源一般包括：
1）业务需求导出的规则；
2）测试理论原则导出的规则；
3）软件业传统导出的规则；
4）业内常识导出的规则。
业务规则模型的基础是手工测试中积累的一系列用例设计规则、行业规范和源于业务的特殊约束。业务规则模型用于表达这些手工时代的规则，并建立一种可加载规则的引擎结构，在通过该引擎加载规则后，可以通过决策支持系统生成面向某个具体过程的用例模板的基础用例集。
所谓规则的加载，是将某条规则加入规则库中，重点是适用条件的表达和优化算法的指定。
对于一个目标系统，一次穷尽所有可能的规则是不可能的，只能渐进地逼进，所以应该允许手工追加规则，这一过程是业务规则模型的学习过程。
3.2 修改影响分析 对于软件回归测试来说，确定修改影响的范围是至关重要的，修改的影响范围也是回归测试的目标范围。如果无法确定修改的范围，则理论上说就得把整个系统重测一遍，对于大型软件，这种代价也是巨大的。
3.3 成本风险评估
如何在有限的时间和资源预算下，更合理的规划和安排测试工作。回归测试在实践中往往受到测试时间、测试成本、人工投入和测试对象业务关键性等约束，因此需要制定一个科学的测试计划，以保证在满足各种条件约束的前提下能够确保测试质量。
Boehm 用公式RE=P（UO）*L（UO）对风险进行定义，其中RE表示风险或者风险所造成的影响，P（UO）表示令人不满意的结果所发生的可能性，L（UO）表示糟糕的结果会产生的破坏性程度。
因此，被测试对象f中存在的风险值 Re（f）的大小可以用出错的概率与出错的代价的乘积来表达：
Re（f） = p（f）*l（f）
确定待测试对象风险因素发生的可能性及其造成的损失的过程是风险估计阶段。将风险发生的概率与风险发生造成的损失相乘，可以得到每个测试对象的风险值。
为了方便对风险进行定量的估计，采用等级评定的方法对出错代价和出错概率进行表达。其中风险概率由模块成熟度和开发人员的出错预期共同计算。确 定开发方的出错预期的依据是过往的缺陷率记录，在没有缺陷记录时，所有的开发人员度成熟度都默认为高，此后，个人成熟度分值随着个人缺陷率对平均缺陷率的 相对值和个人缺陷率趋势而变化。
根据风险值的估算，可以确定待测试对象的最低测试深度。在测试深度的要求下，首先选择适当强度的测试用例简约算法进行试算，可以得出完成该对象测试需要的用例数。
由于回归测试中大量用例可以复用，计算实施成本是需要对自动生成的测试用例和手工完成的测试用例区分对待，以不同的权重进行计算，最终得出整个 测试过程的实施成本。实施成本可以表示为测试投入的人时数。根据实施成本与项目预期成本投入和时间进行比较，判断待测试对象的成本是否在可以接受的范围 里，如果可以接受，就可以根据相应简约算法生成最终需要的测试用例库。如果实施成本无法接受，可以重新调整用例简约算法，降低或者提高测试强度，重新计算 实施成本，直到满足预算要求。
4、结论
回归测试研究有着广阔的空间，尤其对于系统结构复杂，构成要素多的大型系统软件回归测试，本文提出的自动化回归测试方法，对于降低回归测试代价，提高回归测试质量和效率具有及其重要的作用。
性能计数器（Performance Counter），也叫性能监视器。一个人健康状况如何，我们通过对其做各项体检获得相关的状况指标，如血压、心跳，肺活量等。那么在做性能测试过程中，整个系统的软硬件进行监控也必不可少，监控所获得的数据也是我们分析系统性能的主要依据。
在整个系统中，对于不同的软件和硬件，我们对其监控的指标也不一样，就像一个公司中的所有人员，其每个人的职责不同，评判和考核的标准也是不一样的。下面将从系统的各个方面进行分析。
操作系统性能计数器
操作系统监控器，主要监控操作系统级别上的系统性能表现，这里分析最常见的windows操作系统与Linux操作系统。
window 操作系统的主要性能计数器
Windows操作系统的性能监控：
Window系统下的计数器比较多，主要技术器如下：
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿
Linux/UNIX 操作系统的主要性能计数器
Linux系统的命令和UXIN的有些差别，在UNIX系统下的主要计数器监控命令是vmstat、iostat、top、sar、sag(图形方式，需要XServer 支持)；而在linux中，没有isostat命令。另外他们的输出结果也稍有差别。
上面罗列了windows与linux系统下的性能计数器，分析一个操作系统的性能，应该查看哪些指标。那么操作系统的载体是系统硬件。那么硬件的性能直接影响着操作系统的性能。下面就简单分析一下系统的硬件。CPU、内存、磁盘。
CPU分析
CPU的性能对于计算机整体的性能起着主导作用。对于早期对计算机甚至直呼其CPU的型号，如 386 、486、奔三，奔四。
那么我们CPU性能最直接的评估就是查看其CPU工作频率，就是CPU的时钟频率，单位为是Hz。随着CPU的发展，主频由MHz现在的GHz
（1GHz=1000MHz=1000000KHz=1000000000Hz）
处理器除了主频指标外，还有另外两个密切相关的概念：倍频与外频。外频是cpu的基准频率，单位是MHz。外频是 CPU与主板之间同步运行的速度，而且目前的绝大部分计算机系统中外频与是内存与主板之间的同步运行速度，在这种方式下，可以理解为CPU的外频直接与内 存相连通。实现两都的同步运行状态；倍频即主频与外频之间的倍数。
主频 = 外频 * 倍数
如何真对CPU进行分析？
1）查看System\%Total Processor Time 性能计数器的计数值。
该计数值用于体现服务器整体的处理利用率，对于多处理器来讲，该数值体现的是所有CPU的平均利用率。如果该数值大于持续大于90% ，表示CPU有可能存在平静。
2）查看每个CPU的Processor\%User Time
Processor\%User Time是指系统的非核心消耗的CPU时间，如果该值较大，可以考虑通过算法优化来降低该值。如果该服务器是数据库服务 器，Processor\%User Time值大的原因很可能是数据库的排序或是函数操作消耗了过多的CUP时间，此时可以考虑对数据库进行优化。
3）查看Processor\%Processor Time 和 System\Processor Queue Length
查看System\Processor Queue Length 计算器，当该计数器的值大于CUP数量的总数加1时，说明CPU产生了赌塞。但产生赌塞时，Processor\%Processor Time的值不一定很大，此时就必须查看CPU赌塞的原因。
4）查看%DPC Time
%DPC Time 是另一个需要关注的内容，该计数值越低越好。在多CPU系统中，如果该值大于50% 并且Processor\%Processor Time值非常高，则考虑加一个网卡来提高性能。
磁盘I/O分析
硬盘应该是计算机硬件中发展最慢的设备，很多常见瓶颈都是由于硬盘的读/写速度慢导致的。提高硬盘读/写性能无非是 提高转速、提高单碟容量，增加缓存和更新接口，因为传统的硬盘是物理旋转读写数据，所以转速的提高相当困难；而提高单碟容量也存在一写的技术瓶颈，1TB 的单碟的容量想要突破还也需要时间。
对于传统的温氏硬盘到现在速度也只能达到120MB/s的读取速度，这个速度还真对大文件的读写，而对于服务器大量 4KB的小文件读/写速度，会惊人的下跌至1MB不到，而对应的IOPS（每秒磁盘的读/写次数）会低得可怜，大量的数据都在排队从硬盘上读取到内存中， 再利用内存的超大带宽完成操作。这也是为什么内存大的系统比较快的原因。但内存的速度虽然比硬盘快得多，也有其致命的缺点，一旦断电，内存中的数据将全部 丢失。
IOPS（Input/Output Per Second）每秒磁盘的输入/输出量（或读/写次数），是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位。
另一个重要指标是数据吞吐量（Throughput），指单位时间内可以成功传输的数据数量。对于大量顺序读/写应用，则更关注吞吐量指标。
传统的温氏硬盘完成一个I/O请求所花费的时间包括 寻道时间、旋转延迟和数据传输时间三部分。
* 寻道时间，是指将读写磁头移动至正确的磁道上所需要的时间。目前磁盘的平均寻道时间一般在3~15ms
* 旋转延迟，是指盘片旋转将请求数据所在扇区移至读/写磁头下方所需要的时间。7200转速的磁盘，平均旋转言辞大于为60 * 1000/7200/2=4.17ms
* 数据传输时间，是指完成传输所请求的数据所需要的时间。目前SATA II 可达到300MB/s的接口数据传输速率。数据传输时间通常远小于前两部分时间。
如何分析磁盘I/O
1）与 Processor/Privileged Time 合并进行分析。
如果在Physical Disk 计算器，只有%Disk Time 值较大，其它值都比较适中，则硬盘可能会是瓶颈。若几个值都比较大，且数值持续超过80% ，内里可能是内存泄漏。
2）根据Disk sec/Transfer 进行分析
一般来说，定义Transfer 数值小于15毫秒为优秀，介于15~20毫秒之间为良好，30~60毫秒之间为可以接受，超过60毫秒则需要考虑更换硬盘或硬盘的RAID方式。（注意：各种不同的RAID其计算方式也不完全相同）
固态硬盘SSD是一种电子装置，避免了传统硬盘在寻道和旋转上的时间花费，存储单元寻址开销大大降低，因些IOPS可以非常高。
内存分析
为什么固态硬盘的无法做到内存的存取速度呢？这是因为ROM固态硬盘和RAM内存的实现原理不同导致的。
内存的发展速度已经达到了第五代DDR内存（一般用于显卡上），而我们通常主板上的使用的都是第三代DDR内存，内存的主要性指标是在读写/带宽上，而影响带宽上的指标主要是内存通道及内存频率。
现在常见的内存一般型号为DDR3 1333MHz ，我们可以通过更换更高频率或更低时序的方式来提升内存的带宽。（内存时序是描述内存条性能的一种参数）
内存频率比较好理解，现在“发烧”级别的内存频率可以做到2400MHz，相对于1333MHz的默认频率几乎有了一倍的提升，这种频率的提升，可以换来带宽从16GB到24GB的提升，如果再能降低时序，那么结果会进一步提升。（关于内存时序概念请参考其它文献）。
另外一个提升策略就是通道，简单来说就是让多根内存并行和内存控制器进行交互，从而成倍地提升吞吐能力。对于内存比较了解的朋友，双通道、三通道甚至四通道这些名词应该不会陌生。
内存分析指标
1）查看Memory\Available Mbytes指标。
这个计数器是描述系统可用内存的直接指标，在对系统进行操作系统级别的内存分析时，首先通过这个指标建立一个初步的印象，了解性能测试过程中系统是否仍然有足够的内存可用。
如果这个指标的数据比较小，系统可能出现了内存方面的问题。
2）Pages/sec、Pages Read/sec 和Page Faults/sec指标
操作系统经常会利用磁盘交换的方式提高系统可用的内存量或内存的使用效率。这三个指标直接反映了操作系统进行磁盘交换的频度。
如果Pages/sec 的计数器持续高于几百，很可能会有内存方面的问题产生，但Pages/sec的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所导致。 Page Faults/sec 值表示每秒发生页面失效的次数，页面失效次数越多，说明操作系统向内存读取的次数越多。些时还需要查看Pages Read/sec 的计数值，该计数器的阀值为5，如果计数值超过5，则可以判断内存存在问题。
3）根据Physical Disk计数器的值分析性能瓶颈
Physical Disk 计数器的分析包括对Pages Read/sec和 %Disk Time及Average Disk Queue Length 的分析。如果Pages Read/sec 很低，同时%Disk Time和Average Disk Queue Length 的值很高，则可能有磁盘瓶颈。但是，如果队列长度增加的同时 Page Read/sec 并未降低，则是由于内存不足。
------------------------------
由于篇幅问题，进程分析，网络分析被遗漏，后面有必要的话会进行补充。
文章脉络
测试的重要性在此就不赘述了，先说一下测试基础：测试的目标很简单，就是为了找到软件中尚未发现的错误的缺陷；测试阶段在整个开发过程中所占比例不小，测试也不是想起两个数据来就测试一下，而是需要规范的测试用例来完成，测试用例要既有输入更要有输出，同时需要有一个整体的规划。
如何评价一个测试用例的好坏？不用看定义，按测试的目标即可知道，一个好的测试用例就是可以发现错误和缺陷，一个更好的测试就是可以发现更多的错误。
软件测试不是等编码完成后在开始的，而是贯穿于整个开发过程，从开始的可行性分析阶段即开始着手软件测试。软件测试有这么几个原则：
● 尽早、不断进行软件测试，一个错误越早发现，改正它需要的改价就越小。
● 所有测试追溯到用户需求，一个软件最大的失败就是不能满足用户需求。
● 测试应当是从小小规模到大规模测试的
● 远在测试之前就应该制定测试计划，为的是有计划有步骤的执行测试，不能让测试耽误整个软件开发周期。
● 第三方测试，自己写的代码潜意识会跟自己说做的很好或者用自己的逻辑检查自己的逻辑，从而漏掉错误。
● 对非法的输入数据也像合法的数据一样编写用例。
● 检查软件是否做了不该做的事。
● 测试只能证明软件有错误，不能证明软件没错误。
测试分类
从阶段上可以分为：
单元测试
放在编程阶段，可以由程序员对自己的模块测试，测试模块是否实现了详细设计中规定的功能和算法，单元测试主要是发现编程和详细设计中的错误，测试方法主要采用白盒测试，单元测试的计划应当在详细设计阶段制定。
单元测试时，需要为模块编写驱动模块和桩模块，驱动模块的作用是调用被测模块，主要看测试结果是否正确；桩模块的作用是供被测模块调用，检查调用参数的正确性。
集成测试：在模块组装完毕后检测，主要是测试模块间的接口和通信问题。集成测试主要是发现设计阶段的错误，测试计划应当于概要设计阶段制定。
确认测试：主要是测试软件是否满足需求说明中的功能、性能和其他约定，确认测试应当在需求分析阶段制定。
测试计划制定与实施顺序：
测试方法
测试方法分为白盒测试和黑盒测试。
白盒测试主要用于单元测试阶段，它的前提是把程序看做是透明的，测试者知道程序中的结构和算法。这种方法按照内部逻辑设计测试用例，检测程序中的分支是否正确工作。白盒测试常用的方式是逻辑覆盖，按覆盖程度分为六种，覆盖强度由低到高：语句覆盖、判定覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。
黑盒测试主要用于集成测试和确认测试，该方法把程序看做是不透明的，不考虑程序的结构和算法，只测试软件是否有选择地接收数据并产生正确的输出信息，黑盒测试常用的方式是等价类划分、边值分析、错误推测和因果图。
维护
维护是指软件交付到软件淘汰修改或改进软件的过程，可能是软件生命周期中最长的一个阶段，所占花费也占到大部分。可维护性包括可理解性、可测试性、可修改性，这点就要求必须把程序的注释书写完善、程序修改有文档记录、文档与程序相对应。
在CMMI四五级的软件公司中，建立过程性能模型是一个重点也是一个难点工作，很多公司无法建立过程性能模型，为什么呢？
1）数据不准
比如：
？ 对于评审的会议，评审的参与人有的是来学习的，在统计人数、工作量时就不应该统计在内。
？ 有的数据当时没有采集，而是靠时候回忆采集上来的。
？ 有的代码行数不是通过工具统计上来的，而是靠人估计估计出来的。
2）过程不稳定
过程不稳定的原因可以细分为：
i）过程太大
比如：对于整个项目的工期偏差率建立回归分析模型，由于影响因子太多，每个因子都有影响，但是影响都不是很大，这样对于采集数据的要求，过程的稳定性等要求很高，很难建立起回归方程，因此此时需要划分项目的阶段建立每个阶段工期偏差率模型或者不去细致的分析影响因子，而是建立蒙特卡罗的模拟模型，或者分不同类型的项目建立回归方程。
ii）过程定义不稳定
在过程定义中定义的不够细致，对于过程成功的要点没有定义清楚，比如：
对于评审的流程，为了保证评审过程的稳定，应该要求：
● 评审的时长不能超过2小时。
● QA跟着每次评审控制会议不要过多讨论。
● 会议开始是要声明规则。
● 评审会与讨论会要分开。
iii）过程执行不稳定
在流程定义中有要求，但是实际执行时没有做到位，比如：
● 开评审会的时候进行了大量的讨论比如设计的评审会，所以会议的工作量、会议的时长都不准。在设计会议上讨论了设计方案的合理性。
● 会议的时间超过了2个小时，4个小时的评审会议，后边的2个小时效率很低的。
● 会议的主持人在会议上没有讨论的现象进行控制。
iv）过程的输入不稳定
不同的项目在执行过程时，投入差别太大，过程执行的前提条件不稳定，导致过程的输出也会不稳定。比如：测试过程投入的单位工作量，有的项目投入的多，有的项目投入少，而如果这些输入没有被识别出来作为因子的话，则方程就无法建立起来。
3）影响因子（X）识别不全
● 在识别对于Y的影响因子时没有识别出来关键的影响因子，比如测试过程的单位规模的测试工作量等；
● 识别了关键影响因子但是不好量化表达，采集数据有难度，比如人员的技术水平；
● 采集了关键因子的度量数据，但是数据不全，缺少样本点；
影响因子的识别需要经验识别，也需要统计的假设检验，也可以进行实验设计。
4）对于大过程建模，影响因子太多，每个因子相关性都不大
如果是对于大的过程建模，则可能存在如下的问题：
● 影响因子多，每个因子的相关性都不是很大；
● 影响因子多，采集数据有难度，对每个数据都要求很准确；
● 影响因子之间彼此有交互叠加的作用，有相关性，建模困难。
5）样本量太少
样本量太少，增加或删除一个样本对回归的结果影响很明显，则规律不具有典型性。比如，在下图中如果删除右上角的一个点，则两个变量之间就没有相关性了，如果删除了右下的2个点则两个变量之间就是相关的。之所以出现这种现象就是样本点太少而导致的。
6）样本不随机
比如有2个变量X1，X2与Y都应该是正相关的，但是在实际中存在的数据却是：
| | 正相关 | 正相关 |
| Y | x1 | x2 |
| 中 | 大 | 小 |
| 中 | 小 | 大 |
此时如果对这些类型的数据进行分析，则表现出来Y与X1，X2是不相关的。
以测试过程为例，我们的经验与常识：
假设或常识1：高水平的测试人员找出的BUG多， 低水平的测试人员找出的BUG少。
假设或常识2：高水平的开发人员犯的错误应该少，低水平的开发人员犯的错误应该多。
我们的实际数据：
在实践中常常采用的策略：
策略1：关键的模块应该由高水平的开发人员进行开发，非关键的模块由低水平的开发人员进行开发。
策略2：高水平的测试人员要测关键的模块，低水平的测试人员测试非关键的模块。
如果是这样，对于测试过程做了度量以后，数据无法证明假设1和2的成立。
以上六个原因就是最常见的原因，这些原因在实际中克服起来并非那么容易，这也是为什么4-5级需要比较长的实施周期的原因。
问题描述：
测试过程中如何区分什么是功能bug，什么是需求bug，什么是设计bug？
精彩答案：
会员 土土的豆豆：
本期问题其实主要是针对不同方面或纬度上对于bug的一个归类和定位。
个人认为，从软件开发测试生命周期上分析的话，三者从开发测试阶段应该是需求bug、设计bug、功能bug。（这里仅针对提问排比）
需求问题可以包括设计问题和功能问题，当然还有非功能性缺陷等。
需求bug，简而言之就是对于业务需求不清晰或者理解有偏差产生的问题。可能包括业务分析人员不专业因素、开发与测试人员思维不一致、产品未满足客户实际需求（想法）等一系列bug。
功能问题大部分理应该是附属于需求说明书上的功能模块，因为开发、设计、实现等原因故而产生功能bug。但也不仅限于需求上列举出的功能，因为一个项目/产品，完全有可能因为相关协作的功能模块或整合的第三方程序导致产生bug。所以功能bug既可能是需求bug，也可能是需求外的bug。这里对于bug的优先级和安全级别等不作赘述。
设计问题可以认为是开发架构师/人员在项目设计编码前遗留的“历史”问题。因为设计bug还是根据需求说明书来进行开发设计，故而一些业务逻辑上的关系、代码算法的优化、数据库/表的关联等都属于设计bug。
个人认为，需求bug最为麻烦，也是后期维护成本最高的bug。设计bug次之，因为一个产品/项目设计层面问题较多的话，无论修复或改进多少，在代码编写结束后，开发人员很难重头再整理一套框架，即便目前没有设计bug，以后产生的风险也是很大的。
功能bug最平凡，但是也是基础。除去客户业务需求上的变更因素，整个项目/产品的质量好坏最基本的就是取决于功能是否按需求进行了实现，其问题是否很多。我们大部分测试阶段的bug以功能问题为主。
当然还有其他一些bug类型，本期问题所列3个bug从根本上分析不属于一个维度。但是也是很基本的概念。
以上是我个人拙见，请大家补充指正。谢谢！
会员 TesterChen：
首先什么是需求Bug、设计Bug、功能bug？
需求Bug，指由于客户需求描述不清晰或错误、需求收集人员自身原因及需求本身模糊难于分析、获取等原因，导致客户需求获取不准确，后期产品不能满足客户、用户的要求
设计Bug，是指产品在最初设计时由于未考虑全面，而使产品在使用中存在的一些潜在的缺陷。
功能Bug，是指计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
建议从以下几点进行区分：
1、产生的时间不相同：
需求Bug：产生于项目前期
设计Bug：产生于项目前期或中期
功能Bug：产生于项目中期或后期
2、产生的原因不相同：
需求Bug：客户需求描述不清晰或错误、需求收集人员不够专业、需求本身模糊难于分析、获取等原因
设计Bug：系统框架、通讯模式、库表设计、编写语言等选择不当，导致后期扩展棘手、安全性低等
功能Bug：开发工程师需求理解错误、代码编写缺陷等原因
3、造成的影响不相同：
需求Bug：对整个项目的影响极大，会直接拖后项目的进度、加大项目成本、降低客户对公司的评价
设计Bug：后期功能扩展、性能、安全性等可能会遭到威胁
功能Bug：影响用户使用体验、影响数据、资金安全
4、处理方式不相同
需求Bug：重新收集需求，重新设计和开发（需求Bug是对项目成本和进度影响最大的因素）
设计Bug：重大缺陷必须修复，小设计缺陷在下一次发布时更新（一般难于修复或修复成本较大）
功能Bug：直接修复缺陷，重新发布或更新
5、Bug的直接责任人不相同
需求Bug：业务人员、需求专员、项目经理等
设计Bug：架构工程师、数据库工程师、技术经理、项目经理等
功能Bug：开发、测试工程师
原帖地址：http://bbs.51testing.com/thread-820993-1-1.html
版权声明：本文由会员土土的豆豆、TesterChen首发于51Testing软件测试论坛每周一问活动。
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
之前曾简单的介绍了安全测试相关的一些内容，在代码端，我们一般需要做的不多，现在国内比较流行的是Fortify SCA来进行代码安全审核。
代码端我们可能遇到的问题主要在于堆栈溢出威胁，IO处理权限，Cache处理权限等问题上面。可以在编程的同时结合一些插件尽可能的避免此类的问题。
另外做安全测试最重要的是先做渗透攻击，只有在攻击中才能找到漏洞，加以处理。
最后为安全测试总结下所知道的一些可能被利用的入侵点：
1、SQL注入漏洞
老生常谈了，可以利用漏洞扫描器确定问题的所在，然后使用SPI Dynamics公司的SQL注入器等先进行渗透测试。
2、XSS跨站漏洞
XSS一直是重中之中，我们能做的是不停的扫描，注重问题的解决，在各个开放层面进行扫描。
3、服务器溢出漏洞
此漏洞目前好象比较少，只要管理员勤打补丁基本没事，不过在很多性能测试不过关的网站上问题比较严重。
4、上传漏洞
利用上传漏洞能直接得到WEBSHELL，危害等级终极高，之前比较流行。目前都比较少见了。。我们需要的是对服务器服务的严格把控。
5、DDoS
一般正确的管理员配置可以解决。
6、同服务器漏洞
很多的代理服务器的问题，你的网站做得安全，可是在你的服务器上的另外某些站点做得漏洞百出。因为都是同一个服务器的吧。。 所以别人就会利用别的服务器。提权。 然后得到你的服务器权限。
7、社会工程学
最难防御的问题，在于安全意识本身的加强。
先总结到这里，给自己留下点Memory，之后在此基础上加强。
摘要：软件测试是保证软件质量的重要手段，尤其是自动化测试可以提高测试效率，降低成本。黑盒测试是针对非计算机专业人员进行的测试，为了确保测试质量，必须总结出一套适合业务人员使用的测试方法。文章从实际需要出发，对黑盒测试方法进行了分析，并提出了优化方案。希望可以降低软件测试成本，提高测试效率，对软件测试人员的工作有所帮助。
关键词：软件测试；黑盒测试；测试策略
引言
黑盒测试是目前软件业界采用的主流测试方法，这种方法以业务应用为驱动，通过控制输入及其对业务的预期影响来判断代码实现是否正确。 实践证明，这是一种行之有效的测试方法。
1、黑盒测试常用技术及方法
黑盒测试方法主要运用于单元功能和性能方面的测试。其常用的技术方法有三种。
1.1 边界值分析法
边界值分析的基本思想是使用最小值（min）、略高于最小值（min+）、正常值（nom）、略低于最大值（max-）和最大值（max）处取输入变量值。如果要进一步测试被测对象的健壮性，除了变量的五个边界值外，还要通过采用一个略超过最大值（max+）和一个略小于最小值（min-）的取值来看看超过极值时系统会有什么表现。如果被测对象是多个独立变量的函数，这些变量受物理量的限制，则很适合边界值分析。
1.2 等价类划分法
等价类划分法是依据软件的任务书、需求规格说明或设计文档，把输入数据范围划分为多个区间（即等价类），在每个等价类中选取有代表性的数据设计测试用例。划分等价类是应用等价类划分的关键，既要划分出所有等价类，也要确保没有划分重复的等价类。等价类划分少了会导致测试不充分，等价类划分重复了会导致设计多余的测试用例。例如，对于if（int_DataA>=100 &&int_DataA<200）{…}，首先针对变量int_DataA进行等价类划分，就能划分为三个等价类（-∞，100）、\[100，200）和\[200，+∞），其中\[100，200）为有效等价类，而（-∞，100）和\[200，+∞）为无效等价类。然后再针对每一个等价类选取其中的数据进行测试用例设计。
1.3 基于决策表测试法
决策表指以表格方式给出的可能输入条件和程序所的对应输出结果之间的严格的逻辑关系.基于决策表设计出相应的测试用例的测试方法即为基于决策表的测试法。该测试方法在所有功能性测试方法中是最严格的。
2、黑盒测试方法的优化
2.1 数值更改黑盒测试的思路
首先描述一下数值更改的几种设计思路和模式。一般设计员进行数值更改往往使用直接查找工程文件的方法。如查找到需要更改的数值，就直接使用新数值进行更改。多数设计员认为只要没有漏改数值，就不会有问题。但不幸的是，还是会被测试人员发现一些程序中的错误。本文将按照软件工程开发测试流程的八个模块进行分析，提供一些数值更改的思路。针对数值更改的设计思路和模式，相应的测试思路如下：
（1）首先确定设计更改的需求是否达到目的；
（2）确认设计更改点所处的功能模块的功能是否满足要求；
（3）找出该更改点涉及的相关功能和接口；找相关接口要注意查阅相关的设计文档，如接口定义、通信协议、程序结构、芯片资料、设计标准等，设计人员的笔误往往集中在更改点涉及的相关接口；
（4）确认更改点涉及部分的功能是否能够满足要求；
（5）按测试要求做好测试记录并最后出具报告。
2.2 随机模拟法在黑盒测试中的应用
该方法的基本思想是为了求解数学、物理、工程技术或生产管理等方面的问题。首先建立一个与求解有关的概率模型或随机过程，使它的参数等于所求问题的解，然后通过对模型或过程的观察或抽样试验来计算所求参数的统计特征，最后给出所求解的近似值。概率统计是随机模拟法的理论基础，其基本手段是随机抽样。对于那些难以进行或条件不满足的试验而言，这无疑是一种极好的替代方法。在应用时，要先产生一种均匀分布的随机数序列，然后再设法转换成特定要求的概率分布的随机数序列，并以此作为数字模拟试验的输入变量序列进行模拟求解。其基本步骤：一是建立概率模型，即对所研究的问题构造一个符合其特点的概率模型；二是产生随机数序列作为系统的抽样输入，进行大量的数字模拟试验，从而得到大量的模拟试验值。产生随机数的数学方法，最常用的有同余法、平方取中法以及易位指令加法等；常用的随机数检验方法有参数检验、均匀性检验、独立性检验、组合规律检验和游程检验等；三是对模拟试验结果进行统计处理（计算频率、均值等特征值），给出所求问题的解和解的精度估计。设计测试用例要经历划分等价类和选取测试用例两步，首先要进行等价类划分，之后在此基础上通过随机模拟方法随机选取测试用例，这样可以使选取的测试用例组合覆盖程序的全部输入域，因而更具有一般性和代表性。
2.3 基于需求的测试优先化方法
优先化方法一般基于以下四个优先化因子：
（1）用户指派优先权（CP）是一个需求对于用户的重要性的度量，由用户为每项需求指派范围从1~10的值，值越高，优先权越高；
（2）需求易变率（RV）表示基于一项需求在开发周期中被修改的次数，是对需求变更的估计；
（3）执行复杂性（IC）是从开发团队的角度对需求实现难易程度的主观度量。一般按每项需求可接受的实现难易度给出一个1~10之间的值，值越大，所可能包含的缺陷数越多；
（4）需求缺陷倾向（FP）可帮助开发团队从软件以前多个版本收集的数据发现易出错的需求，并找出实现这些需求的代码。缺陷倾向越大的模块，造成域失效的可能性越大。
优先化因子的收集与更新过程是：先由用户指定系统各项需求的优先权以及开发阶段需求的增加和修改；需求分析者记录需求和相关优先权，并记下需求的任何变动；接着由软件维护工程师修复缺陷，并将故障映射回受其影响的需求；开发者再对各项需求执行的复杂程度给出客观评价；测试者为每项需求编写测试用例，同时将需求映射到其测试用例并运行。最后记录用例失效，并将其映射到引起该失效的测试用例。
2.4 测试用例的分布策略
一般而言，针对一个软件的测试用例集是不可能穷尽的，只能根据各种原则选择部分典型的用例进行测试。特别是对于一些大型软件，最终可能需要数以万计的测试用例来对其进行测试，在测试用例设计之前大量的测试用例该如何进行分布才能达到相对更好的测试效果呢？
（1）基于矩阵的首次分布策略
理论上，程序规模与测试用例的数量并非线性关系，因为程序规模越大，复杂度就越高，关联因素也越多，所以，对软件来说，这并不是单纯行数的增长。但是在工程中，为了便于实际操作，大多会简单将它们假设为线性关系。
为了把握好测试用例数目的合理分布，可采用矩阵式首次分布预测法进行分布。表1所示是以软件子功能作为矩阵的行，以功能测试的基础测试观点作为矩阵的列给出的矩阵法示意表。表1中的行列元素仅仅是举例说明。
（2）基于分析结果的再次分布策略
如果是按照上述基于矩阵的首次分布策略单纯地实施完最初设计的测试用例就认为测试结束，那么测试就不能称之为完整的测试。而必须依据第一轮测试发现的bug的分布特征、bug的收敛趋势等分析结果来判断是否需要继续测试。在需要继续增加测试的情况下，可以采用基于分析结果的再次分布策略来确定增加部分测试用例的分布。具体实施方法是：根据功能点和基础测试观点进行bug的分布规律分析，将测试发现的bug数都正确地填写在表1的矩阵中，然后根据数字明确哪些子功能是薄弱点，哪些基础测试观点是bug最多的观点，根据软件测试中的80-20规则（80%的bug集中在20%的程序代码内），对于这些交叉点提高测试用例密度，并进行增加部分的测试用例再次分布。
2.5 基于输入输出关系的综合黑盒测试方法
这是针对黑盒测试存在的问题提出的一种测试用例设计方法。根据系统规格说明和系统输入输出之间的关系等附加信息，来确定输入参数之间的覆盖和约束关系，并对参数输入域进行约减；接着对各组进行处理，对各个组合中的输入变量进行两两组合覆盖，再对各相关组的结果进行水平拼接组合。实践结果表明，该方法在不影响测试检错能力的情况下，可以有效地提高测试用例的选择效果。
利用输入输出关系对测试用例集进行约简和优化时，首先对输入输出关系自身进行约简，然后进行关联性分析，并将其划分成若干个彼此独立的相关组；接着对各相关组分别进行，可仅对每个输出涉及到的输入变量进行组合覆盖，进而利用组内元素的关联性通过公共元素进行水平拼接，最后再把各个相关组的结果进行水平拼接。结果表明，改进后的方法可以产生数量最少的用例集。
利用测试用例集的约简技术和优化，可以大大地缩减测试计划，降低测试成本。利用已知的输入输出关系，通过对输入输出关系自身的特点（包含和关联）进行分析来对输入输出关系进行约简和分组，然后把每个相关组视为独立的输入输出关系分别进行处理，再对每个输出所涉及的输入变量进行组合覆盖，进而利用关联性把这些组合覆盖的测试数据进行水平拼接，最后再把各个相关组的结果进行水平拼接所样产生的结果不仅最接近最优解，而且时间复杂度也指数级下降，从而得到了较大的优化。
3、结语
为了提高软件测试的质量和效率，本文针对黑盒测试中的软件测试方法进行了分析，并根据实际操作总结出了针对黑盒测试的改进方法。实践证明，通过测试方法的优化，可使软件测试更加系统化、灵活化，其测试效率和质量都会得到明显提升。
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推荐标签： 性能测试 软件测试
曾经我们帮助客户进行软件性能测试的时候，客户不解的问，不是必须通过功能测试后才可以测试性能吗？可能有很多人会存在这样的疑问，在这里，我们的多位专家根据多年经验总结出性能测试的10大误区，希望能给大家带来帮助。
误区1：应用程序必须通过功能测试后才可以测试性能。
应该尽早的进行性能测试。性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起后，才能检查一个系统的真正性能。
性能测试从早开始，完成一个小模块，对小模块的接口进行性能测试，一般耗费资源很少，但可以防止问题在项目最后出现，花费很大的精力去修改。
而有些资料中提到的：在系统代码开发和功能测试完成之后，进行性能测试的说法，是为了检查系统整体性能的做法。一般经常出现在验收性能测试中。
误区2：软件性能测试要向功能测试一样，覆盖到所有功能。
性能测试的主要目的是为了系统调优。不可能对所有的系统功能都进行性能测试。在测试设计时需要结合当时的实际系统，先分析软件可能存在的瓶颈，此时可依据80/20原则分析：对系统资源的利用、数据大量传输、数据转换、用户使用频率、逻辑复杂度等进行分析，选择要执行的功能和场景，再依次制定性能测试的方案。
误区3：系统吞吐率随着并发量增加而增加。
随着并发量的增加吞吐率并不是线性增长的。并发量从小逐渐增大，开始阶段吞吐率随着并发量的增加线性变化；当并发量达到某一值时，系统处理能力趋于饱和（也可能某一硬件条件达到临界值），此时再逐渐增大并发，会有一些请求处于等待状态，所以响应时间变慢，吞吐率趋于稳定；当并发量达到系统的最大处理能力后，再增加并发，系统处理能力会下降，吞吐率也会下降，最终可能发生宕机。
误区4：客户给出性能指标，我们一定要想法设法达到。
根据用户提供的指标进行可行性分析，分析这些指标在理想状态下是否可以达到。比如有这么一个要求：有一台服务器，希望能承载10000个用户每秒200kb的传输。从CPU、Disk、网卡等方面分析都是很难达到的，也是很难测试的。需要和客户商讨增加硬件配置或者通过其他途径来解决。
误区5：压力测试、负载测试、容量测试等这些不同类型的测试一个一个分开来执行。
现实场景是复杂的，测试也需要尽可能的模拟负载的场景。在一个整体的系统性能测试场景中，应该包括各个类型的测试。而需要检查某一个方面的指标或分析某个性能问题时，尽量保证场景简单、单一、容易模拟。
误区6：做性能测试主要就是性能测试工具的使用；我做不好性能测试，是因为对测试工具不熟悉；测试工具可以自动生成我所需要的报表；依靠性能测试工具就能准确定位系统瓶颈；
测试工具在测试中只能起到辅助性作用。而测试方案、测试场景的分析、问题的定位这才是性能测试的关键。不要期望测试工具能够生成你想要的东西（报表、瓶颈分析），工具只是尽可能多的提供我们分析的依据。
误区7：在线用户数就是并发用户数。并发用户数高意味着PV（页面浏览量）大。
并发用户数*用户访问页面数=PV
误区8：提高一下硬件配置就可以提高性能了，因此性能测试不重要。
随着软件规模的扩大，提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题，再多的资源可能也不够用，例如：内存泄露问题，随着时间的增加，内存终究会被耗尽，最后导致系统崩溃；数据库连接等配置信息、数据库死锁是和硬件很难挂钩的；算法逻辑问题导致程序缓慢。即使要提高配置，也要首先用性能测试的方式得出哪些硬件可能存在瓶颈。
误区9：性能测试独立于功能测试
一方面，整体性能测试的场景设计要求的系统功能非常熟悉；另一方面，功能测试可以发现性能问题，性能测试也能发现功能问题。很多性能问题时由于软件自身功能缺陷引起的。如果应用系统功能不完善或者代码运行效率低下，通常会带来一些性能问题。功能测试可能会发现这些问题。
误区10：随便找个环境下进行一下性能测试就可以了。
做性能问题分析可以在类生产环境上进行，配置可以有些差别，但是，整体性性能测试、验收性性能测试要尽量在用户生产环境下进行。
摘要：随着社会的不断进步和计算机科学技术的快速发展，计算机软件在国民经济和社会
生活等方面发挥着越来越重要的作用。作为计算机的灵魂――软件在其中起着举足轻重的作用。
软件开发中出现错误或缺陷的机会越来越多，市场对软件质量重要性的认识逐渐增强，因此
软件测试在软件项目实施过程中的重要性日益突出。但目前软件测试的地位和作用，还没有真正受到重视，这影响了软件测试活动开展和软件测试质量的提高。本论文简要介绍了软件
兼容性测试中所涉及的知识。
关键词：计算机；软件；兼容性；测试
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。其中软件兼容性测试，是指针对软件对其运行环境的依赖进行测试，以验证软件是否能够在所有期望的环境中运行，兼容性测试主要包括以下三个方面。
一、硬件兼容性测试
硬件兼容性测试一般考虑两个方面的内容：一是不同的硬件配置可能影响软件的性能，二是软件若使用了某些硬件的特定功能，就要对此进行兼容性测试。硬件兼容性测试具体内容如下：
1、与整机的兼容性测试
考虑到软件的运行情况，需要对常见的硬件配置进行测试，从而确定软件能够在多种硬件配置环境下运行。如果软件对硬件的配置要求比较高还要测试它的敏感度。
2、与板卡和外设的兼容性测试
如果软件需要直接访问某类板卡和外部设备，通常需要对这些板卡和外设的接口调用进行测试，以确保对这些接口的访问适用于所有型号的板卡和外设。
二、软件兼容性测试
软件兼容性测试主要考虑以下问题：
1、与操作系统的兼容性
如果一个软件可以在多种操作系统上运行，就需要测试它在同一操作系统平台的不同版本上的兼容性。
2、与数据库的兼容性
如果软件需要支持不同的数据库，通常需要针对不同的数据库产品进行兼容性测试，另外如果同一数据库产品包含多个版本，也需要针对不同的版本进行兼容性测试。目前常用的数据库产品大多数都支持SQL标准的数据库，如MS SQL Server、Oracle、ODBC、JDBC等，但不同的数据库对SQL标准的支持不同，如果软件支持不同的数据库，通常要针对不同的数据库产品进行兼容性测试；如果被测软件支持ODBC和JDBC，并通过ODBC和JDBC与实际的数据库连接，此时对该软件进行兼容性测试应该包括对ODBC和JDBC的测试，和对实际数据库的测试。
3、与浏览器的兼容性
对于不同的浏览器以及浏览器的不同版本经常会出现兼容性问题，如某些特定的HTML标签只能在某些特定的浏览器上使用；某些特定的脚本和插件只适用于特定的浏览器。如Active X只有IE浏览器支持，不同的浏览器对于安全性的设置各有不同，需要测试浏览器是否都能够为使用该Web应用提供合适的安全设置。
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿
4、与中间件的兼容性
越来越多的软件需要中间件的支持才能运行。不同厂商开发的中间件有很大差别，在一种中间件上运行的软件很难再其他的中间件上运行。所以与中间件的兼容性测试主要针对同一产品的不同版本进行测试。另外，某些应用软件还可能需要在不同的J2EE中间件上运行。
5、与其他软件的兼容性
软件在运行中总是需要与其他软件进行交互，而任何交互问题都可能引起软件的运行问题，因此要针对与该软件可能发生交互的软件进行兼容性测试。
6、与平台软件的兼容性
我们可以把平台软件分为运行平台和开发平台两种。对于运行平台，兼容性测试主要包括测试平台软件与在其上运行的应用软件的兼容性，对于开发平台，兼容性测试包括测试所开发的软件与相应环境的兼容性。
三、数据兼容性测试
数据兼容性主要包括以下内容：
1、不同版本间的数据兼容性测试
一个软件系统在其生命周期里会出现一系列的版本，所以测试新版本软件能否兼容旧版本的数据时兼容性测试的一个重要方面。
2、不同软件间的数据兼容性测试
数据兼容性测试不但存在于同一软件的不同版本之间，也存在于不同的软件之间。通常一个系列中不同软件通过约定好的数据格式实现集成，不同的软件通过标准的数据格式进行集成，这个时候就需要针对相应的一种或多种数据格式检查被测软件是否可以通过复合数据格式的各种数据进行正确的交互。
结束语：在实际软件开发中，软件通常都是需要在许多种不同的软硬件环境中运行，然而由于任何一个软件都或多或少地依赖所运行的环境，所以环境的差异可能导致软件在不同的环境下运行会有不同的结果，所以对软件的兼容性进行测试是很重要的。然而并不是每个软件都要进行所有的兼容性项目的测试，在实际测试中，要按照软件类型、需求定位和测试环境进行选择，并调整并扩充测试方案。还要注意的是，对于定制系统来说，兼容性测试应尽早进行，否则系统投入使用后，随着系统中数据的增多，兼容性测试的风险和投入将越来越大。通常如果期望的运行环境存在众多的可变性，兼容性也会很复杂，反之，兼容性就很可能不存在问题，兼容性测试也会变得非常简单。因此针对不同的软件对其运行环境的要求，要开展不同的软件兼容性测试，以保证软件的正常运行并发挥其最大的作用。
要做
测试，首先要具备七大素质：
（1）自信自尊，充分热爱测试——一般做技术的人喜欢开发甚于做测试，原因有三：
第一：开发人员的成就感更易满足；
第二：在应用技术方面，测试人员对其的领悟是和开发人员不能比的；
第三：测试的性质决定，心高气傲的人，才不愿整天跟在开发人员屁股后面打扫战场；本性温厚的人，也不愿意每天像监工一样，挑三拣四地以挑人家毛病为唯一任务。
（2）尽职尽心，以质量为己任——测试人员要牢记自己是对产品质量负责的
（3）有大局观，不为名利所扰——测试人员应该有更高的境界，要审视项目真实的需要，以整个项目的大局为重；测试的管理者要清楚了解测试的终点在哪里，最做足够的测试而不做无尽的测试。
（4）孜孜不倦，刻苦专研技术——测试也需要技术，如果一直满足于从客户和使用的角度来测试问题，这种测试的效率和价值都值得怀疑；在技术上安于现状，不思进取，最终会发现测试的路子也会越走越窄。
（5）悲观工作，不能悲观生活——好的测试人员要以其天生的悲天悯人的态度对待工作，他们不相信任何看似平静的表面，总要提防水下是否有暗流涌动。在他们眼里，没有好的产品，做产品做到极致也只是不太烂而已。
（6）心细如发，绵密绝无破绽——在工作中把网结的密实一点，当细心成为习惯，也就成为性格的一部分了。
（7）发散思维，习惯剑走偏锋——美特斯邦威，不走寻常路（极限测试、反叛测试、压力测试）
除此之外，测试人员还应该精通五大学识：
（1）经济学——项目是要讲成本的，如果解决一个BUG的成本高于保留它所付出的价值，不解也罢。
（2）心理学——揣摩开发人员的心里，抓住他们的弱点进行测试容易起效；更需要揣摩用户的心理，知道他们关注那些房买呢，以作为测试的关注点。
（3）统计学——测试人员要学会从已有的数据（测试数据的分析与统计）里分析趋势，预测项目的走势
（4）刑侦学——针对发生一次、间歇性的问题，能够在多个影响因素中找到蛛丝马迹，发现复现的步骤
（5）逻辑学——测试完毕要有结论，下结论的过程就是逻辑分析的过程。
开发人员代表了一种创造的力量，测试人员充当着一股毁灭的力量。
养不教，父之过，教不严，师之惰。
在项目即将上市前，列出测试团队认为将会对产品质量伤害最大的几个遗留问题，同时附有精确的发生环境和概率的分析，还有客户可能的反应，以此作为测试方的意见提交给项目的管理者决定。
一个项目在什么样的标准下算是测试结束。
测试就好比一张网，要确保把所有要测试的内容完整的包在这张网里，需要系统化的规划，不能让某些部分漏在往外。
开发经理是亲爸爸，测试经理是老师：开发一个产品但不测试，这是开发经理的过错；测试了但不严格，这是测试经理的责任。