-
测试用例的编写与评审
2009-06-23 23:16:24
如何编写有效的测试用例
2009.06.23 于厦门
测试用例是测试的指导文档，是保证产品的基本武器，同时也是测试人员的主要输入成果，因此保证测试用例的有效性及时时性就显得尤为重要。哪么我们如何尽可能的保证测试用例的有效性及及时性呢？
一、明确项目的进度及计划
只有明确了项目的进度及计划，我们才知道应当在何时进行测试用例的编写，何时完成测试用例的编写。以保证在测试执行时，至少已经有了第一版本的测试用例。同时也可以避免因时间仓促而草草编写的测试用例。另外，测试用例编写任务的下达必须要明确完成的时间及需要达到的目标，没有时间限定及目标的测试用例编写将是低效的。
二、提供产品的相关文档
正所谓“巧妇难为无米之炊”，要求测试人员编写测试用例，就必需要为提示人员提供尽可能多的产品相关信息，如软件需求说明书、市场同类产品信息、市场反馈的相似产品的主要问题、软件及硬件环境，甚至于开发人员联系方式及项目的主要负责人信息等。这些信息都将有力的推动测试用例的有效性。
三、深入理解产品的相关文档
在正式编写测试用例之前，需要深入理解产品的相关文档。虽然需求分析人员都具有一定的产品规划能力，但是也有可能会犯错。很难想像根据一份有瑕疵的、甚至是严重错误的需求文档编写出来的测试用例是有着多么可怕的“指导”作用。因此我们在编写测试用例之前，需要深入的理解产品的相关文档。建议可以采用会议的方案来进行，各自提出自己的见解，经过讨论会将相关的疑问提前给需求分析人员重新确认。同时将这些疑问作为BUG进行提交，记住这也是工作成果的一部份。一份完美的需求应该不存在任何的歧义或含糊的地方。
四、编写测试用例概要
在充分的理解产品的相关文档之后，就可以正式编写测试用例的概要了。之所以没有要求进行详细测试用例的编写，主要是出于编写测试用例时间的压力及评审的需要。由于测试人员的工作除了编写测试用例以外，还要进行日常的测试工作及各类报告的书写，工作量大且相对繁琐，因此应当尽量的控制编写测试用例的时间，以保证测试人员有充分的休息时间。同时对于一份详尽的、完整的测试用例而言，对于进行评审是很不经济的（试想一下，让你对1000个详尽的测试用例进行评审，你会作何感想？）。
测试用例的概要应该简洁明了，只需要说明验证点即可。同时在编写测试用例的概要时，尽量反映时编写测试用例的基本思路。对于100个测试用例概要进行分别评审比对10类（每类10个）的测试概要进行评审要困难得多。
测试用例概要可以采用如下格式：
//以下X个测试用例用于验证XX问题：
Ø 验证……
Ø 验证……
Ø 验证……
Ø 验证……
……
五、测试用例的评审
在测试用例概要编写完成之后，下一步的工作就是进行测试用例的评审。个人对产品的理解及经验始终是有限的。测试用例的评审的主要目的就是集众人的经验及认识于一体，对测试用例进入查漏补缺，使得测试用例的有效性进一步提升。
尽管我们采用了测试用例概要及用例概要分类的方法来简化测试用例，明确测试用例编写的思路。但是对于一些比较大型的项目，其需要评审的内容仍然是巨大的。因此我们需要在测试评审开始前做好如下准备：
1. 提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。
2. 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。
3. 会议主持者（一般为用例编写人员）应在会议前整理相关疑问，以便在会议上提出。
在会议进行时，会议主持者应尽量把握会议进度，尽量按时有效的完成评审工作。在评审会议结束后，应提交会议记录，会议记录应由与会人员签字确认，以说明测试用例评审是一件严肃而认真的事情。用例编写人员在会议结束后应根据会议中提出的问题及疑问，对测试用例进行优化。
六、细化测试用例
经过测试用例的评审，并对测试用例进行优化之后就可以进行测试用例的细化工作了。测试用例的细化并没有标准的形式，依各个公司的不同而有所不同，但主要都包含了操作步骤、预期结果等。测试用例的细化就是根据测试概要，对各个验证点的前置条件、操作步骤、预期结果进行完善以适应公司测试招待的要求。对于自动化测试，在测试用例细化时应提示相关的测试脚本文件。
好的测试用例应该是具体完全的指导性，且无二义的。为了保证测试用例指导的唯一性，在测试用例细化完成后，应与测试组长进行抽查（或者与同事之间进行相关检查）。在发现问题时应及时要求测试用例编写人员进行整改。
七、测试用例长期更新
没有任何事物是一成不变的，测试用例也是如此。在进行具体的测试之后，测试人员将对产品的需求及功能等产生最为深入的理解，对于这些有用的理解应及时将其更新至测试用例中，同时对于一些不是在测试用例中发现的BUG，可根据其对价值考虑是否需要将其更新至测试用例中。测试用例在整个产品的测试过程中应一直保挂动态的更新，甚至当项目结束以后，对于市场上反馈的有价值的问题，也应及时更新至测试用例表中，直到产品退出市场为止。
-
BUG发现率及严重程度重定义
2009-04-24 19:02:43
BUG发现率及严重程度重定义
2009.04.24 于厦门
1．BUG等级划分建议：
目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。
Ø 致命(可对应目前BUG体系中的“非常严重”)：
致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
具体基本上可分为：
l 严重花屏
l 内存泄漏
l 用户数据丢失或破坏
l 系统崩溃/死机/冻结
l 模块无法启动或异常退出
l 严重的数值计算错误
l 功能设计与需求严重不符
l 其它导致无法测试的错误
Ø 严重（可对应目前BUG体系中的“严重”）
严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
具体基本上可分为：
l 功能未实现
l 功能错误
l 系统刷新错误
l 语音或数据通讯错误
l 轻微的数值计算错误
l 系统所提供的功能或服务受明显的影响
Ø 一般（可对应于目前BUG体系中的“普通”）
一般性问题主要为：界面、性能缺陷
具体基本上可分为：
l 操作界面错误（包括数据窗口内列名定义、含义是否一致）
l 边界条件下错误
l 提示信息错误（包括未给出信息、信息提示错误等）
l 长时间操作无进度提示
l 系统未优化（性能问题）
l 光标跳转设置不好，鼠标（光标）定位错误
Ø 提示（可对应于目前BUG体系中的“轻微及建议”）
提示性问题主要为：易用性及建议性问题
具体基本上可分为：
l 界面格式等不规范
l 辅助说明描述不清楚
l 操作时未给用户提示
l 可输入区域和只读区域没有明显的区分标志
l 个别不影响产品理解的错别字
l 文字排列不整齐等一些小问题
l 建议
注意：对于结构及硬件问题，由于产品测试部仅是进行辅助测试，碰到此类问题时，均将于定位于等级“致命”，具体情况由结构及硬件部门相关人员确认。
2．BUG发生率划分建议：
目前通用的对BUG发生率的划分主要有两种划分方法：一种是测试发生率：即按照特定步骤执行多次的BUG重现率；另外一种是用户使用发生率：即模拟用户在使用产品发生此问题的概率。第一种方法计量精确简单，可操作性高，但不太符合产品的实际使用情况。第二种方法，则需要推断用户使用某一业务的频率，因此计量相对没有第一种精确，操作性高，但比较符合产品的实际使用情况。由于产品的最终使用总是用户，因此建议我司的BUG发生率采用第二种方法——即用户使用发生率。
用户使用发生率=用户类别*业务类别*测试发生率
Ø 用户类别：
我们公司的主要客户群有生产人员、客服人员、最终用户。根据其对公司产品的生产、销量、声誉、维护的不同可以分配不同的权重（权重范围为0-1之间）。
如：生产人员——>0.3
客服人员——>0.5
最终用户——>1.0
Ø 业务类别：
业务类别根据具体项目的业务情况分为主要业务、次要业务及辅助业务。
业务类别的确认具有人为的主观因素，若需求文档有明确说明各个业务功能的优先级（业务功能优先级由“风险”，“复杂度”及“用户需要”在撰写需求时确认），那么一般可参考此优先级来确认。优先级高的为主要业务，优先级其次的为次要业务，其它为辅助业务（注：仅可作为参考，确认业务类别最好由市场相关人员来确认。如产品经理，市场分析人员等。）
若需求中没有明确说明各业务功能的优先级，哪么应当在测试开始前，召开由产品，研发及测试部门一同出席的会议，确认各业务功能的分类，并将其记录于需求文档中。
Ø 测试发生率
测试发生率为按照特定步骤执行多次的BUG重现率
测试发生率=BUG重现次数/按照特定步骤执行的总次数。
其中：对于概率性问题，执行的总次数应结果BUG的复杂程度执行(20-50次)
用户使用发生率等级划分：
如上所述，用户使用发生率=用户类别*业务类别*测试发生率，根据最终得到的用户使用发生率的值的不同，可以将用户使用发生率划分为如下几个等级（也可沿用旧等级划分，将<2%的问题划入等级“低”）：
用户使用发生率
新 等 级 划 分
对应于目前的等级划分
70%-100%
常常发生
高
30%-70%
经常发生
中
2%-30%
有时发生
低
<2%
一次发生
无
-
BUG中的小概率事件
2009-04-24 18:55:32
BUG中的小概率事件
对于用户而言，一个产品的好坏不仅仅决定于其产品的功能，而更加在于产品的可靠性及稳定性。小概率BUG则是影响产品可靠性及稳定性的主要因素。而小概率BUG的产生，一般是由于积累操作或多任务并发所引起。哪么在成本及时间等影响产品发布的条件允许的情况下，小概率BUG在产品上遗留的越少，那么产品的质量也就更好，用户对产品的体验值可能就越高。
但实际情况要解决小概率BUG并不乐观。由于小概率BUG发生的概率较小，因此不论是对于开发人员还是测试人员而言，要解决或验证小概率BUG都是一件让人头痛不已的事情。
哪么作为测试人员的我们如何把握住这仅有的一次或两次机会，以提供更多的小概率BUG信息给开发人员呢？
小概率BUG的多发地带：
1． 临界测试
2． 中断测试
3． 多任务测试
4． 积累测试
小概率BUG信息的提供：
1． 若被测终端提供LOG接口，在测试过程中一定要打开LOG跟踪工具。在BUG发生时提示LOG或图像。
2． 若发生小概率BUG，我们应该多做测试或者询问其它同事是否发生类似问题，争取找出其发生的规律。
3． 若发生的小概率BUG引发系统崩溃或主要功能无效，应及时通知开发人员。
4． 在提交小概率BUG时，一定要详细记录BUG发生的环境，测试步骤及时间点等因素。
小概率BUG的验证：
1． 小概率BUG的验证应当由发现此BUG的测试人员来进行。
2． 若小概率BUG相对轻微，在产品经理确认不必修改时，可以将其关闭或保留。
3． 若小概率BUG在验证时再次发生，应及时通知开发人员。
4． 小概率BUG连续验证3轮之后没有发生（每轮验证根据BUG的复杂度可分为20-50次），可将其关闭。
5． 对于特别严重，而开发人员又束手无策的小概率BUG，在条件允许的情况下，可让开发人员发布T版本来进行测试。
6．对于特别严重的，而开发人员又未确认修改的小概率BUG，可在风险中提出此小概率BUG风险。
