软件测试读书笔记一

lsekfe · 发表于 2016-1-8 11:26:25

测试计划中有关计划的相关主题：
测试结束标准
一些相关约定，部分模板中添加入“术语”一栏
测试工作中产生的文档及定义（测试用例文档，缺陷报告文档等）
测试工作个团队之前的协调工作，主要包括开发组需要对测试组提供的相关帮助
测试的范围
测试的时间安排（时间进度表）
测试的策略
测试过程中的资源要求
测试人员的任务分派
测试中可能遇到的风险等问题
测试工作的度量和统计
测试工具相关的计划
等等。

以上这些主题都是常见且有助于我们做好计划工作的内容，至于测试费用等的计划，笔者认为适当估计但不要过分追求，因为在实际的操作过程中，测试工作延期、测试工具购置、人员流动造成的培训费用等会打乱这个计划，并且在测试计划中列出的费用是不会跟财务直接挂钩的，具体费用还得依照公司专用流程，因此“测试费用”这类主题在笔者计划测试的过程中不会考虑太多。

也就是5W1H定义：
> WHY：为什么要写测试计划；
> WHAT：测试什么；
> WHEN：测试不同阶段的起止时间；
> WHERE：文档放哪；
> WHO：哪些人去做；
> HOW：怎么测试；

中国有句老话“养兵千日，用在一时”。这句话往往是在临战的时候将军（测试负责人）对战士（普通测试人员）说的。中国古代还有一个方法叫做“战时兵闲时农”的策略，即我们广大的劳动人民在没有战争的时候安心种我们的地，一旦战争爆发或者国家需要的时候我们就披上盔甲去作战。这两句话给我们一个提示：我们应该培养我们的测试人员或者说我们的测试队伍。

者先拿“养兵千日用在一时”来讲，正如我上面提到的，往往在临战的时候大家才想起这句话，可是我们不妨倒过来想一想，一时的用是需要千日的积累的。这也是在提示我们，一支优秀的测试队伍的每个人都应该是优秀的并且我们需要在“用一时”之前好好“养千日”。这种积累不是一天两天可以形成的，正所谓冰冻三尺非一日之寒。为什么要在谈论计划测试的时候谈论这个问题呢？原因在于“巧妇难为无米之炊”，我们在做计划的时候如果发现没有一个可用之才，那我们的计划怕是做不下去了，或者我们只有准备另外招新人到行伍中间来，亦或者只能外包测试给专业队伍，这无疑又增加了项目的风险，因为新人或者其他队伍使我们不了解的，他们会做成什么样子只有老天知道，当我们把命运交给老天的时候，这相当于在玩火。我们需要把“养千日兵”拉到我们的计划中来，从更加长远的角度来计划一下我们的测试工作，测试方向等等。对于人才的培养，一般使用的是人尽其才的分工制度，即某一个或者一些人熟练掌握某一些测试技能，并对其他技能有所了解，最理想的情况下，我们在测试的方向（或者说是本公司主要的开发方向相关联的各个测试技术方面）都有“专家”，这样才可以保证一个测试队伍可以应付不可预知的测试任务。

我们的学习方向，笔者大概归纳一下：

> 测试理论（包括测试基本概念，流程，管理等等内容。对于测试来讲，这才是基本）

> 测试文档（虽然网络上的文档中的内容对于目前的你来说不可能完全有用，但是知道一份专业或者说完整的文档是怎么写的也是必要的）

> 测试工具（对于刚起步的测试人员，如果你不是开发大牛，建议你还是先使用别人已经写好的工具）

> 开发知识（有则加之，无则添之，总是是要学，因为这一点是为将来打算，这些知识有助于我们更好地测试）

对于一般外包项目来讲，对于测试要求相对较低，而时间是固定的。对于这种项目的测试工作来讲，一般是标准的段段式的，即计划测试，测试用例设计，测试用例执行及bug管理，测试报告提交等等阶段。这就好弄多了，根据经验（如果一点经验都没有，那还有直觉）我们把这几个阶段换算成比例，然后把测试总时间瓜分了，需要提醒大家的就是记得在瓜分之后留点“缓冲时间”来，否则到时候出了点意外就麻烦了，记住是在每段时间之后加上一个缓冲期，而不是最后加上一次。

对于产品来讲，测试要求会比较高，时间当然也是需要考虑的，套用IT界最常被引用的一句话，“在这个瞬息万变的时代”，把握时机对于一个产品来讲无疑是很重要的。这个时候我们还是先将测试分段，对于这种项目，我们首先站在测试质量的角度，实事求是按照功能点数目、难度，测试经验等来估计测试时间，然后将总时间加起来，如果时间充裕，我们考虑加入更多测试面，如果时间紧迫，我们考虑是否删除部分非核心功能，以降低开发和测试的时间成本，从而为测试质量保驾护航

测试标准应该包含的内容：
》有效测试用例（功能）执行率达到X%？
》单元测试代码行覆盖率达到X%？
》单元测试用例通过率X%？
》单元测试用例设计通过评审
》核心模块（A,;B,D等模块）测试覆盖
》所发现缺陷均纳入缺陷管理系统
》优先级最高的bug全部修复
》其他bug全部被处理（修复，延迟并报告等处理方式）
》功能测试用例模块，功能点覆盖率达到？

按照测试类型来的测试停止标准：
比如单元测试活动在满足以下所有条件之后可停止：
》核心模块代码100％经过Code Review
》单元测试用例设计通过评审
》测试用例执行率100%
》最新版本的单元测试通过率为100%
》单元测试全局代码行覆盖率不低于80%
》单元测试单个模块代码行覆盖率不低于70%
》单元测试中被测单元发现的bug产生率不低于3个/千行代码
》所有发现缺陷都纳入缺陷追踪系统
》优先级1类bug全部被修复
》优先级2，3类bug全部被处理（修复或者不处理并明确在测试报告指出且获得通过）
》完成了单元测试报告并通过评审
……

实际工作中会出现的停止“标准”
测试活动在满足下列条件之一时需要暂停或者终止：
》新的需求变更过大，测试活动应暂停，待需求定义稳定后继续；
》测试超过了预定时间，且测试时间不可能继续增加的情况下应停止测试；
》测试成本增高（Bug发现率低于1个/周，此时所发现缺陷低于预定义的上限）；
》若开发暂停，则相应测试也应暂停，并备份暂停点数据；
》软件系统通过验收测试；
》软件项目在其开发生命周期内出现重大估算和进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据；
》项目负责人申明停止项目；
》团队集体（开发，管理，测试，市场，销售人员）同意停止项目（因市场及利益等原因）；
……