软件测试面试1软件测试基础理论（持续更新中...）

1.软件测试工程师的素质&＃xff1a;

良好的沟通和表达能力

具有怀疑与破坏的精神

扎实的软件测试基础知识

缜密的业务逻辑分析能力

处在用户的角度进行换位思考

足够的耐心、细心、信心、责任心

积极乐观向上的心态和团队协作能力

要有严谨、敢于承担责任、稳重的做事风格

善于自我总结、自我督促和不断学习的能

 

2.软件的分类&＃xff1a;

软件 &＃61; 程序 &＃43; 数据 &＃43; 文档。

　　按照功能划分&＃xff1a;

　　　　系统软件&＃xff1a;如操作系统、数据库管理系统&＃xff0c;各种驱动软件等

　　　　应用软件&＃xff1a;如Office、金山词霸、QQ等

　　按照技术结构划分&＃xff1a;

　　　　单机版本&＃xff1a;如Office&＃xff0c;画图工具等

　　　　C/S结构软件&＃xff1a;如QQ、MSN等

　　　　B/S结构软件&＃xff1a;如新浪、搜狐、google等

　　按照用户划分&＃xff1a;

　　　　产品软件&＃xff1a;Office、财务处理软件、金山毒霸等

　　　　项目软件&＃xff1a;如为企业定制的OA系统等

　　按照开发规模划分&＃xff1a;

　　　　类别  参与人数     开发时间

　　　　小型  10人以下  1-4个月

　　　　中型  10-100人  1年以下

　　　　大型  100人以上  1年

3.软件测试的对象&＃xff1a;

① 源程序/目标代码

② 各开发阶段的文档&＃xff08;需求规格说明、概要设计说明、详细设计说明及其它相关文档&＃xff09;

4.软件测试的目的&＃xff1a;
软件测试的目的是尽可能多的发现软件缺陷。检查系统是否满足需求&＃xff0c;站在用户角度思考产品或项目功能实现的正确性。

测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征。可以帮助项目管理者发现当前所采用的软件过程的缺陷&＃xff0c;以便改进。同时&＃xff0c;通过分析也能帮助我们设计出有针对性的检测方法&＃xff0c;改善测试的有效性。

5.软件测试的原则

0&＃xff09;所有测试的都应以软件设计需求规格说明书为标准进行。

1&＃xff09;应当把“尽早地不断地进行软件测试“作为软件开发者的座右铭。

2&＃xff09;程序员应避免检查自己的程序。

3&＃xff09;充分注意测试中的群集现象。

4&＃xff09;严格执行测试计划&＃xff0c;排除测试的随意性。

8&＃xff09;妥善保存测试计划、测试用例、出错统计和最终分析报告&＃xff0c;为维护提供方便。

5&＃xff09;完全测试是不可能的

6.软件测试分类

 

单元测试&＃xff1a;

单元测试又称模块测试&＃xff0c;针对软件设计中的最小单位——程序模块&＃xff0c;进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

单元定义:

C中指一个函数&＃xff0c;Java中指一个类&＃xff0c;在图形化的软件中&＃xff0c;单元一般指1个窗口&＃xff0c;1个菜单。

如何进行单元测试&＃xff1a;

单元测试主要用白盒测试&＃xff0c;先静态地检查代码是否符合规范&＃xff0c;然后动态运行代码&＃xff0c;检查其实际运行结果&＃xff0c;检查程序的运行结果是否正确是一个最基本的要求&＃xff0c;还要关注容错处理&＃xff0c;程序的边界值处理等。

集成测试&＃xff1a;

集成测试又叫组装测试&＃xff0c;通常在单元测试的基础上&＃xff0c;将所有程序模块进行

有序的、递增的测试。重点测试不同模块的接口部分。

系统测试&＃xff1a;

指将整个软件系统看为一个整体进行测试&＃xff0c;包括对功能、性能、以及软件所运行的软硬件环境进行测试。

验收测试&＃xff1a;

验收测试指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审&＃xff0c;决定是否接收或拒收系统。在系统测试的后期&＃xff0c;以用户测试为主或有测试人员等质量保证人员共同参与的测试。

α测试&＃xff1a;指的是指的是由用户&＃xff0c;测试人员、开发人员等共同参与的内部测试。

β测试&＃xff1a;指的是内测后的公测&＃xff0c;即完全交给最终用户测试

验收测试的重要性&＃xff1a;验收签字,收钱。

静态测试&＃xff1a;

指不实际运行被测软件&＃xff0c;而只是静态地检查程序代码、界面和文档中可能存在的错误的过程。

动态测试&＃xff1a;

指实际运行被测程序&＃xff0c;输入相应的测试数据&＃xff0c;检查实际输出结果与预期结果是否相符。&＃xff08;动态测试方法为结构和正确性测试&＃xff1b;动态测试工具Robot、QTP等&＃xff09;

黑盒测试&＃xff1a;

指的是把被测的软件看做一个黑盒子&＃xff0c;我们不关心盒子里面的结构是什么样子的&＃xff0c;只关心软件的输入数据和输出

白盒测试&＃xff1a;

指的是把盒子打来&＃xff0c;去研究里面的源代码和程序结构。

软件公司中&＃xff0c;往往采用黑盒测试&白盒测试相结合的方式。

&＃xff08;静态黑盒测试&＃xff1a;看文档&＃xff0c;看页面等

静态白盒测试&＃xff1a;看源代码等

动态黑盒测试&＃xff1a;使用软件等

动态白盒测试&＃xff1a;运行源代码等&＃xff09;

灰盒测试&＃xff1a;

是介于白盒测试与黑盒测试之间的一种测试&＃xff0c;灰盒测试多用于集成测试阶段&＃xff0c;不仅关注输出、输入的正确性&＃xff0c;同时也关注程序内部的情况。

功能测试&＃xff1a;

是黑盒测试的一方面&＃xff0c;它检查实际软件的功能是否符合用户的需求。

逻辑功能测试(functiontesting)

界面测试(UItesting)

易用性测试(usability testing)

安装测试(installationtesting)

兼容性测试(compatibilitytesting)

性能测试&＃xff1a;

是软件测试的高端领域&＃xff0c;通常我们所说的高级软件测试工程师一般就是指性能测试或是白盒测试工程师。

时间性能&＃xff08;事务响应时间等&＃xff09;

空间性能&＃xff08;系统资源消耗&＃xff09;

一般性能测试

可靠性测试

负载测试

压力测试

回归测试&＃xff1a;

指对软件的新版本测试时&＃xff0c;重复执行上一个版本测试时的用例。

冒烟测试&＃xff1a;

是指在对一个新版本进行系统大规模的测试之前&＃xff0c;先验证一下软件的基本功能是否实现&＃xff0c;是否具备可测试性。

随机测试&＃xff1a;

是指测试中所有的输入数据都是随机生成的&＃xff0c;其目的是模拟用户的真实操作&＃xff0c;并发现一些边缘性的错误。

7.软件测试的常用种类&＃xff1a;

黑盒测试&＃xff1a;把测试对象看做一个黑盒子&＃xff0c;测试人员完全不考虑程序内部的逻辑结构和内部特性&＃xff0c;只依据程序的需求规格说明书&＃xff0c;检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。

黑盒测试方法包括&＃xff1a;等价类划分、边界值分析、因果图分析、错误推测法、功能图分析等。

等价类划分&＃xff1a;

为了保证软件质量&＃xff0c;需要做尽量多的测试。但不可能用所有可能的输入数据来测试程序&＃xff0c;即穷尽测试不可能。因此可以选择有代表性的数据来测试程序。

等价类是某个输入域的集合&＃xff0c;在这个集合中的每个输入条件都是等效的。

等价类分为有效等价类和无效等价类。

划分等价类重要的是&＃xff1a;集合的划分&＃xff0c;划分为互不相交的一组子集&＃xff0c;而子集的并集是整个集合。

参考链接&＃xff1a;https://wenku.baidu.com/view/c491516fa45177232f60a2c4.html

边界值分析&＃xff1a;

边界值分析法就是对输入或者输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充。

边界值分析法与等价类划分的区别

1.边界值分析不是从某等价类中随便挑一个作为代表&＃xff0c;而是使这个等价类的每个边界都要作为测试条件。

2.边界值分析不仅考虑输入条件&＃xff0c;还要考虑输出空间产生的测试情况。

注&＃xff1a;

字符的边界值检验&＃xff1a;在计算机软件中&＃xff0c;字符也是很重要的表示元素&＃xff0c;其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

 

字符	ASCII码值	字符	ASCII码值
空 (null)	0	A	65
空格 (space)	32	a	97
斜杠 ( / )	47	Z	90
0	48	z	122
冒号 ( : )	58	单引号 ( ‘ )	96
&＃64;	64

因果图分析

等价类划分方法和边界值分析方法&＃xff0c;未考虑输入条件之间的联系&＃xff0c;相互组合。考虑输入条件之间的相互组合&＃xff0c;可能会产生新的情况。因果图方法最终生成的就是判定表&＃xff0c;适合于检查程序输入条件的各种组合情况。

错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误&＃xff0c;从而有针对性的设计测试用例的方法。

错误猜测法并非是一项有章可循的工程设计方法&＃xff0c;而是很大程度上依赖于测试人员的经验、能力以及态度。从个人测试经验角度来看&＃xff0c;在考虑使用错误猜测法补充测试用例时&＃xff0c;可以从如下维度考虑&＃xff1a;

A.极限值设计&＃xff1a;考虑数值最大、最小、为空、为0等情况。

B.特殊取值设计&＃xff1a;

• 年、月、日情况&＃xff0c;必须考虑平年、闰年&＃xff0c;2月&＃xff0c;每月包含28天、29天、31天等情况。同时考虑跨年、跨月等情况。
• 模糊查询情况&＃xff0c;考虑"."、"%"、"&＃xff1f;"等特殊字符取值情况。原因是这些字符在SQL中有它指定的含义。
• 其他取值&＃xff0c;包括NULL、1024、FALSE&＃xff08;0&＃xff09;、TRUE&＃xff08;1&＃xff09;、特殊字符&＃xff08;&＃xff01;&＃64;#...&＃xff09;等。

C.特殊组网考虑&＃xff1a;测试场景的考虑必须考虑版本使用局点的组网情况&＃xff0c;特别是一些特殊的组网&＃xff0c;比如网元主备、容灾等。曾经出现过某token使用未考虑同步到备机&＃xff0c;导致业务出现故障后切换备机&＃xff0c;业务运行失败的问题。

D.端到端用例考虑&＃xff1a;通常测试用例都是以特性为维度进行设计&＃xff0c;或者测试人员在用例执行时都是分功能进行测试用例设计和执行&＃xff0c;并未进行端到端测试用例设计。而端到端的测试用例更容易发现问题。以充值转账功能为例。端到端的用例场景包括&＃xff1a;用户开户&＃xff08;用户模型&＃xff09;->用户转账&＃xff08;不同用户层级间&＃xff0c;所有的转账接口转账&＃xff09; -> 用户充值&＃xff08;预付费、后付费&＃xff0c;所有的充值接口&＃xff09; -> 交易记录查询&＃xff08;所有的查询接口&＃xff09;。当然&＃xff0c;如果有必要。这里还需要考虑用户的类型、交易渠道等。

E.性能角度考虑&＃xff1a;测试场景补充设计时必须要考虑性能情况&＃xff0c;特别是未针对核心特性进行性能场景验证的情况。最经常出现的性能问题是报表查询&＃xff08;功能测试时未考虑交易记录数&＃xff09;&＃xff0c;包括充值交易记录查询、转账记录查询等涉及大业务量数据的测试。类似的功能包括报表测试或者核心交易逻辑的测试。业务数据量&＃xff08;交易记录数&＃xff09;一定需要与现网数据量保持一致。

F.安全角度考虑&＃xff1a;是否考虑不同用户权限功能使用情况、日志中是否有明文显示用户隐私信息、用户登录是否安全校验机制&＃xff08;如密码连续3次输入错误锁账户、验证码&＃xff09;、是否允许越权、前后台校验是否一致等等。

G.可维护性考虑&＃xff1a;新开发特性出现问题时&＃xff0c;已知日志信息是否可以快速定位问题故障。如果没有&＃xff0c;需要增加日志信息。

H.用户体验&＃xff1a;提示信息描述是否合理、搜索出现单条记录是否默认选中、交互次数是否太多、界面操作是否简洁、新增菜单风格是否与已知菜单保持一致。

I.功能实现与规格描述是否一致&＃xff1a;功能实现是否与规格描述一致。是否存在规格中描述但实际特性缺失或者规格中未描述但存在多于交付特性。无特殊情况&＃xff0c;交付功能需与规格内容保持一致。另外一点&＃xff0c;产品的某些特性需要在不同模块中同时满足。比如新增某充值功能&＃xff0c;需要界面模块和业务模块两种接入方式同时支持。

J.输出域考虑&＃xff1a;用例设计需针对输出域情况进行分类考虑。一个是针对输出情况设计输入条件&＃xff0c;另外一个是针对输出内容的使用途径进行补充用例设计。比如某特性是针对充值功能的话单记录新增一个字段&＃xff0c;也就是话单发生了变化。那么必须要考虑后台对逻辑对话单的处理是否能够成功将新增字段的话单入库到充值历史记录表。

K.隐含功能测试考虑&＃xff1a;比如客户要求历史交易功能查询&＃xff0c;客户通常仅会要求输入条件和查询方式&＃xff0c;并会针对隐含功能如交易记录展示的分页、跳转、单页默认显示行数等内容。但测试设计时必须针对这些隐含功能进行测试。

L.针对不同开发考虑用例设计&＃xff1a;这一条情况比较特殊。版本的缺陷会因人而异&＃xff0c;同样的特性会由于开发能力、开发态度、开发自验证程度的不同而产生不同的bug。特别注意新员工、自验证随意的开发人员&＃xff0c;你会发现有很多"惊喜"。但这些"惊喜"没有在版本发布前发现&＃xff0c;就会成为"惊吓"了

参考链接&＃xff1a;https://zhuanlan.zhihu.com/p/121831069

白盒测试&＃xff1a;是对软件的过程性细节做细致的检查。是把测试对象看做一个打开的盒子&＃xff0c;它允许测试人员利用程序内部的逻辑结构及有关信息&＃xff0c;设计或选择测试用例&＃xff0c;对程序所有逻辑路径进行测试。通过在不同点检查程序状态&＃xff0c;确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

白盒测试方法包括&＃xff1a;语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。

单元测试&＃xff1a;是对软件中的基本组成单位进行的测试&＃xff0c;如一个模块、一个过程等等。它是软件动态测试的最基本的部分&＃xff0c;也是最重要的部分之一&＃xff0c;其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约(详细设计)而言的。因此&＃xff0c;单元测试以被测试单位的规约为基准。

单元测试方法包括&＃xff1a;控制流测试、数据流测试、排错测试、分域测试等。

集成测试&＃xff1a;是在软件系统集成过程中所进行的测试&＃xff0c;其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划&＃xff0c;一边将模块或其他软件单位组合成越来越大的系统&＃xff0c;一边运行该系统&＃xff0c;以分析所组成的系统是否正确&＃xff0c;各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

系统测试&＃xff1a;是对已经集成好的软件系统进行彻底的测试&＃xff0c;以验证软件系统的正确性和性能等满足其规约所指定的要求&＃xff0c;检查软件的行为和输出是否正确并非一项简单的任务&＃xff0c;它被称为测试的“先知者问题”。因此&＃xff0c;系统测试应该按照测试计划进行&＃xff0c;其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多&＃xff0c;主要有功能测试、性能测试、随机测试等。

验收测试&＃xff1a;由客户或最终用户执行&＃xff0c;旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是&＃xff0c;验收测试常常有软件系统的购买者代表在现场&＃xff0c;甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

UAT测试&＃xff1a;

UAT&＃xff0c;(User Acceptance Test),也就是用户验收测试&＃xff0c;或用户可接受测试&＃xff0c;系统开发生命周期方法论的一个阶段&＃xff0c;这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。 它让系统用户决定是否接收系统。 它是一项确定产品是否能够满足合同或用户所规定需求的测试。

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

性能测试&＃xff1a;是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试&＃xff0c;两者可以结合进行。通过负载测试&＃xff0c;确定在各种工作负载下系统的性能&＃xff0c;目标是测试当负载逐渐增加时&＃xff0c;系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点&＃xff0c;来获得系统能提供的最大服务级别的测试。

用户视角的软件性能&＃xff1a;

• 从用户角度来说&＃xff0c;软件性能就是软件对用户操作的响应时间。

系统管理员视角的软件性能&＃xff1a;

• 系统的响应时间&＃xff1b;
• 系统运行时服务器的状态&＃xff0c;如CPU利用情况、内存使用情况等&＃xff1b;
• 系统是否能够实现扩展&＃xff1b;
• 系统支持多少用户访问&＃xff1b;
• 系统性能可能的瓶颈在哪里&＃xff1b;
• 系统是否支持7*24小时的业务访问。

软件性能指标&＃xff1a;

• 并发用户&＃xff1a;一给定时间内&＃xff0c;某个时刻与服务器同时进行会话操作的用户数。
• 响应时间&＃xff1a;客户端发出请求到得到服务器返回结果的整个过程所经历的时间。
• 吞吐量&＃xff1a;单位时间内系统处理的客户请求的数量&＃xff1b;一般来说&＃xff0c;吞吐量用请求数/秒或页面数/秒来衡量&＃xff1b;从业务的角度&＃xff0c;吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量&＃xff1b;从网络的角度来说&＃xff0c;也可以用字节数/天等单位来考察网络流量。
• 资源利用率&＃xff1a;指系统资源的使用程度&＃xff0c;比如服务器的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。

负载测试&＃xff1a;

• 定义
  • 数据在超负荷环境下运行&＃xff0c;测试软件系统是否能够承担。这种超负荷主要指多并发用户。
• 方法
  • 人为生成大数据量&＃xff0c;并利用工具模拟频繁并发访问
• 工具
  • 一般需要使用自动化工具
• 考察指标
  • 响应时间、交易容量、资源使用率等

压力测试&＃xff1a;

• 定义
  • 指系统不断施加越来越大的负载&＃xff08;并发&＃xff0c;循环操作&＃xff0c;多用户&＃xff0c;网络流量&＃xff09;的测试。
• 目标
  • 通过确定一个系统的瓶颈或者不能接收的性能点&＃xff0c;来确定系统能提供的最大服务级别的测试。

恢复测试&＃xff1a;恢复测试主要检查系统的容错能力。当系统出错时&＃xff0c;能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败&＃xff0c;然后验证系统是否能尽快恢复。如果系统恢复是自动的&＃xff08;即恢复由系统自身完成&＃xff09;&＃xff0c;则应该检验以下内容&＃xff1a;重新初始化、检验点设置机构、数据恢复以及重新启动是否正确。

可用性测试&＃xff1a;

可用性测试是面向用户的系统测试。让一群有代表性的用户尝试对产品进行典型操作&＃xff0c;- - 同时观察员和开发人员在一旁观察&＃xff0c;聆听&＃xff0c;做记录。

• 系统中是否存在繁琐的功能以及指令&＃xff1b;
• 安装过程是否复杂&＃xff1b;
• 错误信息提示内容是否详细&＃xff1b;
• GUI接口是否标准&＃xff1b;
• 登录是否方便&＃xff1b;
• 需要用户记住内容的多少&＃xff1b;
• 帮助文本是否详细&＃xff1b;

兼容性测试&＃xff1a;

• 定义
  • 测试软件在一个特定的硬件、软件、操作系统、网络等环境下系统能否正常运行。
• 目的
  • 检验被测软件对其他应用软件或者其他系统的兼容性。

安全性测试&＃xff1a;

• 定义
  • 安全测试检测系统对非法入侵的防范能力。
• 应用程序级别的安全性测试
• 数据库安全性测试
• 系统级别的安全性测试

Alpha测试&＃xff1a;由用户在开发者的场所进行&＃xff0c;并且在开发者对用户的“指导”下进行测试。开发者负责记录发现在错误和使用中遇到的问题。总之&＃xff0c;Alpha测试是在受控的环境中进行的。

Beta测试&＃xff1a;由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同&＃xff0c;开发者通常不在Beta测试的现场&＃xff0c;因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题&＃xff08;真实在或想像的&＃xff09;&＃xff0c;并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后&＃xff0c;开发者对软件产品进行必要的修改&＃xff0c;并准备向全体客户发布最终的软件产品。

冒烟测试&＃xff1a;可以根据其名称理解为该种测试耗时短&＃xff0c;仅用一袋烟功夫足够了&＃xff1b;其实是对软件基本的功能进行测试&＃xff0c;测试的对象是每一个新编译的需要正式测试的软件版本&＃xff0c;目的是确认软件基本的功能正常&＃xff0c;保证软件系统能跑的起来&＃xff0c;可以进行后续的正式测试工作。

回归测试&＃xff1a;是指修改了旧代码后&＃xff0c;重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误&＃xff0c;回归测试的困难在于不好确定哪些内容应当被重新测试。

随机测试&＃xff1a;主要是根据测试者的经验对软件进行功能和性能抽查。它是根据测试说明书执行样例测试的重要补充手段&＃xff0c;是保证测试覆盖完整性的有效方式和过程。

动态测试&＃xff1a;是指通过运行被测程序&＃xff0c;检查运行结果与预期结果的差异&＃xff0c;并分析运行效率和健壮性等性能&＃xff0c;这种方法由三部分组成&＃xff1a;构造测试实例、执行程序、分析程序的输出结果。所谓软件的动态测试&＃xff0c;就是通过运行软件来检验软件的动态行为和运行结果的正确性。目前&＃xff0c;动态测试也是公司的测试工作的主要方式。

静态测试&＃xff1a;是指不运行被测程序本身&＃xff0c;仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析&＃xff0c;找出欠缺和可疑之处&＃xff0c;例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错&＃xff0c;并为测试用例选取提供指导。

UI测试&＃xff1a;指测试用户界面的风格是否满足客户要求&＃xff0c;文字是否正确&＃xff0c;页面美工是否好看&＃xff0c;文字&＃xff0c;图片组合是否完美&＃xff0c;背景是否美观&＃xff0c;操作是否友好等&＃xff1b;用户界面(UI)测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外&＃xff0c;UI测试还可确保UI中的对象按照预期的方式运行&＃xff0c;并符合公司或行业的标准。包括用户友好性&＃xff0c;人性化&＃xff0c;易操作性测试。UI测试比较主观&＃xff0c;与测试人员的喜好有关。

自动化测试&＃xff1a;利用软件测试工具自动实现全部或部分测试&＃xff0c;它是软件测试的一个重要组成部分&＃xff0c;能完成许多手工测试无法实现或难以实现的测试&＃xff1b;正确、合理的实施自动测试&＃xff0c;能够快速、全面的对软件进行测试&＃xff0c;从而提高软件质量&＃xff0c;节省经费&＃xff0c;缩短软件发布周期。

桩测试&＃xff1a;

桩的英文是stub&＃xff1b;是指一个软件模块的框架或特殊目标实现&＃xff0c;主要用于开发和测试一个组件&＃xff0c;该组件调用或依赖这个模块。

桩模块&＃xff1a;集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块&＃xff0c;以代替被测模块的接口&＃xff0c;接受或传递被测模块的数据&＃xff0c;这些专供测试用的“假”模块称为被测模块的桩模块。

测试桩一般是 自顶向下集成时需要使用

驱动测试&＃xff1a;

所谓驱动测试&＃xff08;自底向上集成时使用&＃xff09;&＃xff0c;就是你负责测试模块/方法是中间的&＃xff0c;没有main&＃xff08;&＃xff09;入口&＃xff0c;怎么编译&＃xff0c;怎么启动呢&＃xff1f;就需要写一个带main()的方法来调用你的模块/方法

桩模块的使命除了使得程序能够编译通过之外&＃xff0c;还需要模拟返回被代替的模块的各种可能返回值(什么时候返回什么值需要根据测试用例的情况来决定)。

驱动模块的使命就是根据测试用例的设计去调用被测试模块&＃xff0c;并且判断被测试模块的返回值是否与测试用例的预期结果相符

public class ddd{//Test driverpublic static void main(String[] args) {ddd d &＃61; new ddd();d.Add();}//My modulepublic int Add() { int output&＃61;this.Stub1() &＃43; this.Stub2();System.out.print("My module: return value is "&＃43;output&＃43;"\n");return output; }//Stub1public int Stub1() { int output&＃61;3;System.out.print("Stub 1 : return value is "&＃43;output&＃43;"\n");return output;}//Stub2public int Stub2() {int output&＃61;7;System.out.print("Stub 2 : return value is "&＃43;output&＃43;"\n");return output;}}

测试用例八大设计方法

测试方法分类&＃xff1a;

• 黑盒测试 &＃xff1a;等价类划分 边界值分析 因果图分析 错误测试
• 白盒测试&＃xff1a;语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 多重条件覆盖

等价类划分方法

等价类划分&＃xff1a;指某个输入域的子集合。在该子集合中&＃xff0c;各个输入数据对于揭露程序中的错误都是等效的&＃xff0c;并合理地假定&＃xff1b;测试某等价类的代表值就等于对这一类其它值的测试。因此&＃xff0c;可以把全部输入数据合理划分为若干等价类&＃xff0c;在每一个等价类中取一个数据作为测试的输入条件&＃xff0c;就可以用少量代表性的测试数据&＃xff0c;取得较好的测试结果。

等价类划分可有两种不同的情况&＃xff1a;有效等价类和无效等价类。

边界值分析方法

边界值&＃xff1a;是对等价类划分方法的补充&＃xff0c;测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上&＃xff0c;而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例&＃xff0c;可以查出更多的错误。使用边界值分析方法设计测试用例&＃xff0c;首先应确定边界情况。通常输入和输出等价类的边界&＃xff0c;就是应着重测试的边界情况。应当选取正好等于&＃xff0c;刚刚大于或刚刚小于边界的值作为测试数据&＃xff0c;而不是选取等价类中的典型值或任意值作为测试数据。

错误推测方法

错误推测&＃xff1a;基于经验和直觉推测程序中所有可能存在的各种错误&＃xff0c;从而有针对性的设计测试用例的方法。

错误推测方法的基本思想&＃xff1a;列举出程序中所有可能有的错误和容易发生错误的特殊情况&＃xff0c;根据他们选择测试用例。例如&＃xff1a;在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等&＃xff0c;这些就是经验的总结。还有&＃xff0c;输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

因果图方法

前面介绍的等价类划分方法和边界值分析方法&＃xff0c;都是着重考虑输入条件,但未考虑输入条件之间的联系&＃xff0c;相互组合等。考虑输入条件之间的相互组合&＃xff0c;可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类&＃xff0c;他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合&＃xff0c;相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图&＃xff08;逻辑模型&＃xff09;。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

判定表驱动分析方法

判定表&＃xff1a;是分析和表达多逻辑条件下执行不同操作的情况的工具。

正交表设计分析方法

有时候&＃xff0c;可能因为大量的参数的组合而引起测试用例数量上的激增&＃xff0c;同时&＃xff0c;这些测试用例并没有明显的优先级上的差距&＃xff0c;而测试人员又无法完成这么多数量的测试&＃xff0c;就可以通过正交表来进行缩减一些用例&＃xff0c;从而达到尽量少的用例覆盖尽量大的范围的可能性。

功能图分析方法

功能图&＃xff1a;由状态迁移图和布尔函数组成&＃xff0c;状态迁移图用状态和迁移来描述。一个状态指出数据输入的位置&＃xff08;或时间&＃xff09;&＃xff0c;而迁移则指明状态的改变。同时要依靠判定表或因果图表示的逻辑功能。

场景模拟分析方法

指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。

软件测试基本流程

软件测试的基本流程&＃xff08;文字描述&＃xff09;

1测试需求分析阶段&＃xff1a;阅读需求&＃xff0c;理解需求&＃xff0c;主要就是对业务的学习&＃xff0c;分析需求点&＃xff0c;参与需求评审会议

2制定测试计划阶段&＃xff1a;主要任务就是编写测试计划&＃xff0c;参考软件需求规格说明书&＃xff0c;项目总体计划&＃xff0c;内容包括测试范围&＃xff08;来自需求文档&＃xff09;&＃xff0c;进度安排&＃xff0c;人力物力的分配&＃xff0c;整体测试策略的制定。风险评估与规避措施有一个制定。

3测试设计阶段&＃xff1a;主要是编写测试用例&＃xff0c;会参考需求文档&＃xff08;原型图&＃xff09;&＃xff0c;概要设计&＃xff0c;详细设计等文档&＃xff0c;用例编写完成之后会进行评审。

4测试执行阶段&＃xff1a;搭建环境&＃xff0c;执行冒烟测试&＃xff08;预测试&＃xff09;-然后进入正式测试&＃xff0c;bug管理直到测试结束

5测试评估阶段&＃xff1a;出测试报告&＃xff0c;确认是否可以上线

人工测试技术

从心理学的角度出发思考&＃xff0c;下面两个方面显著地提高了测试的功效和可靠性

首先&＃xff0c;人们普遍认识到错误发现得越早&＃xff0c;改正错误的成本越低&＃xff0c;正确改正错误

的可能性也越大。

其次&＃xff0c;程序员在开始基于计算机的测试时似乎要经历一个心理上的转变。从内部产生的压力似乎会急剧增长&＃xff0c;并产生一个趋势&＃xff0c;要“尽可能快地修正这个缺陷”。由于这些压力的存在&＃xff0e;程序员在改正某个由基于计算机测试发现的错误时所犯的失误&＃xff0c;要比改正早期发现的问题时所犯的失误更多一些。

检查与走查(Inspections And Walkthroughs)

代码检查与走查是两种主要的人工测试方法

代码检查与走查都要求人们组成一个小组来阅读或直观检查特定的程序。无论采用哪种方法&＃xff0c;参加者都需要完成一些准备工作。准备工作的高潮是在参加者会议上进行的所谓“头脑风暴会”。“头脑风暴会”的目标是找出错误来&＃xff0c;但不必找出改 正错误的方法。换句话说&＃xff0c;是测试&＃xff0c;而不是调试

代码检查是以组为单位阅读代码&＃xff0c;它是一系列规程和错误检查技术的集合。对代码检查的大多数讨论都集中在规程、所要填写的表格等。

这个代码检查过程通常将注意力集中在发现错误上&＃xff0c;而不是纠正错误。

软件生命周期

是指从软件的产生直到报废的整个周期&＃xff0c;包括可行性分析与项目计划&＃xff0c;需求分析&＃xff0c;概要设计和详细设计&＃xff0c;编码&＃xff0c;调试&＃xff0c;维护七个阶段。

软件测试生命周期

是指从测试项目计划建立到BUG提交的整个测试过程&＃xff0c;包括软件项目测试计划&＃xff0c;测试需求分析&＃xff0c;测试用例设计&＃xff0c;测试用例执行&＃xff0c;BUG提交五个阶段。

也可以是&＃xff08;测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估&＃xff09;。

软件测试生命周期并行与软件生命周期&＃xff0c;存在于软件生命周期的各个阶段。

软件测试人员的主要职责

编写测试计划

设计测试用例

执行测试&＃xff0c;发现缺陷提交测试报告

验证缺陷是否得到修改

编写测试总结报告

软件测试的原则 &＃xff1a;

十项原则

1 测试用例中一个必需部分是对预期输出或结果进行定义

2 程序员应避免测试自己编写的程序

3 编写软件的组织不应当测试自已编写的软件

4 应当彻底检查每个测试的执行结果

5 测试用例的编写不仅应当根据有效和预料到的输入情况&＃xff0c;而且也应当根据无效和未预料到的输入情况

6 检查程序是否“未做其应该做的”仅是测试的一半&＃xff0c;测试的另一半是检查程是 否“做了其不应该做的”

7 应避免测试用例用后即弃&＃xff0c;除非软件本身就是个一次性的软件

8 计划测试工作时不应默许假定不会发现错误

9 程序某部分存在更多错误的可能性&＃xff0c;与该部分已发现错误的数量成正比

10 软件测试是一项极富创造性&＃xff0c;极具智力的挑战性的工作

三个重要的测试原则&＃xff1a;

• 软件测试是为发现错误而执行程序的过程。

• 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。

• 一个成功的测试用例能够发现某个尚未发现的错误。

优秀的软件测试人员需要具备的素质和技能

良好的沟通和表达能力

具有怀疑与破坏的精神

扎实的软件测试基础知识

缜密的业务逻辑分析能力

处在用户的角度进行换位思考

足够的耐心、细心、信心、责任心

积极乐观向上的心态和团队协作能力

要有严谨、敢于承担责任、稳重的做事风格

善于自我总结、自我督促和不断学习的能力

常用测试工具

1、Apache JMeter是一个Apache项目&＃xff0c;可用作负载测试工具&＃xff0c;用于分析和测量各种服务的性能&＃xff0c;重点关注Web应用程序。

做压力测试的步骤如下:

1. 写脚本 或者录制脚本

2. 使用用户自定义参数

3. 场景设计

4. 使用控制器&＃xff0c;来控制 模拟多少用户。

5. 使用监听器&＃xff0c; 查看测试结果