根据我的观察，的测试人员可以做的事情可以包括如下3点：
　　由单纯的测试变成项目质量保证工作
　　持续集成探索和推动和自动化测试技术研究
　　测试相关工具的开发
　　1、我们先来讲第一点，由单纯的测试变成项目质量保证工作。
　　测试，从狭义的角度来讲，包括如下这些环节：
　　测试计划和测试用例编写－测试执行－质量报告书写
　　测试人员一般会在开发阶段进行测试计划和测试用例的编写和准备工作；在测试阶段，我们一般先会做功能测试，等项目功能基本稳定，bug较少了，开始做兼容性测试、性能测试、安全性测试。兼容性测试保证了产品在多浏览器、APP在产品在不同机型下的兼容性；性能测试保证了产品在海量用户大流量下的服务能力；安全测试能发现产品可能会被攻击的各个隐患。做完了这些测试以后，人员发布质量报告，产品上线。
　　不过，的测试人员需要向上游和下游拓展测试的领域，把自己放在“质量保障”的角色上，推动整个项目组一起保证质量，上游的工作包括：
　　在产品刚立项、进行需求确认的时候，测试人员会参与进去，仔细地Review需求，看需求是不是完整、有没有漏洞，这个时候还没有进入正式开发，修改需求对于项目组来说代价是少的。在这个环节，测试人员凭借缜密的推演、发散性的思维，往往能发现很多需求的漏洞，提高了项目的整体效率。
　　另外，测试人员在完成测试计划、测试用例以后，会邀请开发、策划一起来评审测试用例，在这个环节，由于测试人员把每个需求如何细化测试都体现在了用例里面，相当于再次把需求分析了个透，往往还能发现很多需求的漏洞。这也是提早发现需求漏洞的有效环节。
　　我们知道，代码的质量归根结底是由开发保证的，测试做的工作，只是发现Bug让开发修复。如果一个花瓶，一开始是很完美的；另一花瓶经过了各种修补，看起来比较完美，大家觉得哪个花瓶比较好？当然是第一个花瓶。所以，测试人员应该站在质量保障的立场，想办法跟项目组沟通、给开发提供工具，让开发自己把质量保障工作做好。比较可行的一些方式是：提供一些手工用例让开发自测；给一些自动化的接口和UI测试代码让开发自测；部署静态代码检查工具，并推动开发分析和修改发现的问题；有一些做得好的项目已经实现了持续集成，也可以尝试。
　　下游的工作包括：
　　在产品完成了测试以后，是发布的环节了，测试人员在发布的环节也能发挥作用，首先，测试人员为了部署测试环境，研究自动化部署的技术，可以把上线部署的环节也自动化，以前需要2个小时的部署环节压缩到半个小时甚至更少，而且更加准确可靠。
　　如果有些版本修改比较多，上线的质量风险大，测试人员会跟产品一起制定灰度发布的方案并在技术上进行实现，让版本先面向一小部分用户开放，如果发现Bug了，影响的用户也比较小，Bug改掉以后，再逐渐扩大用户范围。
　　另外，的测试人员还会发动项目组的其他人一起来保证项目质量，比如推动开发进行代码Review；引入冒烟自测流程，让开发先自测以后再提交给测试做冒烟测试；通过在项目组分析Bug，让开发提高自测，降低Bug数量等；引入策划、交互、视觉在测试阶段进行走查，等等各种措施。
　　2、持续集成探索和自动化测试技术研究
　　业界都在说持续集成，那持续集成究竟是个什么鬼呢？
　　持续集成原本的意思是让开发每提交一次代码自动化测试一次，如果自动化测试发现问题了，测试用例会失败，开发会马上发现这个失败，并修改代码。
　　要做到持续集成可有很多工作要做。
　　首先是编译环节，要把所有编译的环节都自动化起来，开发每次提交代码都能进行自动编译；
　　编译完成后，是静态代码检查的环节，通过静态代码检查的工具检查代码的问题，比如，数据库连接池没有释放，参数不匹配等。
　　静态代码检查完成后，是单元测试了，单元测试用例一般是开发人员或者测试人员编写，或者开发和测试合作编写，保证的是开发内部函数的正确性。一个健康的自动化测试方案中，单元测试用例的占比是高的。
　　然后是接口测试，一般保证的是后端开发提供给前端开发的HTTP接口，接口一般也比较稳定，用例比较容易维护，所以，接口测试的自动化占比也可以做到很高。
　　在接口测试的上层是针对用户界面的UI测试了，像测试人员手工执行一样，UI自动化测试能操作页面的元素，完成自动化。不过，由于用户界面常常要重构，所以我们常常会控制UI自动化测试的规模，只覆盖主干的用例。
　　的测试人员可以把自己的工作尽量自动化，并用持续集成框架串起来，提高工作效率和质量。
　　3、测试相关工具的开发
　　的测试人员会开发其他好用、趁手的工具来提高工作效率，比如数据自动生成、报表自动生成、报bug工具等。
　　其实归根结底是一句话：测试人员核心的工作是保障项目的质量，各类测试流程、技术、工具和平台的发展让我们可以更好地保证项目的质量。