发表于: 2018-04-04 11:22:13

2 2298


今天完成的事:

1.根据师兄的建议,了解了UI测试和Android各个版本号和iphone各种型号的参数规格并做了个统计。

2.了解接口测试.

3.完善任务二的总结。

一.什么事UI测试?

UI测试就事你设计好了一个产品,你需要对这个产品的外观进行测试,它是否符合用户的审美。它的功能按钮放置谁否符号用户的操作习惯。你所使用文字、图片是否合理等等。

测试目标:

1.通过浏览测试对象可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法 (Tab 健、鼠标移动和快捷键)的使用

2窗口的对象和特征(例如:菜单、大小、位置、状态和中心)都符合标准。

测试方法:为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。

测试方法:

1、静态测试:对于用户界面的布局,风格,字体,图片等与显示相关的部分测试应该采用静态测试,比如点检表测试,即将测试必须通过的项用点检表一条一条列举出,然后通过观察确保每项是否通过。

2、动态测试:对用户界面中各个类别的控件应该采用动态测试,即编写测试用例或者点检表,对每个按钮的响应情况进行测试,是否符合概要设计所规定的条件,还可以对用户界面在不同环境下的显示情况进行测试。

完成标准:

证实各个窗口都与基准版本保持一致,或符合可接受标准

需考虑的特殊事项:并不是所有定制或第三方对象的特征都可访问。

而针对WEB应用程序,也就是我们通常所说的B/S系统,可以从如下方面着手来进行用户界面测试:

导航测试

导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。

导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。

Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

图形测试

在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

(1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

(2)验证所有页面字体的风格是否一致。

(3)背景颜色应该与字体颜色和前景颜色相搭配。

(4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩,最好能使图片的大小减小到 30k 以下

(5)最后,需要验证的是文字回绕是否正确。如果说明文字指向右边的图片,应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

通常来说,使用少许或尽量不使用背景是个不错的选择。如果您想用背景,那么最好使用单色的,和导航条一起放在页面的左边。另外,图案和图片可能会转移用户的注意力。

内容测试

内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"。

对于开发人员来说,可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能,然后开始开发,在开发的时候,开发人员可能不注重文字表达,他们添加文字可能只是为了对齐页面。不幸的是,这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则,公司可能陷入麻烦之中,也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时,最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章,所以相信您也希望自己的站点能更专业一些。 最后,需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址,或者从某个站点下载浏览器。但是如果用户无法点击这些地址,他们可能会觉得很迷惑。

表格测试

需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格?把价格放在左边,而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽,表格里的文字是否都有折行?是否有因为某一格的内容太多,而将整行的内容拉长?

整体界面测试

整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

对所有的用户界面测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

二.Android版本号和iphone各机型参数规格:

1.iphone各机型参数规格:

2.Android版本号:

Android milestone builds (with Astro Boy and Bender floating around in here somewhere)

Android 1.0(没有开发代号)

Android 1.1 - Petit Four(小蛋糕)

Android 1.5 - Cupcake(纸杯蛋糕)

Android 1.6 - Donut(甜甜圈)

Android 2.0/2.1 - Éclair(松饼)

Android 2.2 - Froyo(冻酸奶)

Android 2.3 - Gingerbread(姜饼)

Android 3.0/3.1/3.2 - Honeycomb(蜂巢)

Android 4.0 - Ice Cream Sandwich(冰淇淋三明治)

Android 4.1/4.2/4.3 - Jelly Bean(果冻豆)

Android 4.4 - KitKat(奇巧)

Android 5.0/5.1 - Lollipop(Android L)(棒棒糖)

Android 6.0 - Marshmallow(Android M)(棉花糖)

Android 7.0 -Nougat(Android N)(牛扎糖)

Android 8.0 -Oreo(Android O)(奥利奥)

三.接口测试:

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。

使用范围:

接口测试一般会用于多系统间交互开发,或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统,主要测试这些系统对外部提供的接口,验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口,越往上层,其测试的难度越大。接口测试在淘宝的应用是一个自下而上的发展过程。

接口测试实施在多系统多平台的构架下,有着极为高效的成本收益比,接口测试天生为高复杂性的平台带来高效的缺陷监测和质量监督能力。平台越复杂,系统越庞大,接口测试的效果越明显。

接口测试的目的是测试接口,尤其是那些与系统相关联的外部接口,测试的重点是要检查数据的交换,传递和控制管理过程,还包括处理的次数。外部接口测试一般是作为系统测试来看待的。

不是所有的团队都可以在一个隔离的测试环境中进行测试工作的,因此使得对外部接口的测试显得困难。我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来测试。等等这些都增加了实际测试执行中遇到的风险,但有些时候是可以避免的。

假设/预处理

项目的责任人/开发人员必须已经成功完成了单元测试功能测试集成测试,一些错误都已经被列出。测试策划人员拿到的是最新版本的源代码

期望

正如前面提到过的那样,最重要的是关于外部接口的测试,这需要依赖于外部接口的相关数据,而这可能是极其复杂的

测试项目需要一系列的测试计划以及和外部组织的协调工作,主要包括:

负责人选

预定的测试时间

如果没有合适的测试环境,测试可能需要在周末或者工作时间以外的时间里进行

需要什么类型的测试用例,需要多少以及这些用例分别是用来测试什么的

提供测试用例的副本及相关文件给相关合作人员

如果外部组织有一些特殊用例需要执行,我们也需要拿到相关副本及文件

谁将提供测试数据,这些测试数据包括哪些方面的内容,是以什么形式给出的(纸质,电子档还是只是一些数据的底稿并且需要相关的人员整理成可用的数据)

谁将对测试结果进行确认并且判别这些数据就是我们所需要的

每隔多久时间我们需要各路人马聚在一起讨论测试中遇到的问题以及测试进度

所有正常的情形和异常的情形都需要测试,测试的各个方面(数据的各个出口,路径,入口)都需要尽可能考虑周全。我们不仅需要用一般大小的数据量去测试,也需要用预期的或者规定的最大数据量去测试

如果允许的话,我们还可以测试各个部分处理一批数据的时间数据

如果因修复bug等改动代码从而改变了接口的某一端,相关的决定,到期时间,再测试等过程都应该被记录在案,并且分发到各个相关组织或人员。

遇到的问题:

暂时没有(以后可能碰到吧)

明天要完成的事:

1.了解测试点以及测试点提取

2.了解下Python。



返回列表 返回列表
评论

    分享到