测试经验总结

第一篇：测试经验总结

1.测试人员和用户的联系与区别

黑盒测试人员和用户，都是站在实际应用层进行操作，因此他们对应用层的可用性、实用性非常关注。用户不懂的是软件的使用，而相对用户来说，测试人员对软件比较了解，但不熟悉业务本身。

八个字归纳：用户是用，测试是测。

用户不懂使用就需要技术支持人员去培训，而测试人员在测试初期经过开发人员和项目负责人的简单培训后，就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。

应该做到：由测试人员培训技术支持人员，由技术支持人员实施时给用户培训。

2.带着问题去测试

阿猪工作守则第一条：带着问题去测试

测试中会遇到很多问题，没关系，没有脑子里面的一个个问号，是不能很好的发现问题的。往往发现一些藏的很深的bug都是在测试人员一步步解决这些问号的过程中，切忌遇到问题就问，不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度，而且自己对问题的印象也不会很深刻，毕竟在相对较短的测试时间内，听不如记，记不如自己去发现规律。

3.测试期间提问题和交流的时机

什么时候应该提问题？

我们都知道，作为测试人员，并不是测试期间什么时候遇到问题就要马上问，那什么时候是提问的时间？

培训

培训时，一般在讲解内容的间歇允许打断，由培训人员解答测试人员的疑惑。培训的过程其实就是一个传输新知识并答疑的时间，这个期间的提问是欢迎的，也可以增加参与性和调动积极性。所以希望大部分的问题能在这个阶段提出来。受时间、环境等条件制约，有时培训的人讲的也不一定细致和全面，这时就需要自己多想，想想这个功能是干什么的，为什么这么做，对应的业务是什么。

阿猪工作守则第二条：培训时脑子灵活转动，多想多问

以前大家可能有过参加辩论会的经历，就算没有其实和人聊天也是一个交互的过程。参加辩论会要求快速思考，然后放慢语速说出自己的观点，因为不能说错。我们在参加培训时前者相同，后者相反。脑子嘴巴都要快，说错了也没有关系，自己的想法被纠正的过程中也是加深印象和理解的过程。

计划评审

提出对于软件不理解、安排的任务不明白的地方。

测试期间

这个时期最主要的问题应该集中在影响测试流程和进度的问题，而不是说明书或其它文档上已有的内容，或者与自己负责模块无关的内容。开发人员和其他测试人员都有自己的进度安排，因此，影响测试流程和进度的问题,马上问！

不影响流程的问题，记下来统一问！

不必要的问题（说明书或其它文档上已有的内容、讲过三遍以上的问题、今晚去哪里吃饭的问题），不问！

好处：避免不必要的时间支出，不打乱自己的测试思路，一气呵成，并且使项目成本得到控制

坏处（？）：脑子里、笔记本上留下一堆待解决的问号吧，浪费脑细胞和公司的笔和纸

张等资源

阿猪工作守则第三条：先做事，后学习

在有限的时间内先完成该做的事，有空闲的时间再去补充自己的知识。

要很好的把握上述内容，也要求提高培训期间培训人员培训内容的完善性，要求前期培训人员强调出软件的重点、难点和注意事项。这个期间适合于上面提到的“带着问题去测试”的方法。

但有一点需要注意：不要为了一个地方的卡壳在那耗上一天半天的，这就不值得了。测试中期评审测试问题

答疑解惑的时间。

测试报告评审

对一些结论有疑惑和不解的地方，提！

4.记笔记

一个老生常谈的话题。

阿猪工作守则第四条：好记性不如烂笔头

测试培训的时候对于一些重点应该记下来，即使当时听懂了；没听明白的更应该记下来，到测试软件的时候去验证自己的疑问。如果培训时特别强调的地方，测试时再去问，这就不好了。

养成一个良好的习惯，会使以后的工作更加顺利。

5.在公司和学校的学习的区别

学校是专门学习的地方，公司就是工作的地方，因此，它们的性质决定了其学习内容和方法的不同。

学校 公司 备注

内容上 主要是系统的理论知识 主要是和项目相关的业务知识 如果在测试中感到自己部分理论知识欠缺时，就应该回家多补充了

时间上 大块时间的连续学习相对邻散 在公司一般不会拿出大块时间来学习和讲解 形式上 老师授课＋自学 培训＋交流＋测试过程中自学

个人觉得，一个高效的测试流程应该如下：

a.花几个小时至多半天时间快速阅读浏览软件说明书、设计文档；

这个阶段要让脑子里面形成对软件的整体印象感，能够让自己把握全局，因此，测试负责人安排时间看文档时，决不能忽视它的重要性，否则就会出现后续阶段磕磕碰碰的情况。注重速读，把握软件说明，忽略具体的数据库设计、功能点设计、计算、规则和辅助工具（相关软件）说明文档，囫囵吞枣的方法在这里就显得很有效。

如果项目时间紧或没有文档，这个步骤所做的事可以在下面完成。

b.利用培训时间消化吸收的知识

c.软件上手

几个小时至多半天时间，熟悉软件框架和基本功能，不要求所有功能都会操作，自己负责的模块可以多侧重一些。

d.细测

主要症对计划中安排给自己做的模块，这时就要相对放慢节奏，每一步操作、每个对话框（操作界面）都要深究，别放过任何情况。这时会遇到一些错误或不理解的地方，明显的如报错就提到开发过程论坛，不明显的就先记下来，等这个功能点测完再回头去看，你会发现：

50％的问题可以自己分析出来和解决，有的问题不是问题，只是开始还没有完全理解。阿猪工作守则第五条：软件不是一次能测透的Rome is not built in one day.工期、人力、环境资料等，都制约着测试的深度和广度，因为不要期望一次能完全把握某个软件。

综合测试的优势在于，我们负责公司产品的把关，而项目由产品延伸而来；测试产品会不断出新的版本，一次没有理解，可以在下一次中弥补，温故而知新。

一口吃不成一个胖子，看我这么瘦又这么能吃就知道了^^

要结合自己的实际情况决定本次测试的深度，不要看着别人进度快了就打乱自己的节奏，只要安排合理，应该按照计划来。特别忌讳认为自己这块没问题了就马上去看看别人负责的功能，期望全能。这样一般来说除了ljl这种全能性人物外都会造成最后自己的问题留了一堆，别人的也没搞懂。

新人特别注意，踏踏实实的搞懂每个自己负责的模块，打阵地站，这种方法很有效。评价自己是否可以转入下个模块的几个因素：自我提问与别人提问、测试进度

如果大多数相关人员（主要是测试负责人、其他部分相关测试人员特别是开发组集成测试人员和技术支持人员）对于自己负责模块的问题都能解答，搞定！NEXT-->转入下个模块。

否则，还是再回头想想思路和遗漏的地方。当然，要综合考虑测试进度。请组长对自己提几个软件的问题，他会很乐意的。

e.小结

一个阶段就进行一次小结，这个小结可以是书面的，比如测试问题记录、测试用例补充、测试模块设计等，但大多是自己分析，为了方便接下来模块的测试.f.性能测试

性能测试不仅是测试性能，同时也加深自己对软件应用的理解，因为性能测试往往和实际应用或用户需求结合的很紧密，避免造成软件功能都会用，但不知用来干麻的尴尬情况。g.安装盘测试

安装盘程序测试，简单过一下软件功能有无错误。

安装盘程序文件、库文件、组件等的完整性、正确性，这个非常重要，要不返工就浪费时间了。这个阶段要积极与开发负责人和GJ沟通，确保最后的胜利。

h.测试总结

测试接近尾声，总结自己对软件的掌握情况，得出测试结论、归纳测试方法、提出修改建议，为软件以后版本的修改提供依据，也为以后再测类似软件提供捷径。

5.小结

 用户用软件，测试测软件

培训时多想多问

好记性不如烂笔头

带着问题去测试，在测试中解决问题

 先做事，后学习，争取双赢

软件不是一次能测透的

第二篇：测试经验总结

6年测试工作的思考

前言

在公司已经干了6年的测试了，干测试经理也5年了。正好趁此机会把自己6年来一直想写但没写的东西写出来。这篇文件纯粹是对自己工作的回顾。由于时间仓促基本上是想到什么些什么，有点儿乱，也请大家多多担待了。只要还有些人能从中找到些儿同感，或从中得到一些帮助，一些经验，我就知足了。

1.什么是测试

首先我要谈谈什么是测试。相信好多测试人员跟我一样，来公司之前也没有从事过任何测试工作。对于测试都是从零开始的。也有好多人跟我一样，从各种书上或是培训中得到过有关测试的各种定义。但不知道大家有没有净下心思考一下。什么是测试。在公司公司测试工作的定义是什么，测试的工作范围是什么。

测试的定义根据测试技术的发展，历经了3个主要的阶段。第一个阶段，认为测试就是找产品中的bug。第二个阶段，除了找bug以外，又增加测试是对软件质量的度量这一概念。第三个阶段，明确了测试是指为了度量和提高被测试软件的质量，对测试件进行工程设计，使用和维护的并发生命周期。注意其中提高的测试件，其主要是与软件这个词进行对应。明确测试也是一种开发过程。他的工作成果就是测试件，好像平时我们所谓的测试案例、测试脚本等等都可以称为测试件。然后使用测试件去度量和提高被测试软件的质量。

目前，在中国大部分软件企业，尤其是中小型的软件企业还停留在第一阶段。我个人觉得公司稍微好一点儿，处于一、二阶段之间。因为我们平时做的最多的一件事，还是找bug。至于测试案例和测试脚本等等，只占用工作量的很小一部分。而且我看不到大家在平时的测试工作中是完全依据测试案例进行测试的。目前测试案例等工作更多的成为了一种形式上的产物。从有些部分所有产品的测试案例在一个下午就能评审完就能看得出来。

说到这里顺便在谈一句测试计划。目前的测试计划是作为产品计划的一部分。先明确大概发版时间，然后是各个阶段的里程碑，其中提交集成的里程碑是死的。开发需要的时间就是那么多，剩下倒推的时间就是测试的时间。这样定出的计划是否能够起到计划的作用就不好说了。现在的计划更多的是罗列联调测试的各种内容，至于时间，不说也罢。所以从中也可以开出公司的测试也就停留在一、二阶段之间。

明确了公司测试的定义（个人理解），也就不难理解公司给测试人员的定位了。在测试人员中经常流传的一种说法就是国外测试人员的地位多么多么的高，开发就是coding。咱们公司开发比测试多拿多少多少，测试人员地位是开发序列中最低的。大家也要看看人家公司测试人员的素质，测试在开发过程中的重要性。再看看自己所从事的工作，就是找软件的bug。当然我也个人认为有经验极其丰富的测试人员对产品的贡献比开发和需求大。明确了这些，心里也就能少点儿不平衡感。

2.测试方法的思考

说完个人对测试含义的理解，再说说个人对测试方案的一些思考。

个人认为在公司6年，测试方法没有什么提高。主要还是以黑盒测试为主。中间也曾经引入过各种各种工具，但测试人员真正用起来的也就是robot。而且robot主要是进行回归测试，再加上一些人并没有真正认识到其价值，应用范围也极其有限。对整体测试效率的提升影响不大。所以目前的测试方案还主要是以需求为依据的黑盒测试。至于什么极限值了，成对测试法等等，都是建立在黑盒测试的基础上，而且从我一来公司就有相应的测试项目，只不过没有明确概念而已。

另一个说个人觉得6年来公司测试方法没有什么提高的原因是，6年前测试是以人为主，靠得是测试人员的经验，对产品的熟悉程度，对业务的理解程度。6年后测试还是以人为主，人就是测试的主体，产品质量的保证。还没有过渡到测试案例就是测试的主体，测试案例的完整性是产品质量的保证。只要测试还是以人为本，我觉得测试的效率就不会有太大提高，产品质量的信心来源也是对相关测试人员的信任。我个人觉得以黑盒测试为主要的测试方法没错，而且也比较符合目前公司的测试现状。但一定要注意各种经验的总结、积累，更重要的是共享。虽然目前测试案例在测试工作过程中的地位不重要，但其毕竟是编写者的经验积累。汇总起来也是一笔可观的财富。可现在如果有人问我850的测试方案在那里，其中还有多大比例能够用在现在的产品中，在现在的测试工作中有多少以前的案例能够复用。其他产品中的测试案例中有多少是关于接口功能，有多少我可以借鉴。我不知道，这也是自己工作不到位的地方。所以我要说的作为黑盒测试为主要的测试方法，一定要注意测试经验的总结和共享。

而且我认为一个人如果黑盒测试能做到位，做到最后培养的是一种测试的感觉。测到最后，产品你一看就能知道那里可能有问题，那里应该没什么问题。这样有重点地投入测试力量可以收到事半功倍的效果。可这是需要大量测试经验的积累的，不是我告诉你，你就知道的能力。在此前提上加强测试人员之间的横向沟通，形成经验贡献。可以较快的培养测试人员的测试感觉。

最为测试经验积累的另一个重要方法就是加强对测试案例的要求和管理。每版测试案例不仅要包括新增功能，还需要包括上一版本中继承的案例，修改或删除上版案例中变更的内容。从而形成一份完整的关于产品所有功能点、接口、升级、年结等等各方面的测试案例。真正做到测试案例是测试的主体，从而提高测试效率，提高产品质量。

3.测试工具的概念和作用

测试工具，什么叫测试工具。我认为任何能提高你测试效率的工具都可以称之为测试工具。不仅仅指robot或是loadrunner这类专门的测试工具，也不仅仅指使用各种编程工具编写的测试工具。像总账工具、eai等，即使只是帮我们导入一些常用档案，也可以节约我们的测试时间也可以称之为测试工具。

我个人现在公司测试在测试工具开发上还很不足。在公司里一提起测试工具，大家第一个想到的可能就是robot。即使是robot应用的也不够深入。大家经常认为robot主要录制gui的脚本，跟产品界面联系紧密。每次回放成功率不高，各个版本间脚本复用率也较低。而且每次总是以各种理由将脚本录制放到最后，经常就不了了之了。最后阶段的测试任务实在太紧。我想说的是robot的应用虽然有各种各样的局限性，但其毕竟提高了测试效率。比如说安装盘验证，使用robot验证，每天都可以节约一半以上的验证时间，这就是效率。认识了它的好处，才能想尽办法解决或避免在robot使用中的各种问题。以前同事有一套robot脚本规范就很好，使用后不仅提高了回放成功率，而且回放中断后，继续回放也变得很容易。所以说使用robot后，想100%回放成功不可能，想不再进行脚本的调试也不可能。认识这两个问题后，就需要加强robot使用经验的总结和共享，有针对性地加强robot使用问题的研究，每版测试开始时针对上版robot脚本的复用问题进行研究。这样才能用好它，真得使之成为一个工具，而不是一项任务。

一种工具也不是万能，有许多针对产品特性的测试工具。只能自己开发，大家应该积极提需求。凡是认为有可能提高测试效率的工具需求都可以提。能从网上找到现成的工具解决需求更好。不能，如果是普遍性的需求，可以专门进行开发。因为咱们产品的特性，每版间测试工具的复用度很大。从长远看就是节约开发成本，缩短开发周期。

在现阶段加大测试工具的适用范围和力度，用好各种测试工具，可能是提高整体测试效率最快最好的方法。但一定要加大推广的力度。否则有了好的工具，没人用或用不起来也是没用。

4.如何看待各种规则和执行

可能大家觉得平时开发过程中有好多规则、制度。这些除了一些自己公司内根据各种情况制定的外，大部分都是跟cmm体系相关的一些规则。可以说是已经被许多软件公司验证过，可以提高开发和测试效率的规则。但好多人觉得起没有什么用，就是在浪费时间。总是以一种完成任务或是应付差事的心情去做。我觉得大家之所以觉得其没用，恰恰就是由于你去做这件事的动机不对。总以应付差事的心情去做，你就不可能真正理解这么做的目的，这样做能给你带来什么好处，你从中会得到什么收益。所以我个人认为，既然有规则，不管是公司自创的或是借鉴其他标准，都是为了解决开发过程中的问题，为了提高开发的效率，保证产品质量。也许这些规则中有这样那样的不合理，但只有你认真地去做了，才能发现其中的不妥之处，才能改进，才能更有助于你的工作。

执行也是我觉得在工作中需要进一步加强的环节。许多规则就是因为执行力度不足，才容易让一些人找到空子，应付了事。但怎样加强执行力度，还是一个需要大家一起进行探讨的问题。

5.作为一名测试人员应该具有的素质

测试人员应该具有什么样的素质，相信好多人都有自己的理解，不同书上的观点也不尽相同。我就说说我在公司工作了六年，觉得一个合格的测试人员应该具有什么样的素质。业务和测试方面的能力就不说了。

测试人员应该具有的素质包括： 1.踏实细心和积极主动

我觉得作为一名测试人员首先要踏实细心。测试人员每天都要面对着枯燥的程序，从事着大量的重复工作，还要尽量发现产品中的bug。如果不踏实，你就坐不住，总想干别的，就无法净下心来想用户有可能怎么用，需求对产品是怎么要求的，现在产品中是怎么做的，哪里可能存在问题。不细心，就特别容易一些产品中微笑的错误，而恰恰就是这些错误是最影响产品形象的问题。

至于积极主动就不多说了。这是每个人都应该具有的素质。2.怀疑一切

不抱着怀疑一切的态度就不是一名合格的测试人员。经过你手测试的产品面对的是直接用户。你不认真负责，不抱着怀疑一切的态度。总想着这个功能本版没动应该没什么问题，这个功能没什么用户用不用认真测了。这样发出的产品，我是不敢让用户用。因为用户用起产品来是千奇百怪，有些用户的水平和对产品的理解比咱们还要深。所以一定要抱着怀疑一切的态度，认为产品每个功能都可能有问题，认真地测试产品的每一个测试点。

3.协作和团队感

协作和团队感也是十分重要的。要意识到测试、开发、需求是一个团队，一个整体。离了谁，产品的质量都无法保证。诚然有个别开发人员责任心不强，经常将未经任何验证的代码编译后发给测试进行验证。耽误了测试人员不少的时间。但越这样，测试人员越应该负责，否则产品发出去影响的是公司的形象。

还有个别开发人员开不起测试。此时就需要你通过各种方法去证明你自己的能力。比如测试出他根本就没考虑过的问题等等。以实际行动证明你离不开我，咱们是一个水平的。只有这样加强协作和团队建设，加强整个团队的质量意识，才能提高开发效率，保证产品质量。

4.自我提高和总结的能力

测试人员经常很迷茫，不知道自己的发展方向在哪里。测试技术还是专业知识。领导们所谓的个人发展方向考虑也经常是画一个饼在那里。这时就只能靠我们自己了。看你想今后从事哪方面的工作。一般情况下，如果升不到管理层就只有两条路可选了。一是业务精通，将来可以向需求或是售前、实施方向发展。一是技术精通，多掌握几种测试工具，又能力可以学习一些编程方面的知识。将来还继续从事测试方面的工作。随着中国软件开发的规范化，这条路也是很有发展的。

另外，我觉得作为一名合格的测试人员，一定要注意进行总结。通过总结可以对自己的工作进行一个回顾分析，看看那些做得不错，下次还继续这么做。那些工作还有改进的余地。对自己能力的提高是一个很好的帮助。

6.作为一名测试经理应该具有的能力

作为一名测试经理，我觉得除了具备一个测试人员应该具备的素质外，还应具备以下能力。

1.出色的沟通和协调能力

由于测试人员和开发人员的工作性质，必然导致测试人员和开发人员在工作中会产生冲突，对同一问题会产生不同的看法。这时，你怎么去协调，去沟通，解决这种矛盾，让自己所在的开发团队中极少的受此影响，就是考验你能力的时候。

2.条理性和计划性

作为测试经理，要负责带领团队内的其他测试人员全面的测试产品。由于测试项目很多，不仅包括产品功能，还要包括效率，性能，压力，并发互斥，环境等等方方面面。此时你如何去安排这些测试项目，哪些可以先做，哪些可以并行。与开发人员在一些项目的测试中如何协调就是考验你做事的条理性和计划性。

3.从全局考虑产品测试的能力

每一个测试人员在产品测试中，重点肯定是自己负责产品的功能，此时就容易遗漏其他的一些测试项目。有可能是接口的部分功能，又可能是升级或年结的部分功能。此时，你如何提请他们还有漏测的功能点。在有限时间内，能找出他产品测试上的薄弱点，就是考验你通盘考虑产品测试的能力。

后记

上面就是我对6年测试工作的一个回顾。这些都是我个人的一些观点，很不全面，也有不正确和遗漏的地方。大家看后，能从中得到一些自己需要的东西，我就知足了。

再次感谢在这6年中给了我许多帮助和支持的各位兄弟姐妹们。

附录A、QA工作心得

看过许多同行兄弟姐妹的工作感受，反映了一些从事QA工作过程中的困惑，心里也很有同感。之前做过几年的测试工作，到了新的公司开始做QA工作，虽说测试工作也是属于质量工作范畴，但是真正干起来才发现，还是有很大的不同的，尤其是思想方法和工作方法上。所以也是边学边干，这边和大家分享一点心得。

1、调整好自己的心态。

尊重开发人员、产品经理、项目经理等项目组内同事，不要把自己定位为监工，要把自己定位为服务员。如果你真的是从心里想帮助大家把事情做好，而不是教训别人，大家会感受到的。很多时候，调整好自己的心态才是难点。

2、有的放矢 不要盲目的发表意见，要做到有理有据，这也是避免项目组内成员产生争执和不理解的前提。在提出意见和建议前，最好做一下调查，收集一些资料和数据，或者和大家深入的聊一聊，开一些交流会，座谈会，收集到一线开发人员的真实感受，不要自己一觉得有问题就冲出来，这样肯定会被别人反感，也会降低大家对QA的认同和信任感。

3、数据说话

质量工作相对务虚不假，之前做测试好歹还有很多的bug摆在那里，刚开始做QA工作确实觉得虚了很多。自己的产出在哪里？后来发现，其实还是可以有很多的，呵呵。你可以给相关人员进行培训（质量知识、软件工程知识、产品开发知识、质量制度和规范等等），会议记录和培训资料算是你的产出的一部分。另外，对于项目过程中产生的问题，变更等，要有记录，一定周期内作出分析和报告，比如，变更发生率，项目延期的原因分布，与计划的不符合程度等等。进一步提出改进建议，有了这些数据支持，你提出建议也就更有说服力。

4、沟通再沟通

其实很多问题都是发生在沟通上，我觉得沟通好了，起码可以解决70%的问题。多为大家提供交流和沟通的机会，比如，发起一个交流会，让组内同事互相培训，形成一个良好的内部学习交流气氛。另外，什么也比不过面对面的沟通，抛弃聊天工具和email吧，走过去，和你的同事一起好好聊聊，吃饭的时候，坐车的时候，你会发现很多深入的问题的，呵呵。

5、循序渐进

规范制定好了，不要一下子就想完全推行到底。毕竟要改变别人已有的习惯，是会让别人不舒服的，呵呵。所以要循序渐进，分期分批，一点点来，习惯慢慢的就被改变了，这样大家就不会太抵触。而且，在分期分批推行规范的过程中，别忘了不断收集反馈意见，不断改进和修正规范，规范可不是qa说是什么就是什么的，一定要收集大家的意见，达成共识，这样才有被大家执行的基础。

6、展示自己

QA工作务虚，但是可以落到实处，是有很多实际工作要做的，比如文档编写，规范起草。培训、评审、跟进问题。这些工作的成果如何体现，效果如何，可以通过一些问卷调查，来收集大家的反馈，举个例子，如果推行产品开发流程规范前大家对流程的满意度是50%，推行规范两个月以后，满意度成了90%，你说这是谁的功劳呢？呵呵，这也是数据说话的一个方面，也是QA工作成绩的展现。说了这么多，其实我做QA工作也只有3个月，还有很多的不足，希望能和大家多多的交流，如果自己的一点心得，能够给大家一些帮助或启发，就深感欣慰了，呵呵。欢迎拍砖！

附录B、SQA之Q&A 软件质量保证，即 SQA，全称是 Software Quality Assurance。

问： SQA 目的是什么？

答： 对于任何的行业，讲到质量控制，归根结底都是为客户提供更高品质的产品，更好地满足客户的需求。质量有问题的话就不能满足客户的需求。在 CMMI 里边就有 “ 集成流程产品开发 IPPD(Integrated Product & Process Development)”，为什么要集成呢？就是说产品的研发不仅仅是开发团队的工作，还要把市场团队、销售团队、整个的流程、包括客户的反馈都要考虑进来、集成进来。目的是为了什么？其实就是为了更好地满足客户的需求。六西格玛里面说 DPMO(Defect Per Million Opportunities)，百万产品里有缺陷的产品只有三个。这是为什么？就是为了减少差错，从而让客户享受非常高质量的服务。

问： SQA 等于测试？

答： 测试其实只是 SQA 的一个环节，SQA 的全称是软件质量保证。在国外很多的大型的企业，比如说摩托罗拉、爱立信，他们的研发团队里面都专门有一个 QA 部门，其实他们并不是做测试工作的。QA 部门其实是管理开发流程的执行，并专门负责制定产品开发流程。比如说 RUP 里面有一个角色，叫 Process Engineer，过程工程师，他就属于 QA 部门，他的工作就是负责制定整个软件开发的流程。因为如果说要保证质量的话，不能只靠测试来保证。而必须在整个开发流程的各个环节都要做得很好，才能够真正地提升软件的质量。而测试只是整个开发流程最后的一个阶段。所以说一个好的流程就决定了一个软件的开发能不能按时交货，能否保证软件质量。这个流程就是由 QA 部门来制定的。QA 部门还有另外一个职责，就是保证整个研发团队能够严格按照这个流程来运作。在项目到达每一个里程碑的时候，QA 部门的 QA 经理就会介入，对项目做一个审核，检查前一阶段的工作是否按照公司制定的流程来运作。看看该有的工件是不是都有了，该有的步骤是不是都有了。开发团队要证明给 QA 人员看。只有过了这一关，QA 部门才会同意说开发团队可以往下走，进行下一步的工作。所以严格来讲，众广义上理解，SQA 是针对整个软件开发流程的，它关心的是怎样在软件开发生命周期中来保证好软件的质量。这是一个非常大的概念。

问： SQA 在 RUP 中是如何体现的？

答： 其实 RUP 整个流程都在讲 SQA。业界常见的模型，譬如 CMM/CMMI，六西格玛，ISO9000，RUP，它们做的基本上是同一件事情--都是在做流程改进，都在做质量控制，但是各自的侧重点不一样。像 RUP 和 SDP 专门侧重于从软件开发的整个生命周期来保证软件质量，所以对软件开发商特别适合。而其它的模型，侧重点则在其它的环节，比如说 ISO9000，用在制造业比较多一些； CMM，原来是应用在软件这个行业的，后来扩展到 CMMI，就扩展到其它行业它也适用。但适用面越广，它拉的层次就越高，可实际操作的东西就越少。RUP 是专门侧重于软件项目开发的。怎样来保证做好 QA 呢？ RUP 里定义了一个软件生命周期模型，分成四个阶段--初始阶段、细化阶段、构造阶段、交付阶段，每个阶段有不同的侧重点，通过多次的迭代，每次迭代里面都要做质量控制。

质量控制从需求开始，有很多需求分析和需求管理方面的技巧和技术方法，它们从需求方面来保证软件的质量；到了设计，就有很多成熟的设计方法，例如可视化建模，基于构件的架构设计和现在提出的模型驱动开发方法；再到实现，到测试等方面，都有很多的方法和技巧来提高软件的质量。这里面每一个环节的目的都是为了提高整个软件开发的质量。

开发过程中，什么样的问题会造成质量问题呢？其实最主要的就是沟通方面的问题，以及对系统复杂度把握程度的问题。我们逐渐发展了一些技术来帮助我们解决这些方面的问题，例如用 UML 这种标准化的语言来增强团队的沟通，用面向对象的技术来帮助加强对复杂度的控制能力。

原来这个系统很复杂，使用面向对象的方法，本身就是为了简化系统构建的复杂度。改变你看问题的角度，你对问题的把握程度就会不一样。譬如人看一个二维迷宫很容易就能找到出路，但蚂蚁在里面就走不出来，因为看问题的角度不一样。面向对象方法和可视化建模技术可以让开发人员可以更好地去把握系统，增强对系统的可控制能力，从而从这些维度上来提高和保证软件的质量。

现在有很多自动化的工具，如 IBM Rational RAD(Rational Application Developer)/ RSA(Rational Software Architect)，都是支持 MDA 的开发方法，在模型这一级进行开发，从模型直接生成代码。在开发方面我们有很多辅助工具，帮助开发人员尽量将人工做的工作、复杂的重复性的工作、不具有创造性的工作让工具来做。让人去关注他应该关注的方面，比如开发人员应该关注业务逻辑的处理，但是软件的构建方面我们是尽量让工具来降低构建细节上的难度。这样也是有助于提高质量的。

然后产品出来了，需要进行测试，有测试流程、测试规范来帮助保证质量，这是最直接的。然后还有很多的环节还会发生错误，比如配置管理、版本的管理，也需要相关的支持来保证软件的质量。所以说软件质量保证不应该只是在一个环节上，比如测试环节来保证，而应该是整个的流程，我们应该全面地去改进流程来保证质量。

问： 做 SQA 这方面的人员，在沟通方面需要的什么样技巧和能力？

答： 首先从大的方面说，整个团队的沟通，首先是大家要讲同样的语言。UML 只是这种语言的一部分，我们不要狭义地理解这种沟通语言就是 UML。它还包括采用一个什么样的流程方法，整个团队都要理解。譬如你说项目正处于 “ 精化(Elaboration)” 阶段，这个团队都要能理解这个术语。

还有就是整个组织机构内部大家采用的流程都是要一样的。举个例子来说，Rational 有很多产品，其中很多都是收购来的。不同的产品团队采用的开发方法、开发工具都是不一样的，他们到了 Rational 之后做的第一件事就是整合。这个整合一方面是说产品要整合起来（我们有 Suite 产品）；同时也是针对开发团队开发方法的整合，例如 Rational 花了一两年的时间把所有产品团队统一到 RUP 和 ClearCase/ClearQuest平台之上，这是我们的首选。实际上到了 IBM 之后也是一样，IBM 现在正在做的计划就是让所有的实验室、研发团队都要使用 IBM Rational 自己的开发工具，他们都在使用 IBM 自己的开发方法、开发平台。这就是让大家的沟通基于一个统一的基础架构 ―― 统一的软件开发平台，这也是增强沟通的一种方式。另外，讲到 SQA 的人员，在 RUP 里对应的就应该是 Process Engineer。他的主要的职能就是定义流程，保证流程的执行，并且不断地改进流程。对他的要求就是要对流程要比较了解，有实际项目的开发经验，不然没有办法理解流程，这是技能方面；另外就是与人的沟通能力要强，跟一般的开发人员和项目经理是有区别的，沟通的能力一定要强，他要负责说服项目团队来遵循标准。

问： QA 人员与目经理和开发人员之间的关系是怎样的？

答： 首先彼此之间是一个合作的关系。如果片面理解 QA 人员只是 “ 过程警察 ” 的话，就可能把他和其他的角色对立起来了。实际上在一个团队内部要避免这种认识。因为大家都是在一个组织架构内部的，大家的目标是一致的，就是要把公司的业务做好。所以 QA 人员的职责和任务就是帮助这个项目团队更好地进行软件的开发。既然已经定义的流程是比较适合企业的，项目就应该遵守这个流程来进行开发。如果有时候项目因为赶工，或是其它的原因违背一些流程上的规定的话，就会对软件的质量会造成一定影响，他就有责任来帮助开发团队来纠正这方面的一些错误。还有就是进度方面的问题。如果不按照流程来走的话，短期内看起来进度是快了一点，但从整个项目的周期来看，有可能是给以后的工作带来隐患，客观上肯定是延长整个开发的进度的。所以对于一些流程管理得比较好的企业，你会发现他们的 QA 部门和开发团队是相处得比较融洽的，配合是比较紧密的。在我们的客户里就看到过他们的开发团队非常感谢自己的质量控制人员，觉得他们对自己是给了很大的帮助。

QA 人员跟每一个角色的关系，如果你对应到 RUP 的话，RUP 里就定义好每一个角色是做什么工作的。RUP 里分了 9 个规程(discipline)，流程工程师是在环境规程里边，项目经理是在项目管理规程里边。每一个规程其实就是一类开发活动，其中的角色和他们所产生的工件集合，是一个分类。可以把项目经理相关的工作，他所涉及到的工件，比如说软件开发计划、风险管理计划、质量保证计划都放在一起，放在这个规程里面。所以 QA 人员跟项目经理的关系就是去检查项目经理在这个岗位上所做的职责是否到位，是不是跟流程相符合。其他的角色也是一样的，譬如一个测试人员，就要看你有没有根据规定把缺陷按正确的测试流程汇报，发现缺陷之后是否能够得到改正，并作一个复审，还有回归测试的时候有没有考虑测试的完备性等问题，就是看测试人员有没有做好具体的工作。QA 人员和整个项目团队在工作中的关系就是看每一个角色是不是很好地完成了自身角色所应该完成的开发任务。标准是什么？就是这个组织的流程，流程是保证质量很重要的一个依据。

问： QA 人员如何判断其工作效果和质量？

答： 最直接就是 RUP 里的工件。可以去检查这些工件，可以根据检查的结果来判断角色是否达到了要求。既然是检查这个结果的话，就有必要涉及到统一流程和工具的问题。就是说开发团队有必要采用统一的开发方法和流程。不然的话每一个开发团队各自采用不同的开发流程，流程工程师就很难去评价，没有一个可对照的标准，没有可比性。另外，和采用的工具也有关系，就是说团队要尽量采用统一的开发平台。采用统一的开发平台，工具会帮助自动收集很多的信息。比如说我们的 Project Console 可以帮助收集很多量化的指标；现在有 Portfolio Manager，项目组合管理平台，可以帮助了解项目进度还有项目进行过程中产生的各种结果；还有包括测试的报告等等，这些都最好有一个统一的标准。打个比方来说，现在的航空公司都会选择相同飞机制造厂商的机型，就是要降低维护的成本。因为机型比较统一的话，就比较好进行管理。在一个软件企业的话，在内部采用统一的软件开发平台也能有助于企业判断项目的情况，判断的方法也会相对比较简单，工作量会降低。

这是从 QA 的角度来看，其次从整个团队的角度来说，今天是做这个项目，明天做另外一个项目，作为企业的管理人员肯定不希望员工今天做这个项目用一个工具，明天做另外一个项目用另外的工具，这样学习成本就太高了。

第三篇：测试工作经验总结

测试工作经验总结

功能测试最重要的是理解业务和需求。知道系统要实现什么功能，业务流程是怎样的，然后就可以根据需求编写测试计划和测试用例了。测试书籍上介绍常用的编写测试用例的方法有：等价类、边界值、因果图、判定表等，在实际工作中，我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点，将测试用例按测试目的进行分类，比如用户界面、功能点、业务场景等，会让测试用例的结构看起来更清晰，执行测试用例的效率也更高。

要做好功能测试，还需要对整个系统的数据库结构比较清楚，每个功能点涉及哪些数据表，对数据的操作方式是怎样的。这样就不单从前台页面来进行测试，通过对数据库中数据的验证，可以发现隐藏的一些bug。比如库表没有进行关联删除，从前台页面是看不出来的，但实际可能导致程序出现问题。对一些比较复杂的组合查询或数据排序，也可以自己编写sql语句对结果进行验证。

了解程序的框架结构和一些开发知识也有助于更好地测试程序和定位错误。

测试用例的编写经验步骤和数据的分离

将输入的各种数据已参数的形式表达在操作步骤中，而不需要为每一种输入数据创建一个测试用例。

例如：atm存款

好的测试用例，在执行的步骤(Step)的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：

1.密码正确的登录

2.密码错误的登录

3.密码输入三次错误，卡被锁定

4.取少于余额的款项

5.尝试取大于余额的款项

6.尝试取等于余额的款项(考虑手续费)

6.取款额度大于当次的限制

7.取款额度大于当天的限制

7.取款次数大于限制次数

等等

不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下(此处只列出了操作的步骤，略去了系统的交互中的反馈结果)：

1.插入卡->A:输入密码->B:按“确定”键->重复A-B

2.A:选择取款功能->B:填写取款金额->C:点击“确定取款”的按钮->D:取现金->重复A-D

因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢?单独的测试基础数据准备工作

将测试基础数据提前准备好，写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。测试用例的前后置条件

除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。

顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。

第四篇：手机测试经验总结

手机测试经验总结

VPM主要是激励团队成员测试和学习，而不是自己去执行用例。当被委派为一个项目的测试经理时，VPM应该清楚项目计划和转折点、软件发布时间表、产品定义特征列表。

1、作为VPM应具备以下几方面能力：

（1）、用不同的方式看待问题

（2）、制定计划，满足项目上市时间

（3）、依据质量、时间、成本对PR进行判断和决定

（4）、增进沟通，总结不同项目的经验

（5）、和团队的密切合作

2、测试工作点：

（1）、测试软件机制

（2）、分析问题

（3）、对产品进行认证并得到相应证书

（4）、评估对于返修率、最终用户和运营商抱怨的影响

若做欧洲市场的产品，一定要做CE认证。FCC认证在Latam市场是必须的，CTA认证在中国是必须的。

一、相关测试知识学习

1、软件测试包括测试计划、测试设计、测试执行、测试评估这几个阶段；

测试计划：

了解软件当前状态及客户对软件的需求；

了解产品规格书：按键定义及菜单树；

管控和跟催软件方案商的版本发布时间；

测试设计：根据客户需求和产品规格说明书来编写测试用例；

测试执行：测试策略包括基本功能测试、UI测试、冲突测试、压力测试、兼容性测试、验收测试

测试评估：进行三次全面测试，由方案商发出软件和报告，TMC和SZ Team

同时测试并反馈给方案商，如此反复数次，方案商改善结果并商讨最终结论。

2、场测

在硬件成熟、软件基本成熟的情况下做场地测试，主要测试这几项：寻网时间、呼通率数据、通话质量、Wap测试、FM测试、信息、紧急呼叫、基本功能测试。

3、说明书测试

验证说明书基本功能是否正确，是否清晰易懂、排版规范、无错别字等。

4、认证分类

按照销售地区分为国内认证和国外认证，国内认证是CTA认证，国外认证是CE认证和FCC认证。CTA认证需要拿到国家无委颁发的入网证书、受理中心颁发的许可证书、3C认证颁发的3C证书。

第五篇：软件测试经验总结

软件生命周期(SDLC)的六个阶段

1、问题的定义及规划

此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

2、需求分析

在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。“唯一不变的是变化本身。”，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。

3、软件设计

此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。

4、程序编码

此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。

5、软件测试

在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。

6、运行维护

软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

2、软件生命周期模型

从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为“生命周期模型”（Life Cycle Model）。

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。

瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来。迭代模型比瀑布模型问题暴露的要早；快速原型法比瀑布模型直观。

3.软件测试概念

广义概念：指软件生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段，以及完成开发后维护阶段的各类文档、代码的审查和确认

狭义概念：识别软件缺陷的过程，即实际结果与预期结果的不一致

4.软件测试目的测试的目的就是发现软件中的各种缺陷

测试只能证明软件存在缺陷，不能证明软件不存在缺陷

测试可以使软件中缺陷降低到一定程度，而不是彻底消灭

以较少的用例、时间和人力找出软件中的各种错误和缺陷，以确保软件的质量

5．软件测试原则

Good-enough: 一种权衡投入/产出比的原则

保证测试的覆盖程度，但穷举测试是不可能的所有的测试都应追溯到用户需求

越早测试越好，测试过程与开发过程应是相结合的测试的规模由小而大，从单元测试到系统测试

为了尽可能地发现错误，应该由独立的第三方来测试

不能为了便于测试擅自修改程序

既应该测试软件该做什么也应该测试软件不该做什么

6．软件测试的的重点

测试用例的设计

测试用例的设计是整个软件测试工作的核心

测试用例反映对被测对象的质量要求，决定对测试对象的质量评估

测试工作的管理

尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提

测试环境的建立

测试环境应该与实际测试环境一致

7．黑盒测试

什么是黑盒测试

又称功能测试或数据驱动测试，是针对软件的功能需求/实现进行测试，通过测试来检测每个功能是否符合需求，不考虑程序内部的逻辑结构

黑盒测试方法

功能划分

等价类划分

边界值分析

因果图

错误推测等

8．什么是白盒测试

白盒测试也称结构测试或逻辑驱动测试，必须知道软件内部工作过程，通过测试来检测软件内部是否按照需求、设计正常运行

白盒测试的主要方法

对应于程序的一些主要结构：语句、分支、逻辑路径、变量；白盒测试的主要方法是： 语句覆盖方法

分支覆盖方法

逻辑覆盖方法

什么是动态测试

动态测试需要在开发/测试环境或实际运行环境中运行软件，并使用测试用例去查找软件缺陷；动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等

10.什么是静态测试

静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估.静态测试包括代码检查、程序结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行

11.手工测试和自动测试

a.手工测试缺点在于测试工作量大，重复多，回归测试难以实现

b.自动测试利用软件测试工具自动实现全部或部分测试工作：管理、设计、执行和报告；节省大量的测试开销，并能够完成一些手工测试无法实现的测试

手工完成测试的全部过程无法保证测试的科学性与严密性:

修改的缺陷越多，回归测试越困难

没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率

反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一

测试花费的时间越长，测试的严格性也就越低

自动测试将测试人员从反复、烦杂的测试执行中解放出来，用更多的时间进行测试设计和结果分析

软件测试不可能完全自动化

不能完成所有手工测试任务

无创造性且灵活性差，不能改进测试的有效性

过程中可能会遇到许多意想不到的问题，特别是当软件不稳定时

测试脚本的维护高

12.测试流程

单元测试

集成测试

系统测试

用户验收测试

回归测试

确认测试报告

13.单元测试

完成对最小的软件设计单元—模块的验证工作

目标是确保模块被正确地编码

使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误

通常情况下是面向白盒的对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早地发现和解决不易显现的错误

单元测试的内容

接口测试

内部数据结构

全局数据结构

边界

语句覆盖，错误路径

14.集成测试

通过测试发现与模块接口有关的问题

目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构

应当避免一次性的集成（除非软件规模很小），而采用增量集成集成测试主要内容

API(Application Programming Interface,应用程序编程接口)

API/参数组合15．系统测试

根据软件需求规范的要求进行系统测试，确认系统满足需求的要求

系统测试人员相当于用户代言人

在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作

系统测试主要内容

所有功能需求得到满足

所有性能需求得到满足

其他需求（例如安全性、容错性、兼容性等）得到满足

16.用户验收/确认测试

Alpha测试

是由用户在开发者的场所来进行的，Alpha测试是在一个受控的环境中进行的Beta测试

由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者

17．压力测试VS性能测试

性能测试的目的不是去找bugs,而是排除系统的瓶颈，以及为以后的回归测试建立一个基准。而性能测试的操作，实际上就是一个非常小心受控的测量分析过程。在理想的情况下，被测软件在这个时候已经是足够稳定了

性能测试是为了检查系统的反映，运行速度等性能指标，他的前提是要求在一定负载下，如检查一个网站在100人同时在线的情况下的性能指标，每个用户是否都还可以正常的完成操作等。

概括就是：在不同负载下（负载一定）时，通过一些系统参数（如反应时间等）检查系统的运行情况；

压力测试是为了发现系统能支持的最大负载，他的前提是要求系统性能处在可以接受的范围内，比如经常规定的叶面3秒钟内响应；概括就是：在性能可以接受的前提下，测试系统可以支持的最大负载。

举例说明：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。

18.主流测试工具的测试流程

========winrunner启动时选择要加载的插件进行一些设置（如录制模式等）识别应用程序的GUI，即创建map(就是学习被测试软件的界面）建立测试脚本（录制及编写）对脚本除错及调试（保证能够运行完）插入各种检查点（图片，文字，控件等）在新版应用程序中执行测试脚本分析结果，回报缺陷

=========quicktestpro========准备录制

打开你要对其进行测试的应用程序，并检查QuickTest中的各项设置是否适合当前的要求。2 进行录制

打开QuickTest的录制功能，按测试用例中的描述，操作被测试应用程序。编辑测试脚本

通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。调试脚本

调试脚本，检查脚本是否存在错误。在回归测试中运行测试

在对应用程序的回归测试中，通过QuickTest回放对应用程序的操作，检验软件正确性，实现测试的自动化进行。分析结果，报告问题

查看QuickTest记录的运行结果，记录问题，报告测试结果。

＝＝＝＝TestDirect============

安装好后，先进入站点管理创建域及工程添加用户编辑licenses及本服务器编辑数据库

－－TD选择新建的工程进行定制(列表，用户，组，版本等)在require中增加需求把需求转化为plan在testlab中由计划新建测试具体用例与执行发现bug，在defect中提交bug

（每一部分都可以相对独立地使用）

======loadrunner制定负载测试计划

(分析应用程序，确定测试目标，计划怎样执行LoadRunner）开发测试脚本

（录制基本的用户脚本，完善测试脚本）创建运行场景

（选择场景类型为Manual Scenario，选择场景类型，理解各种类型，场景的类型转化）监视场景（MEMORY 相关，PROCESSOR相关，网络吞量以及带宽，磁盘相关，WEB应用程

序，IIS5.0，SQL SERVER，NETWORK DELAY等)

分析测试结果

7(分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其他有

用的功能)