某甲问道：「测试做太多的话，会不会使得bug解不完？」
某乙回答：「还不简单。只要不做测试，就没有bug。」
上述对话，反应出许多软件工作人员对于测试的想法。对多数软件开发人员而言，测试大概是仅次于维护之外，最令人讨厌的工作。对软件研发主管来说，测试是必要之恶：做得不够后患无穷，做得过多又增加成本，延误商机。因此，如何能够规画与执行一个最经济有效的测试工作，当是软件研发主管们须研究的一个课题。
软件测试的困难，在于它不仅是产品的测试，更是产品设计程序的检验。由于关乎设计的测试，准则不易寻找，经验未必得以再用，他山之石也有应用的局限性，因此难度颇高。欲提高测试的效益，有赖全盘的规画，确实的执行，与事后的检讨改进动作。许多小型软件研发单位，对于软件测试并不重视，但从许多稍具规模的软件公司均配置常设测试人员，乃至于测试品保部门来看，测试工作显然有其学问与价值的。
测试工作没有最佳方法可依循，是因为不同的软件所需的测试手段不同。譬如小型软件与大型系统的做法不同；订制软件与软件包的要求不同；系统软件的测试往往无法采用应用软件所使用的技巧；游戏软件与库存系统有其各自需面对的测试标的。因此，测试人员必须因应软件的特性与资源的限制，加上过去相关的经验，规画最适合的测试方式。并随着经验的累积，不断改进作法，才能找出最佳的测试方法。
由此可知，要做好有效的测试，不只是埋头苦干而已，它需要良好的管理，使整件工作获致最佳的成果。关于测试的管理工作，可从组织、规画、执行与检讨几个角度来探讨。以下谨就笔者粗浅的经验野人献曝一番，希望提供读者基本的协助。
测试组织之设计
由于人性总自认为自己的最好最正确，完全由软件开发人员兼任测试人员，并不值得推荐。实务上往往因软件开发单位的经济规模不够，使得开发人员经常兼任测试人员。但若可行，研发单位应尽可能配置专任的测试人员，尤其是独立于开发小组之外的测试负责人员。尽管是否应设置独立测试小组业界仍有争议，许多人甚至以为保障软件品质唯有从改进软件开发的程序做起，但大部份美国的软件公司均设有独立测试或品保人员乃至于部门，这说明了独立测试仍有其不可摇撼的地位。
许多的软件研发单位将测试视为次等的工作，从而配置次等人员负责相关工作。如此一来，优秀人员无从参与，也缺乏意愿参与测试工作。结果软件品质不易度量，研发的成果常常被不佳的品质抵销，实为令软件开发人员泄气之事。主管是否能体认到软件测试的重要性，通常是成功的关键。软件测试固然是支持性工作，仍应配置合理的资源，以获取整体之成效。在当前的环境下，给予测试人员较多的关注，毋宁是必要的作法。
测试工作规画
测试工作的规画，至少包含两项要点：测试目标的订定与测试资源的配置。攻击需要目标，测试亦然。测试的目的在于找出软件的问题，提供改进之参考。目标若不明，测试人员即不知如何着手。
测试目标的订定，最重要的在于软件通过的准则，亦即测试何时方可结束。常见的情形是：软件开发的进度不断落后，最后剩余的时间仅有两个星期，于是测试人员的目标就是把最后两周用完，尽人事听天命。究竟测试多完整，隐藏的多少错误，测试工作的生产力如何？皆一概不知。反正产品卖出去或上线后有的是时间改进。然而产品销售后再改进，成本往往大幅增高，甚至原有开发人员离职他调，连亡羊补牢都倍感困难。经验一再显示，事前的测试除错绝对比事后维护省时省钱，唯有卖不出去或不能用的软件例外。
对于测试的要求可简单区分为二：一种是通过目标所订之软件品质；一种是在既定资源内达到最佳成效。前者要求山头一定要攻下，不达目的绝不停止。譬如目标为单位测试时间的错误发现率须低于某数字，若超过了就得延长测试。此种方式适用于品质要求较高的软件。至于后者则是上市时间已宣布，无法更改者，其目标着重于铲除最严重的错误。此种测试较着重测试的准备、经常对测试执行与除错设定时限与数量要求，其中最容易遵循的准则即为：重要功能永远先测。这两类测试的需求不同，足以影响到测试的计划、测试的顺序与关心的重点。读者不可不察。
至于测试资源配置适当性，则是评估测试目标能否达成的重要参考指标。测试人员需要合理的测试资源，譬如要求总研发人力的20%以上。总时程的1/3以上。人力不足，测试流于形式，时程过短，找到错误也来不及除错，均不可取。除了测试在研发的比重，也需注意测试工作本身在规画管理、规格个案订定、测试执行、回归测试、训练准备工作的人力分配。人员的训练与设备的安排尤其容易轻忽，需加以注意。不同阶段测试的资源配置，也必须加以考量，如此可避免测试集中于功能测试，忽略系统测试。这些工作的适切安排，有助于协助测试工作时时都执行最重要，也最有效的测试。
测试执行与管理
测试工作执行在管理上，首先需使测试与开发人员了解轻重缓急。测试人员常常不考虑测试的效果，而只依照测试的方便性来进行测试。譬如软件有十大模块，每一模块有50个测试个案，于是他从第一个模块的第一个个案开始测，测完一整个模块，再进行第二个模块的测试，执行全部完成或无法进行为止。事实上，测试应从重要且常用的项目测起。
开发人员的除错，则往往从好改的改起。于是100个错误改了90个，系统主要的缺陷仍为克服。测试管理人员需特别注意此事，确保测试工作的效率。
进行测试管理的好处在于随时可掌握状况，并因应需求及时调整测试策略。譬如测试一段时间后，发现某子系统的问题特别多，即可调整人力，增强该部份的测试。或是某些人的测试绩效较差，则可调整工作之分配，以求整体效果。当然，这些数据的取得有赖相关信息的搜集，包括数量与时间之信息。如果可行，可记录不同测试工作耗用的人力时数，计算耗用成本，以便未来进行测试规划时拥有更精确的参考数据。
进行相关资料的统计与分析，最好运用工具来帮忙，以节省人力并增进效果。如果市面已有的测试管理工具符合需求，也可径行采用。测试结果的统计资料，不妨公布在大家的眼前，使得测试成果可为大家了解，亦能促进工作同仁求取更佳的成绩。附图所显示为一简单的统计图表，显示每周的测试成果、除错成果，与产品残存的问题量，可协助主管决定测试终止及发行产品的时间。
测试结果分析与改进
当(阶段)测试结束后，测试管理人员可以进行测试成果的分析。有关预定目标与实际执行结果的差异，可作为下一版软件测试检讨改进的依据。譬如预定开立的测试个案数是否达成目标，执行与通过数是否可接受？投入的测试甚至除错人力是否足够？均可视状况计算依标准工作量，作为未来执行测试工作之预估标准。经由分析软件错误的生命周期，可以研究缩短的方法，例如加速除错与重测周期，或在分析设计阶段减少错误发生的机率，以缩短测试时程。
由测试结果可分析出不同测试的效益，与应改进之处。以下表为例。单元测试耗用大部份的人力，可能使整合与系统测试不完全。再以发现的错误数观之，整合测试发现一个错误的成本远低于另两项。由此可见在有限的人力时间下测试，单元测试做得太多，整合测试又太少。此意谓着对于单元测试所需耗用的人力资源过度乐观，或是在测试工作的配置不尽理想，应予改进。
测试人力时数 测试人力分布比率 错误个数 错误分布比率 平均时数/错误数
单元测试 227.104 58.6% 49 39.51% 4.635
整合测试 87.212 23.3% 54 43.55% 1.615
系统测试 70.184 18.1% 21 16.94% 3.342
合计 384.5 100% 124 100% 3.2
除了以上的测试成效分析。如行有余力时应再对错误发生的原因加以分析，力求从问题的根源加以解决。这包含测试工作的改进与开发工作的流程改进。以前者而言，可考虑对测试人员施以较充分的训练，避免测试工作因准备不周浪费宝贵的人力与时间。测试标准程序的建立，也有助于测试工作效率的提升。至于后者，可由错误发生的原因研究预防之道。例如对需求变更未确实记载，导致设计错误的问题发生，或是软件的设计未加充分的考虑再撰写程序，导致设计不良造成的大量错误，均应加以预防，如此可望从根本解决软件的问题。
结语
欲提升软件品质与生产力，得先掌握现况。测试工作既是必要之恶，就需拟定最好的方法来面对。有关软件测试方法论的书籍文章为数固然不少，在应用上仍须因应自身的情形加以调整。品管大师戴明认为：获得好品质不能靠检验，而是来自改善工作流程。因此，测试工作只是一项起步。如何藉由测试工作，了解改善软件品质与生产力之道，才是我们追求的目标。愿祝各位软件品质的捍卫者，在工作岗位顺利前进，为测试工作赢得荣耀，更为你们的成功产品喝采。
某乙回答：「还不简单。只要不做测试，就没有bug。」
上述对话，反应出许多软件工作人员对于测试的想法。对多数软件开发人员而言，测试大概是仅次于维护之外，最令人讨厌的工作。对软件研发主管来说，测试是必要之恶：做得不够后患无穷，做得过多又增加成本，延误商机。因此，如何能够规画与执行一个最经济有效的测试工作，当是软件研发主管们须研究的一个课题。
软件测试的困难，在于它不仅是产品的测试，更是产品设计程序的检验。由于关乎设计的测试，准则不易寻找，经验未必得以再用，他山之石也有应用的局限性，因此难度颇高。欲提高测试的效益，有赖全盘的规画，确实的执行，与事后的检讨改进动作。许多小型软件研发单位，对于软件测试并不重视，但从许多稍具规模的软件公司均配置常设测试人员，乃至于测试品保部门来看，测试工作显然有其学问与价值的。
测试工作没有最佳方法可依循，是因为不同的软件所需的测试手段不同。譬如小型软件与大型系统的做法不同；订制软件与软件包的要求不同；系统软件的测试往往无法采用应用软件所使用的技巧；游戏软件与库存系统有其各自需面对的测试标的。因此，测试人员必须因应软件的特性与资源的限制，加上过去相关的经验，规画最适合的测试方式。并随着经验的累积，不断改进作法，才能找出最佳的测试方法。
由此可知，要做好有效的测试，不只是埋头苦干而已，它需要良好的管理，使整件工作获致最佳的成果。关于测试的管理工作，可从组织、规画、执行与检讨几个角度来探讨。以下谨就笔者粗浅的经验野人献曝一番，希望提供读者基本的协助。
测试组织之设计
由于人性总自认为自己的最好最正确，完全由软件开发人员兼任测试人员，并不值得推荐。实务上往往因软件开发单位的经济规模不够，使得开发人员经常兼任测试人员。但若可行，研发单位应尽可能配置专任的测试人员，尤其是独立于开发小组之外的测试负责人员。尽管是否应设置独立测试小组业界仍有争议，许多人甚至以为保障软件品质唯有从改进软件开发的程序做起，但大部份美国的软件公司均设有独立测试或品保人员乃至于部门，这说明了独立测试仍有其不可摇撼的地位。
许多的软件研发单位将测试视为次等的工作，从而配置次等人员负责相关工作。如此一来，优秀人员无从参与，也缺乏意愿参与测试工作。结果软件品质不易度量，研发的成果常常被不佳的品质抵销，实为令软件开发人员泄气之事。主管是否能体认到软件测试的重要性，通常是成功的关键。软件测试固然是支持性工作，仍应配置合理的资源，以获取整体之成效。在当前的环境下，给予测试人员较多的关注，毋宁是必要的作法。
测试工作规画
测试工作的规画，至少包含两项要点：测试目标的订定与测试资源的配置。攻击需要目标，测试亦然。测试的目的在于找出软件的问题，提供改进之参考。目标若不明，测试人员即不知如何着手。
测试目标的订定，最重要的在于软件通过的准则，亦即测试何时方可结束。常见的情形是：软件开发的进度不断落后，最后剩余的时间仅有两个星期，于是测试人员的目标就是把最后两周用完，尽人事听天命。究竟测试多完整，隐藏的多少错误，测试工作的生产力如何？皆一概不知。反正产品卖出去或上线后有的是时间改进。然而产品销售后再改进，成本往往大幅增高，甚至原有开发人员离职他调，连亡羊补牢都倍感困难。经验一再显示，事前的测试除错绝对比事后维护省时省钱，唯有卖不出去或不能用的软件例外。
对于测试的要求可简单区分为二：一种是通过目标所订之软件品质；一种是在既定资源内达到最佳成效。前者要求山头一定要攻下，不达目的绝不停止。譬如目标为单位测试时间的错误发现率须低于某数字，若超过了就得延长测试。此种方式适用于品质要求较高的软件。至于后者则是上市时间已宣布，无法更改者，其目标着重于铲除最严重的错误。此种测试较着重测试的准备、经常对测试执行与除错设定时限与数量要求，其中最容易遵循的准则即为：重要功能永远先测。这两类测试的需求不同，足以影响到测试的计划、测试的顺序与关心的重点。读者不可不察。
至于测试资源配置适当性，则是评估测试目标能否达成的重要参考指标。测试人员需要合理的测试资源，譬如要求总研发人力的20%以上。总时程的1/3以上。人力不足，测试流于形式，时程过短，找到错误也来不及除错，均不可取。除了测试在研发的比重，也需注意测试工作本身在规画管理、规格个案订定、测试执行、回归测试、训练准备工作的人力分配。人员的训练与设备的安排尤其容易轻忽，需加以注意。不同阶段测试的资源配置，也必须加以考量，如此可避免测试集中于功能测试，忽略系统测试。这些工作的适切安排，有助于协助测试工作时时都执行最重要，也最有效的测试。
测试执行与管理
测试工作执行在管理上，首先需使测试与开发人员了解轻重缓急。测试人员常常不考虑测试的效果，而只依照测试的方便性来进行测试。譬如软件有十大模块，每一模块有50个测试个案，于是他从第一个模块的第一个个案开始测，测完一整个模块，再进行第二个模块的测试，执行全部完成或无法进行为止。事实上，测试应从重要且常用的项目测起。
开发人员的除错，则往往从好改的改起。于是100个错误改了90个，系统主要的缺陷仍为克服。测试管理人员需特别注意此事，确保测试工作的效率。
进行测试管理的好处在于随时可掌握状况，并因应需求及时调整测试策略。譬如测试一段时间后，发现某子系统的问题特别多，即可调整人力，增强该部份的测试。或是某些人的测试绩效较差，则可调整工作之分配，以求整体效果。当然，这些数据的取得有赖相关信息的搜集，包括数量与时间之信息。如果可行，可记录不同测试工作耗用的人力时数，计算耗用成本，以便未来进行测试规划时拥有更精确的参考数据。
进行相关资料的统计与分析，最好运用工具来帮忙，以节省人力并增进效果。如果市面已有的测试管理工具符合需求，也可径行采用。测试结果的统计资料，不妨公布在大家的眼前，使得测试成果可为大家了解，亦能促进工作同仁求取更佳的成绩。附图所显示为一简单的统计图表，显示每周的测试成果、除错成果，与产品残存的问题量，可协助主管决定测试终止及发行产品的时间。
测试结果分析与改进
当(阶段)测试结束后，测试管理人员可以进行测试成果的分析。有关预定目标与实际执行结果的差异，可作为下一版软件测试检讨改进的依据。譬如预定开立的测试个案数是否达成目标，执行与通过数是否可接受？投入的测试甚至除错人力是否足够？均可视状况计算依标准工作量，作为未来执行测试工作之预估标准。经由分析软件错误的生命周期，可以研究缩短的方法，例如加速除错与重测周期，或在分析设计阶段减少错误发生的机率，以缩短测试时程。
由测试结果可分析出不同测试的效益，与应改进之处。以下表为例。单元测试耗用大部份的人力，可能使整合与系统测试不完全。再以发现的错误数观之，整合测试发现一个错误的成本远低于另两项。由此可见在有限的人力时间下测试，单元测试做得太多，整合测试又太少。此意谓着对于单元测试所需耗用的人力资源过度乐观，或是在测试工作的配置不尽理想，应予改进。
测试人力时数 测试人力分布比率 错误个数 错误分布比率 平均时数/错误数
单元测试 227.104 58.6% 49 39.51% 4.635
整合测试 87.212 23.3% 54 43.55% 1.615
系统测试 70.184 18.1% 21 16.94% 3.342
合计 384.5 100% 124 100% 3.2
除了以上的测试成效分析。如行有余力时应再对错误发生的原因加以分析，力求从问题的根源加以解决。这包含测试工作的改进与开发工作的流程改进。以前者而言，可考虑对测试人员施以较充分的训练，避免测试工作因准备不周浪费宝贵的人力与时间。测试标准程序的建立，也有助于测试工作效率的提升。至于后者，可由错误发生的原因研究预防之道。例如对需求变更未确实记载，导致设计错误的问题发生，或是软件的设计未加充分的考虑再撰写程序，导致设计不良造成的大量错误，均应加以预防，如此可望从根本解决软件的问题。
结语
欲提升软件品质与生产力，得先掌握现况。测试工作既是必要之恶，就需拟定最好的方法来面对。有关软件测试方法论的书籍文章为数固然不少，在应用上仍须因应自身的情形加以调整。品管大师戴明认为：获得好品质不能靠检验，而是来自改善工作流程。因此，测试工作只是一项起步。如何藉由测试工作，了解改善软件品质与生产力之道，才是我们追求的目标。愿祝各位软件品质的捍卫者，在工作岗位顺利前进，为测试工作赢得荣耀，更为你们的成功产品喝采。
