通用软件测试实践

通用软件测试实践

软件分类

软件缺陷定义

软件测试定义

测试目的

测试与调试区别

测试对象

整个软件开发完毕，是否所有功能实现就是确认测试，所有功能确认开发完毕进行系统测试

系统测试耗时最多，模拟环境与真实环境下进行测试。

验收测试，专门针对特定人群开发需要验收测试

职业素养

软件生命周期

软件工程

瀑布模型

快速原型模型

Axure，固定的客户开发软件产品

增量模型

组件为单位进行开发，降低软件开发风险，后续不断增加新功能

最常用的开发模型

迭代模型

强调开发的深入优化，发布新版本 新增功能体现增量模型，对已有功能优化就是迭代，修复缺陷是

迭代适应需求的变化比较明显，变化比较快的场合，需求不稳定自己的产品

螺旋模型

独有的分险分险功能，更适合大型昂贵的系统开发

 

软件测试模型

需求分析、测试计划、测试设计、都需要进行测试

V模型

测试放在了编码之后

W模型

测试与开发过程独立开，测试作为独立工作内容分开

拿到需求分析，首先验收软件具体的验收点是什么，验收通过符合客户需求，进行测试的设计。

当系统进行分析与系统设计时，要确认系统测试的设计

概要设计，各功能模块的设计，要确认集成测试的设计，哪些模块之间合并与集成，联系

详细设计文档，要确定单元测试的设计，每一个模块做什么的，功能模块的单元测试

有了代码以后，开始进行模块测试，集成测试，所有程序都合并进行系统测试与确认测试，交付用户要进行验收测试。

所有执行都依赖前面确定的思路方法文档。

H、X模型

H模型一般第三方测试外部，完全独立从开发中独立出来，测试活动要尽早准备与执行

X模型

针对小的功能模块，探索性随机测试，传统测试要提前进行规划，对有可能出现问题的地方随机测试，有经验

测试过程理念

测试人员要站在用户角度思考问题与发现问题，邀请用户参与测试也是必要的

测试越多发现问题越多

软件测试分类

确认测试验证功能是否实现，走一遍软件流程

系统测试必须要确认测试之后进行，要在不同环境下

白盒检查内部逻辑正确，又称为结构测试。

黑盒检查功能是否安装需求文档都实现

灰盒测试，判断输入与输出的正确性，判断内部运行状态，接口测试用来检测输入输出及结果，只关注一部分接口代码。

程序规范标准，有没有注释，空格测试静态的，是否真正符合用户需求，实际界面与需求中的说明是否相等，静态测试检查文档。

动态测试，输入数据与输出数据是否符合预期。

功能黑盒测试，功能是否满足要求，是否符合大众使用习惯，考虑全面

性能测试，时间性能与空间性能

回归测试 ，测试用例就是测试的过程，除了测试新的功能还得要用以前的测试对新功能测试，兼容性验证，测试以前的缺陷是否已经修复。

测试流程

第一步明确知道对哪些方向，需求进行测试，会有多少个功能模块。

第二步编写测试计划，要测试哪些内容，场景，对模块与模块之间内在联系与规则该如何去测试。

测试生命周期

软件测试原则

事先制定质量标准，再进行测试，根据标准判断测试结果准确性，是否为缺陷能否通过

 

错误缺陷都会有集中，调用错误会造成错误，深挖还有错误

保存好测试计划、测试用例、测试报告

 

职业发展

测试需求与需求分析

沟通的问题

显示需求文档提及的与隐式需求，常理默认

用户需求能不能实现相应的功能，通过界面实现

需求分析

在什么环境下使用，什么用户会使用，会有什么操作行为

缺陷分布

隐性需求不满足也是缺陷

多注重用户任务，而不是系统都有哪些功能

保证需求没有歧义

需求状态，已确定，待确定

评审是否可行性

需求改变，变更说明书，要二次评审，对其他模块有无影响

Axure使用

跟踪矩阵

判断需求是否具有可测性

开发正向，测试逆向思维，考虑的越全面越好，想法越多越好

价格排序，功能单一不用拆分，测试文本框可以拆分，按照规则与不按照规则进行拆分

正向测试在需求范围内的，反向不再需求范围内的就是反向的，测试要点根据测试标准去定

 

评审

开会

对软件需求规格说明书进行评审

测试需求不深入，找不全也会有问题

概要设计

详细设计

代码规范

评审分类

评审流程

 

评审规则流程

开会流程

评审规则

开会为了发现问题，而不是解决问题

需求评审，代码评审与测试评审，与测试相关的人员

会签应该提前提前阅读被评审作品

评审误区

非实质性不是本质问题

评审记录表

问题来源，对测试需求跟踪矩阵的某一行，记录需求跟踪矩阵编号

提的问题认不认可，一定要和产品作者进行确认，开完会要对所有问题进行确认，确认问题进行标注

需求编号命名都是相同的，功能点名称，功能和软件界面元素和控件来实现

需求是对前面功能的描述，查询功能，查询文本框输入内容，点击查询按钮，把结果，列表等所有相关内容都要体现

需求拆分，正向在需求描述范围内的，反向不在需求范围内

测试要点，输入正确获取验证码按钮才可以点击，要点如果怎么样，会怎么样，判断标准如果满足需求会怎么样，不满足怎样

需求跟踪矩阵，评审记录

验证码获取有前提条件，输入正确手机号才能获取验证码，对应的手机号会受到验证码短信，这是对验证码测试，划分要详细

需求拆分，怎么获取的验证码，获取之后会怎么样，测试点缺失覆盖不全，根据社会经验

获取两次验证码，第一次为准还是第二次为准，验证码获取时间间隔 ，不能一天无限制的获取验证码

测试要点，做了操作要有什么效果与结果都要列举，要有判断条件与判断条件的结果都要明确，必须是肯定语句，固定标准。

不显示出来的东西，没法测试，测试要点没有的不用去测试，检查版本的过程不会给客户提示，界面没有的东西不能测试

不能出现是否，必须用确定话语。

界面组件是按钮不是功能，功能不要与组件名冲突

不能把缺陷的标准写在需求文档中，是bug，需求拆分只用写怎么操作的会有什么结果，两个完全相反的不能同时定义需求

功能点必须要拆分为单一的，功能对应需求，需求要对功能做相应描述要一一对应。

测试要点也要分开

测试要点必须要明确，有什么，没什么怎么样

语言描述，所有人都能理解的了，清晰明确

需求描述不能有歧义

功能说明清除一些，不能用组件界面内容代替

测试计划

第一产品介绍说明，要确定版本，确定目标用户，产品背景

测试引用出处，引用设计原型

详细规定测试用例(文档类型)

严重程度，客观评价，影响范围与程度

测试术语

测试策略与方案

哪个模块怎么测试，通过标准是什么都要说明

软件不但要测试正确的，也要测试不正确非法的，并提示错误信息。

不但强调功能还得要强调易用性，友善人性化

完成标准参考测试需求跟踪矩阵，正确操作有什么结果，错误操作有什么结果

单元测试进入的条件，关联模块开发完毕就可以进入继承测试，就是进入标准

集成测试完成，确认测试所有功能完毕就可以进行系统测试

所有单元测试完毕退出单元测是

理论上功能测试要覆盖所有的功能项

设计错误，有没有合乎场景，整体考虑，考虑功能的优先级与风险

多个不同设备，兼容性测试

测试进度安排

测试计划模板

文档修改记录

测试范围测试几个大阶段

参考文档

测试需求，每个模块做哪些方面的测试，需求是什么

测试需求跟踪矩阵与软件需求中都会有，主要突出每个功能模块要做哪些方面的测试，是功能、性能还是安全的测试

测试策略

安装测试阶段，分为单元、集成、系统

安装不同模块测试类型进行测试，分为数据测试、功能测试、业务周期测试、界面测试

 

测试方法与工具

黑盒测试用例

设计测试用例

测试用例内容

测试项是测试软件的目的，要测试什么

输入1+1，输出预期结果显示结果的位置为2.

反向测试故意输入错误，执行错误操作，提示

测试用例模板

模块名称/二级模块名称，用户名不算一个模板，不要写到最底层的叶节点，测试类型Function

依赖用例，删除必须依赖于添加，之间有业务依赖于联系

测试步骤要详细描述操作步骤与操作流程，详细到打开浏览器，输入超链接，文本框输入什么内容，逻辑正确

测试项/目的 ，要用一句话概括主要的内容，目的描述要精确和细微

预期结果要写到足够准确，根据程序界面把步骤写出来，实际结果与预期结果是否相同，设计阶段只考虑设计

测试过程测试用例要写清楚，打开百度首页url，通过什么方式走到注册页面。

所有到达注册登录界面的步骤都得测试，页面上所有的内容都得测试

一个测试用例最重要的是目的，主要目的勾选协议注册账号，查看协议内容是另外的测试用例，目的确定用最少路径实现目的

根据系统设计要求的流程去做

用例编写注意

特殊有代表的例子，在有效的时间里要找到平衡点，差不多就行，多设计测试用例从不同方向测试，差不多就行找到平衡，看的全面一些

反向从不同角度违反规则，测试用例应该越来越多覆盖面越来越全。

及时更新版本，系统和环境要求

测试用例与测试用例步骤要对等清晰

用例设计方法

黑盒测试输入等于预期

测试数据的选择，等价类划分、边界值分析

测试步骤设计，通过因果图法、判定表法、正交实验法、功能图法、场景法

等价类划分

划分若干个部分，挑选一部分数据进行测试，一个类代表性的等价所有

对数据进行正向反向各种检测

级联菜单，省市县在计算机程序中，符合条件有n个，其他都是无效的

无效等价类从不同角度违反规则，所有等价类合并起来是全部数据整体，数据改变测试目的发生改变

边界值分析法

重要的地方就在边界，在边界安全其他位置更为安全，边界数据非常容易出问题，数据类型边界整形int -2147483648 ~ 2147483647  1字节     8位元组，即8位bit，   可存储-2^8~2^7   (-128 ~ 127)

数组下标越界

等价类考虑 5与18 边界值，小的文本框

刚刚，明确个数多1少1，选择列表第一个与最后一个下拉框，省市，额定电压221

因果图测试用例步骤设计方法

分析输入条件与输出结果的因果关系，组合关系。

想要得到弹出框、提示框必须要怎么执行操作的，通过什么样的操作才能实现当前步骤，多个因素才能有一个结果

程序设计阶段考虑到的，操作产生结果，上一步操作结果是下一步操作的原因

适合局部小功能

互斥至多有一个成立

判断表驱动法

当某个条件产生，其他的条件不起作用，主要选择成立其他影响因素直接被忽略屏蔽

 

正交实验法

面更加广泛，比较注重全面，多步骤多组合的分析

排列整齐，统计新思想方法

内容分析，分析出来对测试结果有影响的因素条件都有哪些，条件因素都有几种取值情况，确保分析的结果每一列不同数字出现次数相等，相同内容出现次数相等，测试每个因素参与实验几率相同的，保证实验公平的（字体颜色、字体大小、字体样式）

 黄色、红色都出现10次，每一个都是公平的，数字对出现一次不能一个数字对出现两次

确定因素，如果涉及好按照说明，否则按照等价类边界值或者每一个因素有多少可选状态，选择合适的正交表

每个因素有3个水平，因素数是3^4 影响因素4每个因素取值情况3

场景法

某一个场景有很多动作是一个复杂流程，一个片段代表一个节点，一个场景包含很多内容

一个业务一般只有一个基本流，从整体考虑问题分支比较多，适合流程分析，把每个流程分支在路径上分析一下，给每一个路径配测试数据能达到相应结果

具体业务逻辑流程，购物车买东西有很多分支，主分支直接结算，其他分支货不够，限卖一件，清空购物车，添加商品数等等其他过程

软件测试人员一定对业务流程最清晰，认识最深刻，开发正向方式，测试各种组合去破坏，发现缺陷越多

软件测试从小规模扩展为大规模，从小到大按照流程去做，用什么浏览器，打开网页，点击按钮，预期结果。第一个输入框，第二个输入框输入，预期结果。

系统，账号登录系统(普通员工、审核员区分)，进入后再进行相应操作，测试必须按照一定流程执行，必须根据软件说明，描述出程序基本流与备选流。

某一个场景某一个小片段，再等价类边界值因果图，整体流程按照场景法，设计各种不同场景。

流程清晰的系统都适用于场景法测试

只考虑文本框等价类分析法、考虑请假流程场景法

状态迁徙图法(功能图)

操作系统四大管理功能、进程管理、存储管理、文件管理、设备管理

优先程序优先级非常高

设计足够多测试用例，对系统状态覆盖，优先状态必须在一定条件下满足，对状态条件组合的覆盖

列出所有可能的输入事件，点击输入内容，找到空闲状态，操作A到达一个状态，后续不能循环操作A

 

不要遗漏任何操作，任何操作都会对软件状态产生影响，产生新的状态

状态一直变迁，有没有新产生的状态，新产生的状态要继续分析，由1，2操作来，不能使用1，2操作了

测试大纲法

从根节点对模块分析，对所有功能点分析，从根节点到不可分割的叶节点为止就是测试路径，覆盖性

探索性测试

必须写测试用例，凭借直觉经验，猴子测试随意

测试方法选择策略

首先等价类划分，只要有文本框肯定要做等价类划分，任何条件下都要使用边界值，等价类划分都要涉及边界值，有效等价于无效等价类中间通过边界值划分。

输入条件组合情况，要选用因果图和判定表法（决策表），因果图就是条件组合和条件之间约束。

参数配置类，正交表法选择较少组合方式达到最佳效果

状态迁徙图通过不同时期条件有效性设计不同测试数据，对软件进行测试

业务流程清晰的系统，使用场景法贯穿整个案例，流程设计测试用例

错误推测法、探索性

对照程序逻辑与测试大纲，测试点树形结构列出来，一条一条测试，检查测试用例覆盖程度，补充足够多测试用例

表达能力

web测试考虑点

功能连接、表单、cookie、数据库数据测试、设计语言测试

性能测试、速度、压力、负载

兼容性测试，从客户端性能只考虑速度，服务端会考虑压力与负载

可用性测试与安全测试

软件缺陷

缺陷类型

缺陷状态

缺陷来源

软件生命周期

软件定向，开始到最后

软件测试生命周期

获取测试需求，准备下一版本测试

缺陷生命周期

缺陷描述

缺陷报告

测试报告

衡量测试覆盖程度，是否所有界面都测试到，界面是否美观，界面的图标、文本框，弹出框，文字，信息是否准备，空间准确性。

 

功能需求，非功能需求

缺陷分析报告

质量评估

测试报告模板