测试用例编号
◇
规则：编号具有唯一性、易识别性，由数字和字符组合成的字符串
◇
约定：
系统测试用例：产品编号-st-系统测试项名-系统测试子项名-xxx
集成测试用例：产品编号-it-集成测试项名-集成测试子项名-xxx
单元测试用例：产品编号-ut-单元测试项名-单元测试子项名-xxx
●
测试项目
◇
规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等
◇
约定：
系统测试用例测试项目：软件需求项
如：测试手机在没有sim卡的情况下，可以拨打紧急电话
集成测试用例测试项目：集成后的模块名或接口名
如：测试模块a提供的文件接口
单元测试用例测试项目：被测试的函数名
如：测试函数int
readfile(char
pszfilename)
●
测试标题
规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。
●
重要级别
规则
高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；
中：重要程度介于高和低之间的测试用例；
低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。
●
预置条件
规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件
●
输入
规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等
●
*** 作步骤
规则：执行当前测试用例需要经过的 *** 作步骤，保证 *** 作步骤的完整性。
●
预期输出
规则：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：正确性测试；容错性（健壮性）测试；完整（安全）性测试；接口间测试；数据库测试；边界值分析法；压力测试；等价划分；错误推测需要明确个问题，有没有有需求或者设计文档没？1，有的话按照文档写，将文档中的功能点摘录出来，按照功能点去写测试用例；2，没有文档，按照软件功能去写--那你们应该属于了解和学习阶段了：先了解软件功能，然后将软件的功能模块进行划分，梳理出来一个个功能点；这样有了功能点就可以进行测试用例编写了：1，测试用例的要包括 *** 作步骤：怎么 *** 作--把你的 *** 作过程描述下来； 期望结果--软件设计的结果是什么--这个来自设计和平时的体验； 实际结果--在测试过程中按照步骤执行下来之后看到的结果；2，编写测试用例时将功能点进行划分，需要确认该功能点有几个测点，基本上做到一个测点一个case；3，测试用例要划分优先级和重要级别：软件功能主流程上的功能是重要级别最高的，而优先级一半配合开发过程和功能完善来确定：基本的要优先级最高，边角的可以优先级最低；LZ如果是个新手，建议将软件划分成小块，一个个的消化，其实测试最容易入门的方式就是将你作为使用者，这就是用例的来源。希望能对你有帮助。一支付功能怎么测试？
1、从功能方面考虑：
1）、用户的使用场景：包括正常完成支付的流程；
支付中断后继续支付的流程；
支付中断后结束支付的流程；
单订单支付的流程；
多订单合并支付的流程；
余额不足；未绑定yhk；密码错误；密码错误次数过多；找人代付；
弱网状态下，连续点击支付功能功能，会不会支付多次；分期付款等；
2）、不同终端上支付：
包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
3）、不同的支付方式：yhk网银支付、支付宝支付、微信支付等；
4）、从产品容错性上：包括支付失败后，能否再次支付、能否退款；
2、从性能方面考虑：
多个用户并发支付能否成功；
支付的响应时间；
3、从安全性方面考虑
使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，
(下两个订单A,B，付款时拦截订单B，并把订单B的订单号改为A订单的订单号)无法完成支付；
4、从用户体验方面考虑
是否支持快捷键功能；
点击付款按钮，是否有提示；
取消付款，是否有提示；
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
5、兼容性
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同 *** 作系统的手机上测试
二购物车怎么测试？
1功能测试
a）、未登录时：
将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加。
b）、登录后：
所有链接是否跳转正确；
商品是否可以成功加入购物车；
购物车商品总数是否有限制；
商品总数统计是否正确；
全选功能是否可用；
删除功能是否可用；
价格总计是否正确；
商品文字太长时是否显示完整；
购物车中下架的商品是否有标识，是否还能支付；
新加入购物车商品排序（添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品）；
是否支持快TAB、ENTER等快捷键；
商品删除后商品总数是否减少；
收藏功能是否可用；
购物车结算功能是否可用。
2兼容性测试：
BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
APP：在主流的不同类型，不同分辨率，不同 *** 作系统的手机上测试，华为，vivo，oppo等
3用户体验测试：
删除商品是否有提示；
是否支持快捷键功能；
是否有回到顶部的功能；
商品过多时结算按钮是否可以浮动显示；
购物车有多个商品时，能不能只对单个商品结算；
界面布局、排版是否合理；
文字是否显示清晰；
不同卖家的商品是否区分明显。
4性能测试：
打开购物车页面要多长时间
输入框怎么测试？
1、长度：例如输入框支持100字符， 那需要测试100字符、101字符，最大长度的显示是否正常；
2、哪些是支持的字符类型：数字、字母、汉字、字符！@！#、特殊字符；
3、是否支持换行；
4、字符串前后中带空格，前后的空格是否过滤， 中间的空格是否保留
5、全角半角的字母、数字
6、快捷键：能不能全选，部分选择，复制剪切粘贴是否可用，粘贴超过最大长度的字符串怎么显示，table键盘是否可用；
7、不同终端的兼容性
三登陆功能怎么测试？
功能方面的测试：
1输入正确的用户名和密码，点击提交按钮，验证是否能正确登录，能否能跳转到正确 的页面
2输入错误的用户名, 验证登录失败，并且提示相应的错误信息
3输入错误的密码, 验证登录失败，并且提示相应的错误信息
4用户名为空, 验证登录失败，并且提示相应的错误信息
5密码为空, 验证登录失败，并且提示相应的错误信息
6用户名和密码都为空，点击登陆
7用户名和密码前后有空格的处理
性能方面的测试
1打开登录页面，需要多长时间
2输入正确的用户名和密码后，登录成功跳转到新页面，需要多长时间
安全性方面的测试
1密码是否在前端加密，在网络传输的过程中是否加密
2用户名和密码的输入框，能否防止SQL注入攻击
3用户名和密码的输入框，能否防止XSS攻击
4错误登陆的次数限制（防止暴力破解）
5是否支持多用户在同一机器上登录
6一个用户在不同终端上登陆
7用户异地登陆
用户体验测试：
1页面布局是否合理，输入框和按钮是否对齐
2输入框的大小和按钮的长度，高度是否合理
3是否可以全用键盘 *** 作，是否有快捷键
4输入用户名，密码后按回车，是否可以登陆
5 牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
兼容性测试
BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
APP：在主流的不同类型，不同分辨率，不同 *** 作系统的手机上测试，华为，vivo，oppo等
四支付功能怎么测试？
1、从功能方面考虑：
1）、用户的使用场景：包括正常完成支付的流程；
支付中断后继续支付的流程；
支付中断后结束支付的流程；
单订单支付的流程；
多订单合并支付的流程；
余额不足；未绑定yhk；密码错误；密码错误次数过多；找人代付；
弱网状态下，连续点击支付功能功能，会不会支付多次；分期付款等；
2）、不同终端上支付：
包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
3）、不同的支付方式：yhk网银支付、支付宝支付、微信支付等；
4）、从产品容错性上：包括支付失败后，能否再次支付、能否退款；
2、从性能方面考虑：
多个用户并发支付能否成功；
支付的响应时间；
3、从安全性方面考虑
使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，
是否防止SQL注入，XSS攻击(跨站脚本攻击)。
4、从用户体验方面考虑
是否支持快捷键功能；
点击付款按钮，是否有提示；
取消付款，是否有提示；
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
5、兼容性
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同 *** 作系统的手机上测试
五还款怎么测试？
功能上：
1不同的还款方式：等额本息，等额本金还款，一次性还本付息。
2逾期，提前还款和第三方还款。
3不同账户的还款。
4余额不足的还款，
5金额输入错误，不输入。
6弱网状态下连续点击还款按钮或者系统不问题情况下，支付方未把支付结果返回给下单发起方。
从性能方面考虑：
还款的响应时间；
从安全性方面考虑：
是否防止SQL注入，XSS攻击(跨站脚本攻击)。
还款金额是否被拦截，还款密码等敏感信息是否加密。
从用户体验方面考虑
系统界面是否容易理解。
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
兼容性：
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同 *** 作系统的手机上测试
《附》
支付流程：
用户发送下单请求-平台后台查看订单并制作支付请求后将请求传给第三方（银行）-银行将支付的信息反馈给客户，客户核对后输入支付密码--银行成功划账后将支付成功信息告知给平台后台和用户--平台确认支付信息反馈给第三方并发货
退款流程：
用户提交退款申请给平台，平台后台通过审核后将退款信息告知给第三方（银行），第三方将钱退到用户绑定的银行账户中并告知平台处理结果。平台确认结果后并结束用户退款申请。
六电梯如何测试？
需求测试：
查看电梯使用说明书、安全说明书等
界面测试：
查看电梯外观
功能测试：
1测试电梯能否实现正常的上升和下降功能。
2电梯的按钮是否都可以使用。
3电梯门的打开，关闭是否正常。
4报警装置是否可用。
5与其他电梯之间是否协作良好。
6通风状况如何。
7突然停电时的情况。
8上升途中的响应。
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来；
2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
可靠性：
1门关上的一刹那出现障碍物。
2同时按关门和开门按钮。
3点击当前楼层号码。
4多次点击同一楼层的号码等等。
5同时按上键和下键会怎样。
易用性：
1电梯的按钮的设计符合一般人使用的习惯吗．
负载/压力测试：
1看电梯的最大限度的承受重量．在负载过重时是否有提醒。
2在一时间内不断的让电梯上升，下降。
稳定性测试：
1最大负载下平稳运行的最长时间。
文档测试：
1使用手册是否对电梯的用法、限制、使用条件等有详细描述我一直在想，作为测试人员应该用脑袋去测试，也就是说应该在工作中不断的总结经验，把自己的发现应用到测试中去，这样你才能有真正的提高，你所具备的理论和能力才有竞争力。回到测试用例中来，我觉得做好以下三点就是一个好的用例。第一：依据分明众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，昨晚需求分析后，测试就可以做测试需求，然后就可以写测试用例了。所以写测试用例的依据就是需求。这么说太笼统，举一个例子。一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。这也是需求必须可测的一个体现。假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。那么 ok，我们就要写5000个测试用例。还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。这样做的目的在统计中讲。第二：目的明确用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。前面无论多少步骤，都是为了找到这个目的途径。功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢？等到测试最小的功能点是，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只把他当成一个正确的找到目前的功能点的途径就行。换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们再以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。就是这样。第三：便于统计测试用例对整个测试过程的质量控制和评估有很重要的意义。一，可以做测试需求覆盖分析。这样如果一个用例写几个测试点，那么就无法完成需求覆盖分析工作，至少是不符合规则的。你还可以通过模块划分，来分析哪个模块存在的问题较多，还有可能存在更多的问题（应为程序员不同，能力就不同，缺陷喜欢扎堆分布，这个大家都知道），存在问题较多的模块需要做进一步的测试或者下一次作为测试重点。如果你统计的数据不准确，会误导结果的。三，做缺陷分析。用例失败了，就生成一个缺陷。
测试分析报告：
1、编写目的：说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
2、测试概要：用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
3、测试结果及发现：把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
4、对软件功能的结论：简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。
测试原则
对计算机软件进行测试前，首先需遵循软件测试原则，即不完全原则的遵守。不完全原则即为若测试不完全、测试过程中涉及免疫性原则的部分较多，可对软件测试起到一定帮助。
因软件测试因此类因素具有一定程度的免疫性，测试人员能够完成的测试内容与其免疫性成正比，若想使软件测试更为流畅、测试效果更为有效，首先需遵循此类原则，将此类原则贯穿整个开发流程，不断进行测试，而并非一次性全程测试。
百度百科-软件测试
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）