测试报告

在测试过程中发现的Bug

前端bug

前端BUG	是否解决
无法上传PDF文件	是。最初功能设想是每名用户使用自己的Azure storage账户，如果使用这种方法我们的工具将变得难以推广，因为国内大部分人都没有一张visa卡。因此我们后来改变了功能设计，在改变时却忽略了上传模板的功能，后来增加了一个上传页面，让用户上传空表单模板
工具栏图标错误	是。不熟悉fabric-icons这个UI库的使用，导致本地图标无法显示，并且在前端控制台中报warning和error。在研读原代码之后，知道了如何关联和使用这个图标库，但显示时图标发生了莫名其妙的“失真”，最终挑选原项目已有的图标作为工具栏中的页面图标。
data页面展示pdf时，无法切换想要展示的pdf	是。由于原代码架构过于复杂，一些读取storage的服务和写好的关于pdf资源展示的模块理解出错，花费一天时间才找到问题，但同时也对项目架构有了更多的理解
生成数据改变时，展示界面更新有延迟	是。一开始以为是网络问题导致的延迟，后来在代码复审的过程中，发现在生成新的pdf后，没有及时调用更新展示界面的函数，而令其自动检测容器中文件是否发生变化，有变化时才更新。发现错误后就及时进行了修补。
页面部分文字错误	是。某前端开发人员搞错了单词是否是可数名词，在代码复审的时候发现并修复，增长了姿势。😃
前端向后端发送请求时有概率出现500错误	是，发现本地测试与部署网站后测试时，Azure Function设置需要进行改变
下载的数量固定为四个	是，修改后支持任意数量PDF的下载
标注页面标注时响应时间时快时慢	否。由于原项目架构为先更新服务器端数据，再读取服务器数据显示在前端，我们依然使用了这种架构，因此响应时间会受到网速影响
有时候前端页面展示的pdf与服务器中存储的pdf不相同	否。一开始由于bug无法稳定复现，怀疑是受到网络情况的影响而搁置（确实是收到网络影响）。后来进行代码复审时，发现可以通过改变原有不合理架构避免网络状况影响，修改之后网络状况的问题不会导致展示出现错乱。但在其他条件下尝试的时候，发现是由于chrome浏览器缓存导致的问题。由于读取资源从原项目继承，且不能稳定复现，目前还在探索中，如果出现此情况需要清楚浏览器缓存后才能正常显示

后端BUG

Azure Functions 临时文件使用问题

BUG：Azure Functions为我们带来好处和便利的同时也带来了一个冲突性问题——临时文件的使用；

解决：因为Azure Functions的定位是函数，且运行环境不受本地控制，我们发现在函数中生成临时的文件会失败，导致后端逻辑一度无法实现，后来经过研究和探索，我们通过使用Azure Storage来临时存储文件，虽然带来一定的传输时延，但是整体的效果足以满足目前需求。

文件删除

Bug：前端需要显示后端对应内存中的文件，而OCR扫描会生成一些临时文件，使得第二次使用时显示错误。

解决办法：后端增加判断，每次上传时先清空对应的存储。

container删除问题

Azure Storage的存储结构如下：

—container1

|—blob1

|—blob2

—container2

|—blob1

|—blob2

BUG：删除之后的操作会失败！

解决：因为Azure删除container需要一定的时间，导致后续的http请求到达时，前一个container还没有被删除，造成冲突。因此我们改为了遍历container删除相应的blob！

name和address生成的支持

BUG：接第一个问题，name和address的生成需要后端数据，但是因为无法部署数据到Azure Functions，导致这一功能一度无法实现

解决：通过把数据库文件保存在Azure Storage上，每一次使用时通过API调用下载，虽然带来一定的时延，但是解决了这一问题。实测显示时延问题并不明显！

补充bug

前端标记框时候由对角线，有四种情况：

• 先左上，后右下
• 先右下，后左上
  ……
  因为后端在生成时需要一个基点，一开始没有考虑到第二种情况，导致可能会出现文字反转的BUG。
  解决：后端增加了处理逻辑，解决这一问题！

后端测试方案

本项目的后端是基于微软Azure Functions构建的http访问接口，遵循RESTful架构。

目前前后端的交互较为单一，只涉及了GET和POST两种请求，因此测试主要针对这两种，同时API的功能主要为：

• 上传pdf模板文件 —— POST + pdf二进制文件
• 上传JSON文件 —— POST + JSON字符串
• 请求生成 —— GET + 参数：生成数量
• 请求下载 —— GET

如上，对于各种情况，分别构建相应的http请求，使用Postman软件来测试API的正确性，前后端结合后，通过前端进一步测试后端API的正确性。

同时，Azure Functions提供了请求的追踪，使得我们可以追踪每一次请求的具体过程，分析问题，监控http服务的运行！

压力测试

你是怎么进行场景测试（scenario testing）的？包括你预期不同的用户会怎样使用你的软件？他们有什么需求和目标？你的软件提供的功能怎么组合起来满足他们的需要？

卡罗尔·狗蛋·史密斯

用户信息	用户情况
姓名	卡罗尔·狗蛋·史密斯
用户身份	微软表单项目开发测试人员
用户情况	为了测试项目的bug，需要雇用大量的人力来填写表单
用户痛点	大量人力意味着大量的薪水，另外耗时较多
典型场景	新的模型开发出来了，又到了紧张刺激的训练和测试环节，但是真实表单数据，公司有要求不让用，只能花钱请人伪造表单来训练测试了，又费时又费钱。发现有一个自动生成表单数据的项目，可以把数据生成到Azure里，还能下载下来，真是非常方便呀！
预期场景	史密斯访问项目网址，新建一个项目 史密斯上传了要进行测试的空白PDF，并进行了标注 史密斯使用生成功能，生成出了大量的仿真PDF 史密斯下载好PDF，完成任务

给出你的测试矩阵（test matrix），也即在什么样的平台、硬件配置、浏览器类型……上对你的软件进行测试？

基于chromium的浏览器均可以正常使用

操作系统	浏览器类型	是否正常
win10	Microsoft Edge（版本号81.0.416.68 ）	正常显示和使用
win10	Internet Explorer（版本号11.778.18362.0）	不正常。该版本最后发布日期应该是2015年，比较老旧，无法正常显示
win10	Google Chrome（版本号81.0.4044.129）	正常显示和使用
Ubuntu16.04	Google chrome	正常显示和使用
Android9	华为手机自带浏览器（版本号5.0.420）	可以正常显示，并且界面大小比较合适。但由于部分操作涉及键盘，在使用时存在困难。

你的软件Alpha版本的出口条件（exit criteria）是什么？也即在什么条件下，认定你的软件已经足够好，可以发布Alpha版本？

当Alpha版本能够在浏览器上正常显示，并且：

• 用户能够上传空白表单；
• 支持对空白表单进行操作，使PDF能够添加姓名、年龄、地址等简单的相关信息；
• 能够正确生成PDF文件；
• 能构正常下载PDF和JSON文件的压缩包；
  即认为符合alpha版本发布条件