错误推断法：是根据经验或直觉推测可能存在的各种错误。

正则表达式：通常被用来检索、替换哪些符号某个规则的文本（如手机号码、邮箱）

因果图：适合检查程序输入各个条件的各种组合情况。因果图转为判定表。一般使用在输入条件的的各种组合

判定表：与因果图结合使用

大纲法：拆分系统模块（一般原型图已经拆分） 主要用在测试计划

正交法：一般不用这种方式测试（因为太过繁琐，需要将所有输入和结果进行组合）

（借鉴别人的打油诗，仅供参考）

所有输入选等价

给定范围加边界

条件孤立想判定

指定常量取正交

跨界操作流程法

多种状态迁移图

条件组合出因果

测试充分全覆盖

多种方法不唯一

测试用例优先顺序划分

高 ：用户经常执行的业务逻辑操作，涉及金钱的功能等

中 ：用例多数包括边界值、逆向逻辑等

低 ：很少被用户执行的操作

下面是目录，可以根据自己的需求来选择性阅读哈

→→测试用例是什么？

→→测试用例有什么必备的方面？

→→写测试用例的方法有哪些？

→→测试用例怎么写？

→→测试用例用什么写？

1.测试用例是什么？

测试用例是指对一项特定的软体产品进行测试任务的描述，体现测试方案、方法、技术和策略。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软体需求

2.测试用例有什么必备的方面？

编写测试用例的八大要素有：用例编号，所属模块，测试标题，重要级别，前置条件，测试输入，操作步骤，预期结果

3.写测试用例的方法有哪些？

知道了什么是测试用例，那该怎么写测试用例呢？不著急，先来学习一下测试用例的方法有哪些

（1） 等价类划分

原作者：xuping511_to

原文链接：https://wenku.baidu.com/view/f7684221bcd126fff7050bef.html#

来源：百度文库

将测试中所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性

举个栗子：输入框要求输入1-100的数

有效等价类：可以输入1-100之间的数来验证，如：2、6……99

无效等价类：可以输入1-100之外的任意字元验证，如：250、字母、下划线、特殊符号、空格、回车.....

（2） 边界值

原作者：xuping511_to

原文链接：https://wenku.baidu.com/view/f7684221bcd126fff7050bef.html#

来源：百度文库

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

实践告诉我们：大量的错误是出在输入输出的边界价上。我们还拿上面的例子，一个输入框要求输入1-100之间的数。我们要测它有没有超出这个范围，如：0、-1、-2、10、101.....等等，来判定是否超出了我们的范围。

（3）因果图

用图解的方法表示输入的各种组合关系，写出判定表，从而设计相应的测试用例。最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。

原文链接：https://www.docin.com/p-2173458956.html

原作者：边雄刚

原文出处：豆丁

例子：有一个处理单价为5角钱的饮料的自动售货机软体测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。

解析：如题可知，可分析出原因和结果

原因：

1. 售货机有零钱找

2. 投入1元硬币

3. 投入5角硬币

4. 按下橙汁按钮

5. 按下啤酒按钮

结果：

10.售货机【零钱找完】灯亮

11.退还1元硬币

12.退还5角硬币

13.送出橙汁饮料

14.送出啤酒饮料

中间结点：

6.选商品

7.应该找零钱

8.能够找零钱

9.钱已付清

如下所示↓：画出因果图（原因结点列在左边，所有结果结点列在右边，中间节点表示处理的中间状态）

（4） 错误推测法

基于经验和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法

（5） 其它方法

除了上面几种常用的，其它的方法还有：状态迁移图、流程分析法、正交验证法等等

我在逛博客园的时候看到一首打油诗，我觉得非常合适：

所有输入选等价

给定范围加边界

条件孤立想判定

指定常量取正交

跨界操作流程法

多种状态迁移图

条件组合出因果

4.测试用例怎么写？

当~当~当~终于来到重头戏了，让我们来看看怎么写一个合格的测试用例吧

用例编号：唯一标识用例的序号。一般是数字或者模块字母+数字组合。如：L001，L表示登录，001表示用例序号

所属模块：所测功能模块的名称，如：登录模块

用例名称：就是这个用例是什么意思。如：输入账号

前置条件：前置条件可以保障后面的测试步骤正常进行，可以理解为执行当前用例的前提条件。比如：只有注册过的用户才能登录

测试输入：用例执行期间输入的外部信息。根据用例的种类不同，测试输入也有所不同。包括数据、图片、手工操作、文件、资料库记录等类型

测试步骤：详细完整的把你测试的过程描述出来

预期结果：对当前用例的输出做一个预期值。预期结果是根据软体需求所得出的，相当于一个衡量标准。在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

实际结果：实际测出来的结果（可能会和预期结果不符）

另外，有些公司可能会要求在用例后面添加优先顺序、用例人员姓名、测试日期、用例修改日期、测试结果（Pass、Fail、Block）等等，这个得根据公司的会实际情况来看

我根据上面的登录页面写了一个登录模块的测试用例，如下表所示，你们可以参考一下：

PS：都看到这里了，真的不考虑给这么用心的我

@可乐豆

一个点赞、关注吗？(*?▽?*)

5.测试用例用什么写？

测试用例可以以Word或者Excel的方式呈现，主要用到的工具有禅道、testlink等等

---

另外，网上有很多软体测试的模板。（本来这里有一个博客园模板的链接，知乎告诉我违规了，想要的可以私我，当然你们也可以去博客园自己找）

对了，关于软体测试的学习路线，可以看一下我之前写的文章，里面非常详细的写了软体测试的技术学习路线和每个阶段该具体该学什么：2020最全软体测试学习路线和资料分享

好了，终于写完了这篇文章。如果你喜欢这篇文章就请点赞关注一下@可乐豆吧。总之，关注可乐，入股不亏~(笔芯)后续，可乐也会发布关于软体测试的相关文章

---

安装卸载测试？

安装程序是第三方的还是自己写的？

第三方的简单，好的情况他都处理好了，只要确保调用正常就可以。案例检查配置文件需要修改的地方是不是配置正确。

自己写的要测的就多了。

一 界面

一共几个界面，界面元素，位置，文字，是否有效

二 安装

1.预设安装

安装完成后启动成功

拷贝的文件位置正确，数量正确，文件完整，许可权正确

创建文件成功，位置正确，内容正确，许可权正确

链接文件创建成功，链接正确，许可权正确

注册表修改成功，内容正确

安装日志无报错

2.自定义安装

安装路径创建成功

自定义配置正确

3.安装失败

错误处理：许可权不足，空间不足，文件拷贝不全……安装日志内容正确

手动取消，退回上一步，退出安装程序，清除已安装文件

4.再次安装，覆盖已有文件或升级已有文件

三 卸载

目标文件已删除

注册表内容修改成功

卸载日志内容正确

另外，如图，存在帮助，调用帮助成功

就测试案例来说，明确测试目的，测试点是否已覆盖，测试步骤明确可操作，测试结果明确可验证，必要时辅助测试数据

再复杂一些，说明所使用的测试方法，测试工具，自制脚步……

最终目的，使其他测试人员能复现整个测试过程，查找没有覆盖的测试点，优化测试数据，测试方法，测试工具，更有效的保证软体质量

---

哈喽我来了 感谢邀请！！

在企业的实际工作当中，为了提高测试的覆盖率，提高测试过程的可追溯性，我们往往需要通过需求分析从而编写大量的测试用例，看似简单的测试用例其实隐藏著众多逻辑和技巧在内，写出一份优质的测试用例能够大大的提高测试质量，从而发现更多的BUG，写好测试用例其实并不容易！

下面我来说说到底如何编写一个测试用例呢？步骤是怎么样的？作为测试新人，如何实现测试用例的设计一直是大家共同的困惑，在工作中我们该如何展开测试用例的编写工作呢？我们先来梳理一个测试用例的设计步骤。

　　前提:　　再去编写测试用例之前我们要对我们的项目需求进行了解，按照什么顺序测试，去测什么？覆盖哪些内容和需求都要自己心里有数，作为测试用例的编写者不仅了解要有工作当中常见的测试用例编写方法，同时需要了解被测软体的设计、功能规格说明、用户试用场景以及程序/模块的结构。 步骤： 1、测试需求分析需求分析就是要弄清楚用户需要的是什么功能，用户会怎样使用系统。这样我们测试的时候才能更加清楚的知道系统该怎么样运行，才能更好的设计测试用例，才能更好的测试。测试需求分析是测试工作的第一步，经过需求分析，对原始需求列表中列出的每一个需求点，找到我们需要测试的测试要点；针对所确定的测试要点，分析测试执行时对应的测试方案/方法。

2、业务流程分析

　　分析完需求后，明确每一个功能的业务处理流程，不同的功能点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软体的业务流程。　　从业务流程上，应得到以下信息： A、 主流程是什么? B、 条件备选流程是什么? C、 数据流向是什么? D、 关键的判断条件是什么?

例如：app测试流程及业务流程

3、测试用例设计

　　完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。

4.编写完成后自我检查以及部门内部评审

5.测试用例更新完善　　测试用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;在软体交付使用后客户反馈的软体缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

好的测试用例是怎么样的？

　　一.质量属性

　　1.正确性：确保测试标题描述部分的内容正确性。

　　2.经济性：只为确定需要的目的设计相应的测试步骤

　　3.适应性：既能适应短期需要，又能考虑长远需要。

　　4.可追踪性：用例能追踪到一个具体的需求。

　　5.自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。

　　二.结构化和可测试性

　　1.含有规范的测试标题和编号。

　　2.含有一个确定的测试某一个特定需求的目的。

　　3.含有关于测试方法的描述。

　　4.指定条件信息-环境、数据、预置的条件测试、安全入口等。

　　5.含有操作步骤和预期结果。

　　6.陈述任何辅助证据，例如截图报告并确保这些东西妥善保存。

　　7.确保测试环境的干净（即用例不会影响整个环境）。

　　8.描述时使用主动语气结构。

　　9.操作步骤不要超过15步

　　10.确保单个用例测试执行时用时不超过20分钟。

　　11.自动化脚本用例添加必要的注释，比如目的、输入和期望结果。

　　12.如果可能，建议提供可选择性的预置条件测试。

　　13.用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。

　　三.配置管理

　　1.采用命名和编号规范归档。

　　2.保存为特定的格式，文件类型。

　　3.用例版本是否与当前被测试软体版本一致（对应）。

　　4.包含用例需要的相应测试对象，如特定资料库。

　　5.存档阅读。

　　6.存档时按角色控制访问方式

希望可以帮到题主有什么问题私信我，还有免费资料可以领取！

---

测试用例组成部分一般是：前置条件，测试步骤，期望结果，用例等级，用例类型等等。

具体要怎么写就太宽泛了，一般是根据需求点去写，灵活运用等价类划分、边界值分析、组合覆盖、逻辑推断、业务路径覆盖等等设计方法，并在测试中不断完善和新增……

---

推荐阅读：