软件测试基础 1--------软件测试介绍和测试用例-CSDN博客

什么是软件测试？

　　广义概念：指软件生存周期中所有的检查、评审和确认工作，其中包含了对分析、设计阶段，以及完成开发后维护阶段的各类文档、代码的审查和确认。

　　狭义概念：识别软件缺陷的过程，即实际结果与预期结果的不一致

软件测试的目标

　　最终目标是确保软件的功能符合用户的需求，把尽可能多的问题在发布或者交互之前发现并改正。

　　a.确保软件完成了它所承诺或公布的功能

　　b.确保软件满足了性能的要求

　　c.确保软件是健壮的和适应用户环境的

　　d.为软件的质量评估提供依据

　　e.为软件质量改进和管理提供帮助

　　软件测试有以下目标：

　　　　发现缺陷

　　　　获取信心和提供信息

　　　　防止缺陷

软件测试的原则

　　a.Good-enough原则。一种权衡投入/产出比的原则

　　　　解析：不充分的测试是不负责任的，而过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于，如何界定什么样的测试是不充分的，什么样的测试是过分的。针对这种情况，测试人员最好制定最低测试通过标准和测试内容，然后具体问题具体分析。

　　b.保证测试的覆盖度，但穷举测试是不可能的

　　c.所有的测试都应追溯到用户需求

　　d.越早测试越好，测试过程与开发过程应是相互结合的

　　e.测试的规模有小而大，从单元测试到系统测试

　　f.为了尽可能的发现错误，应由独立的第三方进行测试

　　g.不能为了便于测试擅自修改程序

　　h.即应该测试软件应该做什么，也应该测试软件不应该做什么

　　f.杀虫剂悖论

　　　　相同的测试再重复多次后就无法再找到缺陷了。要克服“杀虫剂悖论”,测试用例要不断评审修改,不断添加新的和不同的测试,就有可能找到更多缺陷。随着对系统的加深理解,必然会有更多的测试用例产生。另外缺陷本身也是新用例的很好来源。

测试的木桶原理和80-20原则。

1）依据软件产品全面质量管理的概念，产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充的检查手段，是提高产品质量的必要条件，也是提高产品质量最直接、最uaijie的手段，但决不是一种根本手段。反过来说，如果把提高产品质量的砝码全部押在测试上，那将是一个漫长而恐怖的灾难。

2）Bug的80-20原则。一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的4%的Bug可能只有在用户的大范围、长时间的使用之后才会暴露出来。因为测试只能尽可能多的发现缺陷，无法保证能发现所有错误。

3、测试人员永远不要保证什么。在任何时候都不要表露出有了测试人员或者有了像你一样的测试人员，产品绝对没有任何问题了。这是在自己打自己的嘴，测试人员要给自己留个退路，要表露出谦虚的一面，“尽量少在用户使用时发现问题”，“我会竭尽全力做好测试工作”。

4、测试人员编写的文档是代表自己。测试人员的任何文档代表的是你本人，所以文档一定要写的漂亮，所谓漂亮就是要求格式、版面整齐，没有错别字，语言通顺，表达清楚，没有歧义，一般的技术人员都能读懂你的文档。

5、测试人员要学会逆向思维。开发人员一般都是从正面满足需求，比较少去考虑不满足需求的部分，测试人员就要从逆向思维考虑，有哪些是开发人员没有考虑到的、不满足需求的部分。

6、编写缺陷一定要保证重现。在保证重现缺陷的时候，要注意缺陷不要描述太啰嗦，一般在3-个步骤要完成操作。

7、测试一定要依据需求。离开了需求，叫做你根本没有真正测试被测项目。

8、关注对用户不利的缺陷。要更多的考虑用户能否正确、完整的使用被测软件，用户使用这套软件能够给他们的工作带来好处。不要过多考虑用户不在意的问题。

9、适当的引入测试工具提高测试效率。完全的手工测试过程是非常浪费时间和资源的，所以测试人员应该根据公司的实际情况适当的引入测试工具。一般情况首先引入的是测试管理工具，把整个测试过程管理起来，然后考虑其他测试工具。

10、测试人员是服务人员。整个项目组的人都是测试人员服务的对象，针对不同的人，我们应该提供不同的帮助与协助。

软件测试的经验　

1、应当把“尽早和不断的测试”作为开发者的座右铭

测试应该尽早进行，最好在需求阶段就开始介入，不要等到软件产品做完了才开始。

2、程序员应该避免检查自己的程序，软件测试应该由第三方构造。程序员对自己的程序已经产生抗体，所以测试自己的程序无法测试深层次的缺陷。

3、设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断，电源断电等。

4、一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。测试中存在群集现象，错误喜欢发现在相同的模块以及相关的开发人员编写的程序。

5、对测试错误结果一定要有一个确认过程。一般由A测试出来的错误，一定要有一个B来确认。严重的错误可以召开评审会议进行讨论和分析，对测试的结果要进行严格的确认，是否真的存在这个问题，问题的严重程度是否正确等。

6、制定严格的测试计划，并把测试时间安排的尽量宽松。不要希望在极短的时间内完成一个高水平的测试。一定要制定测试计划，但不要为了做测试计划文档而制定测试计划，测试计划一定要有指导性。

7、回归测试的关联性一定要引起充分注意。修改一个错误而引起更多错误出现的现象并不少见。

8、妥善保存一切测试过程文档。测试的重现性往往要靠测试文档来体现。软件测试过程中产生的文档要纳入配置管理库，进行严格的版本控制，不能随意的修改测试文档，需要制定变更测试文档的流程。

软件测试的主要步骤

软件测试的基本流程（重点）

测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议

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

测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。

测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束

测试评估阶段：出测试报告，确认是否可以上线

总结

开发流程：了解用户需求--》进行需求分析--》得知功能组成及设计软件结构--》开发设计计划--》概要设计--》详细设计--》进行软件编码--》单元测试--》代码审查--》打包提交给测试部--》测试部返回bug--》更新修复bug--》再次进入测试部测试-。。。直到bug解决--》版本上线--》面向用户使用

测试流程：了解用户需求--》参考需求规格说明书--》测试计划（人力物力时间进度的安排）--》编写测试用例--》评审用例--》搭建环境--》测试包安排预测（冒烟测试）-正式测试-bug-测试结束出报告--》版本上线--》面向用户

测试的分类

　　一单元测试

定义：又称模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作；可以从程序的内部结构出发设计测试用例，多个模块测试可以平行地独立进行测试
目的：发现模块内部可能存在的各种差错
内容：模块接口测试（数据的流入流出）、局部数据结构测试、路径测试、错误处理测试、边界测试。
步骤：利用设计文档设计测试用例；创建被测模块的桩模块或驱动模块；利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试

　　二集成测试

定义：又称组装测试或联合测试，在单元测试基础上，将所有模块按概要设计和详细设计进行组装
目的：发现模块连接中的接口可能存在的各种差错
内容：
- 穿越模块之间的数据是否会丢失；
- 一个模块组装后是否会对另一模块或其他模块存在影响；
- 各个子功能组装在一起是否会达到预期的父功能；
- 全局数据结构是否有问题；
- 单个模块的错误累积起来是否会放在
组装方法：包括一次性组装方式、增殖式组装方式两种组装方法
完成标志：成功地执行了测试计划中规定的所有测试用例；修正了所发现的错误；测试结果通过专门小组的评审

　　三系统测试

目的：验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试
测试内容：在真实或模拟系统运行环境下，检查完整的程序系统能否和系统（硬件设备、网络、系统软件）正确配置、连接，满足用户需求

　　四验收测试

测试目的：在用户环境中进行测试，以确定系统和产品是否能够满足合同或用户所规定的需求
测试内容：根据任务书或合同、供需双方约定的验收依据文档进行对整个系统的测试与评审，确认是否接收或拒绝系统

　　五静态测试

　　静态测试又称为静态分析技术，不执行被测试软件，对需求分析说明书、软件设计说明书、源程序做结构检测、流图分析、符号执行等找出软件的错误。

　　六动态测试

　　通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序，而达到发现程序错误的过程

　　七自动化测试

　　自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

-----------------------------------------------------------------------------分割线--------------------------------------------------------------------------------------------------------------------------------------

这几种测试出现在软件测试的周期中，既不算具体明确的测试阶段，也不是具体的测试方法。了解即可

　　冒烟测试　

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

　　引入到软件测试中，就是指测试小组在正式测试一个新版本之前，先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有运行通过，则打回开发组重新开发。这样做的好处是可以节省时间和人力投入到不可测的项目中。

　　回归测试　

　　回归测试是指修改了旧代码后，重新进行测试以确认修改后没有引入新的错误或导致其他代码产生错误。

　　回归测试一般是在进行第二轮软件测试时开始的，验证第一轮软件测试中发现的问题是否得到修复。当然，回归也是一个循环的过程，如果回归的问题通不过，则需要开发人员修改后再次进行回归，直到所有问题回归通过为止。

　　随机测试

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

　　随机测试可以发现一些隐蔽的错误，但是也有很多缺点，例如测试不系统、无法统计代码覆盖率和需求覆盖率、发现的问题难以重现等。一般是放在测试的最后执行。随机测试更专业的升级版叫做探索性测试。

测试用例

　　测试用例设计原则

单个用例覆盖最小化原则

　　这条原则是所有这四条原则中的“老大“，也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。

　　测试用例的覆盖边界定义更清晰，则测试结果对产品问题的指向性更强。

　　测试用例间的耦合度最低，则彼此之间的干扰也就越低。

　　上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容。

测试用例替代产品文档功能原则

　　通常我们会在开发的初期（Scrum每个Sprint的头两天）用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息，勾勒将要实现功能的样貌，便于团队进行交流和细化，并在团队内达成对产品功能共识。但随着产品开发深入，团队会对产品的功能有更新的认识，产品功能也会被更具体细化，在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复，在不断倾听和吸收用户的反馈，多个迭代过后，原本被描述为A的功能很可能最终变为了Z。这是时候再去看看曾经的Word文档和OneNote页面，它们仍然记录的是A。之所以会这样，是因为很少有人会去以及能够去不断地去更新那些文档，以准确地反映出功能当前准确的状态。

单次投入成本和多次投入成本原则

　　成本永远是任何项目进行决策时所要考虑的首要因素，项目中的测试也是如此，对成本的考虑也应该客观和全面的体现在测试的设计、执行和维护的整个阶段中。

　　测试中的成本按其时间跨度可以分为：单次投入成本和多次投入成本。例如：编写测试用例可以看作是单次投入成本，因为编写测试用例一般是在测试的计划阶段进行（Scrum每个Sprint的开始阶段）的，虽然后期会有小的改动，但绝大多数是在一开始的设计阶段就基本上成型了；

使测试结果分析和调试最简单化原则

　　这条原则实际上是单次投入成本和多次投入成本原则 – 针对自动化测试用例的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调试更为简单，包括：用例日志、调试辅助信息输出等。

　　测试用例设计方法　

常用方法

等价类划分
边界值分析
错误推测
因果图
判定表驱动分析
正交实验设计
场景设计法
状态转换图

　　测试用例包含哪些关键内容：

测试用例主要包括用例编号、用例描述、前提条件、输入数据、测试步骤和期望结果6项关键内容：

用例编号

　　用例的组织要方便测试人员执行测试用例，应设计一套良好的用例编号体系。

用例描述

　　用例描述应使用最精简的文字，描述出用例的全貌。让测试人员不用看测试步骤，只看这个描述就可以知道这个用例是描述哪个场景、哪个功能点。

前提条件

　　一个测试用例一般是针对一个特点的场景，而需要测试的场景发生时通常会有一些铺垫场景，即测试用例的前提，如软硬件环境配置、权限设置，数据准备。

输入数据

　　一个测试用例可以有一个或多个输入数据，也可以无输入数据。

测试步骤

　　测试步骤是测试用例的主体，一个测试用例由一个或多个步骤组成，每个步骤之间有一定的前后关系。每个步骤必须表述详细，描述清晰，用于规范、严谨而又客观，最基本的要求是能够使其他人理解，并能正确的执行编写者希望的操作。

期望结果

　　期望结果是测试执行对执行结果进行对比的标尺，是测试是否通过的判断依据。测试结果必须保证其正确性。

　　测试用例参考内容

　　浅谈测试用例

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

通俗的讲：就是把我们测试系统的操作步骤用按照一定的格式用文字描述出来。



二、写测试用例有什么好处？
理清思路，避免遗漏
这里是我们认为最重要的一点，假如我们测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。

跟踪测试进展
通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。

历史参考
在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。

重复性
我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。



三、测试用例的方法
好吧，咱知道啥是测试用例了，也是知道为什么要写测试用例了，那到底应该怎么写？无从下手啊。我们在写测试用例之前，先学习几种方法，它是我们写测试用例的指导思想。

等价类划分
等价类是指某个输入域的一个特定的子集合，在该子集合中各个输入数据对于揭露程序中的错误都是等效的，也就是说，如果用这个等价类中的代表值作为测试用例未发现程序错误，那么该类中其他数据（测试用例）也不会发现程序中的错误。

有效等价类： 输入满足程序输入的要求（来自规格说明书），通俗的说就是正确的输入。

无效等价类： 输入不满足程序输入的要求，即异常输入，需要系统对此有一定的容错性。

例如：

一个输入框要求输入1-10000的数字

有效等价类：可以输入1-10000之间的数来验证，如：2、5、99、8495......

无效等价类：可以输入1-10000之外的任意字符验证，如：0、10001、字母、下划线、特殊符号、空格、回车.....

边界值
边界值是对等价类的补充，测试工作经验告诉我们，大量的错误是出在输入输出的边界价上。我们还拿上面的例子，一个输入框要求输入1-10000之间的数。我们要测它有没有超出这个范围，如：0、-1、-2、1000、10001.....等等，来判定是否超出了我们的范围。

因果图
因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。举个例子：原因：A=0，B=0，结果我就可以判定：A=B。确切的说他是一种因果关系思想。它会无形中指导这我们的测试。当然了，我们为了以免遗漏，可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。呵呵。

错误推测法
基于经验和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法。

其它
设计测试用例的方法有很多，我们常用就上面几种，其它的方法还有：状态迁移图、流程分析法、正交验证法等等。



四、测试用例的格式与要素
一个测试用例应该包括：编号，标题，测试场景，测试步骤，预期结果。

当然还可加入一些它选项，如：优先级、测试阶段....

编号：

标题:

测试环境：

测试步骤：

预期结果：

关于测试用例的存放管理：

1、项目管理系统自带的用例管理，一般用例会与项目挂钩，有固定的格式，搜索、修改等功能，使用起来非常方便。如：禅道项目管理、QC、bugfree 等等都带的有用例管理功能。

2、通过world\Excel文档形式管理，这样的好处就是自己定义测试用例的格式。

面来看一个具体的测试用例。我们会有更深刻的认识。

编号：001

标题: 系统登录测试用例

测试环境：
Windows 10/Chrome 58


测试步骤：
1、打开浏览器，输入系统网站，打开登录页面。
2、用户名密码为空，点击登录按钮
3、输入用户名，密码为空，点击登录按钮。
4、用户名为空，输入密码，点击登录按钮。
5、用户名正确，密码错误，点击登录按钮。
....


预期结果：
1、成功打开首页。
2、系统提示：用户名密码不能为空。
3、系统提示：密码不能为空。
4、系统提示：用户名不能为空。
5、系统提示：用户名或密码错误。
....

View Code

　　什么是测试计划

　　根据项目相关文档，需要定义测试范围、测试策略、人员分配、软硬件配置、进度表以及测试过程每个阶段需要达到的目标

查漏补缺的方法

说明书是基础和标准
测试的执行，通常按测试用例来进行，但测试用例的设计编写是依据产品规格说明书、需求规格说明书、界面设计规范等。写测试用例时难免有考虑不到的地方，因此反复阅读说明文档，也许会有一些新的思路和启发。在项目后期，回归测试阶段，容易思维定势、疲惫，这是可以把这些文档拿出来，再看一下功能点是否覆盖，覆盖到的是不是和需求一致，没有偏差。

 

相关变动邮件，讨论记录
变动是一个项目过程中不可少的部分，而这些变动，通常是通过讨论的方式定下来的，因此会有一些文档记录和邮件。反复阅读这些邮件和文档记录，可以更深入的理解项目。

 

不定期阅读别人的缺陷
每个人的思路、考虑的角度和操作习惯各不相同，因此发现的问题就会不一样。多阅读别人的缺陷可以拓宽思路，看多了，也会不自觉把多种思路集中到一起，慢慢得应用到测试实践中了。

 

多和开发人员沟通
功能测试对测试人员来说大多是黑盒测试，只有开发人员最清楚哪个函数调用哪个函数、哪块单元测试不够充分、哪个逻辑结构比较复杂，多和他们沟通，可以知道哪里还需要多关注一下。

 

有选择的重新验证以前的缺陷
特别在回归测试、验收测试阶段，除了验证前面发现的缺陷，还要重视那些与缺陷相关的模块。一个底层参数的变动，可能会引起很多相关功能的问题，继而造成缺陷的遗漏。

 

关注变化
一段代码的改动，需要开发人员和测试人员去识别。开发人员知道改动的地方会被哪些模块调用或者会引起哪些模块的变化，但由于时间紧、任务重、很难做好单元测试，因此开发人员要通知测试人员需要关注的测试点。

 

简单思维方式，以主线为主，减少大遗漏
一个项目的成功不是把缺陷全报出来，而是在有限的代价下达到预期的质量。按计划进行的项目，主要功能的质量在一定程度上决定了产品的好坏。在项目工期紧张时，全部走完所有测试用例是很难的，可以基本功能为主线，做好相关测试用例的执行，保证不会发生大的质量事故。

 

在测试后期，测试人员可能对质量已经很有信心，受思维和经验的局限性，可能仅限于此。若此时，在产品发布之前，调动其他组的员工参与限时测试并给予奖励，必然能有效减少软件缺陷带来的风险，提高产品质量。

View Code

转载于:https://www.cnblogs.com/xiangrikuidebuluo/p/10281281.html