2020-08-21 09:05发布
一、微信小程序的测试点
单纯功能测试的层面来说,微信小程序测试、APP测试、web测试在流程和功能测试上是没有区别的,但由于载体的不同,导致有一些不同,主要可以从几个方面体现:
1、系统架构方面
2、性能方面
3、兼容方面
4、测试工具方面
微信小程序测试与app测试非常相似,微信小程序是已微信为载体的,通过微信进入小程序中。
性能方面:
1.微信小程序使用微信开发者工具对小程序进行性能测试
兼容性:
1、手机系统-ios、Android、windows
2、手机机型-华为、iPhone、小米、iPad等市场主流的机型
3、微信版本-微信各个版本(可估计主要的用户群体和使用的微信版进行测试-微信小程序后台可查看使用版本的统计)
测试点:
更新:热更新、覆盖更新(需要注意更新版本时,用户是否需要删除小程序才会有效果)
微信版本类型:开发版、体验版、正式版,在测试过程中,曾经遇到同一套代码在体验版正常,发布 正式版就挂了,经开发分析是微信本身的bug,需要注意这点。
一、小程序开发并非随心所欲,你需要看懂以下规则才能不走弯路:
1、小程序的功能定义与实际提供的服务必须一致;小程序所提供的类目,必须放置在首页,最深也只能放置在二级页面;
2、小程序所提供的服务目前暂时不能涉及游戏、直播等服务(涉黄涉赌就不用多说了)内容也不能涉及测试类内容;比如:算命,抽签,星座运势等;
3、小程序所提供的服务可以允许设置付费可见及隐藏可见(这点对于开发者来说可以发挥地方很多,具体在后面文章做详细论述);
4、小程序不能提供与微信现有功能相似的服务,如含朋友圈、漂流瓶等,也不能提供导航、排行榜、互推的服务;
5、小程序一如既往的不支持诱导分享、诱导关注,虚假欺诈等内容,也不支持广告展示比例超过50%的页面内容;
6、小程序不得诱导、泄露、转让用户的任何数据。所有行为都必须经过用户授权或有明显提示;
二、微信团队对小程序设计也有严格定义,前端工程师们需要看懂以下规则:
1、页面设计需要考虑除微信导航以外其它导航页面的设计,遵循“导航明确,来去自如”,也就是能让客户知道,当前在哪,可以去哪,如何回去等问题。
2、页面设计需要遵循重点突出,并且不能出现与业务无关的业务入口,正反举例:
错误示例
以上页面主题是查询,但查询按钮下面却出现“今日热点|头条新闻”的无关内容
正确示例
以上页面查询按钮下面显示的是新搜索过的关键词,与页面主题匹配
3、页面设计无需考虑微信一级菜单的导航,微信系统内的所有小程序均会自带有微信提供的导航栏
标准导航图
4、微信导航栏自定义颜色规则,开发者如果需要自设导航需要与官方定义的颜色和谐搭配
官方定义导航颜色
5、小程序首页可选择微信提供的原生底部标签分页样式,该样式仅供小程序首页使用。初期的页面内导航设计尽可能利用微信自带导航Tab,添加自有导航可以添加标签分页(Tab)导航,标签数量不得少于2个,最多不得超过5个,为确保点击区域,建议标签数量不超过4项。
小程序标准导航样式
6、小程序已经明确定义了标准的启动页面和页面下拉刷新加载样式,无需开发者设计,启动页面只能上传品牌LOGO且不能更改。
小程序启动页标准样式
下拉加载页标准样式
7、小程序页面的加载反馈和结果反馈应提供载入进度和结果提示,并且每个页面都要有明确的指引操作和退出提示。
加载页必须有加载提示如右边图
结果反馈必须有明确提示如:已发送
8、小程序页面设计需要遵循“减少输入,巧用接口,多用选择”的原则,比较大限度的优化用户体验,减少或避免不必要的键盘输入。
搜索内容建议设计成按钮选择而不是让用户手工输入
持卡人和卡号不建议让用户直接输入而是调用接口让用户选择
9、小程序页面的字体尽量与用户所运行的系统字体保持一致,常用字号为20, 18, 17, 16,14 13, 10(pt),字体颜色主内容 Black 黑色,次要内容 Grey 灰色;时间戳与表单缺省值 Light 灰色;大段的说明内容而且属于主要内容用 Semi 黑;蓝色为链接用色,绿色为完成字样色,红色为出错用色 Press与 Disable状态分别降低透明度为20%与10%
字体规范
字体颜色
主内容 Black 黑色,次内容 Grey 灰色;时间戳与表单缺省值 Light 灰色;大段说明内容用 Semi 黑;
蓝色为链接用色,绿色为完成字样色,红色为出错用色
10、小程序页面同样明确定义了列表视觉规范、表单输入视觉规范、按钮使用原则、图标使用原则等详细的规范。
三、小程序对开发规则也进行了相应的解释和定义,基本定义如下:
1、开发者需要在公众号小程序的后台“设置”-“开发者设置”中获取AppID ,通过开发者工具,来完成小程序创建和代码编辑。
2、开发者在小程序后后台绑定身份之后,可以在开发者工具内实现编辑、预览、提交等所有工作流程。
3、小程序开发的基本文件包括app.js、app.json、app.wxss 这三个。其中,.js后缀的是脚本文件,.json后缀的文件是配置文件,.wxss后缀的是样式表文件。微信小程序会读取这些文件,并生成小程序实例。
4、每一个小程序页面是由同路径下同名的四个不同后缀文件的组成,如:index.js、index.wxml、index.wxss、index.json。.js后缀的文件是脚本文件,.json后缀的文件是配置文件,.wxss后缀的是样式表文件,.wxml后缀的文件是页面结构文件。
、 黑盒测试:是一种常用的软件测试方法,它将被测软件看作一个打不开的黑盒,主要根据功能需求设计测试用例,进行测试。几种常用的黑盒测试方法和黑盒测试工具有,等价类划分法、边界值分析法、因果图法、决策表法。在实际运用中要选择合适的方法。二、 因果...
果图法是一种适合于描述对于多种输入条件组合的测试方法,根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用,通过映射同...
判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确....
判定表通常有以下四个部分组成:1)条件桩(Condition Stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。2)动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。3)条件项(Condition Entry):列出针对它左列...
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是...
1) 边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。2) 边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。
边界值分析方法是对等价类划分方法的补充. 长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例...
在编程中,布尔量指一个真或假状态。通常它们分别用0,1或1,-1来表示,这和编程语言有关。具体来说当布尔量为真的时候表示一个表达式或判断成立,否则这个式子或判断不成立。你把它理解为成立或不成立就行了。...
1)输入条件规定取值范围,则卡定义一个有效等价类和两个无效等价类。例如学生成绩范围是0~100,则一个有效类:0
1,先确定等价类别2,找出有效等价类和无效等价类3,边界值找好,尽可能多的找的会有重复的数据4,有效等价类尽可能条件符合的归一起不要重复5,无效等价类单独写开6,写好测试用例7,执行测试用例...
应用场景:只要有数据输入的地方就可以采用等价类划分法。按照需求,把无穷多的数据进行分类,从中挑选出代表性数据进行测试。具体操作:(1)明确测试对象(测试什么)(2)划分等价类(按照需求分有效、无效)(3)细化等价类(有效、无效进行细化)(4)建...
采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。
Priority()和Severity(严重程度)是的两个重要属性。很多新人经常混淆这两个概念。通常,人员在提交Bug时,只定义Bug的Severity, 即该Bug的严重程度,而将Priority交给Project Leader 或Team Leader来定义,由他们来决定该Bug被修复的优先等级。某种意义上来说...
1致命:致命是指系统主要功能丧失,用户数据受到破坏,造成系统崩溃、悬挂、死机或者危及人身安全等的问题。例如程序所引起的死机,非法退出、死循环、数据库发生死锁、数据流环节上严重的数值计算错误、产品设计存在严重的安全问题、漏洞被利用后可能导致系统...
1、New:(新的)当某个bug被发现的时候(第一次),测试人员需要与项目负责人沟通以确认发现的的确是一个bug,如果被确认是一个bug,就将其记录下来,并将bug的状态设为New。2、Assigned(已指派的)当一个bug被指认为New之后,将其将给开发人员,开发人员将...
软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等...
最多设置5个标签!
一、微信小程序的测试点
单纯功能测试的层面来说,微信小程序测试、APP测试、web测试在流程和功能测试上是没有区别的,但由于载体的不同,导致有一些不同,主要可以从几个方面体现:
1、系统架构方面
2、性能方面
3、兼容方面
4、测试工具方面
微信小程序测试与app测试非常相似,微信小程序是已微信为载体的,通过微信进入小程序中。
性能方面:
1.微信小程序使用微信开发者工具对小程序进行性能测试
兼容性:
1、手机系统-ios、Android、windows
2、手机机型-华为、iPhone、小米、iPad等市场主流的机型
3、微信版本-微信各个版本(可估计主要的用户群体和使用的微信版进行测试-微信小程序后台可查看使用版本的统计)
测试点:
更新:热更新、覆盖更新(需要注意更新版本时,用户是否需要删除小程序才会有效果)
微信版本类型:开发版、体验版、正式版,在测试过程中,曾经遇到同一套代码在体验版正常,发布 正式版就挂了,经开发分析是微信本身的bug,需要注意这点。
一、小程序开发并非随心所欲,你需要看懂以下规则才能不走弯路:
1、小程序的功能定义与实际提供的服务必须一致;小程序所提供的类目,必须放置在首页,最深也只能放置在二级页面;
2、小程序所提供的服务目前暂时不能涉及游戏、直播等服务(涉黄涉赌就不用多说了)内容也不能涉及测试类内容;比如:算命,抽签,星座运势等;
3、小程序所提供的服务可以允许设置付费可见及隐藏可见(这点对于开发者来说可以发挥地方很多,具体在后面文章做详细论述);
4、小程序不能提供与微信现有功能相似的服务,如含朋友圈、漂流瓶等,也不能提供导航、排行榜、互推的服务;
5、小程序一如既往的不支持诱导分享、诱导关注,虚假欺诈等内容,也不支持广告展示比例超过50%的页面内容;
6、小程序不得诱导、泄露、转让用户的任何数据。所有行为都必须经过用户授权或有明显提示;
二、微信团队对小程序设计也有严格定义,前端工程师们需要看懂以下规则:
1、页面设计需要考虑除微信导航以外其它导航页面的设计,遵循“导航明确,来去自如”,也就是能让客户知道,当前在哪,可以去哪,如何回去等问题。
2、页面设计需要遵循重点突出,并且不能出现与业务无关的业务入口,正反举例:
错误示例
以上页面主题是查询,但查询按钮下面却出现“今日热点|头条新闻”的无关内容
正确示例
以上页面查询按钮下面显示的是新搜索过的关键词,与页面主题匹配
3、页面设计无需考虑微信一级菜单的导航,微信系统内的所有小程序均会自带有微信提供的导航栏
标准导航图
4、微信导航栏自定义颜色规则,开发者如果需要自设导航需要与官方定义的颜色和谐搭配
官方定义导航颜色
5、小程序首页可选择微信提供的原生底部标签分页样式,该样式仅供小程序首页使用。初期的页面内导航设计尽可能利用微信自带导航Tab,添加自有导航可以添加标签分页(Tab)导航,标签数量不得少于2个,最多不得超过5个,为确保点击区域,建议标签数量不超过4项。
小程序标准导航样式
6、小程序已经明确定义了标准的启动页面和页面下拉刷新加载样式,无需开发者设计,启动页面只能上传品牌LOGO且不能更改。
小程序启动页标准样式
下拉加载页标准样式
7、小程序页面的加载反馈和结果反馈应提供载入进度和结果提示,并且每个页面都要有明确的指引操作和退出提示。
加载页必须有加载提示如右边图
结果反馈必须有明确提示如:已发送
8、小程序页面设计需要遵循“减少输入,巧用接口,多用选择”的原则,比较大限度的优化用户体验,减少或避免不必要的键盘输入。
搜索内容建议设计成按钮选择而不是让用户手工输入
持卡人和卡号不建议让用户直接输入而是调用接口让用户选择
9、小程序页面的字体尽量与用户所运行的系统字体保持一致,常用字号为20, 18, 17, 16,14 13, 10(pt),字体颜色主内容 Black 黑色,次要内容 Grey 灰色;时间戳与表单缺省值 Light 灰色;大段的说明内容而且属于主要内容用 Semi 黑;蓝色为链接用色,绿色为完成字样色,红色为出错用色 Press与 Disable状态分别降低透明度为20%与10%
字体规范
字体颜色
主内容 Black 黑色,次内容 Grey 灰色;时间戳与表单缺省值 Light 灰色;大段说明内容用 Semi 黑;
蓝色为链接用色,绿色为完成字样色,红色为出错用色
10、小程序页面同样明确定义了列表视觉规范、表单输入视觉规范、按钮使用原则、图标使用原则等详细的规范。
三、小程序对开发规则也进行了相应的解释和定义,基本定义如下:
1、开发者需要在公众号小程序的后台“设置”-“开发者设置”中获取AppID ,通过开发者工具,来完成小程序创建和代码编辑。
2、开发者在小程序后后台绑定身份之后,可以在开发者工具内实现编辑、预览、提交等所有工作流程。
3、小程序开发的基本文件包括app.js、app.json、app.wxss 这三个。其中,.js后缀的是脚本文件,.json后缀的文件是配置文件,.wxss后缀的是样式表文件。微信小程序会读取这些文件,并生成小程序实例。
4、每一个小程序页面是由同路径下同名的四个不同后缀文件的组成,如:index.js、index.wxml、index.wxss、index.json。.js后缀的文件是脚本文件,.json后缀的文件是配置文件,.wxss后缀的是样式表文件,.wxml后缀的文件是页面结构文件。
相关问题推荐
、 黑盒测试:是一种常用的软件测试方法,它将被测软件看作一个打不开的黑盒,主要根据功能需求设计测试用例,进行测试。几种常用的黑盒测试方法和黑盒测试工具有,等价类划分法、边界值分析法、因果图法、决策表法。在实际运用中要选择合适的方法。二、 因果...
果图法是一种适合于描述对于多种输入条件组合的测试方法,根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用,通过映射同...
判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确....
判定表通常有以下四个部分组成:1)条件桩(Condition Stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。2)动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。3)条件项(Condition Entry):列出针对它左列...
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是...
1) 边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。2) 边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。
边界值分析方法是对等价类划分方法的补充. 长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例...
在编程中,布尔量指一个真或假状态。通常它们分别用0,1或1,-1来表示,这和编程语言有关。具体来说当布尔量为真的时候表示一个表达式或判断成立,否则这个式子或判断不成立。你把它理解为成立或不成立就行了。...
1)输入条件规定取值范围,则卡定义一个有效等价类和两个无效等价类。例如学生成绩范围是0~100,则一个有效类:0
1,先确定等价类别2,找出有效等价类和无效等价类3,边界值找好,尽可能多的找的会有重复的数据4,有效等价类尽可能条件符合的归一起不要重复5,无效等价类单独写开6,写好测试用例7,执行测试用例...
应用场景:只要有数据输入的地方就可以采用等价类划分法。按照需求,把无穷多的数据进行分类,从中挑选出代表性数据进行测试。具体操作:(1)明确测试对象(测试什么)(2)划分等价类(按照需求分有效、无效)(3)细化等价类(有效、无效进行细化)(4)建...
采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。
Priority()和Severity(严重程度)是的两个重要属性。很多新人经常混淆这两个概念。通常,人员在提交Bug时,只定义Bug的Severity, 即该Bug的严重程度,而将Priority交给Project Leader 或Team Leader来定义,由他们来决定该Bug被修复的优先等级。某种意义上来说...
1致命:致命是指系统主要功能丧失,用户数据受到破坏,造成系统崩溃、悬挂、死机或者危及人身安全等的问题。例如程序所引起的死机,非法退出、死循环、数据库发生死锁、数据流环节上严重的数值计算错误、产品设计存在严重的安全问题、漏洞被利用后可能导致系统...
1、New:(新的)当某个bug被发现的时候(第一次),测试人员需要与项目负责人沟通以确认发现的的确是一个bug,如果被确认是一个bug,就将其记录下来,并将bug的状态设为New。2、Assigned(已指派的)当一个bug被指认为New之后,将其将给开发人员,开发人员将...
软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等...