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

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

从啥也不会，到现在项目收工。一个学期的研究讨论，真的是，所有人都辛苦了。

一群人从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。尤其是今天上午和昨天，感觉就体会到项目上线前开发者们的疯狂。不过在测试的过程中依旧感觉我们的测试不够专业完美具体，还是有很大的改进空间。这个项目虽然实现，但是不可否认它有二期的可能性。不过一切可能性都留给未来就好。

 

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

转载于:https://www.cnblogs.com/clover-muyou/p/10205592.html