MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">所谓轻量级，本文的含义是包含测试人员三人以内、项目周期在三月以内或者测试负载量较低的项目。
一般轻量级的测试项目普遍都为时间紧，资源少，需求不明确或者优先级权重较低的测试项目。所以能够分析使用和形成的文档较少而且无法使用很标准规范流程。所以我们需要对各个流程进行拆分和合并，从而满足项目的需要。
正常的软件测试周期分为如下阶段：
Planning计划阶段
Analysis分析阶段
Design javascript.:;" target=_self>设计阶段
Construction书写阶段
Testing Cycles测试阶段
Final Testing 完成阶段
Implementation执行阶段
对于计划阶段，我们是不能跳过的。即便是无法形成文档，至少也要做到心中有数。一般来说，所谓计划就是在起始和终结时间内，你都需要干什么。所以要包含如下几个要素：
- 什么时候可以开始测试
- 什么时候必须结束测试
- 测试的最终目地是什么，或者说测试到什么程度就可以接受
- 测试环境
- 测试人员的时间
- 测试的方法
- 开发的文档等
基本上明确了如上几点，你就可以断定出一个大概的蓝图，根据完成阶段的标志从而制定你在分析设计和书写阶段的深度和广度。
例如：完成阶段是只要保证所有的功能可用。那么你在分析和设计阶段只需要考虑正向测试即可。而在测试用例的书写和测试阶段，就可以设计最小的数据集。例如对某个字段，只需要验证合理范围的数据可通过即可。在执行阶段，就可以注明测试通过了某个数据集。
实例：一个可接受整数1-99的字段。测试时可以只测试1和99这两个整数。对于边界值1和100就可以抛弃。同时也抛弃了其他特殊字符的测试。
而且对于完成阶段要保证所有的功能可用，并且不出现致命错误。在上例中就可以包含入边界值1和100。而当要求客户界面友好时，就需要验证特殊字符。 如果要求更加严格一些，就要包含是否出现错误信息。而在商业要求比较高的情况下，就必须保证程序对错误有对应的解决方法。
在书写阶段，如果明确只有一遍测试。那么开发测试用例时，就不需要层次和优先级，完全可以将bug的优先级作为测试用例的优先级使用。 而在极其苛刻的时间要求下，完全可以只列一个测试大纲来作为测试的基本点使用。
例如： 在某个页面上有很多域，需要提交到下个页面，测试大纲可以这么写
- 测试各个域的显示逻辑 ，如果有必要可以列出必须显示和可选显示表
- 各个类型的域都需要测试那些数据。例如数值域要测试可接受的值，可接受的格式，不可接受的字符等等。
- 验证和对应的信息
- 上下页面的连续性
而通常不只一遍测试递归的时候，可以给测试用例分级，例如UI，Field，Function， System，Security等等。 然后在第一遍结束时就可以将各个level的一些case从下一轮测试中删除。从而减少下一轮测试的工作量。当然也有其他方法可以用于挑选case。
其实以上这些，都取决资源。你有多少时间，多少人员，每个人的负载，其他项目时间。都要包含进来才能做到上面的管理。而有时候你无法明确你的资源。这样就成为了一个勃论。互为依靠，但是都不明确。
这时候，你就需要根据以前项目的经验去判断。例如每个测试工程师每天可以执行35-40个测试用例，需要6小时。一个小时需要交给bug，还有一个小时需要交给会议，邮件等等。 这样你大概可以从你有多少时间和多少人上判断出需要开发多少测试用例。通过常规项目的测试用例的数量判断，你可以在这个时间段内做几轮，大概需要多少资源。然后通过两方面的衡量，得到一个平衡值。
例如，我现在有5个测试人员 那么每天可以做的测试用例是175-200个之间。时间大约是1个月，那么就是22个工作日。大概需要 4000左右个case。然后根据经验，这样的项目，根据最后的测试完成标准，大概有2000个case。这个数量是通过上面的方法推断出来：一共多少个页面，每个页面上大概有多少个域和button，有多少个流程，每个域个键大概需要多少个case推断出来。 这样我们知道我们在一个月内大概能做2轮测试。然后根据case的level分析，大概有多少case只做一边就可以。比如说一般的UI方面的case能占到总数的10%-20%，而在域测试大概也能有10%-20%只需要一遍。所以最后有 40%左右case只需要一遍测试。那么剩下的60%也不一定全取。
一般情况下，我们第一遍测试完后，根据bug的情况进行分析。完全可以剔除到50%的水平。而第二轮的测试速度，实际上要比第一轮快10-30%。
这样我们实际上可以制定一个三轮的计划：
- 全部100%的case
- 全部50%的case
- 全部20%的case
剩下30%case的时间，是用于做bug修复后的regression测试使用。
这样我们就可以判断出我们实际要开发的测试用例2000个是可以满足要求的。 这是最常见的形式。 如果可以完成的事4000，而只有1000个case。你就可以深化case的广度和深度。或者减少人力资源。
如果测试人员只能完成1000个case，大概有2000个case，那么就需要减少case的广度和深度。只进行一轮测试为期3天的smoke测试。或数量为20%左右的回归测试。 如果时间还是不够，要么要求加资源，要么就只指定测试大纲，然后每人负责一片，进行深度区域smoke测试。然后有一个人进行go through的广度测试。
呵呵，很短很乱，回头再改。
