网站的后缀5188关键词平台
（一）您认为做好测试用例设计工作的关键是什么？
（二）您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
（三）我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
参考答案：1、检查系统是否有中毒的特征；2、检查软件/硬件的配置是否符合软件的推荐标准；3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
（四）什么是并发？在lordrunner中，如何进行并发的测试？集合点失败了会怎么样？
（五）写出bug报告当中一些必备的内容。
（六）简述一下缺陷的生命周期？
（七）、判断题（每题2分,正确的“√”，错误的“╳”）
（1）发现错误是软件测试的目的（）
（2）白盒测试可以找出软件遗漏功能和代码错误功能。（）
（3）在设计测试用例时，应包括合理的应用条件和不合理的应用条件。 （）
（4）软件缺陷一定是由编码引起的错误。 （）
（5）文档测试是对系统提交给用户的文档进行验证，并不是一般性的审查活动。（）
（八）如何编写提交给用户的测试报告？
（九）你最擅长什么？
（十）测试产品与测试项目的区别是什么？
参考答案：习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件，例如Windows2000。而通常把针对一个或者几个特定的用户而开发的软件成为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：-质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。-测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。-项目最后要和用户共同验收测试，这是产品测试不具有的特点。此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作。
（十一）没有产品说明书和需求文档地情况下能够进行黑盒测试吗？
参考答案：这个问题是国内测试工程师经常遇到的问题，根源就是国内软件开发文档管理不规范，对变更的管理方法就更不合理了。实际上没有任何文档的时候，测试人员是能够进行黑盒测试的，这种测试方式我们可以称之为探索测试，具体做法就是测试工程师根据自己的专业技能、领域知识等不断的深入了解测试对象、理解软件功能，进而发现缺陷。在这种做法基本上把软件当成了产品说明书，测试过程中要和开发人员不断的进行交流。尤其在作项目的时候，进度压力比较大，可以作为加急测试方案。最大的风险是不知道有些特性是否被遗漏。
（十二）在测试一个web页面时，页面显示为空白页，如何定位问题所在？可能是哪些原因引起的？
（十三）软件的评审一般由哪些人参加？其目的是什么？
（十四）描述测试用例设计的完整过程？
(十五 ）有个产品相当于大家下载软件的应用商店这样，做了一个策略，要求省内省外下载的软件包不是一个渠道包。渠道包大家应该知道吧。就是后台有两个下载地址，一个是省外下载地址，一个是省内下载地址。当用户是省内IP，则使用省内地址，当用户是省外IP时，使用省外地址。如果是这个功能大家会怎么测试呢，首先你就要搭建测试环境，编写测试用例等等，留言告诉小编你如何搭建测试环境，功能点需要怎么考虑那些。
（十六）面试官问用安卓系统和ios系统进行软件测试，会有哪些不同？
（十七）LoadRunner分哪三部分？
（十八）数据库内联接和外连接，自联接有什么区别？
（十八）测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
测试计划一般是由有经验的公司老人，组长经理来写，也称工作计划，主要是根据测试范围列表划分功能优先级，分配测试人员的工作量，对于风险的评估其中像需求的变更，人员的变动，技术业务的成熟度，测试的总体周期，测试的标准是什么样的。最重要的就是测试的标准，周期，每人每责
（十九）当开发人员说不是BUG时，你如何应付？
参考答案：开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
（二十）如果一个bug只出现一次，该怎么处理？
参考答案：（1）bug出现的同时立即截图留下异常的画面（2）使用相同的环境、设备、测试步骤、方法，使用相同的输入数据，看能否重 （3）不能重现，则告诉项目经理发现bug的过程，分析优先级，讨论解决方案
（二十一）软件测试的缺陷等级如何划分？
参考答案：
A类—严重错误，包括以下各种错误：
1． 由于程序所引起的死机,非法退出
2． 死循环
3． 数据库发生死锁
4． 因错误操作导致的程序中断
5． 与数据库连接错误
6． 数据通讯错误
B类—较严重错误，包括以下各种错误：
1.程序接口错误
2.系统可被执行，但操作功能无法执行（含指令）
3.单项操作功能可被执行，但在此功能中某些小功能（含指令参数的使用）无法被执行（对系统非致命的）
4.在小功能项的某些项目（选项）使用无效（对系统非致命的）
5.业务流程不正确
6.功能实现不完整，如删除时没有考虑数据关联
7.功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现；
8.报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误）
C类—一般性错误，包括以下各种错误：
1.操作界面错误（包括数据窗口内列名定义、含义是否一致）
2.打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误）
3.简单的输入限制未放在前台进行控制
4.删除操作未给出提示
5.已被捕捉的系统崩溃，不影响继续操作
6.虽然正确性不受影响，但系统性能和响应时间受到影响
7.不能定位焦点或定位有误，影响功能实现
8.显示不正确但输出正确
9.增删改功能，在本界面不能实现，但在另一界面可以补充实现。
D类—较小错误，包括以下各种错误：
1.界面不规范
2.辅助说明描述不清楚
3.输入输出不规范
4.长时间操作未给用户提示
5.提示窗口文字未采用行业术语
6.可输入区域和只读区域没有明显的区分标志
7.必填项与非必填项应加以区别
8.滚动条无效
9.键盘支持不好，如在可输入多行的字段中，不支持回车换行；或对相同字段，在不同界面支持不同的快捷方式
10.界面不能及时刷新，影响功能实现
E类—其他错误
1.光标跳转设置不好，鼠标（光标）定位错误
2.一些建议性问题
（二十三）http有哪些请求方式，get和post请求有什么区别
参看答案：
get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用"?"连接，多个请求数据间用"&"连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的；post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；
Get传输的数据量小，因为受URL长度限制，但效率较高，Post可以传输大量数据，所以上传文件时只能用Post方式；
post较get安全性较高，get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等.
get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码，post支持标准字符集，可以正确传递中文字符。
（二十四）http请求和http响应包含哪些内容
参考答案：
请求报文包含三部分：
a、请求行：包含请求方法、URI、HTTP版本信息
b、请求首部字段
c、请求内容实体
响应报文包含三部分：
a、状态行：包含HTTP版本、状态码、状态码的原因短语
b、响应首部字段
c、响应内容实体
（二十五）α测试，β测试定义?
α测试是软件开发公司组织内部人员，模拟各类用户，对即将上市的软件产品进行测试，试图发现错误并修复的过程。
β测试是由软件的多个用户在实际使用环境中进行的测试，这些用户返回有关错误信息给开发者。
（二十六）Socket编程了解么，应用在哪些地方
参考答案：
可以把 WebSocket 看成是 HTTP 协议为了支持长连接所打的一个大补丁。WebSocket是HTML5下一种新的协议。它实现了浏览器与服务器全双工通信。最大不同是：
WebSocket是一种双向通信协议。在建立连接后，WebSocket服务器端和客户端都能主动向对方发送或接收数据，就像Socket一样；
WebSocket需要像TCP一样，先建立连接，连接成功后才能相互通信
一个使用WebSocket应用于视频的业务思路如下：
使用心跳维护websocket链路，探测客户端端的网红/主播是否在线
设置负载均衡7层的proxy_read_timeout默认为60s
设置心跳为50s，即可长期保持Websocket不断开
（二十七）Tcp与udp区别？
TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接TCP提供可靠的服务。
TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
TCP首部开销20字节;UDP的首部开销小，只有8个字节
TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
（二十八）、接口测试用例的编写要点有哪些？
1、测试每个参数类型不合法的情况(类型不合法容易遗漏null型)
2、测试每个参数取值范围不合法的情况
3、测试参数为空的情况
4、测试参数前后台定义的一致性
5、 测试每个参数的上下限(这里容易出现致命的BUG，如果程序处理不当，可能会程序导致崩溃)
6、如果两个请求有严格的先后顺序，需要测试调转顺序的情况
（二十九）你所熟悉的软件测试类型有哪些?
参考答案：
测试类型有：功能测试、性能测试、界面测试
功能测试在测试工作中占有比例最大，功能测试也叫黑盒测试。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。
区别在于，功能测试关注产品的所有功能，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性。界面测试则关注与用户体验相关内容，用户使用该产品的时候是否已用，是否易懂，是否规范(用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告)。做某个性能测试的时候，首先它可能是个功能点，首先要保证她的功能是没有问题的，然后再考虑性能的问题。
（三十）说说你对集成测试中自顶向下集成和自底向上集成两个策略的理解，要谈出它们各自的优缺点和主要适应于哪种类型测试？
参考答案：
1、自顶向下集成
优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功
能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。
适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
2、自底向上集成
优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
（三十一）开发人员修复缺陷后，如何保证不影响其他功能
参考答案：
Bug的修复以及新功能的添加都有可能对版本造成一些影响，为了避免，在新版本发布以后，首先会对新版本做一个基础的流程测试也叫做冒烟测试，如果测试基本流程都顺利通过没有任何问题，那么测试人员可以继续进行详细的测试，否则就将冒烟测试中出现 的问题以及问题有可能出现的原因反馈给开发人员，由开发人员修正后再次发版，进行测试。这是一个迭代的过程。
（三十二）接口测试持续集成是如何进行的呢？
参考答案：
对接口测试而言，持续集成自动化是核心内容，通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化，主要应用于回归阶段，后续还需要加强自动化的程度，包括但不限于下面的内容：
1) 流程方面：在回归阶段加强接口异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程自动化。
2) 结果展示：更加丰富的结果展示、趋势分析等
3) 问题定位：报错信息、日志更精准，方便问题复现与定位。
4) 结果校验：加强自动化校验能力，如数据库信息校验。
5) 代码覆盖率：不断尝试由目前的黑盒向白盒下探，提高代码覆盖率。
6) 性能需求：完善性能测试体系，通过自动化的手段监控接口性能指标是否正常。
（三十三）接口响应的结果有那些？
1）对异常请求的处理
2）请求头的处理
3）存在业务关联的接口
4）涉及数据库交互的接口
5）结构不同
6）节点值有效性
7）列表结构排序
（三十四）正交表测试用例设计方法的特点是什么？
参考答案：
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂;
对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来;但是更深的缺陷，更复杂的缺陷，还是无能为力的;
具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
（三十五）说说你对软件配置管理的理解
参考答案：
项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制，配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大，配置管理就越显得重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并只有经过授权后才能变更这个标准。配置管理工具主要有CC，VSS,CVS,SVN等，我只用过SVN，对其他的工具不是很熟悉。
（三十六）软件测试分为几个阶段?
很多新手不知道软件测试人员要从什么时候进行测试，那些软件测试的阶段你必须知道，来看看吧。
和开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段：
单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。
集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。
系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。
验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。
单元测试测试策略：
自顶向下的单元测试策略：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。
自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长。
孤立单元测试策略：最好的单元测试策略。
集成测试的测试策略：
大爆炸集成：适应于一个维护型项目或被测试系统较小
自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。
自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。
基于进度的集成
优点：具有较高的并行度；能够有效缩短项目的开发进度。
缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。
系统测试的测试策略：
数据和数据库完整性测试；功能测试；用户界面测试；性能评测；负载测试；强度测试；容量测试；安全性和访问控制测试；故障转移和恢复测试；配置测试；安装测试；加密测试；可用性测试；版本验证测试；文档测试
（三十七）如何测试一个纸杯？
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水
（案例一）放24小时检查泄漏时间和情况；盛上汽油
（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
（三十八）BUG管理工具的跟踪过程（用BugZilla为例子）
参考答案：
测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员
开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配，开发人员和测试确认BUG，如果是本人的BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。
如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。
测试人员在新版本中测试，如果发现问题依然存在，则拒绝验证；如果已经修复，则关闭BUG。
（三十九）数据库主键、外键的作用，索引的优点与不足?
参考答案：
主键：是表中的唯一标示键。作用：保证实体的完整性;加快数据库的操作速度;增加新的表记录时，数据库会自动检索新记录的主键值，不允许该值与其他表中记录的主键重复;数据库会按主键值的顺序显示记录，如果没有设定主键，则按输入的顺序显示记录。
外键：是主键的从属，表示了两个表之间的联系。作用：使用外键可以避免冗余。
索引
优点： 1、通过创建唯一性的索引，可以保证表中数据的唯一性; 2、加速数据的检索速度; 3、加快表与表之间的连接; 4、在使用分组与排序数据检索时，可以显著检索分组与排序的时间; 5、在查询的过程中使用优化隐藏器，提供系统性能。
缺点： 1、创建索引需要时间，且随着数据量的增加而增加; 2、索引需要占用物理空间; 3、当对表中数据进行修改时，索引也要动态维护，降低了数据的维护速度。
（四十）性能测试的流程?
参考答案：
1.测试需求分析2.测试计划制定与评审3.测试用例设计与开发4.测试执行与监控5.分析测试结果6.编写性能测试报告7.测试经验总结。
（四十一）怎样看待加班问题
（四十二）功能测试用例需要详细到什么程度才是合格的？
这个问题也是测试工程师经常问的问题。有人主张测试用例详细到每个步骤执行什么都要写出来，目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子：欧美、日本等软件外包文档都是这样做的。
另外一种观点就是主张写的粗些，类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范，变动十分频繁，因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护，可以让测试执行人员有更大的发挥空间。
实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。举个例子：“用户登陆系统”的测试用例可以不写出具体的执行数据，但是至少要写出五种以上情况（），如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点，而是要写出功能点的各个方面（如果组合情况较多时可以采用等价划分）。
另一个影响测试用例的就是组织的开发能力和测试对象特点。如果开发力量比较落后，编写较详细的测试用例是不现实的，因为根本没有那么大的资源投入，当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求，如果进度较紧张的情况下，是根本没有时间写出高质量的测试用例的，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。
因此，测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。最后要注意的是测试人员一定不能抱怨，力争在不断提高测试用例编写水平的同时，不断地提高自身能力。
（四十三）配置和兼容性测试的区别是什么？
配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。
配置测试的核心内容就是使用各种硬件来测试软件的运行情况，一般包括：
（1）软件在不同的主机上的运行情况，例如Dell和Apple；
（2）软件在不同的组件上的运行情况，例如开发的拨号程序要测试在不同厂商生产的Modem上的运行情况；
（3）不同的外设；
（4）不同的接口；
（5）不同的可选项，例如不同的内存大小；
兼容性测试的核心内容：
（1）测试软件是否能在不同的操作系统平台上兼容；
（2）测试软件是否能在同一操作系统平台的不同版本上兼容；
（3）软件本身能否向前或者向后兼容；
（4）测试软件能否与其它相关的软件兼容；
（5）数据兼容性测试，主要是指数据能否共享；
配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。具体进行时仍然按照测试用例来执行。
（四十三）什么是系统瓶颈
瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。
严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如CPU使用率刚好达到100%时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。
因此我们测试系统瓶颈主要是实现下面两个目的：
-发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。