测试规模

功能测试规模：

319 个测试用例。

非功能测试规模：

? 测试过程各类活动的工作量

测试过程回顾

4 月初，测试组开始和开发组接触。测试组先阅读了产品的相关文档，同时也通过从其他渠道了解产品的信息。之后测试组和开发组进行了初步沟通，确定如下问题：产品架构；测试的大致范围；产品性能要求；测试环境；提交第一个介质的时间；工作交互的人员接口。由于产品的相关文档所能提供的信息有限，测试组要求开发组提供了一个产品的临时演示环境，以使测试组能够更好的学习这个产品。

4 月 10 号左右，测试组完成初步的测试计划，开始编写产品的测试用例。测试用例的编写工作用了 2 周左右的时间（ 2 名测试人员完成）。测试用例编写完成时，测试计划经多次调整后，也在 4 月底定稿，相关人员对测试计划进行了评审。

4 月 25 日，开发组正式提交产品的第一个测试版本。这个版本没有制作安装程序，需要通过手工进行部署。测试组要求开发组下一个版本必须提供安装程序。第一个版本提交后，测试组认为其中一个功能设计过于复杂，和开发组讨论这个问题。开发组认为目前设计比较合理，待收到用户的实际反馈后再做决定。测试组在第一轮测试过程中发现 260 个 bug ，占 bug 总数的 28% 。

开发组在提交第二轮测试的介质时，提供了正式的安装程序。由于其他来源的意见，开发组对测试组原来提出修改意见的部分进行了调整（降低了操作的复杂度），测试组据此调整了相应的测试用例。测试组在第二轮测试过程中发现了 163 个 bug ，占 bug 总数的 17% 。

由于测试组发现系统在进行全文检索时结果不正确，开发组在提交的第三轮测试介质中，修改了系统后台进行全文检索信息的设计策略。这个修改是后台处理的变化，对系统前端没有产生影响。测试组在第三轮测试过程中，发现 96 个 bug ，占 bug 总数的 10% 。

在第四轮测试过程中，测试组发现 140 个 bug ，占 bug 总数的 15% 。

截至到第四轮测试结束，测试组共发现 659 个 bug ，占最终 bug 总数的 70% 。由于前线对产品需求比较紧急，第四轮测试结束后，经过评审，发布了产品 的 β 版本。

下面是 产品 各轮测试所产生 bug 的数量图：

?

图 3 － 1 各轮测试 bug 数量

直到 产品 的第四轮测试， 产品的部分 功能，还没有按预定的计划提供。在 产品 β 版本发布评审时，讨论了这个问题，要求尽快提供功能，避免产品后期的风险。但由于涉及到 产品 开发组与其他产品组的工作协调问题，还是决定到最后几个版本的时再提供（事实证明，这给产品后期的测试，带来了不良影响）。

产品 β 版本发布后，测试组除了进行常规的功能测试外，开始进行自动化测试编码、文档测试、各个环境的安装卸载测试工作。

自动化测试是在第五轮测试的时候开始的。测试组做了前期部分工作，在第五轮测试开始后，测试组内的两名同事开始分别编写不同模块的测试脚本。自动化测试脚本完成后，能够完成占全部功能测试执行工作量30%左右的工作。在后期的几轮测试中，自动化脚本起到了缩短测试周期的作用。

在实施这次测试自动化的时候，组内的人员没有实际的测试自动化实施经验，只是有一些概念上的认识。自动化测试是对手工测试的程序化，是开发性质的工作。测试自动化编码需要积累实际的经验，包括：脚本中变量的抽取；操作步骤之间wait时间的设置；checkpoint的选取和设置；测 试组主要进行的是以下三项工作：

性能测试； 试数据的准备、恢复；脚本的注释及文档说明；脚本的可维护性，等等。编写自动化脚本，应该作为一项基本技能来掌握，并且必须要经过一次项目的实践。我们现在实施自动化测试的很多顾虑和风险，其实根源就在于我们自动化测试实现水平的限制。通过这次实践，测试组以后在考虑怎样实施自动化测试时会更有经验。

产品的国际化支持测试，这项工作在最初的测试计划中没有考虑，是在测试后期补充的。国际化支持测试，在同开发人员讨论后，决定从数据库、 Web 页面显示 2 个方面进行测试，选取了 中国国际广播电台网站上的40多种语言进行了测试。这项测试，没有写到原来的测试计划中，而是制定了单独的计划。这项测试工作在我们以后大多数应用产品的测试中可能都会涉及到，这份测试计划在以后可作为参考。

到了产品测试的最后阶段，主要进行以下几项工作：
? 性能测试

后期提供功能的测试；

版本更新后的完整功能测试。

性能测试。性能测试的数据准备花费了不少时间，用2天多时间才完成测试数据的准备 。在性能测试过程中，发现和改进了系统中存在的3个性能问题。现在感觉，本次 产品 的性能测试进行的有些晚， 应该提前到beta版本发布后就开始着手进行，这样可以尽早发现问题，尽早解决。

后期提供功能的测试。在测试后期产品组提交了2个模块，通过测试组的测试，发现这两个模块在功能上存在不少问题。在产品临近发布的几次迭代测试过程中，多数的bug都出自这两个模块或与之相关联的模块。这种临近产品发布才提交的功能，风险确实很大，以后对这种情况要注意。

版本更新后的完整功能测试。接近测试结束，在每次版本更新后，测试组都要进行完整的功能验证。每轮测试，系统都会由于修正bug或多或少的又出现一些新bug。这个时候，更能体会到自动化测试带来的好处。在产品的最后阶段，如果是影响不大的bug，为了保证产品的稳定，是否要进行修改,需要权衡。

回顾产品的整个测试过程，当初制定的测试计划，内容是基本符合的，但实际进度比计划延迟了32 个工作日。导致这种状况的原因：首先，测试组这边在测试安排上存在问题，包括：版本更新时的工作安排不合理；某些测试工作的安排滞后（比如性能测试。测试安排的原则应该是当一项工作可以进行的时候，尽早尽快执行）、对测试工作量的预测不够准确，等等。其次，就整个过程来说也存在一些问题，包括：产品设计、功能的变更；产品部分模块提供测试过晚；产品部分版本的bug reopen率比较高，等等。

还有一个问题应该引起重视——测试组和开发组沟通协调的问题。首先，信息应该对称。测试人员要站在用户的角度考虑问题，但测试人员又高于一般的用户，所以产品的相关信息，测试组需要充分了解。其次，变更的控制，这里主要指的是开发组对产品变更的控制，从产品内部设计的变更，到界面上一个 GUI 元素的位置变化，在每轮测试提交介质前，建议开发组能提交一个变更清单。测试组这边则可以根据清单相应的进行测试用例、自动化测试脚本的更新。

关于对这个 产品 测试过程的总结，就是以上这些内容。