啥也不会还作出了机器学习——测试心得

写这篇博客的时候真的是，心里百感交集。

从啥也不会，到如今项目收工。一个学期的研究讨论，真的是，全部人都辛苦了。

一群人从0开始完成项目。主要技术岗们疯狂看论文，找文档 ，各类看……你们终于走到了能够测试的环节了

而后就……喵喵喵？咱们的算法怎么测试啊？

项目的主要难点在于算法，enas算法自己就是（按照如今的时间算的话）不到一年前才提出的新型算法。测试算法的话只能经过一个代码测试准确率。而后呢……没了。

有点不太对啊……

忽然想到咱们还有前端界面——微信小程序和后台管理系统。

好，咱们能够测试了。

---

 

 

 

这个测试主要针对的是微信小程序和后台管理系统。而算法自己的准确率具备不可控性。（关于算法准确率的问题会在下面详细说明）

因此 ，关于测试的报告就要……到来啦~

 

 

 

（微信小程序部分）

1.0测试用例设计

咱们随机选取了200张/批次的图片进行测试，对于结果进行累计统计。覆盖正例训练的十个类别。

1.1测试环境

1.1.1硬件环境

Android6.0及以上设备一台，iPad/iPhone设备一台：用于测试前端界面对于不一样系统布局是否正常，软件因为基于微信小程序，故只需正常开启权限便可使用。

1.1.2软件环境

基于微信小程序，微信版本须要能支持小程序运行。主要基于不一样的系统，ios和安卓端的不一样样式，以及不一样的屏幕所展示的不一样效果。

1.2 测试工具

    本次测试未用到测试工具。 

1.3测试方法

经过人工对如下几个方面进行测试：

1)   权限测试：因为小程序在使用过程当中不是很须要用户的相关信息，用户的惟一标识也是经过获取openId获得的。而openId的获取并不须要权限与受权。因此用户给小程序受权与否并不影响小程序的使用和性能，以及数据库的填充和信息获取。

2)   UI测试：小程序的界面展现，字体，按键的方式位置

经过小组全部成员的手机进行测试，发现小程序的界面比较明确，按键也都同时显示在屏幕上，字体由用户手机自带字体决定，因此总体没有什么问题。

3)   兼容性：针对不用的操做系统和屏幕尺寸以及微信版本，程序都能较好的适配而且完成既定目标与要求

小组成员的手机牌子较多，包含了安卓平台和ios平台，针对两种大的平台均可以较好的适应。针对你们的手机的不一样的版本和不一样的微信版本，也能够有较好的适应结果。

4)   性能测试：页面渲染时间，资源占用问题——页面是否会在屡次跳转后出现长时间卡顿

在人工测试时，并未发现长时间卡顿现象。能够屡次识别而且继续识别进行跳转。页面渲染时间，在进入小程序后页面渲染时间人体感知下没法感知到。结果仍是比较好的。

5)   网络测试：验证在各类网络环境与条件下小程序是否可以照常运行。

在测试过程当中，咱们在移动网络和Wifi网络的环境下均可以正常使用。在无网络链接时，小程序能够正常打开，进行简单跳转，可是因为上传图片和文件下载须要网络，因此小程序的主要功能几乎没法实现。只能看一下界面展现了。（能够在没网的状况下把两个界面跳来跳去）

6)   功能测试：按照数据流向进行测试，好比图片上传后在下一界面的展现是否正常完整正确。而后是界面跳转功能，各界面的跳转可否正常实现，按钮的功能可否知足要求。在最后的相关论文查看界面，是否能查看/下载论文，可否成功将论文的相关连接引入。

 

针对功能咱们的结果能够分为两类：

a)   图片上传显示功能：

图片能够完整的显示在要显示的界面（也就是下一界面）。虽然因为每一个图片大小不一样，会致使显示时页面有所变化，好比有的页面能够直接看到结果，有的页面会须要下滑才能看到结果。因为图片大小的问题，页面可能会出现须要下滑的状况。可是全部的功能及按键都能较好的保存下来而且所有展现（图片显示这里咱们为用户体验也没法进行修改，只能经过下滑进行其他操做）。并且图片保存较为完整清晰，能够很明确的看出来最后结果。

在测试过程当中这个数据流向正确，而且显示完整。

b)   跳转功能：

关于跳转功能，在跳转的过程当中咱们的原跳转界面和跳转到的界面之间的跳转都能正确进行，而且能较好的跳转过去。并且关于界面保留，咱们的界面会保留一些须要比较频繁的界面（也就是选择识别内容的界面），其他界面会关闭。而后在识别结束选择继续识别时会将其他界面所有关闭，保证识别种类选择界面是惟一保留的。

这样的跳转也保证了咱们的微信小程序可以支持屡次识别，不会由于页面保留过多，页面栈满而致使卡顿。

c)   论文查看功能：
查看论文时会显示加载中的字样，让用户可以知道本身的已经点击，论文正在准备中（界面会出现loading栏，提示字样为“论文正在赶来…”）。而若是用户此时没有链接网络（未链接网络时也能够到达论文查看界面），则会提示用户打开论文失败。经过这样的显示可让用户对现阶段的行动更为了解，也符合Don’t Make Me Think的须要。

 

（web后台管理部分）

2.1测试环境

2.1.1硬件环境

装有浏览器且能正常上网的电脑和手机（不一样系统都可）。

2.1.2软件环境

web部署在装有Ubuntu Server 16.04.1 LTS 64系统的服务器上，运行网页须要设备（手机、电脑）上安装某类浏览器（IE等）。

 

2.2 测试工具

    本次测试未用到测试工具（web安全访问计划采用AppScan测试工具）。

2.3测试结果

对后台管理系统的各项测试结果以下：

1)   权限测试：权限测试：验证用户是否能够未通过登陆直接访问后台。验证时直接请求视图函数/server等，会默认跳转到登陆界面，没法进行登陆。测试结果以下：

  

当用户错误输入密码时，有错误提示：

  

 

若必填项为空，会有默认提示： 

 

权限测试经过。

 

2)   UI测试：经过测试不一样浏览器对界面字体图层位置等的影响，发现对测试覆盖到的浏览器都可以进行正常的显示，在IE、QQ浏览器、360浏览器、搜狗浏览器，均显示正常，且在显示比例135%时，整个窗口适配最为美观。

 

3)   兼容性：针对不用的操做系统和屏幕尺寸的pc和平板，程序都能较好的适配而且完成既定目标与要求，可是对于手机的各类浏览器，有显示不兼容的状况存在，导航栏的显示存在异常。

 

4)   性能测试：

a)   页面渲染时间：因为背景图较大，在第一次登录系统时，首页面的背景会加载较长时间（具体时间与网络情况相关，网络正常的状况下不超过三秒的加载）。

b)   页面相应时间：各个页面相应具体时间的测试状况和分析见本报告的4.3性能数据与分析部分。

c)   资源占用问题：运行页面的时候不占用太多系统资源，一般不会影响机器的运行，也与机器配置和浏览器相关。

d)   为了提升用户体验，在数据量较大的部分页面作了处理，例如在评价展现界面，只展现总体的分布状况和最新的20条具体评价内容，不会产生卡顿或者渲染失败等问题。

 

5)   功能测试：按照功能模块进行测试，好比点击导航栏目查看不一样的反馈数据以及按钮功能是否出现BUG等。

测试环境：360浏览器

左侧导航栏按钮测试均正常，能够正常跳转，包括WX一图识趣 V1.0该home键，以及admin鼠标滑过期可默认弹出下拉框按钮。

点击左侧反馈统计页面，稍做等待后会加载处页面信息以下：

 

 

鼠标滑动到饼状图上能够看到详细信息： 

  

点击左侧日志查看界面，能够看到系统的最近日志文件：

 

帐户管理页面默认展现当前管理员用户信息内容，包括ID，用户名以及密码和用户状态，具体操做有左侧选择复选框后能够进行批量删除，以及添加帐户和右侧对每个ID进行停用操做：

选择每行左侧复选框（可多选）后，点击上方批量删除按钮对用户进行批量删除操做：

 

点击确认后页面自动刷新并剔除所删除的行，再也不展现到页面上。

【注】

当未选择任何复选框后，会有异常提示：

 

点击添加按钮，自动弹出添加窗口，用户输入信息后点击添加会自动跳转到主页面，并展现添加一行。

 

【注】当必填项未选择时，对必填项会有提示操做：

 

停用/启用测试：

点击每行后最后一栏对应操做按钮响应。

 

测试结果及缺陷分析

3.1 覆盖分析

3.1.1需求覆盖分析

微信小程序部分：

首先进入界面，接着用户能够对须要识别的类型进行选择（手写体数字或CIFAR10数据集中的十类物品）。用户进行点击后能够成功跳转，而且屡次点击不会出现卡顿与生命周期异常，确认无误。

用户选择从相册或相机拍照上传图片，上传后能够成功跳转到下一个页面，有相应反馈给用户，确认无误。

上传后能够正确接收后台传来的识别结果，并保存用户提交的评价数据，识别结果较为精确，确认无误。

此外，在模拟单次传输后，咱们对后台进行高IO测试，以200张每批次的测试样例进行测试，得出正确率约90%，确认无误。

需求覆盖率=测试经过需求点/需求总数×100％=5/5×100％=100%

web后台管理系统部分：

登陆界面验证，输入系统所分配的帐号密码或者超级帐号能够进行正常登陆；

页面数据请求，点击左侧导航栏可切换不一样页面进行访问查看，点击左上方home键能够返回第一页面，点击右上方admin正常下拉，点击切换帐号或者退出可正常退出到登陆界面。

数据展现验证，服务器状态页面可正常显示后台服务器信息。反馈统计页面第一部分正常显示统计饼状图，第二部分正常显示用户评价详细信息。日志查看页面正常显示文件信息和文件内容。帐户管理可正常查看帐户列表，点击删除按钮和复选框能够删除用户，点击添加按钮能够正常添加用户，点击右侧启用/停用按钮能够启用或停用帐户。

3.1.2测试覆盖分析

    略

3.2  缺陷统计与分析

因为小程序未发布，没法进行负载测试与压力测试。

3.2.1缺陷统计

3.2.1.1全部bug列表

web后台管理系统部分：

①　在帐户查看时，未点击行前复选框就进行批量删除会致使点击肯定按钮无反应（已解决）。

②　左侧导航栏出现BUG，没法正常跳转。

 

3.2.1.2重要解决bug列表

在帐户查看时，未点击行前复选框就进行批量删除会致使点击肯定按钮无反应（已解决）。

网页左侧导航栏出现BUG，第四个选择的页面只能在第三个窗口打开，其他窗口没法打开。（已解决）

3.2.1.3遗留bug列表

暂无

3.2.2缺陷分析

本次测试发现的主要缺陷在于处理时间过长，致使客户端响应时间太久，用户体验较差。

在后台管理系统的测试中，因为设计时未考虑手机使用后台管理系统的相关状况，因此后台管理系统的网页没法在手机端使用，只能经过电脑网页运行，手机不能使用。

3.2.2.1缺陷综合分析

web后台管理系统部分：

用户登陆界面考虑安全问题，对密码进行MD5加密操做，可是加密安全度不高。

在member-add页面进行添加用户时，未对密码和用户名进行加密操做和特殊字符验证。

在数据库评价信息过多时，评价结果展现页面渲染部分较慢，渲染动画未正常显示。

3.2.2.2测试曲线图

本测试曲线图主要用于展现测试的正确率。

 

 

按理来讲，做为一个程序识别的准确率应该在95%以上，咱们目前只能达到93%以上。可是正如测试图像所示，这个识别的准确率是一个波动上升的曲线，只是因为时间和金钱的限制，致使咱们没法继续训练进行识别。相信若是能够继续训练，这个模型的结果能够有更好的结果。

3.3 性能数据与分析

3.3.1性能数据

经过运行记录识别所用的时间，咱们对5000张测试集进行测试，输出结果时间。能够看出一次识别的反应时间大概在0.1s左右。对于一个用户来讲，这个时间应该还处于能够接受的范围。  

 

 

3.3.2测试结论

测试能够经过。虽然反应有些迟钝，可是还能知足用户的基本识别要求。而关于后台管理系统，虽然手机端不能适用，可是使用电脑能够很好地进行使用和查看管理。因此本小组认为这个程序能够发布使用。

 

测试总结和建议

4.1软件质量

软件开发成功达到预期目标，能够交付使用。

4.2软件风险

目前对于后台的管理审计未进行安全性检查，前端因为托付在微信小程序端，故数据安全性受到微信限制。

4.3测试结论

对测试计划执行状况以及测试结果进行总结，包括：

1．主要测试方面均已涉及，但较为浅层，对于安全性问题未深刻考虑，主要功能实现并获得良好测试

2．在测试风险应对方面，积极给出测试方案与样例设计，对可能遇到的边界状况以及数据通路进行了检查

3．完成了预约的测试目标并测试经过

4．能够进行下一阶段的检查

 

---

 

经过设计，对后台管理系统和微信小程序作了一系列的基本测试。

在测试的过程当中，咱们尽量的将全部能想象到的内容完成。可是可能有的时候尚未 很考虑到一些奇葩用户的奇葩需求。已经尽量的将特殊状况进行想象和测试，而且对过程当中出现的bug进行了解决。可是由于没有学过测试的相关内容，对测试实在是不够了解。没法清楚地对项目进行测试，也没法很专业系统的进行测试工做。

自己因为咱们项目的特殊性，在完成过程当中也屡次感受到了咱们的特殊。咱们的项目其实需求很简单。名字解释了一切——基于Pytorch图像识别的ENAS。重点在于算法实现，所用框架为Pytorch，其中没有写的就是，网络架构为CNN（卷积神经网络）。简单的需求也注定了咱们所获得的结果简单，自己就不具有很高的表面工做量。而最为核心的部分又有代码帮忙进行测试。因此咱们的测试结果具体如何仍是有些未知的。也算是一系列的未知数。

总结一下——在进行测试的过程当中，仍是感受到咱们的许多不专业性。最后，就有点玄学了……一切看玄学吧。

 

---

 

 

2019.1.4补充

偶然状况下，咱们发现原来微信小程序能够自动测试。微信开发者工具也具有测试功能。

因此咱们抓紧最后机会使用自动测试对微信小程序进行了一个测试。可是因为测试具备冷却期（24小时）。因此只生成了一个测试报告。

下面展现的是微信开发者工具进行测试所获得的测试结果：

 

将其中主要内容放大，这里主要是针对性能进行测试而且获得及汇报结果：

 

接着，因为第一个界面存在渲染，因此只有这个界面出现了加载时间。

 

其他全部界面都能正常显示，就是数据信息几乎都不存在。应该也是这个测试工具的不成熟与不完善吧。（或许是自己这些信息在这个小程序中就没有显示与测试的必要） 

使用下来感受微信小程序的自动测试结果还不如人工测试。不过在针对性能的测试中微信小程序的自动测试有数据支持，更具有说服力和可信度。

 

---

 

 

最后再说一些心得吧。

咱们在进行测试的过程当中，一开始因为种种问题，有些bug没有测试出来（也是因为咱们对测试的不熟练与不熟悉）。而后还有咱们在使用微信的过程当中遇到的种种反人类的设计，对用户至关不友好。后来经过修改，让小程序几乎是教学式操做，这样处理后小程序也就比较的友好外加比较符合Don't make me think的基本要求了。

其实小程序在使用的过程当中仍是发现了一些设计上的不完美的，好比说物品识别返回结果是英文，不够贴合用户，可是因为时间限制不太敢进行更改了（从周三开始进入项目冷却期，避免bug的出现，可是周五才以为这里实在是反人类……但是已经要上交服务器了），这也是咱们下一步要对这个项目进行更改和完善的内容。

作项目的过程真的是体会到了开天辟地，测试的时候也是人心惶惶。当时测试的时候测出了一个bug就一群人特别紧张，怎么办，要怎么处理，五我的这几天一直在集中开发，而后集中测试，一我的测出了bug，就有一群人围着开发人员，疯狂改代码，解决bug。尤为是今天上午和昨天，感受就体会到项目上线前开发者们的疯狂。不过在测试的过程当中依旧感受咱们的测试不够专业完美具体，仍是有很大的改进空间。这个项目虽然实现，可是不能否认它有二期的可能性。不过一切可能性都留给将来就好。

 

此次测试也算是告一段落，这个学期也走向了终结，人生中第一个项目也就尘埃落定。咱们这个“啥也不会还作机器学习”开发小组，终因而从啥也不会到勒作出了机器学习。