东软测试管理系统 Test Management System，简称TMS。
TMS有不同的版本，目前提供外部用户试用期免费试用。
东软的TMS可以进行全生命周期软件测试过程专业化管理。为主管领导、项目管理者以及项目成员，提供不同的管理和应用视窗，提供便捷服务和高效应用,为组织积累测试资产，为全员提供知识分享的平台。TMS基于B/S结构，无需客户端安装。
主要特色如下：
—灵活的、可定制化的缺陷管理流程，满足不同成熟度的各类组织使用；
—强大的统计分析功能，涵盖项目级、项目群级及组织级三大类70多种报表展现，满足不同层级管理者要求。
—简单、高效的自动化测试管理组件，极大降低执行人员的技术要求，可帮助组织迅速开展自动化测试活动。
—实用的财富库管理功能，可对典型缺陷、用例财富及各类文档财富进行专业化管理。
—灵活的定制化功能、便捷的二次开发接口，能够迅速满足不同体系框架下的使用要求。一、游戏软件与通用软件的区别 a) 通用软件的需求明确，游戏软件需求理想化 i 通用软件中用户每步 *** 作的预期结果都是明确且有规范可参考的，而网游中并 不是所有的需求都有一个明确的预期结果，拿技能平衡性来说，我们所谓的平衡也只是相对的平衡，而非绝对的平衡。没有什么明确的参考参数。只能根据以往游戏的经验获得一个感知的结果。 ii 网络游戏中的某些功能是有预期结果可参考的。例如组队、交易，而另外一些 带有策划创意的功能，却是根据策划个人的理解，来确定其预期结果的。人的思考力都是有限的，所以不能保证在他的创意中会考虑到各种各样复杂的细节。也不能够保证这个创意就可以完全被用户所接受。 当你作为游戏测试人员时，很多时候你需要做的不仅仅是验证功能。也需要帮助开发者和用户找到一个互相容忍的平衡点。游戏软件的测试员带有对策划需求的怀疑，力求通过自己的努力在玩家和开发者之间将可能产生的矛盾减小。 b) 通用软件开发过程中需求变更少，游戏软件开发过程中需求便更快 i 通用软件的使用人群和软件的功能针对性，决定软件从开始制作就很少再有新 的需求变更。而游戏软件，为了满足玩家对游戏的认可度，策划需要不断的揣摩玩家的喜好，进行游戏功能的改进。加之网游制作本身就是一个庞大复杂的工程，开发者不可能做到在开发的前期，就对游戏架构及扩展性做出最好的评估。所以导致为了满足用户的需求而不断的进行一些基础架构的修改，基础架构的修改必然导致某些功能的颠覆。所以就出现了，游戏开发过程中的一个恶性循环，当基础架构修改到满意了，玩家的需求又有了新的变化，随之而来的又要进行新的调整，再进行新的修改。最终导致了游戏软件的开发周期不断加长。任何一个有经验的团队，对于每一个影响基础的改动都应该做出正确的评估。 二、网游有哪些测试内容 a) 性能 i 客户端性能 ii 服务器端性能 1 服务器 2 数据库 iii 网络 b) 功能 i 从运行完gameexe打开游戏界面后可进行的各种 *** 作、玩法 ii 界面 iii 音乐 c) 自动化 i 测试工作组织实施中需要的工具、软件、平台的开发 ii 自动化的回归测试作用：游戏中基础的、变动不大的、出错率高的、可进行 checklist重复测试的功能、性能等自动化是一个好方法 iii 任何时候自动化都取代不了人脑，它只是将一些重复性的劳动从我们测试人员 身上去掉，让我们有更多的时间做更有意义的事情，如果你觉得你做一件事情是重复的，且有规律可行的，不防考虑自动化 三、游戏中针对功能性测试测试用例编写浅谈
国际体验设计协会IXDC 历届大会精彩集锦
游戏用户体验大会 互联网产品大会 交互设计体验周
作者：sunli 制作时间：2008年10月份 个人空间地址：
[url]>测试方案，大概包括哪些方面
人员、资源、进度、测试目标、测试范围、测试完成标准等
软件测试方案设计 10分
OA办公系统自动化测试方案
办公自动化系统擅长处理类似公告、公文等流转类型的行政办公类应用需求、设计及相对独立的个人相关资料、通讯录、记事本等个人事务类的需求、设计。另外办公自动化系统软件的权限管理是其不同于其他应用软件的另外一个特点。系统需要为使用人员提供设置不同的权限和访问许可的功能，管理员可以通过调整各功能模块的访问权限，设置一般用户某些功能可以用，某些功能不允许用；并为员工创建、注销帐号及访问权限。提高了企业系统的资料的安全度，阻止非授权人的非法进入系统。针对这些特点我们在测试时主要着重于对流转型的行政办公需求、设计和对独立型的个人事务需求和设计来组织测试工作。
一、测试方法：
从整体来OA办公自动化系统一般包括公文管理、网上审批、个人信息管理、以及公共信息管理四个大的模块，在对每个模块的测试过程中我们将针对对每个模块的需求、特点分别采用不同的方法，具体在以后的测试过程中我们将采用以下方法：
1、公文管理、网上审批：
公文管理和网上审批都是以流转型业务为主，在此对于此类功能点我们将以收文管理为例，简要说明我们测试过程所采用的方法方案。
例如oa公文管理主要对公文进行登记和处理。在登记收文过程中直接输入，并将登记后的收文送领导阅读或批示（批示的流程完全可以根据用户的需要自己定义，也可以使用系统管理员已经定义好的公文批示流程），处理结束后将文件进行归档。管理人员可以对收文处理全过程进行监督、催办、重定位，也可以随时进行文件流程跟踪及查看其所有领导的批示意见、批示时间。针对这些情况，在进行测试分析和设计时，我们首先按照上面提到的根据现成的公司体制进行分析和设计的测试数据，然后将各个领导是否 的情况区分开来。测试过程中我们准备了两套数据：
1) 领导不
领导不 的情况， 相对较简单， 即每个领导只负责一个批示。
2) 领导
领导 的情况，即每个领导可能负责不同过程中多个批示，这是流转型模块测试的一个难点，因此在测试过程中我们对此进行了重点测试。
2、个人事务
个人事务通常包括：待办工作、日程安排、个人资料、个人通讯录、个人记事本、外出声明等模块。例如批阅各部门上报的各种公文，评阅同事交流的各种文件内容，起草各类报告，查看个人的活动日程、外出等安排，同时系统能自动提醒待办事项。
以个人通讯录为例，用户可将朋友、同事名片登记并进行管理查询。每个人只能看到自己的通讯录，通过对所有个人通讯录的查询，自己可很快地找出所需要联系的人员信息，并方便地通知他们参加会议或发送邮件等等。在进行测试分析、设计和执行中我们将特别考虑以下几点：
1) 新建或修改通讯录时对于输入重复的信息系统是否给予提示警告；
2) 新建或修改信息时个人维护的私有名片是否能被其他人看到或修改；
3) 个人删除私有通讯录信息时是否影响到其他用户的通讯录信息；
4) 需要联系的通讯信息主人联系时，是否可以正确联系上，其联系内容是否显示正确；
3、公共信息管理
公共信息通常分两部分：一部分为一般用户的浏览 *** 作，在此用户只能浏览、查阅。一部分为管理级别的用户，他们有权限添加、修改、编辑、删除相应的功能信息
在进行测试分析、设计和执行时要重点考虑：
1) 对规章制度的权限 *** 作（管理员用户和一般用户）
2) 规章制度的套红头 *** 作。
3) 规章制度浏览时的不可修改性。
4、系统基础信息
基础服务包括：人员注册、部门设置、组织结构调整、OA基础信息维护等模块。在此以基础数据维护
软件测试设计的测试方案应该是怎样的额
软件测试中有测试方法，测试计划等，此处说的测试方案是否是指测试计划呢
对于一个软件的测试计划，具体指需求分析，测试策略，工作量估算，进度安排，度量标准，风险评估，子计划制定，计划评审。测试计划包括的内容要素也可概括为：软件测试的范围、策略、需求、资源要求、人员要求、进度，软件测试停止的方法，测试用例设计的方法，测试中潜在的风险和问题区域以及角色与职责。
若你此处的测试方案指的是测试的策略的话，应该有以下几项内容：测试方法、测试工具、测试用例设计方法内容的选择则，测试方法也就是那些黑盒白盒等，测试用例的设计方法可以是等价类划分，边界值等等。希望有所帮助。(^__^) ……
测试方案如何写
谢谢！我并没有说明测试方案就是提取功能点，只是基于功能流程，提取测试点，不知道怎么写测试方案
软件测试方案怎么写啊？有什么格式DOC文档的！
这里有些恢复软件的介绍，可以借鉴下，找个相对应的
测试过程：
①一个分区格式化后塞满文件，全部删除后进行数据恢复。
②把这个分区再次格式化后再恢复。
③把这个分区删除后进行数据恢复。
PS：我硬盘最后有一个隐藏的150M左右的分区，是平时用来在DOS下作业的。为了节省测试时间和方便 *** 作，就使用了这个分区进行测试。
测试环境：
主板 ASUS P4P800-X
CPU C4D 24
内存 512M DDR333
硬盘 Maxtor 120G
测试结果：
①几乎所有软件都能够对删除的文件进行恢复，但部分软件恢复后的数据有问题。
②只有部分软件支持对格式化后的硬盘进行数据恢复。
PS：由于时间原因我没有进行全面的测试，只对是否能有效恢复文件做了简单测试，根据测试结果把这些软件分位三类，只对能够进行格式化后恢复的软件做了详细比较。其他两类没有做比较，因此不做说明。
一、只能恢复已删除文件
1 Active File Recovery
一个简单易用、功能超强的数据恢复工具，使用它可以恢复在 Windows 中丢失或删除的文件和文件夹。它不仅可以恢复分区格式化或丢失后的数据，而且可以恢复被损坏、病毒或目录结构导致丢失的数据。所有类型的硬盘驱动器：IDE、ATA、SCSI 和软盘；可移动设备：pactFlash、SmartMedia、Secure Digital/MultiMediaCard、Sony Memory Sticks 等；
格式化恢复：无 速度很快，只有一种扫描方式，对中文支持不好，带中文名字的文件大多无法恢复（中文和英文结合时，如果中文在前，无法恢复；如果英文在前，可恢复，丢失中文部分），中文Word文档恢复后部分成乱码。扫描到的文件以原来目录结构方式显示。
2 Drive Rescue 19d
一款优秀而且免费的磁盘数据拯救程序，它能恢复驱动器（例如硬盘）上误删或遗失的数据，即使已经失去分区表或硬盘已被快速格式化或者遭遇系统崩溃等情况，找回驱动器重要文件系统信息如分区表、引导记录、FAT、文件/目录记录等。当然对于物理损坏的硬盘它也无能为力。Drive Rescue支持FAT 12/16/32分区和Windows全系列 *** 作系统以及双硬盘。
格式化恢复：无
功能一般，扫描速度中等，扫描效果还不错，对中文和特殊字符文件名的文件都能够很好的支持。恢复时要到菜单里选择保存，或者用Ctrl S。特色是能够查找丢失的分区并修复。
3 DISKMAND
Winternals公司的又一款力作。它是基于WINNT内核平台的数据恢复软件，支持FAT16/FAT32/NTFS，支持SCSI、RAID，支持长文件名，还可以恢复NTFS加密的软件，可以说，只要硬盘主数据区没被破坏，无论分区表有无，或者损坏的多么严重，他都可以完整的恢复几乎所有的文件，即使文件区被损坏，也能把剩下的部分，恢复到不同程度，这个是其他软件无法做到的。
格式化恢复：无
这个软件没有单独发行版本，是包含在ERD系统里的恢复软件，当年做光盘时专门测试过它。扫描速度还不错，可以选择扫描已经删除的文件，或者是丢失或损坏的文件， *** 作比较傻瓜化。对中文以及深层目录支持的比较好，可以恢复到最原始的状态。
4 Filerecoveryangel
一款文件恢复工具，它能够帮助你从格式化成FAT12、FAT16、FAT32、NTFS文件系统的磁盘中恢
解决方案测试和软件测试有什么区别
解决方案测试是针对的解决方案，这个解决方案也许能解决问题，也许解决不了问题，所以要进行测试以验证其能否真正解决问题，比软件测试更有针对性和目的性。
软件测试是针对一个软件系统，可以包括软件的功能、性能、安全、易用性、兼容性等等，比某一个特定的解决方案的测试要更全面。
软件测试计划中的测试策略怎么写
测试计划编写基本策略
1、测试计划编写依据：项目计划、项目计划的评估状态以及业务的理解
2、测试计划编写时间：尽早开始。原则上应该在需求定义完成之后开始编写测试计划，对于开发过程不是十分清晰和稳定的项目，测试计划也可以在总体设计完成后开始编写。
3、测试计划的编写与实施：测试计划应该由测试小组组长或最有经验的测试人员来进行编写，测试计划由测试人员来实施，测试人员可以对测试计划进行相关人员确认后进行调整。
4、测试计划的变更：测试计划是一个发展变化的文档，会随着项目的进展、人员或环境的变动而变化，确保测试计划是最新的而且依据测试计划执行测试工作。
5、测试计划的优先级别：没有谁可以保证通过测试后的产品没有缺陷，也没有公司会允许无休止的测试。好的测试是一个有代表性、简单和有效的测试，在测试计划中，必须制定测试的优先级和重点。
6、测试计划的评审：测试计划需要由高级测试人员或测试组长制订，在经验不足或条件限制的软件测试计划的制订时，需要多名测试人员共同制订和修正（1）软件项目经理负责评审测试计划的方向正确性和软件开发按照总体设计方案实施(如有改动，需通知测试人员修改计划)，并保证软件具有可测试性
（2）QA人员评审测试过程的正确性和能够按照计划要求的正确实施
（3）高级经理评审测试计划的导言和范围的正确性参考下面方法
一、分别在不同电脑上安装不同版本的IE
优点：准确性高，三台电脑分别安装IE6、7、8，显然测试得出的结果是最准确的。
缺点：浪费服务器资源，测试人员 *** 作麻烦，需要不断切换测试机器。
二、在一台电脑上安装IETest
优点：能90%的模拟出不同浏览器的渲染效果，只需安装在一台测试机器上即可。
缺点：
1)如果测试机器安装的为IE6或IE7，那么IETest不能模拟IE8
2)如果测试机器安装的为IE8，那么IETest才能模拟IE6、7、8
3)测试出的渲染效果与浏览器得实际效果存在差异，不一定准确
三、在IE8上安装IE Develop ToolBar
优点：通过此工具可以模拟IE7的渲染效果，拥有有IE7、8的真实渲染效果。
缺点：
1)无法模拟IE6的渲染效果。
2)一定要在一台测试机器上安装IE8才能使用。评审过程的规范性：
1、评审的准入；
2、评审的准出；
3、评审这个过程的一些要求：
如哪些评审员参加？计划性如何？使用检查单？预审情况？缺陷发现情况？缺陷修复情况？总结分析情况及评审结论？
4、识别一些改进机会，记录NC
自己整理吧 下面是模板
2楼
性能测试目标中应对响应时间和处理能力指标进行明确的定义
性能测试模型评审完成
性能测试模型中应具备明确的测试场景名称以及使用该场景的原因说明
测试场景中应具备明确的虚拟用户名称、数量/百分比、思考时间（ThinkTime）、检查点、测试数据说明
测试场景应具备明确的测试环境说明，包括应用版本、网络架构、应用技术架构、服务器硬件设备信息、应用平台的版本和关键参数设置信息
测试场景应具备明确的被测应用系统基础数据信息，包括基础数据量、类型（模拟数据/生产数据）
性能测试过程评审完成
性能测试过程包含了性能测试规程中规定的所有不可裁减的测试任务
每项测试任务应具备明确的测试方法说明
每项测试任务应具备明确的状态（完成/未完成）
若某项测试任务未完成，则该项测试任务应具备明确的未完成原因以及解决方法说明
性能测试单项任务数据分析评审完成
每个单项任务应具备明确的测试目的
每个单项任务应具备明确的测试数据分析
性能测试结论评审完成
每个性能测试目标应具备至少一条结论
每条结论应针对一个具体的性能测试目标
性能测试缺陷评审完成
所有已发现缺陷都具备了明确的状态（已解决/未解决）
所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人）
性能测试分析报告评审完成
若有一项评审结果为“不通过”，则此项为“不通过”
所有与会各方人员签字认可评审结果
若有一方人员未到场，此次评审视为无效。评审会议结束后，将会议记录与会议结论发送给缺席方人员进行离线评审。
获得缺席方离线评审意见后，修订评审结果，此次评审方可视为有效。
333模版
名称：《性能测试分析报告评审报告》
内容：
项目（群）组名称
会议召集时间
会议地点
与会人员、角色及部门名称
主持人员、角色及部门名称
记录人员、角色及部门名称
性能测试背景评审结果：通过/不通过
性能测试需求评审结果：通过/不通过
性能测试目标评审结果：通过/不通过
性能测试模型评审结果：通过/不通过
性能测试过程评审结果：通过/不通过
性能测试单项任务数据分析评审结果：通过/不通过
性能测试结论评审结果：通过/不通过
性能测试缺陷评审结果：通过/不通过
性能测试分析报告评审结果：通过/不通过
性能测试评审会议有效性：有效/无效
参与各方人员签字
34 活动：评审结果的发布
341准入标准
性能测试评审会议有效性：有效
性能测试分析报告：通过
342准出标准
性能测试分析报告评审报告已经发送给所有相关各方，应包括：项目实施管理条线、业务IT管理条线、相关业务部门、数据中心、项目（群）组、测试管理部、技术测试部、业务测试部等
性能测试分析报告评审报告由技术测试部备案
343模版
N/A
35 活动：评审结果的跟踪
351准入标准
性能测试分析报告中的所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人）输入已注册的用户名和正确的密码，验证是否登录成功；
输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
输入未激活的、已锁定的、被注销的用户名和正确密码，验证是否登录成功；
用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
第一次登录失败，再次输入正确的用户名和密码，验证是否登录成功；
如果登录功能启用了验证码功能，用户名、密码、验证码都输入正确，验证是否登录成功；
如果登录功能启用了验证码功能，用户名、密码正确，验证码输入错误，验证是否登录失败，并且提示信息正确；
点击验证码是否可以更换验证码，更换后的验证码是否可用；
刷新页面是否会刷新验证码，刷新后的验证码是否可用；
如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
无网络模式下登录，是否给出“网络未连接”或“网络异常”的提示；
第一次登录请求超时后（服务器出问题，随后恢复正常），再次请求登录能否登录成功。
页面默认焦点是否定位在用户名的输入框中；
快捷键 Tab 和 Enter 等，是否可以正常使用；
用户名和密码是否大小写、空格敏感；
使用中文、英文键盘输入字母传给后端的字符长度是否一致；
前端页面是否根据设计要求限制用户名和密码长度，且前后台都需要限制；
页面上的密码框是否加密显示，是否需要设置明暗码切换按钮；
输入栏是否设置快速删除按钮；
忘记用户名和忘记密码的功能是否可用；
修改密码后，是否重定向到登录页面；
修改密码后，原密码是否作废不可用；
在其他终端修改密码后，PC端是否自动下线，若下线后，使用原密码能否继续登录；
使用默认密码第一次登录成功时，是否提示修改密码；
第一次登录成功，是否会同步其他终端用户信息；
用户登录成功但是会话超时后，继续 *** 作是否会重定向到用户登录界面；
不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
输入错误密码的限制次数：
分别测试最大值-1、最大值、最大值+1 时的输错密码情况；
超过最大次数限制后，是否采取强制手段限制登录或对账号暂时冻结处理；
超过最大次数限制后，分别输入正确的密码和错误的密码再次登录。
用户名、密码、验证码输入框是否不支持复制和粘贴；
密码输入框内输入的密码是否都可以在页面源码模式下被查看；
用户密码后台存储是否加密；
用户密码在网络传输过程中是否加密；
密码是否具有“有效期”，密码有效期到期后，是否提示需要修改密码；
是否可记住密码，记住的密码保存是否加密；
记住密码是否有“有效期”，若有“有效期”，过期之后是否会清空密码；
登录成功后的session时效设置；
登录错误后的提示是否有安全隐患；
退出登录后再次登录，使用记住的密码，是否登录成功；
不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
用户登录过程中log中是否有个人信息明文打印
用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
登录后输入登录URL，是否还能再次登录？如果能，原登录用户是否变得无效；
同用户同终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
同用户不同终端，先后登录，验证登录是否具有互斥性；
同用户同浏览器已经登录，再次打开一个标签页时，是否需要重新登录；
不同用户在同终端同浏览器登录，验证登录信息token的正确性；
不同用户在同终端同浏览器登录，被踢后，页面是否会跳转到登录页；
是否支持第三方登录，如微信、QQ、微博；
是否允许第三方工具平台存储密码；
是否可以使用登录的API发送登录请求，并绕开验证码校验；
是否可以用抓包工具抓到的请求包直接登录；
截取到的token等信息，是否可以在其他终端上直接使用，绕开登录。token过期时间校验；
性能压力测试用例:
单用户登录的响应时间是否小于 3 秒；
单用户登录时，后台请求数量是否过多；
高并发场景下用户登录的响应时间是否小于 5 秒；
高并发场景下服务端的监控指标是否符合预期；
高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
兼容性测试用例：
不同浏览器下，验证登录页面的显示以及功能正确性；
相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
不同分辨率的界面下，验证登录页面的显示以及功能正确性；
网络延迟或者弱网或者切换网络或者断网时正常登录是否正常
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）