测试技术面试题
1、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
参考答案：
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
2、测试的策略有哪些？
参考答案：
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）
3、正交表测试用例设计方法的特点是什么？
参考答案：
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。
4、描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？
参考答案：
就是Bugzilla的状态转换图。
5、描述测试用例设计的完整过程？
参考答案：
需求分析 + 需求变更的维护工作；
根据需求 得出测试需求；
设计测试方案，评审测试方案；
方案评审通过后，设计测试用例，再对测试用例进行评审；
6、单元测试的策略有哪些？
参考答案：
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
7、你所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
参考答案：Compatibility Testing（兼容性测试），也称“Configuration testing（配置测
试）”，兼容性测试是将验证软件与其所依赖的环境的依赖程度，包括对硬件的依赖程度，对平台软件，其它软件的依赖程度，来检查程序能正常的运行的测试
Functional testing (功能测试)，也称为behavioral testing（行为测试）或黑盒测试，根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。
Performance testing（性能测试），性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
主要包括以下三个方面：应用在客户端性能的测试，应用在网络上性能的测试和应用在服务器端性能的测试
8、Beta测试与Alpha测试有什么区别？
参考答案：Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
面试交流教程关注微信公众号：【软件测试小dao】免费领取
更多软件测试资源请加软件测试技术交流群：1033482984
9、一套完整的测试应该由哪些阶段组成？
参考答案：
测试计划、测试设计与开发、测试实施、测试评审与测试结论
10、如何理解压力、负载、性能测试测试？
参考答案：
性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个
用户连续访问系统1个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。
11、在配置测试中，如何判断发现的缺陷是普通问题还是特定的配置问题？
参考答案：
在进行配置测试时，测试工程师仍然会发现一些普通的缺陷，也就是与配置环境无关的缺陷。因此判断新发现的问题，需要在不同的配置中重新执行发现软件缺陷的步骤，如果软件缺陷不出现了，就可能是配置缺陷；如果在所有的配置中都出现，就可能是普通缺陷。
需要注意的是，配置问题可以在一大类配置中出现。例如，拨号程序可能在所有的外置Modem中都存在问题，而内置的Modem不会有任何问题。
12、软件的构造号与版本号之间的区别？BVT(BuildVerificationTest)
参考答案：
版本控制命名格式: 主版本号.子版本号[.修正版本号[.编译版本号 ]]
Major.Minor [.Revision[.Build]]
应根据下面的约定使用这些部分：
Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。
Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。
Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。
Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。
BVT(BuildVerificationTest)：
作为Build的一部分，主要是通过对基本功能、特别是关键功能的测试，保证新增代码没有导致功能失效，保证版本的持续稳定。实现BVT方式是有以下几种：
1、测试人员手工验证关键功能实现的正确性。特点：这是传统开发方法中，通常采用的方式。无需维护测试脚本的成本，在测试人力资源充足，测试人员熟悉业务、并对系统操作熟练情况下效率很高，比较灵活快速。缺点：人力成本较高；对测试人员能力有一定要求；测试人员面对重复的工作，容易产生疲倦懈怠，从而影响测试质量。
2、借助基于GUI的自动化功能测试工具来完成，将各基本功能操作录制成测试脚本，每次回放测试脚本验证功能实现的正确性。特点：能够模拟用户操作完成自动的测试，从UI入口到业务实现，每一层的代码实现都经过验证；节约人力成本；降低测试人员重复劳动的工作量，机器不会疲倦；缺点：对于UI变动比较频繁的系统来说，这种方式的维护成本很高，实施起来非常困难。另外，在项目周期较短且后续无延续性或继承的情况下，也不推荐使用此方式。
3、由开发人员通过自动化测试工具完成业务层的BVT测试。特点：通过对业务层关键功能的持续集成测试，保证系统功能的持续稳定。可以结合DailyBuild，做为Build的一部分，自动实现并输入BVT报告。缺点：仅对业务规则实现的正确性进行了测试，对表现层无法测试到，对于诸如：前台页面控件各种事件响应、页面元素变化等方面的问题无法保证。
关注我，不迷路。下一期给大家分享的是人力资源方面的面试题！
燃烧秀发输出内容，如果有一丢丢收获，点个赞鼓励一下吧！
不要只做收藏从未停止，行动从未开始的人，很多事情，做着做着就无师自通了。如果在做的过程中还能稍微加点思考，稍微看一些别人的经验和做法，成长会更快，效果也会更好！加油吧，测试人！路就在脚下，成功就在明天！
