软件测试学习体会Vol31

1、软件测试学习体会Vol 31架构测试的定位和作用1、概述本文所指的测试，包括了对工作产品进行质量控制的所有相关工作，如：理论分析与类比、专家评审、代码走查、程序运行验证等。测试，并不是一个独立的阶段，它不是仅在将产品交付给用户之前才进行，甚至也不是在软件生命周期中每个阶段结束时进行，而是和所有的软件生产过程并行。架构测试，主要是为了降低系统在可用性、易管理性、性能、可靠性、可伸缩性和安全性等方面的风险，利用系统原型，对系统主要架构、关键技术、核心数据设计、统一规范等进行的测试，在项目早期阶段确认系统能否满足用户需求及对产品的定位。架构测试由产品研发团队组织，相关人员参与，特别是需要尽早获得客户

2、的反馈和认可。在以往的开发工作中，很多项目组已经自发进行了很多架构测试相关的工作，但完备的架构测试还没有上升到组织级规范和约定。2、架构测试定位2.1应用需求决定软件架构对应用软件存在着各种需求：功能需求、非功能需求、变更案例等等。一般来说，功能需求决定业务架构、非功能需求决定技术架构，变更案例是将来可能要(或可能不要)满足的，但现在不需要满足的需求。功能需求定义了软件能够做些什么，我们需要根据业务上的需求来设计业务架构，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的约束、规则、标准，而我们的技术架构要能够满足这些约束和规则。变更案例是我们在验证软件的可扩展性、可维护性

3、时需要重点考虑的内容。我们希望一个好的架构能够：重用、可靠、延展、简明、高效、安全。如果说功能需求定义了架构设计的目标的话，非功能需求就对如何到达这个目标做出了限制。进行系统设计初期就需要开始注意非功能需求，因为如果忽略它们，在后期需要花费很大的精力来调整架构模型。2.2架构测试的主要工作内容目前公司在架构测试方面需要进行的工作主要有：1.验证系统整体架构是否满足需求：软件的处理能力是由其架构决定的，良好的架构模式是应用高性能的基础。面对不合理的系统架构，即使编码技巧再高，应用也不可能有良好的性能。所以，需要尽早测试、不断测试，以便验证系统整体架构是否具有可靠性、高性能。2.验证应用主要技术实

4、现的可行性在编码开始前，需要对应用主要技术实现的可行性进行验证，主要包括：资源的使用与释放，数据库连接模式，页面数据量的合理分配，数据传输压缩技术的使用，识别应用可能的性能瓶颈。3.验证系统核心数据设计的合理性：很多应用面临着大量数据处理，数据表存储空间的划分、数据库结构的设计是否合理、索引的建立是否正确等，都会影响系统的整体性能。而且很多时候数据库结构的变动对应用的影响非常大，因此在项目早期需要对系统核心数据管理设计的合理性进行验证。4.应用架构易维护性、易扩展性的测试和验证：软件在设计时都为未来业务的伸缩和扩展留出了空间，在做架构设计的时候，变更案例也是设计的考虑因素之一，为了尽量减少软件

5、的后期维护、修改、测试工作量，良好的软件架构应该具有很好的易维护性、易扩展性，这也是架构测试的验证内容。5.项目组统一规范的测试和验证：合理的设计和编码规范，对提高系统整体风格的统一和软件的易维护性、易测试性很有帮助。有一些组织平时并不注意标准(风格)的积累，认为这种积累属于雕虫小技，但正是这些小技，能够非常有效的提高沟通的效率和降低开发人员的学习曲线。对涉及到具体实现技术的编码设计规范，必须经过测试验证后才能纳入组织的统一规范中。3、架构测试总结3.1架构测试与性能测试1.架构测试有的系统，虽然从在一定条件下的某些测试看，性能比较理想，但是随着数据量、用户量的提高，系统的性能难以满足业务的扩

6、展，并且整体性能难以优化，这说明其从设计架构上就存在致命的缺陷，架构的延展性不够好。实践证明：系统的可靠性和性能是由其架构决定的。如果能抓住架构测试的核心内容，对协助项目组控制技术风险、提高开发质量、降低开发成本都可以起到很好的促进作用。2.性能测试有的系统虽然某些功能暂时性能不理想，但随着程序算法的优化，系统性能提高很大，能很好地满足业务的扩展性。这说明系统的架构设计很合理，算法的完善、改进优化是比较容易实现的。这样的系统通过性能测试比较容易发现问题、改善系统性能质量。通过系统上线前的性能测试，可以对系统主要功能进行抽样检测，从而基本确定一定条件下系统的预期性能，识别系统可能存在的性能瓶颈；

7、3.体会根据很多项目的开发规律，在设计阶段项目进度相对比较宽松，但项目上线前一般非常紧张，此时主要精力放在了完成业务功能以及数据逻辑处理的正确性上，对性能测试提出的问题可能无暇顾及。因此，比较可行的方案是：1)重视架构设计，对系统主要架构、关键技术、核心数据设计、统一规范等利用原型进行实现，在开发过程中，通过理论分析与类比、专家评审、代码走查、程序运行验证等手段，确认系统能满足用户需求及对产品的定位；2)在系统上线前利用Loadrunnert等性能测试工具，对系统整体性能进行验证和评价，保证系统上线时满足用户当前并发处理要求和主要功能的性能。对一般功能的性能问题，如时间、进度等不允许，可暂不关

8、注和处理；3)系统上线初期一般选择部分客户端试运行，必须密切跟踪生产环境下系统性能随着数据量、业务量、用户量变化而下降的幅度。如条件允许，可开启数据库监控开关，或者通过监控服务器日志、应用日志等手段，分析实际生产环境下性能不理想的功能模块，结合性能测试结果，以及用户的实际感受和反映，对具体功能的设计及算法进行优化；4)如果通过对具体功能的设计及算法进行优化，不能有效提高系统的可靠性和性能，需要重新评价系统的架构、技术实现、数据设计等是否合理。3.2如何做好架构测试?总结各项目的测试过程，架构测试的难点：1.架构测试内容与手段：架构测试需要测试的内容包括系统的主要架构、关键技术、核心数据设计、统

9、一规范等，需要具备行业高水平的专家进行评审，以及需要编制各种测试脚本进行程序运行验证；2.测试的基准难以把握：例如对综合业务系统产品，IBM P55A作为服务器，一定数据量的前提下，系统能支持多少用户、响应时间在什么范围内可以认为通过测试?这就需要我们对产品性能指标有个清晰的定位，像是access、Sql Server、Oracle各有不同的性能指标。3.测试人员对系统的理解难以达到一定深度，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。架构测试需要项目经理的协助、开发人员的大力支持，特别是，需要技术经理的全程参与。架构测试需要验证的是系

10、统的核心架构、主要技术实现模式、核心数据库设计、统一规范等，这些工作需要技术经理的指导和帮助，对测试内容的确定、测试结果的分析、测试过程中需要编制的测试脚本等工作全力协助。架构测试对测试工程师知识的深度和广度都是一个考验。对于复杂系统的架构测试，到底如何使用什么样的测试策略、如何分析测试需求、如何选取性能度量项的转换计算模型、如何确定测试内容和轮次、如何设计性能测试案例等等以及规划和实施性能测试中的其它诸多问题，都需要遵循一个系统的方法来解决。=分割线=分割线=解读测试能力素质模型软件测试的能力素质模型(Job Model)，是对不同层级测试工程的能力要求进行明确的定义。目的是为了对每位工程师

11、的能力进行科学的评估，然后分配合理的工作，也帮助大家明确职业规划的方向。淘宝测试工程师的最常用的有4个，分别是：测试工程师(P4)高级测试工程师(P5)资深测试工程师(P6)测试专家(P7)大家注意，不同软件公司对工程师的级别命名会有不同，大家只要理解它们之间的区别就行了，不必纠结具体的名称，那些都是虚名，就像浮云一样。一般大学毕业生加入测试团队，层级就是P4。对P4工程师的能力要求是比较基础的：熟悉软件测试流程，通过阅读文档和沟通可以了解产品的需求，独立设计测试用例TC，执行TC并记录缺陷，完成缺陷跟踪。P4的职责要求是不要出现测试遗漏，特别是不能遗漏一些既严重又初级的Bug。招聘P4工程师

12、的时候，我们重点关注应聘者对计算机软件使用是否熟练，比如测试工作经常涉及的操作系统、Office、浏览器等等；是否能清晰的描述一个事物或者一个过程，因为在记录缺陷的时候，需要让开发工程师很快了解缺陷的重点；与人交流的时候是否可以很容易的表达和理解，因为测试工程师需要经常和产品经理、开发工程师交流需求、设计的内容。与P4工程师相比，P5工程师的一个关键词就是独立。P4工程师可以很好的完成你分配给他的单项任务，比如测试某个功能模块；P5工程师则能够完成一个较大的系统任务，比如一个项目的测试。你可以放心的把一整件事情交给P5，他会主动的推动任务的完成，会主动解决过程中遇到的问题。P5工程师需要了解更

13、多的测试类型和测试策略，比如性能测试、易用性测试等等，当他接到一个项目后，可以分析出来，每个模块需要使用哪种测试策略，那些模块需要重点测试。P5也需要制定测试计划，安排时间表，这些都是P5的工作重点。我已经独立做了好几个项目的测试了，能达到P5么?由于资源的问题，可能很多P4工程师都独立做过一些项目，因此会产生上面的疑问。判断是否达到P5，并不仅仅看是否做了项目，而是重点看你对过程和质量的把握。这么说有点抽象，举两个例子说明。在制定测试计划的时候，测试组长会决定测试策略(How)和测试工期(When)，这时需要PM和开发对测试计划进行评审。P5制定的测试计划，会得到项目组的认可和信服。可是如果

14、测试组长说，这里要重点测试，开发说根本不用，或者测试组长说测试需要1个月，PM直摇头说，哪要那么久，半个月就够了，那就说明能力还差把火。再说个例子，P4可以把一个模块的Bug都找出来，但是如果问他，项目现在的质量好不好，什么时候可以发布，P4难以回答。而P5就可以很好的回答这个问题，他可以和PM站在平等的位置上，讨论质量和风险，商量发布日期，PM也很信任P5做出的质量评估。简单的说，P5可以很自信的站在PM面前，说，我认为现在的质量不合格，因为.，现在不能发布，并且PM也认可。下面讲一下P6，P6的关键词是创新，P6的工作效率较P4、P5有很大的提高，具体表现在下面几个方面。P6对被测软件的结

15、构和相关的开发技术有深入的了解，因此P6在提Bug的时候，定位非常准确，还可以分析出Bug的原因，也能发现一些深层次的Bug，开发工程师与P6测试工程师合作时，会感觉非常high。P6会经常想出一些新的方法或者技巧进行测试，让测试速度更快，决不是只在UI层测试。P6善于发现工作中的一些重复性劳动，然后用技术手段，把这些重复工作自动实现。P6善于思考，一刻也停不下来，你总是能从P6的口中，听到一些新的东西，因为他一直在考虑，怎么把工作做得更快更好。是不是只有会编码，会开发工具，才能到P6?单纯的编码能力，在大学学习的时候，一般就已经掌握了。P6需要的是软件技术的广阔知识面，编程语言、编程工具、流

16、行框架、开源组件、数据库等等。当他遇到问题的时候，善于运用这些技术，找到最优的解决办法。单纯为了编码而编码，没有运用在实际工作中，是没有意义的。最后说说P7，P7也需要创新，但是比P6的创新要复杂一些，关键词应该叫做革新。P6的创新可以让自己工作得更加高效，P7的革新则能够让整个团队的工作效率提升。P7对技术的理解更加成熟，在解决问题的时候，也不仅只考虑技术手段，而是要系统的分析，全面考虑各种方案的可行性，制定出最优的解决方案，下面的例子可以很好的说明。当我们感觉到工作中有一些环节，工作量大，重复性高，并且投入产出比较低，P6的做法是开发一个工具，把自己从这些工作中解放出来；P7的做法是，策划

17、一次创新，用新的方案取代，并运用技术手段来实现。关于各个层级的测试工程师能力要求，我们就谈到这里。关于Job Model，我想大家最常问的问题就是：我想晋升到更高一级，应该怎么做呢?希望这篇文章能帮您理清一些思路。=分割线=分割线=LoadRunner设置检查点的几种方法介绍关于性能测试的问题，谈到如何评估测试结果，有一个朋友谈到规范问题，让我颇有感触，他说他们公司每次执行压力测试的时候，都要求脚本中必须有检查点存在，不然测试结果将不被认可，这是他们公司的规范。其实，在做压力测试过程，我们很容易忽略很多东西，而且随着自身的技术演变，我们很容易去丢失掉一些很好的习惯，当我们再碰到这些问题的时候，

18、我们才发现其实是我们太粗心大意了，所以说好的习惯要保持。这次我刚好也要接手一些性能工作，因此就如何规范设置检查点来谈谈一些基本的流程和方法。使用LoadRunner做压力测试，大致如下几个流程：1、明确测试目标2、录制测试脚本3、脚本优化、调试4、场景运行5、分析测试结果当然这里都是概况性的标题，但从这里我们可以明确的是测试脚本是整个压力测试过程中的重点步骤，如果测试脚本都不能确保正确与否，后面的测试过程就无从说起了。很多时候我们把脚本调试就简单的认为是脚本回放没有错误就认为脚本是没有问题的，这当然不能这么肯定，脚本调试是一个非常严谨的过程，我大致归纳如下几步：1、明确每一行脚本的作用，也就是

19、说每一行脚本执行的功能是什么；2、删减不需要的脚本语句，比如在录制过程由于LR默认设置导致录制之后出现很多冗余的脚本，这些个脚本对我们的测试过程没有用途的应该删除掉，至于哪些是冗余就要具体分析了，所以说脚本录制完之后要分析脚本运行的过程，方能理解脚本执行的用途，不然在后面施压时运行错误，就会开始到处找问题，而又找不出问题；3、查找存在的关联并进行相关设置4、设置检查点，设置检查点的目的就是为了验证页面每次运行之后是否正确，设置检查点的过程总要通过不能的回放来进行验证检查点设置是否正确。5、通过测试目标明确脚本执行的目标事务，并添加事务；6、对需要进行并打操作的功能设置集合点7、根据实际情况设置

20、ThinkTime 8、在以上所有脚本调试步骤完成之后，设置迭代次数，通过在Vuser中设置多次迭代来验证脚本在多次循环运行时是否存在错误注意：在Vuser中运行和回放脚本的过程，要密切关注replay log，也就是回放日志，很多问题通常都暴露在回放日志中，只不过我们没有认真去检查，所以没发觉。因为大多数情况是我们在回放脚本之后只观察回放日志中有没有红色的错误提示信息，如果没有我们就认为我们的脚本是ok的，其实不然，很多时候一些隐藏的错误就在回放日志中可以被发现，比如回放日志中的Warning信息，也就是警告信息，这些信息一旦你不去理会它，它将在场景运行过程中开始频繁暴露出来，而在场景中报错

21、之后我们就认为可能是系统有问题或者是测试过程存在其他问题等等，而很难去考虑到是脚本的问题，是脚本在Vuser中调试就存在的问题。还有的时候一些问题在一次脚本回放中就不能被发现，他需要通过Vuser中设置多次迭代才能在回放日志暴露出问题来，所以说我们通常的思维就是一旦测试脚本没有一次回放没有出现错误，就去场景中运行，结果在场景中哪怕是运行10个用户都还会报错，这就是问题的根源所在。下面还是重点说说检查点吧，三种常用的文本检查web_reg_find的方法：1、将脚本切换到树结构，在page view页面上找到你要check的文本内容，并执行鼠标右键，选择Add atext check.2、通过Vuesr界面去设置检查点。3、将脚本切换回代码界面，在光标闪烁的上行，添加如下的代码：添加的代码根据你检查的方式不同而不同，你可以选择其中之一即可。代码一：web_reg_find(Text=Payment Details,LAST)；注：Payment Details为你要检查的文本；脚本执行到此处，若在页面上找到了这几个字符串，那脚本继续执行下去；若没有找到，脚本将在此报错并且结束。代码二：web_reg_find(Text=Payment Details,SaveCount=para_count,LAST)；/check