在进行软件测试的过程中你有没有经常感觉到你的时间很紧张，不够用？你觉得你已经掌握了测试过程的每个步骤，但是很快你会意识到你又处在计划中"时间不够"的死循环中。
我也是这样，而且这种感觉并不是很美妙。
关于这件事我苦苦思考，想要有所突破。要怎样才能在测试中有个完美的开始，不太糟的过程，让人满意的结果。以下，便是我的分析。
我的时间都去哪儿了？
首先，你得知道这是怎么造成的。有很多原因，包括以下几点：
#1）估计不正确
如果一开始你的预期就不准确，那么会导致整个测试最终的失败。一个成功的测试预估应该涉及 到以下几点:
工作准备时间--在测试中我们谈到的需要准备的工作例如：
· 识别并整理回归套件（Regression Suite）
· 创建测试数据
· 确定测试准备时间（如Smoke、Sanity Test）等
测试用例维护：测试用例是要供长期使用的。在执行的时候肯定会进行一些微小的更新。在测试一个新的软件时候，建议说最多不超过30%的总测试时间用于这些小型的维护任务。在实际测试中，团队和项目可能用不了30%时间，但是需要花费一些精力来做这些工作。
Ad-hoc/Exploratory测试：脚本测试计数是测试估计数的主要分母。但是即使模型主要是脚本，这世界上也没有哪个团队说能够否定探索性软件。
报告/沟通：这包括电话会议、站立式会议，更新管理工具等。
紧急因素：按照标准来说建议设置25-30%的原始估计为缓冲。但是这样很少有团队能负担得起。但即使是这样，要是有可能的话，还是留点喘气的空间。
团队及其能力：如果你有一个团队，或者他们是第一次使用测试工具，你可能需要腾出一些时间来做培训。根据团队的实际能力来量身定做一套适合团队的计划方案。
#2）构建不稳定以及其他的技术性问题
Smoke/Sanity测试失败：当进行到质量检查环境后，AUT基本测试失败，QA团队几乎不会对测试执行做任何事。在这样的情况下，我们可以做其他的事情，但是这仍然不会填满测试测试周期。所以，这也是时间被浪费的一个主要方面。
测试数据不可用：每一个测试项目都必须有一个"产品类似数据"（Production-like data）。没有及时进入QA环境也是另一个阻碍因素。有时候测试人员可以通过创建和管理自己的测试数据来解决这个问题，但是这是很费时间的。
环境问题：构建失败的部署、服务器不断超时，更多的像类似这样的问题会不断耗费你的时间。这可能来源于这样的一个事实：一些公司（不是全部的）对于构建一个具有高效率的工作环境的重要性没有给予足够的重视。他们经常试图摆脱低容量的服务器和设置，但这只是一个短时间的修复，从长远来看并没什么好处，事实上这可能会使浪费的时间更多。
#3）有关各方缺乏一致性：
这可能是因为Agile或者SAFe团体内部关联过于密切而造成的一个罕见的问题，但是许多团队仍然面临着Dev，Ops和QA应该从何处接收可交付成果的不一致性和误解，这样一来时间也就浪费了。
测试人员如何获得足够的时间进行测试？
#1）准确估计。有疑问时可以根据实际在估计的合理幅度范围内浮动，但是不能低估数值。不要忘记根据团队的能力、使用工具和工作流程进行估算调整。完成后，按照流程寻求正式签字，保持透明度让每人都知道，并保持。
#2）考虑到历史数据--测试管理工具（The Test Management tool）是你最好的朋友
· 早期版本测试周期需要多长时间？
· 什么样的问题导致上一个测试周期的中断？
· 大多数测试用例在通过之前有多少次运行？
· 报告有哪些缺陷？
· 什么缺陷导致测试中断？
#3）对以下这些问题做到心中有数，提高工作效率：
· 了解项目的重要功能有哪些？
· 找出项目的高风险模块？
· 用户最了解哪些功能？
· 哪个功能具有最大的安全影响？
· 哪些功能对用户的财务影响最大？
· 应用程序的哪些方面对客户最重要？
· 哪些部分的代码最复杂，最容易出错？
· 应用程序的哪些部分是在急剧或恐慌模式下开发的？
· 开发人员认为应用程序的最高风险方面是什么？
· 什么样的问题会导致最糟糕的宣传？
· 什么样的问题会导致最多的客户服务投诉？
· 什么样的测试可以很容易地覆盖多种功能？
· 考虑到这些要点，您可以在较少的时间限制下大大降低项目发布的风险。
#4）使用测试管理工具。这将大大减少准备、报告、维护的时间和精力。
#5）提高自身能力。对于不正确的构建和测试技术问题，我们能做的不多，首先最重要的是提高自身的技术能力，通过查看测试结果总结自己的缺陷，避免重蹈覆辙。
#6）经常定位自己。明确自己的进步和缺陷，不要让自己的工作状态被团队外部利益绑架，关注自己完成目标的能力才是最重要的。
另外，一定要思考"效率与质量"的经典难题。因为，当你测试结果显示为每天能测试出50个bug，这看起来工作很有成效，不过要是这大部分都是无效的话，这将又会成为一大难题。
