快捷键能否拍照(比如苹果的音量键)；拍照时是否自动对焦；按下快门照片是否自动保存；能否连拍；能否识别单张/多张人脸；非静音模式下按下快门是否有快门声；是否支持各种拍摄模式，如慢动作、连拍、人像模式、视频模式；延时拍摄的时间设置；是否支持触屏拍照；按下快门后能否预览；能否自定义默认拍摄的图片尺寸、滤镜；前置/后置摄像头拍摄出的图片质量是否与说明书一致。
参考这里
单例模式的定义就是确保某一个类只有一个实例，并且提供一个全局访问点。
单例模式具有典型的三个特点：只有一个实例；自我实例化；提供全局访问点。
优点：由于单例模式只生成了一个实例，所以能够节约系统资源，减少性能开销，提高系统效率，同时也能够严格控制客户对它的访问。
缺点：也正是因为系统中只有一个实例，这样就导致了单例类的职责过重，违背了“单一职责原则”，同时也没有抽象类，这样扩展起来有一定的困难。
常见的单例模式实现方式有五种：饿汉式、懒汉式、双重检测锁式、静态内部类式和枚举单例。而在这五种方式中饿汉式和懒汉式又最为常见。
饿汉式：线程安全，调用效率高。但是不能延时加载。示例：
由于该模式在加载类的时候对象就已经创建了，所以加载类的速度比较慢，但是获取对象的速度比较快，且是线程安全的。
懒汉式：线程不安全。示例：
由于该模式是在运行时加载对象的，所以加载类比较快，但是对象的获取速度相对较慢，且线程不安全。如果想要线程安全的话可以加上synchronized关键字，但是这样会付出惨重的效率代价。
懒汉式（双重同步锁）
双重检测锁补充：
为什么加了同步锁之后还需要二次判空？
因为如果不二次判空那么有可能会出现以下情况：
这样的话instance就会被初始化两次，所以在获取到锁后还需要进行二次判空。
测试流程
- 需求沟通 （确认自己对需求文档的理解是不是正确的，以及和产品、开发沟通）
- 制定测试方案
- 设计测试用例
- 准备测试环境
- 测试执行
- bug处理
- 回归验证
- 跟进上线
- 需求沟通（下一个版本的迭代）
测试用例主要有哪些元素？
软件测试有什么类型？
常见的软件测试类型有: 功能测试、性能测试、界面测试、兼容性测试、可靠性测试、安全性测试、压力测试、负载测试等
测试用例是什么？有什么作用？
测试用例就是设计一个特定场景，让软件在这种场景下运行，检验程序是否给出正确的结果，以此验证软件是否正确实现了客户需求。
作用：
- 避免盲目测试并提高测试效率，在软件版本更新之后只需修正少部分用例即可开展测试工作，降低工作强度，缩短测试周期；
- 可以分清哪些是测试重点，测试用例是测试工作的见证，能知道测试了哪些功能，没测哪些模块
- 测试用例是量化测试工作的方法之一
测试用例设计方法
- 等价类与边界值（重点方法）
：等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。等价类方法是一种重要的、常用的黑盒测试用例设计方法。
：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
- 场景法（重点方法）
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
- 因果图法
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
- 错误推测法
错误推测法是指在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。
这种方法没有固定的形式，依靠的是经验和直觉，很多时候，我们都会不知不觉的使用到。
测试阶段
按照测试的先后顺序可以分为 。
单元测试和集成测试由设计人员和程序员完成，系统测试由软件测试小组根据上面的三个基本步骤完成，验收测试由用户完成。
1. 什么是单元测试？
单元测试是对程序中的某个模块进行测试，也就是说一开始的时候不是对整个程序进行测试，而是先将注意力集中在构成整个程序的各个小单元的测试上。
单元测试的目的是开发人员确定这段子程序做了它应该做的事。
测试方法是白盒测试，使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。一般由开发人员编写一小段代码进行测试。
2. 什么是集成测试
集成测试通过测试发现与模块接口有关的问题。
集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。也就是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。
集成测试的目的旨在测试各个组件间是否能互相配合，正常工作。为了看代码是否按"设计或期望的方式"工作。
3. 什么是系统测试
系统测试是将经过测试的子系统装配成一个完整系统来测试。
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
3. 什么是验收测试
验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求，确保所开发的软件产品符合用户的各项要求。
。
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。
经过α测试调整的软件产品称为β版本。
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。
测试报告里面包含什么内容？
测试报告内容一般有：编写目的、系统简介、测试环境、测试方法和工具、测试执行结果与记录、缺陷汇总、遗留缺陷跟踪、测试用例执行情况、测试结论与建议等
- 可维护性（maintainability）
所谓“代码易维护”就是指，在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码。
- 可读性（readability）
我们在编写代码的时候，时刻要考虑到代码是否易读、易理解。除此之外，代码的可读性在非常大程度上会影响代码的可维护性。
看代码是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等。
code review 是一个很好的测验代码可读性的手段
- 可扩展性（extensibility）
它表示我们的代码应对未来需求变化的能力。跟可读性一样，代码是否易扩展也很大程度上决定代码是否易维护.
代码的可扩展性表示，我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码
- 灵活性（flexibility）
如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得比较灵活
- 简洁性（simplicity）
KISS 原则:尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护.
- 可复用性（reusability）
代码的可复用性可以简单地理解为，尽量减少重复代码的编写，复用已有的代码
- 可测试性（testability）
代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题
时间复杂度是指执行这个算法所需要的计算工作量；
而空间复杂度是指执行这个算法所需要的内存空间。
功能测试
- 输入关键字，查看: 返回结果是否准确，返回的文本长度需限制
1.1输入可查到结果的正常关键字、词、语句，检索到的内容、链接正确性；
1.2输入不可查到结果的关键字、词、语句；
1.3输入一些特殊的内容，如空、特殊符、标点符、极限值等，可引入等价类划分的方法等； - 结果显示：标题，卖家，销售量，单行/多行，是否有图片
- 结果排序：价格 销量 评价 综合
- 返回结果庞大时，限制第一页的现实量，需支持翻页
- 多选项搜索：关键字 品牌 产地 价格区间 是否天猫 是否全国购
- 是否支持模糊搜索，支持通配符的查询
- 网速慢的情况下的搜索
- 搜索结果为空的情况
- 未登录情况和登录情况下的搜索（登录情况下 存储用户搜索的关键字/搜索习惯）
性能测试
- 压力测试：在不同发用户数压力下的表现（评价指标如响应时间等）
- 负载测试：看极限能承载多大的用户量同时正常使用
- 稳定性测试：常规压力下能保持多久持续稳定运行
- 内存测试：有无内存泄漏现象
- 大数据量测试：如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来，看表现如何等等。
界面/易用性: 交互界面的设计是否便于、易于使用
- 依据不同的查询结果会有相关的人性化提示，查不到时告知？查到时统计条数并告知？有疑似输入条件错误时提示可能正确的输入项等等处理
- 查询出的结果罗列有序，如按点击率或其他排序规则，确保每次查询出的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等
- 标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格间格开）等实用的检索方式是否正常？
- 输入搜索条件的控件风格设计、位置摆放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化设计？
兼容性
- WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用
- IE/FIREFOX/GOOGLE/360/QQ等各类浏览器下及各版本条件下、各种显示分辨率条件下的应用
- SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试
- 简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
- IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试
- 与各相关的监控程序的兼容性测试，如输入法、杀毒、监控、防火墙等工具同时使用
安全性
- 被删除、加密、授权的数据，不允许被SQL注入等攻击方式查出来的，是否有安全控制设计
- 录入一些数据库查询的保留字符，如单引号、%等等，造成查询SQL拼接出的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等
- 通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患
- 对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制
分析：什么样的问题才是一个缺陷，需要从客户需求出发。
- 软件未实现需求规格说明书中的要求；
- 出现需求规格说明书中指明不应该出现的错误
- 软件未实现需求文档中虽未明确提及但应该实现的功能；（如：账密加密）
- 软件出现难以理解、不易使用或者运行速度慢等问题都可以认为是软件缺陷
首先还是应该回归到客户需求上面，确认这个问题到底属不属于一个缺陷，如果确实是则要和开发同事解释清楚；如果开发还是坚持自己想法的话，则询问同事或者测试组长的意见，讨论这个问题到底属不属于缺陷问题，如果大家都觉得是则需要和开发解释清楚。
测试开发首先离不开测试，而软件测试是指，使用人工或自动的方式来运行某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
测开：主要是会承担一些开发的工作，用来制作一些自动化测试的脚本，或者自动化测试的工具，又或者另外的一些在软件测试工作中用到的提高工作效率的小工具什么的。
首先，在近几年，国内对软件测试越来越重视，测试的前景是非常好的。
其次，从学生会经历、自己追求完美的性格分析，适合做测试。
最后，并不是说测试比开发难度小，其实测试更需要有全局观念，一个好的测试工程师，必须对代码的理解要足够深刻，才能从中找出缺陷。
- 具备扎实的专业知识和良好的测试基础理论
- 首先要有一定的沟通协调能力，因为测试人员经常会与开发、产品、售后售前沟通
- 还需要有一定的耐心、细心，不能放过每一个错误
- 要有责任感，要尽自己最大的能力，保证产品的质量
- 要有好奇心，保持一种怀疑的态度，测试人员的任务是找出缺陷，不是证明没有缺陷，所以需要保持怀疑
1.功能测试
（1）水倒水杯容量的一半
（2）水倒规定的安全线
（3）水倒满且流出来
（4）水杯容量刻度与其他水杯一致
（5）盖子拧紧水倒不出来
（6）烫手验证
（7）是否保温
2.性能测试
（1）使用最大次数或时间
（2）掉地上不易损坏
（3）盖子拧到什么程度水倒不出来
（4）保温时间长
（5）杯子的耐热性
（6）杯子的耐寒性
（7）长时间放置水不会漏
（8）杯子上放置重物达到什么程度杯子会被损坏
3.界面测试
（1）外观完整、美观
（2）大小与设计一样（高、宽、容量、直径）
（3）拿着舒服
（4）材质与设计一样
（5）杯子上的图案掉落
（6）图案遇水溶解
4.安全测试
（1）杯子使用的材质毒或细菌的验证
（2）高温材质释放毒性
（3）低温材质释放毒性
5.易用性测试
（1）倒水方便
（2）喝水方便
（3）携带方便
（4）使用简单，容易操作
（5）防滑措施
6.兼容性
（1）杯子能够容纳果汁、白水、酒精、汽油等。
7.震动测试
（1）杯子加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。
8.可移植性
（1）杯子在不同地方、温度环境下都可以正常使用。
1.功能测试
1、电梯内各楼层键是否正常
2、电梯内开关门键是否正常
3、电梯内的报警键是否正常使用
4、电梯外的上下键是否正常
5、同时关注电梯内外的显示屏显示的电梯层数和运行方向
6、有障碍物时，电梯门的感应系统的有效情况
2.性能测试
1、测试电梯负载单人时的运行情况（基准测试）
2、测试电梯承载多人时的运行情况（负载测试）
3、测试电梯在承载一定人数下较长时间的运作（稳定性测试）
4、测试电梯在更长时间运作时的运行情况（疲劳测试）
5、测试不断增加电梯内的人数导致电梯报警情况（拐点压力测试）
3.界面测试
1、查看电梯的外观
2、查看按钮的图标显示，大小
3、查看电梯内部张贴的说明（比如报警装置的说明、称重量等）
4.易用性测试
1、楼层按键高度（小孩和一些身高矮的用户会按键不方便）
2、楼层按键上是否有盲文显示
3、电梯是否有地毯、夏天是否有空调、通风条件、照明条件、手机信号是否通畅
3、电梯是否有扶手，是否有专针对残疾人的扶手等等
5.安全性测试
1、下坠时是否有制动装置
2、暴力破坏电梯时是否报警
3、超重是否报警
4、超时是否自动开门
5、火灾报警后，是否允许就近停靠
6、停电情况下，电梯是否有应急电源装置
6.兼容性测试
1、电梯的整体和其他设备的兼容性，与大楼的兼容，与海底隧道的兼容等等
2、不同类型的电压是否兼容
7.验收测试
1.大量用户从1楼上电梯，去向不同的楼层的情况。
2.大家从不同的楼层上电梯，一起到一楼的情况。
更细心，更有耐心，这也是作为测试人员 应该具备的
沟通能力强，学生会经历、社团经历培养了自己积极主动与他人沟通的能力，并且能对事件进行清楚的描述
需求评审通常是由产品经理主持，通过讲解产品需求文档，让相关人员了解具体需求，并提出疑问，进行沟通的过程。
- 注意对需求规格说明的正确性进行评审
1、是否有需求与其他需求相互冲突或者重复？
2、是否清晰、简洁、无二义地表达了每个需求?
“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致 。
3、是否每个需求都通过了演示、测试、评审，分析是否得到了验证?
4、是否每个需求都在项目的范围内?
5、是否每个需求都没有内容和语法上的错误?
6、在现有的资源内, 是否能实现所有的需求?
7、每一条特定的错误信息，是否都是唯一的和具有含义的? - 注意对需求规格说明的实践性进行评审
- 注意对需求规格说明的完整性进行评审
1、编写的所有需求，其详细程度是否一致和合适?
2、需求是否能为设计提供足够的基础?
3、所有对其他需求的内部引用是否正确?
4、是否包含了每个需求的实现优先级?
5、是否定义了功能说明的内在算法?
6、是否包含了所有已知的客户需求或系统需求?
7、是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?
8、是否对所有预期的错误条件所产生的系统行为都编制了文档? - 注意对需求方案的可行性和成本预算进行评审
- 注意对需求的质量属性进行评审
- 等等…
许多公司虽然执行了技术评审，但却未能从中获益，这往往是因为以下的原因导致的：
没有评审计划，没有充分的准备
专家选择不合适
评审会议偏离主题和重点，过多争论占用大量时间
没有使用Checklist作为指导
问题修改后跟踪不力……
常见的技术评审包括了走查（Walkthrough）、轮查（Pass Around）、正式的同行评审（Peer Reviews）等。
走查（Walkthrough）：是大名鼎鼎的面向对象方法学的开发者之一Yourdon 定义的方法，它由作者启动和主持评审，作者向评审者展示文档。优点是启动快，成本低，缺点是容易被作者误导过程。
轮查（Pass Around）：作者向评审者作简要介绍，但不参加评审过程；评审者独立进行评审，并记录发现结果、准备报告。
同行评审：评审者与作者是地位平等的同行/专家，而不是领导对员工的评价；是最为结构化的评审方法；可以作为同行之间学习和分享经验的机会。
1.功能测试
1、使用USB接口多次拔插看是否能够识别
2、关机情况下拔插能否正常充电
3、开机情况下拔插能否正常充电
4、手机通过USB接口与电脑连接能否实现数据传输
5、手机通过USB接口与电脑连接能否实现只充电
6、手机通过USB接口与电脑连接后 手机向电脑传输数据时断开连接，数据中断传输
7、手机通过USB接口与电脑连接后 电脑向手机传输数据时断开连接，数据中断传输
8、持续一小时传输数据
9、在播放视频、音频时拔插
2.性能测试
1、防水性
2、耐热性
3、长时间传输数据
4、同时传输大量数据
3.界面测试
1、长度是否合理
4.安全性测试
1、是否漏电
字节数与系统多少位有关，比如32位，64位。
在64位系统中Java基本类型占用的字节数：
1字节： byte , boolean
2字节： short , char
4字节： int , float
8字节： long , double
1、“+”号操作符
2、StringBuilder的append()方法
3、StringBuffer的append()方法
4、String类的concat() 方法
5、String 类的 join 方法
修饰方法，
修饰变量，
修饰代码块 类加载的时候只被执行一次
在虚拟机执行到monitorenter指令的时候，会请求获取对象的monitor锁，基于monitor锁又衍生出一个锁计数器的概念。
当执行monitorenter时，若对象未被锁定时，或者当前线程已经拥有了此对象的monitor锁，则锁计数器+1，该线程获取该对象锁。
当执行monitorexit时，锁计数器-1，当计数器为0时，此对象锁就被释放了。
那么其他阻塞的线程则可以请求获取该monitor锁。
Error是程序无法处理的错误，表示运行应用程序中较严重问题。Error出现时，除了使程序终止外，没有其他选择
Exception有编译时异常和运行时异常。
运行时异常：都是RuntimeException类及其子类异常，如NullPointerException、IndexOutOfBoundsException。这些异常是不检查异常，程序中可以选择捕获处理，也可以不处理。
编译时异常：是RuntimeException以外的异常，类型上都属于Exception类及其子类。从程序语法角度讲是必须进行处理的异常，如果不处理，程序就不能编译通过。如IOException、SQLException等以及用户自定义的Exception异常，一般情况下不自定义检查异常。
悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿掉锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
“具体的发展方向，还需要公司的发展方向去调整”
软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序错误的过程。
测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现。
测试设计是否符合全部需求以及设计是否合理。
α测试是属于验收测试吧…
Alpha测试(α测试)是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块(子系统)测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。
β测试是属于验收测试吧…
Beta测试(β测试)是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。
只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有：1. 保证一个模块中的所有独立路径至少被测试一次；2. 所有逻辑值均需要测试真（true）和假（false）；两种情况；3. 检查程序的内部数据结构，保证其结构的有效性；4. 在上下边界及可操作范围内运行所有循环。
白盒测试六种方法：
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。 六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
通过运行程序测试软件称为动态测试。在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.
通过评审需求文档、阅读代码等方式测试软件称为静态测试。
回归测试的目的是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。
说白了就是，我们测试人员在对程序进行测试时发现bug，然后返还程序员修改，程序员修改后发布新的软件包或新的软件补丁包给我们测试人员，我们就要重新对这个程序测试，已保证程序在修正了以前bug的情况下，正常运行，且不会带来新的错误的这样一个过程。 一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。
软件缺陷的等级可以用严重性和优先级来描述
严重性：衡量缺陷对客户满意度影响的满意程度，分为
- 致命错误，可能导致本模块以及其他相关的模块异常，死机等问题；
- 严重错误，问题局限在本模块，导致模块功能失常或异常退出；
- 一般错误，模块功能部分失效；
- 建议模块，有问题提出人对测试模块的改进建议
优先级：缺陷被修复的紧急程度；
- 立即解决（P1级）：缺陷导致系统功能几乎不能使用或者测试不能继续，需立即修复；
- 高优先级（P2级）：缺陷严重，影响测试，需优先考虑；
- 正常排队（P3级）：缺陷需要正常排队等待修复；
- 低优先级（P4级）：缺陷可以在有时间的时候被纠正
白盒测试、黑盒测试
需要的知识：
软件测试基础理论知识，如黑盒测试、白盒测试等；
考编程语言基础，如C/C++、java、python等；
自动化测试工具，如Selenium、Appium、Robotium等；
计算机基础知识，如数据库、Linux、计算机网络等；
测试框架，如JUnit等。
需要具备的能力：
业务分析能力，分析整体业务流程、分析被测业务数据、分析被测系统架构、分析被测业务模块、分析测试所需资源、分析测试完成目标；
缺陷洞察能力，一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；
团队协作能力，合理进行人员分工、协助组员解决问题、配合完成测试任务、配合开发重现缺陷、督促项目整体进度、出现问题勇于承担；
专业技术能力，掌握测试基础知识、掌握计算机知识、熟练运用测试工具；
逻辑思考能力，判断逻辑的正确性、对可行性逻辑分析、站在客观角度思考；
问题解决能力，技术上的问题、工作中的问题、沟通问题；
沟通表达能力，和技术人员、产品人员、上下级的沟通；
宏观把控能力，有效控制测试时间、有效控制测试成本、有效制定测试计划、有效进行风险评估、有效控制测试方向。
黑盒测试方法有 等价类划分，边界值分析，错误推测，因果图法
白盒测试方法有逻辑覆盖法，程序插桩技术，基本路径法，符号测试，错误驱动测试
测试是软件开发中不可或缺的一环，测试通过经济，高效的方法，捕捉软件中的错误，从而达到保重软件内在质量的目的。
测试分为功能测试和非功能测试，非功能测试又可以分为性能测试、压力测试、容量测试、健壮性测试、安全性测试、可靠性测试、恢复性测试、备份测试、协议测试、兼容性测试、可用性测试、配置测试、GUI测试。
测试方法用过等价划分法、边值分析法、错误推测法、因果图法。
协议测试包括四种类型的测试
1、一致性测试：检测协议实现本身与协议规范的符合程度
2、互操作性测试：基于某一协议检测不同协议实现间互操作互通信的能力
3、性能测试：检测协议实现的性能指标，比如数据传输速度，连接时间，执行速度，吞吐量，并发度
4、健壮性测试：检测协议是现在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断