automail

UltraSoft - Beta - 测试报告 在测试过程中发现了多少 Bug ？有哪些是Beta阶段的新Bug？有哪些是Alpha阶段没有发现的Bug？ 很多Bug在开发阶段就已经经过测试了，我们在Beta阶段采用了Pull Request的协作方式，前后端完成新功能需要进行连接测试之后才会merge到主分支Master，所以在连接测试的过程中就可以发现Bug并修复解决，在完成的覆盖测试中并没有特别多的Bug出现。 Beta阶段的Bug 在Beta阶段，我们增加了对后端数据库API调用的验证，如果请求中没有我们需要验证的数据则拒绝，所以在每个后端函数的开头加上了一个判断，然而在用户个人设置中，取出验证数据的方式有误，导致调用会出现 500 Internal Error 的错误，由于平时使用不多，没有发现，在覆盖测试中该bug才被揪出来。 Alpha阶段没有发现的Bug 在更新课程信息的爬虫中，在爬取个人课程ddl时使用了作业的url作为主键，然而在Beta开发阶段中发现存在同一个作业被创建了两次的情况——完成作业前和完成作业后，经过对比发现是课程中心的作业链接发生了变化：在完成作业前所有人是统一的链接，在完成作业后每个人的提交生成了一个submissionId被插入到了作业的url中，所以用url当作主键的情况下，完成作业前后的url不同，所以出现了两份作业的情况。

Delphi SuperDll 作为一名5年的Delpher，一直认为Delphi是桌面应用的王者，我相信其他的Delpher也这么认为。 但是，慢慢的我发现普通方式的Delphi开发会造成代码的严重臃肿，特别是MDI类大型项目、多人同时开发的情况下。 举个例子，一个Delphi常用的业务逻辑，数据导出到Excel，完全可以写成一个公用的模块放置在业务单元，子窗体用到时直接调用即可，但是一般情况下，事情并不止想象的那么简单，维护人员的思想真的一言难尽。 后来，我有了将Delphi中常用的业务逻辑功能封装成DLL的想法，所有的业务逻辑只能在DLL中实现，系统中不允许直接写业务逻辑，只能调用DLL。 这么做的好处是，相同的业务功能不会被重复开发，大大减少了代码的臃肿，同时，业务逻辑开发人员和前台开发人员独立开来，提高了开发效率。 这里就是SuperDLL的由来，后续将持续更新。 请看如下代码： 更新日志： //初始化 //邮件发送 //FTP上传、下载 //cxGrid数据导出 1 library SuperDll; 2 3 { Important note about DLL memory management: ShareMem must be the 4 first unit in your library's USES clause AND your project's