项目级测试设计 软件测试
在测试设计阶段，要考虑的因素有很多，比如：测试覆盖率，测试质量标准，信息来源，人员工作态度，技能，团队组成，计划的可执行性，测试阶段，被测软件技术背景，被测软件开发过程，缺陷信息，评价度量元，测试用例粒度，设计用的技术等等。当然，从不同的角度，不同预期，我们需要考虑的因素还有更多。
因此，个人认为测试设计不是尽可能多的考虑问题，而是应该把握住最关键的因素。作为项目级别的测试设计，继承项目一次性的特点，同时时间，人员素质，可用资源相对固定。如果计划这样的测试任务，我们从哪里入手呢?
要是把覆盖率作为基准的话，测试活动会更容易被评价和度量。从管理上来说，覆盖率这个标准简单，有说服力，也容易度量，可以说没有理由不作为首要指标。不过测试覆盖率是个计算值，并不准确。举个例子，一个ERP产品，可以从需求，代码块，逻辑路径，岗位职责，页面划分等角度进行覆盖。但是在项目初期，我们可以按照这些标准决定我们要做那些工作吗?当然可以，但是像85%，60%，或100%这样的数据能给我们任何启发吗?做一个各种覆盖率均为100%的设计大概只需要五分钟，但是它对项目而言是毁灭性的决定，因为它让我们丧失了集中力量的机会。因此，我觉得覆盖率是个评价测试方案用的数据，但是不能作为设计测试的指标。或者说，当你的测试设计中有覆盖率这样的数据时，你应该讨论数据背后的意义，而不是马上执行。
相比之下，人员情况是个相对稳定又实际的标准。测试人员的多少，测试人员的技术结构，工作的积极程度，已经测试团队的组成结构，这些因素都会影响到测试的执行能力，以及管理的难度。测试人员能进行什么样的测试?每天的工作量是多少?能同时进行多少独立的任务?在那些方面和程度测试人员是可以信任的呢?如何确定测试人员符合项目要求的标准是什么，怎么去检验这些标准?人员需要进行什么样的培训会对项目更有帮助?
另外一个，项目的开发模式，也就是测试的大环境。一个正常的瀑布模式，你应该考虑项目每个阶段的联系，并做到心中有数。需求和设计的联系紧密吗?设计能贯彻到编码吗，如果不能可以找到相关的负责人吗?代码的可测试性能支持单元测试吗?需求由谁来更新?完整的设计是书面形式的吗，还是在某个人的脑子里?测试工作的重点是整个开发过程，还是等代码进入可测试状态以后?整个开发过程能被暂停或取消吗，什么样的情况能导致以上结果，然后呢?
测试本身的质量，诸如强大程度，缺陷的信赖度，测试过程的可见性，合适的负责度，以及提升测试强度的方法。这些值能够度量吗?我们度量这些值的目的是什么?
可能，设计本身需要考虑的东西太多了。大概可分为对内测试活动如何安排以提高效率，对外测试的产出对整个项目，或项目以外能提供什么要的贡献，包括缺陷本身，缺陷的相关信息(项目级的度量元)，非功能性测试报告，以及为项目提供风险识别的手段。
虽然说得很乱，但是这是我为某个项目设计测试时会考虑到的内容。能够分析哪些因素对测试设计有影响，而那些因素对整体测试没有影响。之后可能得出一个非常简单的结论：需要3个初级测试人员，一个中级测试人员作为管理者(实际只有2个人可用1初+1中)，仅仅安装需求说明进行功能测试，大概进行5个版本的回归和一定的探索测试。这就是我正在给出的计划，我个人把这种行为理解为知白守黑。
文章来源于领测软件测试网 https://www.ltesting.net/
