软件测试主要技能.doc

word完整版)软件测试主要技能
测试技能问题
1. 什么是软件测试?答：软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。软件测试的定义：使用人工和自动化手段来进行或测试某个系统的过程；其目的是在于检验它是否满足规定的需求或弄清预期结果和实际结果之间的差距；
2.软件测试的目的？答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种 错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺 陷和错误造成的隐患带来的商业风险.
3.什么是缺陷?不符合需求规格说明书的，实际结果与预期结果不一致的
4.测试结束的标准是什么?-——用例全部测试--—覆盖率达到标准-——缺陷率达到标准-——其他指标 达到质量标准
5。如何进行回归测试?一般是系统发现BUG，开发人员修改后，和BUG直接相关以及可能 相关的功能进行的测试。回归测试是指修改了旧代码后，重新进行测试以确认修改没有 引入新的错误或导致其他代码产生错误.
6.测试用例通常包括哪些内容？测试用例的定义：是为了某个特定目标而编制的一组测试输 入执行条件以及预期结果以便测试某个程序路径或核实满足某个特定需求；
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步 骤、预期结果。测试用例方法：有效等价类、边界值分析、因果图、错误猜测法
等价类分等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的 错误都是等效的，分为为有效等价类和无效等价类，例如:用户登录模块里面的用户名, 用户名的长度为15个字符由数字和汉字组成,当输入的是15个汉字和数字就属于有效 等价类，输入的不是15个汉字和数字，是特殊字符就属于无效等价类
边界值分析测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发 生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误。 使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边 界，就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为 测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
因果图方法最终生成的就是判定表.他是对原因和结果之间的组合， 它适合于检查程序输入 条件的各种组合情况.
错误推测法基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测 试用例的方法.错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生 错误的特殊情况，根据他们选择测试用例。 例如， 在单元测试时曾列出的许多在模块中 常见的错误. 以前产品测试中曾经发现的错误等， 这些就是经验的总结. 还有, 输入 数据和输出数据为 0 的情况.输入表格为空格或输入表格只有一行。 这些都是容易发 生错误的情况. 可选择这些情况下的例子作为测试用例.
6. 您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒测试用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口.不可能做到 完全测试,以最少的用例在合理的时间内发现最多的问题
7。测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、 测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容.借助软件测 试计划，参与测试的项目成员,尤其是测试管理人员，可以明确测试任务和测试方法， 保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上 规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的 具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）
8。 您认为做好测试计划工作的关键是什么？
—---明确测试的目标，增强测试计划的实用性；--—坚持“5W”规则，明确内容与过程：“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W"规则创建软件测试计划，可以帮助测试团队理解测试的目的(Why）,明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How）,给出测试文档和软件的存放位置（Where）；—--采用评审和更新机制，保证测试计划满足实际需求；分别创建测试计划与测试详细规格、测试用例
9。请以web网站测试为例,详细的描述一次测试用例设计的完整的过程。
首先：得到相关文档(需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
第二步:设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小,所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录,如果表中某一数据记录中新加进来的（还没有被处理的,有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤,网站才算完成了它的任务。有3个步骤呢，就可以分别对这3个步骤进行测试用例的设计，尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示；第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了,只有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同,它需要的测试环境比较麻烦,需要web服务器(Apache，tomcat），不过这次需求呢，网站部分只用到了tomcat,所以只要有tomcat即可;第四步：执行测试
10。 性能测试工具load runner———性能测试工具：Load runner ：（集合点、事务）就是通过代理的方式截取客户端和服务期间交互的数据流。性能测试的事务是自定义的，切事务关注页面的一个响应时间定以瓶颈。吞吐量和吞吐率与网络有关。
优点：广泛支持业界的标准协议；支持多种平台开发的脚本；创建真实的系统的负载； 强大的实时监控与数据采集功能；精确分析结果，定位问题所在。
缺点：不知道协议就无从下手；防火墙等会误认其为病毒，在运行是将其杀死。
制定负载测试计划：（分析应用程序,确定测试目标，计划怎样执行Load Runner）—--开发测试脚本(录制基本的用户脚本,完善测试脚本）—--创建运行场景（选择场景类型为Manual Scenario，选择场景类型,理解各种类型,场景的类型转化）运行测试———监视场景(MEMORY 相关，PROCESSOR相关，网络吞量以及带宽,磁盘相关,WEB应用程序，IIS5。0,SQL SERVER，NETWORK DELAY等)—--分析测试结果
（分析实时监视图表，分析事务响应时间，分解页面确定WEBSERVER的问题，其他有用的功能）
11.利用因果图导出测试用例需要经过的一般步骤--—分析程序规格说明的描述中，哪些是原因,哪些是结果;分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的因果图;在因果图上使用若干个特殊的符号标明特定的约束条件;把因果图转换成判定表;把判定表中每一列表示的情况写成测试用例
12。设计用例的方法、依据有那些？
白盒测试用例设计有如下方法：基本路径测试/等价类划分/边界值分析/覆盖测试/循环测试/数据流测试/程序插桩测试/变异测试.这时候依据就是详细设计说明书及其代码结构吧，恩，这个真不确定；黑盒测试用例设计方法：基于用户需求的测试/功能图分析方法/等价类划分方法/边界值分析方法/错误推测方法/因果图方法/判定表驱动分析方法/正交实验设计方法.依据是用户需求规格说明书,详细设计说明书
13.一个缺陷测试报告的组成--—缺陷的标题，缺陷的基本信息,复现缺陷的操作步骤，缺陷的实际结果描述，期望的正确结果描述，注释文字和截取的缺陷的图像.缺陷的标题；缺陷的基本信息；测试的软件和硬件环境；测试的软件版本；缺陷的类型；缺陷的严重程度；缺陷的处理优先级.复现缺陷的操作步骤———缺陷的实际结果描述；期望的正确结果描述；注释文字和截取的缺陷图像。
14. 简述一下缺陷的生命周期--—软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。简单的软件缺陷生命周期:
-—-发现—-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；
——-打开—-修复：开发人员再现、修复缺陷，然后提交测试人员去验证；
-——修复-—关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。
复杂的软件缺陷生命周期：———新建一个软件缺陷，这个软件缺陷是（open）状态,进行bug审查,不是代码问题，就是设计需要修改;———新建一个软件缺陷,这个软件缺陷是（open）状态，进行bug审查，以后修改的,就可以延期；—-—新建一个软件缺陷,这个软件缺陷是（open）状态，进行bug审查，实际没有这个bug,可以将其关闭；——-新建一个软件缺陷,这个软件缺陷是（open)状态，看是否清楚可重现,如果不能重现，就是缺少信息，需要返回到（open)状态;如果能够重现，就进行修正,修正后关闭，进行回归测试。
15。 测试管理工具 QC：流程 确定需求-——计划测试---执行测试—-—追踪缺陷
基于测试过程的测试管理系统，web 浏览器环境下的管理工具。
QC中的软件缺陷状态new –缺陷的初始状态open –开始修改缺陷 fixed –修改缺陷完毕
Closed –回归测试通过 reopen –回归测试失败 postpone –推迟修改 rejected –拒绝缺陷
16. 自动化测试QTP：脚本语言基于vbs且只能用在重复性较强的地方和回归测试两方面。
QTP测试七个阶段：录制测试脚本前期准备—录制测试脚本—加强测试脚本—对测 试脚本除错—执行测试脚本-分析测试结果-回报问题
QTP测试流程框架设计:录制回放-数据驱动--基于软件系统-—关键字驱动
QTP测试流程:选择协议——导入对象库—录制脚本-优化脚本-执行脚本—检查脚本— 回报问题
检查点（7个)：——标准检查点：检查对象的属性
——图片检查点：检查图片的属性-—表格检查点：检查表格的内容
——网页检查点：检查网页的属性-—文字/文字区域检查点：检查网页上或是窗口上出现的文字是否正确——图像检查点:提取网页和窗口的画面检查画面是否正确
——数据库检查点：检查数据库的内容时候正确-—XML检查点:检查XML文件的内容
参数化：-—在测试应用程序时,可能想检查对应用程序使用不同输入数据进行同一操作时，程序是否能正常的工作.在这种情况下,你可以将这个操作重复录制多次，每次填入不同的数据，这种方法虽然能够解决问题，但实现起来太笨拙了。
——参数化测试脚本包括数据输入的参数化和检测点的参数化.;通过将固定值替换为参数，扩展基本测试或组件的范围
17。Linux 命令:重启机器命令-—-reboot或init6关机命令——-shut down 或halt /init0
注销命令--—logout(exit)查看主机名--—hostname设备重启命令---service network start
设置主机名———vi /etc/sysconfig/network 进入编辑文件后在HOSTNAME=设置的主机名（wxm）
设置ip地址——-ifconfig eth0 192.168.1。3 netmask 255。255。255。0 查看ip地址———ifconfig
查看网卡情况-——ifconfig eth0 禁用网卡-—-ifconfig eth0 down 启用网卡———ifconfig eth0 up
设置辅助ip地址———ifconfig eth0：0 192。168.1.110 netmask 255。255。255.0更改网卡MAC地址---ifdown eth0 —--ifconfig eth0 hw ether 00:37:29：38：7E:E3（设置临时生效，重启失败）
添加默认网关—-route add default gw 192.168.1。1 删除-—— route delete default gw 192.168.1。1
新建文件——-touch new。txt 重启防火墙—-—ip tables restart 查看网管及路由情况--—route
切换账户—-—su root用户切换--Ctrl+Alt+F1～Ctrl+Alt+F6返回原来的图形桌面环境—— —Ctrl+Alt+F7
拷贝文件———cp index.htm index。html cp ＊.c /home/wxm 删除文件——-rm filename切换目录—-—cd
移动文件-—-mv /home/wxm/a。c/home/wxm/b.c 创建目录—--mkdir foo —-—mkdir –p wxm/syb
删除目录-—-rmdir /directory/ 查看当前目录—-—pwd查找文件---find /-name wxm。txt
显示文件内容-——cat [-n] www.txt 生成新文件并添加内容cat >new.txt关闭文件---Ctrl+D
合并原文件内容并生成新文件--—cat ＊。txt〈wxm2。txt 从文件中查找信息——-grep
把一个文件内容追加到另一文件的后面———cat new.txt <〈wxm2.txt存盘退出-—-:q /:q！/：wq
18. 黑盒和白盒测试：区别是是否需要查看源代码
白盒测试方法：静态分析和动态分析技术(逻辑覆盖率）
静态分析:手工操作（检视、走读）自动（静态验证、语法分析器、符号分析器）
动态分析：测试数据生成（随机测试、结构化测试、功能测试、函数测试。..）
覆盖率（逻辑、判定、条件、条件组合.。。覆盖率)
黑盒测试方法：(需求覆盖率）功能测试、容量测试、负载测试、可恢复性测试；
测试的流程：完整的需求分析——UT-—IT——联调——系统预测试-—ST；
计划——设计—-实现——执行；回归测试策略：完全重复性测试、选择重复性测试
选择重复性测试（覆盖修改法、周边影响法、指标达成法）
19。软件生命周期——-需求分析；概要设计;详细设计；编码阶段；测试阶段;运行维护
测试流程：计划；设计；执行；执行结果；追踪缺陷；报告；用户体检
20.单元测试方案与测试计划的区别：测试计划属于组织管理层面的文档，从组织管理的角度对测试活动进行规划；测试方案属于技术层面的文档，从技术的角度对测试活动进行规划。
—--测试计划对测试全过程的组织、资源、原则等进行规定和约束，并制定测试过程各个阶段的任务分配以及时间进度安排并提出对各项任务的评估，风险分析和管理需求；测试方案描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试测试方案用例的测试方法、测试代码的设计方案。--—测试方案需要在测试计划的指导下进行;测试计划提出“做什么”，测试方案明确“如何做".
测试方案包含的内容：人员、资源、进度、测试目标、测试范围、测试完成标准等
单元测试方案测试阶段：-——单元测试计划阶段完成单元测试计划---单元测试设计阶段单元测试方案-——单元测试实现阶段完成单元测试用例和脚本，单元测试规程—--单元测试执行阶段执行单元测试用例发现问题,提交缺陷报告并进行回归测试提交单元测试日报和单元测试报告。
单元测试用例设计原则（方法是覆盖率）：
——为系统运行设计用例：规范导出法、等价类划分
——为正向测试设计用例：规范导出法、等价类划分、状态转换测试
——为逆向测试设计用例：错误猜测法、边界值分析、状态转换测试
——为满足特殊需求设计用例：规范导出法
-—为代码覆盖设计用例：分支测试、条件测试、数据定义使用测试、状态转换
-—为覆盖率指标完成设计用例：分支测试、条件测试、数据定义使用测试、状态转换