测试用例

选项 组合次数/o:N：默认2，最大值为参数总量。取值越大生成的测试用例越多，从而测试覆盖率就更高。 值分隔符/d：默认逗号","。 别名分隔符/a：默认管道符"|"。 负值前缀/n：默认波浪符"~"。 输出随机/r：使用同样的模型内容和选项得到的输出是相同的，使用此选项可使输出结果随机。 区分大小写/c：参数的取值区分大小写。 模型文件参数定义 模型文件内容分块：至少1个"参数定义"区域，额外可选择包含"子模型"和"约束定义"区域。 注释和空行：可以用"#"开启一行注释，空行可以出现任何地方。 参数定义：参数与其取值间使用分号":"分隔，一行一个参数。 参数类型：数值型和字符型两种。 模型文件子模型 定义：使用"{参数名1,参数名2,...} @ 组合次数"的格式自定义一个组合，然后通过增减"组合次数"来使特定组合得到更多或更少的测试。 说明：可以定义多个子模型；同一参数可在多个模型中使用；组合次数默认值为选项/o的取值，最大值为子模型参数总量。 模型文件约束 条件约束 IF分支语句：IF pass THEN pass ELSE pass; 关系运算符：=,<>,>,>=,<,<=,LIKE(可使用通配符*和?),IN 逻辑运算符：NOT,AND,OR 可以使用圆括号改变它们的运算优先顺序；参数名需用中括号[]括起来；IN的目标集合需用大括号{}括起来。 无条件约束

p ytest 模块的使用 pytest 是第三方测试框架，是基于 unittest 的扩展框架，比 unittest 更简洁，更高效。 安装 pytest 模块 使用 pip install pytest 即可。安装好之后，到 cmd 中输入 pytest --version 检查是否安装成功。 pytest 运行方法 想要用 pytest 运行，首先要 import pytest 比如创建一个 demo.py 文件，内容为： import pytest # 导入包 def test_sucess(): # 定义第一个测试用例,assert 0表示断言失败 print("test sucess") assert 0 def test_fail(): # 定义第二个测试用例，没有assert，默认成功 print("test fail") if __name__ == "__main__": #定义一个列表，列表内容为测试文件名，也可以为元组，表示需要运行的文件为demo.py test_list = ['demo.py'] # 用pytest模块的main()方法，参数为上面定义好的列表或者元组。 pytest.main(test_list) # pytest.main(['-s','demo.py']) # 也可以这样写，这样写和上面那样写会运行结果会有所不同，可以自己试试看。

出场人物： 08：10 小H，是巨杉数据库引擎研发的一名工程师。7：20 天还蒙蒙亮，小H就起床了，点亮了心爱的光剑，开始了新的一天。 在08:10时候，他已经洗漱完，锻炼好身体，倒好了咖啡。 整个春节由于疫情防控，他为国家做出了贡献，基本都宅在家里了。但是他觉得，宅在家里，也是一个挺好的春节。 小H查看了手机，发现一封未读邮件，显示是公司 Jenkins 系统发出。 小H打开邮箱，查看了未读邮件，是昨天新提交的优化代码 PR，导致了昨晚自动化测试系统中一个测试用例没有通过。 09:15 在平时，大家 9 点上班回到公司，各个小组都会在09:15自发地开一个简短的站立会，组内成员分别大致介绍一下昨天完成的工作内容还有今天的工作计划，然后大家开始了一天的工作。 现在，只是面对面的站立会，变成了“线上站立会“，大家依然按时登入小鱼易联的会议号。 小H在会上介绍了一下昨天提交引擎里 analyze 优化的代码，以及发现新代码会导致一些测试用例失败的情况。他打算今天将这个问题解决。 09：25 小N，是巨杉数据库的测试工程师。 早上刚刚拿出“小黄鸭“准备开始工作，她也收到了昨晚自动化测试系统用例失败的邮件。昨晚失败的测试用例，是她负责的。在刚才的站立会上，她计划今天和小H一起跟进这个失败用例。 开完了早上站立会，她通过 *** 远程连接公司内部的云桌面。

第一级：初始阶段： 措施：测试是完全混乱无序的，测试等同于调试，编码完成后随意地测试与调试，目标是表明软件是奏效的。 优势：省事 弊端：开发出的软件产品得不到任何质量的保证，存在很多缺陷，用户无法接受。 第二级：定义阶段 第三级：集成阶段 第四级：管理和测量 措施：测试成为一个可以测试和量化的过程，开发过程引入评审机制，测试用例和测试过程·被管理起来。 优势：基于规范的测试，拥有流程控制，出现质量管理活动。 弊端：只能被动地找缺陷，无法主动控制缺陷。 第五级：最佳化： 措施：建立缺陷预防的思想，通过统计抽样等方式不断改进测试，自动工具完全支持测试用例的运行，开展各种与测试相关的度量活动。 优势：机制好转，不断改进测试，可以度量和优化产品质量。 软件测试以需求为中心。 程序员、测试师 软件开发过程 ①、定义需求②分析需求③、实现需求、④、校验需求 测试是从分析需求阶段开始的。 来源： CSDN 作者： 指极所致 链接： https://blog.csdn.net/qq_45393395/article/details/104409308

基础篇——在学习中思考！ 在大概了解了 UML 之后就该系统的学习 UML 的主要建模元素了，一个个实例帮助我们更好的理解这些元素的重要性并运用相关知识解决实际问题。 在 UML 里有一个概念叫版型，有些书里也称为类型、构造型。版型只是 UML 的一种扩展手段，本身并不涉及太多的思想和方法，而是在建模的不同阶段，为了区分视图之间的不同观点，会采用不同的图示来表示。 以人为本是当代的流行词汇， UML 建模也是以人为本的。参与者在建模过程中是处于核心地位的， actor 是在系统之外与子同交互的某人或某事。系统之外的定义说明在参与者和系统之间有一个明确的边界，赞誉这只可能存在于边界之外，边界之内的人和事物都不是参与者。在查找参与者的过程中，可以询问以下问题以帮助确定参与者： （1）谁是负责提供、使用或删除信息？ （2）谁将使用此功能？ （3）谁对某个特定的功能感兴趣？ （4）在组织的什么地方使用系统？ （5）谁负责支持和维护系统？ （6）系统有哪些外部资源？ （7）其他还有那些系统需要与该系统交互？ 查找参与者时请注意，参与者一定是直接并且主动的向系统发出动作并获得反馈的，否则就不是参与者。此时可以理解刚开始举的例子“小王到银行去开户，向大厅经历询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。”在这个场景中，小王是参与者，而经理和柜台职员及其他事物都在系统边界以内

定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一些列操作，这些操作生成特定主角 可以观测的值 。一个完整的用例定义由参与者、前置条件、场景、后置条件构成。 1、理解用例： 用例就是参与者希望通过系统达到的愿望。一个系统的功能性是由一些对系统有愿望的参与者要做的一些事构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能够通过用例来达到，那么这个系统就被确定下来了。捕捉功能性需求就是用例的作用。 2、特征： （1）用例是相对独立的； （2）用例的执行结果对参与者来说是可观测的和有意义的； （3）用例必须由参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例； （4）用例必然是以动宾短语形式出现的； （5）一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。 3、区分用例和功能： 第一，功能是脱离使用者的愿望存在的，而用例不是； 第二，功能是孤立的，给一个输入，通过计算机就有一个固定的输出，例如，按下开关灯就亮；而用例是系统性的，它需要描述谁在什么情况下通过什么方式开灯的结果是什么； 第三，非要从功能的角度解释的话，用例可以解释为一系列完成一个特定目标的“功能”的组合。 4、业务用例： 业务用例是用例版型中的一种，用于需求阶段的业务建模。严格的说，业务建模与计算机系统建模无关，它只是业务领域的一个模型

客户是提供全球金融服务的著名欧洲银行 系统是基于Web的 现金管理系统 ，80多个国家使用，有非常严格的质量和测试需求 新版本发布每月2次，需要频繁进行大量的冒烟测试和回归测试，而手工测试覆盖全部功能需要2个月/轮 现有测试用例数量达6900个；展现层使用Flex技术，测试工具支持差 解决方案 基于QTP搭建了 自动化测试 平台 采用数据驱动技术(Data-driven)，将测试数据和测试程序分离，极大地提高了程序的可维护性 编写了可复用的模块，如文件读写、日志管理、异常处理、结果统一存储与分析等 将现有的测试用例分类，按照计划分批实现自动化，目前已完成80%的测试用例自动化 项目成果 每发布一次小版本，之前需要20.9人/月进行测试验证， 实施自动化测试后仅需5.7 人/月； 在测试周期和覆盖率也上满足了版本每月发布2次的任务 在此项目上实施的自动化测试框架和公用模块可复制到其他项目 来源： oschina 链接： https://my.oschina.net/u/4158156/blog/3158165

页面描述 web登录页面：有两个文本框，一个提交按钮(注册、忘记密码等按钮) 用例设计 【功能测试(Function test) 0.什么都不输入，点击提交按钮，看提示信息。（非空检查） 1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。（正常输入） 2.输入错误的用户名或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验） 3.登录成功后能否能否跳转到正确的页面（低） 4.用户名和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示） 5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤） 6.记住用户名的功能 7.登陆失败后，不能记录密码，用户名可以保存 8.用户名和密码前后有空格的处理 9.密码是否加密显示（星号圆点等） 10.登录需要验证码的，输入完用户名和密码后，验证码为必填项 11.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），"刷新"或"换一个"按钮是否好用 12.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确 13.输入密码的时候，大写键盘开启的时候要有提示信息。 14.输入错指定次数后，账号锁定，需要做解锁处理 15.登录失败的提示信息需要高亮处理 16.登录失败有次数限制的，每失败一次，提示剩余可以登录次数和处理建议 【界面测试(UI Test) 1

很多时候，需要对类中的方法进行一些测试，来判断是否能按要求输出预期的结果。 C#提供了快速创建单元测试的方法，但单元测试不仅速度慢不方便，大量的单元测试还会拖慢项目的启动速度。 所以决定自己搞个方便的测试用例。 控制台一句话调用。 测试用例.注册并Print(EnumEx.Name); 结果画面： 测试用例的实现 /// <summary> /// 提供测试用例的注册和运行功能，用来比对结果和预期值是否相同，向控制台输出结果。 /// </summary> public class 测试用例 { /// <summary> /// 测试的方法 /// </summary> public Func<string> 方法 { get; set; } /// <summary> /// 测试名称 /// </summary> public string 名称 { get; set; } /// <summary> /// 期望得到的结果string /// </summary> public string 期望值 { get; set; } /// <summary> /// 新建一个测试 /// </summary> /// <param name="v名称">测试名称</param> /// <param name="v期望值">期望得到的结果string</param> ///

软件测试的原则： 1.测试用例中一个必需的部分是对于预期输出或结果进行定义； 2.程序员应当避免测试自己编写的程序； 3.编写软件的组织不应当测试自己编写的软件； 4.应当彻底检查每个测试的执行结果； 5.测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况； 6.检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”； 7.应避免测试用例用后即弃，除非软件本身就是个一次性的软件； 8.计划测试工作时不应默许假定不会发现错误； 9.程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比； 10.软件测试是一项极富创造性、极具智力挑战性的工作。 来源： https://www.cnblogs.com/jitipaper/p/12337418.html