经过一段时间的磨合，逐渐熟悉了测试相关的工作，作为测试主管，负责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 Microsoft Windows
这是基本的环境，每个项目组成员第一天参与项目组的主要工作就是配置环境。提前给组员下载好所有的操作系统镜像，给大家平的工作省去不少时间。
从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，绝大部分时间里以这个版本为主要数据库平台。
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也是一应俱全。
一提到Visual Studio，少不了两个基本的扩展工具，Resharper和Ozcode。因为不做开发，这一部分没有多少内容可写，主要是作为TFS客户端软件，提交BUG，撰写测试用例，上传项目文档。偶尔在工厂里还能遇到VB6写的小工具，速度快，用户好评多，真唏嘘微软这么多年，给VB增添各处feature，到头来得到了什么。
4 Microsoft Office
微软办公软件，从Office 2007到Office 2019, 是微软的现金牛，传说这颗星球上的电脑用户人手一份。
我们的ERP系统是不依赖于微软Office的。多年以前的一个夜晚，一个用户打开ERP系统，生成报表的时候报了个COM错误，导致一些事故。后来痛定思痛，生成EXCEL报表，不能依赖EXCEL,也就是说不能依赖COM调用，避免问题。Office Excel的版本太多，微软正版用户的服务器没必要买一份Excel的license来专门作为报表生成用。
Office 主要用来做文档处理。遇到客户讲解报表问题时，可以生成一份带数据的Excel文件传过来，报表格式，取数公式，文字样式一目了然。遇到流程或是难理解的问题，用Visio画个图交流也非常方便。市面上有很多画图工具，我认为还是微软的Visio受欢迎，兼容性好，用户基数大。
5 Visual Studio Team Foundation
微软TFS源代码和团队合作服务器。主要是获取新版本的程序。
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为编译平台。