老程序员转测试 配置测试环境设置共享文件 提高团队效率

经过一段时间的磨合,逐渐熟悉了测试相关的工作,作为测试主管,负责ERP系统的软件测试,产品交付。

1.  只关注C/S架构的UI,B/S和手机端暂不展开。有同事说,B/S页面做好之后,手机端可以借助自适应,达到70%左右的功能,完全不用重新开发。但就是这剩余的30%,会将团队的士气降低到及格线之下。手机设备的屏幕尺寸始终是绕不开的话题,一行到底保留多少列,网格控件到底能不能用,还有复杂的图表图形,一到手机中查看,惨烈的不忍直视。

2.  只关注Visual Studio + SQL Server的产品线,前端可以是Angular JS, Vue, Reator,后端是Web API, 这是基本的目标结构定位。虽然使用ORM(Entity Framework) 可以适应多种数据库,但MySQL, Oracel也必须排除在外,不同的数据库操作习惯,SQL语言细节,只会让产品测试难度增加,徒增繁琐工作,又不能给产品带来直接的价值。

1

1 Microsoft Windows

这是基本的环境,每个项目组成员第一天参与项目组的主要工作就是配置环境。提前给组员下载好所有的操作系统镜像,给大家平的工作省去不少时间。

image

从Window Server 2000到Windows Server 2019, 一应俱全。主要关注的操作系统是Windows 10。 多亏了微软,现在新电脑只配售Windows 10,其实省去了测试的很多工作。但是我们也需要满足工厂的最低需求,一如既往的支持Windows Server 2003/XP。再加上部分电脑是Windows 7,每次有新版本发布,我们需要同时在这三个环境中更新程序,测试功能。微软的浏览器IE的测试还更加严格,不同的操作系统平台,不同的语言环境,测试工作更加复杂。

提供镜像文件是第一步,还需要找一台性能快的电脑,生成VMWare虚拟机。我们提供Windows Server 2003到Windows 7, Windows 10三个虚拟机空白系统,这样遇到客户报告问题,立马复制一套虚拟机环境,还原数据库,测试客户问题。

很少的时候会遇到与语言有关的错误,我们为此还准备了各个环境的语言包(Language Package)。这里主要遇到的时多语言环境下,字符宽度的问题。不同的字符集语言宽度不相同,会导致UI有部分控件被遮盖或是看不清,这时直接跟开发人员讲解,也讲不出所以然。正所谓一图解千言,把程序放到这个语言环境中截个图作为BUG的附件,开发人员一看便知道,提高效率。

2 Microsoft SQL Server

数据库镜像文件,从SQL Server 200到最新的SQL Server 2019,也全部准备。我们的产品主要面向SQL Server 2008 R2,绝大部分时间里以这个版本为主要数据库平台。

image

SQL Server的问题主要是版本太多,各版本之间又不能平缓过度。低版本的SQL Server备份文件可以在高版本中恢复,但是有代数限制。比如SQL Server 2000的备份不能直接在SQL Server 2016中还原,必须先到SQL Server 2008或SQL Server 2014中还原,再备份才可以去SQL Server 2016中还原。虽然有时候可以通过SSDT生成数据库脚本与数据来跨版本传送数据,但数据量一大,生成脚本需要耗费大量时间,而且生成的脚本可能会出错。

保留SQL Server Express版本的主要原因是轻量,我们的ERP系统 99% 的情况下只用到了数据库引擎。在没有与客户相同的电脑环境(不同的测试人员安装不同的操作系统,刚好这个测试人员请假了),遇到客户报告问题,我们通过复制虚拟机备份,安装一份SQL Server Express,可以确保从接到客户问题报告到开始查找问题,这个时间点可以控制在30分钟之内。Express 版本有个令人烦恼的4G和10G文件大小限制,为解决这个问题,我们在第一步制作虚拟机的时候,会制作两份虚拟机,一份是空白的虚拟机,另一份是带有SQL Server 完整版的虚拟机,虚拟机的尺寸因为SQL Server 暴涨,跑起来的性能也会下降一些。

SQL Server的各个版本,企业版,标准版暂时没有影响,我们的工厂系统用不到高级的特性(高可用,高性能)。遇到服务不响应,重启一下服务器也不会造成多大损失。SQL Server LocalDB是个好东西,遇到有些问题是Windows 7但又不能安装SQL Server 2016,直接用Local DB来配置数据库是个折中的方案。

另外,还有一些SQL Server必备的工具,比如SQL Prompt,SQL Compare等,这些工具非常实用,是生产效率工具。遇到重建索引,可以用SQL Index Manager,遇到SQL 数据库文件损坏,需要用SQL Log Recovery导出日志数据。遇到性能问题,上SQL Sentry Plan Explorer, 查看SQL 生成的查询计划。各种情况下都需要具备一些工具程序,可以是写好的EXE,也可以是SQL TSQL脚本或是Power Shell脚本。如果遇到工具是开源的,还要考虑把源代码下载到本机,解压缩生成编译,再打包为压缩文件。这样是为了预防有一天工具出了问题或是想改造一下,可以随手就来。ILSpy反编译太花时间和精力,还要修正反编译器的语法问题,折腾的一天两夜也不是没遇到过。

3 Microsoft Visual Studio

现在测试工作平台是建立在TFS之上,好用的Visual Studio必不可少。多年的开发经验,也是为了自己方便,各个版本的Visual Studio也是一应俱全。

image

一提到Visual Studio,少不了两个基本的扩展工具,Resharper和Ozcode。因为不做开发,这一部分没有多少内容可写,主要是作为TFS客户端软件,提交BUG,撰写测试用例,上传项目文档。偶尔在工厂里还能遇到VB6写的小工具,速度快,用户好评多,真唏嘘微软这么多年,给VB增添各处feature,到头来得到了什么。

4 Microsoft Office

微软办公软件,从Office 2007到Office 2019, 是微软的现金牛,传说这颗星球上的电脑用户人手一份。

image

我们的ERP系统是不依赖于微软Office的。多年以前的一个夜晚,一个用户打开ERP系统,生成报表的时候报了个COM错误,导致一些事故。后来痛定思痛,生成EXCEL报表,不能依赖EXCEL,也就是说不能依赖COM调用,避免问题。Office Excel的版本太多,微软正版用户的服务器没必要买一份Excel的license来专门作为报表生成用。

Office 主要用来做文档处理。遇到客户讲解报表问题时,可以生成一份带数据的Excel文件传过来,报表格式,取数公式,文字样式一目了然。遇到流程或是难理解的问题,用Visio画个图交流也非常方便。市面上有很多画图工具,我认为还是微软的Visio受欢迎,兼容性好,用户基数大。

5 Visual Studio Team Foundation

微软TFS源代码和团队合作服务器。主要是获取新版本的程序。

image

TFS有一些power toys和extension,弥补TFS本身功能上的不足。TFS对SQL Server有版本上的依赖限制。目前支持SQL Server 2008 R2的只有TFS 2012或更低版本。

我推荐测试人员自己的本机电脑也安装一份TFS,作为文档控制用。这是多年的开发经验和体会,就算是一个人开发,也需要配置TFS用来管理源代码,用于对比源代码变更,撤回旧版本非常容易。虽然平时多做几个压缩包也可以凑合,如果压缩包文件太多,有时候也会忘记做压缩包,这个时候,TFS是救星。

这些文件加起来200GB多一点,如果每个人需要这些文件时,从网上找或是单独下载,会浪费大量时间。有其他同事在工作时,大文件下载会影响收发邮件的效率。平时有空收集这些工具放到公司共享服务器中,方便大家。这也是基础中的基础。平时的工作还会遇到些灵活的小工具,比如AsmSpy,GAC Manager,开源小工具,解决软件部署大问题。比如之前有同事遇到服务程序不能启动的问题,死活找不出问题,用AsmSpy一跑,红色字提示,缺少log4net.dll,5分钟就可以解决前线人员的问题,救人于水火之中。同时反馈给开发人员,部署时需要将log4net.dll也打包进来,倘若遇到客户电脑中遇到有log4net.dll时,还要在打包中制定assembly redirect,这样既不影响客户的现有程序,也可以让程序跑起来。一旦将客户的程序部署成功,再次安装任何东西要是复杂的,要打申请,审批,一套流程跑下来真是复杂。这之前遇到过.NET Framework的问题,开发人员编译成.NET 4.5.2, 但客户的机器只有4.5,按道理说,安装一个.NET Framework 4.8 可以解决问题,但就是审批不通过,开发人员只好降级编译,改成以.NET 4.5为编译平台。

posted @ 2021-02-28 15:31  信息化建设  阅读(186)  评论(1编辑  收藏