黑盒测试
就是把被测试的程序看成一个黑色的盒子，看不到里面内部的结构，对应的是系统测试，是功能测试的一种形式。黑盒测试用到的测试用例的设计方法为：等价分类、因果图、错误推测法、边界
值。
2.2.2白盒测试
被测程序看成一个白色的盒子，能够看见程序内部的结构，对应的是单元测试。针对程序判断逻辑，判断分支，判断循环，程序流程走向的测试。白盒测试是一种高技能的测试。对测试的技术水
平要求是比较高的。
2.2.3灰盒测试
介于白盒测试和黑盒测试之间，它对测试的要求是：能够参与开发代码的评审，以及开发代码的检查，互联网公司基本都是灰盒测试。
2.3按编写代码分类
2.3.1手工测试
就是由人去一个一个的输入测试用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。手工测试又叫功能测试，或者说是业务测试。它的特点主要为: 优点:自动化测试是
无法替代人的测试的行为模式的，也无法替代探索性的测试。 缺点:执行效率慢，影响测试交付的效率。
2.3.2自动化测试
就是通过编写代码(使用工具)的方式来替代模拟人的一种行为方式来对系统进行的一种测试。自动化测试又分为UI自动化测试、API自动化测试、性能自动化测试。一般性说的自动化测试大多数时
候指的是UI自动化测试和API自动化测试。
3、软件的质量
3.1软件质量六大特性
描述当前软件是否好用，在当前的软件行业里我们所采用的一套标准是基于ISO组织制定的。需要我们记忆的就是软件质量的六大特性：
（1）功能性：软件需要满足用户显式或者稳式的功能。
（2）易用性：软件易于学习和上手使用。
（3）可靠性：指的就是软件必须实现需求当中指明的具体功能。
（4）效率性：类似于软件的性能。
（5）可维护性：要求软件具有将某个功能修复之后继续使用的能⼒。
（6）可移植性：当前软件可以从⼀个平台移植到另⼀个平台上去使用的能⼒。
三大主流平台：windows、unix、linux
测试开发四大主流领域
1、服务端测试开发
2、算法测试开发
（1）队列 ：先进先出
（2）堆栈 ：先进后出
3、大数据测试开发
4、移动专项测试开发
数据类型
1、int：整形数字
2、str：字符串
3、float：带小数点的数字
4、bool：布尔，判断语句，true/flase
5、表达式：<、=、 >、 &&（并且）、||（或者）、++（现有基础上加1）、 -- （现有的基础上减去1）
4、测试概述
4.1软件分类
中间件
（1）缓存中间件：Redis、MemCached
（2）MQ中间件：Kafka、 RabbitMQ
windows常用命令
1、ipconfig:查询IP的地址。
2、cmd:win+R，输入cmd，就可以打开控制台。
3、dir:展示当前目录下的文件和文件夹。
4、cd d:/ :进入到了D盘 。输入步骤为：
（1）cd d:/
（2）d: cd 文件名XX（进入d盘的XX文件中）
5、pwd:查询当前的在那个盘下。
4.2测试术语
4.2.1冒烟测试
1、目的：确认软件基本功能正常。
2、使用场景：开发转测后，测试要进行冒烟测试 ，验证被转测的软件基本流程是否正常。
4.2.2探索性测试
1、定义：可以说是一种测试思维技术，探索性强调测试人员的主观能动性。抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
2、使用场景：测试报告已经完成，要准备上线前，对产品进行探索性的测试。
4.2.3安全测试
目前安全测试更多的聚焦于渗透测试这部分。
4.2.4回归测试
1、定义：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
2、自动回归测试：自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
3、回归测试的三个场景
（1）转测后即测试阶段，对系统已有功能进行回归测试。
（2）上线前即系统测试，开发对代码进行了合并，需要对系统整体的进行回归测试。
（3）上线后即线上环境，对产品进行整体的回归测试。
4.3如何做软件测试需求分析
4.3.1为什么要需求分析
（1）软件测试需求是设计测试用例的依据。
（2）有助于保证测试的质量和进度。
（3）软件测试需求是衡量测试覆盖率的重要指标。
4.3.2分析需求测试要做什么
（1）梳理业务逻辑，了解本次迭代的要做什么？
（2）本次迭代功能是否影响之前的功能？
（3）提出疑问点？
4.3.3软件测试需求分析步骤
可以用思维导图来梳理需求文档。
（1）列出需求文档中的具有可测性的原始需求。
（2）对每一条需求进行细化分解，形成可测试的分层描述的测试点。
（3）对形成的每一个测试点，从软件产品的质量需求来分析，确定测试执行时需要实施的测试类型。
（4）建立测试需求跟踪矩阵，对测试需求进行管理。
4.3.4需求分析主要目的
获取测试点，根据测试点来编写测试用例。
4.3.5测试点的分析
（1）输入输出：通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）；
（2）逻辑处理：各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试）；
（3）业务场景：考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，⽐如界⾯的验证，异常情况（界⾯、易⽤性、兼容性、安全性、性能）。
4.3.6测试需求理解偏差相关方影响
解决方案：
1、逻辑不清晰，找开发同学多讨论；
2、开发与测试意见不一致的情况下，找产品经理；
3、产品的逻辑不合理，找产品经理，同时找开发同学，统一意见。
标签：需求,4.3,理论,开发,测试,自动化,软件 来源： https://www.cnblogs.com/wu199916/p/16452061.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。