- 什么是软件测试?
答:软件测试是为了发现错误而执行程序的过程。
- 软件测试的目的?
答;测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
- 什么是需求文档测试?
答:主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;
- 什么是设计文档测试?
答:测试设计是否符合全部需求以及设计是否合理。
- 请问你了解什么测试方法
（黑盒测试方法）等价类划分，边界值分析，错误推测，因果图法，
（白盒测试方法）逻辑覆盖法，程序插桩技术，基本路径法，符号测试，错误驱动测试
- 测试的类型
测试分为功能测试和非功能测试，非功能测试又可以分为性能测试、压力测试、容量测试、健壮性测试、安全性测试、可靠性测试、恢复性测试、备份测试、协议测试、兼容性测试、可用性测试、配置测试、GUI测试。
- 什么是驱动模块？
答:驱动模块在大多数场合称为”主程序”，它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此写驱动。驱动模块主要完成以下事情：
接受测试输入;
对输入进行判断;
将输入传给被测单元，驱动被测单元执行;
接受被测单元执行结果，并对结果进行判断;
将判断结果作为用例执行结果输出测试报告。
- 什么是桩模块?
答:比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的错误，定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。
- 软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义?
答:大体上来说可分为单元测试,集成测试,系统测试,验收测试。每个阶段又分为以下五个步骤: 测试计划，测试设计，用例设计，执行结果，测试报告。
单元测试集中在每个模块(函数)上，保证源代码的正确性，主要用白盒测试方法。然后是集成测试，集成测试主要考虑各模块之间是否存在问题，主要采用灰盒测试方法。系统测试的目的是确保整个系统的运行以及与其他软件的兼容性。系统测试包括：功能测试，性能测试，可靠性测试，安全性测试等，只需要进行黑盒测试方法。
验收测试是一项确定产品是否能够满足合同或用户所规定需求的测试。它的测试数据通常是系统测试的测试数据的子集。验收测试包括正式验收测试，非正式验收测试：Alpha测试和Beta测试。
Alpha测试(α测试)是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。
Beta测试(β测试)是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。
- 自顶向下测试和自底向上测试
自顶向下测试：是从程序的初始模块开始测试。
（1）该方法会在早期发现顶层的错误。
（2）早期的程序框架可以进行演示
（3）需要开发桩模块辅助测试。有些甚至需要多个桩模块辅助，加大了桩模块本来的错误影响。
（4）测试完一个上层模块后，挑选哪个模块作为下一个测试模块，以及测试的顺序没有唯一的界定标准。
优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。
自底向上测试：是从程序的底层模块开始测试。
（1）I/O操作可以提前测试，更好提交测试用例。
（2）测试后比较容易观察输出。
（3）需要开发驱动模块。
（4）直到最后一个模块提交，程序才能完整的系统测试。
优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
- 请你回答一下单元测试、集成测试、系统测试、验收测试、回归测试这几步中最重要的是哪一步？
这些测试步骤分别在软件开发的不同阶段对软件进行测试，我认为对软件完整功能进行测试的系统测试很重要，因为此时单元测试和集成测试已完成，能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此我认为系统测试很重要。（言之有理即可）
- 什么是白盒测试?
白盒测试，又称逻辑驱动测试,结构测试。它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。
常用白盒测试方法： 静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，也可以借助软件工具（Fxcop）自动进行。动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
语句覆盖每条语句至少执行一次。
判定覆盖每个判定的每个分支至少执行一次。
条件覆盖每个判定的每个条件应取到各种可能的值。
判定/条件覆盖同时满足判定覆盖条件覆盖。
条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
路径覆盖使程序中每一条可能的路径至少执行一次。
- 什么是黑盒测试?
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
- 设计用例的方法、依据有那些?
白盒测试用例设计有如下方法:基本路径测试\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试。这时候依据就是详细设计说明书及其代码结构
黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。
既可以用于黑盒测试，也可以用于白盒测试的方法的是（边界值分析）
- 如果能够执行完美的黑盒测试，还需要进行白盒测试吗?(白盒与黑盒的区别)
答:任何工程产品(注意是任何工程产品)都可以使用以下两种方法之一进行测试。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
是否有不正确或遗漏的功能?
在接口上，输入是否能正确的接受?能否输出正确的结果?
是否有数据结构错误或外部信息(例如数据文件)访问错误?
性能上是否能够满足要求?
是否有初始化或终止性错误?
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
对程序模块的所有独立的执行路径至少测试一遍。
对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
在循环的边界和运行的界限内执行循环体。
测试内部数据结构的有效性等等。
以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量(相对于穷举的巨大数量而言)的有限的测试，在未发现错误时，不能说明程序中没有错误。
- 什么是静态测试?
答:通过运行程序测试软件称为动态测试.通过评审文档、阅读代码等方式测试软件称为静态测试,在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.
静态测试方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。
- 什么是回归测试?
答: 回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。
- 软件的缺陷等级应如何划分?
软件缺陷的等级可以用严重性和优先级来描述；
严重性：衡量缺陷对客户满意度影响的满意程度，分为：
1,致命错误，可能导致本模块以及其他相关的模块异常，死机等问题；
常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误， 如服务器500错误。
2.严重错误，问题局限在本模块，导致模块功能失常或异常退出；
常见的有：功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。
3.一般错误，模块功能部分失效；
常见的有：操作界面错误，边界条件错误，提示信息错误，长时间操作无进度提示，系统未优化，兼容性问题。
4.建议模块，有问题提出人对测试模块的改进建议；
优先级：缺陷被修复的紧急程度：
立即解决（P1级）：缺陷导致系统功能几乎不能使用或者测试不能继续，需立即修复；
高优先级（P2级）：缺陷严重，影响测试，需优先考虑；
正常排队（P3级）：缺陷需要正常排队等待修复；
低优先级（P4级）：缺陷可以在有时间的时候被纠正；
- 针对缺陷采取怎样的管理措施?
要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
所有发现的缺陷(不管是测试发现的还是走读代码发现的)都必须全部即时的、准确的提交到缺陷管理工具中，这是缺陷提交的管理。
缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决;二是方便后面缺陷的分析(保证缺陷相关的信息准确，如龄期等)，这是缺陷状态的管理。
为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。
- 描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程
测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED.
还有问题，REOPENED，状态重新变为“New”，并发邮件通知。
项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
若是，进行处理，resolved并给出解决方法。(可创建补丁附件及补充说明)
开发者收到Email信息后，判断是否为自己的修改范围。
若不是，重新reassigned分配给项目组长或应该分配的开发者。
测试人员查询开发者已修改的bug，进行重新测试。
- 请说一下手动测试与自动化测试的优缺点
手工测试缺点：
重复的手工回归测试，代价昂贵、容易出错。
依赖于软件测试人员的能力。
手工测试优点：
测试人员具有经验和对错误的猜测能力。
测试人员具有审美能力和心理体验。
测试人员具有是非判断和逻辑推理能力。
自动化测试的优点：
对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
可以运行更多更繁琐的测试。是可以在较少的时间内运行更多的测试。
可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。
测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。
自动化测试的缺点：
不能取代手工测试
手工测试比自动测试发现的缺陷更多
对测试质量的依赖性极大
测试自动化不能提高有效性
测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
工具本身并无想像力
- 你觉得测试和开发需要怎么结合才能使软件的质量得到更好的保障
测试和开发应该按照W模型的方式进行结合，测试和开发同步进行，能够尽早发现软件缺陷，降低软件开发的成本。
W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试
- 请问你觉得测试项目具体工作是什么？
搭建测试环境
撰写测试用例
执行测试用例
写测试计划，测试报告
测试，并提交BUG表单
跟踪bug修改情况
执行自动化测试，编写脚本，执行，分析，报告
进行性能测试，压力测试等其他测试，执行，分析，调优，报告
- 请你说一下软件质量的六个特征
功能特征、可靠特征、易用特征、效率特征、可维护特征、可移植特征
- 描述测试工具的功能？
LoadRunner-负载压力测试：预测系统性能。
JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制
功能测试：通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。
Junit：白盒测试工具：针对代码测试
测试管理工具：对测试需求、计划、用例、实施进行管理
测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备
负载压力测试：LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。
功能测试： QTP(quicktest professional):自动测试工具
白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试）
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
测试辅助工具：SVN
测试实例设计
- 请你说一下app性能测试的指标
1、内存：
内存消耗测试节点的设计目标是为了让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。当然关于内存测试，在这里我们需要引入几个概念：空闲状态、中等规格、满规格。
空闲状态指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲；中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短。
内存测试中存在很多测试子项，清单如下：
●空闲状态下的应用内存消耗；
●中等规格状态下的应用内存消耗；
●满规格状态下的应用内存消耗；
●应用内存峰值；
●应用内存泄露；
●应用是否常驻内存；
●压力测试后的内存使用。
2、CPU：
使用Android提供的view plaincopy在CODE上查看代码片派生到我的代码片
adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt来获取；
使用top命令view plaincopy在CODE上查看代码片派生到我的代码片
adbshell top |grep packagename>/address/CPU.txt来获取。
3、流量：
网络流量测试是针对大部分应用而言的，可能还有部分应用会关注网速、弱网之类的测试。
流量测试包括以下测试项：
应用首次启动流量提示；
应用后台连续运行2小时的流量值；
应用高负荷运行的流量峰值。
4、电量：
●测试手机安装目标APK前后待机功耗无明显差异；
●常见使用场景中能够正常进入待机，待机电流在正常范围内；
●长时间连续使用应用无异常耗电现象。
5、启动速度：
第一类：首次启动–应用首次启动所花费的时间；
第二类：非首次启动–应用非首次启动所花费的时间；
第三类：应用界面切换–应用界面内切换所花费的时间。
6、滑动速度、界面切换速度
7、与服务器交互的网络速度
- 请你说一说app测试的工具
功能测试自动化
a) 轻量接口自动化测试
jmeter，
b) APP UI层面的自动化
android：UI Automator Viewer，Android Junit，Instrumentation，UIAutomator，
iOS:基于Instrument的iOS UI自动化，
性能测试
a) Web前端性能测试
网络抓包工具：Wireshark
网页文件大小
Webpagetest pagespeed insight chrome adb
b) APP端性能测试
Android内存占用分析：MAT
iOS内存问题分析：ARC模式
Android WebView性能分析：
iOS WebView性能分析
c) 后台服务性能测试
负载、压力、耐久性、可拓展性、基准
工具：apacheAB、Jmeter、LoadRunner，
专项测试
a) 兼容性测试
手工测试：操作系统，分辨率，rom，网络类型
云平台：testin，脚本编写，Android。
b) 流量测试
Android自带的流量管理，
iOS自带的Network tcpdump抓包
WiFi代理抓包：Fiddler
流量节省方法：压缩数据，json优于xml；WebP优于传统的JPG，PNG；控制访问的频次；只获取必要的数据；缓存；
c) 电量测试
基于测试设备的方法，购买电量表进行测试。
GSam Battery Monitoe Pro
iOS基于Instrument Energy工具
d) 弱网络测试
手机自带的网络状况模拟工具
基于代理的弱网络的模拟:
工具：windows：Network Delay Simulator
Mac：Network Link Conditioner
- 请你说一说bug的周期，以及描述一下不同类别的bug
1、New:（新的）
当某个“bug”被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New
2、Assigned（已指派的）
当一个bug被指认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”
3、Open（打开的）
一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”
4、Fixed（已修复的）
当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
5、Pending Reset（待在测试的）
当bug被返还到测试组后，我们将bug的状态设置为Pending Reset”
6、Reset(再测试)
测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”
7、Closed（已关闭的）
如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”
8、Reopen（再次打开的）
如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”
9、Pending Reject（拒绝中）
如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”
10、Rejected(被拒绝的)
测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”
11、Postponed（延期）
有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“
不同的Bug类型：
• 代码错误
• 界面优化
• 设计缺陷
• 配置相关
• 安装部署
• 安全相关
• 性能问题
• 标准规范
• 测试脚本
• 其他
- 请问你怎么测试网络协议
协议测试包括四种类型的测试
一致性测试：检测协议实现本身与协议规范的符合程度
互操作性测试：基于某一协议检测不同协议实现间互操作互通信的能力
性能测试：检测协议实现的性能指标，比如数据传输速度，连接时间，执行速度，吞吐量，并发度，
健壮性测试：检测协议是现在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断。
- 请你说一说简单用户界面登陆过程都需要做哪些分析
一、功能测试
输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。
输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。
登录成功后能否能否跳转到正确的页面
用户名和密码，如果太短或者太长，应该怎么处理
用户名和密码，中有特殊字符（比如空格），和其他非英文的情况
记住用户名的功能
登陆失败后，不能记录密码的功能
用户名和密码前后有空格的处理
密码是否非明文显示显示，使用星号圆点等符号代替。
牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者），刷新或换一个按钮是否好用
登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
输入密码的时候，大写键盘开启的时候要有提示信息。
什么都不输入，点击提交按钮，检查提示信息。
二、界面测试
布局是否合理，testbox和按钮是否整齐。
testbox和按钮的长度，高度是否复合要求。
界面的设计风格是否与UI的设计风格统一。
界面中的文字简洁易懂，没有错别字。
三、性能测试
打开登录页面，需要的时间是否在需求要求的时间内。
输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。
模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。
四、安全性测试
登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)。
用户名和密码是否通过加密的方式，发送给Web服务器。
用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript 验证。
用户名和密码的输入框，应该屏蔽SQL注入攻击。
用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）。
防止暴力破解，检测是否有错误登陆的次数限制。
是否支持多用户在同一机器上登录。
同一用户能否在多台机器上登录。
五、可用性测试
是否可以全用键盘操作，是否有快捷键。输入用户名，密码后按回车，是否可以登陆。输入框能否可以以Tab键切换。
六、兼容性测试
不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
同种浏览器不同版本下能否显示正常且功能正常。
不同的平台是否能正常工作，比如Windows, Mac。
移动设备上是否正常工作，比如Iphone, Andriod。
不同的分辨率下显示是否正常。
七、本地化测试
不同语言环境下，页面的显示是否正确。
