我和老王不太熟
如何编写一个完整全面的测试用例
展开全部 一、编写测试用例的原则测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。
测试用例编写应该遵循的原则：1、测试用例要达到最大覆盖软件系统的功能点。
测试工程师应该测试计划编写完成之后，在开发阶段编写测试用例，参考需求规格说明书和软件功能点对每个功能点进行操作上的细化，尽可能趋向最大需求覆盖率。
2、测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。
3、 测试用例的设计应包括各种类型的测试用例。
在设计测试用例的时候，除了满足系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受压力的能力等。
4、 测试用例的管理。
使用测试用例管理系统对测试用例进行管理。
一个好的测试用例应该具有较高的发现某个尚未发现的错误的可能性，而一个成功的测试案例能够发现某个尚未发现的错误，通常一个好的测试案例有以下特性：1、具有高的发现错误的概率2、没有冗余测试和冗余的步骤3、测试是“最佳类别”4、既不太简单也不太复杂5、案例是可重用和易于跟踪的.6、确保系统能够满足功能需求测试用例不可能设计得天衣无缝，也不可能完全满足软件需求的覆盖率，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试。
二、如何编写测试用例测试用例的信息有很多，可以根据实际的情况进行增删，一般来说一个优秀的测试用例应该包含以下信息：1、产品相关信息（1）软件产品或项目的名称（2）软件产品或项目的版本（3）功能模块名（4）功能描述（5）测试平台这些信息建议可以在测试案例手工选择。
2、基本记录信息（1）测试用例入库者（2）测试用例入库时间（3）测试用例更新者（4）测试用例更新时间这些信息建议可以由测试案例自动生成。
3、测试用例的属性（1）测试用例ID：测试用例的ID（由案例管理系统自动生成，方便跟踪管理）（2）测试用例名称：测试用例的名称（3）测试功能点：测试的功能检查点（4）测试目的：该测试功能点的测试目的（5）测试级别：主路径测试、烟雾测试、基本功能测试、详细功能测试。
下面对这几个测试级别进行说明：A、主路径测试：对照需求中重要模块和功能的最主要功能路径，主路径测试为设计探针模块，快速检查程序的可测试性（可测试性还包括安装测试是否成功）的主要依据的测试案例B、烟雾测试：对照需求中所有模块的主要功能路径，主路径测试案例为烟雾测试案例的子集，烟雾测试为做回归测试的主要依据的测试案例。
C、基本功能测试：对照需求和总体设计中所有模块和功能的基本功能路径，基本功能测试为测试软件产品的非重要级别模块，书写完全的自动测试脚本的主要依据。
D、详细功能测试：对照总体设计中所有模块和功能的功能路径，测试各个模块及功能各个层次，各种类型。
详细功能测试案例为对重点模块，易发生错误的模块的主要依据。
（6）测试类型：功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/停止测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。
（7）预置条件：对测试的特殊条件或配置进行说明（8）测试步骤：详细描述测试过程，案例的操作步骤建议少于15个。
（9）预期结果：预期的测试结果三、测试用例设计过程对一个全新的产品来说，首先需要了解的是产品需求文档和产品模块之间的关系。
然后需要从需求文档中书写与所有需求相对应的主路径测试案例和烟雾测试案例，这个时候也同时会包括一定的基本路径测试案例甚至是详细测试案例。
在这个时候，因为对产品没有直接的使用感受，书写测试案例要考虑面广而不要太过精细。
继续阅读产品功能定义文档，将所有的功能定义直接对应写相关的测试案例，这个时候，最好能够对程序的本身有一定的接触，加深对程序的了解，以便写出更好，更全面的测试案例。
最后，在实际测试中，还需要不断扩充，修改以前的测试案例，得到完整的基本功能测试案例和详细测试案例。
如果对于一个已有一定或大部分案例的产品来说，不管测试者是否本身熟悉这个产品，其主要的任务就是阅读，检查需求及相关的变更，然后对原有的案例进行理解，扩充和修改。
这就是案例的重用/复用。
软件测试的自动化测试开发小案例有哪些？
有些同行提到自动化测试或自动化测试开发就想到使用自动化测试工具QTP、Winrunner、或其他开源的测试框架，其实除了这些商业的自动化测试工具外，我们亲自编写一些测试驱动程序，完全可以实现自动化测试，且控制灵活，能够符合自己公司业务系统的特点。
下面是一个小案例，希望能够给你带来一些启发。
测试需求： 要对公司提供的Web services进行测试，包括功能和性能，当然只是测试压力。
功能就是把从web services 调用中把提交一条发送的WAP push广告信息插入到数据库，因为数据库表之间有关联，所以插入后数据后，会自动选择决定选择投放的频道，当用户单击频道上的链接后再显示广告文字或图片。
功能就是要测试插入一条广告后，是否正确的选择频道，并且插入的信息是正确的。
性能测试则是测试当前服务器能够部署的web services能处理多少条插入的广告信息。
测试开发设计： 把发布的Web services地址直接添加到测试开发的web references中，通过在C#中直接调用Web services方法，把从界面的广告信息传递给该方法。
为了检验插入是否正确，打开数据库读取字段与测试数据进行比对。
在压力测试时，通过开辟多个线程，向系统施加压力（本系统在压力时，没有改变插入的数据，其在数据库表中因为有ID为主键，所以不会冲突）。
自动化测试无处不在，只要有时间，有条件，可以随时开发适合的测试小工具，满足测试的需要。
下次再讲解一个直接通过读取页面链接，进行压力测试的例子。
软件测试流程,在给我一个测试项目的例子
展开全部 一般的软件测试流程是这样：1.拿到需求说明书，开始对需求进行测试，找出需求中的问题或者说不可测的地方2.需求测试通过后，根据需求说明书制定测试计划，包括测试策略、测试方法、测试周期等3.然后根据软件功能说明书编写测试用例，一般的公司都是根据需求说明书进行编写4.搭建测试环境，包括软件环境和硬件环境5.根据测试用例进行测试，提交缺陷6.回归测试7.测试完成后，进行测试总结，编写测试报告至于测试文档，我这倒是有cmmi标准的一些文档，如果你想要的话，可以留下邮箱，我发过去。
好了，都发过去了。
...
软件测试,谁能给我一个测试项目的例子,大概的说明一下,呵呵。
...
以一个网站注册功能为例： 用例编号：register001用例标题：注册功能验证用例级别：高预置条件：服务器开启输入 ： A.用户名：11111 b.密码：22222 C.确认密码：22222 。
。
。
操作步骤：1.进入注册界面。
2.依次输入A,B,C... 3.提交。
预期结果：注册成功，跳转登陆界面。
。
展开全部...
软件测试报告怎么写
摘要 测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。
本文提供测试报告模板以及如何编写的实例指南。
关键字 测试报告 缺陷 正文 测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。
下面以通用的测试报告模板为例，详细展开对测试报告编写的具体描述。
PARTⅠ 首页0.1页面内容： 密级 通常，测试报告供内部测试完毕后使用，因此密级为中，如果可供用户和更多的人阅读，密级为低，高密级的测试报告适合内部研发项目以及涉及保密行业和技术版权的项目。
XXXX项目/系统测试报告 报告编号 可供索引的内部编号或者用户要求分布提交时的序列号 部门经理 ______项目经理______ 开发经理______测试经理______ XXX公司 XXXX单位 （此处包含用户单位以及研发此系统的公司） XXXX年XX月XX日 0.2格式要求： 标题一般采用大体字（如一号），加粗，宋体，居中排列 副标题采用大体小一号字（如二号）加粗，宋体，居中排列 其他采用四号字，宋体，居中排列 0.3版本控制： 版本 作者 时间 变更摘要 新建/变更/审核 PARTⅡ 引言部分 1.1编写目的 本测试报告的具体编写目的，指出预期的读者范围。
实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。
预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。
提示：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。
此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。
1.2项目背景 对项目目标和目的进行简要说明。
必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。
1.3系统简介 如果设计说明书有此部分，照抄。
注意必要的框架图和网络拓扑图能吸引眼球。
1.4术语和缩写词 列出设计本系统/项目的专用术语和缩写语约定。
对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。
1.5参考资料 1.需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。
2.测试使用的国家标准、行业指标、公司规范和质量手册等等 PARTⅢ 测试概要 测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。
（其他测试经理和质量人员关注部分） 2.1测试用例设计 简要介绍测试用例的设计方法。
例如：等价类划分、边界值、因果图，以及用这类方法（3-4句）。
提示：如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念，顺便说一句，在这里写上一些非常规的设计方法也是有利的，至少在没有看到测试结论之前就可以了解到测试经理的设计技术，重点测试部分一定要保证有两种以上不同的用例设计方法。
2.2测试环境与配置 简要介绍测试环境及其配置。
提示：清单如下，如果系统/项目比较大，则用表格方式列出 数据库服务器配置 CPU： 内存： 硬盘：可用空间大小 操作系统： 应用软件： 机器网络名： 局域网地址： 应用服务器配置 ……. 客户端配置 ……. 对于网络设备和要求也可以使用相应的表格，对于三层架构的，可以根据网络拓扑图列出相关配置。
2.3测试方法（和工具） 简要介绍测试中采用的方法（和工具）。
提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。
工具为可选项，当使用到测试工具和相关工具时，要说明。
注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。
怎样写一个项目的测试用例
首先，建议你找一些软件测试基本理论的资料来看，学习软件测试基础；其次，你要学习分析需求；最后，你明白了一条完整的测试案例的组成部分，掌握了测试案例设计方法，结合这些方法再根据需求，就可以设计案例了；一条测试用例的主要部分包括：案例编号，案例名称，案例性质（正或反），案例概述（描述案例执行目的），操作步骤序号，步骤描述，预期结果，运行结果，测试数据，案例设计人员，案例执行人员，计划执行日期，实际执行日期，轮次等。
。
黑盒测试案例设计方法主要是 等价类划分法，边界值法，因果图分析法，错误推测法，经验；白盒测试案例设计方法：判定覆盖法，条件覆盖法，语句覆盖法，条件组合覆盖法等；...
＂软件测试工程师＂是具体做什么工作呢？
软件测试工程师主要职责是编写测试用例，按照产品要求测试功能点，发现并记录bug的。
软件测试工程师（Software Testing Engineer）指理解产品的功能要求，并对其进行测试，检查软件有没有错误（Bug），测试软件是否具有稳定性（Robustness），写出相应的测试规范和测试用例的专门工作人员。
简而言之，软件测试工程师在一家软件企业中担当的是“质量管理”角色，及时发现软件问题并及时督促更正，确保产品的正常运作。
按其级别和职位的不同，可分为三类：1、高级软件测试工程师，熟练掌握软件测试与开发技术，且对所测试软件对口行业非常了解，能够对可能出现的问题进行分析评估；2、中级软件测试工程师，编写软件测试方案、测试文档，与项目组一起制定软件测试阶段的工作计划，能够在项目运行中合理利用测试工具完成测试任务；3、初级软件测试工程师，其工作通常都是按照软件测试方案和流程对产品进行功能测验，检察产品是否有缺陷。
转行做软件测试应该做一个怎样的学习规划
我们先理一下测试工程师是什么。
测试工程师，软件质量的把关者，目前传统的软件行业还是以软件测试工程师为主，但是在新兴的互联网行业大多还是以QA来命名这个职位，也就是质量保证。
测试的工作在开发之后，是产品上线前的最后一步。
一般来说，当开发按照产品需求、交互设计、视觉设计完成软件开发后，就把完成版本提交给测试，测试人员再根据既定的测试用例进行功能测试、兼容性测试、性能测试等，逐渐收敛BUG，最后才能正式上线。
测试的工作主要由四部分组成功能测试：功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
兼容性测试：指对所设计程序与硬件、软件之间的兼容性的测试，包括软件能否在不同操作系统、不同机型、不同应用软件上、以及向前向后等兼容性能。
性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，以保证产品在大流量前提下都能正常运行，像我们熟知的负载测试和压力测试都属于性能测试，安全测试：以发现安全隐患为目标，防止产品上线后被攻击。
完成这些测试的步骤后，一款互联网产品就可以正式上线了。
因此，测试既是产品的第一个体验者（最早从开发手中接过成型的产品），也是产品质量的最后一道防线守卫者（做各种测试，保证用户拿到的最终成品可用、易用）。
因为测试的工作特性，他需要从用户的角度出发体验产品，这也决定了测试与开发、策划、设计等岗位交流、沟通的时间也会成为工作的一部分，甚至承担起整个产品的协调工作。
这样看来，把测试称为QA（质量保证人员）也就一点不奇怪了。
测试无用论？即使前面废话了很多，对测试有偏见的人依然会说，“测试的工作其实开发也能做啊，何必再设一个测试呢？”会产生这种想法也并不奇怪，毕竟隔行如隔山，不过这里还是要指出，上面的论述的错误之处在于(1)完全割裂了测试与开发工作(2)测试的工作被简化成找BUG事实上，找BUG只是测试最初级的阶段，虽然必须承认，测试的门槛低于开发，但优秀的测试人员工作量之大，专业度之高，绝非一般用户能替代。
就像我们每个人都会接触到的kpi指标一样，测试的每块工作内容也都有不同的能力等级划分：(1)手工测试，发现BUG(2)通过各种手段，确认这个BUG是一个需要解决问题，然后确定该BUG的重现步骤并尽可能简化(3)了解被测产品框架，能从代码中定位BUG源头，并能给出可能的解决方法(4)尝试找出该BUG发生的原因，并能找出检测同类BUG的方法（标准化）(5)能在保障产品质量的基础上，协调起整个项目上线的时间和流程以上能力，是从授人以鱼向授人以渔递进的。
当你在执行前人的测试用例时，找BUG固然是工作要求，但最主要的用意是学习用例的编写思路和方法，从案例中总结出规律，进而开始自己编写标准化测试用例，以免同类问题生出千万条不同用例。
一个测试的能力，能达到的层级越高，团队中的开发、策划就能节省更多时间，团队运行也会更高效。
而专业的测试，正常来说应该比开发对产品有更深入的理解，对于可能影响测试的因素，像Tomcat配置、数据库索引、多线程等都会有丰富的经验。
从入门到精通测试，距离有多远？始终认为，每个专业的学习与进步，都有赖于三个因素：(1)坚持(2)资源(3)天赋以第一个最重要，但第一个和第三个都不是外部可控因素，全靠自己，所以这边也只能列一些可以参考的资源。
职业发展规划
于涌编写的软件性能测试与lr实战和陈霁的lr11哪个好
于涌编写的软件性能测试与lr实战本书在介绍软件性能测试概念的基础上，结合实际测试案例的剖析，重点讲解了LoadRunner工具的使用技巧和实战技术。
全书分为4个部分。
在“基础篇”中，介绍了使用LoadRunner工具进行软件性能测试的基本应用，如性能测试流程、性能测试场景和脚本的调试等技术。
在“实战篇”中，分别对数据库、邮件协议以及LoadRunner .NET插件等应用进行了详细的讲解。
在“提高篇”中，讲解了一个完整的GIS测试案例，把前面的知识整体贯穿起来，培养读者具有大型项目测试的能力。
附录部分，提供了性能测试中经常用到的非常重要的模板文件和规范化的软件测试相关文档。
陈霁：本书是一本基于HP LoadRunner 11工具的指导用书，从性能测试原理到工具使用再到项目实施，全面介绍了性能测试的各个方面，其内容基本主线说明如下。
第一步（了解理论）：磨刀不误砍柴工，打下基础；第二步（掌握工具）：深入介绍LoadRunner11工具三大部分（Virtual User Generator、Controller、Analysis）如何实现用户行为的模拟、性能指标的监控、负载的生成及后期的数据分析；第三步（项目实施）：理论联系实际，介绍性能测试项目实施的流程和性能测试部门的组织管理；第四步（进阶提升）：对一些当下流行的或比较特殊的协议和开发技巧通过真实案例进行介绍。
本书结合了很多工作中的实际案例，图文并茂，既适合渴望了解性能测试的新人，也适合对性能测试有一定认识和经验的中、高级测试工程师。
同时，本书也可以作为高校开展性能测试课程的参考教材，让在校学生能对性能测试的本质和价值有一定的认识。
