那些口口声声，说一代不如一代的人们，应该看看你们，像我一样，看看你们，满怀羡慕:现代互联网的成果被层层打开，所有的开源代码可以被尽情享用，像是专门为你们准备的礼物自由学习各种编程语言，精通框架和数据库，研究最新的技术，deliver 下一代产品，因为互联网的发展，你们拥有了世界上最优质的教育资源。世界各地的人可以汇聚在同一个课堂

你们只凭相同的兴趣，就能结交千万个可以一起奋斗的朋友，你们有幸，遇到这样的时代

但是时代更有幸，遇见加班到凌晨的你们，我看着你们，满怀敬意：向你们的付出致敬

十年寒窗，朝九晚九，非七即六，向你们的高效致敬，因为你们，那些所谓的次日达、5G，已不再是神话，向你们的专业致敬，因为你们

我们的祖国拥有了自己的研发能力

世界开始注视中国，因为你们，这个世界会更敬重中国，因为一个国家真正的脊梁，就是这个国家的科学技术，技术的道路崎岖漫长

你可能会和产品经理各种讨论，你可能会遇到各种 bug，你可能会遇到无法解释的 error

但不必悲伤，不必心急，你们已经在书写历史、改写未来，我们这一代人的想象力不足以想象出未来的产品，如果你们依然需要我们的祝福，那么，奔涌吧，后浪，在科技的长河中勇猛向前。

没有背诵，何必面试，那些年我们背过的面试题！

学习从来不是一件容易的事，基本功练了一大堆，始终无法融会贯通？害怕宝剑未佩妥，出门已是江湖，不要垂头丧气，显矮。咔嚓一声,亦庄亦谐的面试题来了！是它，是它，就是它，我们的英雄小哪吒！拥有此秘籍者，进可攻北上广，退可守江浙沪，横扫东三省，平走云贵川！同学们跟着面试题一起好好学习。引用村上春树的一句话：“当你穿过了暴风雨，你就不再是原来的那个人了”

出来混，最重要的不是讲义气，

而是出来！

学技术，最重要的不是怎么学，

而是开始学！

 

多少有志青年，想得太多，做得太少。

没开始时，在“学什么”中纠结，

开始之后，在“怎么学”中迷茫，

以梦为马，越骑越傻，

诗和远方，越走越慌……

 

急你所急，想你所想，

厦门北大青鸟最新版面试题为你而来！

 

一、  软件测试工程基础

0.b/s架构和c/s架构区别

对比C/S与B/S的不同。

C/S架构的优点：

1 C/S架构的界面和操作可以很丰富。（客户端操作界面可以随意排列，满足客户的需要）

2 安全性能可以很容易保证。（因为只有两层的传输，而不是中间有很多层。

3 由于只有一层交互，因此响应速度较快。（直接相连，中间没有什么阻隔或岔路，比如QQ，每天那么多人在线，也不觉得慢）

C/S架构的缺点：

可以将QQ作为类比：

1 适用面窄，通常用于局域网中。

2 用户群固定。由于程序需要安装才可使用，因此不适合面向一些不可知的用户。

3 维护成本高，发生一次升级，则所有客户端的程序都需要改变。

B/S架构的优点：

1、客户端无需安装，有Web浏览器即可。 
2、BS架构可以直接放在广域网上，通过一定的权限控制实现多客户访问的目的，交互性较强。 
3、BS架构无需升级多个客户端，升级服务器即可。可以随时更新版本，而无需用户重新下载啊什么的。

B/S架构的缺点：

1、在跨浏览器上，BS架构不尽如人意。 
2、表现要达到CS程序的程度需要花费不少精力。 
3、在速度和安全性上需要花费巨大的设计成本，这是BS架构的最大问题。 
4、客户端服务器端的交互是请求–响应模式，通常需要刷新页面，这并不是客户乐意看到的。（在Ajax风行后此问题得到了一定程度的缓解）

 

何种情况应该用C/S架构，何种情况用B/S架构。它们之间的优缺点是什么。

日常生活中哪个是C/S架构的，哪个又是B/S架构的。

C/S：QQ;LOL;各种电脑上安装的软件，

B/S：一刀999血，很多网游等

发展前景

1、 C/S和B/S各有优势，C/S在图形的表现能力上以及运行的速度上肯定是强于B/S模式的，不过缺点就是他需要运行专门的客户端，而且更重要的是它不能跨平台，用c++在windows下写的程序肯定是不能在linux下跑的。但是比B/S安全

2、B/S模式就，它不需要专门的客户端，只要浏览器，而浏览器是随操作系统就有的，方便就是他的优势了。 而且，B/S是基于网页语言的、与操作系统无关，所以跨平台也是它的优势，而且以后随着网页语言以及浏览器的进步， B/S在表现能力上的处理以及运行的速度上会越来越快，它的缺点将会越来越少。尤其是HTML5的普及，在图形的渲染方面以及音频、文件的处理上已经非常强大了。 不过，C/S架构也有着不可替代的作用。

老刘认为：将来将是B/S架构的世界，电脑只要有一个浏览器既可以，不需要安装软件

因为：

1、分布性：可以随时随地进行查询和浏览等业务；

2、功能业务扩展比较方便：增加服务器的功能，就能增加浏览器端的功能；

3、维护简单方便：改变服务器端数据即可以实现所有用户同步更新；

4、开发简单，共享性强，成本低，数据可以持久存储在服务器端而不必担心数据的丢失

1.  阐述软件生命周期都有哪些阶段？常见的软件生命周期模型有哪些？

软件生命周期是指一个计算机软件从功能确定、设计，到开发成功投入使用，并在使用中不断地修改、增补和完善，直到停止该软件的使用的全过程（从酝酿到废弃的过程）生命周期从收到应用软件开始算起，到该软件不再使用为止。它有如下各方面的内容： 初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测 试、维护、升级、再测试、逐步淘汰 (phase-out)、等等，

瀑布模型，迭代式模型，快速原型模型，螺旋模型

2.  什么是版本控制，常用的版本控制系统有哪些？

版本控制（Revision control ）是一种软体工程技巧，籍以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。

Git(读音为/gɪt/。)是一个开源的分布式555555555版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。

Git 是 Linus Torvalds 为 了 帮 助 管 理 Linux 内 核 开 发 而 开 发 的 一 个 开 放 源 码 的 版 本 控 制 软 件 。https://git-scm.com/doc

SVN 是 Subversion 的简称，是一个开放源代码的版本控制系统，相较于 RCS 、CVS，它采用了分支管理系统，

它 的 设 计 目 标 就 是 取 代 CVS 。 互 联 网 上 很 多 版 本 控 制 服 务 已 从 CVS 迁 移 到 Subversion 。https://tortoisesvn.net/support.html

3.  简述软件测试与软件开发之间的关系？

（1）项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。

（2）需求分析阶段：确定测试需求分析、系统测试计划的制定，评审后成为管理项目。测试需求分析是对产品

生命周期中测试所需求的资源、配置、每阶段评判通过的规约；系统测试计划则是依据软件的需求规格说明书，制

定测试计划和设计相应的测试用例。

（3）详细设计和概要设计阶段：确保集成测试计划和单元测试计划完成。

（4）编码阶段：由开发人员进行自己负责部分的代码的测试。在项目较大时，由专人进行编码阶段的测试任务。

（5）测试阶段（单元、集成、系统测试）：依据测试代码进行测试，并提交相应的测试状态报告和测试结束报告。

开发和测试是一个有机的整体！在产品的发布之前，开发和测试是循环进行的， 测出的缺陷要经开发人员修改后继续测试。在开发的同时测试经理开始编写测试用例，测 试文档要参考开发文档，所以开发和测试是不可分割的，少了任何一个都不能开发出产品。

从角色方面看，像理论和实验的关系，开发人员通过自己的想象创造出一套思想，之 后测试人员再对它进行检验、证伪，开发人员再修改的过程从而不断丰富产品。从方法方 面看，是演绎和归纳的关系，一个要掌握大量的技术，一个要不断的从实例中学习。因这 两方面的不同，所以开发和测试看上去做的工作很不一样。

开发与测试是相辅相承、密不可分的，开发人员开发出新的产品后要通过测试判断产 品是否完全满足用户的需求。如果发现缺陷，提交给开发人员进行修复，然后再转交测试 人员进行回归测试，直到产品符合需求规格说明。

一个符合用户需求的产品是开发和测试 共同努力的成果。

4.常见测试模型有哪些？

 

特点：这是一种古老的瀑布模型，反映了实际和测试之间的关系

局限：仅仅把测试过程作为编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，如果前面设计错误，得一直到后期的验收测试才被发现，耗时耗力。

 

特点：测试与开发同时进行，在 V 模型的基础上，增加了在开发阶段的同步测试

局限：仍然不支持迭代，减少了一定错误发生率，但是需按照流水线进行设计、编码和测试

5.编写测试计划的目的是？

使测试工作顺利进行；使项目参与人员沟通更舒畅；使测试工作更加系统化。

6.测试计划编写的六要素？

why——为什么要进行这些测试

what—测试哪些方面，不同阶段的工作内容

when —测试不同阶段的起止时间

where —相应文档，缺陷的存放位置，测试环境等

who—项目有关人员组成，安排哪些测试人员进行测试

how—如何去做，使用哪些测试工具以及测试方法进行测试。

7.项目版本执行过程中，测试人员如何把控测试进度？

在项目的系统测试过程中，测试负责人要及时了解测试进度，跟踪 BUG 提交、修复及验证情况以及系统的拷机情况。

在开发初期阶段，测试组执行 BBFV 时，很多模块、功能点的开发完成进度和原计划会存在一定的偏差，就需要测试负责人动态的刷新 WBS 计划，根据实际的开发进度调整测试计划。

在开发阶段，存在版本编译不出来导致无法测试，开发人员修复代码太随意导致版本稳定性反复，需求变更过大导致后端测试开发变更严重等现象，会导致测试工作无法正常进行。就需要测试负责人及时反馈出来，根据项目本身的特点进行对应的处理。

当测试进度出现延期时，要及时确认问题原因，如果是问题协查导致，则需及时与研发人员进行沟通协商，看问题是否必须在测试环境进行排查，若为必现问题可与研发协商要求其在自己环境进行排查，若必须占用测试环境，则需及时调整测试计划，若因此可能影响版本的发布，则应及时与 SE 确认。

若发现有较多 BUG 未解决，则应主动联系 SE 及研发人员召开 BUG 会确定问题的解决时间。若发现有较多 BUG未验证，则应提醒项目组的测试人员及时进行验证，对于一些拷机或非必现的 BUG，建议测试人员在此 BUG 上现做拷机标记，连续拷机一周未再复现的做关闭处理，若再次复现则继续进行排查。

疑难问题的跟控：比较难复现的问题，怎么去尝试复现。比较难定位的问题，怎么驱动、反馈给 SE，协调开发人员定位问题。比较难处理的问题，怎么跟控反馈进度等每天下班前需确认拷机内容，每天上班第一件事需确认拷机结果，只有这样才能保证拷机的效果，实现拷机的真正意义。

8.测试人员在软件开发过程中的任务是什么？

寻找 Bug ；避免软件开发过程中的缺陷；衡量软件的品质；关注用户的需求。

总的目标是：确保软件的质量。

 

9. 请列出你所知道的软件测试种类，至少 5 项？

 

性能测试：性能测试是为了描述测试对象与性能相关的特征并对其进行评价而实施和执行的一类测试。它主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项指标进行测试。通常把性能测试、负载测试、压力测试等统称为性能测试。

    负载测试：是通过逐渐增加系统的负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统所能承受的最大负载量的测试。简而言之，负载测试时通过逐步加压的方式来确定系统的处理能力和能够承受的各项阈值。

    压力测试：是通过逐步增加系统的负载，测试系统性能的变化，并最终确定在什么负载条件下，系统性能处于失效状态，并获得系统能提供的最大服务级别的测试。压力测试是逐步增加负载，使系统某些资源达到饱和和甚至失效。

    配置测试：主要是通过对被测试软件的软硬件配置进行测试，找到系统各项资源的最优分配原则。配置测试能充分利用有限的软硬件资源，发挥系统的最佳处理能力，同时可以将其与其他性能测试类型联合应用，从而为系统提供重要依据。

    并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，几乎所有的性能测试都会涉及一些并发测试。

    容量测试：在一定的软、硬件条件下，在数据库中构造不同数量级的记录数量，通过运行一种或多种业务场景在一定虚拟用户数量的情况下，获取不同数量级别的性能指标，从而得到数据库能够处理的最大会话能力，最大容量等。系统可处理同时在线的最大用户数，通常和数据库有关。

    可靠性测试：通过给系统加载一定的业务压力（如CPU资源在70%~90%的使用率）的情况下，运行一段时间，检查系统是否稳定因为运行时间较长，通常可以测试出系统是否有内存泄漏等问题。

    失败测试：对于有冗余备份和负载均衡的系统，通过失败测试来检验如果系统局部发生故障，用户能否继续使用系统，用户受到多大的影响，如几台机器做均衡负载，一台或几台机器垮掉后系统能够承受的压力

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

黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性， 只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。

白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。

单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。

集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。

系统测试：在所有都考虑的情况下，对系统进行测试。

验收测试：第三方进行的确认软件满足需求的测试。

11. 黑盒测试和白盒测试常用的测试方法有哪些，举个例子？

黑盒有等价类划分法，边界分析法，因果图法和错误猜测法。

白盒有逻辑覆盖法，循环测试路径选择，基本路径测试。

例子：在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首先利用等价类划分法，可以一个或多个结果是 OK 的测试用例，然后确认多个 NG 的测试用例， 然后利用边界值分析法，可以对结果分别是 OK 和 NG 的测试用例进行扩展和补充。

12.简述黑盒测试和白盒测试的优缺点？

※ 黑盒测试的优点有：

1.比较简单，不需要了解程序内部的代码及实现；

2.与软件的内部实现无关；

3.从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；

4.基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

5.在做软件自动化测试时较为方便。

※ 黑盒测试的缺点有：

1.不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的  30%；

2.自动化测试的复用性较低。

※ 白盒测试的优点有：

1.帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

※ 白盒测试的缺点有：

1.程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销会非常大。

13. 在没有产品说明书和需求文档的情况下能够进行黑盒测试的设计吗？

能，可以通过其他工作内容去替代产品说明书和需求文档

根据客户的功能点整理测试需求追溯表

根据开发人员的 Software Specification List（软件） 整理功能测试点

开展项目跨部门讨论会，主要整理对功能点的理解和认识

测试人员整理用例需求疑问提交项目组或者产品

项目内部的用例品胜

邮件客户代表确认部分争议问题

项目的 Demo （演示）和部分已经开发的系统

参考同行业和竞争对手的类似产品

交叉模块之间的测试

咨询客户或相关者

14. 单元测试的策略有哪些，主要内容有哪些？

    逻辑覆盖，循环覆盖，同行评审，桌前检查，代码走查，代码评审，静态数据流分析

15.白盒测试逻辑覆盖有哪几种覆盖标准，覆盖率最高的是什么？

    语句覆盖,分支覆盖,条件覆盖 ,路径覆盖,分支条件覆盖,覆盖率最高的是路径覆盖

16. 测试结束的标准是什么？

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

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

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

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

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

17.软件测试的原则是什么？

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

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

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

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

5) 软件测试的原则

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

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

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

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

18.什么是测试用例，测试用例的基本要素？

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

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

19.描述测试用例设计的完整过程？

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

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

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

    注意

l 选用适合的用例管理工具（如 word，excel ）

l 用例一定要及时更新（补充新的想法，删除过时的需求）

l 做好用例分级

l 做好用例评审，写用例之前可以征询相关人员的意见，如果评审通过可以参考其执行测试，如果未通过，需要继续修改直到通过为止。

可以考虑结对编写，这个是不错的主意

要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等

注意把握适当的颗粒度

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

测试项目：杯子

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

界面测试：查看杯子外观

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

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

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

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

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

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

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

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

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

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

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

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

(1)硬度：是否达到设计标准。

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

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

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

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

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

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

(3)易用性测试。

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

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

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

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

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

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

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

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

21. 一个身份证号码输入框，怎么设计用例？

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

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

校验末位是 X 的情况

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

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

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

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

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

22.登录功能怎么设计测试用例？

具体需求：

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

此题的考察目的：

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 、高对比度下能否显示正常（视力不好的人使用）

23. 好的测试用例有哪些特点？

质量属性：

l 正确性：确保测试标题描述部分的内容正确性。

l 经济性：只为确定需要的目的设计相应的测试步骤。

l 可重复性：自我一致性，即不管谁执行此用例，结果一样。

l 适应性：既能适应短期需要，又能考虑长远需要。

l 可追踪性：用例能追踪到一个具体的需求。

l 自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。

l 结构化和可测试性

l 含有规范的测试标题和编号。

l 含有一个确定的测试某一个特定需求的目的。

l 含有关于测试方法的描述。

l 指定条件信息–环境、数据、预置的条件测试、安全入口等。

l 含有操作步骤和预期结果。

l 陈述任何辅助证据，例如截图报告并确保这些东西妥善保存。

l 确保测试环境的干净（即用例不会影响整个环境）。

l 描述时使用主动语气结构。

l 操作步骤不要超过 15 步。

l 确保单个用例测试执行时用时不超过 20 分钟。

l 自动化脚本用例添加必要的注释，比如目的、输入和期望结果。

l 如果可能，建议提供可选择性的预置条件测试。

l 用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。

配置管理：

l 采用命名和编号规范归档。

l 保存为特定的格式，文件类型。

l 用例版本是否与当前被测试软件版本一致（对应）。

l 包含用例需要的相应测试对象，如特定数据库。

l 存档阅读。

l 存档时按角色控制访问方式

l 当网络备份时存档。

l 离线归档

24.软件缺陷的生命周期？

 

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

25.缺陷描述（报告单）中应该包括哪些内容？

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

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

26.如何提高缺陷的记录质量？

通用 UI 要统一、准确；尽量使用业界惯用的表达术语和表达方法；使用业界惯用的表达术语和表达方法，保证

表达准确，体现专业化；每条缺陷报告只包括一个缺陷；不可重现的缺陷也要报告；明确指明缺陷类型；明确指明

缺陷严重等级和优先等级；描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置；0

短行之间使用自动数字序号，使用相同的字体、字号、行间距； 每一个步骤尽量只记录一个操作；确认步骤完整，

准确，简短；根据缺陷，可选择是否进行图象捕捉； 检查拼写和语法缺陷；尽量使用短语和短句，避免复杂句型句

式；缺陷描述内容

27.如果一个缺陷被提交后，开发人员认为不是问题，怎么处理？

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

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

l v. 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确

认的直接依据；

l vi.如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；

l vii.根据用户的一般使用习惯，来确认是否是缺陷；

l viii.与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；

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

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

做出决定。

28. 软件具有几个特点，请详细说明。

软件具有8个特点：

(1) 软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性。

(2) 软件的生产与硬件不同，它没有明显的制造过程。对软件的质量控制，必须着重在软件开发方面下功夫。

(3) 在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。然而它存在退化问题，必须要对其进行多次的修改与维护。

(4) 软件的开发和运行常常受到计算机系统的制约，对计算机系统有着不同程度的依赖性。为了解除这种依赖性，在软件开发中提出了软件移植的问题。

(5) 软件的开发至今尚未完全摆脱人工艺的开发方式。

(6) 软件本身是复杂的。软件的复杂性可能来自它所反映的实际问题的复杂性，也可能来自程序逻辑结构的复杂性。

(7) 软件成本相当昂贵。软件的研制工作需要投入大量的、复杂的、高强度的脑力劳动，它的成本是比较高的。

(8) 相当多的软件工作涉及到社会因素。许多软件的开发和运行涉及机构、体制及管理方式等问题，它直接影响到项目的成败。

 

29.软件的分类方法都有哪些？

软件的分类方法有如下 4种：

（1）按软件的功能分类

  （2）按软件服务对象的范围分类

  （3）按开发软件所需要的人力、时间以及完成的源程序行数分类。

（4）按软件工作方式分类

       按软件的工作方式分为：实时处理软件、分时软件、交互式软件、批处理软件。

30.软件测试的概念 

软件测试是软件工程中的一个环节，是开发项目整体的一部分。软件测试是有计划有组织的，是保证软件质量的一种手段，它是软件工程中一个非常重要的环节。因此，可以认为它是伴随软件工程的诞生而诞生的，伴随着软件复杂程度的增加、规模的增大，软件测试作为一种能够保证软件质量的有效手段，越来越受到人们的重视，软件测试最终目的是使产品达到完美。

 

31.软件测试的方法有哪些?

软件的测试方法有3种，即用试题测试、用新旧两个系统作平行处理测试和软件测试自动化工具测试。

 

32.请简要说明软件测试阶段的任务。

    软件测试阶段有以下几方面的任务：

(1) 制定测试大纲；

(2) 制作测试数据；

（3）程序测试；

（4）功能测试；

（5）子系统测试；

（6）系统测试；

（7）系统接口测试；

（8）写出测试报告书；

（9）向下阶段工作提交系统运行、维护手册的草案。

（10）制定测试大纲。

 

33.说明软件测试人员需要的知识结构。

★ 需要具有懂得计算机的基本理论，又有一定开发经验的人员；

★ 需要具有了解软件开发的基本过程和特征，对软件有良好的理解能力，掌握软件测试相关理论及技术的人员；

★ 需要具有软件业务经验的人员；

★ 需要根据测试计划和方案进行软件测试；针对软件需求开发测试模型，制定测试方案，安排测试计划，搭建测试环境, 进行基本测试,设计简单的测试用例；

★ 需要具有规划设计环境；编制测试大纲并设计测试用例；对软件进行全面测试工作的人员；

★ 需要具有编制测试计划；评审测试方案,规范测试流程及测试文档；分析测试结果,管理测试项目；

★ 需要会操作软件测试工具的人员。

 

34.软件测试人员需要的素质都有哪些？请简要说出。

    ① 沟通能力

    ② 技术能力

③ 自信心

④ 洞察力

⑤ 探索精神

⑥ 不懈努力

⑦ 创造性

    ⑧ 追求完美

⑨ 判断准确

⑩ 老练稳重和说服力

35.白盒测试有哪两个分类？

（1）静态测试

静态测试是测试中很重要的方法之一。它不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试。静态测试大约可以找出25%—60%的逻辑错误。

（2）动态测试：

输入一组预先按照一定的测试准则设计的实例数据驱动运行程序，检查程序功能是否符合设计要求，发现程序中错误的过程。

 

36.说出白盒测试的4个原则。

1）保证一个模块中所有路径至少被测试一次；

    2）所有逻辑值都要测试真和假两种情况；

    3）检查程序的内部数据结构是否有效；

    4）再上、下边界及可操作范围内运行所有循环。

 

37.详细说明白盒测试方法要注意的问题。

在白盒测试中，可以使用各种测试方法进行测试。但是，测试要考虑五点问题。

   （1）测试中，尽量先用自动化工具来进行静态结构分析；

（2）测试中建议先从静态测试开始，如：静态结构分析、代码走查和静态质量度量，然后进行动态测试，如：覆盖率测试；

   （3）利用静态分析的结果作为依据，再使用代码检查和动态测试的方式对静态分析结果进行进一步确认，提高测试效率及准确性；

   （4）覆盖率测试是白盒测试中的重要手段，在测试报告中可以作为量化指标的依据，对于软件的重点模块，应使用多种覆盖率标准衡量代码的覆盖率；

（5）在不同的测试阶段，测试的侧重点不同：

      ★ 在单元测试阶段，以代码检查、逻辑覆盖为主；

      ★ 在集成测试阶段：需要增加静态结构分析、静态质量度量；

      ★ 在系统测试阶段：在黑盒测试的基础上，白盒测试技术配合黑盒测试技术进行系统测试。

 

38.请简要写出白盒测试常用的7类技术。

1) 逻辑覆盖法

2) 插桩技术

3) 基本路径测试法

4) 域测试法

5) 符号测试

6) Z路径覆盖法

7) 程序变异测试法

 

39.逻辑覆盖主要测试哪8各方面的覆盖率？

（1） 语句覆盖

（2） 判定覆盖

（3） 条件覆盖

（4） 条件判定组合覆盖

（5） 多条件覆盖

（6） 修正条件判定覆盖

（7） 组合覆盖

（8） 路径覆盖

40.请详细叙述黑盒测试的基本概念。

黑盒测试（Black-Box Testing）又称为数据驱动测试或基于规格说明的测试。黑盒测试就是把程序看作一个不能打开的黑盒子，不考虑程序内部逻辑结构和内部特性的情况下，测试程序的功能，测试者要在软件的接口处进行，它只检查程序功能是否按照规格说明书的规定正常使用，程序是否能接收输入数据而产生正确的输出信息，以及性能是否满足用户的需求，并且保持数据库或外部信息的完整性。通过测试来检测每个功能是否都能正常运行，因此黑盒测试又可称为从用户观点和需求进行出发的测试。

 

41.黑盒测试都有哪些优点？请说明。

黑盒测试的优点：

★ 从产品功能角度测试可以最大程度满足用户的需求。

★ 相同动作可重复执行，最枯燥的部分可由机器完成。

★ 依据测试用例针对性地找寻问题，定位更为准确，容易生成测试数据。

★ 将测试直接和程序/系统要完成的操作相关联。

 

42.黑盒测试都有哪些缺点？请说明。

    黑盒测试的缺点：

★ 代码得不到测试。

★ 如果规格说明设计有误，很难发现。

★ 测试不能充分的进行。

★ 结果取决于测试用例的设计。

 

43.请详细说明黑盒测试的方法。

    因为黑盒测试是一种基于证明功能需求和用户最终需求的测试方法，所以在选择测试，设计测试方法方面有如下几种。

★ 等价类划分法；

★ 边界值分析法；

★ 因果图法；

★ 判定表驱动测试；

★ 场景法；

★ 功能图法；

★ 错误推测法；

★ 正交试验设计法。

在实际测试工作中，往往是综合使用各种方法才能有效提高地提高测试效率和测试覆盖率，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效地提高测试水平和测试的效率。

 

44.黑盒测试的原则都有哪些？

★ 根据软件规格说明书设计测试用例，规格说明书的正确性是至关重要的。

★ 有针对性的地找问题，并且正确定位等价类

★ 功能是否有缺陷或错误现象？ 

★ 根据测试的重要性来确定测试等级和测试重点，减少程序可能出现的缺陷。

★ 在接口处，输入的信息是否能正确接受？接受后能否输出正确的结果？ 

★ 认真选择测试策略，尽可能发现程序的数据结构错误或外部信息访问错误，站在用户立场上进行测试。

45.什么是测试用例。

测试用例（Test Case）通俗一点来讲就是编写（编制）一组前提条件、输入、执行条件、预期结果以完成对某个特定需求或目标测试的数据，体现测试方案、方法、技术和策略的文档。

 

46.测试用例主要包括哪些内容。

完整的测试用例通常包括：

★ 测试用例的编号；

★ 测试日期；

★ 测试用例设计人员和测试人员；

★ 测试用例的优先级；

★ 测试标题；

★ 测试目标；

★ 测试环境；

★ 输入数据/动作；

★ 测试的操作步骤；

★ 测试预期的结果。

 

47.请写出设计测试用例所需的文档资料。

设计测试用例所需要的文档资料包括：

★ 软件需求说明书；

★ 软件设计说明书；

★ 软件测试需求说明书；

★ 成熟的测试用例（案例库或财富库）。

 

48.简述白盒测试用例的设计技术和目的。

（1）白盒测试用例的设计技术如下：

★  逻辑覆盖；

★  基本路径测试。

（2）采用白盒测试技术设计用例的目的主要是：

★  每个模块中的所有独立路径至少被执行一次；

★  所有的逻辑值必须测试真、假两个分支；

★  在边界值内和可操作范围至少循环一次；

★  检查数据的内部结构保证其有效的实现预定功能。

 

49.简述黑盒测试用例的设计技术和目的。

（1）黑盒测试用例设计技术如下：

★  等价类划分；

★  边界值分析；

★  错误推测；

★  因果图。

（2）采用黑盒测试技术设计用例的主要目的是：

★  检查功能是否实现或遗漏；

★  检查人机交互界面是否出错；

★  数据库读取、更新操作出错；

★  性能特性是否得到满足。

50.简述单元测试的目的。

单元测试目的主要有以下几点：

（1）检查单元模块内部的错误，为软件的评审验收提供依据。

（2）单元测试是以程序设计说明书和之前所作的测试数据（正常的和错误的）为指导，测试模块内重要的路径，以检查出错误；

（3）检验信息能否正确地流入和流出单元；

（4）在单元测试工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。

（5）在为限制数据加工而设置的边界处，能否正确工作。

（6）单元的运行能否做到满足特定的逻辑覆盖。

（7）单元中发生了错误，其中的出错处理措施是否有效。

 

51.简述单元测试的主要任务。

单元测试的主要任务有：程序语法检查、程序逻辑检查、模块接口测试、局部数据结构测试、路径测试、边界条件测试、错误处理测试、代码书写规范检查。

 

52.单元测试主要需要测试哪8点？

程序语法检查、程序逻辑检查、模块接口测试、局部数据结构测试、路径测试、边界条件测试、错误处理测试，代码书写规范检查。

 

53.局部数据结构测试主要表现形式是哪6个方面？

（1）局部数据结构测试最常见的积累错误；

（2）不适合或者不相容的类型说明；

（3）变量无初值；

（4）变量初始化或者缺省值有错；

（5）不正确的变量名或不正确的截断；

（6）出现上溢、下溢或地址异常。

 

54.边界条件测试主要测试的是哪3点？

（1）程序内有一个n次循环，这个n次循环应该是1~n，而不是0~n；

（2）由小于 小于等于 等于 大于 大于等于 不等于确定的比较值出错；

（3）出线上溢、下溢和地址异常问题。

55.功能测试的基本概念是什么？请简述之。

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

功能测试一般须在完成单元测试后集成测试前进行，而且是针对应用系统进行各功能测试。一般应用系统有多个功能（子系统），功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用、是否实现了产品规格说明书的要求、是否能适当地接收输入数锯而产生正确的输出结果等。功能测试，包括用户界面测试、各种操作的测试、不同的数据输入、逻辑思路、数据输出和存储等的测试。对于功能测试，针对不同的应用系统，其测试内容的差异很大，但一般都可归为界面、数据、操作、逻辑、接口等几个方面。

 

56.功能测试的基本要求是什么？请简述之。

功能测试（Functional testing）是基于产品功能说明书并根据产品特征、操作描述和用户方案，来测试产品的每个功能是否都能正常使用、是否达到了产品规格说明书的要求。功能测试只需要考虑它的功能点不需要考虑软件的内部结构及代码等。功能测试包括用户界面测试、各种操作的测试、不同的数据输入、逻辑思路、数据输出和存储等的测试。

 

57.请说明功能测试的重点。

功能测试工作一般由程序员担当，测试的结果交系统设计、测试人员审核通过。

功能测试的重点应注意如下两大点内容：

A  整体性

（1） 符合标准和规范；

（2） 直观性；

（3） 一致性；

（4） 灵活性。

B  重点性

（1） 确认每个功能是否都能正常使用， 每项功能符合实际要求；

（2） 是否实现了产品规格说明书的要求；

（3） 否能适当地接收输入数据而产生正确的输出结果；

（4） 用户界面测试、是否有相应的提示框、适当的错误提示；

（5） 系统的界面是否清晰、美观；

（6） 菜单、按钮操作正常、灵活，能处理一些异常操作；

（7） 是否能接受不同的数据输入（能接受正确的数据输入，对异常数据的输入可以进行提示、容错处理）；

（8） 数据的输出结果准确，格式清晰，可以保存和读取；

（9） 功能逻辑清楚，符合使用者习惯；

（10）系统的各种状态按照业务流程而变化，并保持稳定；

（11）支持各种应用的环境，能配合多种硬件周边设备，与外部应用系统的接口有效；

（12）软件升级后，能继续支持旧版本的数据 。

 

58.请详细说明Web功能测试的方法主要包括的内容。

Web功能测试通常又称为网站（网页）测试。测试的方法主要有如下几点：

1. 页面链接检查：每一个链接都要有对应的页面，并且页面之间切要正确。

2. 相关性检查：检查删除/增加其中每一项是否会对其他项产生影响，如果产生影响，这些影响是否都正确。

3. 检查 按钮的功能是否正确，如Add，delete，save，update功能键.

4. 字符串长度检查：输入超出所要求的字符串长度的内容，看系统检查字符串长度时会不会出错。

5. 字符类型检查：在应该输入指定类型的地方输入其他类型的内容，例如在应该输入浮点型的地方输入其他字符类型，看系统是否检查字符类型时是否报错。

6. 标点符号检查：输入内容包括各种标点符号，特别是逗号、句号、空格、回车键、回格键。看系统处理是否正确。

7. 中文字符处理：在可以输入中文的地方输入中文，看是否出现乱码或出现错误。

8. 检查带出信息的完整性：在查看信息和更新信息时，查看所填写的信息是否全部带出以及带出和添加的信息是否一致。

9. 信息重复：在一些需要命名并且名字是唯一的信息中输入重复的名字，看系统是否处理、报错；重名包括是否区分大小写；以及在输入内容的前后输入空格，系统是否作出正确处理。

10. 检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按“delete”键，看系统如何处理，是否出错;然后选择一个和多个信息，进行删除，看是否正确处理。

11. 检查添加和修改是否一致：检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填;添加规定为浮点型的项，修改也必须为浮点型。

12. 检查修改重名：修改时把不能重名的项改为已存在的内容，看能否处理、报错。同时也要注意，会不会报和自己重名的错。

13. 重复提交表单：一条已经成功提交的纪录，回格后再提交，看看系统是否做了处理。

14. 检查多次使用回格键的情况：在有回格的地方回格，回到原来页面，再回格，重复多次，看会否出错。

15. Search检查：在有search功能的地方输入系统存在和不存在的内容，看搜索结果是否正确。如果可以输入多个搜索条件，可以同时添加合理和不合理的条件，看系统处理是否正确。

16. 输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会否会跳动。

17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件能否打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统能否做到。

18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息。

19. 快捷键检查：是否支持常用快捷键，如Ctrl+C ，Ctrl+V等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

20. 回车键检查：在输入结束后直接按回车键，看系统处理如何，是否报错。

 

59.请详细说明Web翻页功能测试的方法主要包括的内容。

A．首页、上一页、下一页、尾页。

★ 有无数据时控件的显示情况；

★ 在首页时，首页和上一页是否能点击；

★ 在尾页时，下一页和尾页是否能点击；

★ 在非首页和非尾页时，四个按钮功能是否正确；

★ 翻页后，列表中的记录是否仍按照指定的排序列进行了排序。

B．总页数，当前页数

★ 总页数是否等于总的记录数/指定每页条数；

★ 当前页数是否正确。

C．指定跳转页

★ 是否能正常跳转到指定的页数；

★ 输入的跳转页数非法时的处理。

D．指定每页显示条数

★ 是否有默认的指定每页显示条数；

★ 指定每页的条数后，列表显示的记录数，页数是否正确；

★ 输入的每页条数非法时的处理。

 

60.请详细说明搜索功能测试的方法主要包括的内容。

对于搜索功能，主要通过以下八点测试：

1． 页面检查；

2． 默认条件搜索；

3． 修改可选条件搜索；

4． 修改输入条件搜索；

5． 修改区间条件搜索；

6． 组合可选、输入条件搜索；

7． 操作后检查搜索条件及查询结果；

8． 错误、空记录搜索。

61.请详细说明集成测试的内容。

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

 

62.请说明集成测试的过程，可以用图表表示。

集成测试的过程包括：制定集成测试计划，设计集成测试，实施集成测试，执行集成测试，评估集成测试。如下图所示。

 

 

63.简述集成测试的五个步骤。

1.首先确定子系统有哪些模块组成，保证这些模块都进行过单元测试。

2.有开发人员组装这些模块，生成一个子系统，并保证在此子系统中，各个模块的功能尽可能发挥出来。

3.测试前，要设计测试用例，所以一个关键的模块为核心展开，以功能和性能为两条主线，注意模块间接口。

4.搭建必要的测试环境，按照所写测试用例，进行模块连接的充分测试。

5.记录测试结果，总结测试问题。

 

64.请详细说明集成测试过程中要注意的事项。

1. 测试中问题的处理

（1）问题的定位，由谁定位，定位的时间

在测试过程中发现与测试计划中测试项预期结果有所不同，既是问题。如果测试人员有能力定位问题，需明确程序代码中出错的地方，并记录下来；否则找开发人员到现场来定位。定位的时间最好是在问题产生之前，这样有利于保护现场和问题重现，但时间不能太长，否则影响测试进度，原则上说，集成测试中发现的问题都应该定位到语句，除非涉及到方案设计上的错误。

（2）环境问题的处理

集成测试的环境可以是单机、双机或机架。测试过程中需要有独立的、稳定的和良好的实验环境。但在实际中由于条件限制，测试环境是大家共享的，为保证本次测试不影响下次测试工作或其他人测试工作的开展，所以测试人员需要做以下的工作：

★ 测试环境的申请；

★ 测试环境的维护；

★ 测试环境的移交。

（3）测出问题的记录与提交

测试过程中发现的现象和问题由测试人员做详细记录，测出的问题最好先由开发人员确认，然后以内部问题报告单的形式提交，这样防止测试人员提交的问题并非是程序的问题，（可能是环境因素或其他因素造成），同时保证发现的问题能够被跟踪到回归测试，即被彻底解决为止。

2. 测试过程记录

测试人员在测试过程中完成必要的测试记录，记录的内容包括：测试版本；测试任务；使用环境；测试项目；测试结果；问题描述；产生原因。

每一阶段性的测试任务结束后，应向测试负责人提交测试记录，测试负责人做存档处理。

3.  测试人员在测试过程中应不断地与开发人员进行经验交流，讨论程序中的疑问以及问题的解决，加深程序的理解，以积极合作的方式来完成测试工作。     

4. 测试用例、CHECKLIST、测试进度的适当修正

随着集成测试的进一步进行，对程序代码的理解不断加深，会发现以前的测试集不够理想，这就需要及时更新测试用例，以提高测试覆盖率和达到需要的异常测试，相应也要修改CHECKLIST和调整测试进度。

 

65.判断集成测试过程完成与否，需要注意哪些方面？

★ 成功地执行了测试计划中规定的所有集成测试；

★ 修正了所发现的错误；

★ 测试结果通过了专门小组的评审。

 

66.请详细说明性能测试的目的。

性能测试主要是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈及问题，找到软件的可扩展点，优化软件，最后起到优化系统的目的。

性能测试的目的主要有以下几点：

（1）评估系统的能力

性能测试主要考查系统的能力，它对系统的负荷和响应时间是相当重要的，也是验证系统能力的依据之一。

（2）识别体系中的弱点

性能测试考查系统受控的负荷还存在有哪些缺陷，并为解决这些缺陷提供路径。

（3）系统调优

性能测试的系统调优就是重复运行测试，验证系统的活动是否得到了预期的结果，从而改进系统性能。检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中隐含的问题或冲突。

（4）验证稳定性及可靠性

验证稳定性及可靠性是在一个生产负荷下，执行一定时间的测试，是评估系统稳定性和可靠性是否满足要求的唯一方法。

   

67.请列举性能测试的先决条件。

性能测试的先决条件包括：

（1）针对性能测试对象的技术要成熟；

（2）性能测试的测试环境要稳定； 

（3）进行性能测试的准备要充分；

（4）性能测试的目标要明确；

（5）性能测试的计划要详细；

（6）性能测试的数据要精确以及要有代表性；

（7）性能测试的描述要精练。

满足了这些之后我们才能够进入测试阶段。

 

68.请说明性能测试的主要分类，并简介之。

性能测试主要分为三类：

（1）应用在客户端性能的测试

应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

（2）应用在网络上性能的测试

应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

（3）应用在服务器端性能的测试

对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统 、数据库系统、应用在服务器上性能的全面监控。  

 

69.请列举在进行性能测试之前我们应掌握的相关文档。

（1）用户需求规格说明及其相关文档；

  （2）软件开发的前期数据；

  （3）前期工作的详细资料（单元测试、集成测试、功能测试等的相关文档）；

  （4）在真正进入性能测试之前的软件数据的备份等；

  （5）性能测试的测试大纲；

  （6）性能测试的审批文稿及所签署的合同等。

 

70.一个标准的性能调优过程是是什么？

（1） 确定基准环境、基准负载和基准性能指标；

（2） 调整系统运行环境和实现方法，执行测试。（包括硬件环境的调优、Weblogic调优、Oracle调优）；

（3） 记录测试结果、进行分析。

71.简述系统测试的测试类型。

系统测试一般要考虑功能测试、性能测试、负载测试、容量测试、安全性测试、用户界面测试、配置测试、安装测试、回归测试等。

 

72.请分析系统测试的目标，并列举出来。

1) 确认系统测试的过程是按需求说明书进行的；

2) 确认新系统是否与需求说明书有不同或者缺陷；

3) 对新系统在进行测试的过程中出现的不足或不符合要的地方时行记录；

4) 建立完善的系统测试缺陷记录跟踪库；

5) 将测试过程中出现的问题进行修改，使之能达到令用户满足。

      

73.系统测试策略的内容是什么？请详细说明。

测试策略用于说明测试工作的方法和目标，系统测试策略主要是对系统测试的需求，确定测试类型和怎样进行测试的方法和技术。

测试策略应包括如下内容：

★ 要进行的测试类型和测试目标；

★ 进行测试时要采用的技术；

★ 对测试的结果制定标准；

★ 对测试过程中所出现问题存在的影响的特殊事项；

★ 进行系统测试的对是应是完整的、集成的计算机系统；

★ 按照设计说明书的规定，逐项测试系统的功能．性能等特性。

 

74.系统测试的方法比较多，其中常用的方法是哪三个？

1) 多任务测试

2) 临界测试

3) 中断测试。

75.中断测试可分为：人为中断、硬件异常中断、程序执行中断以及意外中断4种情况，请分别说明这4种情况。

1. 在测试中人为中段是为了表现测试结果而设置的中断。在测试中是常用的一种手段。
2. 而硬件异常中断是由计算机硬件异常或故障引起的中断，对硬件异常中断主要测试系统设备有没有在线功能和备用设备。
3. 程序执行中断主要是由程序中执行了中断指令引起的中断，也称为软中断。这是不应该发生的，对这类问题测试重点审查集成测试的过程和结果。

意外中断主要是外部原因引起的中断，对他的测试主要是审查有没有备用电源、有没有安装UPS。

75.请详细列举验收测试的首要条件。

验收测试的首要条件有以下几点：

1． 软件开发已经完成，并全部解决了已知的软件缺陷； 

　　2． 验收测试计划已经过评审并批准，并且置于文档控制之下； 

　　3． 对软件需求说明书的审查已经完成； 

　　4． 对概要设计、详细设计的审查已经完成； 

　　5． 对所有关键模块的代码审查已经完成；

　  6． 对单元、集成、系统测试计划和报告的审查已经完成；

　　7． 所有的测试脚本已完成，并至少执行过一次，且通过评审； 

　  8． 使用配置管理工具且代码置于配置控制之下； 

9． 软件问题处理流程已经就绪；

10．新系统已通过尝试运行工作；

11．所被测的新系统应该是稳定的，要符合技术文档和标准的规定；

12．已经制定、评审并批准验收测试完成标准；

13．合同、附件规定的各类文档齐全。

 

76.请详细说明验收测试的目的。

验收测试的目的主要是：

★ 新建系统产品是否是按照用户需求开发的，体验该产品是否能够满足用户使用要求、有没有达到原设计水平、完成的功能怎样；

★ 对照合同的需求进行验收测试，是否符合双方达成的共识；

★ 新建系统产品的可靠性和可维护性好不好？

★ 新建系统产品通过运行的结果表明，对业务处理的能力；

★ 新建系统产品对用户操作的容错能力；

★ 新建系统产品新系统对系统运行时发生故障的恢复能力；

★ 承建单位向业主单位提交的有关技术资料是否俱全。

 

77.请列举验收测试过程中所涉及到的相关文档。

测试过程中涉及到的文档有：

1. 测试任务说明书；

2. 测试计划说明书；

3. 测试用例说明书；

4. 测试报告说明书；

5. 测试总结说明书；

6. 测试验收说明书；

7. 缺陷跟踪报告说明书。

 

78.正式验收测试是什么？它的优缺点又是什么？请介绍之。 

正式验收测试，是系统测试的后续，也就是说正式测试的测试工作和系统测试差不多，测试计划和测试用例设计都应很详细，在这个测试过程中应用的测试用例应是系统测试的用例的子集，不能对系统的测试方向有所偏离，在很多测试过程中，正式验收是自动进行测试的。

正式验收测试的优点是： 

1) 要进行验收测试的软件的功能和特性都是已知的；

2) 可以对测试的过程进行评测；

3) 正式验收测试可以自动进行测试；

4) 对软件的要求是由用户需求说明书所决定的。 

正式验收测试的缺点：

1) 进行正式验收测试需要大量的资源和计划；

2) 正式验收测试可能和系统测试差不多；

3) 正式验收测试过程中可能不能发现某些缺陷。

 

79.请介绍非正式验收测试的两个过程。 

非正式验收测试过程分为Alpha 测试 和Beta 测试。

Alpha测试

Alpha测试是用户在开发环境下所进行的测试，或者是开发内部的人员在模拟实际环境下进行的测试。Alpha测试没有正式验收测试那样严格，在Alpha测试中，主要是对用户使用的功能和用户运行任务进行确认，测试的内容由用户需求说明书决定。

Beta 测试

进行Beta 测试时，各测试员应负责创建自己的测试环境、选择数据，决定要研究的功能、特性或任务，并负责确定自己对于系统当前状态的接受标准。

80.请详细说明回归测试的定义。

在软件开发过程当中，只要软件发生改动，就可能给该软件带来诸多的问题，我们就必须重新测试现有的功能模块。软件的改动可能是源于功能的变更、模块的增加或者bug的修改，具体表现在以下几个方面：

(1) 跟踪和管理系统不够健全，遗漏对bug的修改；

(2) 开发者对bug理解不够深入，只修改了bug的表面现象，而没有对bug做本质修改；

(3) 本bug被修改，之前版本bug掩盖的其他错误暴露出来；

(4)  bug被修改，但并没有考虑到与此问题相关联的其他功能模块。

回归测试正是为了验证以上几个方面是否发生，以便确定修改是否达到了预期的目的，验证修改是否损害了原有的正常功能。与此同时，还需要补充新的测试用例来测试新增的、被修改了的功能模块。验证修改的正确性及其影响，即为回归测试。

回归测试不是特定的测试级别，软件开发的各个阶段都会进行多次回归测试。

　

81.请说明回归测试的范围是什么。

在进行回归测试的时候，必须决定回归测试的范围，具体表现在以下几个方法：

(1)  测试所有修改或修正过的功能模块；

(2)  测试与被修改的模块相关的模块；

(3)  测试所有新增加的功能模块；

(4)  测试整个系统。

方法(1)、方法(2)和方法(3)中只进行了部分的回归测试，这样的测试是不健全的，因为在软件系统中，对本地代码的修改可能导致整个系统产生副作用。

 

82.请简要列举回归测试用例库的维护方法。

软件测试项目组在进行测试的过程中会将所用到的测试用例保存到“测试用例库”中，并进行维护，回归测试用例库的维护方法如下。

1) 删除过时的测试用例

2) 改进不受控的测试用例

3) 删除冗余的测试用例

4) 增添新的测试用例

 

83.列举常用的回归测试的方法。

再测试全部用例

基于风险进行测试

基于操作进行测试

仅测试修改部分

 

84.请列出回归测试可遵循的基本过程。

(1) 识别出软件中被修改的部分。 

(2) 从测试用例库中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的测试用例库。

(3) 依据一定的策略从新的测试用例库中选择测试用例测试被修改的软件。

(4) 如果必要，可生成新的测试用例集，用于测试新的测试用例库无法充分测试的软件部分。

(5) 用测试用例集执行修改后的软件。

其中第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证修改工作本身。

85.配置测试的目标都有哪些？请列举之。

正如同所有测试的目标都是为了保证软件功能的强大，性能的优越，bug报错率小配置测试的目标也是相同的，它的目标有以下几点：

★ 验证应用程序（即，确定它是否满足了它的配置要求）。

★ 确定配置问题的软件出错。

★ 帮助识别那些不能有效地在单元和集成测试发现的一些缺陷。

★ 决定增加或修改，如硬件资源的影响：内存、磁盘和磁带资源、处理器、负载均衡。 

★ 确定最佳的系统配置。

 

86.请列举进行配置测试的几个前提条件。

进行配置测试需要以下几个前提条件：

★  进行配置测试的需求分析已经完成。

★ 已完成应用程序的多个版本。

★ 相关的软件组件已通过单元测试。

★ 软件集成测试已经进行，但在配置测试开始之前软件组件必须已经安装在被测硬件设备上。

★ 相关系统组件已通过系统集成测试。

★ 在独立的测试小组配备足够的人员进行配置测试和训练。

★ 配置测试环境准备完成。

87.简要说明进行配置测试的两个范围所包括的内容。

配置测试的目标是为了使软件在尽可能多的硬件平台上运作，那么进行配置测试一般需要测试它的硬件环境和软件环境。

1．硬件环境

硬件环境主要包括：

★ 不同的主机；

★ 不同的组件；

★ 不同的外设；

★ 不同的接口以及可选项的测试。

2．软件环境

软件环境包括：

★ 对操作系统平台的兼容测试；

★ 对同一操作系统平台不同版本的测试；

★ 软件自身向前向后更新操作时的测试；

★ 同其他软件产品兼容性测试以及数据兼容性（主要是数据共享）的测试。

 

88.列举进行配置测试工作前和工作后所需的相关文档。

1.工作开始前所需的文档

配置测试进行前需要以下文档资料：

★ 测试计划；

★ 需要进行的测试列表 ；

★ 被测程序源码；

★ 配置测试软硬件设备清单；

★ 配置测试用例。

2.工作结束后递交的文档

配置测试结束后需要递交以下文档资料：

★  配置测试报告 ；

★ 配置测试总结报告 。

 

89.配置测试设计的要点包括哪8点？请说明之。

★ 确定哪些功能是软件需要用到的，例如一个办公程序可能对显卡要求是很低的，没有必要去测试太多。又或者一个大型游戏根本不需要打印功能，那么就不需要管打印机了；

★ 看看要对哪些牌子，型号，具体那些驱动程序的硬件是可用的。一般都会选用市场上比较流行的软件；

★ 看看哪些硬件特性，模式和选项是可用的；

★ 在已有的测试集合里面挑选出一个可维护可管理的测试集，还是挑出表常见的硬件；

★ 找出软件中对配置特别敏感的特有功能；

★ 不同配置下的测试用例需要分别设计；

★ 在每个配置环境下至少执行一边测试用例；

★ 反复执行测试用例直到结果具有说服力。

90.简要说明可用性测试的概念。

可用性测试的概念主要表现为：

1. 可用性是产品的一个基本的自然属性，是最终用户使用产品的可用的程度。

2. 可用性测试是依照可用性标准对GUI的系统评估。

3. 可用性是在产品和用户的相互作用中体现出来。

4. 可用性测试是用户在和系统（网站，软件应用程序，移动技术或任何用户操作的设备）5. 交互时对用户体验质量的度量。

6. 可用性的基本评价指标是效率、满意和安全（容错，无错）。

 

91.什么是压力测试？请说明之。

压力测试（Stress Test）也就是强度测试，压力测试是指模拟巨大的工作负荷来测试应用程序在峰值情况下如何执行操作。在实际的软硬件环境下，压力测试主要是以软件响应速度为测试目标，尤其是针对在较短时间内大量并发用户访问时软件的抗压能力。其目的是找到系统在哪里失效以及如何失效的地方。

 

92.请详细说明确认测试的内容（功能测试和性能测试）。

确认测试内容主要包括功能和性能两部分。

（1）功能测试

功能测试考察软件对功能需求完成的情况，应该设计测试用例使需求规定的每一个软件功能得到执行和确认。

 ★ 按照系统给出的功能列表，逐一设计测试案例；

 ★ 对于需要资料合法性和资料边界值检查的功能，增加相应的测试案例；

 ★ 运行测试案例；

 ★ 检查测试结果是否符合业务逻辑；

 ★ 评审功能测试结果。

（2）性能测试

性能测试是检验软件是否达到需求规格说明中规定的各类性能指标，并满足一些与性能相关的约束和限制条件。

★ 测试软件在获得定量结果时程序计算的精确性；

★ 测试在有速度要求时完成功能的时间；

★ 测试软件完成功能时所处理的数据量；

★ 测试软件各部分工作的协调性，如高速操作、低速操作的协调性；

★ 测试软件/硬件中因素是否限制了产品的性能；

★ 测试产品的负载潜力及程序运行时占用的空间。

 

93.请简要说明容错性测试的内容。

容错性测试包括两个方面：

输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。

灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

 

94.请详细说明容错性测试需考虑的特殊事项。

从容错性测试的概念和内容可以看出，当软件出现故障时如何进行故障的转移与恢复有用的数据是十分重要的。对于如何进行容错性测试，这是我们关心的事情，所以进行容错性测试需要考虑以下的特殊事项。

故障发生时数据的转移与数据的恢复

故障发生时数据的转移是为了确保在出现故障时能成功的转移有效的数据，防止因故障的发生导致意外的破坏各种硬件、软件和网络设备。数据的恢复是为了能够继续运行系统，同时，一旦系统发生故障，备用系统将不失时机地“顶替”已发生故障的系统。

容错性测试目前主要做的事情表现为：

      服务器断电；

      网络设备断电；

      数据库系统发生故障；

      应用系统文件发生故障；

      系统软件发生故障。

 

95.请用简短的语言介绍一下易用性测试。

易用性是交互的适应性、功能性和有效性的集中体现。易用性一般分为两个层次，即用户界面的易用性和操作系统的易用性。易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。

 

96.请详细说明易用性测试中的用户界面测试的内容。

用于与软件交互的方式称为用户界面或UI，易用性包括如下方面的测试：

（1）符合标准和规范

用户界面要素要符合软件现行的标准和规范。

（2）直观

用户界面是否洁净、不拥挤；

布局是否合理；

    是否有多余功能。

（3）一致

如果软件或者平台有一个标准，就要遵守它。如果没有，就要注意软件的特性，确保相似的操作以相似的方式进行。

（4）灵活

多种视图的选择；

状态跳转；

状态终止和跳过；

数据输入和输出。

（5）舒适

软件使用起来应该舒适，不能给用户工作制造障碍和困难。

（6）实用

是否实用是优秀用户界面的最后一个要素。

 

97.请详细说明安全性测试的方法。

（1） 应用程序（应用系统）级别的安全性测试方法

★ 对数据或业务功能的访问，在预期的安全性情况下，操作者只能访问应用程序的特定功能、有限的数据；

★ 操作者只能访问其所属用户类型已被授权访问的那些功能或数据；

★ 不同权限的用户类型，创建各用户类型并用各用户类型所特有的事务来核实其权限，最后修改用户类型并为相同的用户重新运行测试。

★ 测试结果的安全性分析

           ● 分析所有测试用例，测试是否通过。

           ● 测试代码是否按照要求分析，并达到相应的测试覆盖率。

           ● 对测试结果进行分析，以验证所有的安全性需求是否得到了满足。

（2）系统级别的安全性测试策略和方法

★ 只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问，包括对系统的登录或远程访问；

★ 只有具备系统和应用程序访问权限的操作者才能访问系统和应用程序。

 

98.请说明需求分析测试的内容。

需求分析测试的内容主要讨论以下3点：

1．功能是否能满足用户的需求？

2．性能是否能满足用户的需求？

3．需求说明书所讨论的内容是否得到了用户的认可？

 

99.请详细说明软件可靠性测试中需注意的问题。

软件可靠性测试需要注意的问题主要有3点：

1． 功能识别

软件可靠性测试首先考虑的是功能识别，确定系统所使用的功能。

功能识别的目标是：

★ 识别系统所确定的功能（依据系统功能说明书进行审核）；

★ 识别系统功能所需的相关条件。

2. 可靠性对时间的要求

软件可靠性对时间的要求是比较高的，测试时应将“运行时间”作为衡量可靠性的重要指标，所谓运行时间就是软件运行时应在“规定的时间”内完成所要完成的工作。对于时间的要求应根据系统性能说明书的要求进行审核。

3. 可靠性对环境条件的要求

环境条件是指软件系统运行时所需的各种支持要素，主要表现为：硬件环境（服务器、路由器、交换机、防火墙、磁盘阵列）、网络操作系统、软件工具、应用系统的操作规程等。        

 

100.请说明风险测试的内容。

风险是指在软件开发过程中遇到的预算、进度、开发不成功等方面的问题引起损失的可能性，这种风险会导致软件开发的失败。

软件测试的风险是指软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，造成测试的补充以及结果不准确。测试的不成功导致软件交付潜藏着问题，一旦在运行时爆发，会导致软件失败。

软件测试风险主要是对测试计划执行的风险分析与制定要采取的应急措施，降低软件测试产生的风险造成的危害。

 

101.请列举缺陷测试应注意的问题。

在缺陷测试过程中需要注意的问题有：

1) 由于市场的压力而造成的产品最终发行的时间限制 ；

2) 因测试员不正确操作或错误理解引出的缺陷 ；

3) 错误的修改影响的模块较多，带来的风险较大； 

4) 在缺陷报告中提出很难被重现的问题；

5) 修改性价比太低的缺陷 。

 

102.请简要说明Web测试的内容。

Web测试与一般应用系统的测试不同，链接的吻合性是web应用系统的一个主要特征，需要检查和验证是否按照设计的要求运行，而且测试系统在不同用户的浏览器的显示是否合适。更重要的是，还要从最终用户的角度进行安全性和可用性测试。

 

103.请说明接口测试的目的。

接口测试（Interface-Testing）的目的是：

l 测试系统相关联的外部接口；

l 测试的重点是要检查数据的交换；

l 传递和控制管理过程；

l 提高测试质量；

l 提高测试覆盖；

l 更好地重现软件缺陷；

l 更好定位错误。

作为接口测试主要考虑的问题是模块接口、系统接口。

 

104.请详细介绍接口测试的测试项目。

接口测试的测试项目主要包括以下几点：

1．数据类型问题

★ 变量的数据类型是否错误 ；

★ 是否存在不同数据类型的赋值；

★ 是否存在不同数据类型的比较。

2．变量值问题

★ 变量的初始化或缺省值是否有错误；

★ 变量是否发生上溢或下溢；

     ★ 变量的精度是否足够。

3．逻辑判断问题

★ 是否由于精度原因导致比较无效；

★ 表达式中的优先级是否有误 ；

★ 逻辑判断结果是否颠倒。

4．文件I/O问题

★ 对不存在的或者错误的文件是否进行操作；

★ 文件是否以不正确的方式打开；

★ 文件结束判断是否正确；

★ 是否正确地关闭了文件。

 

105.请列举安装和反安装测试的4个目标。

安装和反安装测试的目标有4点：

1. 安装/卸载程序能正确运行； 

2. 程序安装正确；卸载时完全清除；

3. 程序安装后能正确运行；卸载后系统的影响； 

4. 完善性安装后程序能正确运行。 

 

106.请分别详细说明安装测试和反安装测试各自的内容。

1. 对安装进行测试要注意如下内容：

（1）安装程序是否正确；

（2）程序安装后能否正确运行；

（3）安装过程是否符合安装手册的安装步骤；

（4）安装过程中所有缺省选项是否得到了验证；

（5）安装过程中典型的选项是否得到了验证；)；

（6）安装过程中是否出现异常配置状态（非法和不合理配置）；

（7）安装后是否能产生正确的目录结构和文件属性；

（8）安装后的动态库是否正确；

（9）安装后的软件能否正确运行；

（10）安装后该系统是否对其他的应用程序造成不正常影响。

2. 对反安装进行测试要注意如下内容：

（1）文件－－安装目录里的文件及文件夹；

（2）非安装目录（向系统其它地方添加的文件及文件夹）；

（3）快捷方式－—（桌面，菜单，任务栏，系统栏,控件面板，系统服务列表等） ；

（4）复原方面－—卸载后，系统能否恢复到软件安装前的状态； 

（5）卸载方式－－程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具；

（6）卸载状态－－程序在运行/暂停/终止等状态时的卸载； 

（7）非正常卸载情况－卸载软件过程中，取消卸载进程，然后，观察软件能否继续正常使用； 

（8）冲击卸载－－在卸载的过程中，中断电源，然后，启动计算机后，重新卸载软件，如果软件无法卸载，则重新安装软件，安装之后再重新卸载； 

（9）卸载环境－－不同的(操作系统，硬件环境，网络环境等)下进行卸载 ;卸载后,该系统是否对其他的应用程序造成不正常影响。 

107.测试大纲写作模板

第1章  概述

1.1  编写目的

1.2  术语和缩写词

1.3  参考资料

第2章  测试环境

2.1  硬件

2.2  软件

第3章  测试阶段技术

第4章  测试内容和测试的重点

4.1 测试概述：对测试进行一个总体描述

4.2测试操作步骤的记录

第5章  人员和时间

第6章  测试进度计划

第7章  文档提交文档

第8章  测试提交文档

 

2.  软件测试计划写作模板

第1章 引言

1.1编写目的

1.2 项目背景

1.3范围

1.4测试摘要

1.4.1 重点事项

1.4.2 争议事项

1.4.3 风险评估

1.4.4 时间进度

1.4.5 测试目标

1.5提交的测试文档

1.6名词解释

1.7参考资料

第2章 测试任务概述

2.1 测试目标

2.2 测试环境

2.3 需求概述

2.3.1 描述建立测试环境所需要的设备

2.3.2 说明所需设备的机型

2.3.3 设备的用途

2.3.4 说明每台设备上部署的软件

2.3.5 说明第三方软件和应用程序的预计空间

2.3.6 测试使用的工具以及用途。

2.5 测试的方法

2.5.1 单元测试

2.5.2 集成测试

2.5.3系统测试

2.5.4 功能测试

2.5.5数据和数据库完整性测试

2.5.6接口测试

2.5.7用户界面测试

2.5.8性能测试

2.5.9负载测试

2.5.10强度测试

2.5.11容量测试

2.5.12 安全性和访问控制测试

2.5.13故障转移和恢复测试

2.5.14配置测试

2.5.15安装测试

2.5.16 验收测试

2.5.17文挡测试

2.5.18回归测试

第3章 测试计划

3.1 测试方案

3.2 测试项目

3.3 测试准备

3.4 测试进度

3.5测试机构及人员

第4章 测试项目说明

4.1 测试项目名称及测试内容

4.2 测试用例

4.3 测试进度安排

4.4 条件

4.5 测试方法

4.6 测试准则

4.7 测试用例

4.8 测试资料

第5章 评价

5.1评价的范围

5.2 评价的结果

第6章测试数据的记录、整理和分析

第7章 测试计划的审核和批准人

 

3.  测试任务说明书写作模板

1. 概述

1.1  编写目的

1.2  项目背景

1.3  编写测试任务说明书需要的文档

2. 测试任务

3. 测试质量

4. 测试范围

4.1  流程测试

4.2  边界值测试

4.3  容错性测试

4.4  异常测试

4.5  安装测试

4.6  易用性测试

4.7  界面测试

4.8  接口测试

4.9  配置测试

4.10 性能测试

4.11 压力测试

4.12 兼容性测试

4.13 升级测试

4.14 功能测试

4.15 单元测试

4.16 集成测试

4.17 系统测试

4.18 回归测试

4.19 验收测试

4.20 文档测试

5. 确定测试进度和管理

5.1  确定测试进度

5.2  管理

6. 测试任务的重点

6.1  单元测试

6.2  集成测试

6.3  系统测试

6.4  验收测试

7. 测试注意事项

 

4.  测试需求说明书写作模板

1． 概述

1.1 编写目的

1.2 项目背景

1.3 术语定义

1.4 文档约定

1.5 产品的测试范围

1.6 参考资料

2．测试任务概述

   2．1 测试目标

   2．2 运行环境

2．3条件与限制

3．系统特性

4．数据的一致性、正确性测试

5．用例描述

6．功能测试要求

7．性能需求测试要求

8．运行测试要求

8.1运行测试要求

8.2 硬件接口

8.3 软件接口

8.4 通信接口

8.5 设备

8.6 故障处理

9. 安全测试需求

9.1 安全设施测试需求

9.2 安全性测试需求

10. 文件传输

11. 数据导入导出测试

12. 测试约束

13. 回归测试需求功能

14. 用户文档测试

15. 其他专门要求

 

5.  单元测试写作模板

1．概述

1.1单元测试的目的

1.2测试的背景

1.3单元测试所需文档

2. 主要步骤

2.1 程序语法检查

2.2 程序逻辑检查

2.3桩模块检查

3. 单元测试项目

3.1模块接口测试

3.2局部数据结构测试

3.3路经测试

3.4边界条件测试

3.5错误处理测试

3.6代码书写规范测试

4. 单元测试报告

4.1测试报告目的

4.2测试内容

4.3单元结构

4.4测试过程

4.5测试

4.6提交BUG测试

4.7单元评估

4.8填写表格

5．小结

 

6.  代码检查写作模板

1. 概述

1.1 代码检查的模块

1.2 编写目的

1.3 代码检查需要的文档

2. 代码检查方式

2.1 桌面检查

2.2 走查

2.3 代码审查

3. 代码检查项目

3.1 目录文件组织

3.2 检查函数

3.3 数据类型及变量

3.4 检查条件判断语句

3.5 检查循环体制

3.6 检查代码注释

3.7 桌面检查

3.8 其它检查

4. 静态结构分析

5. 静态质量

6. 质量度量

6.1 质量因素（Factors）

6.2 分类标准（criteria）

6.3 度量规则（Metrics）

7. 代码检查的分析与评价

7.1 能力

　 7.2 缺陷和限制

7.3 评价

 

7.  程序错误报告写作模板

1. 程序错误报告目的

2. 程序错误的描述

2.1 功能类错误描述

   2.2 界面类错误描述

   2.3 数据处理类

   2.4 流程类错误描述

   2.5 提示信息类错误描述

3. 程序错误报告表

 

8.  程序设计写作模板

1. 引言

1.1 目的     

1.2 定义和缩写词

1.3 参考资料

2. 编码风格

2.1 程序编码要采用缩进风格编写

2.2 编写子程序一定要做注释

2.3 相对独立的程序块之间、变量说明之后必须加空行

2.4 较长的语句要分成多行书写

2.5 循环、判断等语句中有较长的表达式或语句，要在低优先级操作符处划分新行，操作符放在新行之首

2.6 若函数或过程中的参数较长，则要进行适当的划分

2.7 一行只写一条语句

2.8 if、for、do、while、switch等语句自占一行,执行语句部分要加括号

2.9 对齐只使用空格键，不使用TAB键

2.10 程序块的分界符应独占一行

3. 注释

3.1 源程序有效注释量必须在20％以上

3.2 说明性文件头部应进行注释

3.3 源文件头部应进行注释

3.4 函数头部应进行注释

3.5 编写代码要边注释

3.6 注释的内容要清楚、明了，含义准确，防止注释二义性

3.7 对数据结构声明

3.8 全局变量要有较详细的注释

3.9 将注释与其上面的代码用空行隔开

3.10 对变量的定义和分支语句必须注释

4．标识符命名

4.1 标识符的命名要清晰、明了，有明确含义

4.2 命名中若使用特殊约定或缩写，则要有注释说明

4.3 命名规范必须与所使用的系统风格保持一致

5. 可读性

5.1 注意运算符的优先级

6. 变量、结构

6.1 去掉不必要的公共变量

6.2 仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系

6.3 明确公共变量与操作此公共变量的函数或过程的关系

6.4 当向公共变量传递数据时，防止赋与不合理的值或越界等现象发生

6.5 防止局部变量与公共变量同名

6.6 严禁使用未经初始化的变量作为右值。

6.7 结构的设计要尽量考虑向前兼容和以后的版本升级

6.8 要注意数据类型的强制转换

6.9 对自定义数据类型进行恰当命名

7. 函数、过程

7.1 对所调用函数的错误返回码要仔细、全面地处理

7.2 明确函数功能

7.3 编写可重入函数时，应注意局部变量的使用

7.4 明确规定对接口函数参数的合法性检查

7.5 避免使用无意义或含义不清的动词为函数命名

7.6 函数的返回值要清楚、明了，让使用者不容易忽视错误情况

7.7 函数本身不递归调用

8．可测性

8.1 在同一项目组或产品组内，要有一套统一的打印函数

9. 程序效率

9.1 编程时要经常注意代码的效率

9.2 提高代码效率

9.3 循环体内工作量最小化

9.4 尽量减少循环嵌套层次

10. 质量保证

10.1 代码质量保证原则

10.2 只引用属于自己的存贮空间

10.3 过程/函数中分配的内存，在过程/函数退出之前要释放

10.4 防止内存操作越界

10.5 初始化有关变量和运行环境

10.6 不能随意改变与其它模块的接口

10.7 要注意易混淆的操作符

10.8 要注意程序机器码大小

11. 代码编辑、编译、审查

11.1 打开编译器的所有告警开关对程序进行编译

11.2 在产品软件（项目组）中，要统一编译开关选项

11.3 通过代码走读及审查方式对代码进行检查

12. 代码测试、维护

12.1 单元测试要求覆盖语句

12.2 单元测试开始要跟踪每一条语句，并观察数据流及变量的变化

12.3 清理、整理或优化后的代码要经过审查及测试

12.4 代码版本升级要经过严格测试

12.5 使用工具软件对代码版本进行维护

12.6 软件的任何修改都应有详细的文档记录

13. 宏

13.1 用宏定义表达式时，要使用完备的括号

13.2 将宏所定义的多条表达式放在大括号中

13.3 使用宏时，不允许参数发生变化

 

9.  测试用例写作模板

第1章 概述

第2章 一般测试用例写作模板    

第3章 接口测试用例编写方法

第4章 需求测试用例写作模板

第5章 路径测试用例模板

第6章 功能测试模板

第7章 恢复能力测试用例写作模板

第8章 容错能力测试用例写作模板

第9章 性能测试用例写作模板

第10章 界面测试用例写作模板

第11章 信息安全测试用例写作模板

第12章 压力测试用例模板

第13章 可靠性测试用例模板

第14章 安装 / 反安装测试用例模板

 

10. 软件测评写作模板

1. 软件测评登录表

2. 适用程度测评表

3. 数据管理测评

4. 整理编目测评

5. 检索查询测评

6. 辅助实体管理

7. 安全保密

8. 系统维护

9. 兼容性测评

10. 信息处理速度

11. 易用性

12. 容错性

13. 安全可靠性

14. 软件资料

15. 软件总体测评结论

 

11. 功能测试写作模板

1. 概述

1.1 编写目的

1.2 项目背景

   1.3 测试方法和策略

1.4 测试依据

2. 功能测试测试方式与环境

2.1 测试方式

2.2硬件设备

2.3软件设备

3. 功能测试内容

3.1 功能测试的功能点

3.2 界面

3.3数据

3.4操作

3.5 翻页功能测试

3.6 搜索功能测试

3.7 功能逻辑

3.8 功能接口

3.9功能约束条件（或测试边界）

4. 功能测试结果

4.1功能测试统计

4.2功能测试详细结果

5. 功能的安全性

6. 功能的易用性

7. 功能的总体分析

8. 功能测试的结论

 

12. 性能测试写作模板

1. 概述

1. 1 编写目的

1.2 项目背景

   1.3 测试方法和策略

1.4 参考资料

2. 性能测试方式和环境

2.1 测试方式

2.2硬件设备

2.3软件设备

2.4测试配置

3．性能测试内容

3.1基本性能测试

   3.2 高级性能测试

3.2.1 并发性能测试

3.2.2 并发测试

3.2.3 系统资源监控测试

3.2.4 速度测试

3.2.5疲劳测试

3.3 大数据量测试（压力测试）

4. 性能测试的结果统计

   4.1 应用软件的测试指标

4.2 网络环境的测试指标

4.3 操作系统环境的测试指标

   4.4 数据库环境的测试指标       

5．性能测试结论

6．测试工作清单

7．性能测试的审批

8．性能测试的报告

 

13. 可靠性测试写作模板

1. 概述

1.1    软件可靠性测试概念

1.2    软件可靠性测试过程

2. 成熟性测试规定

2.1 成熟性测试规定目的

2.2 成熟性测试规定实施细则

3. 容错性测试规定

   3.1容错性测试规定目的

3.2容错性测试规定实施细则

4. 易恢复性测试规定

   4.1易恢复性测试规定目的

   4.2易恢复性测试规定实施细则

5. 容错性测试规定

   5.1容错性测试规定目的

   5.2容错性测试规定实施细则

6. 易恢复性测试规定

   6.1易恢复性测试规定目的

   6.2易恢复性测试规定实施细则

 

14. 集成测试写作模板

1． 引言

1．1 编写目的

1．2 背景

1．3 定义

1．4 集成测试任务

1．5 集成测试范围

1．6 集成测试进度

1．7 集成测试风险和应急计划

1．8 参考资料

2． 计划集成测试

2．1 制定集成测试计划

2．2 确定测试进度和管理

2．3 集成测试具体内容

2．3．1 功能性测试

2．3．2 可靠性测试

        2．3．3 易用性测试

        2．3．4 性能测试

        2．3．5 维护性测试

        2．3．6 可移植性测试

        2．3．7 操作性测试

2．3．8 疲劳性测试

2．4 设计集成测试用例

3． 实施集成测试

4． 测试结果评估

5．集成测试的工作清单

6．审批

7．填写集成测试报告表格

8． 集成测试提供的文件

 

15. 系统测试写作模板

1. 概述

1.1 编写目的

1.2 项目背景

   1.3 系统简介

1.4 术语和缩写词

1.5 系统测试工具

1.6 参考资料

2．系统测试环境与配置    

3. 系统测试的主要内容和测试类型

3．1 系统测试的主要内容

3．2 系统测试的测试类型

4．系统测试测试方法

5．系统测试的结果分析

5.1 系统反应时间的测试

5.2 CPU测试

6. 系统测试总结

6.1 测试时间、地点、人员

6.2 测试范围

6.3 工作组织

6.4 系统测试分析

6.4.1 系统测试统计

6.4.2 系统测试发现的问题汇总

6.4.3 系统测试结果分析

   6.5 系统残留缺陷与未解决问题

6.5.1 系统残留缺陷

6.5.2 系统未解决问题

7. 系统测试结论

7.1 系统功能性

7.2 系统易用性

7.3 系统可靠性

7.4 系统兼容性

7.5 系统安全性

8. 系统使用说明书和维护手册的编写

9. 系统测试结果的评价和结论

9.1 系统测试结果的评价

9.2 系统测试结果的结论

10．系统测试文档资料

11. 建议

12. 测试人员名单

13. 附件

 

16. 验收测试写作模板

1. 概述

1.1 验收测试目的

1.2 项目基本情况

1.3 验收测试范围

2．验收测试组织方案

2.1 验收测试时间

2.2 测试地点

2.3 验收测试环境

2.3.1 硬件

2.3.2 软件

2.3.3 网络

2.3.4 测试工具

2.4 人员安排

3． 项目进度审核

3.1 项目实施进度情况

3.2 项目合同变更情况

3.3 项目需求变更情况

3.4 项目投资结算情况

4． 验收测试计划

4.1 验收测试原则

4.2 验收测试方式

4.3 验收测试内容

4.4 测试结果及缺陷分析

4.5 文档测试

4.5.1 文档主要测试内容

4.5.2 测试过程涉及到的一些文档

5． 项目验收情况汇总

5.1 项目验收情况汇总表

5.2 项目验收附件明细

5.3专家组验收意见

6． 项目验收结论

6.1 开发单位结论

6.2 建设单位结论

7．验收结果汇总

8．附件

8.1 附件一：软件平台验收单

8.2 附件二：功能模块验收单

8.3 附件三：项目文档验收单

8.4 附件四：硬件设备验收单

 

17. 测试分析报告写作模板

1. 概述

1.1 项目简介

1.2 编写目的

1.3 术语定义

1.4 测试环境

1.5 测试人员安排和分工

1.6 参考资料

2. 测试内容

2.1 系统界面需求

2.2 系统功能需求

2.3 系统性能需求

2.4 系统接口需求

2.5 用户界面测试报告

2.6 功能测试报告

2.7 性能测试报告

2.8 接口测试报告

2.9 数据库测试

2.10 安装、卸载测试

3. 测试发现的问题

3.1 功能测试不符合项列表

3.2 性能测试不符合项列表

3.3 接口测试不符合项列表

4. 测试结果分析

4.1 覆盖测试

       4.1.1 需求覆盖

       4.1.2 测试覆盖

4.2 缺陷的统计与分析

       4.2.1 缺陷汇总

       4.2.2 缺陷分析

       4.2.3 残留缺陷与为解决问题

5. 测试资源消耗

6. 分析与评价

6.1 能力

6.2 缺陷和限制

6.3 评价

7. 测试结论与建议

7.1 测试结论

7.2 建议

 

18. 测试总结写作模板

1. 概述

1.1 编写目的

1.2 项目背景

1.3 系统简介

1.4 术语和缩写词

1.5 测试工具

1.6 参考资料

2．测试环境与配置

3．测试方法

4．测试总结

4.1 测试时间、地点、人员

4.2 测试范围

4.3 工作组织

4.4 测试分析

4.4.1 测试统计

4.4.2 测试发现的问题汇总

4.4.3 测试结果分析

4.5 残留缺陷与未解决问题

4.5.1 残留缺陷

4.5.2 未解决问题

4.6 测试资源消耗情况

4.7 测试结论

4.7.1 功能性

4.7.2 易用性

4.7.3 可靠性

4.7.4 兼容性

4.7.5 安全性

4.8 测试文档

5. 建议

6. 附件

 

19. web测试写作模板

1. 概述

1.1   编写目的

1.2   术语和缩写词

1.3   参考资料

2. Web测试的重点及测试的主要内容

2.1 Web的功能测试；

2.1.1链接测试

2.1.2表单测试

2.1.3数据校验测试

2.1.4 Cookis测试

2.1.5 数据库测试

2.1.6 权限测试

2.1.7 应用程序特定的功能需求测试

2. 2 Web的性能测试（包括负载/压力测试）

2.2.1 基准性能测试

2.2.2 负载测试、

2.3 稳定性测试

2.4 压力测试等。

3．Web的用户界面测试

3.1 Web的用户界面页面、页面元素和容错性

       3.1.1 页面清单是否完整

       3.1.2页面在窗口中的显示是否正确、美观

       3.1.3页面特殊效果

3.1.4页面特殊效果显示是否正确

   3.2 页面元素应注意的内容

       3.2.1 Web的功能需要列出按钮、单选框、复选框、列表框、超连接、输入框

       3.2.2页面元素的文字、图形、签章

       3.2.3页面元素的按钮、列表框、核选框、输入框、超连接等外形、摆放位置

       3.2.4页面元素基本功能文字特效、动画特效、按钮、超连接

3.3 容错性应注意的内容

3.4 Web用户界面测试的内容

3.4.1 导航测试

3.4.2 图形测试

3.4.3 内容测试

       3.4.4 表格测试

       3.4.5 整体界面测试

4．Web兼容性测试

4.1 系统平台测试.

4.2 浏览器测试

4.3 分辨率测试

5．Web的安全性测试

   5.1 目录设置测试

   5.2 SSL测试

5.3 登录测试

5.4 日志文件测试

6．Web的接口测试；

6.1服务器接口测试

   6.2 外部接口测试

7．硬件\软件平台描述

 

20. 软件安全性测试写作模板

1. 概述

1.1   编写目的

1.2   术语和缩写词

1.3   参考资料

2. 用户认证安全性测试

3. 系统网络安全性测试

4. 数据库安全性测试

5. 软件安全性记录

 

 

 

 

 

 

 

 

二、linux基础

1.  如何查看 CPU 信息？

/proc/meminfo

2.  查看占用 CPU 使用率最高的进程？

ps -aux | sort -k3nr | head -K

3.  如何查看一个文件的末尾 50 行？

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

# head -n 10 /etc/profile

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

# tail -n 50 /etc/profile

4.  如何过滤文件内容中包含”ERROR“的行？

grep “ERROR” file_name

cat file_name | grep “ERROR”

5.  查看某端口号？

netstat -anp | grep port_number

6.  查看某进程号？

ps -ef | grep ps_name

ps -ef | grep ps_number

7.  查看 IP 地址？

ifconfig

8.  创建和删除一个多级目录？

mkdir -p ./a/b

rm -rf ./a

9.  在当前用户家目录中查找 haha.txt 文件？

find ~/ -name haha.txt

10.如何查询出 tomcat 的进程并杀掉这个进程，写出 linux 命令？

ps -ef | grep tomcat

kill -9 tomcat_port

11.动态查看日志文件？

tail -f log_file

12.查看系统硬盘空间的命令？

df -aTh

13.查看当前机器 listen 的所有端口？

netstat -tlnp

14.把一个文件夹打包压缩成 .tar.gz 的命令，以及解压拆包 .tar.gz 的命令？

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

15.Xshell  工具如果想要实现从服务器上传或者下载文件的话,可以在服务器上安装什么包？

lrzsz

16.以/etc/passwd 的前五行内容为例，提取用户名？

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

17.在 linux  中 find  和 grep  的区别？

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

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

linux  下的 find：

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

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

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

三、Web 测试

1.描述用浏览器访问 www.baidu.com 的过程？

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

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

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

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

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

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

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

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

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

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

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

2.  了解的常用浏览器有哪些？

IE ，Chrome ，Safari，Firefox ， Opera

3.  什么是 sql 注入，什么是跨站脚本，什么是跨站请求伪造？

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（前面提到防图片盗链接也是用的这种方式）。

令牌和验证都具有一次消费性的特征，因此在原理上一致的，但是验证码是一种糟糕的用户体验，不是必要的

情况下不要轻易使用验证码，目前很多网站的做法是如果在短时间内多次提交一个表单未获得成功后才要求提供验

证码，这样会获得较好的用户体验。

4.  给你一个网站怎么开展测试？

a)首先，查找需求说明、网站设计等相关文档，分析测试需求。

b)制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测，试界面测试，性能测试，数据库测试，安全性测试， .兼容性测试

c)设计测试用例：

l 功能性测试可以包括，但不限于以下几个方面：链接测试；链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等；提交功能的测试；多媒体元素是否可以正确加载和显示；多语言支持是否能够正确显示选择的语言等

l 界面测试可以包括但不限于一下几个方面：页面是否风格统一，美观。页面布局是否合理，重点内容和热点内容是否突出。控件是否正常使用。对于必须但为安装的空间，是否提供自动下载并安装的功能。文字检查。

l 性能测试一般从以下两个方面考虑：压力测试，负载测试，强度测试

l 数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证

等方面。

l 安全性测试：基本的登录功能的检查；是否存在溢出错误，导致系统崩溃或者权限泄露；相关开发语言的常见安全性问题检查，例如 SQL 注入等；如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持。

l 兼容性测试，根据需求说明的内容，确定支持的平台组合：浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性。

d)开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。

e)定期评审，对测试进行评估和总结，调整测试的内容。

5.  电商支付模块的测试如何展开？

支付流程里面就涉及到了第三方支付接口：

l 下单接口：商户提交下单请求到第三方支付接口，第三方支付收单成功后返回下单成功结果给到商户系统。

（下单接口的最终处理结果分为下单成功和下单失败，若未收到明确结果可调用单笔订单查询接口查询结果。）

l 支付接口：调用该接口时指定支付参数，完成买家账户向商户账户的支付，采用页面跳转交互模式和后台通 知交 互模 式 。（ 结果 分为 两路 返回 ：一 路为 前台在 return_url 页 面跳 转显示 支付 结果 ；一 路为 后台在notify_url 收到支付结果通知后进行响应。）

l 退款接口：调用第三方支付的支付请求接口返回付款成功后，在需要做退款处理时调用退款请求接口发起退款处理。 退款接口的最终处理结果分为退款成功和退款失败，若未收到明确结果可调用退款查询接口查询结果。）

l 单笔订单查询接口：根据订单号查询单笔订单信息和状态。退款订单查询接口：调用第三方支付的退款接口返回后，在需要查询退款请求状态可调用退款订单查询接口查询退款订单的状态和订单信息。

测试过程中需要注意的主要测试点及异常场景：

l 首先要保证接口都能正常调用；

l 生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效；

l 生成一笔订单，复制订单号和金额，再次生成一笔订单，用 fiddler 设置断点，用第一笔已完成的订单号和订单金额去替换现有的订单号和金额，无法完成支付；

l 生成一笔订单，跳转到第三方时修改金额，无法到账，或者如果是游戏充值游戏币的话，到账为篡改后的金额对应的游戏币；

l 异步通知屏蔽，同步有效，进行支付，同步能够正常到账；

l 同步设置无效，异步有效，进行支付，异步能够正常到账；

l 同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点时，能够正常通知到账（补单机制的验证，如果商户收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商户应答不是 ok 或超时，第三方支付就会认为通知失败，会在规定的时间内持续调用 notify_url ，一般有时间或次数的限制）；

l 针对支付订单在数据库中存储是否完整和正确进行校验（比如：第三方订单号 — 方便与第三方对账和问题排查、订单金额、订单状态等）；

l 如果是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发情况的验证以确保安全性；

l 如果是用户购买虚拟商品，比如话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证

6.  如何开展兼容性测试？

（1 ）Web 兼容性测试

l 首先开展人工测试，测试工程师测试主流浏览器和常用操作系统测试主流程和主界面，看看主流程和主界面是否有问题，如果存在问题，那么记录下 bug 情况，以及浏览器型号和版本，以及操作系统，准确定位bug 产生的原因，提交 bug ，告知开发人员修改。所有的主流设备都需要进行测试，只关注主流程和主界面，毕竟每个系统主流程和主界面不是很多，所以这个工作量还是可以承受的。

l 其次借助第三方测试工具，目前我觉得比较好用的第三方 Web 测试工具有 IEtester（离线）、SuperPreview（离线）和 Browsershots： browsershots.org（在线），一款可以测试 IE 的兼容，一款可以测试主流浏览器的兼容，包括谷歌、火狐、 Opera 等等。借助第三方测试工具，找到 bug 产生的位置，分析测试结果，告知程序员调整。

（2 ）APP 兼容性测试

l APP 的兼容性测试和 Web 测试类似，首先开展人工测试，测试工程师借助测试设备对主流程和主功能，主界面进行测试；收集所有的能收集到的不同型号的测试设备测试主流程和主界面，看看主流程和主界面是否有问题，如果存在问题，综合考虑设备的使用率等因素，看看是否需要调整，如果需要，那么记录下bug 情况以及测试设备的型号和操作系统，准确定位 bug 产生的原因，提交 bug ，告知开发人员修改。

l 其次借助第三方测试工具，对于 APP 的兼容性测试，推荐的是百度众测平台和云测平台，我经常使用的是云测平台，这两款测试工具里面包含了安卓和 iOS 的测试；测试很齐全，包括功能测试、深度兼容测试、

性能测试、网络环境测试，还可以模拟海量用户测试，，还可以导入自己编写的测试用例进行功能测试，里面还包括测试专家的测试，当然了找专家是要花钱滴。基本进行兼容性测试是不需要花钱的；测试工程师把打包好的 apk 或者 IPA 文件，上传到测试平台，选择需要测试的设备型号，开始任务即可；等待一段时间，在等待的时间你是不需要盯着的，你可以做其他的工作。测试完成后会生成一份测试报告，可以查看错误页面和错误日志，如果需要调整，那么提交 bug ，告知程序员修改即可。

7.  nginx,tomcat,apache 都是什么？

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

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

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

8.  apache  和 nginx  的区别？

Nginx  相对 Apache  的优点：

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

抗并发，nginx  处理请求是异步非阻塞的，支持更多的并发连接，而 apache  则是阻塞型的，在高并发下 nginx能保持低资源低消耗高性能；

配置简洁；

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

社区活跃。

Apache  相对 Nginx  的优点：

rewrite  ，比 nginx  的 rewrite  强大；

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

少 bug  ，nginx  的 bug  相对较多；

超稳定。

 

 

四、Web测试方法总结

一、输入框

1、字符型输入框：

（1）字符型输入框：英文全角、英文半角、数字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时，使用“粘贴、拷贝”功能尝试输入。

（2）长度检查：最小长度、最大长度、最小长度-1、最大长度+1、输入超工字符比如把整个文章拷贝过去。

（3）空格检查：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格

（4）多行文本框输入：允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）、

（5）安全性检查：输入特殊字符串（null,NULL, ,javascript,<script>,</script>,<title>,<html>,<td>）、输入脚本函数(<script>alert(“abc”)</script>)、doucment.write(“abc”)、<b>hello</b>）

2、数值型输入框：

（1）边界值：最大值、最小值、最大值+1、最小值-1

（2）位数：最小位数、最大位数、最小位数-1最大位数+1、输入超长值、输入整数

（3）异常值、特殊字符：输入空白（NULL）、空格或”~!@#$%^&*()_+{}|[]\:”<>?;\’,./?;:\’-=等可能导致系统错误的字符、禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能，通过剪贴板拷贝到输入框，分页符，分节符类似公式的上下标等、数值的特殊符号如∑，㏒，㏑，∏，+，-等、输入负整数、负小数、分数、输入字母或汉字、小数（小数前0点舍去的情况，多个小数点的情况）、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制，8进制数值、货币型输入（允许小数点后面几位）、

（4）安全性检查：不能直接输入就copy

3、日期型输入框：

（1）合法性检查：(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入[30][31]、输入非闰年，月输入[2]，日期输入[28、29]、输入闰年，月输入[2]、日期输入[29、30]、月输入[0、1、12、13]

 (2)异常值、特殊字符：输入空白或NULL、输入~！@#￥%……&*（）{}[]等可能导致系统错误的字符

（3）安全性检查：不能直接输入，就copy，是否数据检验出错？

（4）信息重复:

在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

二、搜索功能

若查询条件为输入框，则参考输入框对应类型的测试方法

1、功能实现：

（1）如果支持模糊查询，搜索名称中任意一个字符是否能搜索到

（2）比较长的名称是否能查到

（3）输入系统中不存在的与之匹配的条件

（4）用户进行查询操作时，一般情况是不进行查询条件的清空，除非需求特殊说明。

2、组合测试：

（1）不同查询条件之间来回选择，是否出现页面错误（单选框和多选框最容易出错）

（2）测试多个查询条件时，要注意查询条件的组合测试，可能不同组合的测试会报错。

 

三、添加、修改功能

1、特殊键：（1）是否支持Tab键 （2）是否支持回车键

2、提示信息：（1）不符合要求的地方是否有错误提示

3、唯一性：（1）字段唯一的，是否可以重复添加，添加后是否能修改为已存在的字段（字段包括区分大小写以及在输入的内容前后输入空格，保存后，数据是否真的插入到数据库中，注意保存后数据的正确性）

4、数据 正确性：

（1）对编辑页的每个编辑项进行修改，点击保存，是否可以保存成功，检查想关联的数据是否得到更新。

（2）进行必填项检查（即是否给出提示以及提示后是否依然把数据存到数据库中；是否提示后出现页码错乱等）

（3）是否能够连续添加（针对特殊情况）

（4）在编辑的时候，注意编辑项的长度限制，有时在添加的时候有，在编辑的时候却没有（注意要添加和修改规则是否一致）

（5）对于有图片上传功能的编辑框，若不上传图片，查看编辑页面时是否显示有默认的图片，若上传图片，查看是否显示为上传图片

（6）修改后增加数据后，特别要注意查询页面的数据是否及时更新，特别是在首页时要注意数据的更新。

（7）提交数据时，连续多次点击，查看系统会不会连续增加几条相同的数据或报错。

（8）若结果列表中没有记录或者没选择某条记录，点击修改按钮，系统会抛异常。

 

四、删除功能

1、特殊键：（1）是否支持Tab键 （2）是否支持回车键

2、提示信息：（1）不选择任何信息，直接点击删除按钮，是否有提示（2）删除某条信息时，应该有确认提示

3、数据 实现：（1）是否能连续删除多个产品（2）当只有一条数据时，是否可以删除成功 （3）删除一条数据后，是否可以添加相同的数据（4）如系统支持批量删除，注意删除的信息是否正确 （5）如有全选，注意是否把所有的数据删除（6）删除数据时，要注意相应查询页面的数据是否及时更新 （7）如删除的数据与其他业务数据关联，要注意其关联性（如删除部门信息时，部门下游员工，则应该给出提示）（8）如果结果列表中没有记录或没有选择任何一条记录，点击删除按钮系统会报错。

如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试

单项功能测试（增加、修改、查询、删除）

增加——>增加——>增加 （连续增加测试）

增加——>删除

增加——>删除——>增加 （新增加的内容与删除内容一致）

增加——>修改——>删除

修改——>修改——>修改 （连续修改测试）

修改——>增加（新增加的内容与修改前内容一致）

修改——>删除

修改——>删除——>增加 （新增加的内容与删除内容一致）

删除——>删除——>删除 （连续删除测试）

 

五、注册、登陆模块

1、注册功能：

（1）注册时，设置密码为特殊版本号，检查登录时是否会报错

（2）注册成功后，页面应该以登陆状态跳转到首页或指定页面

（3）在注册信息中删除已输入的信息，检查是否可以注册成功。

2、登陆 功能：

（1）输入正确的用户名和正确的密码

（2）输入正确的用户名和错误的密码

（3）输入错误的用户名和正确的密码

（4）输入错误的用户名和错误的密码

（5）不输入用户名和密码（均为空格）

（6）只输入用户名，密码为空

（7）用户名为空，只输入密码

（8）输入正确的用户名和密码，但是不区分大小写

（9）用户名和密码包括特殊字符

（10）用户名和密码输入超长值

（11）已删除的用户名和密码

（12）登录时，当页面刷新或重新输入数据时，验证码是否更新

 

六、上传图片测试

1、功能 实现：

（1）文件类型正确、大小合适

（2）文件类型正确，大小不合适

（3）文件类型错误，大小合适

（4）文件类型和大小都合适，上传一个正在使用中的图片

（5）文件类型大小都合适，手动输入存在的图片地址来上传

（6）文件类型和大小都合适，输入不存在的图片地址来上传

（7）文件类型和大小都合适，输入图片名称来上传

（8）不选择文件直接点击上传，查看是否给出提示

（9）连续多次选择不同的文件，查看是否上传最后一次选择的文件

七、查询结果列表

1、功能 实现：

（1）列表、列宽是否合理

（2）列表数据太宽有没有提供横向滚动

（3）列表的列名有没有与内容对应

（4）列表的每列的列名是否描述的清晰

（5）列表是否把不必要的列都显示出来

（6）点击某列进行排序，是否会报错（点击查看每一页的排序是否正确）

（7）双击或单击某列信息，是否会报错

八、返回键检查

1、一条已经成功提交的记录，返回后再提交，是否做了处理

2、检查多次使用返回键的情况，在有返回键的地方，返回到原来的页面多次，查看是否会出错

 

九、回车键检查

1、在输入结果后，直接按回车键，看系统如何处理，是否会报错

十、刷新键检查

1、在Web系统中，使用刷新键，看系统如何处理，是否会报错

十一、直接URL链接检查

1、在Web系统中，在地址栏直接输入各个功能页面的URL地址，看系统如何处理，是否能够直接链接查看（匿名查看），是否有权限控制，是否直接执行，并返回相应结果页；

十二、界面和易用性测试

1、风格、样式、颜色是否协调

2、界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条

3、界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字）

4、操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作）

5、提示界面是否符合规范（不应该显示英文的cancel、ok，应该显示中文的确定等）

6、界面中各个控件是否对齐

7、日期控件是否可编辑

8、日期控件的长度是否合理，以修改时可以把时间全部显示出来为准

9、查询结果列表列宽是否合理、标签描述是否合理

10、查询结果列表太宽没有横向滚动提示

11、对于信息比较长的文本，文本框有没有提供自动竖直滚动条

12、数据录入控件是否方便

13、有没有支持Tab键，键的顺序要有条理，不乱跳

14、有没有提供相关的热键

15、控件的提示语描述是否正确

16、模块调用是否统一，相同的模块是否调用同一个界面

17、用滚动条移动页面时，页面的控件是否显示正常

18、日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX

19、页面是否有多余按钮或标签

20、窗口标题或图标是否与菜单栏的统一

21、窗口的最大化、最小化是否能正确切换

22、对于正常的功能，用户可以不必阅读用户手册就能使用

23、执行风险操作时，有确认、删除等提示吗

24、操作顺序是否合理

25、正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。

26、系统应该在用户执行错误的操作之前提出警告，提示信息.

27、页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。

28、合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。

29、检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。

 

十三、兼容性测试

兼容性测试不只是指界面在不同操作系统或浏览器下的兼容，有些功能方面的测试，也要考虑到兼容性，

包括操作系统兼容和应用软件兼容，可能还包括硬件兼容

比如涉及到ajax、jquery、javascript等技术的，都要考虑到不同浏览器下的兼容性问题。

十四、链接测试

主要是保证链接的可用性和正确性，它也是网站测试中比较重要的一个方面。

可以使用特定的工具如XENU来进行链接测试。

1导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到30k以下
（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

十五、业务流程测试（主要功能测试）

业务流程，一般会涉及到多个模块的数据，所以在对业务流程测试时，首先要保证单个模块功能的正确性，其次就要对各个模块间传递的数据进行测试，这往往是容易出现问题的地方，测试时一定要设计不同的数据进行测试。

十六、安全性测试

（1）SQL注入（比如登陆页面）

（2）XSS跨网站脚本攻击：程序或数据库没有对一些特殊字符进行过滤或处理，导致用户所输入的一些破坏性的脚本语句能够直接写进数据库中，浏览器会直接执行这些脚本语句，破坏网站的正常显示，或网站用户的信息被盗,构造脚本语句时，要保证脚本的完整性。

  document.write(“abc”)

  <script>alter(“abc”)</script>

（3）URL地址后面随便输入一些符号，并尽量是动态参数靠后

（4）验证码更新问题

（5）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

（6）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

（7）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

（8）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

（9）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

 

十七、性能测试

1连接速度测试

用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。

另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

2.负载测试

负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？

3压力测试

负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。

备注：

1、负载/压力测试应该关注什么

测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。

1）瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟X个用户同时访问测试站点。

2）每个用户传送大量数据
网上书店的多数用户可能只订购1-5书，但是大学书店可能会订购5000本有关心理学介绍的课本?或者一个祖母为她的50个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址)系统能处理单个用户的大量数据吗?

3）长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于web的email服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100个人同时点击某个站点。但是同时组织100000个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
采取措施：采用性能测试工具WAS、ACT，LR等协助进行测试

 

十八、测试中应该注意的其他情况

1、在测试时，与网络有关的步骤或者模块必须考虑到断网的情况

2、每个页面都有相应的Title，不能为空，或者显示“无标题页”

3、在测试的时候要考虑到页面出现滚动条时，滚动条上下滚动时，页面是否正常

4、URL不区分大小写，大小写不敏感

5、、对于电子商务网站，当用户并发购买数量大于库存的数量时，系统如何处理

6、测试数据避免单纯输入“123”、“abc“之类的，让测试数据尽量接近实际

7、进行测试时，尽量不要用超级管理员进行测试，用新建的用户进行测试。测试人员尽量不要使用同一个用户进行测试

8、提示信息：提示信息是否完整、正确、详细

9、帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细

10、可扩展性：是否由升级的余地，是否保留了接口

11、稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护

12、运行速度：运行的快慢，带宽占用情况

五、测试场景标准库

1.一般测试场景

1.  所有必填字段都应校验并用星号“*”标注

2.  验证错误提示信息应在正确的位置合理显示

3.  所有的错误信息都应用相同的CSS样式显示（如：红色）

4.  一般性的确认信息应该用错误消息意外的CSS样式显示（如：绿色）

5.  提示信息应是有意义的

6.  下拉字段的第一个条目应是空白或“请选择”之类的文本

7.  删除页面中的任何记录信息都应要求确认

8.  如果页面支持记录的添加/删除/更新功能，那么页面中应提供“全选”和“全不选”所有记录的选择项

9.  数量值应该显示正确的货币符号

10. 应提供默认页面排序

11. 重置按钮功能应将页面所有字段设置为默认值

12. 所有的数值都应正确地格式化

13. 输入字段应检查最大字段值，输入的字段值超过指定的最大值则不被接受或不被存储到数据库

14. 检查所有输入字段中输入特殊字符的情况

15. 使用标准的字段标签，如：一个接受用户姓名的字段标签可以被定义为“姓名”

16. 检查添加/编辑/删除操作后页面中信息记录的排序功能

17. 检查超时功能，超时的值应是可配置的，操作超时后检查应用程序的行为是否合理

18. 检查Cookies在应用程序中的使用

19. 检查可下载文件是否指向了正确的文件路径

20. 所有的资源键应该可以在配置文件或数据库中配置，而不是写死

21. 资源键的命名应始终遵循标准惯例

22. 验证所有的web页面标记（验证HTML和CSS的语法错误）以确保它符合标准

23. 应用程序崩溃或不可用页面应该重定向到错误页面

24. 在所有页面中检查文本的拼写和语法错误

25. 检查数字输入字段中输入字符的情况，应提示合适的校验信息

26. 如果字段允许输入数值，应该检查输入负数的情况

27. 检查数量字段值带有小数的情况

28. 检查页面中所有按钮的功能

29. 用户连续点击提交按钮时不能重复提交页面信息

30. 在任何计算中都应处理除以0的情况

31. 应正确处理输入数据前后的空格

2.过滤条件测试场景

1.  用户应能够使用页面中的所有参数过滤结果

2.  精确搜索功能应根据用户选择的所有搜索参数加载搜索页面

3.  当页面中至少需要一个过滤条件才能执行搜索操作时，必须保证用户没有设置任何过滤条件提交查询时能显示合适的错误提示信息

4.  当页面中至少有一个过滤条件是非强制的时，用户提交查询后那些非强制过滤条件使用默认搜索条件查询相关结果

5.  过滤条件设置为无效值时应显示合适的校验信息

3.结果表测试场景

1.  当结果页面加载时长超过默认时长时，应该显示“页面加载中”之类的提示信息

2.  检查结果表中获取的数据是否满足所有的搜索条件

3.  结果总数都应在结果表中显示

4.  使用的搜索条件应该在结果表中显示

5.  结果表中的值应该按照默认列排序

6.  排序列应该显示排序的图标

7.  结果表中的结果正确且包含所有指定的列

8.  对支持排序的列，应能进行升序和降序排序操作

9.  结果表中的行列间距合理

10. 当结果多于每页默认显示的结果数时应正确分页

11. 检查上一页、下一页、首页和末页分页功能

12. 结果表中无重复的记录

13. 检查所有的列是否都可见，必要时启用水平滚动条

14. 检查数据动态列（列值由其他列计算得来的列）

15. 对于报表结果表，应检查行汇总和列汇总的值

16. 对于报表结果表，应检查有分页的情况下用户切换分页时的行汇总值

17. 检查显示列是否使用了正确的符号，如：%（百分号）应该显示在百分数计算结果中

18. 检查结果表中的数据是否启用了日期范围

4.窗口测试场景

1.  检查默认窗口的大小是否正确

2.  检查子窗口的大小是否正确

3.  检查默认焦点是否放在了页面中的某个字段上（一般来说，焦点放在页面中第一个可输入的字段上）

4.  检查关闭父窗口或开着的窗口时是否会关闭子窗口

5.  当子窗口开着时，用户不能使用或更新父窗口或子窗口后面窗口的字段值

6.  检查窗口最小化、最大化和关闭功能

7.  检查窗口是否能重设大小

8.  检查父窗口和子窗口的滚动条的功能

9.  检查子窗口中的“取消”按钮的功能

5.数据测试场景

1.页面提交成功时检查数据是否正确地保存在数据库中

2.检查不接受空值的列值

3.数据应根据表设计被存储在单个或多个表中

4.索引名称应按照标准如IND_ <表名> _ < 列名>

5.表应该有主键

6.应对表中的列给出相应的描述信息（除了诸如创建时间、创建人等审计列）

7.应该为每个数据库的添加/更新操作添加日志

8.应该为需要的表创建索引

9.检查是否只有操作完全成功后才将数据提交到数据库中

10.一旦事务失败数据应该回滚

11.数据库名称应按照应用程序类型命名，即测试,UAT,沙箱,现场(尽管这不是一个标准，但对数据库维护是很有帮助的)

12.数据库逻辑名称应根据数据库名称命名(这不是标准但又有利于数据库维护)

13.存储过程不应该以前缀“sp_”命名

14.检查表审计列的值(如创建日期、创建人、更新日期、更新者、已删除、删除日期、删除者等等)填充正确

15.检查输入数据保存时是否未被截断，在页面中显示的字段长度和数据库的字段长度应该是相同的

16.检查包含最小、最大和浮点的数值字段

17.检查数值字段含有负值(接受和拒绝两种情况)

18.检查单选按钮和下拉列表正确地保存在数据库中

19.检查数据库字段设计的数据类型和数据长度是否正确

20.检查所有的表约束条件如主键、外键等是否正确实现

21.测试存储过程和触发器的样本输入数据

22.输入数据的首尾空格应在数据保存到数据库之前被自动隐去

23.主键列不允许为NULL值

6.上传功能测试场景

1.检查图片上传路径

2.检查图像上传和修改功能

3.检查各种扩展图像文件的上传(例如JPEG、PNG、BMP等).

4.检查文件名中含有空格或其他可用特殊字符的图片的上传

5.检查重复名称图片上传

6.图片尺寸大于最大允许值，上传时应该显示适当的错误消息.

7.检查上传的图片文件类型外的其它文件时(例如txt、doc、pdf、exe等等)，应该显示适当的错误消息

8.检查如果上传的图片满足指定的高度和宽度(如果有定义的话)则可以成功上传，否则不能上传

9.上传大尺寸图片时应显示上传进度条

10.检查上传过程中的取消按钮是否有效

11.检查文件选择对话框中的文件列表是否只显示支持文件类型

12.检查上传多个图像的功能

13.上传后检查图像质量，图像质量不应该改变

14.检查用户是否能够使用/查看上传的图像

7.发送电子邮件场景测试

1.所有电子邮件模板应该使用CSS标准

2.要验证电子邮件地址后再发送电子邮件

3.特殊字符在邮件正文模板应妥善处理

4.特定语言的字符(例如：俄文、中文或德文字符)应在电子邮件主体模板中妥善处理

5.电子邮件主题不能空

6.占位符字段中使用电子邮件模板应该替换为实际的值如{姓} {名}应该替换为所有收件人正确的名字和姓氏

7.如果报告有动态值包含在电子邮件的正文中,报告数据应正确计算

8.电子邮件发送者的名字不能为空

9.应该在不同的电子邮件客户端（如：Outlook,Gmail,Hotmail,Yahoo 邮件等）检查电子邮件

10.检查发送电子邮件功能使用TO、CC和BCC字段

11.检查纯文本邮件

12.检查HTML格式的电子邮件

13.查看邮件页眉和页脚相应的公司LOGO,隐私政策和其他链接

14.检查带附件的电子邮件发送

15.检查给一个、多个或者联系人组发送电子邮件

16.检查回复电子邮件地址是否正确

17.检查发送大量的电子邮件

8.excel导出测试场景

    1.文件输出时应该有适当的文件扩展名

　　2.导出Excel文件的文件名应该按照标准，例如：如果文件名使用时间命名，它应该在导出文件的时候妥善换成实际时间

　　3.当Excel文件包含日期列时需要检查导出的日期格式

　　4.检查数字格式的数值或货币值，格式应该和页面显示的相同

　　5.导出的文件应该有适当的列名称

　　6.默认页面排序应体现在导出文件中

　　7.Excel文件数据应正确格式化包括页眉和页脚文本、日期、页码等所有页面的值

　　8.检查数据在页面上显示的文件与导出Excel文件是是否一样

　　9.检查使用分页时的导出功能

　　10.检查导出按钮图标是否根据导出的文件类型正确显示，如：导出的是.xls文件，则显示Excel文件对应的图标

　　11.检查大文件的导出功能

　　12.检查页面包含特殊字符的导出功能，检查这些特殊字符是否正确地导出到Excel文件

　　13.上传后检查图像质量，图像质量不应该改变

　　14.检查用户是否能够使用/查看上传的图像

 

9. 性能测试场景

    1.检查页面加载时间是否在可接受范围内

　　2.检查页面加载缓慢的链接

　　3.检查在轻度、正常、中度和重度负载环境下所有操作的响应时间

　　4.检查数据库存储过程和触发器的性能

　　5.检查数据库查询执行时间

　　6.检查应用程序的负载测试

　　7.检查应用程序的压力测试

8.在峰值负载条件下检查CPU和内存的使用情况

10.安全性能测试场景

    1.检查SQL注入攻击

　　2.安全页面应该使用HTTPS协议

　　3.崩溃页面中不应泄漏应用程序或服务器信息，只有错误页面才显示这些

　　4.转义特殊字符的输入

　　5.错误消息不应该透露任何敏感信息

　　6.所有凭证都应该通过一个加密传输通道

　　7.测试密码安全性和密码强制策略

　　8.检查应用程序的注销功能

　　9.检查暴力攻击

　　10.Cookie信息只能以加密的格式存储

　　11.检查会话cookie持续时间和会话超时或注销后登录会话终止情况

　　12.会话标记应该通过安全通道传送

　　13.密码不应该存储在cookie中

　　14.对阻断服务攻击进行测试

　　15.检测内存泄漏

　　16.通过在浏览器地址栏中手动更改变量值访问未经授权的应用程序

　　17.验证对文件扩展名的处理方式以使得.exe文件不能上传到服务器或在服务器上执行

　　18.如密码和信用卡信息等敏感领域不应该启用自动完成

　　19.对文件上传功能应使用文件类型限制和反病毒扫描上传的文件

　　20.检查目录是否可用

　　21.在输入密码和其他敏感字段时应该被伪装起来

　　22.检查忘记密码是否采用了密码保护功能，如：临时密码在指定的时间段后过期，更改密码或获取新密码有安全问题提问等

　　23.检查验证码功能

　　24.检查重要事件是否被记录在日志文件中

　　25.检查是否正确实现访问权

 

 

 

 

六、管理工具

1.  熟悉的软件项目管理工具有哪些？

2.  结合你的测试工作中使用的管理缺陷的工具，讲一下使用此工具描述软件缺陷和跟踪管理流程 ?

3.  简述常用的 Bug 管理或者用例管理工具 , 并且描述其中一个工作流程？

常用：testlink， QC，mantis ，禅道，TAPD，JIRA 。

TAPD ：产品创建(需求，计划，模块 )–>项目创建（PM 排期、任务分解）–>研发 (编码、单元 测试等)–>测试

(测试计划，用例，执行，bug ，报告等)。

4.  禅道和 qc 的区别？

同为缺陷管理工具。

QC

作为缺陷管理工具， QC 在缺陷管理方面，做的相对完善。提 bug 页面：填写内容可以根据测试需求，不断

修改添加新的字段；以我上一家公司为例，在提 bug 过程中，有一下几个必填项：Bug 状态（new、fixed 、closed

等）、发现人员、缺陷发现阶段 (测试阶段、上现阶段等 ) 、缺陷来源（测试人员给出的 bug 定位）、 Bug 分类（功

能、性能等问题）、测试阶段（单元测试、集成测试、系统测试等）、归属需求、缺陷回归次数、优先级、分配给，

这些必填项再加上 bug 标题和操作描述、上传附件，使很多疑问都变得清晰。

缺陷查看页面：可以根据自己需要选择要呈现的字段，相对人性化可操作，每个显示的字段都可以进行筛选，

使研发人员很快能定位到属于自己的 bug ，再根据 bug 状态、优先级进行筛选，使未完结的 bug 能有序并无遗漏

地完成修改；页面还有注释功能，研发人员能写出针对本问题的各种感想，方便完善而又人性化。

禅道（开源版）

禅道涉及面非常广，但是在缺陷管理这方面，与老牌的 QC 还是略逊一筹。提 bug 页面：页面是非常清晰整洁的 web 页面，但是需要填写的字段，并没有完全覆盖开发和测试人员的全部需求。页面字段：产品模块（对应 QC

中的项目）、所属项目（对应 QC 中的需求）、影响版本（bug 所属版本？）、当前指派（修改 bug 的人员）、bug 标题、重现步骤、相关需求（页面标注了这个字段，但是什么也没有显示，并且没有可填写的位置）、相关任务、类型/严重

 

 

 

 

 

 

 

 

 

七、软件测试工程师忙碌的一天

1.  引言

软件测试成为最近  IT  行业的“香饽饽”，引得很多人对软件测试跃跃欲试。可是软件测试

的门槛并不低，对于没有软件测试经验的新人而言，如何尽快转入测试工作中去呢？

了解软件测试都做些什么，具体过程是怎么进行的，可以有助于对软件测试进行初步了解，

尽快进入测试工作角色。但是关于软件测试的工作流程，各种现有书籍和文章往往都描述的

非常复杂，充斥着不少测试术语，使测试初学者望而生畏。

现在让我们换一种角度看看典型的软件测试是如何进行的，暂且把软件测试过程看作一场

大戏，主角就是测试工程师，按照时间顺序记录软件测试工程师一天的工作场景（假设正常

工作时间  9:00  到  18:00  ）。

2.  测试大戏开演

时间：  9:00

工作场景：

· 启动工作计算机，查看收到的电子信件。

画外音：

· 查看收到的电子邮件（哇塞，这么多电子邮件！），理解当天的测试工作的内容和

要求。

· 测试工程师至少配置两台计算机：其中一台是日常工作用，例如，收发电子邮件等。

另外还有一台软件测试用的计算机。

时间：  9:10

工作场景：

· 回复电子邮件。

画外音：

· 回复电子邮件。如果对于安排的测试任务和要求存在任何疑问，请在回复电子邮件

时列举出来。如果任务明确，回信中可以简单的说明理解测试任务了，按照测试任务要求进

行测试。 正好今天有一封电子邮件分配了测试任务  A  ，而且任务明确，测试文档等完整。）

· 电子邮件有不同的优先级，任务非常紧迫的电子邮件应该优先处理，尽快回复。（面

对多封邮件保持镇定，分清哪些邮件需要马上回复）

· 并非全部的电子邮件都需要回复（抄送给自己的邮件和一般通告等不需要回复）

时间：  9:25

工作场景：

· 启动用于测试的计算机

· 根据测试要求配置操作系统、安装要测试的软件

· 根据测试用例执行测试任务  A  。

画外音：

· 测试一般需要按照测试指导文档和测试用例进行。（软件测试可不是盲目的乱测一

气的呀！）

· 很多软件的测试要求在一个“干净”的计算机上测试（提示：干静的计算机是仅安装

了操作系统，没有安装其他应用程序的计算机）。

· 在进行正式测试前，需要阅读测试文档，明确测试任务（这些测试文档你找到了吗？

是最新的测试文档吗？）。

时间：  11:00

工作场景：

· 执行软件测试，书写软件测试  Bug  报告

画外音：

· 按照测试要求，尽量多找出软件的  Bug  。（什么破软件，能找出这么多  Bug  ！

反过来想，软件如果没有  Bug  ，我们测试工程师不就失业了吗！）

· 根据发现的软件  Bug  ，按照客户要求写出每个  Bug  的报告（要书写明白，否则客

户事后会要求你重写，很费时间，也影响公司的测试质量，是否很没有面子？）

时间：  11:30

工作场景：

· 报告测试执行中的遇到了问题

画外音：

· 如果测试用例的步骤不明确或者测试的软件不能成功安装，无法进行下面的测试，

应该及时向测试负责人报告，等待答复后进行测试。（重大问题，切莫瞒报，也别主观想当

然地猜测！）

· 如果某些测试步骤不明确，但是可以暂时跳过，请向测试负责人报告，并且继续进

行下面的测试。（灵活处理，合理利用时间，时间就是金钱！）

时间：  12:00

工作场景：

· 查收和回复新邮件，新邮件又来了一个新的测试任务  B  ，而且要求紧急处理。

· 暂停测试任务  A  ，进行测试任务  B  。

画外音：

· 测试过程中，要主要定时查看是否有新邮件，特别是那些要求非常紧急的任务。（重

要任务一定要优先处理，否则就是工作失职）

· 如果新任务比较紧急，应该中断当前的测试，接着执行新任务。（为什么计划总是

没有变化快，可是现实就是这样。）

时间：  12:30

工作场景：

· 午餐、休息

画外音：

· 阳光、午餐、休息，美！（禁止在办公室玩任何电子游戏，办公室不是娱乐场所！）

时间：  13:30

工作场景：

· 查收和回复新邮件

画外音：

· 真幸运，没有其他新任务。

· 继续上午的任务  B  。

时间：  14:30

工作场景：

· 完成新任务  B  ，向测试负责人提交任务  B  的测试结果

画外音：

· 完成任何任务后，需要向测试负责人发送任务完成的电子邮件。（这一点很重要的，

否则你做的工作再多，测试负责人也不一定很清楚）

· 提交任务的电子邮件中，应该写明任务是否全部完成，存在什么问题，测试结果存

放在什么计算机的哪个目录中。（想象测试负责人需要你提交哪些内容，最好在一封信中交

待明白，完整，清楚，条理分明）

时间：  14:40

工作场景：

· 发送测试任务  A  不能按期完成的电子邮件

画外音：

· 由于执行了新测试任务  B  ，使得测试任务  A  不能按时完成，应该及早向测试负责

人发送电子邮件。（如果你不主动说无法按时完成任务  A  ，测试负责人就默认为你能够按

时完成。而如果到了完成任务的最后期限，而你突然向测试负责人说任务还没有完成，那么

我可以很负责任地告诉你：测试负责人将会很生气，后果很严重！）

· 得到测试负责人的答复后，继续执行测试任务  A  。

· 如果客户要求必须当天完成测试任务  A  ，可能要做好加班准备（苦恼  …  ）。或

者请测试负责人将一部分任务分解给其他测试人员执行（呵呵，谢谢兄弟们拉我一把  …   ）。

时间：  14:50

工作场景：

· 继续执行测试任务  A  。

画外音：

· 寻找软件  Bug  （这是主要任务之一）

· 书写  Bug  测试报告（这也是主要任务之一）

时间：  15:30

工作场景：

· 查收和回复新邮件

画外音：

· 没有新电子邮件，呵呵！（最不喜欢在测试工作中，经常有邮件来骚扰！）

· 继续执行测试任务  A  。

时间：  17:00

工作场景：

· 参加测试小组内部会议

画外音：

· 经常在测试过程中，测试小组内部会召开短暂的会议。（交流很重要的，倾听和发

言一个都不能少）

· 会议内容一般是测试过程中遇到的问题，以及可能的解决办法，也包括测试进度是

否与测试计划保持一致。

时间：  17:30

工作场景：

· 发送当天任务完成情况的电子邮件

画外音：

· 当天任务完成情况的报告应该在下班前尽早发送给测试负责人，以便得到及时回复。

· 总结当天测试任务完成的情况（全部完成还是部分完成）

· 测试遇到的需要测试负责人或者问题客户帮助解决的问题（遇到问题一定要反映，

不要什么问题都自己扛！）

· 给出当天处理  Bug  的数量、类型和存放位置（确保测试负责人能很容易的找到这些

测试结果吗？）

时间：  17:45

工作场景：

· 整理当天的测试文档，

· 做好备份

· 个人总结

画外音：

· 备份当天的测试结果（有备无患！）

· 总结测试遇到的问题和学习的新知识（好好学习，天天向上！）

· 准备第二天的测试任务（未雨绸缪）

时间：  18:00

工作场景：

· 下班

画外音：

· 如果不需要加班，按时回家，爽！

3.  测试大戏背后的故事

上面的测试场景描述基本上反映了软件测试工程师的工作情形，但是由于测试工作的复杂

性、琐碎性、变化性，实际测试过程将是不断变化的。

测试的变化性

对于软件本地化等外包测试，测试过程和测试要求因不同客户而异，即使相同客户的不同

项目，也会有些变化。另外，测试所用的测试计划、测试用例、测试  Build  版本经常变化。

这是对测试工程师需要面对和正确处理的工作挑战。

多任务同时处理

软件测试工程师在一天的工作时间里，可能需要做多件事情（例如，测试负责人可能中间

会安排新的任务），正常测试过程经常被中断，对此需要有相应的心理准备。

及时交流

测试过程很少是一帆风顺的，特别是不熟悉的新软件，或者测试用例没有表达清楚。这时

除了自己学习和思考，还需要向测试组的其他同事请教。如果问题仍然没有解决，请及时向

测试负责人反映情况，寻求帮助（提示：测试负责人积累了软件测试经验，一般问题都可以

搞定，但是测试负责人也不是万能的，他们也有很多不能解决的问题，但是他们有“杀手锏”

—  向客户的测试负责人寻求帮助，由于源语言是客户开发的，客户才是万能的！）。

电子邮件是主要的交流方式

测试过程不要一味地在测试计算机上做下去，要经常在日常工作用计算机查看和回复电子

邮件，以免耽误了更重要的任务。除了电子邮件之外，也可以打电话和即时网络交流工具（

MSN  等），或者面对面与同事交流（提示：对于复杂的问题，与其来回发送多封电子邮件

还说不明白，还不如打个电话或者面对面交谈更有效）。

4.  结束语

有人说，测试很枯燥，而且“一点技术含量都没有”。也有人说，软件测试大有前途！现在

中国确的不是软件编程大师，而是软件测试大师。这些观点孰是孰非，您请自己琢磨。不过

既然从事了测试行业，还是将它做好为上！

八、软件测试工程师职业发展的各个阶段

初级测试工程师

刚入门的拥有计算机科学学位的个人或具有一些手工测试经验的个人。开发测试脚本并开始

熟悉测试生存周期和测试技术，通常需要接受系统的软件测试技术培训。

测试工程师/测试分析员

具有 1-2 年经验的测试工程师或程序员。编写自动测试脚本程序并担任测试编程初期的领导

工作。进一步拓展编程语言、操作系统、网络与数据库方面的技能。

高级测试工程师/测试分析师

具有 3-4 年经验的测试工程师或程序员。帮助开发或维护测试或编程标准与过程，负责同级

的评审，并为其它初级的测试工程师或程序员充当顾问。继续拓展编程语言、操作系统、网

络与数据库方面的技能。

测试组负责人

具有 4-6 年经验的测试工程师或程序员。负责管理 1 至 3 名测试工程师或程序员，担负一

些进度安排和工作规模/成本估算职责，更集中于技能方面。

测试/编程负责人

具有 6-10 年经验的测试工程师或程序员。负责管理 8 至 10 名技术人员，负责进度安排、

工作规模/成本估算、按进度表和预算目标交付产品，负责开发项目的技术方法，为一些用

户提供支持与演示，开发一些特定领域的技术专长。

测试/质量保证/开发（项目）、经理

具有 10 多年的工作经验。管理 8 名或更多的人员参加的 1 个或多个项目，负责这一领域（测

试/质量保证/开发）内的整个开发生存周期业务，为一些用户提供交互和大量演示，负责项

目成本、进度安排、计划和人员分工。

计划经理

具有 15 年以上开发与支持（测试/质量保证）活动方面的经验。管理从事若干项目的人员以

及整个开发生存周期，负责把握项目方向与盈亏责任。

 

 

九、XX系统测试总结报告

编写目的

编写该测试总结报告主要有以下几个目的

1． 通过对测试结果的分析，得到对软件质量的评价

2． 分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考

3． 评估测试测试执行和测试计划是否符合

4． 分析系统存在的缺陷，为修复和预防bug提供建议

背景

 

用户群

    主要读者：XX项目管理人员，XX项目测试经理

其他读者：XX项目相关人员。

定义

严重bug：出现以下缺陷，测试定义为严重bug

ü 系统无响应，处于死机状态，需要其他人工修复系统才可复原。

ü 点击某个菜单后出现“The page cannot be displayed”或者返回异常错误。

ü 进行某个操作（增加、修改、删除等）后，出现“The page cannot be displayed” 或者返回异常错误

ü 当对必填字段进行校验时，未输入必输字段，出现“The page cannot be displayed” 或者返回异常错误

ü 系统定义不能重复的字段输入重复数据后，出现“The page cannot be displayed” 或者返回异常错误

 

测试对象

略

测试阶段

系统测试

测试工具 

Bugzilla缺陷管理系统

参考资料

《XX需求和设计说明书》

《XX数据字典》

《XX后台管理系统测试计划》

《XX后台管理系统测试用例》

《XX项目计划》

测试概要

XX后台管理系统测试从2007年7月2日开始到2007年8月10日结束，共持续39天，测试功能点174个，执行2385个测试用例，平均每个功能点执行测试用例13.7个，测试共发现427个bug，其中严重级别的bug68个，无效bug44个，平均每个测试功能点2.2个bug。

XX总共发布11个测试版本，其中B1—B5为计划内迭代开发版本（针对项目计划的基线标识），B6－B8为回归测试版本。计划内测试版本，B1—B4测试进度依照项目计划时间准时完成测试并提交报告，其中B4版本推迟一天发布版本，测试通过增加一个人日，准时完成测试。B5版本推迟发布2天，测试增加2个人日，准时完成测试。

B6－B11为计划外回归测试版本，测试增加5个工作人日的资源，准时完成测试。

XX测试通过Bugzilla缺陷管理工具进行缺陷跟踪管理，B1—B4测试阶段都有详细的bug分析表和阶段测试报告。

进度回顾

版本/时间	计划开始时间	实际开始时间	计划完成时间	实际完成时间	加班	增加资源
B1	2007.7.2	2007.7.2	2007.7.5	2007.7.5	否	否
B2	2007.7.16	2007.7.16	2007.7.19	2007.7.19	否	否
B3	2007.7.23	2007.7.23	2007.7.25	2007.7.24	否	2个人日
B4	2007.7.28	2007.7.29	2007.7.31	2007.7.31	1个人1天1个人2天	2个人日
B5	2007.8.1	2007.8.2	2007.8.6	2007.8.3	否	2个人日
B6		2007.8.4		2007.8.4	2个人1天	2个人日
B7		2007.8.5		2007.8.5	1个人1天	1个人日
B8
B9	2007.8.9	2007.8.9	2007.8.10	2007.8.10	否	2个人日
B10
合计					1个人6天	11个人日

测试执行

此次测试严格按照项目计划和测试计划执行，按时完成了测试计划规定的测试对象的测试。针对测试计划规定的测试策略，在测试执行中都有体现，在测试执行过程中，依据测试计划和测试用例，对系统进行了完整的测试

测试用例

功能性

系统实现的主要功能，包括查询，添加，修改，删除。

系统实现的次要功能，包括为用户分配酒店，为用户分配权限，渠道酒店绑定，渠道RATE绑定，权限控制菜单按钮。

需求规定的输入输出字段，以及需求规定的输入限制

易用性

  操作按钮提示信息正确性，一致性，可理解性

  限制条件提示信息正确性，一致性，可理解性

必填项标识

输入方式可理解性

中文界面下数据语言与界面语言的一致性

 

 

测试环境

软硬件环境

硬件环境	应用服务器	数据库服务器	客户端
硬件配置	CPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01 Memory： 1048256k HD：ST380817AS 80G SATA	CPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01 Memory： 1048256k HD：ST380817AS 80G SATA	CPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01 Memory： 1048256k HD：ST380817AS 80G SATA
软件配置	OS：CentOS 4.2 JDK 1.5.0_06 Apache 2.2.0 Tomcat 5.5.15	OS：CentOS 4.2 MySQL 5.0.17 Linux	Window 2000 Professional （SP2）IE6.0.2900.2180.xpsp_sp2
网络环境	10M LAN	10M LAN	10M LAN

 

网络拓扑

 

测试结果

Bug趋势图

    此次黑盒测试总共发布10个版本，V1.0.1-V1.0.5为计划内迭代开发版本（针对项目计划的基线标识），V1.1.1-V1.2.2为进行的回归测试版本，所有版本一共发现bug  1306个。bug版本趋势图如下图所示：

 

    由Bug的版本分布图可以看出，V1.0.1-V1.0.5版本质量非常不稳定，bug数量最高达到189个，V1.0.1作为第一个版本bug数量为58个。在版本V1.0.3验证了前面发现的所有bug的基础上遗留bug数量在123个质量表现也不够稳定，在V1.1.1新增了批量制证、数据恢复、数据备份、数据清除等功能所以bug数目骤增为232个。随着版本的迭代在版本V1.2.2  bug数量逐渐将为0。

Bug优先级分布 

 

    测试发现的bug主要集中在未完善功能级别major，属于一般性的功能缺陷，但是测试的时候，出现了163个涉及到程序崩溃、程序启动不了、不能完成正常制证、不能完成正常印刷等严重级别的bug，出现严重级别的bug主要表现在以下几个方面：

ü 系统的主要功能没有实现

ü 本地数据库数据量比较大的时候出现程序崩溃死机

ü 系统主要功能逻辑混乱导致意外bug

ü 后台进程在程序关闭后没有相应停止导致程序不能启动

ü WebAPI接口调用错误导致核心功能不可实现

问题类型分布

 

 

    系统的问题类型主要分布于测试过程和维护过程发现影响系统运行的缺陷bug和对现有系统功能的改进improvement。Bug占所有问题类型的百分比为：97%，improvement占所有问题类型的百分比为：3%。图上结果说明系统在需求采集、程序设计工作过程中考虑十分全面极少存在功能设计遗漏问题。

Bug模块分布图

 

 

 由上图可以看出，bug主要分布模块是CerDesk印刷端（405个）和CerDesk制证端（534个）两个工作台，占到了全部bug的2/3以上。而CerWeb服务器端（260个）的bug分布相对来说比较少占总体百分比为7%。CerDesk运维端（107个）的bug量最少主要原因是功能比较简单。

 

最近提交缺陷图

 

 

 

由上图可以看出，在统计的十个周bug提交和解决状况比较理想，当前提交的bug都能够在很快的时间得到修复，并且随着版本的稳定解决bug数量为全部解决新增bug数量逐渐降为0，整个过程属于正常的软件版本迭代过程。

 

Bug状态分布

 

由bug状态图可以看出，打开的bug有0个，重新打开的bug有0个。已解决bug有2个，主要是版本V1.2.2中提交的界面易用性bug，而其他的1304个都是已验证修复并关闭的bug。系统整体的遗留bug数量达到测试结束标准。

测试结论

功能性

系统正确实现了通过数据字典管理基础数据的功能，实现了数据内容的多语言功能，实现了中英文界面。实现了基础数据管理，酒店集团管理，酒店基础信息管理，渠道管理，代理管理，用户管理的查询，添加，修改，删除的功能，系统还实现了将权限控制细化到菜单按钮的功能。

系统在实现用户管理下的权限管理功能时，存在重大的缺陷，权限控制不严密，权限设计有遗漏。

易用性

   现有系统实现了如下易用性：

ü 查询，添加，删除，修改操作相关提示信息的一致性，可理解性

ü 输入限制的正确性

ü 输入限制提示信息的正确性，可理解性，一致性

现有系统存在如下易用性缺陷：

ü 界面排版不美观

ü 输入，输出字段的可理解性差

ü 输入缺少解释性说明

ü 中英文对应的正确性

ü 中英文混排

可靠性

现有系统的可靠性控制不够严密，很多控制是通过页面控制实现的，如果页面控制失效，可以向数据库插入数据，引发错误。

现有系统的容错性不高，如果系统出现错误，返回错误类型为找不到页面错误，无法回复到出错前的状态

兼容性

现有系统支持window下的IE浏览器和傲游浏览器，支持linux系统下的IE浏览器和火狐浏览器。

现有系统未进行其他兼容性测试

安全性

现有系统控制了以下安全性问题：

ü 把某一个登录后的页面保存下来，不能单独对其进行操作不进行登录

ü 直接输入某一页面的Url能否打开页面并进行操作不应该允许。

现有系统未控制以下安全性问题：

ü 用户名和密码应对大小写敏感

ü 登陆错误次数限制

分析摘要

覆盖率

此次测试，所有测试用例都是在中文界面下执行，未在英文界面下执行，测试不包括英文界面下的测试，也不包括正对英文翻译的测试。

此次测试，部分页面需求描述无明确的定义，对输入限制无详细定义，无明确的测试依据，在测试过程中，测试是根据输入字段含义，测试人员理解，以及和项目经理，开发人员沟通获得测试依据，无法保证测试依据的正确性和完整性，因此，没有进行完整的，正确的无效数据的测试，测试覆盖率不够，无法保证测试的有效性和正确性

下面为此次测试测试用例覆盖率分析图：

 

遗留缺陷的影响 

1． 缺陷描述：酒店娱乐项添加页面， “距离”字段无单位，建议增加单位

缺陷影响：距离字段无单位说明，无衡量标准，用户易用性不好

推迟原因：需求定义无单位定义，统一在升级版本中解决

2． 缺陷描述：酒店基础信息管理模块，默认语言设置不一致。用中文查询酒店，进入酒店基础信息模块后，如下模块，语言显示为“请选择”

列表页面	添加页面
取消政策	停留政策
	担保政策
	机场
	参照点
	会议室详情
	打包促销
	服务
	Rate

而其他模块语言显示“中文语言”

缺陷影响：相同功能模块默认语言设置不一致，一致性不好

推迟原因：默认语言设置，目前无统一标准，升级版本中统一

3． 缺陷描述：tomcat日志有乱码，日志无项目名称，查看不方便

缺陷影响：其他项目日志都有项目名称，日志无项目名称，查看不方便

推迟原因：目前的日志为了调试方便，显示了很多其它信息，在项目正式发布时会统一处理的。

4． 缺陷描述：取消政策管理要么，取消时间“天/小时”缺少单位补充字段

缺陷影响：该处因为是两个不同的单位时间，需要有另外一个单位补充字段补充所所填写内容的单位

推迟原因：该缺陷单位补充字段本来存在，翻译不够准确，不能理解为补充单位的字段，需要等翻译完毕后再确认。

5． 缺陷描述：数据字典种类修改，默认值设置后，在调用该数据字典种类的数据字典，默认值无显示

缺陷影响：数据字典种类的默认值设置后，不能显示设置的默认值，相当于数据字典种类默认值设置功能未实现

推迟原因：该功能暂时不好实现，需要和和系统的默认语种一起处理。

6． 缺陷描述：担保政策管理页面，“Edposit Due”缺少解释行输入描述信息

缺陷影响：缺少解释性输入描述信息，用户不理解应该输入什么内容

推迟原因：需求没有描述，需要解释性说明文字由项目经理整理后，在升级版本中添加

7． 缺陷描述：多媒体添加，文件上传功能未实现

缺陷影响：文件上传功能未实现

推迟原因：该功能暂时不好完成，在下个版本中完成

8． 缺陷描述：参照点添加权限和修改权限单独控制出现权限异常错误

缺陷影响：用户执行添加，修改时，出现权限异常，无法完成任务

推迟原因：B9版本发现该权限，B10版本未通过验证，目前该模块开发人员调休，无法修改bug，

9． 缺陷描述：酒店渠道绑定关系权限控制出现权限异常错误

缺陷影响：a>权限控制易用性不好，会引起用户误操作;

b>权限控制错误

推迟原因：B9版本发现该权限，B10版本未通过验证。该模块后台无insert权限,只有Update权限，与其他模块不同，需要重新设置权限控制方式。

10．缺陷描述：酒店Rate绑定关系权限控制出现权限异常错误

缺陷影响：a>权限控制易用性不好，会引起用户误操作;

b>权限控制错误

推迟原因：B9版本发现该权限，B10版本未通过验证。该模块后台无insert权限,只有Update权限，与其他模块不同，需要重新设置权限控制方式。

11．缺陷描述：新建业务管理员权限用户，进入打包促销页面出现权限异常错误

缺陷影响：除系统管理员外，其他用户无法进行打包促销操作

推迟原因：B10版本发现该bug，目前该模块开发人员调休，无法修改bug

建议

ü 在项目开始的时候应该制定编码标准，数据库标准，需求变更标准，开发和测试人员都严格按照标准进行，可以在后期减少因为开发，测试不一致而导致的问题，同时也可以降低沟通成本。

ü 发布版本的时候，正确布置测试环境，减少因为测试环境，测试数据库数据的问题而出现的无效bug。

ü 开发人员解决bug的时候，填写bug原因以及解决方式，方便bug的跟踪。

ü 开发人员在开发版本上发现bug，可以通知测试人员，因为开发人员发现的bug很有可能在测试版本上出现，而测试人员和开发人员的思路不同，有可能测试人员没有发现该bug，而且，这样可以保证发现的bug都能够被跟踪。

度量

资源消耗

缺陷密度

 

典型缺陷引入原因分析

测试过程中发现的缺陷主要有以下几个方面：

     1． 需求定义不明确

需求文档中，存在功能定义错误，输入输出字段描述错误，输入输出字段限制定义错误，输入输出限制定义缺失这几种类型的缺陷。使得开发人员根据需求进行设计时，没有考虑相关功能的关联性，以及需求错误的地方，在测试过程中，需求相关的问题表现出来。需求做改正，设计必须跟着做改动，浪费时间和影响开发人员的积极性，降低开发人员对需求的信任，可能会导致开发人员不按照需求进行设计而根据自己的经验来进行设计。

2． 功能性错误

ü 功能没有实现，导致无法进行需求规定的功能的测试。主要是无法进入酒店设施管理，会议室管理页面，酒店安全项管理无法保存信息，地区，房型删除功能缺失。

ü 功能实现错误，实现了需求未定义的功能，执行需求定义的功能时系统出现错误。主要是角色拥有不属于自己的权限，酒店联系人删除页面跳转错误等。

3． 页面设计和需求不一致

页面设计没有根据需求进行，输入，输出字段文字错误，用户无法理解字段含义。页面设计没有完成需求规定的输入限制验证，导致用户可以输入错误的或者无效的数据，这些数据有可能会引起功能性错误。

4． 多语言数据问题

ü 系统中很多输入字段是通过调用数据字典的方式输入，但是现有系统中，很多数据字典的多语言信息没有完成，导致使用多语言的时候，显示空白字段。

ü 系统中很多地方使用多语言，由于多语言编码不统一导致页面设计和数据设计使用语言编码不一致，由此引起的多语言数据无法显示的缺陷。

5． 页面设计易用性缺陷

ü 页面设计不友好，系统中很多页面的输入字段无明确的输入提示，用户无法理解何种输入是正确的，但是用户输入错误后，系统提示出错，增加用户负担。

ü 提示信息错误，不同模块相同结果的提示信息不一致，用户操作后，相应的提示信息不明确，引起用户误解。

ü 提示信息一致性，用户在不同页面执行相同的操作，提示信息不同。

6． 开发人员疏忽引起的缺陷

因为开发人员的疏忽，导致系统需要验证的地方，调用了错误的验证，系统需要进行输入控制的地方没有进行相应的控制。