测试基础
测试流程
请介绍你们公司的测试流程
（1）理解需求并参考需求评审
（2）编写测试计划
（3）设计测试用例
（4）搭建测试环境
（5）执行测试用例
（6）发现问题→提交bug→跟踪bug→关闭bug
请介绍你们公司的bug管理流程。
发现bug→ 确认是问题，稳定重现，未提交 → 提交bug → 跟踪bug
→ 验证bug →关闭
文档
测试计划包括什么？测试报告包含什么？
测试计划：项目概述，测试需求和规格，人力分配，
时间，测试方法，测试工具；
测试报告：执行了多少用例，
发现了多少问题，总结。
软件系统的用户文档包括哪些？
- 用户手册
- 安装和设置指导
- 联机帮助
- 指南、向导
- 样例、示例和模板
- 授权/注册登记表
- 最终用户许可协议
除用户文档之外，文档测试还应该关注哪些文档？
- 开发文档
软件需求说明书
数据库设计说明书
概要设计说明书
详细设计说明书
可行性研究报告
- 管理文档
项目开发计划
测试计划
测试报告
开发进度月报
开发总结报告
BUG 管理
发现bug，开发不认，怎么办？
首先查看需求文档，确定需求有明确要求；
确认是问题且稳定重现，提交操作流程、数据、截图、日志给开发人员，让他去确认；
如果还是不行，和领导沟通进行确认需不需要改。
发现一个bug，很难重现，怎么办？
首先排除错误操作，多执行几次，找到导致问题发生的必要条件。
理论
测试用例设计方法有哪些？
1. 等价类划分：常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2. 边界值分析法：边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3. 错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.
4. 因果图方法：前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
5. 正交表分析法：有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
6. 场景分析方法：指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
软件测试和质量保证的区别？
软件测试：尽早尽快尽多的找出bug
质量保证：验证软件是否满足规定的质量和用户需求
什么是兼容性测试？兼容性测试侧重哪些方面？
兼容性测试：主要检查软件在不同的硬件环境、软件环境上
是否能够正常的运行，即可移植性。
硬件环境：指测试所需的服务器、客户端、网络连接设备、
以及打印机、扫描仪等辅助硬件设备所构成的环境。
软件环境：软件运行所需的操作系统、数据库、中间件、浏
览器及与被测软件共存的其他软件所构成的环境。
兼容测试的重点是，对兼容环境的分析。通常，是在运行
软件的环境不是很确定的情况下，才需要做兼容。根据软
件运行的需要，或者根据需求文档，一般都能够得出用户
会在什么环境下使用该软件，把这些环境整理成表单，就
得出做兼容测试的兼容环境了。
测试的策略有哪些？
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）
软件测试的5C标准？
Correct（准确）：每个组成部分的描述准确，不会引起误解；
Clear（清晰）：每个组成部分的描述清晰，易于理解；
Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
Consistent（一致）：按照一致的格式书写全部缺陷报告。
你认为做好测试计划工作的关键是什么？
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，
并且通过对资源、时间、风险、测试范围和预算等方面的综合分析
和规划，保证有效的实施软件测试；
做好测试计划工作的关键 ：目的，管理，规范
（1）明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺
陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找
出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖
功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，
便于使用，生成的测试结果直观、准确
（2）坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、
“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以
帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定
测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文
档和软件的存放位置（Where）。
（3）采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容
的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试
计划的内容没有及时更新，误导测试执行人员。
（4） 分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试
小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据
库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划
主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用
例是完成测试任务的具体战术。
你认为做好测试用例工作的关键是什么？
需求和设计文档的理解程度，对系统的熟悉程度。
你觉得软件测试通过的标准应该是什么样的？即软件交付标准。（被问过）
缺陷密度值达到客户的要求。
集成测试和系统测试的关系？
（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；
（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。
黑盒测试和白盒测试的优缺点？
| 黑盒测试 | 白盒测试 | |
|---|---|---|
| 优点 | 1）比较简单，不需要了解程序内部的代码及实现； 2）与软件的内部实现无关； 3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题； 4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能; 5）在做软件自动化测试时较为方便。 |
帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。 |
| 缺点 | 1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%； 2）自动化测试的复用性较低。 |
1）程序运行会有很多不同的路径，不可能测试所有的运行路径； 2）测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求； 3）系统庞大时，测试开销会非常大。 |
疑难杂症（挑刺）
需求不详细，该怎么测试？（待修改）
（1）站在用户角度使用软件
（2）看公司是否有相关的邮件、文档整理出需求
测试活动中，如果发现需求文档不完善或者不准确，怎么处理？
测试需求分析 发现需求文档不完善或者不准确，应该立即和相关人员进行协调交流。
问题
如何测试一个杯子？
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放 24 小时检查泄漏时间和情况；盛上汽油（案例二）
放 24 小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透