松勤软件测试：整理的各种类型的软件测试面试题

Monkey 测试的优点和缺点？
优点：
1、使用简单
2、节省了重复性操作的时间
3、随机输入可能会发现一些平常意想不到的缺陷。Monkey 虽然可以根据一个指定的命令脚本发送按键消息，但其不支持条件判断，也不支持读取待测界面的信息来执行验证操作。
4、可对 Monkey Test 的对象，事件数量，类型，频率等进行设置。
缺点：
测试的对象仅为应用程序包，有一定的局限性。

Why 为什么进行抓包测试?
1:有些时候公司没有标准的接口文档，测试人员只能抓包来获取接口信息
2:抓包可以迅速找到请求，通过抓包可以查看整个请求过程，以及响应过程，可以通过抓包来分辨前台还是后台 bug3:通过抓包，可以查看是否有敏感信息泄露，比如用户密码和个人账号信息等数据。
3:可以通过抓包进行测试，拦截请求，修改请求数据，查看对应响应结果，抓包本身就是接口测试的一部分

怎么进行抓包?
1:工具上，使用 Fiddler 或者 charles 这两个工具
2:Fiddler 设置 http 代理，设置端口号，在手机上设置和 fiddler 在同一网段，设置代理 ip，设置代理端口，手机上的请求就能被获取到了。
3:抓取请求查看，可以过滤，找到自己域名下的请求，通过分析请求地址，请求参数，响应结果来查找问题。

Why 为什么进行性能测试?
对于我们测试，一个系统如果仅仅通过功能测试就发布出去，是很危险的，也是不允许的。系统必须通过性能测试，当然还要有安全性测试，兼容性测试等，才能够对外发布。另外对于性能测试，并不是简单的描述为系统性能好，反应速度快，就行了，这种描述比较含糊，通常我们测试一个系统，项目经理或者产品经理都会提出这个系统的性能需求，比如系统在正常负载下必须 3 秒内做出响应，一分钟能够接收至少 50 个请求，会提出比较明确的需求，当然，有的项目经理不提，那我们的测试经理也应该去问，或者定出性能需求来。

需求的标准是什么？(灵活回答)
标准的需求应该包含以下信息:文档版本信息:包含文档版本、作者、完成日期，如果是修订版需要加上修订记录（包括版本号、修订者、修订日期、修订内容）
目录:目录结构要清晰，不同级别的标题要区分开字号。
目录:目录结构要清晰，不同级别的标题要区分开字号。
产品架构:一般包括功能架构和信息架构。可根据项目性质来确定。
角色定义:产品角色描述，如电商类平台包含的角色有：游客、注册供应商、注册采购商、认证供应商、认证采购商、普通管理员、超级管理员等
功能摘要:通过列出一级功能->二级功能，不需要细分
详细功能描述（产品特性）:即产品特性，包括功能列表、原型界面、详细设计（细分页面元素及约束）等
其它产品需求:依据公司产品要求来定，一般包含系统兼容性要求、产品运营要求、性能要求等

当你参加需求评审时，你的评审准则是什么？
完整性：每一项需求都必须将所有要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确的陈述其要开发的功能。
一致性：指与其它软件需求或高层需求不相矛盾
可行性：每一项需求都必须是已系统和环境的权能和限制范围可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求简明的用户性的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：可理解为每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回溯至某项客户的输入。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在 SRS 中出现一次。这样更改时容易保持一致性。另外，使用目录列表、索引和相互参照列表方法使软件需求规格说明书更容易修改。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好(f i n e - g r a i n e d )的方式编写并单独标明，而不是大段大段的叙述。
分配优先级：应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度以上特点也是需求评审的要点，评审前可以根据实际情况指定需求评审检查表来帮助评审。可以根据以上特点对需求进行评审

你以前工作时的测试流程是什么？
参考答案：（灵活回答）公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我 1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>制定测试计划，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本（可能测试的代码 通过冒烟测试的代码）－>执行测试用例（中间可能会补充用例）－>提交 bug（有些 bug 需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接写到TD（Test Director 相当于禅道））－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）

测试人员在软件开发过程中的任务是什么？
1、尽可能早的找出系统中的 Bug；
2、避免软件开发过程中缺陷的出现；
3、衡量软件的品质，保证系统的质量；
4、关注用户的需求，并保证系统符合用户需求。
总的目标是：确保软件的质量

面试题内容比较多，有时更新不及时，需要完整版滴，可以cue我

软件测试的目的与原则软件？
测试的作用
1、通过测试工作可以发现并修复软件当中存在的缺陷，从而提高用户对产品的使用信心。
2、测试可以记录软件运行过程中产生的一些数据，从而为决策提供数据支持。
3、测试可以降低同类型产品开发遇到问题的风险。
软件测试原则
所谓的测试原则指的就是我们在执行测试工作时必须要遵守的一些规则。
1、测试证明软件存在缺陷：无论执行什么样的测试操作都能证明当前软件是有缺陷的。
2、不能执行穷尽测试：有些功能是没有办法将所有的测试情况都逻辑出来，所以任何的测试操作都有结束的时间。
3、缺陷存在群集现象：对于软件功能说，核心功能占 20%，非核心 80%。在实际工作中我们会集中测试 20%的核心功能，所以这个部分发现缺陷的几率就会高于 80%。因此我们就会遇到缺陷都集中在 20%功能模块里的现象。
4、某些测试需要依赖特殊的环境。
5、测试应尽早介入：为了更多的发现和更好的解决软件中的缺陷。我们追求测试工作尽早的开展。
6、杀虫剂现象：同样的一个测试用例不能重的执行多次，因此软件会对它产生免疫。
7、不存在缺陷谬论：任何软件不可能是完美的