软件测试面试题 - 测试理论
测试理论
测试策略
相似问法：测试包括哪些？测试要涵盖哪些方面？
功能：各个功能是否完善
性能：确定系统的性能级别和承受压力的能力（负载测试、并发测试、峰值测试、稳定性测试...)
安全性
兼容性
可靠性
易用性
安全卸载
UI
用例要素是什么
相似问法：用例里面包含什么内容？
答：用例编号、模块名称、功能点、用例标题、前置条件、测试步骤、期望结果、优先级、实际结果、备注
为什么写用例
1、理清思路，避免漏测和重复测；
2、提高测试效率；
3、跟进测试进度；
4、更好的发现问题，记录问题，复现问题；
5、跟进重复性工作；
6、告诉领导：我做过；
7、接口测试流程中的一个产物（测试用例）
上面7点，有用例，自己心中有数，不用一个测试点重复测好多次，也避免漏测。
设计测试用例有哪些方法
我是用等价类、边界值、错误推测法、场景法等测试用例设计方法来编写测试用例的。
1.等价类分为有效等价类和无效等价类，符合需求的就是有效等价类，不符合需求的就是无效等价类。
2.因为大量错误都是发生在输入和输出的边界上，而不是发生在输入输出范围的内部，所以就有了边界值分析法，边界值是选取正好等于、刚刚大于和刚刚小于边界的值，它一般是跟等价类一起用的。
举个例子：设置密码要求是6-12位的数字和字母的组合，那有效等价类就是长度在6-12之间，数字和字母的组合；无效等价类就是长度小于6（取5）的数字字母组合，长度大于12（取13）的数字字母组合，长度在6-12之间的纯数字，长度在6-12之间的纯字母，长度在6-12之间的除了数字和字母以外的字符，等等。
3.错误推测法是指凭借经验推测程序可能出现的错误，比如新建和修改的名称要唯一，不唯一的话没办法提交成功。
4.场景法是根据业务流程来写的，有基本流和备选流，然后考虑异常流情况下是否出现bug。比如一个商品加入购物车、提交订单后超时不支付，会出现什么情况。
写测试用例的思路
首先要熟悉熟悉需求文档，不要着急下手，先理清楚“项目是怎么使用的”、“是给谁用的”、“干什么用的”，然后根据业务流程来写，提取功能点，再根据等价类、边界值、错误推测法、场景法进行测试用例的编写，在Excel表格中填写。
功能点的话，每个系统的模块中都有一些共有的功能，比如：增删改查等，所以在测试中我们要先把这些功能过一遍。
先走正常流，正常流通过之后，再对异常情况进行测试。
另外，熟悉业务流程是非常重要的，模块与模块、功能和功能之间是相互联系的，不能只是单独测它的功能正不正常，还要把他们的关系全部走通。比如我测的电商系统中，要先添加商户、品牌和分类，然后才能添加商品。
需求分析===》提取功能点（测试点）==》测试用例编写
常见测试关注点
登录：
1、账号框：正确、错误（错误、中文、特殊字符、超长）、空
2、密码框；正确、错误（错误、中文、特殊字符、超长）、空、密文显示并且不能复制粘贴、是否区分大小写、请求加密
3、用户未注册
4、用户已注销，再次登录
5、验证码：有效时间、输入错误、过期、是否容易识别、点图片是否更换验证码
6、用户名、密码输入“sql注入攻击”字符串
7、账号是否互斥
输入正确的用户名和密码登录成功；
用户名正确，密码错误，是否提示输入密码错误；
用户名错误，密码正常，是否提示输入用户名错误；
用户名和密码都错误，是否有相应提示；
用户名密码为空时，是否有相应提示；
如果用户未注册，提示请先注册，然后进行登录；
已经注销的用户登录失败，提示信息友好；
密码框是否加密显示，并且不能复制粘贴；
用户名是否支持中文、特殊字符；用户名是否有长度限制；
密码是否支持中文，特殊字符；密码是否有长度限制；
密码是否区分大小写；密码为一些简单常用字符串时，是否提示修改；
密码存储方式，是否加密；登录功能是否需要输入验证码；
验证码的有效时间；
验证码输入错误，登录失败，提示信息是否友好；
输入过期的验证能否登录成功；
验证码是否容易识别；验证码换一张功能是否可用；
点击验证码图片是否可以更换验证码；
用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
新建：
必填项要有红色的*号提示
正确输入所有字段的信息，点击提交；
只输入必填字段，点击提交；
不输入必填字段，点击提交；
不输入任何信息，点击提交；
输入各字段信息，点击取消；
输入字符串长度不符合规定的字符串长度，点击提交；
输入不符合规定的字符类型，点击提交；
输入重复的数据，点击提交；
新增内容前后加空格，检查是否有去空格处理；
新增之后，列表默认倒序；
点击输入框的关闭图标。
查询：
不输入任何条件；
进入页面般显示全部；
输入部分有效条件查询；
输入全部有效条件查询；
输入无效条件查询；
输入条件，点击重置；
前后输入空格，要有去空格处理；
输入条件，点击查询后，查询输入不清空；
删除：
单选数据，点击删除，弹出删除提示，点击确定；
单选数据，点击删除，弹出删除提示，点击取消；
多选数据，点击删除，弹出删除提示，点击确定；
多选数据，点击删除，弹出删除提示，点击取消；
不选择任何数据，直接点击删除；
确认是逻辑删还是物理删，逻辑删只是把状态改变，数据库还是有的，物理删是从数据库中删除了，数据库中没有的相应的信息；删除后添加一样的数据。
如何保证测试用例的质量
1.测试用例的需求覆盖率是100%；
2.测试用例的可执行；
3.测试用例的可读性；
4.测试用例的评审；
5.及时的维护测试用例，也许一个功能的变更，或者场景的添加，就需要考虑更多的情况，保证测试用例的完整性。
测试用例是根据什么写的
主要还是根据需求文档来写的，有疑问的地方我会及时问产品经理
之前用什么写测试用例
我们是根据需求文档提取测试点，然后根据等价类、边界值、错误推测法、场景法来编写测试用例，用excel表格来写测试用例的，发现bug后用禅道提交bug，指派给对应的开发。
没有需求文档怎么开展测试工作
1.问：没有需求文档，但是有需求，也就有需求提出者。可以与需求人员进行沟通。
2.问：只要懂需求的人，我们都可以问。也可以问开发，项目经理，测试经理等。
3.分析：结合一些业务资料和百度等进行分析
4.对比：对比竞争对手产品，分析得到合适的需求
5.经验：可以借助原来的经验
6.合理：一切的需求都要符合常理
软件开发过程的常见模型
1、瀑布模型：线形的、顺序的软件开发模型
2、V模型： 需求分析、概要设计、详细设计、编码、
单元测试、集成测试、系统测试、验收测试
3、W模型：测试和开发同步进行，可以尽早发现问题
需求分析、需求测试
概要设计、概要设计测试
详细设计、详细设计测试
编码实现、单元测试
模块集成、集成测试
系统构建、系统测试
系统安装、验收测试
软件上线标准
所有测试用例执行完毕，所有的bug都回归测试完毕，当然如果遗留的一些小的优化性的问题，可以汇报给产品经理、项目经理，决定是否上线；
然后产品经理进行验收后，就可以上线了。
单元、集成、系统、验收测试
1、单元测试属于白盒测试，是对代码中的函数和方法进行测试；
2、集成测试属于灰盒测试，也可以称作接口测试，测试对象是模块之间、子系统之间的接口
3、系统测试是对整个系统进行测试，属于黑盒测试
4、验收测试分为a验收和贝塔验收，a验收是在开发者环境下进行测试，贝塔验收是在真实环境下由真实用户体验，有问题再反馈给开发人员
补充：α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。
软件测试的风险
进度风险、质量风险、人员风险、变更风险、成本风险
测试报告有哪些内容
相似问法：你写过测试报告吗？
写过，不过我们写的都是我们自己负责模块的测试报告，整个系统的测试报告由测试经理完成。
一般的话会对项目背景做一个阐述。
1、测试内容：测试内容的大纲。
2、测试环境：测试环境的描述，包括客户端和网络环境。
3、测试工具：测试过程中的测试资源使用。测试的数据：bug数，解决数，遗留数。
4、模块bug分布，bug走势图，缺陷遗留，需要说明的问题。
5、测试数据分析：对于整个过程测试的一个分析，得出结论。
6、遗留问题：对于软件遗留问题有详细说明。
主要就是内容简洁、不罗列详细数据、挑拣一些能说明问题分析数据的：比如缺陷走势图，模块的bug分布等等，突出重点遗留问题，然后得出分析测试结论。
回归测试策略
历史用例（上一个版本的用例）在先版本怎么回归？
回归测试常用的策略有：全面回归测试、选择性回归测试等
像我们一般会进行三轮的测试，第一轮把功能都过一遍，提bug；第二轮做一个全面的回归测试；看具体的情况，第三轮会进行选择性的回归测试，把出现bug的相关模块都测一遍。
1、全面回归测试：所有的测试用例都重新测一遍
2、选择性回归测试：对于出现问题的bug进行验证，没有问题的bug就不进行测试
3、自动化工具回归测试：使用自动化测试工具进行回归测试
提了一个bug，开发不认怎么办
1、首先从我自身找问题，再根据需求文档分析这是不是一个bug，如果确定是bug；
2、再看看测试用例的操作步骤写的够不够详细、可执行性强不强；
3、如果不是以上原因，那就跟开发沟通，可以在开发的电脑上实现给他看，然后跟他好好解释，如果这真是一个bug，开发是不会不认的；
4、如果还是不认，那就要上报给上级，然后开会进行讨论
什么bug是一个好的bug
1、确定与需求不符
2、bug的复现步骤要详细，可读性可执行性强，能够再次复现出来
