软件测试理论基础

一、测试基础理论

 

1、进行测试用例设计的时候用到的方法有哪些？

A:

　　最常使用的测试用例设计方法包括等价类划分法、边界值分析方法、场景法、错误推测法。其中，最容易发现错误的是边界值法，使用最多的是场景法。以注册为例：首先从需求确定用户名和密码的长度类型约束，根据需求写测试点，然后设计测试数据，编写测试用例。

 

2、测试计划包括哪些主要步骤和信息？

A:

　　测试计划包括引言、测试基本内容（测试目的、测试范围、测试环境、测试工具、测试人员）、实施计划（任务分配、进度安排）、风险控制等。

 

3、测试报告需要包含哪些内容？测试报告交付文档有哪些？你认为测试报告的侧重点是什么？

A:

　　测试报告包括：引言、测试基本信息、测试结果及缺陷分析、测试结论和建议，交付文档。

　　交付文档有测试用例、提交的bug、测试报告。

　　测试报告的侧重点是测试结果和缺陷分析，测试结论。

 

4、bug的生命周期？你是怎么跟进bug的？

A:

bug的生命周期，就是一个bug被发现到这个bug被关闭的过程。生命周期中一般缺陷状态：新建、指派、已解决、待验、关闭。

具体流程如下：

1. 新建Bug，把bug记录到缺陷管理平台
2. 指派给对应的开发人员；
3. 开发人员对Bug进行确认
4. 开发对Bug进行修复；
5. 开发修改后，等新代码包更新测试环境，然后进行bug验证；
6. 如果Bug已经修复，测试人员直接关闭 ；
7. 如果待验的bug在验证时没有解决好，我们需要重新打开>指派>已解决>待验，循环这个过程。中间其他状态：重新打开、拒绝、延期等；
8. 如果提交bug后，开发一直没有修改状态，我们会提醒开发。延期、不予修改的bug则跟开发沟通，找产品确认是否修改。

 

5、Bug记录包含哪些内容？如何提交高质量的bug记录？

A:

一条bug信息至少需要以下几条：

bug标题；bug产生的模块；bug对应的版本；bug严重级别；优先级；bug详细现象描述，包括bug出现的操作步骤，报错日志信息、bug截图等等。

提交高质量的软件缺陷记录需要做到以下几点：

1.严格按照测试流程执行测试：参考需求以及详细设计等前期文档设计出高效的测试用例，然后严格执行测试用例，对发现的问题要充分确认肯定，然后再向外发布。

2.规范提交Bug：注重唯一性，一个bug说明一个问题或者说明一类问题可重现。

3.提交Bug注意准确性：提供这个bug的精确步骤，要让开发人员容易看懂一致；Bug描述及所有信息要前后一致，不可有歧义完整性。

4.明确指明缺陷严重等级和优先级：明确严重等级和优先等级之间的差别，优先解决优先级高的问题。

5.Bug附录：能附带bug现象截图的就带截图，有报错日志的就贴上日志信息客观性。

6.不可重现的缺陷也要记录：首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。

7.明确指明缺陷类型：根据缺陷的现象，总结判断缺陷的类型。如，功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。

 

 

Q:

6、测试分为哪几个阶段?

A:

按照开发阶段划分，软件测试可以分为单元测试、集成测试、系统测试和验收测试；

1. 单元测试：针对每个单元的测试，以及确保每个模块能正常工作为目标；
2. 集成测试：对已测试过的模块进行组装，进行集成测试，目的在于检验与软件设计相关的程序结构问题；
3. 系统测试：检验软件产品能否与系统的其他部分（比如硬件、数据库及操作人员）协调工作；
4. 验收测试：检验软件产品质量的最后一道工序，主要突出用户的作用，同时软件开发人员也应有一定程度的参与。

 

7、什么是回归测试？

A:

　　回归测试有两类：用例回归和错误回归；用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试，看看会重新发现问题。错误回归，就是在新版本中，对以前版本中出现并修复的缺陷进行再次验证，并以缺陷为核心，对相关修改的部分进行测试的方法。

 

8、什么是验收测试？Alpha测试和Beta测试的区别是什么？

　　α、β、λ常用来表示软件测试过程中的三个阶段：

1. α是第一阶段，一般只供内部测试使用；
2. alpha测试 （由用户、测试人员、开发人员共同参与的内部测试）
3. β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；
4. beta测试 （内测后的公测，交给最终用户测试 公司外部展开的测试，可以由非专业的测试人员执行的测试）
5. λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。

A:

验收测试是以用户为主的测试，软件开发和QA人员也应该参加，测试一般在用户所在地进行，由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作。仅限于内部测试稳定后，根据合同中需求由发包商进行验收测试。验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标，该类测试的不是以发现缺陷为主要目的。

 

Alpha测试和Beta测试的区别：两者的主要区别是测试的场所不同。Alpha测试是指把用户请到开发方的场所来测试；beta测试是指在一个或多个用户的场所进行的测试。Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。Alpha测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。

 

Beta测试是当开发和测试基本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。

 

 

Q:

9、你提的问题，开发人员说不是BUG时，你如何应付？

A:

开发人员说不是bug，有两种情况，一是需求没有确定，所以可以找产品经理进行确认，评估是否需要改动，三方商量确定好后再看是否要改。二是这种情况开发认为不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出BUG的依据是什么，如果被用户发现或出了问题，会有什么不良结果。如果还是有分歧，可以将这个问题提出来,跟开发经理和测试经理进行确认，确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

 

 

Q:

10、测试结束的标准是什么？

A:

各个公司可能不同，以下仅供参考，具体根据公司实际情况执行。

1.系统测试用例设计已经通过评审；

2.按照系统测试计划完成了系统测试；

3.核心代码100％ 经过Code Review；

4.系统测试的功能覆盖率达100％；

5.系统的功能和性能满足产品需求规格说明书的要求；

6.在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准；

7.严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后续版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上；对于测试建议性的问题，可调低优先级；

8.由开发经理，测试经理，项目经理共同确认后发布上线。

二、测试用例设计题

1、登录功能，设计测试用例。

A:

功能测试：

• 1.输入正确的账号和密码，点击提交按钮，验证是否能正常登录；
• 2.输入错误的账号或错误的密码，登录失败，是否有相应的提示信息；
• 3.登录成功后能否跳转到正确的页面；
• 4.账号和密码，如果太短或者太长，应该怎么处理，密码太短时是否有提示；
• 5.账号和密码中有特殊字符（如空格），和其他非英文的情况，是否做了过滤；
• 6.是否可以记住登录成功的账号；
• 7.登录失败后，不能记住密码；
• 8.账号和密码前后有空格是否正常处理；
• 9.密码是否加密显示（星号、圆点等）；
• 10.验证码文字是否扭曲过度导致辨认难度大，刷新是否正常；
• 11.登录页面中的注册、忘记密码链接是否正确跳转；
• 12.输入密码的时候，大写键盘开启时是否有提示信息；
• 13.不输入任何内容，点击提交按钮，提示信息是否正确（非空校验）；

UI测试：

• 1.布局是否合理，文字和按钮是否正确排列；
• 2.文本输入框和按钮的长度，高度是否符合要求；
• 3.界面的设计风格是否与Ul的设计风格统一；
• 4.界面中的文字是否简洁易懂，没有错别字；

性能测试：

• 1.打开登录页面，需要几秒；
• 2.输入正确的账号和密码后，登录成功跳转到新页面，不超过5秒；

安全性测试：

• 1.登录成功后生成的Cookie是否有HttpOnly(降低脚本盗取风险）；
• 2.账号和密码是否通过加密的方式，发送给Web服务器；
• 3.账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javaScript验证；
• 4.账号和密码的输入框，应该屏蔽SQL注入攻击；
• 5.账号和密码的输入框，应该禁止输入脚本（防止XSS攻击）；
• 6.错误登录的次数限制（防止暴力破解）；
• 7.考虑是否支持多用户在同一机器上登录；
• 8.考虑一用户在多台机器上是否允许登录；

可用性测试：

• 1.是否可以全用键盘操作，是否有快捷键；
• 2.输入账号，密码后按回车，是否可以登录；
• 3.输入框是否可以以Tab键切换；
• 4.高对比度下能否显示正常（视力不好的人使用）；

兼容性测试：

• 1.主流的浏览器下能否显示正常（IE,FireFox.Chrome,Safari等）；
• 2.不同的平台是否能正常工作，比如Windows,Mac；
• 3.移动设备上是否正常工作，比如iPhone,Android；
• 4.不同的分辨率下是否显示正常；

2、怎么测试购物车模块，设计测试用例。

A:

功能测试：

• 1.将商品加入购物车>选择购物车中所有的商品>确认购买>生成订单>查看订单详情，显示商品信息,购物车商品是否被清空；
• 2.将商品加入购物车、从购物车删除,查看购物车该商品是否相应增减；
• 3.将商品加入购物车、增加/减少商品数量，查看购物车该商品是否相应增加/删除；
• 4.购物车商品默认全选/部分勾选/不勾选>,点击购买>生成订单显示全部商品/生成订单显示部分商品/提示未添加商品；
• 5.所有页面链接功能正常，可以跳转到正确页面；
• 6.卖家在线的时候，旺旺icon高亮，反之，灰色；
• 7.购物车页面打开的同时，在其他页面添加了商品，购物车页面刷新后，新的商品能显示；
• 8.若未登录，点击购物车，则提示用户先进行登录；
• 9.商品未勾选的状态下，结算按钮是置灰无法点击的；
• 10.勾选商品后，已选商品的总价会显示，结算按钮变高亮可点击工作；
• 11.购物车有商品降价或者库存告急的，那么点击对应的tab，降价或者告急商品会归类后显示；
• 12.购物车能添加的商品种类有数量上限；
• 13.若商品已经失效，购物车的商品不可以继续结算；
• 14.已进入支付界面但支付未成功，重新进入购物车，又重新添加了一些物品，则原有的物品是否能正确保留；

界面测试：

• 1.打开页面后，页面的布局是否合理，显示是否完整；
• 2.鼠标浮动在购物车按钮，购物车界面显示是否正常；
• 3.不同卖家的商品在不同的table区域显示，区分明显；

性能测试：

• 打开购物车页面要多久；

可用性测试：

• 快捷键功能是否支持；

兼容测试：

• 1.不同浏览器上的功能是否正常；
• 2.不同浏览器上的页面显示是否正常；

3、QQ收藏表情功能，设计测试用例。

A:正常功能：

表情包支持的图片格式包括jpg、jpeg、bmp、gif、png，不支持doc、xls、flv、txt等；

• 1.表情包符合格式要求，且图片大小在范围内，收藏成功；
• 2.表情包不符合格式要求，图片大小在范围内，收藏失败；
• 3.表情包符合格式要求，图片大小不在范围内，收藏失败；
• 4.收藏时支持对符合格式要求，图片大小范围内的表情包进行单个收藏和批量收藏；
• 5.表情包收藏成功后，可以正常使用；6.表情包收藏后支持删除后再次删除；
• 7.点击文字进行收藏，不支持收藏到表情；
• 8.选择聊天记录中系统时间进行收藏，不支持收藏到表情；
• 9.VIP用户退回到普通用户，原收藏的表情可用；
• 10.收藏表情有效时间内可使用，过期不可使用；
• 11.电脑和手机QQ收藏的表情可共用；
• 12.不支持收藏系统自带的表情；
• 13.支持收藏好友发送的、自己发送的未收藏过的表情；

异常功能:

• 1.空间不足时，点击收藏，是否正常处理；
• 2.达到收藏上限时点击收藏，是否正常处理；
• 3.弱网络、断网离线时，点击收藏，是否正常处理；
• 4.收到表情超过一定时限点击收藏，是否正常处理；
• 5.本地修改不支持的格式为支持的格式，点击收藏，是否正常处理；

易用性测试：

• 1.收藏操作是否方便、简单、易上手；
• 2.收藏后是否便于使用；
• 3.收藏后删除是否不再占用内存；

性能测试:

• 1.单个用户对单个表情收藏和批量收藏时，响应时间是否符合要求；
• 2.多个用户对单个表情收藏和批量收藏时，响应时间是否符合要求；
• 3.用户收藏表情数量达到最大限度时，用户使用表情时响应时间是否符合要求；

安全性测试:

• 添加感染病毒的图片进行收藏，是否可以收藏；
• 图片及内容涉及违规时，是否可以收藏；

兼容性测试:

• 不同Windows操作系统是否可以正常收藏；
• QQ更新版本后，原收藏的表情可以正常使用；
• 在Windows/Mac/IOS/Android设备上可以正常浏览和使用收藏的表情；

4、网上银行转账是怎么测的，设计功能测试用例。

A:

功能测试：

• 1 .验证同行转账、跨行转账，绑定的银行卡的互转;
• 2..校验验证码的有效性（一般小额只需手机验证码，大额需要手机验证码+动态口令，转给绑定的银行卡无需验证）;
• 3. 验证转账手续费收取情况（比如小于一定金额同行转账免费，跨行收费等等，具体收费标准以需求书描述为准）；
• 4. 验证即时转账和普通转账情况；
• 5.验证6位数交易密码正确与否的情况；
• 6. 验证账户余额不足的情况；
• 7 .验证转账金额超过限额情况；
• 8.验证转账超时情况（一般交易都有超时控制，服务器超过一定时间（一般30s）没有响应，服务器就会发出超时报错给客户端，超时场景测试需要临时联系开发，让开发设置一下，测试员工就可以在客户端模拟出超时场景）；
• 9.验证收款人姓名和收款账号不一致的情况或者两者都有误的情况；
• 10. 验证转出方或者转入方属于非法账户（挂失，冻结，锁定，销户的账户）情况；
• 11. 验证信用卡、定期存折不能转出。（一般会在账号选择的时候，进行屏蔽）；
• 12.验证在ios、安卓，wap，web端的转账场景；

6、支付宝充值的测试，设计功能测试用例。

A:

功能测试：

• 1. 验证绑定的主流银行卡的充值情况；
• 2 .验证正常充值情况；
• 3. 验证充值金额大于限额情况；
• 4. 验证支付密码输入正确与否的情况；
• 5. 验证银行卡余额不足情况；
• 6 .验证银行卡挂失，冻结，锁定，销户的充值情况；
• 7.验证充值超时情况（一般交易都有超时控制，服务器超过一定时间（一般30s）没有响应，服务器就会发出超时报错给客户端，超时场景测试需要临时；
• 联系开发，让开发设置一下，测试员工就可以在客户端模拟出超时场景）；
• 8 .验证在ios、安卓，wap，web端的充值场景；

六、支付宝提现的测试，设计功能测试用例。

A:

功能测试：

• 1 .验证提现到绑定的主流银行卡；
• 2. 验证提现两小时内到账情况；
• 3 .验证手续费收取情况(0.1%，2016年起每人只有20000的免费提现及转账额度)；
• 4 .验证提现时，临时添加银行卡，并且选择该银行卡；
• 5. 验证提现时输入交易密码正确与否的情况；
• 6 .验证提现超时情况;
• 7.验证提现金额大于余额的情况；
• 8.验证提现金额小于等于余额的情况；
• 9 .验证在ios、安卓，wap，web端的提现场景；

三、测试面试题集-3.生活物品测试：杯子、伞、钢笔、桌子

面试官主要考察目的：

• 没有需求文档或需求不完整的情况下如何测试？
• 能不能把测试用例设计方法应用到实际工作中去？
• 测试思维是否完整，应变能力如何，表达能力如何？

一、如何测试一个杯子？

A：功能测试：

1. 倒入温水，测试杯子是否可以正常装水；
2. 装入水后，是否可以正常喝水；
3. 杯子是否有保温功能，保温功能是否正常；
4. 拧紧杯盖后，上下左右翻转杯子，杯子是否漏水；

容量测试：

• 1、倒入温水，测试杯子最大盛水量是多少；
• 2、杯子最大盛水量是否符合国际计量标准，是否没有误差；

兼容性测试：

• 1、分别倒入不同的液体（冰水、热水、温水、果汁、酒水），测试杯子是否正常；
• 2、用杯子泡茶、咖啡、牛奶，测试被子是否可以正常使用；
• 3、在大风、大雨、大雪、高温天气下，杯子是否正常使用；
• 4、杯子放进微波炉，是否会爆炸；
• 5、杯子放进冰箱的时候，是否会融化；

安全性测试：

• 1.杯子的材质是否符合国际标准，是否对人体有害；
• 2.杯子是否会与所盛液体发生化学反应，产生对人体有害的物质（细菌，病毒等）；
• 3.杯子在高温、零下温度是否会发生化学反应，产生有害物质；
• 4.杯子置于微波炉、冰箱是否会发生化学反应，产生有害物质；
• 5.杯子破损后，是否容易对使用者造成伤害；

性能测试：

• 1.分别倒入0-100摄氏度的水，是否可以承受不同温度；
• 2.倒入不同液体静置一段时间（24小时以上），杯子是否会漏水；
• 3.杯子的保温性是否达到要求 ；
• 4.杯子的耐热性是否达到要求；
• 5.杯子的耐寒性是否达到要求；

压力测试：

• 1.用手按压杯子，是否容易变形；
• 2.杯子从不同高度摔下去的损坏程度如何；
• 3.在杯子内分别装入少量的、半杯的、满杯的液体，看其装载量是否达到设计标准；

易用性测试：

• 1.杯子的形状是否容易倒入液体；
• 2.杯子的重量和大小是否合适；
• 3.杯子是否防滑；
• 4.杯口是否平整，是否方便饮用；
• 5.杯子拿在手上是否会掉色；
• 6.杯子是否隔热、不烫手；

UI测试：

• 1.杯子设计是否符合需求规格说明书；
• 2.杯子的形状和颜色是否符合大众审美需求；
• 3.杯子是否标有刻度、Logo等；

交互性测试：

• 杯子与杯盖、杯托交互性是否符合用户使用习惯；

文档测试：

• 使用手册是否对杯子的用法、限制、使用条件进行了详细描述；

维护性测试：

• 杯子破损后，是否有修补措施；

二、如何测试一把伞？

功能测试：

• 1.伞是否可以正常打开/关闭，是否可以反复打开/关闭；
• 2.伞是否可以折叠，伞的尺寸是否符合使用需求；
• 3.伞骨与伞柄是否耐用，材质是否符合需求，是否生锈；
• 4.伞的底座是否结实，是否容易脱落；
• 5.伞是否能够正常遮阳/挡雨，伞面是否能够承受住风吹日晒，是否防紫外线；
• 6.伞的暗扣/粘扣的是否能够正常使用，外部捆绑条长度是否合适，是否结实耐用；
• 7.自动伞是否可以正常使用，按钮承受力度是否适中；

UI测试：

• 1.伞的类型是否符合需求，手动伞、自动伞；
• 2.伞的外观、颜色、是否齐全，是否美观；

易用性测试：

• 1.伞的重量和大小是否方便人们携带；
• 2.伞的打开、关闭是否容易操作；

兼容性测试：

• 1.伞的用途：遮阳、挡雨是否可以一伞二用；
• 2.伞是否能够遮挡住别的东西，例如沙子等；

压力测试：

• 1.遮阳伞的抗紫外线程度；
• 2.伞最大能承受住多大的风、雨的力度；

安全性测试：

• 1.伞尖是否容易误伤到旁人；
• 2.伞柄是否光滑，避免开合刮伤；
• 3.伞底座的挂绳是否结实，不易脱落；

维护性测试：

• 伞破损后，是否有修补措施；

三、如何测试一支钢笔？

A:

功能测试：

• 1.钢笔书写文字是否流畅；
• 2.钢笔字迹的颜色是否正常，书写的文字是否能正常显示；
• 3.钢笔书写字迹的粗细度是否合适；
• 4.钢笔是按键式还是笔帽式的（按键式的能否正常使笔芯正常收缩，笔帽式的是旋转的还盖帽的）；
• 5.钢笔的笔芯触地能否正常书写；
• 6.钢笔笔芯是否漏墨水；
• 7.钢笔没有墨水是否能继续书写；
• 8.钢笔笔杆能否正常拆卸；
• 9.钢笔笔芯用完能否换笔芯；

UI测试：

• 1.钢笔的笔杆、笔帽、笔芯颜色与风格是否统一；
• 2.钢笔上是否注明了品牌；

兼容性测试：

• 1.钢笔能否在各类纸张上进行书写；
• 2.钢笔换不同类型的笔芯能否调换成功；

易用性测试：

• 1.笔杆是否防滑处理；
• 2.笔杆长度大小是否符合正常人的手大小长度设计；

安全性测试：

• 1.钢笔笔芯的墨水是否有毒；
• 2.手部粘漆是否有毒；
• 3.笔杆是否光滑平整不划手；

压力测试：

• 1.钢笔从一定的高度掉落，是否完好无损；
• 2.钢笔是否能承受一定的压力；

 

四、如何测试一个桌子？

A:

功能测试：

• 1.确认桌子的功能是用于办公还是用于放置物品，桌子的尺寸是否符合需求；
• 2.桌腿高度粗细是否合适，接触地面的部分是否平整；
• 3.桌面是否保持水平面持平，是否能放置物品保持不倾斜；
• 3.桌面和桌腿连接处是否紧密无缝隙；
• 4.桌子的支撑点是否牢固，放置物品桌子是否摇晃；
• 5.桌子会不会掉颜色，物品在桌子上放置一段时间颜色会不会粘到物品上；
• 6.有水撒到桌子上的时候，用布或纸擦的时候会不会掉颜色；
• 7.桌面是否防水、防油以及其他污渍；

易用性测试：

• 1.桌子的高度是否合适，是否方便拿放物品；
• 2.桌子是否方便移动，重量是否合适；
• 3.桌子有污渍是否易于清理干净；

UI测试：

• 1.检查桌子整体颜色是否均匀协调，各个部位之间的颜色是否协调；
• 2.桌子形状大小是否适中，桌面与桌腿的大小比例是否协调；
• 3.桌子的表面是否光滑，是否会凹凸不平；

安全性测试：

• 1.桌子的桌面、边缘和拐角处是否平滑不伤手；
• 2.桌子的支撑力是否足够；
• 3.桌子推倒后，损毁程度如何，是否不易伤人；

性能测试：

• 1.桌子的承重能力如何，最大能承受的重量是多少；
• 2.桌子上堆放较重物体一段时间，承重能力如何；