测试用例设计

等价类划分法 概念： 把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件。 关于等价类划分的两个重要概念： 有效等价类：有效等价类是程序规格说明有意义，合理的输入数据。 比如用正确的用户名和密码来登录系统就是有效等价类。 无效等价类：无效等价类是程序规格说明无意义，不合理的输入数据。 比如用不存在的用户名和密码来登录系统就是无效的等价类。 优缺点分析： 优点：提高用例设计效率，较少冗余用例。 缺点：只考虑了输入的有效和无效，对数据的组合比较随机，边界缺陷不容易发现 。 适用范围：输入条件划分成多个子条件，各个子条件之间相对是独立的，没有制约关系。 实例演习 输入框要求输入[1,100]的数 有效等价类：可以输入1-100之间的数来验证，如：2 无效等价类：可以输入1-100之外的任意字符验证，如：999、字母、特殊符号、空格、回车 边界值划分法 概念： 是对等价类划分法的补充；假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其他取值导致程序错误的可能性也很小。 关于边界值几个“点”的概念： 上点：边界上的点。 例1：边界是封闭的 [1,100]之间的整数：1、100就是上点 例2：边界是是开放的 [1,100)之间的整数：1、100就是上点 内点：区域内的点 离点：里上点最近的一个点 例1：边界是封闭的 [1

一般实习生、新入职的软件测试新手，主管一般是让你先执行别人的用例。 为什么呢，其实很简单，新人执行用例是最好的边工作边学习的方式，如果让新人直接开始写用例，那么结果就是评审的时候提出很多问题、用例需要大改，费时费力。 而已经会写用例的人，新入职，一方面每个测试团队的测试用例粒度有所区别，另一方面，刚入职对于整个业务不熟，执行用例是熟悉业务的方式之一。 过了执行用例阶段，一般你会负责一个模块测试。但是很多人工作好几年，依然是只负责过模块的测试都没有机会（也许是不敢）独立负责一个完整项目的测试、上线。 那么独立负责项目的测试上线，你需要做什么呢？ 1、需求评审，确认研发计划。编写测试计划、测试方案。 2、先根据产品的需求文档 + 自己对当前行业的了解，拆分测试点 。拆分测试点的过程中，把遇到的不清晰的需求（或者技术方面，不理解的知识点），通过问产品/开发/搜索引擎检索/查阅公司内部资料，搞定 。 根据自己梳理完成的最终测试点，开始设计测试用例、进行用例评审（或是测试点评审）。 3、测试执行过程中 ，问题提交Bug系统，对提交的bug进行跟进、回归 。 4、关注风险 / 延期 ，以及 质量 / 进度 的平衡 ，及时反馈。 5、完成测试，提交测试报告 。 6、开始发布 、上线 （或有灰度发布流程。记得把上线的步骤，自己用文档，完整的记录下来，并模拟几次，确保无遗漏）。 7、进行生产环境测试

1、接口测试原理 接口测试，实际上是针对于接口做测试的。 那么接口是什么？ 软件开发，既要做前端，也要做后端，并且后端是整个业务的核心，用于处理业务请求，实现具体的功能；而前端只是提供一个页面给用户看结果以及提供页面给用户做输入。所以整个业务的处理逻辑都在后端。而后端逻辑相对很复杂，所以在开发的时候，会由架构师确定接口，然后再针对这个接口实现其具体的功能。 接口也可以认为是我们要做多少事情，因为在技术层面，如果要实现登录、注册、增、删、改、查等操作，就会先设计好一个模块，说明具体实现哪些功能点，这个功能点应该有哪些输入项，有哪些方法。 这个东西就是我们所谓的接口，在java里，接口里包含属性名和方法，所有的方法都是抽象方法，只有方法名，而没有这个方法的具体实现。也就是说：我知道这是一个登录功能，但是登录怎么实现，这完全是不知道的，需要开发人员具体去实现。那么作为我们的开发人员，他就会领到一个任务去实现这个接口。比如，实现登录接口，注册接口等。 我们可以认为，虽然他是在实现登录接口、注册接口。也就相当于我们根据这个接口去实现登录功能，注册功能。所以这个接口实际上也就是后台一个具体的功能。 那么什么又是接口测试？ 实际上我们所说的接口测试就是开发人员把这个接口实现了，他需要去验证这个接口的实现是否正确。 但是这是一个后台的功能，这个开发也是一个后台开发，他去验证接口的时候

一、何为测试用例 百度百科： “ 测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 通俗的说：把测试系统的每一步，按照一定的规范编写的文档。 二、测试用例要素 测试用例一般所包含的要素包括： 用例编号、测试模块、用例标题、优先级（高BTV、高、中、低）、前提、执行步骤、预期结果、编写人、编写日期、审核结果、备注等 三、测试用例作用 理清思路，减少漏测 输出文档用于测试小组内交叉评审，组外开发评审 跟进测试进度 通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。 重复测试　　 　　一个测试系统，通常需要在不同环境（测试、预生产、生产等）进行测试。保证执行每个环境测试工作时，没有功能点遗漏。根据测试用例执行测试，是一个很好的方案 四、测试用例常见设计方法 这里暂且进行罗列，后续会针对每种设计方法进行详细分析 等价类划分法 边界值分析法 判定表法 因果图法 状态迁移图法 流程分析法 正交实验法 错误推断法 探索性测试 来源： https://www.cnblogs.com/beard/p/11900617.html

黑盒技术设计测试用例的方法主要有： 等价类划分方法 边界值分析方法 错误推测方法 因果图方法 正交实验设计方法 1.等价类划分： 等价类划分法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例；该方法是一种重要的，常用的黑盒测试用例设计方法。 1） 划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。 有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。 无效等价类：与有效等价类的定义恰巧相反。 设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。 2）划分等价类的方法： 下面给出六条确定等价类的原则。 ① 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。 例：输入值是学生成绩，范围是0～100： ②

还记得 .NET Framework 的 ASP.NET WebForm 吗？那个年代如果要在 Web 层做单元测试简直就是灾难啊。.NET Core 吸取教训，在设计上考虑到了可测试性，就连 ASP.NET Core 这种 Web 或 API 应用要做单元测试也是很方便的。其中面向接口和依赖注入在这方面起到了非常重要的作用。 本文就来手把手教你如何用 xUnit 对 ASP.NET Core 应用做单元测试。.NET Core 常用的测试工具还有 NUnit 和 MSTest，我本人习惯用 xUnit 作为测试工具，所以本文用的是 xUnit。 创建示例项目 先用 ASP.NET Core API 模板建一个应用。 模板为我们自动创建了一个 ValuesController，为了方便演示，我们只留其中一个 Get 方法： 1 public class ValuesController : ControllerBase 2 { 3 // GET api/values/5 4 [HttpGet("{id}")] 5 public ActionResult<string> Get(int id) 6 { 7 return "value"; 8 } 9 } 然后再添加一个 xUnit 单元测试项目： 模板自动为我们添加好了 xUnit 引用： 1 <ItemGroup> 2

一、什么是业务领域建模 领域建模： 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型； 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。

自动化测试介绍 自动化测试(Automated Testing)，是指把以人为驱动的测试行为转化为机器执行的过程。实际上自动化测试往往通过一些测试工具或框架，编写自动化测试用例，来模拟手工测试过程。比如说，在项目迭代过程中，持续的回归测试是一项非常枯燥且重复的任务，并且测试人员在每天重复劳动的工作之下，也丝毫得不到成长。 此时开展自动化测试就能够帮助测试人员从重复、枯燥的手工测试中解放出来，提高测试效率，缩短回归测试时间。一般来说，自动化测试通常都会跟持续集成系统（比如Jenkins）配合使用。 但在自动化实践过程中，往往会发现理想和现实之间的差距很大。自动化测试的劣势，主要体现在以下几方面： 1 相对手工测试，自动化测试对测试人员的要求相对较高； 2 测试用例需要根据版本迭代进行更新，有一定维护成本； 3 不能指望自动化测试去发现更多新的BUG，自动化测试能发现的缺陷远远比手工测试少； 4 自动化测试的产出价值往往在于长期的回归测试，短期内发挥的作用可能不明显； 希望借助自动化流程解决的问题 1 测试时间紧张，手工测试可能覆盖不全，容易错过某些边界情况； 2 模块间强耦合时，单纯从页面进行测试时，比较难深入的发现问题； 3 回归测试时，需要投入较大的人力/工时； 4 实现手工测试无法达成的测试任务； 5 通过编写测试用例，加深对业务/数据的认知，有助于下阶段迭代中发现隐藏的问题；

顶尖高手帮你整理的性能测试方法大全 在这半年以来，我陆续参加或者独立承担的项目组版本的部分性能测试，慢慢的有了一些认识，暂时做一个积累，和大家做一个交流。 性能测试的需求背景一般来自于以下三种情况： 第一种是现网出现性能问题，项目组专门进行了性能改造。比如修改的某个接口，由原来的同步调用修改成了异步，又或者是更换了新的api，由tcp协议修改为udp协议，为了保证新替换的api的可靠性，都需要进行性能测试 第二种是一个新做的系统，运营人员需要全面的把脉，了解该系统的处理能力。 第三种是随着请求量的快速增长，而该系统却从未做过性能测试，项目组担心系统在可预见的短期会扛不住，所以要求测试人员对该进行全面的性能测试，给出一份参考数据 根据背景的不同我们往往有不同的准备方式，但是大致可以从以下几个方面入手准备。 1、全面了解该系统概况 （1）系统所期望的性能指标： 对于第一二两种情况，都会有很明确的现网性能指标，比如以前测试的acs，是一个新作的系统，需求说明书中就明确标注需要达到1wtps.而对于第三种情况，往往我们需要尽量的模拟现网，得出数据供运营做参考。 例如最近测试的查询限制引擎，测试这边给出了单台svr的处理能力以及是否支持平行扩展等运维最关心的数据即可。 （2）组网以及网间各个系统之间的通信形式： 有时我们性能改造只是组网中一个小小的系统

目录 为什么需要软件测试？回到顶部 为什么选择软件测试行业？回到顶部 为什么不让开发自己做测试？回到顶部 什么是测试？回到顶部 软件测试的作用？回到顶部 软件测试的诞生回到顶部 软件测试出现原因回到顶部 软件测试的发展回到顶部 软件测试的目标回到顶部 缺少软件测试发生的事故回到顶部 软件测试常见的误区回到顶部 软件测试的主要工作回到顶部 测试原则回到顶部 测试对象回到顶部 软件架构回到顶部 常见项目组织架构回到顶部 软件测试用例回到顶部 什么是测试用例回到顶部 为什么需要测试用例回到顶部 测试用例的意义回到顶部 测试用例的生命周期回到顶部 测试环境设计回到顶部 测试力度回到顶部 软件测试计划书回到顶部 测试计划的意义回到顶部 测试目标回到顶部 资源配置回到顶部 风险控制回到顶部 如何制定测试计划回到顶部 5W1H方法回到顶部 工作经验之谈回到顶部 图解软件测试计划回到顶部 软件计划报告回到顶部 软件兼容性回到顶部 what，什么是软件兼容性测试回到顶部 why，为什么要进行软件兼容性测试回到顶部 when，什么时候开始软件兼容性测试回到顶部 where，软件兼容性测试都要测什么回到顶部 who，谁来执行软件兼容性测试回到顶部 how，怎样执行兼容性测试回到顶部 版本控制回到顶部 引入版本控制的原因回到顶部 版本控制的定义回到顶部 版本控制方法回到顶部 版本控制评价标准回到顶部