标签：blog http io ar os 使用 java sp for
最近在准备网易测试工程师的实习笔试，边学边记了一些常考的知识点，放在这里以便复习之用。
V模型
瀑布模型
驱动函数（一般为Main函数）
桩函数
黑盒测试：
等价类划分（逐个覆盖）、
边界值分析（有序的三个点：边界值及边界值前后的两个点）、
状态转换测试法（起始状态、输入、输出、结束状态） n-switch覆盖
状态表（找到隐藏的状态转换）
因果图法（逻辑图）
语法测试
白盒测试：
语句测试
分支/判定测试 控制流图
条件测试（每一个布尔操作数的真值价值都被测试用例覆盖至少一次）
数据流测试（定义使用对路径） 变量的定义点、使用点（谓词使用、计 算使用）
基本路径测试
线形代码序列与跳转测试（LCSAJ）
单元测试
集成测试
自顶向下
自底向上
三明治集成法（两端向中间）
大爆炸式集成法
系统测试
功能测试
性能测试
压力测试
健壮性测试
兼容性测试
用户易用性测试
安装测试
用户验收测试
Alpha测试（公司内部体验测试） 不由程序员和测试员完成
Beta测试（特定的用户群）
Gamma测试 实际市场测试
回归测试
冒烟测试（强调功能的覆盖率，而不是正确性）
性能测试之性能指标（对时间的利用和资源的占用）
软件的事务处理效率（软件处理时间+人机交互时间）
IO性能（物理硬盘、网络和其他硬件的IO性能）
数据库性能（减少对数据库操作的次数、减少表之间的依赖）
内存利用率
CPU利用率
性能测试之负载测试（进行不同频率不同时间长度不同负载量的压力测试，了解性能瓶颈） 非功能性测试
测试时间： 产品各项基本功能稳定后
加载策略：
一次性加载
递增加载
峰谷式加载
随机加载
安全性测试
常见的软件安全问题：缓冲区溢出、格式化字符串攻击、整数溢出、SQL注入、命令注入、跨站脚本攻击、函数错误返回值、网络数据截获、SSL协议攻击、脆弱的登录口令、非法文件访问、域名服务解析攻击、系统和应用程序的信息泄露、未认证的密钥交换、密码学随机数破解
主要测试方法：
静态的代码安全测试
动态的渗透测试（模拟黑客的输入，对系统进行攻击性测试）
程序数据扫描（通常是内存测试）
正向测试、反向测试
跨站脚本攻击
SQL注入（输入的数据字符串中夹带SQL指令） 重点掌握
Cookie欺骗
网络钓鱼（网站伪造、链接操控）
兼容性测试
向前兼容处理（较新版本是否可以在较老版本执行）
向后兼容处理（较老版本是否可以在较新版本执行）
数据兼容测试
易用性测试
1、软件测试的目的？
答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险
2、需求文档测试：主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；
设计文档测试：测试设计是否符合全部需求以及设计是否合理。
3、什么是软件测试？
答：软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程
4、白盒测试有哪几种方法？
答：白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。
5. 软件的缺陷等级应如何划分？
1．致命错误，可能导致本模块以及其他相关模块异常，死机等问题；
2．严重错误，问题局限在本模块，导致模块功能失效或异常退出
3．一般错误，模块功能部分失效；
4．建议问题，由问题提出人对测试对象的改进意见；
附加: 软件缺陷的分类与管理
在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug.
6. 如果能够执行完美的黑盒测试，还需要进行白盒测试吗？(白盒与黑盒的区别)
任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误。
7. 测试退出标准
测试退出标准为完成测试需求中列出的所有功能及测试过程中发现缺陷的回归测试。
1. 单元测试退出标准
1) 单元测试用例设计已经通过评审
2) 核心代码100％ 经过Code Review
3) 单元测试功能覆盖率达到100％
4) 单元测试代码行覆盖率不低于80％
5) 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
6) 不存在A、B类缺陷
7) C、D、E类缺陷允许存在
8) 按照单元测试用例完成了所有规定单元的测试
9) 软件单元功能与设计一致
2. 集成测试退出标准
1) 集成测试用例设计已经通过评审
2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改
3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试
4) 达到了测试计划中关于集成测试所规定的覆盖率的要求
5) 集成工作版本满足设计定义的各项功能、性能要求
6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
7) A、B类BUG不能存在
8) C、D类BUG允许存在,但不能超过单元测试总BUG的50％
9) E类BUG允许存在
3. 系统测试退出标准
1) 系统测试用例设计已经通过评审
2) 按照系统测试计划完成了系统测试
3) 系统测试的功能覆盖率达100％
4) 系统的功能和性能满足产品需求规格说明书的要求
5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
6) 系统测试后不存在A、B、C类缺陷
7) D类缺陷允许存在，不超过总缺陷的5％
8) E类缺陷允许存在，不超过总缺陷的10％
8. 测试计划的目的是什么？
答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
9. 软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义？
大体上来说可分为单元测试,集成测试,系统测试,验收测试,每个阶段又分为以下五个步骤:
测试计划，测试设计，用例设计，执行结果，测试报告
初始测试集中在每个模块上，保证源代码的正确性，，该阶段成为单元测试，主要用白盒测试方法。
接下来是模块集成和集成以便组成完整的软件包。集成测试集中在证实和程序构成问题上。 主要采用黑盒测试方法，辅之以白盒测试方法。
软件集成后，需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅应用黑盒测试方法。
单元测试
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
集成测试
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
系统测试
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
验收测试
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集.
回归测试
回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。
10. 针对缺陷采取怎样的管理措施？
1. 要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
2. 根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
3. 所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交 到缺陷管理工具中，这是缺陷提交的管理。
4. 缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态， 帮助缺 陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。
5. 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。
11.专业词语解释
α测试:
Alpha测试（α测试）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。
β测试
Beta测试（β测试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是 在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。
驱动模块:
驱动模块在大多数场合称为"主程序"，它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此 写驱动
驱动模块主要完成以下事情：
1、接受测试输入；
2、对输入进行判断；
3、将输入传给被测单元，驱动被测单元执行；
4、接受被测单元执行结果，并对结果进行判断；
5、将判断结果作为用例执行结果输出测试报告。
桩模块
比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的错误，定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。
白盒测试
白盒测试(White-box Testing，又称逻辑驱动测试,结构测试),它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。
静态测试
动态通过评审文档、阅读代码等方式测试软件称为静态测试,通过运行程序测试软件称为测试.在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.
12、 回归测试
回归测试的目的是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。
说白了就是，我们测试人员在对程序进行测试时发现bug，然后返还程序员修改，程序员修改后发布新的软件包或新的软件补丁包给我们测试人员，我们就要重新对这个程序测试，已保证程序在修正了以前bug的情况下，正常运行，且不会带来新的错误的这样一个过程。 一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。
13、单元测试、集成测试、系统测试的侧重点是什么？
单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。
系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。
14、设计用例的方法、依据有那些？
白盒测试用例设计有如下方法:基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构
黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。
15、集成测试通常都有那些策略？
1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
2、各个子功能组合起来，能否达到预期要求的父功能；
3、一个模块的功能是否会对另一个模块的功能产生不利的影响；
4、全局数据结构是否有问题；
5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。
16、一个缺陷测试报告的组成
测试软件项目名称,每个要测试软件项目都有唯一的名称，有的公司对项目还有特定的编号。
测试软件版本号,测试周期内，一般需要测试多个软件版本，报告错误时，一定要正确填写产生错误的软件版本号。
测试者名称,便于分清责任，便于管理。
测试日期与时间,便于分析和统计错误报告信息。
测试软件环境,包括操作系统和其他必要的软件程序。
测试硬件环境,包括测试计算机和其他测试设备的配置信息。
错误描述,简明的描述错误的特征，便于查询和快速浏览。
错误标识编号 (ID#) ,每个错误都有一个唯一的标识编号，方便查询。
错误类型,根据错误类型，分配给适当的人员处理错误。
错误级别,错误的严重程度和处理的优先级，优先处理高级别的错误。
错误状态,错误状态表明错误是否已经处理和将怎样处理，根据错误状态，采用适当的处理方法。
错误处理者名称,便于分清责任，便于管理。
重现错误的操作步骤,便于重现错误，修复错误和验证错误。
期望的结果,描述满足设计要求的结果。
实际测试结果,描述实际测试后得到的结果。
必要的附图,便于确认错误的表现形式和错误位置。
测试者的建议等注释,便于错误处理者快速和正确处理错误
17、基于WEB信息管理系统测试时应考虑的因素有哪些？
一、功能测试
1、链接测试
2、表单测试
3、Cookies测试
4、设计语言测试
5、数据库测试
二、性能测试
1、连接速度测试
2、负载测试
3、压力测试
三、可用性测试
1、导航测试
2、图形测试
3、内容测试
4、整体界面测试
四、客户端兼容性测试
1、平台测试
2、浏览器测试
五、安全性测试
18、软件本地化测试比功能测试都有哪些方面需要注意？
软件本地化测试的测试策略：
1.本地化软件要在各种本地化操作系统上安装并测试。
2.源语言软件安装在另一台相同源语言操作系统上，作为对比测试。
3.重点测试因本地化引起的软件的功能和软件界面的错误。
4.测试本地化软件的翻译质量。
5.手工测试和自动测试相结合
19、软件测试项目从什么时候开始？为什么？
软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现的越晚,修复它所花费的成本就越大.
20、需求测试注意事项有哪些？
一个良好的需求应当具有一下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。
另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。
21、简述一下缺陷的生命周期
软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。
简单的软件缺陷生命周期：
1、发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；
2、打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证；
3、修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。
但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。
复杂的软件缺陷生命周期：
1、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，不是代码问题，就是设计需要修改；
2、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，以后修改的，就可以延期；
3、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，实际没有这个bug，可以将其关闭；
4、新建一个软件缺陷，这个软件缺陷是（open）状态，看是否 清楚可重现，如果不能重现，就是缺少信息，需要返回到（open）状态；如果能够重现，就进行修正，修正后关闭，进行回归测试。
软件缺陷生命
22 什么是“软件测试”？
Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item
1就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过程。
2.软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。
3.软件测试是为了发现错误而执行程序的过程。
23 什么是“测试案例”?
测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。
24 如果时间不够，无法进行充分的测试怎么办?
使用风险分析，确定测试的重点。由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：
1) 对于该项目的用途而言，哪种功能最重要?
2) 哪种功能对用户最明显?
3) 哪种功能对安全影响最大?
4) 哪种功能对用户最有用?
5)对客户来说，该应用软件的哪个部分最重要?
6)在开发过程中，该应用软件的哪个部分可以最先测试?
7)哪一部分代码最复杂，容易导致出现错误?
8)哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?
9)哪一部分程序与过去项目中引起问题的部分相类似/有关?
10)哪一部分程序与过去项目中需要大量维护的部分相类似/有关?
11)需求和设计的那些部分不清楚或不容易读?
12)开发人员认为在应用软件中哪些部分是高风险的?
13)哪些问题能造成最差的发行?
14)哪些问题最能引起用户抱怨?
15)哪些测试可以容易地覆盖多种功能?
16)哪些测试在覆盖高风险部分的测试时使用时间最少?
25 如果需求一直在变化怎么办?
1)如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。
2)如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。
3)好的代码注释和好的文档有助于开发人员作出相应的改变。
4)只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。
5)在项目的时间表中应当留出余量，以应付可能出现的变更。
6)尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。
7)通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。
8)要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。
9)在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。
10)在设计自动测试剧本时，试图使其有一些灵活性。
11)在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。
12)对变更进行适当的风险分析，以减少回归测试的要求。
13)在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。
14)少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。
26.软件测试分哪两种方法？分别适合什么情况？
软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标；黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
27.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。
计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组成：
1）测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。
3）测试开发建立可重复使用的自动测试过程。
4）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。
5）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
28.软件测试的类型有那些？分别比较这些不同的测试类型的区别与联系。
BVT （Build Verification Test），主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确Scenario Tests（基于用户实际应用场景的测试），Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况Smoke Test，修复Bug后，针对此次修复是否会对其他模块造成影响而进行的专门测试。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低此外，还有Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等
29.测试用例通常包括那些内容？着重阐述编制测试用例的具体做法不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出……）
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。
用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
30.描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程
1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
2) 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED.
3) 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
4) 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
5) 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）
6) 开发者收到Email信息后，判断是否为自己的修改范围。
7) 若不是，重新reassigned分配给项目组长或应该分配的开发者。
8) 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件）
转：http://www.cnblogs.com/sayary/archive/2013/03/20/2970500.html
标签：blog http io ar os 使用 java sp for
原文地址：http://www.cnblogs.com/Bob-FD/p/4087201.html
