软件测试面试题及答案,软件测试面试高频题和答案

需求分析、编写测试用例、评审测试用例、搭建环境、等待程序开发包、部署程序开发包、冒烟测试、执行具体的测试用例细节、Bug 跟踪处理回归测试、N 轮之后满足需求，测试结束

第一类标准：测试超过了预定时间，则停止测试。

第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。

第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础

第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订数目的故障。

第五类标准：根据单位时间内查出故障的数量决定是否停止测试

1) 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

2) 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。

3) 程序员应避免检查自己的程序。

4) 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。

5) 软件测试的原则

6) 充分注意测试中的群集现象。 经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。

7) 严格执行测试计划，排除测试的随意性。

8) 应当对每一个测试结果做全面检查。

9) 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例的基本元素： 测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

首先根据需求文档、概要设计、测试计划、测试方案细分出各功能模块的测试项

再根据各测试项，按照概要设计、详细设计以及测试方案中测试的覆盖率细分出测试子项

最后按照测试子项、根据测试用例的设计方法（因果图、边界值、等价类等的设计方法）书写测试用例。

注意

• 选用适合的用例管理工具（如 word，excel）
• 用例一定要及时更新（补充新的想法，删除过时的需求）
• 做好用例分级
• 做好用例评审，写用例之前可以征询相关人员的意见，如果评审通过可以参考其执行测试，如果未通过， 需要继续修改直到通过为止。
• 可以考虑结对编写，这个是不错的主意
• 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等
• 注意把握适当的颗粒度

质量属性：

• 正确性：确保测试标题描述部分的内容正确性。
• 经济性：只为确定需要的目的设计相应的测试步骤。
• 可重复性：自我一致性，即不管谁执行此用例，结果一样。
• 适应性：既能适应短期需要，又能考虑长远需要。
• 可追踪性：用例能追踪到一个具体的需求。
• 自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。

结构化和可测试性

• 含有规范的测试标题和编号。
• 含有一个确定的测试某一个特定需求的目的。
• 含有关于测试方法的描述。
• 指定条件信息-环境、数据、预置的条件测试、安全入口等。
• 含有操作步骤和预期结果。
• 陈述任何辅助证据，例如截图报告并确保这些东西妥善保存。
• 确保测试环境的干净（即用例不会影响整个环境）。
• 描述时使用主动语气结构。
• 操作步骤不要超过 15 步。
• 确保单个用例测试执行时用时不超过 20 分钟。
• 自动化脚本用例添加必要的注释，比如目的、输入和期望结果。
• 如果可能，建议提供可选择性的预置条件测试。
• 用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。

配置管理：

• 采用命名和编号规范归档。
• 保存为特定的格式，文件类型。
• 用例版本是否与当前被测试软件版本一致（对应）。
• 包含用例需要的相应测试对象，如特定数据库。
• 存档阅读。
• 存档时按角色控制访问方式
• 当网络备份时存档。
• 离线归档

1、复用率：如果随着产品不停得升级，需要设计的详细些，追求一劳永逸；仅使用一两次，则没有必要设计的过于详细；

2、项目进展：项目时间如果允许可以设计的详细些，反之则能执行即可；

3、使用对象：测试用例如果供多人使用，尤其让后参加测试的工程师来执行，则需要设计的详细些。

4、用例的冗余

5、操作步骤要细分简明，可执行

1、一个详细合理的详细的测试计划

2、测试尽早的介入项目，连接项目的业务需求，做好测试的前期准备

3、对测试项目前景充满信心，调整最佳心态，保持愉悦的工作心情

4、提高测试接受的标准，减少测试版本的送测次数

1、需求评审

2、梳理需求，尽早与开发人员、需求人员进行需求确认，统一不同角色对需求的认识

3、用例设计及评审

4、测试执行

5、bug 回归

6、发布前的功能回归

1、等价类划分法

2、边界值分析法

3、错误推断法

4、因果图判定表法

5、正交实验法

6、流程法

7、场景法

1、深入了解需求的过程

2、测试执行的指导

3、规划测试数据的准备

4、反应测试进度

5、举一反三发现隐藏缺陷

6、分析缺陷标准

(1)缺陷报告是描述软件缺陷现象和重现步骤的集合。软件缺陷报告 Software Bug Report(SBR)或软件问题报告 software Problem Report(SPR)。

(2)缺陷报告是软件测试人员的工作成果之一，体现软件测试的价值缺陷报告可以把软件存在的缺陷准确的描述

出来，便于开发人员修正缺陷报告可以反映项目/产品当前的质量状态，便于项目整体进度和质量控制软件测试缺陷

报告是软件测试的输出成果之一，可以衡量测试人员的工作能力。

(3)标题(Title)简洁、准确、完整、反映缺陷本质、方便查询前缀 标题正文，标题正文采用结果和动作，或者现象和位置的方式表达；步骤(Steps)可复现、完整、简洁、准确按数字编号；实际结果(Actual results)准确、详细描述软件的现象和特征；期望结果(Expected results)准确、丰富、有理有据；平台(Platforms)准确；截图 (Sereenshots)准确反映缺陷特征；注释(Notes)关于缺陷的辅助说明

Correct（准确）：每个组成部分的描述准确，不会引起误解；

Clear（清晰）：每个组成部分的描述清晰，易于理解；

Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；

Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；

Consistent（一致）：按照一致的格式书写全部缺陷报告。

1、深入了解需求的过程

2、测试执行的指导

3、规划测试数据的准备

4、反应测试进度

5、举一反三发现隐藏缺陷

6、分析缺陷标准

(1)缺陷报告是描述软件缺陷现象和重现步骤的集合。软件缺陷报告 Software Bug Report(SBR)或软件问题报

告 software Problem Report(SPR)。

(2)缺陷报告是软件测试人员的工作成果之一，体现软件测试的价值缺陷报告可以把软件存在的缺陷准确的描述

出来，便于开发人员修正缺陷报告可以反映项目/产品当前的质量状态，便于项目整体进度和质量控制软件测试缺陷

报告是软件测试的输出成果之一，可以衡量测试人员的工作能力。

(3)标题(Title)简洁、准确、完整、反映缺陷本质、方便查询前缀 标题正文，标题正文采用结果和动作，或者

现象和位置的方式表达；步骤(Steps)可复现、完整、简洁、准确按数字编号；实际结果(Actual results)准确、详

细描述软件的现象和特征；期望结果(Expected results)准确、丰富、有理有据；平台(Platforms)准确；截图

(Sereenshots)准确反映缺陷特征；注释(Notes)关于缺陷的辅助说明

Correct（准确）：每个组成部分的描述准确，不会引起误解；

Clear（清晰）：每个组成部分的描述清晰，易于理解；

Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；

Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；

Consistent（一致）：按照一致的格式书写全部缺陷报告。

测试人员提交新的 Bug 入库，错误状态为 New。

高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为 Open。如果不是错误，则拒绝，设置为 Declined(拒绝)状态。

开发人员查询状态为 Open 的 Bug， 如果不是错误，则置状态为 Declined；如果是 Bug 则修复并置状态为 Fixed。不能解决的 Bug，要留下文字说明及保持 Bug 为 Open 状态。对于不能解决和延期解决的 Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。 测试人员查询状态为 Fixed 的 Bug，然后验证 Bug 是否已解决，如解决置 Bug 的状态为 Closed，如没有解决置状态为 Reopen。

缺陷的标题，简要描述。缺陷的类型。缺陷的详细步骤描述。缺陷的实际结果。期望结果。有的缺陷需要上传

截图，日志信息。缺陷的等级。缺陷指派给开发同事。（开发主管）

通用 UI 要统一、准确；尽量使用业界惯用的表达术语和表达方法；使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化；每条缺陷报告只包括一个缺陷；不可重现的缺陷也要报告；明确指明缺陷类型；明确指明缺陷严重等级和优先等级；描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置；

短行之间使用自动数字序号，使用相同的字体、字号、行间距； 每一个步骤尽量只记录一个操作；确认步骤完整，准确，简短；根据缺陷，可选择是否进行图象捕捉； 检查拼写和语法缺陷；尽量使用短语和短句，避免复杂句型句式；缺陷描述内容。

a)首先，将问题提交到缺陷管理库里面进行备案。

b)然后，要获取判断的依据和标准：

• v.根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
• vi.如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
• vii.根据用户的一般使用习惯，来确认是否是缺陷；
• viii.与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

c)合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不掺杂个人情绪。

d)等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级 做出决定。

一般来说按照下面的来分，具体的是由每个公司而定。

软件缺陷有四种级别，分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小的(Minor)。

A 类—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误， 未考虑异常操作，功能错误等

B 类—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。

问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、 缺省值未加完整性等约束条件

C 类—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等

D 类—较小错误的软件缺陷（Minor）

:使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、 界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚

E 类- 建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质 疑。

1.一个有广告的纸杯子，请设计测试用例？

测试项目：杯子

需求测试：查看杯子使用说明书

界面测试：查看杯子外观

功能度：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放 24 小时检查泄漏时间和情况；盛上汽油（案例二）放 24 小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损

震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输

基本功能测试（逻辑功能测试）。

（1）硬度：是否达到设计标准。

装载能力：在杯子内分别装入少量的、半杯的、满杯的，看其装载量是否达到设计标准。

装载种类：开水（是否产生异味）、温水、冷水、冰水、咖啡...

（2）界面测试（UI 测试）。

看其形状、大小设计是否适合人方便拿起。

外观是否吸引人（广告嘛），赏心悦目。

带广告的图案沾水受是否掉色、模糊。

（3）易用性测试。

看其形状、大小设计是否适合人方便拿起。

残疾人士用此杯去喝水的容程度。

杯子设计是否上大下小，在运输过程中可以套在一起有效利用空间，在使用时也容易拿开。

（4）稳定性测试（24 X 7 测试）。装入液体后记录其多少以后漏水。

（5）安全性测试。杯子所用的材料（包括纸基、涂层和广告颜料）是否符合食品卫生标准，在内外温度等环境

因素下是否会与所盛各种饮料相反应，而产生对人体有害的物质。

（6）本地化测试。为国际化和本地化的需要，广告图案和文字是否在政治、宗教和文化方面具有广泛的适用性。

（7）对设计的改进建议。“如果是一次性杯子，能否标示已使用（比如变色）”和“杯子是否有使用者标贴（多 人使用时防止混淆）”。

校验身份证号规则的有效性（包括地址码、生日期码、顺序码和校验码

校验 15 位身份证号和 18 位身份正好都是可用的

校验末位是 X 的情况

校验不足 15 位、16-17 位和大于 18 位的情况

如果是必输项，校验不输入的时候会不会有正确的提示

如果不是必输项，则要校验不输入的时候流程能否正常进行

校验输入非数字的情况，是否会有正确提示信息（包括大小写字母、汉字、特殊字符和标点符号）

校验输入全角的数字的时候，系统是否会识别（这个得根据需求确定是否可以使用全角的数字）

具体需求：

有一个登录页面，有一个账号和一个密码输入框, 一个提交按钮。

此题的考察目的：

1、了解需求（测什么都是从了解需求开始）；

2、是否有设计 Test Case 的能力

3、是否熟悉各种测试方法；

4、是否有丰富的 Web 测试经验；

5、是否了解 Web 开发；

了解需求：

1、登录界面应该是弹出窗口式的，还是直接在网页里面；

2、账号长度和密码的强度（比如需要多少位、大小写敏感、特殊字符混搭等）；

3、界面美观是否有特殊要求？（即是否要进行 UI 测试）；

4、····

用例设计：

测试需求分析完成后，开始用例设计，主要可以从以下几个方面考虑：

功能测试(Function Test)

1、输入正确的账号和密码，点击提交按钮，验证是否能正确登录。（正常输入）

2、输入错误的账号或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）

3、登录成功后能否跳转到正确的页面（低）

4、账号和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）

5、账号和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）

6、记住账号的功能

7、登录失败后，不能记录密码的功能

8、账号和密码前后有空格的处理

9、密码是否加密显示（星号圆点等）

10、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按 钮是否好用

11、登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确

12、输入密码的时候，大写键盘开启的时候要有提示信息。

13、什么都不输入，点击提交按钮，看提示信息。（非空检查）

界面测试(UI Test)

1、布局是否合理，2 个 Testbox 和一个按钮是否对齐

2、Testbox 和按钮的长度，高度是否符合要求

3、界面的设计风格是否与 UI 的设计风格统一

4、界面中的文字简洁易懂，没有错别字。

性能测试(Performance Test)

1、打开登录页面，需要几秒

2 、输入正确的账号和密码后，登录成功跳转到新页面，不超过 5 秒

安全性测试(Security Test)

1、登录成功后生成的 Cookie 是否有 HttpOnly(降低脚本盗取风险)

2、账号和密码是否通过加密的方式，发送给 Web 服务器

3、账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用 javaScript 验证

4、账号和密码的输入框，应该屏蔽 SQL 注入攻击

5、账号和密码的输入框，应该禁止输入脚本（防止 XSS 攻击）

6、错误登录的次数限制（防止暴力破解）

7、考虑是否支持多用户在同一机器上登录；

8、考虑一用户在多台机器上登录

可用性测试(Usability Test)

1、是否可以全用键盘操作，是否有快捷键

2、输入账号，密码后按回车，是否可以登录

3、输入框是否可以以 Tab 键切换

兼容性测试（Compatibility Test）

1、主流的浏览器下能否显示正常已经功能正常（IE6~11, FireFox, Chrome, Safari 等 ）

2、不同的平台是否能正常工作，比如 Windows, Mac

3、移动设备上是否正常工作，比如 iphone, Android

4、不同的分辨率

本地化测试 （Localization Test）

1、不同语言环境下，页面的显示是否正确。

软件辅助性测试 （Accessibility Test）

软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能

1、高对比度下能否显示正常（视力不好的人使用）

单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。

根据两者载体不一样，则区别如下：

系统结构方面

web 项目，b/s 架构，基于浏览器的；web 测试只要更新了服务器端，客户端就会同步会更新。

app 项目，c/s 结构的，必须要有客户端；app 修改了服务端，则客户端用户所有核心版本都需要进行回归

测试一遍。

性能方面

web 项目

需监测 响应时间、CPU、Memory

app 项目

除了监测 响应时间、CPU、Memory 外，还需监测 流量、电量等

兼容方面

（1）web 项目：

1. 浏览器（火狐、谷歌、IE 等）

2. 操作系统（Windows7、Windows10、Linux 等）

（2）app 项目：

1. 设备系统:iOS（ipad、iphone）、Android（三星、华为、联想等） 、Windows（Win7、Win8）、 OSX（Mac）

2. 手机设备可根据 手机型号、分辨率不同

相对于 Wed 项目，APP 有专项测试

1. 干扰测试：中断，来电，短信，关机，重启等

2. 弱网络测试（模拟 2g、3g、4g，wifi 网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g 切换到 4g/wifi 等）

3. 安装、更新、卸载

安装：需考虑安装时的中断、弱网、安装后删除安装文件等情况

卸载：需考虑 卸载后是否删除 app 相关的文件

更新：分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新
4. 界面操作：关于手机端测试，需注意手势，横竖屏切换，多点触控，前后台切换

5. 安全测试：安装包是否可反编译代码、安装包是否签名、权限设置，例如访问通讯录等

6. 边界测试：可用存储空间少、没有 SD 卡/双 SD 卡、飞行模式、系统时间有误、第三方依赖（QQ、微信 登录）等

7. 权限测试：设置某个 App 是否可以获取该权限，例如是否可访问通讯录、相册、照相机等

测试工具方面

自动化工具：APP 一般使用 Appium; Web 一般使用 Selenium

性能测试工具：APP 一般使用 JMeter; Web 一般使用 LR、JMeter

客户端安装测试

客户端升级测试

客户端可维护性测试

（1）个体的客户端应用以“分离的”模式被测试——不考虑服务器和底层网络的运行；

（2）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；

（3）完整的 C/S 体系结构，包括网络运行和性能被测试。

应用功能测试——客户端应用被独立地执行，以揭示在其运行中的错误。

服务器测试——测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。

数据库测试——测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地 存储、更新和检索。

事务测试——创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。

网络通信测试——这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的 发生

如果给你一台电梯，请问你如何测试它，分析如下：

1.功能：上升、下降、停止、开门、关门、梯内电话、灯光、指示灯等；

2.性能：速度、反应时间、关门时间等；

3.压力：超载、尖锐物碰撞电梯壁等；

4.安全：停电、报警装置、轿箱停靠位置、有人扒门时的情况等；

5.可用性：按键高度、操作是否方便、舒适程度等；

6.UI：美观程度、光滑程度、形状、质感等；

7.稳定性：长时间运行情况等；

8.兼容性：不同电压是否可工作、不同类型电话是否可安装等。其实在简单分析的过程中，发现许多东西根本

测试不全，比如电话、灯光、材质、调度程序、可维修性等，当发现在一个用例中无法说清楚时，这些应该拆分开

来分别测试。可以告诉主考官，你需要模块化地测试电话、灯光等。再有在一起的组装测试。

下面是详细的测试点：

需求测试：查看电梯使用说明书、安全说明书等

界面测试：查看电梯外观

功能测试：1.测试电梯能否实现正常的上升和下降功能。

2.电梯的按钮是否都可以使用。

3.电梯门的打开，关闭是否正常。

4.报警装置是否可用。

5.与其他电梯之间是否协作良好。

6.通风状况如何。

7.突然停电时的情况。

8.上升途中的响应。
1）电梯本来在 1 楼，如果有人按 18 楼，那么电梯在上升到 5 楼的时候，有人按了 10 楼， 这时候是否会在 10 楼先停下来

2）电梯下降到 10 层时显示满员，此时若 8 层有人等待电梯，是否在 8 层停。

9.是否有手机信号

可靠性测试：

1.门关上的一刹那出现障碍物。

2.同时按关门和开门按钮。

3.点击当前楼层号码

4.多次点击同一楼层号码

5.同时按上键和下键

易用性：电梯的按钮的设计符合一般人的习惯吗

用户文档：使用手册是否对电梯的用法、限制、使用条件等有详细的描述

压力测试：1.看电梯的最大承重量，在负载过重时报警装置是否有提醒

稳定性测试：看垫底在最大负载下平行运行的最长时间

1.界面测试，无论我们做那类软件（嵌入式别提），只要给用户有看到的东西，从测试的角度，就要考虑界面测试，这个呢，现在针对微软的产品，某公司开发了一套界面检查表，我这里有一份，想要可以找我

界面测试测什么，怎么测呢？针对这个问题我是这样回答的，印刷在产品上的图片，文字，这可能涉及不同的 东西，有圆珠笔厂家的信息，也有针对不同用户的信息（譬如小孩子喜欢颜色搭配多一点的，而成人用稳重的产品 等），可能涉及的还有人的审美观，你圆珠笔色彩搭配之类的

2.功能测试，这是我们测试的重点，也是客户针对某家公司产品给出满意度的参考点，圆珠笔功能主要是书写， 这里面涉及一个功用方面的焦点——书写的快慢程度，也就是流利不流利的问题（这涉及笔芯的材质问题） 针对这方面的测试，个人认为应从以下几点

a.材质问题，这涉及程序员和用户之间的关系，两者利益均有，程序员考虑成本问题，用户考虑污染问题，也 就是说制作圆珠笔的材料与环境的问题，厂商考虑价格因素，用户考虑环境因素以及安全性因素 这就把安全性测试给说出来了，大的方面因为笔油材质的问题，和使用者之间的健康问题有联系， 要测小的方面，笔油的速率，以及书写后是否马上可以涂抹，可否修改，这都涉及安全性的问题

b.性能问题，温度，湿度，气压对笔芯产生不同的影响

3.安全性问题

测试不同的高度，笔身做自由落体损坏程度

4.兼容性问题

不同的笔筒和笔芯之间的互相兼容

5.强度测试

弹簧在不同的压力之下，承受变形的程度

6.在金山面试时候，考官特意问我针对笔芯那个米珠如何测试

或者

1、界面测试

界面测试也就是对其外表先进行判断。

尺寸是否适合用户使用？用户需要的是什么样的尺寸，小孩和成年人使用的尺寸是有区别的；

色彩搭配是否合理？形状是否美观？

是否方便携带和存放？

笔芯颜色是否与客户要求一致？

笔身印的 logo 或者文字是否这么正确

2、功能测试

笔筒开合；

笔芯替换；

出墨快慢；

笔头出墨粗细；

是不是可操作性签字笔；

3、性能测试

笔芯的寿命；

笔墨的气味；

写过的字用纸水浸透后，笔墨是否会晕开

压力测试：笔尖在多大压力范围内可以正常写字，不能正常出墨，太重损坏笔尖或纸张；

笔壳能在多大压力范围内正常使用？成人用力太重掰断笔壳，掉到地上易摔，能在纸上写出清晰的字

4、性能测试

握笔的地方纹路是否会硌手或太滑；

书写的流畅度；

写出的墨水多久能干；

高温和低温环境对笔芯出墨和笔壳的影响；

长时间不盖笔套，或笔盖盖多长时间不用，会不会对笔下次写字有影响

5、安全测试

笔墨是否有易燃性；

笔墨是否对皮肤有害；

笔杆折断，材质是否容易刮伤手；

误食笔芯是否会引起中毒（有小孩或者有人喜欢咬笔头）

6、兼容性测试

笔壳和笔芯是否能够很好的适应主流签字笔尺寸；

这个笔芯的笔尖如果损坏，换上其他的笔芯的笔尖是否能用；

这个笔芯的笔墨如果用完，换上其他笔芯的笔墨是否可以使用；

笔的笔墨如果在其他笔的笔墨上写字是否可以成功覆盖

7、其他测试

（1）比较测试

与其他品牌签字笔比较，优劣在哪些地方？

（2）场景测试

笔从高处摔到地上，笔尖是否会摔坏；

倒着写，是否可以写出很多字来；

扔到水里，笔墨会不会一直晕开；

笔在粗糙的纸上是否能写出字…

1. 功能测试

考虑功能是否符合预期

2. 接口

考虑各内部和外部的接口，比如朋友圈客户端和服务端的交互接口的功能。朋友圈点赞功能和消息提示功能的

接口（点了赞之后对应的朋友收到提示信息）

3. 平台

手机版 pad 版 web 版

4. 用户操作场景

测试用户常用场景，比如：用户打开微信看到十条消息提示，点击后进入朋友圈界面显示了“谁谁谁点了赞”

5. 速度、延迟

6. 性能测试

模拟一些多用户并发操作的场景

7. 安全

ps -aux | sort -k3nr | head -K

查看/etc/profile 的前 10 行内容，应该是：

# head -n 10 /etc/profile

查看/etc/profile 的最后 50 行内容，应该是：

# tail -n 50 /etc/profile

grep "ERROR" file_name

cat file_name | grep "ERROR"

netstat -anp | grep port_number

ps -ef | grep ps_name

ps -ef | grep ps_number

ifconfig

mkdir -p ./a/b

rm -rf ./a

find ~/ -name haha.txt

ps -ef | grep tomcat

kill -9 tomcat_port

tail -f log_file

df -aTh

netstat -tlnp

tar zcvf xxx.tar.gz file tar zxvf xxx.tar.gz

lrzsz

cat /etc/passwd | head -n 5 | cut -d : -f 1

Linux 系统中 grep 命令是一种强大的文本搜索工具，它能使用正则表达式搜索文本，并把匹配的行打印出来。

grep 全称是 Global Regular Expression Print，表示全局正则表达式版本，它的使用权限是所有用户。

linux 下的 find：

功能：在目录结构中搜索文件，并执行指定的操作。此命令提供了相当多的查找条件，功能很强大。

语法：find 起始目录寻找条件操作说明：find 命令从指定的起始目录开始，递归地搜索其各个子目录，查找满 足寻找条件的文件并对之采取相关的操作。

简单点说说，grep 是查找匹配条件的行，find 是搜索匹配条件的文件。

一、 基础知识

数据库(Database)是按照数据结构来组织、存储和管理数据的仓库

关系型数据库是由多张能互相联接的二维行列表格组成的数据库

主关键字(primary key)是表中的一个或多个字段，它的值用于唯一地标识表中的某一条记录外键表示了两个关系之间的相关联系。以另一个关系的外键作主关键字的表被称为主表，具有此外键的表被称 为主表的从表。外键又称作外关键字

在关系数据库中，索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单

交叉连接即笛卡儿乘积，是指两个关系中所有元组的任意组合使用内连接时，如果两个表的相关字段满足连接条件，就从这两个表中提取数据并组合成新的记录 自连接是一种特殊的内连接，它是指相互连接的表在物理上为同一张表，但可以在逻辑上分为两张表 外连接是只限制一张表中的数据必须满足连接条件，而另一张表中的数据可以不满足连接条件的连接方式

1、from 子句组装来自不同数据源的数据；

2、where 子句基于指定的条件对记录行进行筛选；

3、group by 子句将数据划分为多个分组；

4、使用聚集函数进行计算；

5、使用 having 子句筛选分组；

6、计算所有的表达式；

7、select 的字段；

8、使用 order by 对结果集进行排序。

储存过程是一个可编程的函数，它在数据库中创建并保存。它可以有 SQL 语句和一些特殊的控制结构组成。当 希望在不同的应用程序或平台上执行相同的函数，或者封装特定功能时，存储过程是非常有用的。数据库中的存储 过程可以看做是对编程中面向对象方法的模拟。它允许控制数据的访问方式。存储过程通常有以下优点：

1、存储过程能实现较快的执行速度

2、存储过程允许标准组件是编程。

3、存储过程可以用流程控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的运算。

4、存储过程可被作为一种安全机制来充分利用。

5、存储过程能够减少网络流量

1、原子性(Atomicity)：事务中的全部操作在数据库中是不可分割的，要么全部完成，要么均不执行。

2、一致性(Consistency)：几个并行执行的事务，其执行结果必须与按某一顺序串行执行的结果相一致。

3、隔离性(Isolation)：事务的执行不受其他事务的干扰，事务执行的中间结果对其他事务必须是透明的。

4、持久性(Durability)：对于任意已提交事务，系统必须保证该事务对数据库的改变不被丢失，即使数据库出现故障

7. 数据库索引？

数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用 B_TREE。B_TREE 索引加速了数据访问，因为存储引擎不会再去扫描整张表得到需要的数据；相反，它从根节点开始，根节点保存了子节点的指针，存储引擎会根据指针快速寻找数据。

1、储存引擎选择：如果数据表需要事务处理，应该考虑使用 InnoDB，因为它完全符合 ACID 特性。如果不需要事务处理，使用默认存储引擎 MyISAM 是比较明智的

2、分表分库，主从。

3、对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引

4、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描

5、应尽量避免在 where 子句中使用!= 或<>操作符，否则将引擎放弃使用索引而进行全表扫描

6、应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描

7、Update 语句，如果只更改 1、2 个字段，不要 Update 全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志

8、对于多张大数据量（这里几百条就算大了）的表 JOIN，要先分页再 JOIN，否则逻辑读会很高，性能很差。

主要 MyISAM 与 InnoDB 两个引擎，其主要区别如下：InnoDB 支持事务，MyISAM 不支持，这一点是非常之重要。事务是一种高级的处理方式，如在一些列增删改中只要哪个出错还可以回滚还原，而 MyISAM 就不可以了；

MyISAM 适合查询以及插入为主的应用，InnoDB 适合频繁修改以及涉及到安全性较高的应用；

InnoDB 支持外键，MyISAM 不支持；

MyISAM 是默认引擎，InnoDB 需要指定；

InnoDB 不支持 FULLTEXT 类型的索引；

InnoDB 中不保存表的行数，如 select count() from table 时，InnoDB；需要扫描一遍整个表来计算有多少行，但

是 MyISAM 只要简单的读出保存好的行数即可。注意的是，当 count()语句包含 where 条件时 MyISAM 也需要扫描整个表；

对于自增长的字段，InnoDB 中必须包含只有该字段的索引，但是在 MyISAM 表中可以和其他字

段一起建立联合索引；清空整个表时，InnoDB 是一行一行的删除，效率非常慢。MyISAM 则会重建表；

InnoDB 支持行锁（某些情况下还是锁整表，如 update table set a=1 where user like '%lee%'

a. 应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索。

b. 应尽量避免在 where 子句中对字段进行 null 值判断，避免使用!=或<>操作符，避免使用 or

连接条件，或在 where 子句中使用参数、对字段进行表达式或函数操作，否则会导致权标扫描

c. 不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无

法正确使用索引。

d. 使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为

条件时才能保证系统使用该索引，否则该索引将不会被使用。

e. 很多时候可考虑用 exists 代替 in。

f. 尽量使用数字型字段。

g. 尽可能的使用 varchar/nvarchar 代替 char/nchar。

h. 任何地方都不要使用 select from t ，用具体的字段列表代替“”，不要返回用不到的任何字段。

i. 尽量使用表变量来代替临时表。

j. 避免频繁创建和删除临时表，以减少系统表资源的消耗。

k. 尽量避免使用游标，因为游标的效率较差

l. 在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SETNOCOUNT OFF。

m. 尽量避免大事务操作，提高系统并发能力。

n. 尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

1.优化索引、SQL 语句、分析慢查询；

2.设计表的时候严格根据数据库的设计范式来设计数据库；

3.使用缓存，把经常访问到的数据而且不需要经常变化的数据放在缓存中，能节约磁盘 IO

4.优化硬件；采用 SSD，使用磁盘队列技术(RAID0,RAID1,RDID5)等

5.采用 MySQL 内部自带的表分区技术，把数据分层不同的文件，能够提高磁盘的读取效率；

6.垂直分表；把一些不经常读的数据放在一张表里，节约磁盘 I/O；

7.主从分离读写；采用主从复制把数据库的读操作和写入操作分离开来；

8.分库分表分机器（数据量特别大），主要的原理就是数据路由；

9.选择合适的表引擎，参数上的优化

10.进行架构级别的缓存，静态化和分布式；

11.不采用全文索引；

12.采用更快的存储方式，例如 NoSQL 存储经常访问的数据。

程序开发过程中不注意规范书写 sql 语句和对特殊字符进行过滤，导致客户端可以通过全局变量 POST 和 GET

提交一些 sql 语句正常执行。产生 Sql 注入。下面是防止办法：

a. 过滤掉一些常见的数据库操作关键字，或者通过系统函数来进行过滤。

b. 在 PHP 配置文件中将 Register_globals=off;设置为关闭状态

c. SQL 语句书写的时候尽量不要省略小引号(tab 键上面那个)和单引号

d. 提高数据库命名技巧，对于一些重要的字段根据程序的特点命名，取不易被猜到的

e. 对于常用的方法加以封装，避免直接暴漏 SQL 语句

f. 开启 PHP 安全模式：Safe_mode=on;

g. 打开 magic_quotes_gpc 来防止 SQL 注入

h. 控制错误信息：关闭错误提示信息，将错误信息写到系统日志。

i. 使用 mysqli 或 pdo 预处理。

a. SQL 数据存在特定结构的表中；而 NoSQL 则更加灵活和可扩展，存储方式可以省是 JSON 文档、哈希表或其他方式。

b. 在 SQL 中，必须定义好表和字段结构后才能添加数据，例如定义表的主键(primary key)，索引(index),触发器

(trigger),存储过程(stored procedure)等。表结构可以在被定义之后更新，但是如果有比较大的结构变更的话就会变得比较复杂。在 NoSQL 中，数据可以在任何时候任何地方添加，不需要先定义表。

c. SQL 中如果需要增加外部关联数据的话，规范化做法是在原表中增加一个外键，关联外部数据表。而在 NoSQL 中除了这种规范化的外部数据表做法以外，我们还能用如下的非规范化方式把外部数据直接放到原数据集中，以提高查询效率。缺点也比较明显，更新审核人数据的时候将会比较麻烦。

d. SQL 中可以使用 JOIN 表链接方式将多个关系数据表中的数据用一条简单的查询语句查询出来。

NoSQL 暂未提供类似 JOIN 的查询方式对多个数据集中的数据做查询。所以大部分 NoSQL 使用非规范化的数据存储方式存储数据。

e. SQL 中不允许删除已经被使用的外部数据，而 NoSQL 中则没有这种强耦合的概念，可以随时删除任何数据。

f. SQL 中如果多张表数据需要同批次被更新，即如果其中一张表更新失败的话其他表也不能更新成

功。这种场景可以通过事务来控制，可以在所有命令完成后再统一提交事务。而 NoSQL 中没有事务这个概念，每一个数据集的操作都是原子级的。

g. 在相同水平的系统设计的前提下，因为 NoSQL 中省略了 JOIN 查询的消耗，故理论上性能上是优于 SQL 的。

差别在多方面，例如：数据的表示、查询、关系、事务、模式的设计和定义、速度和性能。MongoDB 是由 C 语言编写的，是一个基于分布式文件存储的开源数据库系统。在高负载的情况下，添加更多的节点，可以保证服务器性能。

MongoDB 旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。

MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。

MongoDB 是一个面向文档的数据库，目前由 10gen 开发并维护，它的功能丰富齐全，所以完全可以替代 MySQL。

与 MySQL 等关系型数据库相比，MongoDB 的优点如下：

①弱一致性，更能保证用户的访问速度。

②文档结构的存储方式，能够更便捷的获取数据。

③内置 GridFS，支持大容量的存储。

④内置 Sharding。

⑤第三方支持丰富。(这是与其他的 NoSQL 相比，MongoDB 也具有的优势)

⑥性能优越：

MongoDB 本身它还算比较年轻的一个产品，所以它的问题，就是成熟度肯定没有传统 MySQL 那么成熟稳定。

所以在使用的时候： 尽量使用稳定版，不要在线上使用开发版，这是一个大原则；

另外一点，备份很重要，MongoDB 如果出现一些异常情况，备份一定是要能跟上。除了通过传统的复制的方式 来做备份，离线备份也还是要有，不管你是用什么方式，都要有一个完整的离线备份。往往最后出现了特殊情况，它能帮助到你；另外，MongoDB 性能的一个关键点就是索引，索引是不是能有比较好的使用效率，索引是不是能够放在内存中，这样能够提升随机读写的性能。如果你的索引不能完全放在内存中，一旦出现随机读写比较高的时候， 它就会频繁地进行磁盘交换，这个时候，MongoDB 的性能就会急剧下降，会出现波动。

另外，MongoDB 还有一个最大的缺点，就是它占用的空间很大，因为它属于典型空间换时间原则的类型。那么 它的磁盘空间比普通数据库会浪费一些，而且到目前为止它还没有实现在线压缩功能，在 MongoDB 中频繁的进行数据增删改时，如果记录变了，例如数据大小发生了变化，这时候容易产生一些数据碎片，出现碎片引发的结果， 一个是索引会出现性能问题。另外一个就是在一定的时间后，所占空间会莫名其妙地增大，所以要定期把数据库做修复，定期重新做索引， 这样会提升 MongoDB 的稳定性和效率。在最新的版本里，它已经在实现在线压缩，估计应该在 2.0 版左右，应该能够实现在线压缩，可以在后台执行现在 repair DataBase 的一些操作。 如果那样，就解决了目前困扰我们的大问题。

select * from table limit (start-1)*limit,limit; 其中 start 是页码，limit 是每页显示的条数。

Select * from 表名 order by 主键 desc limit 10

1.对语句的优化

①用程序中，保证在实现功能的基础上，尽量减少对数据库的访问次数；通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担；

②能够分开的操作尽量分开处理，提高每次的响应速度；在数据窗口使用 SQL 时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；

③在查询时，不要过多地使用通配符如 SELECT * FROM T1 语句，要用到几列就选择几列如：SELECT COL1,COL2 FROM T1；

④在可能的情况下尽量限制尽量结果集行数如：SELECT TOP 300 COL1,COL2,COL3 FROMT1,因为某些情况下用户是不需要那么多的数据的。

⑤不要在应用中使用数据库游标，游标是非常有用的工具，但比使用常规的、面向集的 SQL 语句需要更大的开销；按照特定顺序提取数据的查找。

2. 避免使用不兼容的数据类型

例如 float 和 int、char 和 varchar、binary 和 varbinary 是不兼容的。

数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。

例如:

SELECT name FROM employee WHERE salary ＞ 60000

在这条语句中,如 salary 字段是 money 型的,则优化器很难对其进行优化,因为 60000 是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。若在查询时强制转换，查询速度会明显减慢。

3.避免在 WHERE 子句中对字段进行函数或表达式操作。

若进行函数或表达式操作，将导致引擎放弃使用索引而进行全表扫描。

4.避免使用!=或＜＞、IS NULL 或 IS NOT NULL、IN ，NOT IN 等这样的操作符

5.尽量使用数字型字段

6.合理使用 EXISTS,NOT EXISTS 子句。

7.尽量避免在索引过的字符数据中，使用非打头字母搜索。

8.分利用连接条件

9.消除对大型表行数据的顺序存取

10. 避免困难的正规表达式

11. 使用视图加速查询

12. 能够用 BETWEEN 的就不要用 IN

13. DISTINCT 的就不用 GROUP BY

14. 部分利用索引

15. 能用 UNION ALL 就不要用 UNION

16. 不要写一些不做任何事的查询

17. 尽量不要用 SELECT INTO 语句

18. 必要时强制查询优化器使用某个索引

19. 虽然 UPDATE、DELETE 语句的写法基本固定，但是还是对 UPDATE 语句给点建议：

a) 尽量不要修改主键字段。

b) 当修改 VARCHAR 型字段时，尽量使用相同长度内容的值代替。

c) 尽量最小化对于含有 UPDATE 触发器的表的 UPDATE 操作。

d) 避免 UPDATE 将要复制到其他数据库的列。

e) 避免 UPDATE 建有很多索引的列。

f) 避免 UPDATE 在 WHERE 子句条件中的列。

相同点：存储过程和函数都是为了可重复的执行操作数据库的 sql 语句的集合。

1）存储过程和函数都是一次编译，就会被缓存起来，下次使用就直接命中已经编译好的 sql 语句，不需要重复使用。减少网络交互，减少网络访问流量。

不同点：标识符不同，函数的标识符是 function，存储过程是 proceduce。

1）函数中有返回值，且必须有返回值，而过程没有返回值，但是可以通过设置参数类型（in,out)来实现多个参数或者返回值。

2）存储函数使用 select 调用，存储过程需要使用 call 调用。

3）select 语句可以在存储过程中调用，但是除了 select..into 之外的 select 语句都不能在函数中使用。

4）通过 in out 参数，过程相关函数更加灵活，可以返回多个结果。

Show variables like ‘general%’;

Set global general_log=1;

Set global general_log=0;

• Student（sid，Sname，Sage，Ssex）学生表
• Course（cid，Cname，tid）课程表
• SC（sid，cid，score）成绩表
• Teacher（tid，Tname）教师表

写出 sql 语句：

•  查询课程“001“课程比”002“课程成绩高的所有学生的学号
•  修改学号为 20131201 的语文成绩为 100‘
•  插入一条名为“李四”的教师记录
•  删除学习“叶平”老师课程的 sc 表记录

先要解析出 http://baidu.com 对应的 ip 地址：

 要先使用 arp 获取默认网关的 mac 地址

 组织数据发送给默认网关(ip 还是 dns 服务器的 ip，但是 mac 地址是默认网关的 mac 地址)

 默认网关拥有转发数据的能力，把数据转发给路由器

 路由器根据自己的路由协议，来选择一个合适的较快的路径转发数据给目的网关

 目的网关(dns 服务器所在的网关)，把数据转发给 dns 服务

 dns 服务器查询解析出 http://baidu.com 对应的 ip 地址，并原路返回请求这个域名的 client 得到了 http://baidu.com 对应的 ip 地址之后，会发送 tcp 的 3 次握手，进行连接

 使用 http 协议发送请求数据给 web 服务器

 web 服务器收到数据请求之后，通过查询自己的服务器得到相应的结果，原路返回给浏览器

 浏览器接收到数据之后通过浏览器自己的渲染功能来显示这个网页

 浏览器关闭 tcp 连接，即 4 次挥手结束，完成整个访问过程

IE，Chrome，Safari，Firefox，Opera

SQL 注入攻击是注入攻击最常见的形式（此外还有 OS 注入攻击（Struts 2 的高危漏洞就是通过 OGNL 实施 OS 注入攻击导致的）），当服务器使用请求参数构造 SQL 语句时，恶意的 SQL 被嵌入到 SQL 中交给数据库执行。SQL 注入攻击需要攻击者对数据库结构有所了解才能进行，攻击者想要获得表结构有多种方式：

（1）如果使用开源系统搭建网站，数据库结构也是公开的（目前有很多现成的系统可以直接搭建论坛，电商网站，虽然方便快捷但是风险是必须要认真评估的）；

（2）错误回显（如果将服务器的错误信息直接显示在页面上，攻击者可以通过非法参数引发页面错误从而通过错误信息了解数据库结构，Web 应用应当设置友好的错误页，一方面符合最小惊讶原则，一方面屏蔽掉可能给系统带来危险的错误回显信息）；

（3）盲注。防范 SQL 注入攻击也可以采用消毒的方式，通过正则表达式对请求参数进行验证，此外，参数绑定也是很好的手段，这样恶意的 SQL 会被当做 SQL 的参数而不是命令被执行，JDBC 中的 PreparedStatement 就是支持参数绑定的语句对象，从性能和安全性上都明显优于 Statement。

XSS（Cross Site Script，跨站脚本攻击）是向网页中注入恶意脚本在用户浏览网页时在用户浏览器中执行恶意脚本的攻击方式。

跨站脚本攻击分有两种形式： 反射型攻击（诱使用户点击一个嵌入恶意脚本的链接以达到攻击的目标，目前有很多攻击者利用论坛、微博发 布含有恶意脚本的 URL 就属于这种方式）

持久型攻击（将恶意脚本提交到被攻击网站的数据库中，用户浏览网页时，恶意脚本从数据库中被加载到页面执行，QQ 邮箱的早期版本就曾经被利用作为持久型跨站脚本攻击的平台）。

CSRF 攻击（Cross Site Request Forgery，跨站请求伪造）是攻击者通过跨站请求，以合法的用户身份进行非法操作（如转账或发帖等）。CSRF 的原理是利用浏览器的 Cookie 或服务器的 Session，盗取用户身份，其原理如下图所示。

防范 CSRF 的主要手段是识别请求者的身份，主要有以下几种方式：

（1）在表单中添加令牌（token）；

（2）验证码；

（3）检查请求头中的 Referer（前面提到防图片盗链接也是用的这种方式）。

令牌和验证都具有一次消费性的特征，因此在原理上一致的，但是验证码是一种糟糕的用户体验，不是必要的情况下不要轻易使用验证码，目前很多网站的做法是如果在短时间内多次提交一个表单未获得成功后才要求提供验 证码，这样会获得较好的用户体验。

Nginx (engine x) 是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 服务器。

Apache HTTP Server 是一个模块化的服务器，源于 NCSAhttpd 服务器

Tomcat 服务器是一个免费的开放源代码的 Web 应用服务器，属于轻量级应用服务器，是开发和调试 JSP 程序 的首选。

Nginx 相对 Apache 的优点：

轻量级，同样起 web 服务，比 apache 占用更少的内存及资源；

抗并发，nginx 处理请求是异步非阻塞的，支持更多的并发连接，而 apache 则是阻塞型的，在高并发下 nginx 能

保持低资源低消耗高性能；

配置简洁；

高度模块化的设计，编写模块相对简单；

社区活跃。

Apache 相对 Nginx 的优点：

rewrite ，比 nginx 的 rewrite 强大；

模块超多，基本想到的都可以找到；

少 bug ，nginx 的 bug 相对较多；

超稳定

接口是指外部系统与系统之间以及内部各子系统之间的交互点。

包括外部接口、内部接口，内部接口又包括：上层服务与下层服务接口、同级接口。

分别用 http 还有 https 登录试试。如果用 https 可以正常登录，地址栏显示一把锁头，那么这个网站是有部署 SSL的。如果 http 和 https 都能够正常登录，进一步说明该网站没有设置强制 https 登录，或者说没有设置 http 链接自动跳转 https 链接；相反如果用 http 登录，结果跳转到 https 页面，说明网站部署了 SSL，而且设置了 http 自动跳转 https。

功能测试：

1.业务逻辑正确性测试：依据：产品文档->测试用例编写

兼容性测试：

1.系统版本：Android:官方版本,定制版本;IOS：官方提供版本

2.分辨率：720 * 1280 1080* 1920

3.网络情况:2g 3g 4g 5g Wi-Fi

异常测试

1.热启动应用:应用在后台长时间待机;应用在后台待机过程中，手机重启

2.网络切换和中断恢复:网络切换;中断恢复：

3.电话信息中断恢复

升级，安装，卸载测试

1.升级测试：临近版本升级(1.0->1.1);跨版本(1.0->....->2.2)

2.安装测试：首次安装;覆盖安装(同版本，不同版本覆盖);卸载后安装

3.卸载测试：首次卸载;卸载安装后在卸载

健壮性测试

1.手机资源消耗：cpu，内存

2.流量消耗：图片，数据，视频

3.电量测试

4.崩溃恢复

品牌机型兼容：根据市场占有率、发布时间等指标对主流、最新机型进行重点兼容

ROM 兼容：需兼容原生的 ROM（2.1、2.2、2.3、4.0、4.1、4.2）；第三方 ROM（小米、百度易、点心、魅族、 阿里云……）

屏幕兼容：需兼容 HVGA、VGA、WVGA、FWVGA、720p、1080p 屏幕分辨率，并考虑不同 PPI 的情况

软件兼容：安全类软件（百度手机管家、360 优化大师、360 安全卫士、QQ 手机管家、安卓优化大师、网秦、 LBE），输入法软件（系统自带、Sogou、百度）

版本兼容：服务器端需要兼容产品早期版本所需的 API 接口

网络兼容：WiFi、3 大运营商的 2G,3G,4G 网络，需区分 WAP 和 NET 接入

 安装

1.正常安装测试，检查是否安装成功。

2.APP 版本覆盖测试。例如：先安装一个 1.0 版本的 APP,再安装一个高版本(1.1 版本)的 APP，检查是否被覆盖。

3.回退版本测试。例如：先装一个 2.0 版本的 APP,再安装一个 1.0 版本的 APP,正常情况下版本是可以回退的。

4.安装时内存不足，弹出提示。

5.根据安装手册操作，是否正确安装。

6.安装过程中的意外情况（强行断电、断网、来电话了、查看信息）等等，检查会发生的情况。

7.通过‘同步软件’，检查安装时是否同步安装了一些文件。

8.在不同型号、系统、屏幕大小、分辨率上的手机进行安装。

9.安装时是否识别有 SD 卡，并默认安装到 sd 卡中。

10.安装完成后，能否正常启动应用程序。

11.安装完成后，重启手机能否正常启动应用程序。

12.安装完成后，是否对其他应用程序造成影响。

13.安装完成后，能否添加快捷方式。

14.安装完成后，*毒软件是否会对其当做病毒处理。

15.多进程进行安装，是否安装成功。

16.在安装过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码、符号、乱码等。

17.安装之后，是否自动启动程序。

18.是否支持第三方安装。

19.在安装中点击取消。

 卸载

1.用自己的卸载程序进行卸载，检查是否卸载干净。

2.用第三方工具，检查是否卸载干净。

3.在卸载过程中，点击取消按钮，看是否正常退出卸载程序，检查软件是否还能继续正常使用。

4.卸载过程中，出现意外（比如手机关机，没电，查看信息，接打电话），程序是否还能运行。

5.在卸载过程中，突然重启设备，再次访问程序，是否还能运行。

6.在没用使用程序时，删除目录文件，看程序是否能运行。

7.在使用过程中，直接删除目录文件，程序是否还能运行。

8.不同系统、硬件环境、网络环境下进行卸载。

9.卸载成功后，是否对其他程序有影响。

10.卸载后再次安装，是否正常使用。

11.在卸载过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码、符号、乱码等。

 更新

1.当客户端有新版本时，提示更新。

2.非强制更新，可以取消更新，旧版本正常使用，下次使用软件时，仍然会出现更新提示。

3.强制更新，强制更新而用户没有更新时，退出客户端，下次启动，依然提示更新。

4.不卸载更新，检查是否可以更新。

5.不卸载更新，检查资源同名文件如图片等是否更新成最新版本。

6.非 wifi 网络下，提示是否更新，取消就加入待下载，wifi 下自动更新。

adb --help / adb :看见帮助信息

adb start-server:启动 adb 服务

adb kill-server:关闭 adb 服务

adb devices:查看手机设备号

adb shell getprop ro.build.version.release:获取系统版本

adb push 电脑 手机

adb pull 手机 电脑

adb logcat | grep(unix) 包名

adb logcat | findstr(win) 包名

adb shell :进入 shell 命令行，可以操作 Linux 命令

adb shell dumpsys window windows | grep mFocusedApp:获取包名 启动名(win：adb shell dumpsys window

windows | findstr mFocusedApp)

adb install 路径/apk 文件:安装 apk 到手机上

adb uninstall 包名:卸载 app 从手机上

adb shell am start -W 包名/启动名:app 启动时间

输出重定向：logcat >> log_file_name

• 缓存垃圾过多：由于安卓系统的特性,如果长时间不清理垃圾文件.会导致越来越卡.也会出现闪退情况.
• 运行的程序过多,导致内存不足
• 应用版本兼容问题：如果应用版本太低，会导致不兼容，造成闪退。此外，有些新版本在调试中，也会造成应
• 用闪退。解决方法：如果是版本太旧，更新为新版本即可；如果是新版本闪退，可能是应用在改版调试，可卸载后
• 安装旧版。
• 检查 APP 中访问网络的地方，组件中的 ImageView 是否可以正常的下载并显示到 app 页面上。
• 检查 APP 的 sdk 和手机的系统是否兼容。
• 在一些特定情况下的闪退,比如播放视频,在 Android5.0 升级到 Android6.0 的时候,有些系统 API 老版本有,新版本没有,到时回去对象的时候失败,报空,系统就会出现闪退问题.

弱网环境测试主要依赖于弱网环境的模拟。环境搭建方式一般有两种：软件方式和硬件方式。软件方式的成本低，主要就是通过模拟网络参数来配置弱网环境，通常来讲可以达到测试目的.一般可通过热点共享设置。在各类网络软件中，主要就是对带宽、丢包、延时等进行模拟弱网环境。如果要求更接近弱网环境，比如现在很多的专项测试，会更倾向于通过硬件方式来协助测试，但这种方式相对会麻烦很多，一般会由网维协助搭建。当然，对于有些无法模拟的情况，只能靠人工移动到例如电梯、地铁等信号比较弱的地方