软件测试用例篇(5)

测试是否运行代码去划分？

1)静态测试:

不运行代码，检查代码的风格，格式是否符合公司的标准规范，检查代码的逻辑结构是否满足需求要实现的功能

看代码，不运行代码，通过静态分析代码的语法，编写规范，逻辑，结构，功能的实现，看开发的逻辑和软件测试文档的需求是否一致，是否符合公司的一些标准和规范

静态质量标准:看看代码的功能是否符合用户的需求

代码性能上的表现:响应时间，资源利用率，容量，功能性，可靠性，有效性，可以执行

1.2)兼容性:手机app在不同的品牌上用户体验的效果

1.3)容错率，可靠性:当用户进行了一些错误操作，和一些外来因素的影响，系统内部对于处理这些突发情况的表现；

1.4)维护性:以后我还可以重复使用，有错误还可以很好的进行修改

1.5)可移植性:适用于不同的平台

1.6)检查项:代码风格和规则审核，程序设计和结构的审核，走查，审查和技术复审手册

2)动态测试:运行代码，给程序相应的输入，看看是否得到相应的输出

写测试用例，运行代码程序，对系统进行测试，查看分析系统的输出是否符合预期

2.1)构造测试用例

2.2)执行程序

2.3)分析程序的输出结果

新的静态质量标准:

1)从代码的功能上去检查，看看代码是否符合用户的需求

2)是否满足系统对用户系统的需求，资源的利用率还有容量

3)兼容性:不同手机的品牌上面和不同安卓的版本系统上面

4)易用性:用户体验性

5)可靠性:由于用户的一些误操作，和外界环境的一些影响，就是发生一些不可控错误的时候，咱们的系统是否可以处理这些异常，让我们的用户看起来并没有发生这些错误一样，也相当于容错性

6)安全性

7)维护性:重复利用，有错误出现错误可以进行修改，可测试，不是说吧代码写得很死，以后不方便添加新的功能，没法修改

8)可移植性:在不同的平台上面都可以正常的使用

按照是否进行手工划分

1)手工测试(黑盒测试人员):

设计测试用例，运行程序，运行系统，一步一步手动的执行测试，对系统进行测试，分析结果，是一种比较传统的测试方法，也是现在用的最多的测试方法，是按照测试用例来手工的去测试系统的功能

缺陷:量大，人总是会有疲惫的时候，容易出错，效率比较低，人脑哪有机器转动的快

优点:

1)思路比较灵活变换，配到一些特殊的情况可以进行灵活地处理，例如让机器来写测试用例，一旦写好了，就是不可变的了，但是对于人来说，觉得当时写测试用例的时候写的不够全面，所以我们在修改测试用例增加一些测试点，这样测试用例的设计就是灵活可变的了

2)或者当功能和需求有一点点改变的时候，是可以随时修改测试用例的，测试比较灵活，可以根据不同的功能进行测试用例的修改和完善，所以说无论何时，自动化测试都不可以取代手工测试；

2)自动化测试

定义:把手工测试的测试用例转化成自动化脚本让机器执行，但是不能随着实际的情况来进行改变机器按照人为设定好和预设好的条件来执行，这些预设包括正常的行为和异常的行为，去检查软件系统有没有设定的条件，有没有符合预期；

方方面面:接口自动化，性能自动化，web自动化，app自动化,dijigou,RobertFrameWork上面两个都是框架 unittest

2.1)自动化的意义：解放双手，提高测试效率，节省人力和资源

自动化测试的条件：系统功能稳定之后

2.2)如何判断一个自动化脚本有价值？

主要是看自动化脚本的使用率，使用频率越高越有价值

2.3)什么样的项目可以使用自动化脚本？

1)项目周期要长,不停的迭代，可能一周就结束了，以后也不会迭代开发，等到程序都开发完了，你的自动化脚本还没有写好呢？

2)适用于需求比较稳定的项目，测试完之后可以保存，你的项目功能一直发生变化，就意味着我要去频繁的修改自动化脚本，这是很麻烦的，就违背了做自动化测试的初衷

按照测试实施组织区划分测试:是以人为为依据进行划分

a测试是在b测试之前的

1)a测试:在系统测试完成之后，把公司中的用户或者非测试，非开发人员召集到一起，到项目组开发环境下进行测试；

测试环境:开发现场

开发环境:非开发非测试人员

优点:用户或者不属于测试和开发人员的人发现在开发现场问题之后会及时的反馈给开发人员，及时地进行解决

缺点:用户在开发环境下可能容易会受到开发人员和测试人员的一个思维控制和影响，因为如果此时开发人员和测试人员对你进行指导，可能会受到他们的一个思维的影响，思维定式

测试不出来用户在实际情况下使用的问题和错误，有些功能他就压根测试不出来；

2)b测试:实际使用软件的用户在真实的环境下进行测试，测试环境地域不受限制，测试完成之后统一进行汇总反馈，比如说游戏内测，给APP的活跃用户给一个b测试，给发现问题的用户发送奖励；

优点:测试的结果跟接近用户实际使用情况的反馈，b测试在a测试之后很长一段时间；
a测试和b测试对比:
1)地域不一样,a是在开发环境下,b环境是在用户实际使用环境下;
2)同时时间的集中程度也不一样,a测试时间相对比较集中;
b测试相对来说比较分散;b会给一些活跃的用户来发一些测试,有问题直接提交反馈;
3)a测试优先于b测试
3)由软件的第三方测评机构进行测试多角度测试，有国际化的一个标准，这个时候面向的群体既不是开发人员也不是测试人员，按照软件行业标准规范来对软件进行测试，有时还需要付费；

信息注册的测试用例:

程序的需求是:

姓名：1-20个字符，不可以包含数字，不可以有空格

年龄：18-60之间的整数，不能为空格

注册信息是非必填项

一:姓名:

等价有效类:1-20个非数字非空格字符，大写，小写，特殊字符；

无效等价类:1-20数字，1-20空格，1-20空格数字字符空格混合，1-20数字和空格混合，1-20数字空格混合，1-20空格字符组合，不输入，大于20个字符(无论是非数字，非空格)；

边界值:0个字符，1个非数字非空格字符，两个非数字非空格字符，19个非数字非空格字符，20个非数字非空格字符，21个非数字非空格字符

二)年龄:

年龄：17岁，18岁，19岁，59岁，60岁，61岁

有效等价类：18-60之间的整数

无效等价类：18-60之间的非整数，小于18的整数，小于18的非整数；大于60的数，大于60的非整数，为空，小数；

边界值：17，18，19，59，60，61

三)因果图法

自动饮料的售卖机

1)可以输入1.5毛钱硬币或者2元钱硬币

2)一瓶饮料的价钱1.5

3)如果输入两元钱，出饮料的同时会找回5毛硬币；

4)饮料的品种:可乐，红茶，雪碧，出哪种饮料取决你于你付完钱后按下哪个键

一:找出输入和输出:

输入:1.5元硬币，2元硬币，可乐，雪碧，红茶

输出:5毛硬币，可乐，雪碧，红茶

二:分析输入与输出之间的关系:

1)输入1.5元，按下可乐，输出可乐

2)输入1.5元，按下雪碧，输出雪碧

3)输入1.5元，按下红茶，输出红茶

4)输入2元，按下可乐，输出可乐和0.5元

5)输入2元，按下雪碧，输出雪碧和0.5元

6)输入2元，按下红茶，输出红茶和0.5元

三:根据输入输出的关系画出因果图:

四:根据我们画出的因果图画判定表:

这里面出现了两种特殊情况:

1)输入一个钱数，连续输入两次按钮，只会第一次输入的按钮有效

输入2块输入1.5元输入可乐按下红茶输入雪碧中间结果1 中间结果2 5毛硬币可乐雪碧红茶

1 0 0 0 0 1 0 0 0 0 0

1 0 1 0 0 1 1 1 1 0 0

1 0 0 1 0 1 1 1 0 0 1

1 0 1 0 0 1 1 1 0 1 0

1 0 1 1 0 1 1 1 1 0 0

1 0 1 1 1 1 1 1 1 0 0

0 1 1 0 0 1 1 0 1 0 0

0 1 0 1 0 1 1 0 0 1 0

0 1 0 0 1 1 1 0 0 0 1

1 1

根据判定表写测试用例:

1)输入两元钱，按下可乐，输出可乐并输出5毛钱硬币

2)输入两元钱，按下雪碧，输出雪碧并输出5毛钱硬币

3)输入两元钱，按下红茶，输出红茶并输出5毛钱硬币

4)输入1.5元钱，按下可乐，输出可乐

5)输入1.5元钱，按下红茶，输出红茶

6)输入1.5元钱，按下雪碧，输出雪碧

7)输入2元钱，不按下按钮，不出任何饮料，并且超过一定的时间限制，并给用户提示“请按下饮料按键"

8)输入合理的硬币，多次按下不同的饮料按键，出第一次按下的饮料，并给用户进行提示，投币一次，只能按一个饮料按键

9)我们先输入2元钱，再进行输入1.5元，饮料机就会提示，不能连续输入多次硬币.......

除此之外还有自动饮料售卖机断网(无法计算)，断电(会进行提示)，没零钱找了，饮料机会进行提示:请提示工作人员找零，饮料机损坏(贴显示)，饮料及饮料不足，案件损坏，按键失效

场景测试法:

当我们从网上买书的时候:

登录---->查找书籍----->放入购物车----->结算(生成订单)---->支付

可能出现的错误:

顺利情况:顺利登陆，成功查找到目标书籍，把书籍添加到购物车里面，在购物车里面选中书籍，点击结算，到订单页面支付成功，购书完毕

1)登录:密码错误，用户名错误，验证码错误，手机号登陆的时候有可能错误，用户名不存在

测试用例举例:

输入密码错误，提示输入密码有误，请重新输入

超过三次输入密码错误，账户会锁定

用户名输入错误，提示用户名输入有误，请重新输入

手机号输入错误，无法收到验证码

2)查找书籍:缺货，下架，没有该书集

3)放入购物车:购物车达到上限

4)结算:满减活动(本店铺满减，跨店满减，满减卷是否可以进行叠加)

5)支付:支付方式的切换，当余额不足的时候是否自动的切换其他支付方式，进入订单页地址的选择，支付密码错误，选择让其他方式支付，面部，指纹，免密支付，分期支付

按地域划分测试:本质上来说就是一个软件在不同的本地化测试，在本地化有一个很好的表现

国际化测试和本地化测试

软件国际化:进行软件设计和软件开发的时候，使用一种工程技术，使得软件在转化为不同的国家语言的时候，甚至可以不需要修改源码，适应不同国家的语言以及不同国家的风俗习惯等等，适用于不同国家的人都使用它

1)这些软件可以适用于不同国家的语言，以及适用于不同国家的风俗习惯人民的使用习惯；例如我们国家的字体，宋体..，辛丑年，微软雅黑；

开发一款软件的时候运用了一种工程技术，可以使得软件适用不同国家的语言和当地的风俗习惯而不用修改软件的源码，比如说手机，一款手机初始化的时候，会让你选择你是哪一个区域的，选择文字(选中国就显示汉语，选英国就显示英文)

2)如何进行软件国际化的测试？

1)点击切换了不同的国家之后，本地化之后的软件是否和原来的版本存在很大的差异，外观是否整齐，软件功能是否和原来的一致？

2)是否对所有的界面元素进行了本地化处理:包括对话框，菜单，工具栏，状态栏，提示信息，包括声音的提示还有日志；

3)语言，切换语言，提示信息，提示语音，提示英文还是提示中文(年月日，辛丑年，日历国外没有这回事)，是否符合这个国家人的使用习惯，文字，日期，风俗习惯；

4)一些悲痛的日子(国难日)和传统节日，页面要变成灰色，所以要知道国家的一些重大的日子(8月15日)，在过年的时候，要做一些比较喜庆的页面，在国外的圣诞节，会有一些喜庆的页面符合外国人的需求，比如说当伟大的医生李文亮去世的时候，许多的软件APP会变成黑色

3)在不同的屏幕分辨率下界面是否正常显示，不同国家使用的硬件关键设备，芯片技术是不同的，硬件不一样，不同的功能在系统上面的表现是完全不一样的(即使是同一款APP)，这些APP在不同的屏幕上面，分辨率不同的情况下，是否页面能够正常的展示，以及在正常的展示情况下，功能是否发生了变化；

4)不同的国家的语言长度不同，因为语言的长度很可能会影响页面的排版，是否存在不同的字体大小，字体设置是否恰当

5)日期，数字格式，硬币货币(元角分，相同的价钱折算成不同国家的货币)等是否能够适应不同国家的文化风俗，例如中国是年月日，英国是日月年，不同国家的度量单位是不一样的(KG，G，榜)

6)在不同的国家采用不同的度量单位，软件是否能够自适应和转换；

7)繁体语言切换(1，还是一，还是繁体中文的壹)

8)排序的方式是否考虑了不同语言的特点，例如，按照第一个字的汉语拼音顺序排列，但是英文按照首字母进行排序

9)软件是否可以在Windows上面或者其他操作系统的当前版本上面运行，是否可以在不同类型的硬件上面运行，特别是当地市场上的销售的流行硬件上面，一些APP是必须在一些硬件上运行，如果说在其他的硬件上面，是不可以运行的，如果不能在硬件上面运行，就要修改软件的配置

10)联机帮助和文档是否已经翻译，翻译后的链接是否正常，正文翻译是否正确，恰当，是否有语法错误，让本地使用者可以看懂，被使用者是否可以看懂这些文档

3)软件本地化

一个微信群100以上的人，发了一个100元的红包，100个人抢红包，抢完红包之后，如何进行判断强的钱数和发送的钱数是一致的？

一)发送红包的接口:我们要进行发送红包，前排肯定调用了一个发送红包的接口，里面肯定会有一些参数:

1)输入参数:发的钱数，发的红包肯定是在群里面发的，这时就会有一个群ID，发红包的这个人的 We ChatID，输入参数:发的钱数(比如说发了100元钱)

2)还有一个输出参数，当你发送出去红包的时候肯定是有一个红包ID;

二)接受红包的接口:我们接受红包和发送红包的时候共用一个接口

1)输入参数:红包ID，抢红包的人的WeChatID，还有群ID

标识哪一个人在哪一个群抢了哪一个红包

2)输出参数:强的钱数

三)使用接口测试工具:postman jmeter Charles

需要解决的问题:30个WeChatID需要我们在数据库里面提前设置好

四)解决方案:

1)发送红包的接口只调用一次，得到红包ID；

2)我们调用抢红包的接口30次，我们分别进行传入30个不同的WeChatID，记录每一次抢到的金额，我们把这些金额都加起来和发红包的钱数进行比较；

1)当我们按照开发阶段来进行划分的时候，分成单元测试，集成测试，系统测试，还有验收测试，他们进行测试的依据，其实是软件测试开发模型V模型的每一个阶段，我们要知道他们的测试内容是什么，以及他们属于什么类型的测试，是黑盒还是白盒？

2)系统测试分为冒烟测试(作用,是测试人员是否可以进行测试的原则，主要是对我们的系统的一个核心功能和流程的一个测试)和回归测试(啥时候做回归测试?)

3)按照实施组织去划分，就是让那些人员去测试:a,b,第三方测试，b测试是在a测试之后进行的

4)静态测试:IOS25010

1)黑盒测试设计测试用例的方法有哪些？
边界值、等价类、错误推测法、功能分解法、因果图、判定表、正交试验法、场景法
2)按照开发阶段划分的哪几个阶段用的是黑盒测试？
集成测试，系统测试，验收测试，手工测试，自动化测试

3)单元测试：白盒测试

黑盒测试:

软件测试用例篇(5)相关推荐

软件测试用例篇(1)-------针对非软件产品进行测试
假设我们现在根据门锁来进行测试: 一)从功能测试的角度来说:开门,关门,上锁,不上锁 1)没加锁,门里面,门外面都是可以进行开门的: 2)没加锁,门里面,门外面都是可以进行关门的: 3)门上锁之后,外 ...
软件测试用例篇(4)
测试知识回顾: 我们想要根据需求来写测试用例,首先要保证的需求的合理性和正确性,首先要验证需求,需求合理,理解需求,细化需求,把大需求细化成小需求,根据每一个小需求提炼出功能点根据每一个功能点来发散的 ...
软件测试用例篇(2)
功能测试+界面测试+兼容性测试+安全测试+易用性测试+性能测试针对有需求的案例来设计测试用例:邮箱注册,部分测试用例 https://zay1xofb7z6.feishu.cn/mindnotes/ ...
软件测试用例篇(3)------针对软件产品设计测试用例
(378条消息) 软件测试--测试用例设计&测试分类详解_测试用例分类_偷偷敲代码的青花瓷的博客-CSDN博客 (401条消息) 软件测试|黑盒.白盒.灰盒测试的区别_从被测试系统了解角度进行 ...
阿里测开7年大手子教做软件测试，五分钟学会软件测试用例篇
测试用例定义测试用例的定义:软件测试的核心,为了特定的目的而设计的一组测试输入.执行条件.预期结果的输出文档: 测试用例构成要素:用例编号.用例标题.测试项目.用例级别.预置条件.测试输入.执行 ...
软件测试用例（史上最全软件测试干货）
咚咚咚,桥黑板!注意听讲! 今天来点测试干货,纯纯的干货啊,堪称史上最全. 今天来发一篇软件测试用例设计时需要关注的点,前辈总结的非常详细,基本上素有的测试点都包含在其中了,纯纯的图片. 快下载保存本 ...
三代测序纠错软件汇总篇
三代测序纠错软件汇总篇原创: 李海滨诺禾科服 2017-12-21 在之前推出的一篇微信中,已经介绍过了三代测序下机数据"三代全长转录组测序常见问题说明".那么我们拿到数据后是 ...
软件测试用例设计实用经验之谈
概述软件测试用例设计最重要的前提是掌握业务知识,加上一定的测试用例设计方法,软件测试的工作实际就非常简单了,多测试几个实际项目技能就自然提高了. 我把软件测试用例设计分成4个部分: ·测试类型 ·设 ...
读取 wps_软件前世今生篇之WPS（求伯君1988年先于OFFICE研发出WPS）
软件前世今生篇之WPS 今天给大家普及一下WPS这款办公软件,相信你会问wps有什么可普及的?我们都知道啊,不就是一款办公软件,而且还是抄袭office的,安装还挺简单的,而且还有一大堆广告,不过使用 ...

软件测试用例篇(5)

测试是否运行代码去划分？

1)静态测试:

2)动态测试:运行代码，给程序相应的输入，看看是否得到相应的输出

按照是否进行手工划分

1)手工测试(黑盒测试人员):

2)自动化测试

按照测试实施组织区划分测试:是以人为为依据进行划分

信息注册的测试用例:

姓名：1-20个字符，不可以包含数字，不可以有空格

年龄：18-60之间的整数，不能为空格

一:姓名:

二)年龄:

三)因果图法

场景测试法:

按地域划分测试:本质上来说就是一个软件在不同的本地化测试，在本地化有一个很好的表现

国际化测试和本地化测试

2)如何进行软件国际化的测试？

3)软件本地化

软件测试用例篇(5)相关推荐

最新文章

热门文章

输入2块	输入1.5元	输入可乐	按下红茶	输入雪碧	中间结果1	中间结果2	5毛硬币	可乐	雪碧	红茶
1	0	0	0	0	1	0	0	0	0	0
1	0	1	0	0	1	1	1	1	0	0
1	0	0	1	0	1	1	1	0	0	1
1	0	1	0	0	1	1	1	0	1	0
1	0	1	1	0	1	1	1	1	0	0
1	0	1	1	1	1	1	1	1	0	0
0	1	1	0	0	1	1	0	1	0	0
0	1	0	1	0	1	1	0	0	1	0