APP测试流程,测试用例,计划,报告可参照（写写帮推荐）

第一篇：APP测试流程,测试用例,计划,报告可参照（写写帮推荐）

移动APP测试流程及测试点

1.APP测试基本流程

1.1.测试周期

测试周期可按项目的开发周期来确定测试时间，一般测试时间为两三周（即15个工作日），根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向负责人确认项目排期。

1.2.测试资源

测试任务开始前，检查各项测试资源。

--产品功能需求文档；

--产品原型图；

--产品效果图；

--行为统计分析定义文档；

--测试设备（ios7.1-ios9.2；Android4.0-Android6.0；）；

--其他。

1.3.日报、周报及APP上线报告

1）测试人员每天需对所测项目发送测试日报。

2）测试日报所包含的内容为：

--对当前测试版本质量进行分级（高中低）；

--对较严重的问题进行例举，提示开发人员优先修改；

--对版本的整体情况进行评估。

3）APP上线前，测试人员发送APP上线报告。4）上线报告所包含的内容为：

--对当前版本质量进行分级；

--附上测试报告（功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果）；

--总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。5）周报作为汇总本周所有的情况，以及开发人员修改情况与回归测试。

2.APP测试点

2.1.安全测试

2.1.1.软件权限

1）扣费风险：包括发送短信、拨打电话、连接网络等；

2）隐私泄露风险：包括访问手机信息、访问联系人信息等；

3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测；

4）限制/允许使用手机功能接人互联网；

5）限制/允许使用手机发送接受信息功能；

6）限制/允许应用程序来注册自动启动应用程序；

7）限制或使用本地连接；

8）限制/允许使用手机拍照或录音；

9）限制/允许使用手机读取用户数据；

10)限制/允许使用手机写人用户数据；

11)检测App的用户授权级别、数据泄漏、非法授权访问等。2.1.2.安装与卸载的安全性

1）应用程序应能正确安装到设备驱动程序上；

2）能够在安装设备驱动程序上找到应用程序的相应图标；

3）是否包含数字签名信息；

4）JAD文件和JAR包中包含的所有托管属性及其值必需是正确的；

5）JAD文件显示的资料内容与应用程序显示的资料内容应一致；

6）安装路径应能指定；

7）没有用户的允许, 应用程序不能预先设定自动启动；

8）卸载是否安全, 其安装进去的文件是否全部卸载；

9）卸载用户使用过程中产生的文件是否有提示；

10）其修改的配置信息是否复原；

11）卸载是否影响其他软件的功能；

12）卸载应该移除所有的文件。

2.1.3.数据安全性

1）当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码；

2）输人的密码将不以明文形式进行显示；

3）密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上；

4）防止应用程序异常终止而又没有删除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息；

5）当将敏感数据输人到应用程序时, 其不会被储存在设备中；

6）在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作；

7）“取消”命令操作能够按照设计要求实现其功能；

8）应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况；

9）当进行读或写用户信息操作时, 应用程序将会向用户发送一个操作错误 的提示信息；

10）在没有用户明确许可的前提下不损坏删除个人信息管理应用程序中的任 何内容；

11）应用程序读和写数据正确；

12）应用程序应当有异常保护；

13）如果数据库中重要的数据正要被重写, 应及时告知用户；

14）能合理地处理出现的错误；

25）意外情况下应提示用户。

2.1.4.通讯安全性

1）在运行其软件过程中, 如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时, 是否能暂停程序，优先处理通信, 并在处理完毕后能正常恢复软件, 继续其原来的功能；

2）当创立连接时, 应用程序能够处理因为网络连接中断, 进而告诉用户连接中断的情况；

3）应能处理通讯延时或中断；

4）应用程序将保持工作到通讯超时, 进而发送给用户一个错误信息指示有连接错误；

5）应能处理网络异常和及时将异常情况通报用户；

6）应用程序关闭或网络连接不再使用时应及时关闭)断开；

7)HTTP、HTTPS覆盖测试

--App和后台服务一般都是通过HTTP来交互的，验证HTTP环境下是否正常；

--公共免费网络环境中（如：麦当劳、星巴克等）都要输入用户名和密码，通过SSL认证来访问网络，需要对使用HTTP Client的library异常作捕获处理。

2.1.5.人机接口安全性

1）返回菜单总保持可用；

2）命令有优先权顺序；

3）声音的设置不影响应用程序的功能；

4）应用程序必需利用目标设备适用的全屏尺寸来显示上述内容；

5）应用程序必需能够处理不可预知的用户操作, 例如错误的操作和同时按下多个键。

2.2.安装卸载测试

验证App是否能正确安装、运行、卸载及操作过程和操作前后对系统资源的使用情况。

2.2.1.安装

1）软件在不同操作系统（Android、iOS）下安装是否正常；

2）软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里；

3）软件安装各个选项的组合是否符合概要设计说明；

4)）软件安装向导的UI测试；

5）软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理；

6）软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）； 7）安装空间不足时是否有相应提示；

8）安装后没有生成多余的目录结构和文件；

9）对于需要通过网络验证之类的安装，在断网情况下尝试一下；

10）还需要对安装手册进行测试，依照安装手册是否能顺利安装。

2.2.2.卸载

1）直接删除安装文件夹卸载是否有提示信息；

2）测试系统直接卸载程序是否有提示信息；

3）测试卸载后文件是否全部删除所有的安装文件夹；

4）卸载过程中出现的意外情况的测试（如死机、断电、重启）；

5）卸载是否支持取消功能，单击取消后软件卸载的情况；

6）系统直接卸载UI测试，是否有卸载状态进度条提示。

2.3.UI测试

测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足客户要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。

UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏觅功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

2.3.1.导航测试

1）按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航；

2）是否易于导航，导航是否直观； 3）是否需要搜索引擎；

4）导航帮助是否准确直观；

5）导航与页面结构、菜单、连接页面的风格是否一致。

2.3.2.图形测试

1）横向比较。各控件操作方式统一；

2）自适应界面设计，内容根据窗口大小自适应；

3）页面标签风格是否统一；

4）页面是否美观；

5）页面的图片应有其实际意义而要求整体有序美观；

6）图片质量要高且图片尺寸在设计符合要求的情况下应尽量小；

7）界面整体使用的颜色不宜过多。

2.3.3.内容测试

1）输入框说明文字的内容与系统功能是否一致；

2）文字长度是否加以限制；

3）文字内容是否表意不明；

4）是否有错别字；

5）信息是否为中文显示；

6）是否有敏感性词汇、关键词；

7）是否有敏感性图片，如：涉及版权、专利、隐私等图片。

2.4.功能测试

根据软件说明或用户需求验证App的各个功能实现，采用如下方法实现并评估功能测试过程： 1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准，若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或准则。

2)根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，如；涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。

3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。

2.4.1.运行

1）App安装完成后的试运行，可正常打开软件；

2）App打开测试，是否有加载状态进度提示；

3）App打开速度测试，速度是否可观；

4）App页面间的切换是否流畅，逻辑是否正确；

5）注册

--同表单编辑页面--用户名密码长度；

--注册后的提示页面；

--前台注册页面和后台的管理页面数据是否一致；

--注册后，在后台管理中页面提示；

6）登录

--使用合法的用户登录系统；

--系统是否允许多次非法的登陆，是否有次数限制；--使用已经登陆的账号登陆系统是否正确处理；

--使用禁用的账号登陆系统是否正确处理；

--用户名、口令（密码）错误或漏填时能否登陆；

--删除或修改后的用户，原用户登陆；

--不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆；

--登陆后，页面中登陆信息；--页面中有注销按钮；--登陆超时的处理；

7）注销

--注销原模块，新的模块系统能否正确处理；

--终止注销能否返回原模块，原用户；

--注销原用户，新用户系统能否正确处理；

--使用错误的账号、口令、无权限的被禁用的账号进行注销。

2.4.2.APP前后台切换

1)APP切换到后台，再回到app，检查是否停留在上一次操作界面；

2)APP切换到后台，再回到app，检查功能及应用状态是否正常，安卓和IOS的版本的处理机制有的不一样；

3)app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候；

4)手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候；

5)当App使用过程中有电话进来中断后再切换到app，功能状态是否正常； 6)当杀掉app进程后，再开启app，app能否正常启动；

7)出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷；

8)对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。

2.4.3.自动登陆

很多应用提供自动登录功能，当应用开启时自动以上一次登录的用户身份来使用app.1)app有免登录功能时，需要考虑IOS与安卓版本差异；

2)考虑无网络情况时能否正常进入免登录状态；

3)切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出；

4)根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示；

5)app切换到后台，再切回前台的校验；

6)切换到后台，再切换回前台的测试

7)密码更换后，检查有数据交换时是否进行了有效身份的校验；

8)支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误；

9)检查用户主动退出登录后，下次启动app，应停留在登录界面

2.4.4.数据更新

根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。

1)需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新；

2)确定哪些地方从后台切换回前台时需要进行数据更新；

3)根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要 定时更新；

4)确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试；

5)检查有数据交换的地方，均有相应的异常处理。

2.4.5.离线浏览

很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。

1)在无网络情况可以浏览本地数据；

2)退出app再开启app时能正常浏览；

3)切换到后台再切回前台可以正常浏览；

4)锁屏后再解屏回到应用前台可以正常浏览；

5)在对服务端的数据有更新时会给予离线的相应提示

2.4.6.APP更新

1)当客户端有新版本时，有更新提示；

2)当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示；

3)当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。

4)当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新；

5)当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本；

6)当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。

2.4.7.定位、照相机服务

1)App有用到相机，定位服务时，需要注意系统版本差异；

2)有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常；

3)当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务；

4)测试定位、照相机服务时，需要采用真机进行测试。

2.4.8.时间测试

客户端可以自行设置手机的时区、时间，因此需要校验该设置对app的影响。

--中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东8区时间时，再查看则显示为10：00。（另：如果时间不统一，由于semp服务器的缘故，会导致APP无法正常使用，遇到这种情况，请及时更新手机时间，或者通知开发人员修改服务器时间，谢谢大家配合）。2.4.9.PUSH消息推送测试

1)检查push消息是否按照指定的业务规则发送；

2)检查不接受推送消息时，检查用户不会再接收到push；

3)如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH。在非免打扰时间段，用户能正常收到push；

4)当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送；

5)测试push时，需要采用真机进行测试。

2.5.性能测试

评估App的时间和空间特性：

1)极限测试：在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。

--内存满时安装App；

--运行App时手机断电；

--运行App时断掉网络；

2)响应能力测试：测试App中的各类操作是否满足用户响应时间要求。

--App安装、卸载的响应时间；

--App各类功能性操作的影响时间；

3)压力测试：反复/长期操作下、系统资源是否占用异常。

--App反复进行安装卸载，查看系统资源是否正常；

--其他功能反复进行操作，查看系统资源是否正常；

4)性能评估：评估典型用户应用场景下，系统资源的使用情况。

2.6.兼容测试

主要测试内部和外部兼容性：

1）与本地及主流App是否兼容；

2）基于开发环境和生产环境的不同，检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的数据和运用是否正确；

3）与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，各种行为是否一致；

--不同操作系统的兼容性，是否适配；

--不同手机屏幕分辨率的兼容性；

--不同手机品牌的兼容性。

2.7.回归测试

1）Bug修复后且在新版本发布后需要进行回归测试。

2）Bug修复后的回归测试在交付前、要进行全量用例的回归测试。

2.8.用户体验测试

以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性修改意见提升产品的潜在客户满意度。

1）是否有空数据界面设计，引导用户去执行操作；

2）是否滥用用户引导；

3）是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导；

4）菜单层次是否太深；

5）交互流程分支是否太多；

6）相关的选项是否离得很远；

7）一次是否载入太多的数据；

8）界面中按钮可点击范围是否适中；

9）标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换；

10）操作应该有主次从属关系；

11）是否定义Back的逻辑。涉及软硬件交互时，Back键应具体定义；

12）是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计

2.9.硬件环境测试

2.9.1.网络环境测试

手机的网络目前主要分为2G、3G、4G、wifi。目前2G的网络相对于比较慢，测试时尤其要注意此块的测试。

1)无网络时，执行需要网络的操作，给予友好提示，确保程序不出现crash； 2)内网测试时，要注意选择到外网操作时的异常情况处理；

3)在网络信号不好时，检查功能状态是否正常，确保不因提交数据失败而造成crash；

4)在网络信号不好时，检查数据是否会一直处于提交中的状态，有无超时限制。如遇数据交换失败时要给予提示；

5)在网络信号不好时，执行操作后，在回调没有完成的情况下，退出本页面或者执行其他操作的情况，有无异常情况。此问题也会经常出现程序crash。2.9.2.服务器垒机或者出现404、500的情况下测试

后台服务牵涉到DNS、空间服务商的情况下会影响其稳定性，如：当出现域名解析故障时，你对后台API的请求很可能就会出现404错误，抛出异常。这时需要对异常进行正确的处理，否则可能会导致程序不能正常工作。是否有友好的提示。

第二篇：编写测试用例和测试计划

第六章 编写测试用例和测试计划

主要内容：软件测试计划；软件测试方案；软件风险分析

1.软件测试计划

1.1 软件测试计划的简介

1测试计划概念：测试计划在测试中处于中心位置，它阐述了测试准备工作和执行测试的必要条件，同时也形成了测试过程质量保证的基础。

2测试计划的作用：组织和管理测试；使测试工作和整个开发工作整合起来；资源和变更事先最为一个可控制的风险。

1.2 如何编写软件测试计划

1认识测试项目不仅仅只有单一测试计划

2避免不分析直接进行测试阶段日程安排

3避免测试任务的安排超前于开发任务

4避免有些系统测试类型无法按期进入测试

5不正确的变更测试计划

6测试计划里明确更新周期和暂停测试原则

7测试计划不是一成不变的1.3 测试计划包括：简介，目的，范围，测试策略，进度，缺陷的严重程度的定义，风

险分析。

2.软件测试方案

2.1 软件测试方案的概念

软件测试方案描述测试的特征，测试的方法，测试环境的规划，测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。即包括以下几点：

 明确测试策略（黑盒，白盒，灰盒等）

 细化测试特征

 测试用例的规划

 测试环境的规划

 自动化测试框架的设计

 测试工具的设计和选择

2.2 软件测试计划于软件测试方案的区别

 测试计划是组织管理层面的文档。测试方案是技术层面的文档。

 测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，测试方案明确“怎么做”

 回报的对象不同，测试计划向领导汇报，测试方案是组员共享该文档

3.软件测试的风险

 软件需求风险

 人员的风险

 测试环境的风险

 测试工程师对产品的业务不熟悉

补充：

回归测试：把以前检查过的已经修复好的缺陷，拿来另测看有无带来新的缺陷 反侧：把开发人员已经处理的缺陷拿来测，看是否修复

第三篇：可复用测试用例研究

可复用测试用例研究

0、引言

软件测试的关键环节是设计和执行测试用例。测试用例的质量与测试人员的技能、经验以及对被测软件的理解密切相关。如果测试人员对被测软件不甚了解，很难在短时间内设计出有效的测试用例；有的测试用例虽然面面俱到，但冗余现象严重，浪费时间、人力和物力。

随着软件复用技术的发展，测试复用引起了人们的极大关注，特别是对测试用例复用的研究。所谓测试用例复用，就是对一个软件的已执行的测试用例，将其不同程度地应用于该软件新的测试中或其他软件的测试中。测试用例复用是可行和必要的，表现在：1）软件测试对测试人员的经验和技能要求高，通过复用，可提高测试人员技能，解决其经验不足的问题，同时提高软件测试质量；2）软件测试是当前保证软件质量的一种有效手段，但其占用软件开发周期时间长，通过复用，可避免大量重复性劳动，缩短测试周期，提高效率；3）伴随着同一个软件的生存周期，软件经历了单元测试、集成测试、确认测试和系统测试，这一过程产生了成百上千的经过执行确认的高质量的测试用例，在前一测试阶段执行过的一些测试用例可在后续测试阶段中使用，包括在回归测试、维护阶段的版本升级和纠错测试中都可使用；4）同一领域或相同系统架构的不同软件，存在着测试用例复用的可能性，且随着软件复用技术的发展，很多有价值的组件可供使用，这也使测试用例复用成为可能。

由于软件的抽象性、复杂性和多样性，使得软件测试成为一项复杂的、需要智慧和创造性的工作，要实现测试用例复用并不是一件简单的事情。但测试用例复用是软件测试发展的一个必然趋势。本文从可复用测试用例的评估、描述、设计和使用四个方面对测试用例进行了系统研究，提出了可复用测试用例应具有的特性，为评估测试用例的可复用性提供准则；给出了可复用测试用例的系统描述要素，为规范和使用可复用测试用例提供了基础；提出了面向复用的测试用例设计过程和基于复用的软件测试模型，为测试用例复用提供了方法和实现策略。本文的研究内容在某类实时系统软件测试中进行了应用，证明是有效和科学的。

1、可复用测试用例特性

文献中定义了可复用测试用例的六个特性：通用性、简洁性、独立性、有效性、灵活性和检索方便。本文对大量测试用例和测试用例复用的各种应用情况进行了分析，认为可复用测试用例应具有以下特性：通用性、有效性、独立性、标准化和完整性，它们对可复用测试用例而言是充分的也是必要的。上述特性可作为评判一个测试用例是否具有可复用性的准则。

1）通用性。通用性是指可复用测试用例并不局限于具体的应用，不过分依赖于被测软件的需求、设计和环境，能够在某一类型、某一领域的相似软件的测试中广泛使用。

当前绝大多数的测试用例都不具有通用性，这样的测试用例只能用于被测软件和其当前环境，不可能用到其他软件中。

2）有效性。测试用例的目标是发现软件问题，因此，可复用测试用例也必须是能够发现软件问题的，并且是可靠和高效的。

3）独立性。可复用测试用例的独立性是指，对于测试需求R1和R2，测试用例集分别为cl和C2，c1和c2的交集为空，并且，每个可复用测试用例能够独立运行。测试用例是否具有独立性，决定了测试用例可复用能力的强弱。

如果测试用例之间存在着相互联系，或测试用例的运行环境取决于其他测试用例的执行状态，那么，其中的测试用例不能复用时，与之相关的测试用例的可复用性也不复存在。

如何将测试用例的关联性降至最低，是设计可复用测试用例必须解决的问题。首先，每个测试用例的目标应尽量独立、单一；其次，测试用例不包含过多的具体实现细节。

4）标准化。测试用例通常用自然语言来描述，充分体现了测试人员的创造性和个人风格。但对于可复用测试用例，太多的个人风格不利于其他测试人员对测试用例的理解，必然影响其复用。因此可复用测试用例的标准化程度也反映了其易理解和可复用的能力。为此可复用测试用例应遵循统一或规范的格式或结构，规范的命名规则，使用术语、用简明、易懂、无歧义的语言来描述，并且具有详细的文档。

5）完整性。每个可复用测试用例应包括全部应有的要素，不能有缺失，并且每个要素的描述是充分的。文献规定了测试用例应包括的要素，但对于可复用测试用例而言是不够的，应加以补充。

2、面向复用的测试用例设计过程

当前，测试用例设计都砥向不同的具体应用，与被测软件是紧耦合的。考虑到复用的目的，测试用例的设计应不同于以往。本文提出了面向复用的测试用例设计过程，给出了设计过程中应实施的各项活动，主要包括被测软件（系统）共性分析、测试策略分析、设计测试用例、测试用例评审、测试用例执行和修改、测试用例入库共六个步骤，如图l所示。该过程对现有测试用例的复用处理也是适用的。

2．1共性分析

同一领域或相同架构的软件存在着共性需求。通过共性分析或领域分析，并结合任务分析等方法，梳理出被测软件所属领域或相同类型软件的相同或相似特征及需求，例如，工作流程、共性场景、功能、性能等，从而挖掘出可复用点，例如，相对独立且类似的功能、相同的构件、相似的业务流程。该步骤实质上要抽象出被测软件应用领域的概念，类似于设计模式中的共性分析。

这项活动需要领域专家、软件专家、设计人员、测试专家等人员参与。

2．2 测试策略分析

针对共性分析挖掘出的可复用点，分析各复用点的测试策略，包括测试类型、测试方法、测试环境、测试覆盖率等内容。

2．3 设计测试用例

根据前两个步骤的分析结果对每个可复用点设计测试用例。在设计时，应使所设计的测试用例满足可复用测试用例的特性，特别要注意以下几方面：

1）每个测试用例的目的要尽量独立、单一，以满足可复用测试用例独立性的要求。

2）对一项明确的测试需求，应关注“测试思想”，即测试思路，以满足可复用测试用例通用性要求。当前，为了使测试用例是可操作的、可复现的，一般都要求测试用例要设计得非常详细，例如，每一操作步骤的输入数据、操作等信息都要具体描述。这样的测试用例和被测软件是紧耦合的，只有在同一软件的回归测试和版本升级维护测试中可能会复用到，在其他情况下复用是很困难的。在设计可复用测试用例时，测试用例的可操作性、可复现性要弱化，即，对测试用例进行通用化处理，排除和特定应用相关的具体信息，以降低测试用例和被测软件的相关度，例如，参数化或公式来代替具体的输入数据，抽象出共同或关键的操作等。但为了加强测试用例的可操作性和可复现性，在设计可复用测试用例时，应对一些差异之处进行预测，即进行可变性分析mJ，并用适当的方式描述出来。只有这样，当复用该测试用例时，测试人员可以在原有基础上对其进行完善，使其能够满足特定的测试情况。

3）将设计出的测试用例用规范而精炼的自然语言清晰地描述出来，保证其完整、标准。软件评测组织或机构应定义本组织使用的规范和术语。

需要说明的是，对于一个具体的测试项目，因为面向复用，所以以上所设计的测试用例可能不完全满足被测软件的测试需求，为此，应针对被测软件的需求补充新的用例或对现有用例进行充实完善。

2．4 测试用例评审

可复用测试用例设计完成后，组织领域专家、软件专家、测试专家、软件设计人员对其进行评审，确保所设计的测试用例是正确的，满足可复用测试用例的特性。

评审同时应关注以下几点：每个共性需求的测试策略是否合适；每个共性需求是否被可复用测试用例所覆盖；每个共性需求是否被可复用测试用例进行了充分测试，例如，某一共性功能，不能仅测试正常情况，还应测试边界和异常情况。如果测试用例没有通过评审，则需要重新回到设计测试用例步骤。

2．5 测试用例执行和修改

将通过评审确认的测试用例用于被测软件，寻找其不正确或不完善之处并纠正完善。

2．6 测试用例入库

将经过测试执行确认的可复用测试用例统一纳入测试用例库中，供测试人员在后续软件测试或以后的项目中查询使用。测试用例库应是按照一定的组织结构形成的测试用例集合。

3、基于复用的软件测试模型

文献给出了一个测试用例复用流程：首先定义被测软件的测试用例类型；再根据所定义的从测试用例库中检索是否有适合的用例；如果可以找到，则提取出测试用例，程序结束；否则，需要设计测试用例，验证其正确性，如果正确，则添加到库中以便再次复用，程序结束。这个流程只适用于完全不需要进一步完善的可复用的测试用例，由于可复用测试用例的通用性，该流程显然不适用于实际情况。文献[12]给出了另一个测试用例复用模型，该模型建立在没有测试用例库的基础上，且将测试用例分为内外两类，本文认为这种划分是不必要的。

本文提出了基于复用的软件测试模型。该模型面向一个软件测试项目，但不同于以往的测试模型，主要表现在模型中融合了面向复用的测试用例设计以及对测试用例的复用上，模型如图2所示。

“测试需求分析和共性分析”中，测试人员一方面要根据被测试软件需求分析、设计说明等文档或软件代码梳理出被测软件的测试需求，另一方面要针对被测软件所属领域及软件类型进行面向复用的共性分析。

“定义测试策略”中，测试人员根据测试目标和上一步的结果定义测试策略，包括测试方法、测试类型、测试环境等内容。

“定义测试用例”中，测试人员根据测试需求和共性分析结果及所定义的测试策略，定义所需要的测试用例。这里定义的测试用例只是给出一个测试用例名称及其测试目的。

“查询可复用测试用例库”中，测试人员用多字段检索功能从可复用测试用例库中查找满足要求的测试用例。对测试用例的查询是不确定的，查询结果通常是一个相似的测试用例集合。如果可以找到，则“提取测试用例”并对其进行分析，确定出最合适的测试用例；如果没有，则“设计”新的测试用例。找到的测试用例，往往因其通用性，并不能完全满足测试需求，要对其“补充完善”。在设计新的测试用例时，要考虑到上节“设计测试用例”要求。

在传统模型评审的基础上，本模型“测试评审”还包括对新设计的可复用测试用例是否满足要求的审查；对复用的测试用例是否补充完善的审查；所有测试用例是否满足被测软件的测试需求的审查。

“执行测试用例”中，测试人员将所设计的测试用例逐用例逐步骤地执行。在执行过程中，认真观察并详实地记录测试过程、测试结果和发现的错误，形成测试记录。如果在执行过程中发现测试用例有不正确和不完善之处，则纠正；如果测试用例不充分，则补充。

测试人员在“测试总结”中对所有测试结果进行分析总结，将通过测试执行验证的可复用测试用例放入可复用测试用例库中，以便后续复用。

该模型的优点为：1）对已有的可复用的测试用例进行了复用，避免了大量的重复性工作，提高了测试质量和效率；2）考虑了面向复用的测试用例设计，避免再次产生大量的不可复用的测试用例。

4、可复用测试用例描述要素

测试用例的输入、操作、预期结果和评估标准、前提条件是测试用例不可少的要素，但对于可复用测试用例而言，这是不够的。本文在文献规定的测试用例要素基础上，增加了新的内容。从而从多个角度完整地对可复用测试用例进行了描述，为可复用测试用例的标准化提供了模板，为建立可复用测试用例库并对测试用例实施有效管理提供了基础，也为测试用例检索提供了多个检索字段。

1）测试用例名称：名称能清晰且简洁地表达测试用例的功能。

2）ID：该ID在数据库中是唯一的。

3）版本号：用于测试用例的版本管理，每个测试用例应按照定义的规则设定一个版本号。

4）测试需求：对要验证的测试需求的描述和测试要求，例如，功能、性能等。

5）测试阶段：被测软件所处的测试阶段，包括单元测试、部件测试、配置项测试、系统测试，或者单元测试、集成测试、确认测试、系统测试。

6）测试方法：黑盒测试中的等价类划分、因果图，白盒测试中的语句覆盖、分支覆盖等。

7）测试类型：有功能测试、性能测试、安全测试、用户界面测试、接口测试、安装测试等，可选择多项。

8）应用领域：说明被测软件所属领域。

9）系统类型：描述被测软件所在系统的架构，如B／S、C／S、嵌入式软件、非嵌入式软件等。

lO）软件编码：描述被测软件的编码语言。

11）测试环境：描述该测试用例执行的软硬件环境。

12）前提条件：测试用例执行前必须满足的条件，或称之为约束条件。

13）测试输入：对输入值的抽象描述或参数化描述，不能是具体的数据值。

14）操作步骤：说明执行该测试用例的一系列相关联的操作。

15）预期结果：说明测试用例执行后的期望结果。每一操作步骤也可有自己的预期结果。

16）评估标准：描述评判测试用例执行中产生的中间和最后结果是否正确的准则。

17）附件：对测试用例附加的一些描述信息，可任意表示，例如文本、图像、模型、与测试用例有关的一些文档，方便测试人员进一步理解测试用例。

上述要素对可复用测试用例而言是必要的，不可缺少。而且要注意的是，测试人员在描述测试用例各要素时，应尽可能地使用规范语言和术语，以使测试用例规范化和易于理解。

5、应用

本文的研究内容在航天测控领域进行了应用。在航天测控计算机系统中，有一类实时系统软件。在不同型号任务中，该类软件的功能、性能、接口和运行环境都有区别，但不同任务对该类软件有共性需求。更多细节信息的子带图像予以了更多地保留，恢复了图像的边缘轮廓，而且经图像分解后的子带图像含有相同尺寸的大小，也更易于处理。本文算法的缺陷则是执行速度较慢，不如前三种算法，而且对分解后所得到系数处理也比较简单，这些都需作进一步的改进。

第四篇：做好测试计划和测试用例的工作的关键是什么？

一、测试计划的有效性和全面性

无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。

1．测试计划的要点

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。

2．制定测试策略

制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。测试策略可以分为：

基于测试技术的测试策略，根据软件系统的技术构成和层次结构，着重考虑如何分层测试、选择哪些测试工具、如何将白盒测试和黑盒测试有机地结合起来等。

基于测试方案的综合测试策略，根据测试的目标和范围，着重考虑如何更好地满足测试需求、如何让功能测试、适用性测试和兼容性测试等进行有机结合、如何充分利用测试资源、如何更有效地完成回归测试等。

为了更好地制定好测试策略，要做到：

全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；

基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；

根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；

需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。测试不足意味着让用户承担隐藏错误带来的危险；同时反过来看，过度测试则又会浪费许多宝贵的资源或耽误软件产品的发布时间。

3．确定测试范围

测试主要依据 “产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：

优先级最高的需求功能

新增加的功能和编码改动较大的已有功能

容易出现问题的部分功能

过去测试不够充分的地方

经常被用户使用的功能和配置（占20%）

4．所需资源和日程安排

为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。

在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

5．编制测试计划的技巧

要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：

让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；

测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；

测试项目的输入、输出和质量标准，应与各方达成一致；

建立变化处理的流程规则，识别出在整个测试阶段中哪些是内在的、不可避免的变化因素，加以控制。

6．测试项目计划的评审

测试项目的计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。

测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。

二、测试用例在测试活动中的作用：

1.强化测试用例在测试活动中的作用

测试用例在实际中没有起多大作用 , 在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中等等。

为何如此？ 根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，其实，从三个方面具体来说：

1）测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢？答案是肯定的！

2）制定了完备有效的测试用例，为什么不按测试用例执行测试呢？首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做；其次是个别测试人员投机取巧心理作祟的表现。

3）测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些 测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试；如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。

2.改进测试用例执行过程

那么究竟如何做，才能尽量避免上述问题呢？

我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将问题扼杀在萌芽阶段。

1）软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢？

项目的测试负责人和测试工程师在 需求阶段 的任务有：

a.参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。

b.全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

2）软件分析设计阶段：

l 测试人员除制定测试计划书等基本工作外，还有一个相当必要的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。（之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因）。

l 测试人员更要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等，这些信息都是描述性的，无须具体数据；它的作用是据此编写测试用例，以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。

l 当然该文档不是非要不可，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇！

3）软件开发阶段： 编写测试用例。应该遵守的原则是：

n 首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。编写测试用例时，基本上就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上描述以何种数据校验功能点；如此可实现趋向最大需求覆盖率。

n 其次，从数量来讲，一个多于半年开发周期（指从编码开始直到提交客户的时间段）的软件系统，它的用例数量不要低于 4000 个，甚至更多！（IBM 等大公司测试过程的人士会认为 4000 还是很少的数目。我们试想，对于一个中小型软件系统，如果设计出 5000 个用例，那它的测试覆盖率还怕不高么）！

n 再次，如此众多测试用例的管理问题。是的，最好是需要测试用例管理工具软件。以 word 或 excel 来编写测试用例也可以。）测试用例 格式上一般内容以外的几个要点：

l 制定适合本公司的测试用例模版；

l 是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法（分手工 / 自动两种）；

l 是测试用例要有 状态跟踪，可根据用例执行状态索引用例（测试通过、测试失败、测试中断等）；

l 是执行失败的用例要 链接到相应的缺陷报告，如有根据缺陷报告检索测试用例的试图更妙，可评估该缺陷影响范围的大小；

l [FS:PAGE] 是测试用例的修改，以及每个测试周期的运行都有 日志记录，以便后期追踪

和新员工参考；）软件测试阶段，测试负责人划分不同的测试阶段（如集成测试、系统测试、回归测试、性能测试等），再划分不同的子测试周期（如前两个星期做 冒烟测试，测试方式是手工 / 自动，测试版本是 **，测试环境是 **，包括服务器端与客户端等；接着做第一模块功能测试；如此顺次。），再为项目组测试人员分配测试用例（通常原则是每个人负责几块区域的测试任务），测试人员则按照详细的用例文档去执行测试，测试失败则提交软件缺陷报告。这里要遵循的几个原则是：

A）有健全且严格的体制保证测试执行者严格按照测试用例执行测试。这并不妨碍测试者创造力的发挥，因为前期用例的设计和编写就是项目全体测试人员智慧的结晶！我们一直苦苦追寻众多测试工程师加班加点辛苦工作的原因，其实大都发生这一阶段；如此实施，即便没有解决根本问题，也会大大提高测试执行效率。

B）如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。

C）测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。

D）测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态 不断验证软件功 能点。

E）通过缺陷管理工具来 管理软件缺陷 ；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。

F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。这里要提的其他几个基本原则是：

l 是选择恰当的测试工具品牌，并要求提供培训；

l 是项目的自动化测试工作有专人负责跟踪，以保证工作质量，他们可不参与日常测试；l 是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试负责人，负责人同样跟踪其工作状态；

l 是选择最简单、最重用的测试用例使用自动测试方法；

l 是使用工具厂商提供的测试框架编写脚本，千万别采用单纯录制回放的方式，要开发出健壮且重用性强的测试脚本 ；

l 是有专人更新脚本，也有专人跟踪自动测试结果；

l 一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；

l 是在多人协作开发测试脚本、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本。）由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。）软件验收阶段 ：除了提交软件测试评估报告（各种类型测试结果的评估都应有报告）这些基本工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试。即便您开发的是项目软件--提交客户后没有新版本--那也需要后期维护，维护阶段需要重新测试某功能点，然而用例如果不准确，碰巧又是一个

新员工来做，那就死翘翘了！）其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是购买工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行；以此可见，我们的测试工程师需要培训的空间还很大。

3.总结

综上所述，我们得出结论--测试用例在测试中没起到应有的作用，是因为测试用例编写质量不高，覆盖不够，执行不利；测试执行时不遵循测试用例，执行后不更新用例库，是测试部门的整体工作流程不健全、不规范。

第五篇：做好测试计划和测试用例工作的关键

做好测试计划和测试用例的工作的关键

做好测试计划和测试用例的工作的关键（转）

对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已

所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用

这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）

测试计划中最重要的内容包括： 进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了）写好测试计划的关键在于：充分了解你的团队的整体实力和团队中每个成员的特点充分理解为当前软件制订的整个研发活动过程

带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。

写好测试方案的关键在于：有一个合理的测试计划熟悉相关业务深入体会用户的实际需求

这个不想多解释了，不难理解。

至于测试用例，看到上面不少朋友认为关键在于理解用户需求。

其实理解用户实际需求是一切的根本，并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切。

当然，如果有一份好的需求和设计文档的话，什么事情都解决了。可是现实往往是不存在这样的文档的。

所以我的看法是：对业务理解的深入程度经验有自己的文档

前两条不解释了。自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list）。另一个就是自己测试模块对应的相关需求和设计文档。服务器上的标准文档拖到本地来并且记得及时更新。然后在测试过程中，需要什么内容文档上没有，最直接的方法是和开发人员沟通。（其实我很反对这么做。你想，按开发人员自己说的标准

去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么„„应该是和客户和designer去沟通，可惜一般没有这条件-_-）任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来最好，不过通常是没这可能性的。

补充说明：lz最后提到的“完全凭借自己的经验在执行测试活动”不如说是完全凭借自己的感觉在执行测试活动。

项目需要的用例详尽程度可以商量，但是必须要有。如果进度很紧，可以用一部分用例加上check list进行测试活动（比如很多日本外包项目的UI测试，相当一部分可以用check list来代替具体的用例，效果并不差)

完整的大纲应该是：

目录

测试计划标识符

目录表

参考文献

词汇表

介绍

测试项

软件风险问题

待测特征

不予测试的特征

方法

测试项通过/失败准则

挂起准则和恢复需求

测试交付物

测试任务

环境需求

职责

人员安排与培训需求

进度表

计划风险与应急措施

审批