课程描述：全方位的软件测试管理
“能不能再测试一下另外的情况”、“能不能测试的更快一点”、“少给你们安排两个测试人员可以吗”、“你们测试团队能不能少占点测试环境”。从项目一开始，测试团队就会收到各种各样的问题，这些问题都指向了如何提高测试的效率，而且这些问题会一直伴随到整个项目测试结束。
“全方位的软件测试管理”课程，将为你分享一个优秀的测试团队在测试活动中到底通过什么来表现出来，如何通过有效的软件测试管理，达到软件测试的“多快好省”。
1. 多
多测试一些场景、用例、组合、各种功能等等，是每个项目对测试团队的热切希望。如何测试的更多，这里可以分成两个方面：
一方面是测试团队没有办法找到更多的测试点，设计不出更多的测试用例，不知道自己应该测试什么。这个时候测试团队应该考虑基本功能都测试完了，是不是还需要各个功能之间交互和互相可能的影响，还可以测试安全性、可靠性、性能，是否还涉及到和各种其他产品的兼容性测试，都考虑到了以后，还应该考虑一下，被测试对象中的易用性是否需要测试。但是这些测试的思路并不可能会凭空出现，除了借鉴一些他人的测试经验以为，测试团队对被测试对象的理解是非常重要的。测试医疗软件的团队和测试游戏软件的团队在“多”方面肯定是不一样的。
另一方面是有了很多的测试内容，但是时间人员有限，这时候如何能够测的更多。这就要求一个高效的系统化的测试管理。尽可能将阻碍测试的“地雷”提前排除掉。这些“地雷”可能是开发团队带来的。例如：开发人员编写的需求质量太差，或者是设计变动以后没有及时的通知测试团队。也可能是测试人员自己埋的地雷。例如：不能等到要开始测试的时候才发现有测试环境还没有准备好，避免在测试过程中使用的自动化脚本本身出现太多的问题等。这就要求测试经理凭借自己丰富的经验能够提前预测到可能存在的各种问题，而采取必要的预防措施。
2. 快
测试得更快和上面讲到的“多”是相铺相成的。如果能够以更快的速度进行测试，那么自然就可以测试的更多。“工欲善其事，必先利其器”。使用各种工具是一个有效提高测试速度的手段。这里的工具不仅仅是指像IBM、HP等提供重量级的测试管理、执行工具，也包括各种小的能够非常快速有效的解决问题的工具甚至脚本。例如：每天测试人员在访问测试环境的时候都要过一下防火墙，可以通过网页也可以通过FTP的方式，如果有一个小脚本自动的来完成这个动作，那么可能每天都可以节约1-2分钟。在构造各种测试的时候，可能一个Perl的循环语句也能够帮助你节约10分钟。在测试过程中，还经常发现测试人员将很多时间花费在了搭建测试环境上了。如果测试人员能够通过各种手段（包括做镜像、虚拟机、甚至使用云的环境）来将重复的劳动自动化，那么测试想不快都不可能。
这里的“快”，除了测试执行的速度快以外，还包括发现缺陷快、得到测试结论快。能够迅速的发现缺陷需要测试人员具有强烈的探索精神。测试不仅仅是按照测试用例把所有测试步骤都执行完，而是要“眼观六路，耳听八方”。缺陷往往在一些非正常路径上出现，需要测试人员具有开放的思维和敏锐的观察力。有时候在测试过程中，测试组长会问测试人员，你测试的这个模块质量怎么样。如果测试人员是按部就班的执行测试用例，那么他回答起来就会比较困难。但是，如果测试人员在开始测试的时候就把其中最有可能出现问题的地方先测试了，那么他就能比其他人更快的获得被测试对象的信息。
3. 好
如何判断是一个好的测试。这里主要是从缺陷这个角度来分析。自从GlenfordJ. Myers在1979年提出软件测试的主要目的是发现缺陷以来，发现缺陷一直是软件测试最重要的目的之一。我们都知道在现实世界中没有缺陷的系统是不可能的。软件测试就像是医生一样，对于一个有病的病人，医生的首要任务就是找到病症在什么地方。如果病人做了一堆检查，但是医生切告诉他没有什么毛病，那么没有人会对这个医生的工作感到满意的。
因此用更早发现更多更严重的缺陷来作为“好”的测试一个考核点，是个很好的方向。测试的尽早介入已经提出很多年了，有不少团队已经开始实施。测试人员在前期去参与需求的讨论，对需求、设计和代码进行评审，对于尽早发现缺陷是非常有意义的。但现状是很多测试人员前期介入主要是学习，根本没有提出建设性的意见或者发现缺陷。发现严重缺陷并不困难，困难的是你能不断的找到严重缺陷。测试人员的技能的不断提高就显得尤为的重要。
4. 省
所有的测试项目中时间都是不够的，人力资源都是紧张的。这里的“省”关注在节约资源上，能不能用更少的人或者更少的软件和硬件来达到同样的测试目的。前面讲的“多”如果说是做加法的话，那么这里的“省”在一定程度上是做减法。要利用更少的人达到同样的测试目的，一个明显的方向就是要提高每个测试人员的战斗力，让他们的效率更高。那么除了人的能力以外，还有其他的吗？分析测试目的是个非常重要的方向。不是所有的测试活动对于达到测试目的都是有帮助的，即使是有帮助，帮助的程度也是不一样的。例如：不是每个测试数据对于发现缺陷的帮助都是一样的，这也是为什么大家要用边界值来测试的道理；不是每个测试用例都需要写的非常详细的，因为后面可能会因为需求不断的变化而返工；不是每个模块的缺陷密度都是一样的，多的地方就应该多测试一些，相反可以在缺陷少的地方省点资源。
测试中还可能出现各种潜在的重复测试，这些都是我们“省”的方向。测试组中可能有功能测试、安全性测试的或者兼容性测试，这些测试之间可能需要搭建的基础环境都是一样的，那么可以搭一次或者一套环境而测试多种类型吗？这些各种类型的测试中有些只是观测点的不同，测试步骤都是相同的，他们是否可以连在一起测试？在日常的测试工作中，很多地方都存在各种各样可能“省”的地方，需要大家去思考和挖掘。
“多快好省”是每个测试团队所一直努力的目标。伴随着对“多快好省”的思考的过程，也是测试团队不断进步的过程。但是“多快好省”本身其实又是矛盾的。当测试团队想“省”的时候，那么他可能就会影响到“多”。不同的测试团队在不同的阶段可能最求是不一样的。有时候可能更关注“多”，有时候可能是“快”，而很多情况下需要在“多快好省”中取得一个平衡。从这一点上，可以说测试管理除了是一个技术活以外，他也是一门艺术。