Alpha阶段测试文档

测试计划

  • GUI 功能测试(结果见测试 bug 列表)
  • 新增扩展语法单元测试
  • Markdown 解析测试
  • 场景测试

测试 Bug 列表

  • 滚轮,字体,树枝的颜色,sidebar 宽度相关样式没有正确合并。
  • 进入榕图模式后无法进入其他模式(点侧边栏没有效果)
  • 窗口缩小后再放大,榕图不会随之变化
  • 在有些模式下显示只有单文档才可用的功能按钮
  • 热更新在特权目录下 (如 C:\Program Files) 无法自动完成提权,导致更新失败
  • 进入榕树模式时,榕树显示位置不在页面中心
  • 执行撤回操作后,光标位置会回到文档起始位置
  • 执行撤回操作后,文档中的多个连续换行符丢失
  • 直接复制图片文件粘贴时,会将图片内容转为 base64 格式进行渲染,对于比较大的图片有可能会卡死软件。
  • 从系统托盘点击软件的关闭窗口按钮,会导致当前编辑的文件内容丢失

请添加图片描述

  • Markdown 内的网页超链接,点击后会打开一个没有关闭按键的网页窗口
  • 对齐问题

请添加图片描述

  • 代码高亮较少

请添加图片描述

  • 连续输入 —- 报错

请添加图片描述

  • 光标位置太靠下

请添加图片描述

  • 帮助菜单没有绑

请添加图片描述

  • 无法从打字机模式退出,模式提示不清晰

请添加图片描述

  • 文本区的宽度过窄

请添加图片描述

请添加图片描述

  • 被引用数目错误
  • 公式不支持 \begin{align} 这样的对齐
  • 如果在公式框里面打入 ,会变成两对 ,会变成两对 ,会变成两对,而 typora 则会给报错
  • 较大文件进入榕树模式时,加载较慢且没有提示

扩展语法测试

针对扩展语法,我们修改使用 go 语言编写的 lute 解析器,进行解析。对修改后的 lute,加入了一些扩展语法相关的单元测试保证扩展语法正确性。

我们的扩展语法形如 -[label](ficus link),前面是 ficus 链接的 tag,后面是 ficus 链接指向的文件位置,类似 Markdown 中图片的语法。

var markTests = []parseTest{
    {"f1", "-[1](./testmd.md)", "<p><a class='ficus-filelink' href=\"./testmd.md\">1</a></p>\n"},
    {"f2", "-[==foo==](bar)\n", "<p><a class='ficus-filelink' href=\"bar\"><mark>foo</mark></a></p>\n"},
    {"f3", "==-[*foo*==](bar)\n", "<p>==<a class='ficus-filelink' href=\"bar\"><em>foo</em>==</a></p>\n"},
    {"f4", "==-[*foo*](bar)==\n", "<p><mark><a class='ficus-filelink' href=\"bar\"><em>foo</em></a></mark></p>\n"},
    {"f5", "==*-[foo](bar)*==\n", "<p><mark><em><a class='ficus-filelink' href=\"bar\">foo</a></em></mark></p>\n"}
}

lute 与渲染器实现实时渲染,所见即所得是依赖一套 markdown->html,html->markdown 的互相转换机制。前端的修改直接作用在 html dom上,通过 lute 将修改后的 html 转回 markdown。因此对于拓展语法,也需要实现相应的转换。对这一部分也扩展了单元测试,这一部分基本上就是把之前的markdown2html的测试反过来

var vditorDOM2MdTests = []parseTest{
    {"f1", "<a class='ficus-filelink' href=\"./testmd.md\">1</a>", "-[1](./testmd.md)\n"},
    {"f2", "<a class='ficus-filelink' href=\"bar\"><mark>foo</mark></a>", "-[==foo==](bar)\n"},
    {"f3", "<p>==<a class='ficus-filelink' href=\"bar\"><em>foo</em>==</a></p>", "==-[*foo*==](bar)\n"},
    {"f4", "<mark><a class='ficus-filelink' href=\"bar\"><em>foo</em></a></mark>", "==-[*foo*](bar)==\n"},
    {"f5", "<mark><em><a class='ficus-filelink' href=\"bar\">foo</a></em></mark>", "==*-[foo](bar)*==\n"}
}

Markdown 解析单元测试

由于 Ficus 需要结构化的管理 Markdown 文本,因此需要支持对 Markdown 文本的层次化解析,并支持我们的扩展语法如须等。由我们完成 Markdown 解析部分的同学,编写了相关的解析测试。

测试结果及覆盖率如图

请添加图片描述

请添加图片描述

场景测试

预期用户

笔记场景

姓名沈强
年龄17
职业高中学生
专业高中生物竞赛生
工作生活整理生物笔记备考竞赛
需求生物知识过于庞大,盘根错节,难以整理
姓名郭笑笑
年龄25
职业自由职业
专业计算机
工作生活在博客上发表自己的知识博客
需求博客内容的呈现形式需要反复地斟酌润色

测试场景描述

沈强

沈强是一位热爱生物竞赛的高中生,他发现自己的笔记零散且不易管理。于是他开始使用 Ficus,一款功能强大的 Markdown 文本编辑器,来整理他的生物竞赛笔记。

沈强打开 Ficus 软件,进入主界面,他看到左侧是文件浏览器,文件大纲浏览器,右侧是一个文本的实时所见即所得编辑区域。他打开了他存放所有笔记的文件夹,并在 Ficus 里面创建了一个名为 “生物竞赛笔记” 的文件,然后开始输入他的笔记。

沈强像使用其他 Markdown 笔记软件一样,熟练的输入了一系列笔记正文内容,沈强使用 Markdown 中的标题功能,将它的文档组织成一个清晰的树状结构。

当沈强写完一段笔记后,他切换到了 Ficus 的榕树模式,这个模式下, 格式化的展示了沈强编辑的文档。

沈强可以以一个树状的视图查看他完成的笔记。沈强发现,树的结构和他期望有一些差异,某个二级结构应该成为一个一级的结构,沈强随后熟练的用鼠标拖拽二级结构到一级根下,这个修改立即同步到了文档中,完成了对文档的同步修改。榕树模式下展现的文档更有层次化,沈强使用榕树导出图片的功能导出了一份 png

沈强回到所见即所得的编辑模式下, 在界面左侧选择进入了大纲视图,沈强想针对之前完成的某一节进行一些修改,沈强在左侧大纲视图中,选中了相应的一节,编辑器文本框跳到了沈强期望的节处,沈强完成了修改,Ficus 自动保存了编辑后的文件,沈强使用 pdf 导出功能,导出了完成的笔记文档打印。

郭笑笑

郭笑笑是一位大学计算机本科生,她热爱博客写作,并且喜欢使用 Markdown 编辑器来书写博客。计算机专业的博客常需要输入一些数学公式。她使用 Ficus 这款内置 katex 的 Markdown 文本编辑器完成她的博客编写。

郭笑笑打开 Ficus 软件,进入主界面,她从左侧的文件浏览器打开了她存放博客文档的文件夹,并新建了一篇博客,开始了文档编辑。郭笑笑需要插入数学公式时,她借助了 Ficus 内置的 katex 支持,实现了公式编辑的所见即所得。当郭笑笑编辑完她的博客后,她使用 Ficus 的导出功能,将博客导出为 PDF 格式的文档,方便她进行分享。

编辑完成这篇博客后,郭笑笑通过侧边栏打开了榕图模式,这里展示了她当前打开的博客文件夹中所有的文件,以及层次关系,互相引用关系。

由于 Ficus 使用标准的 Markdown语法,她的博客也可以很容易的被上传到一些静态的博客网站上。

测试矩阵

平台信息构建基本MD编辑-富文本模式基本MD编辑-源码模式大纲视图文件操作(正常)文件操作(非法)文件刷新本地ficus链网页超链接引用计数字数统计场景测试-沈强场景测试-郭笑笑热更新
Windows NT 10.0.22621.1555; x64
Linux 5.15.90.1-microsoft-standard-WSL2; ubuntu 22.04.2 LTS; x86_64
Windows NT 10.0.22621.1555; x64
Linux 5.15.90.1-microsoft-standard-WSL2; ubuntu 20.04 LTS; x86_64
Windows NT 10.0.19043.1381; x64
Windows NT 10.0.19044.1704; x64
Linux 5.15.108-1-manjaro; manjaro; x86_64
Linux 5.15.102-1-manjaro; manjaro; x86_64
Windows NT 10.0.22621.1546; x64
Macintosh OS X 10.14.6; Apple Silicon; arm64

出口条件

功能条件

完成基本文档编辑,文件基本操作,对 Markdown 基本语法支持无问题,支持榕树模式、榕图模式显示、大纲视图、引用计数,支持 PDF 导出等常用文本编辑器功能,支持热更新。在主流操作系统平台(windows,linux)上运行没有问题。

测试条件

编写并通过全部 Markdown 相关的单元测试,可以通过场景测试中的场景验证,通过矩阵测试,保证各平台用户的数据安全,保证软件有热更新功能,可以快速更新修正bug。

姓名郭笑笑
年龄25
职业自由职业
专业计算机
工作生活在博客上发表自己的知识博客
需求博客内容的呈现形式需要反复地斟酌润色
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1.5测试中需要考虑的各种测试类型 黑盒测试:不基于内部设计和代码的任何知识,而是基于需求和功能性。   白盒测试:基于一个应用代码的内部逻辑知识,测试是基于覆盖全部代码、分支、路径、条件。   单元测试:最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做,因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好,除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。   累积综合测试:当一个新功能增加后,对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作,或当需要时那些测试驱动器已被开发出来; 这种测试可由程序员或测试员来做。   集成测试:一个应用系统的各个部件的联合测试,以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。   功能测试:用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。   系统测试:基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件。   端到端测试:类似于系统测试测试级的“宏大”的端点;涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。   健全测试:典型地是指一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如,如果一个新版软件每5分钟与系统冲突,使系统陷于泥潭,说明该软件不够“健全”,目前不具备进一步测试的条件。   衰竭测试:软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。   接受测试:基于客户或最终用户的规格书的最终测试,或基于用户一段时间的使用后,看软件是否满足客户要求。   负载测试测试一个应用在重负荷下的表现,例如测试一个 Web 站点在大量的负荷下,何时系统的响应会退化或失败。   强迫测试:在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试,如某个动作或输入大量的重复,大量数据的输入,对一个数据库系统大量的复杂查询等。   性能测试:在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。   可用性测试:对“用户友好性”的测试。显然这是主观的,且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。   安装/卸载测试:对软件的全部、部分或升级安装/卸载处理过程的测试。   恢复测试测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。   安全测试测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。   兼容测试测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。   比较测试:与竞争伙伴的产品的比较测试,如软件的弱点、优点或实力。   Alpha 测试:在系统开发接近完成时对应用系统的测试测试后,仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。   Beta 测试:当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成 概念的进一步扩展 软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。 1 数据和数据库完整性测试 数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。 数据库完整性即: 主码完整性:主码不能为空; 外码完整性:外码必须等于对应的主码或者为空。 数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。 在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。 比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。 员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。 2 白盒测试 白盒测试是基于代码的测试测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试 2.1 静态白盒测试 利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下: Function NameGet(){

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值