阿里巴巴测试题目

1、请说出测试用例的五个要素2、怎么样的需求变更才是合理的3、LOADRUNNER测试工具熟练程度，如何分析性能评价4、测试工具QTP熟练程度，遇到控件不识别的情况5、是否有写测试报告，包括哪些内容6、好的bug流程应该是怎么样的7、有没有做过风险评估8、相对于其他测试工程师有什么优势9、你的缺点是什么？10、与开发员发生冲突如何解决11、与上级领导发生冲突如何解决12、工作中遇到问题如何解决13、若遇上需求描述不清楚如何解决14、怎么样的需求描述才是好的15、你的短长期规划16、怎么样的系统需要做性能测试17、什么时候开展性能测试才是好的18、怎么样的工作环境才能让你有工作效率3. LoadRunner，是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施 并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行 测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统 的发布周期。LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系 统行为并优化系统性能,1分析概要报告2运行用户3秒钟点击数4吞吐量4事务分析5平 均事务响应时间6Web页面的详细分析4. 经常有朋友问：QTP无法识别某些自制的控件或无法录制某些控件的操作，我怎么解 决这个问题？我想解决方法有下面几个：1添加相应的Add-in是解决此类问题的第一选择，如果有相应的Add-in的话。例如如果 是测试Java类的程序，就要加载Java Add-in。你安装好QTP后，有三个Add-in ( ActiveX、Visual Basic和 Web)就被装载了。除此 以为，QTP 8.2 版本还可以装载的 Add-in 有 QuickTest Professional Java 6.5 Add-in、 QuickTest ProfessionalOracle 6.5 Add-in、QuickTest Professiona Siebel 8.0 Add-in 和 QuickTest Professional Terminal Emulator 8.0 Addin。(每个版面的 QTP 可以加载的 Add-in 可以在相应的 QTP_Install_Guide.pdf 和 Main_Users_Guide.pdf 中找到。)2把不能识别的对象设置为虚拟对象(Virtual Object)依次点击 QTP 的 “Tools”- Virtual ObjectsNew Virtual Object.，就会出现 Virtual Object Wizard对话框，你根据Wizard的指引，就可以把添加一些支持的不好的控 件设置成虚拟控件，也就添加到对象库了。CODE:Copy to clipboard在QTP 8.2添加虚拟对象的具体操作步骤是：1， 依次点击 Tools- Virtual Objects- New Virtual Object.，打开虚拟对象向 导，点击Next；2, 选择 Class 为 button，点击 Next；3, 点击标记对象按钮；4, 选择要操作的对象区域，点击Next （对象区域就是你要操作的那个对象，就是login 按钮）；5，默认，点击Next；6，完成。3针对特殊问题有特殊的解决方法。如果不能识别的控件是用VC做的，那么你可以自 己写一个动态链接库，然后让QTP去调用它。至于QTP如何调用动态链接库，请看附 件。五.给你一个测试报告模板作为参考：XXXXXXX X系统测试报告拟制：日期：yyyy-mm-dd审核：日期：yyyy-mm-dd修订记录日期修订版本 描述 作者2004-12-081.00初稿完成xxx目录1概述2测试时间、地点及人员3环境描述4测试对象质量评估4.1覆盖率统计4.2测试对象质量评价5测试过程评估5.1测试设计评估5.2测试执行评估5.2.1测试执行统计数据5.2.2测试用例执行结果统计数据附件附件1：遗留问题报告遗留问题统计附件2：交付的测试工作产品测试报告关键词：摘 要：本文是XXX系统测试报告，对XXX的测试用例设计、测试执行、各特性质量进行总结缩略语清单：对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中文解释。1概述2测试时间、地点及人员版本名称测试时间测试人员测试地点起始时间结束时间3环境描述PC机一台，配置不同Windows操作系统+VC6。04测试对象质量评估4.1覆盖率统计本次测试对以下需求进行了覆盖，所执行的用例对需求覆盖情况如下：需求ID 需求名称对应用例4.2测试对象质量评价测试对象的整体质量：B（A：质量稳定，适合大规模使用。B：存在少数非严重问题，但有规避措施，可以局部使 用。C：基本功能可用，但严重问题较多，不能发布。D：基本功能不可用）5测试过程评估5.1测试设计评估各模块每千行代码用例数统计如下，用例设计达到公司标准，比较充分：模块/特性千行代码用例数5.2测试执行评估5.2.1测试执行统计数据版本名称工作量投入（人天）测试用例规模用例执行陷数代码规模总用例数 新增用例数手工执行行 移植代码行数非移植代码行数发现缺自动执5.2.2测试用例执行结果统计数据表1测试结果统计表统计总测试用例数实际测试的用例数OK 项项NG项NT项无需测试用例数测试用例百分比附件附件1：遗留问题报告遗留问题统计表2遗留问题统计表问题总数致命问题严重问题一般问题题其他统计项数目100100百分比00100%00POK提示问附件2：交付的测试工作产品1. 测试计划2. 测试策略3. 测试方案4. 测试用例5. 测试规程6. 测试问题报告7. 测试报告8. 测试输入及输出数据9. 测试工具10. 测试代码及设计文档参考资料清单：六1. 测试人员提交新的Bug入库，错误状态为New。2. 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。 如果不是错误，则拒绝，设置为Declined（拒绝）状态。3. 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug 则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于 不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通 过才能认可。4. 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态Closed，如没有解决置状态为Reopen十首先，开发人员和测试人员肯定都是以客户需求为主，开发不会不按照需求去开发系统，发 生冲突，多数情况下是因为开发人员和测试人员对系统需求的理解不同，开发说应该是这样 的，测试说应该是那样的，到底是怎样的，开发和测试都应该回头审理自己对系统需求的理 解是否是正确的。作为测试人员，当发现开发做出来的东西与需求不一致时，首先不要去否 定人家的工作，未必你的理解就是正确的。其次，若经过再次审理自己对系统的需求理解之 后，都还坚持自己的意见，那就没必要和开发继续讨论了，应该找第三方来给出答案，比如 项目经理。第三，有很多时候，开发都不是不去修改你提出的缺陷，而是他是根据自己的工 作轻重缓急程度来安排自己的工作，可能有很多只是建议或意见性的缺陷，开发可能不会 去修改，你也不要非得要人家按照你的建议去修改一些不重要的问题，毕竟开发和测试人员 都首先是公司的一员，都应该首先从公司的角度出发去考虑问题，作为测试人员，你也知道 修改任何一个缺陷都是有风险的，缺陷的修改成本以及测试成本，不光是公司领导去考虑 的，开发和测试人员也应该去考虑。十一这个问题要从三个方面来考虑：一是从领导本身来考虑，领导和手下发生矛盾，作为领导首 先要顾全大局，首先从自身上找原因，要坚持公平公正，不能因为和手下发生矛盾就打击报 复，要彻底分清矛盾产生的原因，自己不对的地方要及时改正并向员工道歉，员工不对的地 方要及时指出；如果员工坚持自己的意见不改正，影响到工作的话，可以向上级提出调整的 意见，要么是自己调动，要么是员工调整。二是从员工本身来考虑，思路和领导差不多，这 里要突出强调员工要注意方式方法，要尊重领导意见，要擅于指出领导的不足，违备原则的， 坚决予以反对，领导一意孤行的，可以向上级反映。三是从两者共同的上级领导的身份来考 虑，要以居中人的身份，不能偏袒任何一方，公平公正处理矛盾；要坚持从工作出发的精神， 正确判断矛盾是非，不能因人而异，坚持实事求是；要坚持团结的原则，协调好两人的矛盾， 尽量争取最大的团结；对于实在不能调合的矛盾，可以将两人分开，避免更多的工作磨擦和 误会。作为领导者在处理上下级间矛盾时，要分析矛盾的要害点是否影响公司的利益和团队的利 益以及是否与公司的规章制度相冲突，然后主动找到员工谈话，就矛盾的要点说明各自的力场， 以及各自的责任和义务，在坦诚与不卑不亢中让员工说出自己的需求，在领导职权范围内予 以最大帮助.作为员工，要明白”物竞天择，适者生存”的道理，要明白每个领导作出的决定时通常 是不需要向每个下属去解释的，做为下属如果不能站在领导的角度上去考虑问题，局面就会 变得很不乐观.员工更多应该作的是去适应每位领导不同的作事风格，尽自己所能发挥自己 所长，条条大路通罗马，不必计较一时的意见不统一.但如果员工可以看出领导的所作所为 是有损公司和团队利益或者是违犯公司规章制度的.可以私下找领导单独沟通，阐明其中原 因及自己的难处.如果领导违犯公平公正原则凡事有所针对的情况时，可以在即不违犯公司 规章制度又不损害公司及团队利益的前堤下，向更上级管理层反映情况，必要时可以提出调 整工作岗位.个人拙见，希望能够给你一点参考十六从纯技术的角度讲，任何软件都会有性能方面的问题，但实际上并不是每一个软件都要做性 能测试。软件的性能和性能测试伴随着网络应用的兴起而逐渐被重视起来，但是软件性能和性能 测试却并非网络应用的专属名词，单机版的软件应用同样需要考虑性能问题。先请看以下的案例：1杀毒软件每次都要花费两个小时以上才能完成一次对所有的分区的扫描。2 PolySpace （代码分析软件）分析一个项目（10K LOC），都要花费八个小时以上。以上两款软件都没有做过性能测试，但客户一般不会抱怨软件性能有问题，可能只会抱 怨自己的机器落伍了。3北京奥运会第二阶段门票销售开始第一天，其订票系统一度瘫痪。以上的软件做了性能测试，但用户对订票系统的抱怨声还是造成了很坏的影响。具体来说，如何判断是否需要做性能测试，有以下几个准则。x对于单机版软件来说，要完全站在用户的角度，准确的把握用户需求我们要明白，用户有时候并不会过多的关注软件的实时性。以“我”这个用户为例，在使用杀毒软件之前，我的期望是杀毒软件能尽可能多的查杀病 毒，至于查杀病毒要两个小时还是三个小时，我不会过多关注，因为查杀病毒时，我可能在 吃饭或者休息。同样，“我”在使用PolySpace之前，我已经知道它的分析原理就是做“穷尽”的计算，所 以才能找到代码中的Run-time error （运行时错误），具体它用了八个小时还是十个小时， 我也不会太关心，因为它的分析工作是在机房的服务器上，分析时间都在下班以后。只要第 二天上班我能看到结果就行。当在使用Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，如果每次 都要两三分钟才能看到结果，“我”就会觉得性能比较差，因为我需要眼睁睁的看着它，等着 它的结果出来后才能进行下一步操作。所以说，需不需要对单机版软件做性能测试，取决于对用户需求的深层次理解。一般情 况下，大数据量、交互性强的应用，在性能测试方面要多关注。而对于客户端/服务器系统，性能测试则是必需的。x对于客户端数量相对固定的情况下，如传统的C/S系统，如果客户端数量不大，性 能测试要相对简单一些，一般采用传统的人工“喊号子”的方法即可完成。而如果客户端数量 比较大，要借助于工具完成，自研的专门工具还是专业的性能测试工具都可以协助完成性能 测试。x对于客户端数量无法预测的情况下，如当前最流行的B/S系统，你可能无法预测到 底会有多少人并发访问你的网站，于是性能测试变得至关重要，性能成为产品能否成功的关 键因素之一。如MSN在国内一直打不过QQ，个人以为MSN的性能不稳定是重要的一个原 因。要在这种情况下做性能测试，或者说压力测试，一般要借助于专业的工具，如LoadRunner 才能完成。十七功能测试在开发完成编码提交测试后进行，性能测试则是在功能基本稳定，没什么严重问题 的时候开始执行。当然，环境搭建，场景设计还是要在前期就准备好的如何理解SQA的日常工作内容SQA的工作范围和职责SQA的工作范围和职责，不同国家、不同公司的差别还是比较大的。主要分为：过程QA、产品QA， 这俩类的具体做法也差别很大。过程QA： 一般公司的定位是过程和方法推广、过程审计、过程数据收集和分析、过程改进，有些公 司分得更细致，过程QA只是做过程审计，不关心改进工作，另外设立了过程改进工程师。产品QA： 一把公司的定位主要是做软件系统测试，验证产品需求和发现产品缺陷为目的，确保在产 品发布到客户前产品符合客户提出的需求，质量达到可发布的标准。这里重点说说过程SQA的主要工作范围和职责：1) 熟悉和了解项目和产品特征，理解和指导项目进行过程定义；2) 熟悉和了解企业标准和公司标准，并指导项目按照标准实施项目活动；3) 跟踪项目进展，了解项目偏差情况，包括进度、质量、范围、问题和风险等，并及时向项目 经理发出预警；4) 根据项目计划制定项目审计计划，并按照计划实施审计，其中包括过程审计和部分产品审计；5) 针对审计的不符合项督促制定预防纠正措施，并跟踪关闭；6) 制定项目数据收集和度量计划，并按计划实施数据收集、分析和报告；7) 负责制定和实施组织级的内外部审计，以发现偏差和改进方向，为后续改进规划做准备。3 SQA的工作方式职责很清楚，但操作起来却有些困难。作为监管部门，难免在实施中会有很多阻碍。这里面首先我们 自己要理清楚思路，以下这几点就是两个核心思想：知己知彼（1和2）、胡萝卜（3）加大棒（4、5）的 策略：1）项目和产品运作模式的理解对于自己要服务和监管的项目或产品，如果自己是外行，完全不懂，那么你怎么能够理解项目的语言，知道项目需要什么过程、适合什么管理模式呢？接手一个项目，最初始的工作内容就是项目和产品的学习。作为SQA不需要了解到代码级，但是需要懂得产品需求、产品系统架构、主要的设计方案和测试方案，只有这样才能与项目组有着共同语言，给出的建议或意见才更有发言权。2）对项目进展的了解度知道了产品干什么的，项目的计划和范围，接下来的是项目进展跟踪。很多SQA不太跟进项目，待审核时则拿着检查单，凭借检查单的条目机械的去寻找证据。检查单帮助我们关注到该关注的点，不至于遗漏。但是检查单无法帮助我们理解项目组为什么这样做，是否合理。只有跟进了项目，知道项目如何在开展，你才能很快了解到检查项缺陷是项目组未有效开展还是标准本身需要调整。由于不属于项目组的直接成员，很多信息只能间接获取。我们推荐的一些方式包括：日常沟通、 参加项目例会、参加项目方案讨论或评审、参加里程碑会议、查阅项目文档、查看项目数据、了解项 目问题或风险解决情况等等，通过这些活动以方便要使得项目组认为SQA是项目组成员之一，同时 也能获得很多的项目信息，便于判断当前项目需要的支持或者改进。关于参加项目活动，有一个现象是：项目组通常不会主动的通知SQA去参加，导致SQA不能及 时参与项目活动获得相关信息。我们通常是与项目组项目经理协商，确定哪些活动是SQA必须参加 的，并由项目经理通知到SQA。同时，也要求SQA主动关注项目的日常活动，自行选择参加。3）给以项目的咨询和支持度这点上其实是对SQA本身有很高的要求，如果自己对过程理解不到位，对产品和项目特点不清楚，对项目的组织结构和管理模式不熟悉，那么虽然有检查单帮助发现问题，但却不一定能给出合适的解决方案。这点不容易做到，也是项目人员最为关心和最易抱怨的。SQA除了以上的两点自身充实外，需要学习业界的很多专业知识，包括软件工程、度量、质量知识、组织标准和模板等，至少在过程领域是需要能发出权威的声音，获得项目的认可，在项目需要时能够给以必要的支持和引导。这其中包括：给以标准、制度和模板的使用指导，定期观察项目情况并及时提醒，定期出具项目质量数据给项目组做参考，协助项目经理分析项目问题等等，这些活动会让项目组真正体会到SQA的价值所作。4）畅通的汇报机制历来任何事情要有效推动都需要有胡萝卜加大棒，对于质量工作也是一样。光给以支持、引导和帮助，但是没有有效的惩罚措施，说什么也是白搭。遇到能力水平较高的项目团队，可能工作较好开展，但若遇到认识不到位的项目团队，此时光依靠单方面的引导而不给以压力，工作会在很长时间内不会有成效。虽然，我们说工作要做到人心，首先理解到位了再说操作的问题，但是实践中很多事情往往是先推动和落实，在此过程中不断加深理解。这种体验很多很多，也往往产生了良性的结果，因此是值得的。因此，在制度上需要给以保障，包括考核机制和汇报机制。说到汇报机制，这个度往往是SQA比较犯难的。什么情况下需要汇报给QA经理、产品总经理或 高层？对审计发现问题的处理，我们的原则是：一般的不符合项，首先由QA与项目成员或项目经理 协商制定改善措施，之后由项目组实施、QA跟踪关闭；以下情况SQA需要汇报给产品总经理及其 QA经理：1是当项目组在计划时间内没有落实相关措施，且无任何合理的解释时；2是项目组有合理理由，但未在合理的期限内解决时；3是项目发生的问题或不符合程度比较严重时。此时QA经理需 要与产品总经理沟通协商确定改进措施，并指派项目经理或专人进行处理；若仍然没有成效时，QA 经理负责向公司高层汇报，以便督促相应工作的落实。5）对公司考核制度的把握公司制度体现了公司的业务方向和关注重点。对于软件产品而言，SQA的发现是保障产品质量、 进度和成本的关键环节之一，需要作为KPI之一纳入考核体系。只有有了考核指标的要求，并逐步分 解为可落实的措施上，才能有效开展工作。说到考核，有一点是需要关注的：在考核设计中对SQA 工作成果的应用要关注最终结果而不是过程，最为简单的例子是，日常审核的结果不能作为考核内容， 而半年或一年的定期审核，可以专门用于考核，以便于评估考核周期内项目的质量状况和改进情况。4 SQA的审计方式和重点QA的审计其实是有方法的，而不是简单机械的使用检查单去审核。我们尤其反对那种日常不参与项 目活动，只在审核时才出现的方式。然而到底要怎么审计效果才更好呢？1）检查单的使用使用检查单做审计是一种非常好的方式，检查单帮我们总结了需要审计的范围和关注点，好的检查 单甚至也积累了很多人对某过程的深刻理解，对于知识传承、培养新人起着很重要的作用。同时，也 是检查结果的一个客观反映，杜绝了太多的人为干扰。因此，我们要求所有组织标准和过程都要有检 查单相对应，以便QA能够有效开展工作。但是，检查单本身的质量、使用检查单人的能力对于最终应用结果起着重要的影响。因此，我们重 视检查单但不能依赖检查单，我们强调对各检查单条款的具体理解，并在检查中需要融会贯通。2）证据和访谈的使用SQA审计中很关注证据和访谈的作用，尤其是直接证据。由于在直接证据中能够很轻易的获取到 项目实施情况的数据，从一定程度上客观反映了情况，也避免了与人交流的复杂性，尤其是对不喜欢 与项目沟通的QA。有好处也有坏处，既然是看证据，项目团队也存在为了审核而造证据的现象，无 法真实反映项目能力水平。因此，审核要采取多种方法，包括看证据、访谈合适的人员，同时结合日常对项目的了解给出判断。 若有了日常的了解，基本上我们能够看出来证据的有效性和项目的实际情况，并能够给出合适的审核 结果。3）规范性和有效性问题审核要关注的两个方面，1是规范性，2是有效性。规范性比较容易检查，通过检查单、证据和访 谈都可以获取到，更多看到的执行结果。而有效性要求更高，不仅仅关注做到没有，而且关注怎么做， 为什么这么做的问题。这里就需要SQA有着较高的素质才能做好。有两点我们发现SQA经常遗漏， 但实际上却对审核有效性很重要：1是检查需求的可追溯性，2是检查计划执行状况。任何过程的检 查前，我们需要先了解项目初始计划、当前计划和当前状况，以便确定项目当前应该做到什么，没有 做到什么；当检查项目的工程过程时，无论是设计、开发还是测试过程，都需要关注需求的可追溯性， 抽查几条需求，检查是否在相应的设计开发和测试环节中都考虑到，这是很关键的，只有这样才能看 出项目团队是否是为了文档而写文档，而是真正考虑了项目的需求。4）检查计划和检查结果SQA在项目启动后就应该制定项目审核计划，审核计划应该与项目立项时的计划相匹配。当项目 计划调整时，QA审核计划需要相应的进行调整，以便能够跟上项目的节奏，起到及时预警的作用。每次审计的结果，对于符合项和不符合项都需要进行确认，包括项目团队的确认和QA经理的评 审，尤其是针对新QA的工作成果更需要评审和确认的过程。很多QA经理一忙就难以保证这点，实 际上是工作质量的缺失。当任务紧、资源少、需求多的情况下如何保证软件质量常常会遇到时间紧张，任务重的项目，在这种情况下，如何保证测试质量，我这里抛砖引玉，希望大家 来提出自己的高见：1, 项目成员明确需求，需求按优先级排序，评审之后少做变更需求是源头，PD，开发，测试前期评审把好关，越早发现问题，越容易解决，花费的代价越小。要做 到需求按优先级排序，把需求分解成具体的最小级别的功能点，先实现高优先级的需求。三方评审通过后， 项目中冻结需求，尽量少做变更。2, 制定合理的测试计划，明确里程牌时间和负责人测试计划是指导测试行动的总纲领，规划好测试设计，用例编写，测试执行的时间，测试负责人每天 关注进展，及时调配资源，将问题解决在萌芽状态。3, 保证测试设计和用例的质量资深的测试工程师负责测试设计；按测试组成员能力水平分配任务，完成用例设计。完成之后，进行 测试组和项目组的评审，查漏补缺。4, 提高测试介入的标准时间紧张，需要开发保证代码质量，测试介入的标准肯定是必须通过冒烟测试。冒烟用例评审时一定 找开发确认，开发自己先执行成功冒烟用例，保证测试介入后能顺利走下面的流程。5. 迭代测试开发迭代提交模块，测试针对性进行测试。迭代测试增加了测试时间但是并没有延误整个的时间进度， 因为在每一个迭代过程中测试过程都是提前开始的。6.每天召开晨会，沟通项目进度，解决问题介入测试时，开发，测试，PM等团队成员每天花半小时召开晨会，沟通各自的进展，列出项目中的 问题，确认解决人和解决时间。问题及时解决，会加深团队伙伴的信任，激发工作热情。当然，测试工作最终还是基于代码质量的，当我们发现低估了项目复杂度的时候，增加测试时间才是 明确的选择。欲速则不达，着急冒进，项目的质量很难得到保障，压缩的时间迟早会补偿回去。与项目经理发生冲突时，如何有效沟通