测试基础理论
1、什么是软件测试？软件测试的目的与原则
定义：
在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程
目的：
- 更快、更早的发现尽可能多的错误
- 测试是程序的执行过程，目的在于发现错误
- 软件测试是为了发现程序中存在的代码或业务错误
- 为了检验产品是否符合用户的需求
- 为了提高用户体验
软件测试的原则：测试应尽早启动，介入（需求分析阶段），所有的测试应追溯到用户需求，测试证明软件存在缺陷，不可能执行穷尽测试，完全测试是不可能的，测试需要终止
二八原则：测试发现的错误中80%很可能起源于20%的模块。（缺陷存在群集现象）
对错误结果要有一个确认的过程（测试的详细数据、截图、前置条件等），制定严格的测试计划；妥善保管测试过程中的所有文档；程序员应尽量避免测试自己写的程序；设计测试用例是应该考虑到合法的输入和不合法的输入
2、软件测试的流程
-
熟悉需求原型
-
制定测试计划
-
编写测试用例
-
执行测试用例
-
发现问题需要提交缺陷报告
-
跟踪bug，回归测试
-
一阶段测试完成后编写测试报告
-
总结测试经验
3、测试用例设计方法
白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖
黑盒测试：等价类划分、边界值分析、因果图/判定表法、状态图法、正交排列法、测试大纲法、场景分析法、错误推测法、随机测试
4、简述什么是静态测试、动态测试、黑盒测试、白盒测试、 α测试 、β测试
- 静态测试：是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程
- 动态测试：是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能
- 黑盒测试：一般用来确认软件功能的正确性和可操作性，目的是检测软件的各个功能是否得以实现，把被测试的程序当做一个黑盒，不考虑其内部结构，在知道该程序的输入和输出之间关系和程序功能的情况下，依靠软件规格说明书来确定测试用例和推断测试结果的正确性
- 白盒测试：根据软件内部的逻辑结构分析来进行测试，是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现
- α测试：是由用户在开发环境下进行的测试，也可以使公司内部用户在模拟实际操作环境下进行的受控测试，Alpha不能由程序员或测试员完成
- β测试：由软件的一个或多个用户在实际使用环境下进行的测试，开发者通常不在测试现场，Beta测试不能由程序员或测试员完后
5、软件测试分为几个阶段，各阶段的测试策略和要求是什么？
测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段
- 单元测试：是针对软件设计的最小单元--程序模块甚至代码进行正确性检验的测试工作，通常由开发人员进行
- 集成测试：在单元测试基础上，将所有模块按照设计要求，组装成子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独的工作，但并不能保证连接起来也能正常的工作。程序在某些局部反应不出来的问题，在全局上很可能暴露出来，影响功能的实现，测试重点是模块间的衔接以及参数的传递等
- 系统测试：是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响
- 验收测试：以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目，可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全部测试，尤其要进行文档测试
6、软件生命周期
-
需求分析/评审-->需求测试，产品经理+（测试、研发、设计师）
-
概要设计
-
详细设计
-
软件编码
-
单元测试-->研发
-
集成测试-->研发或测试
-
系统测试-->测试
-
验收测试-->客户
-
运行维护
7、软件产品质量特征是什么？
- 功能性：适应性、准确性、互操作性、依从性、安全性
- 可靠性：成熟性、容错性、易恢复性
- 可使用性：易理解性、易学习性、易操作性
- 效率：时间特性、资源特性
- 可维护性：易分析性、易变更性、稳点性、易测试性
- 可移植性：适应性、易安装性、遵循性、易替换性
8、你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎么解决？
首先，确认开发环境是否跟自己测试环境一致，排除因环境或者业务理解不一致而产生的错误bug，确认是实实在在的bug后，将问题提交到缺陷管理库里面进行备案
严重级别较高的bug，要获取判断的依据和标准：根据需求说明书、产品说明、原型图、设计文档等。确认实际结果是否与计划有不一样的地方，提供缺陷是否确认的直接依据：
如果没有文档依据，
1）可以根据同行或类似软件的一般特性来说明是否存在不一致，来确认是否是缺陷
2）根据用户的一般使用习惯，来确认是否是缺陷
3）与设计人员、开发人员和客户代表等相关人员探讨，确实是否是缺陷
合理的论述，向测试经理说明自己的判断的理由，等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定
如果是级别较低的建议性bug，开发不改，暂时不需要花费大量时间去说服修改，可以在版本结束后遗留缺陷评审会议上再统一讨论跟进。
