测试用例设计方法
等价类划分
- 有效等价类
- 无效等价类
- 案例:
比如一个登陆输入框,规定只能输入中文,同时长度为6-10,通过等价类设计测试用例:
测试用例中重要的三步: 输入 操作 预计结果 如果与预期结果不符合就是bug
a、有效等价类: 输入:输入长度为6的中文,输入的为王小明,这就是有效等价类
b、无效等价类:
1: 输入长度为4的中文,输入位小名,点击登录,预计结果长度不符合要求
2: 输入长度为6,但是是英文的,点击登录,预计结果 请输入中文
3: 输入长度为4,而且不是中文的,是数字,1234,点击登录,预计结果请输入中文并且长度为6-10位
4:输入长度为12而且不是中文的,比如qwertyuiopas,点击登录,预计结果请输入中文并且长度为6-10位
边界值
- 应用场景：边界值往往和等价类划分法一起使用,形成一套更为完善的测试方案,找到有效数据和无效数据的分界点。
- 注解：边界值一般和有效等价类划分法配合使用
- 案例：比如一个登陆输入框,规定只能输入中文,同时长度为6-10，上面输入框的边界的:如果固定大于等于6,并且小于等于10，那左边界就是 5和 6，右边界是:10 和 11
测试用例:
1:输入的为王小明,这就是有效等价类和边界值的结合使用
2:输入小名,这就是边界值为5,同时有效等价类
3:输入欧阳致远家,这就是边界值10,同时等价类有效
4:输入欧阳致远啦啦,这就是边界值为11,同时有效等价类
因果图及判定表法
- 应用场景:在一个界面中有多个控件,如果控件之间有组合关系或者限制关系,不同的控件组合会产生不同的输入结果,为了弄清楚不同的输入组合会产生咋样的输出结果,可以使用因果图及判定表法:
- 案例：判断是儿童还是青年还是成年人:
条件1:年龄 age
条件2:身高height
条件3:体重weight
输入年龄5,体重80公斤,身高170,查无此人
输入体重80,身高170,输入年龄20,成年人
输入年龄5,体重30,身高60,小孩
正交表法
- 应用场景:在一个界面中有多个控件，每个控件有多个取值，测试时考虑不同的控件不同取值之间的多种组合，但组合数量巨大（>20种，20种以下一般考虑判定表因果图），没有必要全部测试，如何从所有的组合中挑选最少、最优的组合进行测试，可以使用正交排列法。
- 正交表的测试思想特点：
1）使用每个控件的每个取值参与组合的次数是基本相等的（均匀的）
2）在所有的组合数据中，选取数据时，应该均匀的选取，而不能从局部选取。
3）如果时间允许，尽可能的多测一些组合 - 正交表:主要针对一个输入框里面可能有多个值,而且数量巨大
年龄 体重 省 市 县
比如:输入年龄 18,体重45,山西 大同 阳高
场景法
- 适用场合：大多数的业务比较复杂的软件系统都适合使用场景法（便于将各个功能点串起来，便于形成完整的业务感觉）是一种基于软件业务的测试方法，把自己当成最终用户，尽可能的模拟用户在使用此软件的操作
- 案例:
场景一:比如买东西:输入袜子,点击查询,出现列表,点击七匹狼,点击进入详情,点击加入购物车,点击去购物车结算,点击收获地址,点击支付,支付成功
场景二:比如买东西:输入袜子,点击查询,出现列表,点击七匹狼,点击进入详情,点击加入购物车,点击去购物车结算,点击收获地址,点击取消支付
随机法
- 随意测试，不考虑任何用例和需求，完全站在一个用户或者的角度对产品进行使用。
适用场景：
1） 所有之前设定的用例已经执行完毕
2）海量的条件组合无法一遍历的时候
错误推断法
- 基于经验和直觉推测程序中所有可能存在的各种错误 , 从而有针对性的设计测试用例的方法
- 在进行灰盒测试的时候经常用到此方法
测试大纲法
- 适用场合：程序包含多个窗口，每个窗口中又有多个功能，这些功能之间又有一定的联系。为了梳理清楚窗口之间以及窗口不同功能之间的联系，使用测试大纲法。
缺陷（bug）等级分类
- 致命：测试过程死机、系统崩溃、数据跌势、功能没有实现
- 严重：导致软件功能不稳定、功能实现错误、流程错误
- 一般：校验错误、罕见故障、错别字，不影响功能，影响体验
- 低级：没影响的小问题
Bug的生命周期
新建，提交，确认，分配，修复，验证，关闭
测试计划编写
编写测试计划：
测试环境准备、第一次功能测试、性能测试、回归测试、测试报告总结
1. 测试目标：
根据xxx需求，提炼测试功能点、制定测试策略、评估测试风险，预计编写测试用例、执行功能测试和回归测试的工作量，进行人员和进度安排。
2. 测试范围：
功能模块：（需要结合实际情况）
3. 测试策略：
对需求中的功能改进进行完整测试，并根据应用场景和并发数考虑兼容性和性能测试方案。 并需要指定出测试工具
3.1 功能测试：见测试用例表
3.2 性能测试
3.3 系统兼容性测试
4. 测试资源
4.1 人员安排
4.2 测试环境
4.3 bug管理
5 测试进度
5.1 测试进度安排：
任务 时间 执行人员 工作量
5.1输出文档：
测试计划、测试报告
6 测试验收标准：
1.完成所有类型测试 ,没有影响到用户业务使用的bug ,bug数量少于一定数量 , 功能业务，性能指标符合需求
2 产品上线标准：产品 checkelist
- 已按照交互文档、需求文档完全的实现需求；
- 符合交互稿的交互设计规范、符合视觉要求，已经通过设计评审；
- 允许遗留可能会对用户正常使用造成一定影响的正常级缺陷，但应在发布前告知项目组，并经风险评估同意发布后方可发布
7. 风险说明
主要包括三个方面：
1.测试范围风险 （测试遗漏，需求变更）、
2.测试进度风险（预估量不准确，测试人员变动，其他业务工作，）、
3.产品质量风险（代码质量，测试人员能力）
软件测试的原则
1.测试软件存在缺陷
证明测试对象是有缺陷的。
2.测试尽早介入
缺陷发现越早，修复成本越小。
3.不可进行穷尽测试
（无意义测试）
4.缺陷集群性（2/8原则）
80%的缺陷发现在20%的模块中。
5.杀虫剂悖论
如果一直使用相同的测试方法或手段，可能无法发现新的bug。
6.测试环境的特殊新
测试活动依赖测试内容，不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容
7.不存在缺陷谬论
软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。
测试策略
功能测试，性能测试，压力测试，容量测试，安全性测试，GUI测试，可用性测试，安装测试，配置测试，异常测试，备份测试，健壮性测试，文档测试，在线帮助测试，网络测试，稳定性测试
正常情况下测试；非正常情况下测试；边界测试；非法，极端测试；
软件产品质量特性是什么
1.功能性：
适应性、准确性、互操作性、依从性、安全性。
2.可使用性：
易理解性、易学习性、易操作性。
3.效率：
时间特性、资源特性。
4.可维护性：
易分析性、易变更性、稳定性、易测试性。
5.可移植性：
适应性、易安装性、遵循性、易替换性。
移动端测试
1.Android手机和IOS手机，系统有什么区别？
1、两者运行机制不同：IOS采用的是沙盒运行机制，安卓采用的是虚拟机运行机制。
2、两者后台制度不同：IOS中任何第三方程序都不能在后台运行；安卓中任何程序都能在后台运行，直到没有内存才会关闭。
3、IOS中用于UI指令权限最高，安卓中数据处理指令权限最高。
2.Android:
1:使用灰盒进行功能测试
2:使用fiddler或者Charles进行抓包测试
3:兼容性测试,Android 从4.0版本的手机测试到9.0版本手机
4:各大品牌的手机都的进行测试,比如:小米小米9 小米8 小米7 小米6 note 红米系列 7红米5，华为: 华为mate20 华为mate10,华为荣耀: 荣耀10,9,8 ，vivo: x21,27,23，oppo: R7,R9,R11，三星手机: note9, 8,7 S9,8。
5:稳定性测试: 使用monkey命令进行稳定性测试
6:专项测试,使用腾讯专项测试工具进行,测试耗电量,流量,CPU占用率
7:性能测试,对app的接口进行性能测试,使用工具jmeter或者loadrunner
8:对app接口进行接口测试,使用postman或者Jmeter都行
9:如果有时间写自动化脚本
3.ios:
1:使用灰盒进行功能测试
2:使用fiddler或者Charles进行抓包测试
3:兼容性测试:ios版本测试从9-12,手机型号从4S测试到xmax
4:性能测试接口和安卓的是一样的所以只需要进行一次就可以了
5:专项测试:使用腾讯专项测试工具进行,测试耗电量,流量,CPU占用率
6:编写自动化脚本
web端测试
1.前端 :
1:web也使用灰＆测试方法
2:兼容性测试:IE浏览器7-12,火狐浏览器 35-最新的,谷歌浏览器,别的浏览器有时间就可以测试
3:对web端页面进行性能测试,使用jmeter或者loadrunner
2.后端
1:测试http接口
2:测试https接口
3:测试tcp接口
4:测试dubbo接口
5:对后台代码进行代码审核,进行白盒测试
在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题
1、检查系统是否有中毒的特征
2、检查软件/硬件的配置是否符合软件的推荐标准
3、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接问题或者访问问题造成的
4、确认当前的系统是否是独立，是否存在负载，无对外提供消耗CPU资源的服务，查看性能监视器，确认应用程序对CPU/内存的访问情况
MySQL外连接、内连接的区别
内连接 ：
连接的数据表相对应的匹配字段完全相等的连接。连接关键字是 inner join
外连接：
分为左外连接与右外连接、全连接。
左连接的结果集包括指定的左表全部数据与匹配的右表数据,右表中没匹配的全为空值.关键字 left join
右连接的结果集包含指定的右表全部数据与匹配的左边数据,左边中没匹配的全为空值.关键字 right join
全连接返回左右数据表的所有行.关键字 full join
测试通过的标准
从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行 72 小时，目前 Bug Tracking System 中，本版本中没有一般严重的 BUG，普通 BUG 的数量在 3 以下，BUG 修复率 90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本 Release。
测试退出标准
单元测试退出标准
- 单元测试用例设计已经通过评审
- 核心代码100％经过Code Review
- 单元测试功能覆盖率达到100％
- 单元测试代码行覆盖率不低于80％
- 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
- 不存在A、B类缺陷
- C、D、E类缺陷允许存在
- 按照单元测试用例完成了所有规定单元的测试
- 软件单元功能与设计一致
集成测试退出标准
- 集成测试用例设计已经通过评审
- 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改
- 按照集成构件计划及增量集成策略完成了整个系统的集成测试
- 达到了测试计划中关于集成测试所规定的覆盖率的要求
- 集成工作版本满足设计定义的各项功能、性能要求
- 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
- A、B类BUG不能存在
- C、D类BUG允许存在,但不能超过单元测试总BUG的50％。
- E类BUG允许存在
系统测试退出标准
- 系统测试用例设计已经通过评审
- 按照系统测试计划完成了系统测试
- 系统测试的功能 明书的要求
- 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
- 系统测试后不存在A、B、C类缺陷
- D类缺陷允许存在，不超过总缺陷的5％
- E类缺陷允许存在，不超过总缺陷的10％
注：这只是一套比较理想化的退出标准，但在实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷解决率不可能是100%。现在的军方标准是达到99%。对于通用软件来说就要根据公司实际情况了。
保证测试的覆盖率
测试需求分析分两步：
1、测试需求的获取 需求的来源：
显式需求：1.原始需求说明书 2.产品规格书 3.软件需求文档 4.有无继承性文档 5.经验库 6.通用的协议规范
隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析
2，需求的分析，产生测试需求文档
将不同的需求来源划分成一个个需求点，针对每一点进行测试分析：界定测试范围，利用各种测试设计的方法产生测试点
在测试方法方面，可做如下注意：
其一，分析出口入口。从入口分析，将可能出现的环境，条件，操作等内容分类组合，然后根据各位测试达人的方法进行整合，逐一验证。从出口分析，将可能出现的结果进行统计，根据结果的不同追根溯源，再找到不同的操作以及条件等内容，统计成文档，逐一验证。
其二，多种测试手法的学习和使用。大家可能更多的关心测试方法，但是具体操作的手法也是需要注意的。毕竟测试方法比较容易找到，各位达人都很熟悉。如果将每个人不同的测试手法总结出来并在自己的测试实施中加以使用，可能会收到意想不到的成果。
二、当测试需求分析完成，并且形成文档后，要进行测试需求评审，保证需求的准确性以及完整性。
三、测试需求完成以后，可以根据测试需求设计测试用例。
要保证测试用例能够全面覆盖测试需求，要包含所有的情况。
测试用例设计上划分为单功能测试用例和测试场景设计，单功能测试覆盖的需求中的功能点，测试场景覆盖需求中的业务逻辑。
在设计测试用例的时候，可以使用多种测试用例设计方法。
●首先进行等价类划分，包括输入条件和输出条件的等价类划分，合理设置有效等价类和无效等价类,这是减少工作量和提高测试效率最有效的方法。
●必须使用边界值分析，经验表明，这种方法设计出的用例能发现很多程序错误。
●可以使用错误推测法追加一些测试用例，这需要依靠您的智慧和经验。
●对照程序逻辑检查已设计出的测试用例的逻辑覆盖度，如果没有达到覆盖标准应当再补充足够的测试用例。
●如果程序的功能说明中含有输入条件的组合情况，一开始就可选因果图和判定表驱动法。
●对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。
●对于业务流清晰的系统，可以利用场景法贯穿整个测试方案过程，在案例中综合使用各种测试方法。
当测试用例设计完成后，要组织测试用例的评审，这样可以吸取别人的意见，减少遗漏，补全测试用例。
四、测试用例编写完成后，就是测试执行
1.测试用例执行100%覆盖。2.在测试执行过程中，要继续对测试用例补充完善，确保提高测试覆盖率。
五、在整个测试过程中，需求都是不可能不变的，所以要及时的更新测试需求、测试用例。
六、要将测试需求、测试用例以及发现的bug关联起来，便于管理和跟踪，同时也便于查看覆盖率。
3816
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
