黑盒测试：
把测试的对象看成是一个黑色的盒子的，看不到里面内部的结构，是对软件的一种功能性的测试。
白盒测试：
就是把测试的对象看成是一个透明的盒子，能够看见被测软件的内部结构，是单元测试的一种形式，是针对程序的内部代码的一种测试形式。
灰黑测试：
它是介于黑盒测试与白盒测试中间，具体的来说就是测试开发工程师（测试工程师）能够看开发的代码，进行代码的走查，和参与开发代码的评审。
测试编写代码的分类：
1、手工测试
2、自动化测试（UI自动化测试，接口自动化测试）：通过工具或者是代码的形式来模拟人的操作，来对被测试的产品进行自动化测试的操作。
现在企业要的是什么样的人？
P6
- 技术方面能够主导公司技术发展。
- 技术层面能够独立的负责公司层面的项目。
- 可以和客户以及公司各个不同职能的人来解决问题。
要求：能够独立的负责一个产品的测试，能够很好的做功能测试，以及在自动化测试需要开展的时候又能很好的参与到自动化的测试，以及在性能测试开展的时候又能够很好的参与进去。
软件质量的六大特性：
功能性：软件需要满足用户显示或者隐式的功能
易用性：软件易于学习和上手使用。
可靠性：指的就是软件必须实现需求当中指明的具体功能。
效率性：类似于软件的性能。
可维护性：要求软件具有将某个功能修复之后继续使用的功能。
可移植性：当前软件可以从一个平台移植到另一个平台上去使用的能力。
什么是算法？
在程序里面，指的是做一件事需要的步骤。什么是程序，程序=数据结构+算法。
数据结构：
队列：先进先出
栈：先进后出
<：小于
==：等于
>：大于
!=：不等于
&&：并且（至少两个条件的关系）
||：或者(至少两个条件满足一个就没可以了)
软件分类：
B/S（WEB）的产品测试经验。app的测试经验
小程序的产品（依赖于微信&支付宝）
WEB/APP/小程序
冒烟测试：
开发把编写好的程序转给测试的时候，程序首先需要做的是针对转测的程序进行正常流程的测试，这个过程叫冒烟测试。
针对被测程序的正常流程的测试，目的是验证程序正常流程可以执行通的情况下继续测试被测程序的其他功能
探索性测试：
探索性强调测试⼈员的主观能动性，抛弃繁杂的测试计划和测试⽤例设计过程，强调在碰到问题时及时改变测试策略。
测试用例有哪些部分组成?
测试⽤例组成元素
⽤例ID；
⽤例名称；
测试⽬的；
测试级别；
参考信息；
测试环境；
前提条件；
测试步骤；
预期结果；
设计⼈员。
测试⽤例组成元素最核心的部分
⽤例名称；
前提条件；
测试步骤；
预期结果；
安全测试：
主要是针对被测软件进行安全的考虑，目前主要使用的技术是渗透测试。
回归测试：
产品都已经测试完成了，在准备上线的情况下，针对产品进行第N次的测试。回归测试目前主要是大量的自动测试来承担这部分的任务。
测试环境：
1、系统已有功能的测试（回归）
线上环境：
1、系统已有功能的测试
2、这对本次上线新功能的回归测试
第一天内容：
1、熟悉环境，熟悉身边的人，梳理清楚谁是你的负责人。
2、安装电脑的常用软件（java环境,Python环境,postman,jmeter,offer办公软件,思维导图软件,foxmail,git）
3、看需求文档
第二天的内容：
1、 继续看需求文档
看需求文档抓住核心的东西：
1、产品是给谁服务的？
2、产品的核心流程是什么？ 核心流程最好使用思维导图的模式把流程梳理出来
3、如果产品里面有专业术语（咨询产品或者是自己百度搜索）
4、梳理出产品哪些逻辑不是很清楚，梳理出来后，专门约产品经理或者是其他测试，让对方协助我们来讲解下这部分
三天：产品经理，身边的测试
toB:商家
toC:消费者
B2C商对客
为什么要需求分析
软件测试需求是设计测试⽤例的依据。
有助于保证测试的质量和进度
软件测试需求是衡量测试覆盖率的重要指标
软件测试需求分析步骤
列出需求⽂档中的具有可测性的原始需求
对每⼀条需求进⾏细化分解，形成可测试的分层描述的测试点
对形成的每⼀个测试点，从软件产品的质量需求来分析，确定测试执⾏时需要实施的测试类型。
建⽴测试需求跟踪矩阵，对测试需求进⾏管理
测试点分析
通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）
各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验
证内容（功能业务测试）
考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，⽐如界⾯的验证，异常情况
（界⾯、易⽤性、兼容性、安全性、性能）
测试⽤例步骤
拿到测试需求 -> 分析需求（画思维导图） -> 编写⽤例 -> 划分⽤例优先级
编写测试用例的三种方式：
1、思维导图 结构化看起来非常的好，但是不够细
2、使用excel，特点是写起来非常浪费时间，但是非常细
3、checklist 只考虑被测对象的大概的点
测试⽤例组成元素
⽤例ID；
⽤例名称；
测试⽬的；
测试级别；
参考信息；
测试环境；
前提条件；
测试步骤；
预期结果；
设计⼈员。
测试⽤例组成元素
⽤例名称；
前提条件；
测试步骤；
预期结果；
你之前测试用例写了多少个？
这个之前还真没有数过，我个人认为数这个没多大意义，更多应该考虑的是把测试的对象的测试点考虑周全
你对加班怎么看？假设我们每天需要加班到10点，你会接受吗？
环境：
1、测试环境：给测试使用的环境，指的是一个产品还没上线前测试的环境
2、预发布环境：介于测试环境与线上环境中间，但是它也是可以给客户使用的环境，一般不开放，只供研发内部人员使用
3、线上环境：给真实的用户使用的环境
标签：需求,产品,技巧,环境,程序,面试,测试,软件 来源： https://www.cnblogs.com/wrwangrong/p/16448444.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。