测试岗面试基础知识—

软件 = 程序 + 数据 + 相关文档

什么是软件测试？

在规定条件下使用人工和自动手段对程序进行操作，从而发现问题，对软件质量进行评估的过程，目的在于检验是否满足了需求。

软件测试的目的

以最少的人力、物力、时间，找到软件中的缺陷并修改，从而回避商业风险。

软件测试的原则

1)所有测试追溯到用户需求
2)尽早和不断的测试
3)测试工作由专业人员执行
4)八二原则：80%的错误出现在20%的模块中
5)设计测试用例要考虑各种情况
6)要写缺陷报告
7)制定严格的测试计划
8)完全测试不可能，测试要终止
9)要回归测试（修改了旧代码后，要确认没有引入新的问题）
10)妥善保存一切测试文档

软件质量模型（iso9126）(6大特性):

1.功能性（满足需求）
2.可靠性（产品不出问题、产品出了问题不影响使用、影响使用能及时修复）
3.易用性（用户体验好）
4.效率（产品性能）
5.可维护性（更新）
6.可移植性（跨越不同系统平台）

软件测试模型

1、V模型：用户需求→需求分析→概要设计→详细设计→编码
→单元测试→集成测试→系统测试→验收测试

把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析，系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。（应该比较多包括系统测试和验收测试）
2、W模型：

左边v是需求分析→概要设计→详细设计→编码→模块集成→系统构建→系统安装
右边v是需求测试→概要设计测试→详细设计测试→单元测试->集成测试→系统测试→验收测试

测试的活动与软件开发同步进行，测试的对象不仅仅是程序，还包括需求和设计。因为在需求阶段测试就已经介入了，后面每一阶段的开发都需要经过测试，能够尽早发现软件的缺陷，降低debug的成本。
3、H模型
4、X模型
5、前置测试模型、
6、敏捷测试模型：结合单元测试和验收测试（进行单元测试后交付给用户进行验收），以用户需求为中心，在每一个迭代周期都需要进行测试，基于自动化测试->速度快、敏捷。更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。缺陷修复的成本也较低。

测试的类型

测试分为功能测试和非功能测试，非功能测试又可以分为性能测试、压力测试、容量测试、健壮性测试、安全性测试、可靠性测试、恢复性测试、备份测试、协议测试、兼容性测试、可用性测试、配置测试、GUI测试。

测试分为哪几个阶段（哪些级别）？：

1 单元测试（组件测试）：模块测试，测试程序中的小模块（如一个函数）。

测试技术：黑盒、白盒（居多），一般先做黑盒再做白盒
测试重点：功能性测试、健壮性、性能

2 集成测试：所有模块合起来测试（组件间接口和交互的测试），其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块

测试技术：黑盒、白盒（居多），一般先做黑盒再做白盒
测试重点：接口和不同部分的交互
策略：
非增量式集成：把所有模块按设计要求全部组装起来，然后整体测试。
增量式集成：自顶向下集成（桩模块）、自底向上集成（驱动模块）

桩模块：被被测模块调用的模块。 驱动模块：调用被测模块的模块
自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。

3 确认测试：类似于冒烟测试，通常在大规模系统测试之前验证版本主要功能是否实现，版本的稳定性是否可以进入系统测试。

4 系统测试：软件全方位测试（整个系统能不能满足用户的需求）

测试技术：黑盒
策略（主要包括）：功能测试，性能测试，易用性测试，安全测试（包括用户访问认证、传输数据加密，安全防护策略如安全日志，入侵检测，隔离防护、数据备份与恢复、防病毒系统、SQL注入和JS注入（在输入框输入一段具有含义的sql语句或js语句）），兼容性测试，界面测试，负载测试，压力测试，可用性测试....

5 回归测试：回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。（回归测试除了错误回归还有用例回归，即过一段时间再回头对以前使用过的用例再重新进行测试，看看会不会重新发现问题）
6 验收测试：也叫交付测试，用户来测，测试人员可介入。分为正式验收测试、alpha测试、beta测试。

Alpha测试（α测试）：（内部测试）在系统开发接近完成时对应应系统的测试；测试后仍然会有少量的变更。一般由最终用户或其他人员完成，不能由程序或测试员完成。开发者负责记录发现的错误和使用中遇到的问题。（用户在开发环境下进行的测试）
Beta测试（β测试）：（公测）用户在自己的环境下测试，由用户记录在测试中遇到的一系列问题，并定期报给开发者。（在用户真实环境测试，通过后进入发布阶段）

注：验收测试针对的是项目，目的是为了以发现“未实现的需求”为目的，以评估“适合使用”为目标，该类测试不是以发现缺陷为主要目的。而beta测试针对的是产品，是一种模拟真实的使用环境从而发现缺陷的一种测试。

单元测试、集成测试、系统测试区别

粒度不同：单元测试粒度最小，集成测试粒度居中，系统测试粒度最大。
测试方式不同：单元测试一般由开发小组采用白盒方式来测试，集成测试一般由开发小组采用白盒加黑盒的方式来测试，系统测试一般由独立测试小组采用黑盒方式来测试。
测试内容不同：单元测试主要测试单元是否符合“设计”，集成测试既验证“设计”，又验证“需求”，系统测试主要测试系统是否符合“需求规格说明书”。
使用阶段不同：单元测试为开发人员在开发阶段要做的事情，集成测试和系统测试为测试人员在测试周期内做的工作。

性能测试、负载测试、压力测试

性能测试：关注处理速度、响应时间、CPU使用、内存使用、硬盘使用等
负载测试：通过不断增加负载来测试系统的性能。（不知道系统的性能）
压力测试：不断增加负载超过正常能力来考察系统是否正常工作。（知道系统的性能）

测试的基本过程（怎么做测试？）

测试需求分析→编写测试计划→编写测试用例→搭建测试环境→执行测试用例→提交缺陷报告并跟踪→测试评估和总结。（每一步工作完成后都要进行评审。）

基本流程：需求分析->编写测试用例（测什么怎么测）->评审测试用例->搭建测试环境->等待程序的开发包->部署测试包->冒烟测试（测试主体功能是否有问题）->执行测试用例->Bug跟踪处理（回归测试）->n轮之后符合要求->测试结束

如何做好测试计划

5w原则：what(明确测试什么，被测内容)、why(明确测试目标)、when（明确项目开始、结束时间）、how(明确测试方案)、where（明确资料的位置）

测试报告都包含哪些内容

测试北京说明、测试范围说明、测试环境说明、测试方法说明、测试结果结论（通过还是不通过还是风险缺陷有什么）、质量和风险评估。

测试用例

通过设计输入数据、执行步骤、按此步骤应产生的预期结果，来进行测试程序是否满足需求；测试用例是指导测试进行的依据；其目的是为了高效率发现软件缺陷而精心设计的少量测试数据。

测试用例的特征：

1.有效性：能被使用，且被不同人使用的测试结果一样。如：任务重新分工、用别人的测试用例
2.可重复性：可重复使用。如回归测试
3.易组织：测试用例可以分门别类的提供给测试人员使用，如测试用例按功能、性能、易用等类型分类编号；
4.可评估性：从测试管理的角度，测试用例的通过率和软件缺陷数目是评估软件质量好坏的标准，如测试计划中提到的测试通过的标准，直接影响软件的发布；
5.可管理性：测试用例可以作为检验测试人工工作进度、工作量以及跟踪测试人员的工作效率的因素。如测试人员的工作量计数和绩效考核。

测试用例的八大要素（组成）：

1、测试编号 2、测试模块 3、测试标题 4、测试优先级 5、测试环境 6、测试输入数据 7、测试步骤 8、预期结果

测试用例优先级：

冒烟测试、高、中、低

测试用例的设计原则：

1)测试用例具有明确性：测试用例的测试结果是唯一的，不能含糊不清
2)测试用例有代表性：尽量将具有相似功能的测试用例抽象合并，如等价类划分
3)测试用例具有简洁性：测试用例简洁，可读性良好，测试过程目的明确。如测试用例一般用陈述句表述，一句话直指问题的核心。

测试用例设计方法：

黑盒测试：

也称功能测试或数据驱动测试，侧重于测试软件能做什么，结果对不对。实际是站在最终用户的立场，检查输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
主要方法：等价类划分；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。

优点：容易实施，不需要关注内部实现；贴近用户需求。
缺点：覆盖率比较低，因为不知道内部逻辑

1等价类：设计输入具有代表性的数据子集

分类：有效等价类：满足需求；无效等价类：不满足需求

注意：（1）无效等价类在一个测试用例中只能出现一次。（2）有效等价类在一个用例中可以出现多次（一个测试用例尽可能覆盖多个不同的有效等价类）

适用场景：输入框、页面上的多个输入框不存在逻辑关系。

缺点：没有关注到边界的问题；没有关注到输入框的逻辑关系（如确认密码）

等价类要关注的要点：长度、类型、字母、汉字、特殊字符、空、空格。
测试文本框要关注的要点：长度、类型、组成规则、是否为空、是否重复（前中后空格、大小写）
例：计算两个1-100之间整数的和。划分等价类如下：
（1）两个（2）1-100 （3）整数（4）小数（5）汉字（6）特殊字符（7）空（8）空格

2边界值：为了规避程序员经常在边界出现错误。（边界值是对输入或输出的边界值进行测试的一种黑盒测试方法）（注：一般配合等价类使用）
（1）离点（2）上点（3）内点
例：[1-100] 0,101离点 1,100上点 2,99内点
(1 100) 1,100离点 2,99上点 3,98内点

3判定表：多条输入，多条输出，输入输出之间存在逻辑关系。
具体做法：条件桩：条件组合：多个输入进行不同组合（二进制方法进行条件组合）
动作桩：动作项：输出
注：可以将相似情况得到同样结果的组合进行合并，减少测试用例（判定表是覆盖了所有的的测试用例）。如YYN=1，YXN=1，YXX=0，则可以将前两组合并为Y_N=1

等价类划分不能解决：（1）多个输入而且输入之间不同组合产生不同的结果；（2）输出之间存在逻辑关系；（3）等价类无效类每个用例只出现一次，不能覆盖多个无效类并存的情况.
判定表可以通过输入的不同组合，产生不同的结果，而不同的组合方式利用二进制解决
如：
3个输入，可以有23=8种组合方式，即000-111（每次在前一次的二进制排列上加1，一共加7次，即000+1 =001，001+1=010，010+1=011，011+1=100…）

4个输入，可以有24=16种组合方式，即0000-1111（每次在前一次的二进制排列上加1，一共加15次）

注：多条件组合，可以出现空值

4正交试验：所有因子的值两两相交（两个因子的值在同一用例中出现一次），适用于兼容性测试，测试范围小。（多个选项，都是正值，没有逻辑关系）（可以用正交工具）

手工正交表：将需求转换为因子状态表（因子：输入参数，状态：输入参数取值）
注：多条件组合，不允许出现空值

5场景法：设计原则包含基本流（从系统的某个初始状态开始，经过一系列状态后到达终止状态的过程中最主要的一个业务流程）和备选流（以基本流为基础，在经过的每个判定节点处满足不同的触发条件而导致的其他事件流）（流程图是有序的，即各个事件流程是有序的）

一般步骤：（1）构造基本流和备选流（2）根据基本流和备选流构造场景（3）根据场景设计测试用例（4）对每个测试用例补充必要的测试数据

注意：（1）通过画流程图得到基本流和备选流（2）备选流从主流的判断中产生（3）输入的参数从流程图中找出
注：流程有序

6状态迁移：（1）先选中某一状态（能到达最多的状态）；（2）把其能够迁移到的状态依次列于下方（3）然后从最左方状态开始，进行（2），如有重复，抹掉（除了最后一行，其余行的最左列不要有重复）（5）如果还有没覆盖到的状态（一般在第一行），补齐
测试用例设计：
一、深度优先迁移图：
（1）自上而下全部状态（所有的状态迁移都是纵向的）
（2）从最左边开始，其所能达到的状态都是一个测试用例
（3）先从左边纵向依次向下达到所能达到的状态，然后分别迁移到此状态下的横向状态，最后依次去掉前面的一个状态，直到达到本状态为止
（2）广度优先
（3）注：流程无序

7因果图：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
四种因果关系：

约束关系：

8输出域覆盖：覆盖所有的输出，不管输入。
9输入域覆盖：覆盖所有的输入，不管输出。
10异常分析法：断电、断网的异常情况。（重点关注）
11错误猜测法：有经验的人对系统做出判断，找到可能出现错误的地方。
12探索性测试：根据自己的测试经验，尝试性测试系统功能。

白盒测试：

也称结构测试或逻辑驱动测试，对程序内部逻辑结构进行的测试。
主要方法：总体分为静态方法和动态方法。

静态：关键功能是检查软件的表示和描述是否一致，没有冲突或者歧义。如：代码检查、静态结构分析、代码质量度量、文档测试等。
动态：

语句覆盖每个执行语句至少执行一次
判定覆盖每个判定分支取真和取假至少执行一次（无需对应，只要每个判定真假各一次）
条件覆盖每个判定中的每个条件的可能取值至少执行一次（无需对应，只要每个条件都真假各一次）
判定条件覆盖组合判定和条件
条件组合覆盖（多条件覆盖）每个判定中的条件a对，条件b必须各对错一次，条件a错，条件b还必须对错一次
路径覆盖覆盖所有可能执行路径
优点：可以检测代码的每条分支和路径；可以揭示隐藏在代码中的错误；对代码的测试比较彻底。
缺点：耗费比较大；不能检测到代码中遗漏的逻辑；不能直接验证需求的正确性

软件缺陷：

提交一个缺陷前应做什么？（怎么判断一个缺陷的确是缺陷）

1.分离缺陷（防止是人为操作失误或测试用例输入错误导致的缺陷）
2.再现3次

缺陷报告的写作准则：

5C原则：correct准确、clear清晰、concise简洁、complete完整、consistent一致（格式一致）

缺陷报告的内容（组织结构）：

缺陷标题、预处理（比如登录功能需要提供账号密码）、复现步骤、预期结果、实际结果、严重程度、优先级、测试环境、测试版本、测试执行人、日期和时间

缺陷的处理流程（生命周期）：

测试人员提交缺陷报告
测试负责人审核后分配给相关开发人员修改
缺陷修改后由测试人员根据缺陷报告中的修改记录进行返测
返测通过的由负责人关闭，未通过的直接返回开发人员重新修改，再继续返测，直到测试与开发达成统一。

缺陷的严重程度、优先级、状态有哪些？

严重程度：致命缺陷、严重缺陷（主要功能出错）、一般缺陷（细小功能出错，不影响整体功能）、较小错误、意见建议
优先级：缺陷必须立即修复、正常排队等待修复、方便时修复、下一版本修复、不修复
状态：新建/已提交、打开、已拒绝、已修复、已验证、关闭

测试生命周期

测试周期是指从测试项目计划建立到BUG提交的整个测试过程。包括软件项目测试计划，测试需求分析，测试用例设计，测试用例执行，BUG提交五个阶段。软件测试周期并行于软件生命周期，存在于软件生命周期的各个阶段。

软件生命周期

软件生命周期是指软件的产生直到报废的生命周期。包括问题的定义及规划，需求分析，软件设计（概要，详细），软件编码，软件测试（单元测试，集成测试，系统测试，验收测试），运行维护

Web和app测试的区别

首先是web和app的区别：web是b/s架构的，基于浏览器；app是c/s架构的，必须要有客户端。Web测试中只要更新了服务器，客户端就会同步更新，保证每个用户用的客户端一样；app就不能保证完全一致，因为app客户端需要用户主动更新，如果app测试中修改了服务器，就意味着客户端用户使用的所有核心版本都要进行回归测试
性能方面：web主要看响应速度；app还看电量、流量、CPU、内存…
兼容方面：web基于浏览器，主要看电脑硬件、电脑系统；app依赖于手机或平板，关注的系统主要是安卓和ios，还要关心分辨率、屏幕尺寸
App比web测试多一些专项测试：弱网测试，安装、卸载、更新，界面操作、触摸手势等

Android中造成APP闪退的原因总结

弱网络情况下，服务端响应不及时，可能造成闪退。（网络异常引起的）
应用版本太低，会导致不兼容，造成闪退。（有些API在老版本中有,在新版本中没有,造成对象为空引起闪退）
APP的SDK和手机的系统不兼容。
缓存垃圾过多：由于安卓系统的特性，如果长时间不清理垃圾文件。会导致越来越卡，也会出现闪退情况。
设计不合理，1个接口，拉取的数据量太大，请求结果会很慢，且占用大量内存，APP会闪退（比如，我们现在做的记录仪，进入相册列表时候，要拉取所有图片，拉取太慢了，就闪退了）
不同APP间切换，交互测试，可能会出现闪退。
权限问题。

测试管理工具

QC、禅道、jir、redmine、testlink、bugzilla、mantis

怎么测试网络协议

协议测试包括四种类型的测试
1、一致性测试：检测协议实现本身与协议规范的符合程度
2、互操作性测试：基于某一协议检测不同协议实现间互操作互通信的能力
3、性能测试：检测协议实现的性能指标，比如数据传输速度，连接时间，执行速度，吞吐量，并发度，
4、健壮性测试：检测协议是现在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断

负载测试、容量测试、强度测试的区别

负载测试：在一定的工作负荷下，系统的负荷及响应时间。
强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
容量测试：目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能持续处理的最大负荷和工作量，使系统承受超额的数据容量来发现它是否能够正确处理。

测试结束的标准

用例全部测试、覆盖率达到标准、缺陷率达到标准、其他指标达到质量标准。

做好测试用例设计工作的关键

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。
黑盒测试用例设计的关键同样也是比较少的用例覆盖模块输出和输入的接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题。

黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法（常见的联调测试）。系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

WEB应用的测试内容

功能测试（链接测试、表单测试、cookies测试、设计语言测试、数据库测试）
性能测试（连接速度测试、负载测试、压力测试）
可用性测试（导航测试、图形测试、内容测试、整体界面测试）
客户端兼容测试（操作系统，即平台测试、浏览器测试）
安全性测试

功能测试：

（1）链接测试：链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
（2）表单测试：当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
（3）Cookies测试：Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
（4）设计语言测试：Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
（5）数据库测试：在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

性能测试

（1）连接速度测试：用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
（2）负载测试：负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
（3）压力测试：进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。压力测试的区域包括表单、登陆和其他信息传输页面等。

可用性测试

（1）导航测试：导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
（2）图形测试：在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
（3）内容测试：内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的”拼音与语法检查”功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓”相关文章列表”。
（4）整体界面测试：整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

客户端兼容性测试

（1）平台测试：市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
（2）浏览器测试：浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

安全性测试：

（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

设计测试用例时需要考虑哪些方面

1、测试用例需要考虑四个基本要素：输入、输出、操作和测试环境
2、考虑测试类型，如功能测试、性能测试、安全性测试、兼容性测试等

测试工程师应该具备的素质和技能

掌握基本的软件测试理论、客观的本着找出软件存在的问题的态度进行测试、熟练阅读需求规格说明书等文档、以用户的角度看待问题、有强烈的质量意识、细心，耐心和责任心和团队精神、有良好的沟通能力（与开发人员或客户）、积攒以往的测试经验、时刻保持怀疑态度，并且具备缺陷防范的意识、从用户的角度思考问题、风险评估能力

怎么给只有一只手的人设计键盘

1、