阿里巴巴测试题目Word格式文档下载.docx

阿里巴巴测试题目Word格式文档下载.docx

《阿里巴巴测试题目Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《阿里巴巴测试题目Word格式文档下载.docx（12页珍藏版）》请在冰豆网上搜索。

2　把不能识别的对象设置为虚拟对象（VirtualObject）

　　依次点击QTP的“Tools”--->

"

VirtualObjects"

--->

"

NewVirtualObject..."

，就会出现VirtualObjectWizard对话框，你根据Wizard 

的指引，就可以把添加一些支持的不好的控件设置成虚拟控件，也就添加到对象库了。

CODE:

[Copytoclipboard] 

在QTP8.2添加虚拟对象的具体操作步骤是：

1， 

依次点击Tools--->

VirtualObjects--->

NewVirtualObject…，打开虚拟对象向导，点击Next；

2， 

选择Class为button，点击Next；

3， 

点击标记对象按钮；

4， 

选择要操作的对象区域，点击Next（对象区域就是你要操作的那个对象，就是login按钮）；

5， 

默认，点击Next；

6， 

完成。

3　针对特殊问题有特殊的解决方法。

如果不能识别的控件是用VC做的，那么你可以自己写一个动态链接库，然后让QTP去调用它。

至于QTP如何调用动态链接库，请看附件。

五．给你一个测试报告模板作为参考：

×

系统测试报告

拟制:

日期：

yyyy-mm-dd

审核:

修订记录

日期 

　　　　　修订版本 

描述 

作者

2004-12-08 

1.00 

初稿完成 

×

目 

录

1概述 

2测试时间、地点及人员 

3环境描述 

4测试对象质量评估 

　4.1覆盖率统计 

　4.2测试对象质量评价 

5测试过程评估 

　5.1测试设计评估 

　5.2测试执行评估 

　　5.2.1测试执行统计数据 

　　5.2.2测试用例执行结果统计数据 

附件 

附件1：

遗留问题报告 

遗留问题统计 

附件2：

交付的测试工作产品 

测试报告

关键词：

摘 

要：

本文是×

系统测试报告，对×

的测试用例设计、测试执行、各特性质量进行总结

缩略语清单：

对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中文解释。

1概述

2测试时间、地点及人员

版本名称 

　　　　　　测试时间 

　　　　　测试人员 

　　　测试地点起始时间 

结束时间 

3环境描述

PC机一台，配置不同Windows操作系统＋VC6。

4测试对象质量评估

4.1覆盖率统计

本次测试对以下需求进行了覆盖，所执行的用例对需求覆盖情况如下：

需求ID 

需求名称 

对应用例

4.2测试对象质量评价

测试对象的整体质量：

B

（A：

质量稳定，适合大规模使用。

B：

存在少数非严重问题，但有规避措施，可以局部使用。

C：

基本功能可用，但严重问题较多，不能发布。

D：

基本功能不可用）

5测试过程评估

5.1测试设计评估

各模块每千行代码用例数统计如下，用例设计达到公司标准，比较充分：

模块/特性 

　千行代码用例数

5.2测试执行评估

5.2.1测试执行统计数据

工作量投入（人天） 

测试用例规模 

用例执行 

发现缺陷数 

代码规模　总用例数 

新增用例数 

手工执行 

自动执行 

移植代码行数 

非移植代码行数

5.2.2测试用例执行结果统计数据

表1测试结果统计表

统计 

总测试用例数 

实际测试的用例数 

OK项 

POK项 

NG项 

NT项 

无需测试用例数

测试用例 

百分比 

附件

遗留问题报告

遗留问题统计

表2遗留问题统计表

问题总数 

致命问题 

严重问题 

一般问题 

提示问题 

其他统计项

数目 

1 

0 

0

100% 

交付的测试工作产品

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（代码分析软件）分析一个项目（10KLOC），都要花费八个小时以上。

　　以上两款软件都没有做过性能测试，但客户一般不会抱怨软件性能有问题，可能只会抱怨自己的机器落伍了。

　　3 

北京奥运会第二阶段门票销售开始第一天，其订票系统一度瘫痪。

　　以上的软件做了性能测试，但用户对订票系统的抱怨声还是造成了很坏的影响。

　　......

　　具体来说，如何判断是否需要做性能测试，有以下几个准则。

　　×

对于单机版软件来说，要完全站在用户的角度，准确的把握用户需求

　　我们要明白，用户有时候并不会过多的关注软件的实时性。

　　以“我”这个用户为例，在使用杀毒软件之前，我的期望是杀毒软件能尽可能多的查杀病毒，至于查杀病毒要两个小时还是三个小时，我不会过多关注，因为查杀病毒时，我可能在吃饭或者休息。

　　同样，“我”在使用PolySpace之前，我已经知道它的分析原理就是做“穷尽”的计算，所以才能找到代码中的Run-timeerror（运行时错误），具体它用了八个小时还是十个小时，我也不会太关心，因为它的分析工作是在机房的服务器上，分析时间都在下班以后。

只要第二天上班我能看到结果就行。

　　当在使用Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，如果每次都要两三分钟才能看到结果，“我”就会觉得性能比较差，因为我需要眼睁睁的看着它，等着它的结果出来后才能进行下一步操作。

　　所以说，需不需要对单机版软件做性能测试，取决于对用户需求的深层次理解。

一般情况下，大数据量、交互性强的应用，在性能测试方面要多关注。

　　而对于客户端/服务器系统，性能测试则是必需的。

对于客户端数量相对固定的情况下，如传统的C/S系统，如果客户端数量不大，性能测试要相对简单一些，一般采用传统的人工“喊号子”的方法即可完成。

而如果客户端数量比较大，要借助于工具完成，自研的专门工具还是专业的性能测试工具都可以协助完成性能测试。

对于客户端数量无法预测的情况下，如当前最流行的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）的策略：

项目和产品运作模式的理解

对于自己要服务和监管的项目或产品，如果自己是外行，完全不懂，那么你怎么能够理解项目的语言，知道项目需要什么过程、适合什么管理模式呢？

接手一个项目，最初始的工作内容就是项目和产品的学习。

作为SQA不需要了解到代码级，但是需要懂得产品需求、产品系统架构、主要的设计方案和测试方案，只有这样才能与项目组有着共同语言，给出的建议或意见才更有发言权。

对项目进展的了解度

知道了产品干什么的，项目的计划和范围，接下来的是项目进展跟踪。

很多SQA不太跟进项目，待审核时则拿着检查单，凭借检查单的条目机械的去寻找证据。

检查单帮助我们关注到该关注的点，不至于遗漏。

但是检查单无法帮助我们理解项目组为什么这样做，是否合理。

只有跟进了项目，知道项目如何在开展，你才能很快了解到检查项缺陷是项目组未有效开展还是标准本身需要调整。

由于不属于项目组的直接成员，很多信息只能间接获取。

我们推荐的一些方式包括：

日常沟通、参加项目例会、参加项目方案讨论或评审、参加里程碑会议、查阅项目文档、查看项目数据、了解项目问题或风险解决情况等等，通过这些活动以方便要使得项目组认为SQA是项目组成员之一，同时也能获得很多的项目信息，便于判断当前项目需要的支持或者改进。

关于参加项目活动，有一个现象是：

项目组通常不会主动的通知SQA去参加，导致SQA不能及时参与项目活动获得相关信息。

我们通常是与项目组项目经理协商，确定哪些活动是SQA必须参加的，并由项目经理通知到SQA。

同时，也要求SQA主动关注项目的日常活动，自行选择参加。

给以项目的咨询和支持度

这点上其实是对SQA本身有很高的要求，如果自己对过程理解不到位，对产品和项目特点不清楚，对项目的组织结构和管理模式不熟悉，那么虽然有检查单帮助发现问题，但却不一定能给出合适的解决方案。

这点不容易做到，也是项目人员最为关心和最易抱怨的。

SQA除了以上的两点自身充实外，需要学习业界的很多专业知识，包括软件工程、度量、质量知识、组织标准和模板等，至少在过程领域是需要能发出权威的声音，获得项目的认可，在项目需要时能够给以必要的支持和引导。

这其中包括：

给以标准、制度和模板的使用指导，定期观察项目情况并及时提醒，定期出具项目质量数据给项目组做参考，协助项目经理分析项目问题等等，这些活动会让项目组真正体会到SQA的价值所作。

畅通的汇报机制

历来任何事情要有效推动都需要有胡萝卜加大棒，对于质量工作也是一样。

光给以支持、引导和帮助，但是没有有效的惩罚措施，说什么也是白搭。

遇到能力水平较高的项目团队，可能工作较好开展，但若遇到认识不到位的项目团队，此时光依靠单方面的引导而不给以压力，工作会在很长时间内不会有成效。

虽然，我们说工作要做到人心，首先理解到位了再说操作的问题，但是实践中很多事情往往是先推动和落实，在此过程中不断加深理解。

这种体验很多很多，也往往产生了良性的结果，因此是值得的。

因此，在制度上需要给以保障，包括考核机制和汇报机制。

说到汇报机制，这个度往往是SQA比较犯难的。

什么情况下需要汇报给QA经理、产品总经理或高层？

对审计发现问题的处理，我们的原则是：

一般的不符合项，首先由QA与项目成员或项目经理协商制定改善措施，之后由项目组实施、QA跟踪关闭；

以下情况SQA需要汇报给产品总经理及其QA经理：

1是当项目组在计划时间内没有落实相关措施，且无任何合理的解释时；

2是项目组有合理理由，但未在合理的期限内解决时；

3是项目发生的问题或不符合程度比较严重时。

此时QA经理需要与产品总经理沟通协商确定改进措施，并指派项目经理或专人进行处理；

若仍然没有成效时，QA经理负责向公司高层汇报，以便督促相应工作的落实。

对公司考核制度的把握

公司制度体现了公司的业务方向和关注重点。

对于软件产品而言，SQA的发现是保障产品质量、进度和成本的关键环节之一，需要作为KPI之一纳入考核体系。

只有有了考核指标的要求，并逐步分解为可落实的措施上，才能有效开展工作。

说到考核，有一点是需要关注的：

在考核设计中对SQA工作成果的应用要关注最终结果而不是过程，最为简单的例子是，日常审核的结果不能作为考核内容，而半年或一年的定期审核，可以专门用于考核，以便于评估考核周期内项目的质量状况和改进情况。

4 

SQA的审计方式和重点

QA的审计其实是有方法的，而不是简单机械的使用检查单去审核。

我们尤其反对那种日常不参与项目活动，只在审核时才出现的方式。

然而到底要怎么审计效果才更好呢？

检查单的使用

使用检查单做审计是一种非常好的方式，检查单帮我们总结了需要审计的范围和关注点，好的检查单甚至也积累了很多人对某过程的深刻理解，对于知识传承、培养新人起着很重要的作用。

同时，也是检查结果的一个客观反映，杜绝了太多的人为干扰。

因此，我们要求所有组织标准和过程都要有检查单相对应，以便QA能够有效开展工作。

但是，检查单本身的质量、使用检查单人的能力对于最终应用结果起着重要的影响。

因此，我们重视检查单但不能依赖检查单，我们强调对各检查单条款的具体理解，并在检查中需要融会贯通。

证据和访谈的使用

SQA审计中很关注证据和访谈的作用，尤其是直接证据。

由于在直接证据中能够很轻易的获取到项目实施情况的数据，从一定程度上客观反映了情况，也避免了与人交流的复杂性，尤其是对不喜欢与项目沟通的QA。

有好处也有坏处，既然是看证据，项目团队也存在为了审核而造证据的现象，无法真实反映项目能力水平。

因此，审核要采取多种方法，包括看证据、访谈合适的人员，同时结合日常对项目的了解给出判断。

若有了日常的了解，基本上我们能够看出来证据的有效性和项目的实际情况，并能够给出合适的审核结果。

规范性和有效性问题

审核要关注的两个方面，1是规范性，2是有效性。

规范性比较容易检查，通过检查单、证据和访谈都可以获取到，更多看到的执行结果。

而有效性要求更高，不仅仅关注做到没有，而且关注怎么做，为什么这么做的问题。

这里就需要SQA有着较高的素质才能做好。

有两点我们发现SQA经常遗漏，但实际上却对审核有效性很重要：

1是检查需求的可追溯性，2是检查计划执行状况。

任何过程的检查前，我们需要先了解项目初始计划、当前计划和当前状况，以便确定项目当前应该做到什么，没有做到什么；

当检查项目的工程过程时，无论是设计、开发还是测试过程，都需要关注需求的可追溯性，抽查几条需求，检查是否在相应的设计开发和测试环节中都考虑到，这是很关键的，只有这样才能看出项目团队是否是为了文档而写文档，而是真正考虑了项目的需求。

检查计划和检查结果

SQA在项目启动后就应该制定项目审核计划，审核计划应该与项目立项时的计划相匹配。

当项目计划调整时，QA审核计划需要相应的进行调整，以便能够跟上项目的节奏，起到及时预警的作用。

每次审计的结果，对于符合