- 1、本文档共10页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
手机测z试面试
5. 正交表分析法
有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。
6. 场景分析方法
指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。
问题七:您认为做好测试用例设计工作的关键是什么?
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题
问题八:详细的描述一个测试活动完整的过程。
1. 项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法 实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。然后SQA进入项目,开始进行统计和跟踪
2. 开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。
3. 测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
4. 测试用例完成后,测试和开发需要进行评审。
5. 测试人员搭建环境
6. 开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现BUG后提交给BugZilla。
7. 开发提交第二个版本,包括Bug Fix以及增加了部分功能,测试人员进行测试。
8. 重复上面的工作,一般是3-4个版本后BUG数量减少,达到出货的要求。
9. 如果有客户反馈的问题,需要测试人员协助重现以及回归测试。
问题九:以往是否曾经从事过性能测试工作?请尽可能的详细描述您以往的性能测试工作的完整过程。
曾经做过一套网管系统的性能测试,主要测试该软件在同时管理大量终端的情况下,在响应时间,CPU/磁盘/内存等参数是否满足要求。
也曾经做过软交换系统的呼叫性能测试,主要是测试软交换系统在有大量呼叫的情况下,响应时间,呼叫成功率,CPU/磁盘/内存等参数是否满足设计要求。?
问题十:您在从事性能测试工作时,是否使用过一些测试工具?如果有,请试述该工具的工作原理,并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
测试网管系统中,使用的Mimic来模拟终端,能够大量的节省成本。
测试软交换系统的时候,使用的Prolab来模拟终端并发送呼叫软交换,他完成了同时数百人才能完成的摘机拨号工作,主要工作原理是产生一些符合要求的IP包并发送给软交换系统,同时对软交换系统的回应进行处理,决定下一步动作。
问题十一:您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
主要是保障在大量用户的情况下,服务能正常使用。
问题十二:在您以往的工作中,一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
1. 在传统的BugZilla中,BUG描述应该包括以下的信息
2. 和BUG产生对应的软件版本
3. 开发的接口人员
4. BUG的优先级
5. BUG的严重程度
6. BUG可能属于的模块,如果不能确认,可以用开发人员来判断
7. BUG标题,需要清晰的描述现象
8. BUG描述,需要尽量给出重新Bug的步骤
9. BUG附件中能给出相关的日志和截图。
高质量的BUG记录就是指很容易理解的BUG记录,所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位。
问题十二:BUG管理工具的跟踪过程
用BugZilla为例子?
测试人员发现了BUG,提交到Bugzilla中,状态为new,BUG的接受者为开发接口人员
开发接口将BUG分配给相关的模块的开发人员,状态修改为已分配
开发人员和测试确认BUG,如果是本人的BUG,则设置为接收;如果是别的开发人员的问题,则转发出去,由下一个开发人员来进行此行为;如果认为不是问题,则需要大家讨论并确认后,拒绝这个BUG,然后测试人员关闭此问题。
如果开发人员接受了BUG,并修改好以后,将BUG状态修改为已修复,并告知测试在哪个
文档评论(0)