性能测试和压力测试该何时做

    一般我们采用的测试流程应该是：首先功能测试，确保功能没有问题后再做性能和压力测试。其实我们这样做的一个原因是测试人员首先默认了只要功能没有问题，那么性能等等的问题开发人员在项目初期就应该已经经过详细调研了，要不然干嘛要做？但是理想是丰满的，现实却是骨感的，测试人员有时候把开发们想的过于完美了，他们很多时候也会犯“想当然”这种错误，可能只是简单的做了个调研，甚至根本没有调研就开始兴致盎然的写代码了，于是一个很大的坑就丢给了测试人员，只看你什么时候能踩到了！

    那么作为测试人员要如何避免在dead line的时候才发现问题，搞的整个项目组鸡飞狗跳呢？首先你要把你的开发当成任性的小孩，他们唯一感兴趣的就是写代码，让他们去认真调研好比让小孩子写个六百字的议论文一样难。这时候我们不妨强势一点。一般大项目都会有项目初期的讨论会议，在会议上我们就要问一些问题：这个项目希望达到什么样的性能？你们的架构预计要调用哪些其他的模块，这些模块是否会成为性能瓶颈？代码调用的这些模块确保都是稳定的吗？当你问了这些问题后开发可能会对此有些重视了，他们会简单做一下调研，然后告诉你一个结果。但是这个结果可靠吗？不一定！所以我们也不能偷懒，每个模块都会有对应的测试人员，我们可以去问他们，他们给我们的答案可能会更细致，因为测试人员看问题的角度是相似的，他们更知道我们想要什么！

    如果问题能在上面那个问答环节就暴露出来是最好的，但是如果没有呢？这时候我们应该已经确定项目的架构就是这样子了，下面开发们要去写代码了。一旦开发代码freeze了，准备提测了，那么我们就要开始按照计划做功能测试了，这时候又回到上面的问题，性能测试最后做合理吗？不留到最后功能有问题性能没法测，但是留到最后一旦性能有问题小则做一些简单的优化，大则牵扯到整个架构的变化，后果严重了！

    如何尽量去避免把问题留到最后呢？当我们做功能测试的时候往往要做好多次，第一遍验证基本功能，第二遍可能包含一些异常case等！其实第一遍我们往往就会发现很多问题，而发现问题之后丢给开发去解决，这时间我们会等，等开发提交新包，其实这时候我们可以做一些事情，比如准备性能的环境和数据，这些工作并不需要开发的程序配合。当我们完成第一遍的测试时，我们已经确保程序至少在正常情况下是可运行的，而且这时候我们的性能测试环境和数据已经准备差不多了，那么我们也就可以开始做性能测试了！性能测试很多时候是采用一些自动化的工具来做，环境准备好，之后就是改动各种参数去做重复性的工作，那么即使后面我们同时再功能测试也不会对工作有太大的影响，或者如果你和开发的关系足够好，也可以说服开发去承担部分工作，毕竟对他们来说性能也是他们非常感兴趣的东西！这时候的性能结果虽然不是完全准确的，但是至少如果有问题也会提前暴露出来，留给开发们比较充足的时间去想对策，测试人员也不会因为最后一刻才发现问题变成众矢之的！

    其实在工作中总会遇到各种各样的问题，当有了问题才会促使我们去思考，原有的习惯就是合理的吗？别人都这样做这样就是对的吗？之所以没有被质疑，那是因为别人没有因此付出代价吧，所以我想说真正推动人进步的不是成功，而是逆境！