象棋中马行走路线的测试用例设计

这个例子的设计并不是我首先想出的，我参考了原文，然后经过整理，融汇了我的Excel技巧，把它整理了出来，分析了表的生成过程，比原来的设计有一定的易学易用性。现在让大家来进行分析与学习。 需求规格： 1、如果落点在棋盘外，则不移动棋子； 2、如果落点与起点不构成日字型，则不移动棋子； 3、如果落点处有自己方棋子，则不移动棋子； 4、如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子； 5、如果不属于1-4条，且落点处无棋子，则移动棋子； 6、如果不属于1-4条，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子； 7、如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。 一．原因条件： 1、 落点在棋盘上； 2、 落点与起点构成日字； 3、 落点处不为自己方棋子； 4、 落点方向的邻近交叉点有棋子（绊马腿）； 5、 落点处无棋子； 6、 落点处为对方棋子（非老将）； 7、 落点处为对方老将。 二.结果动作： 21．不移动棋子 22．移动棋子（不吃子） 23．移动棋子并除去对方棋子 24．移动棋子除去对方老将，胜利。 添加一个中间节点11，这样能够简化设计。然后画出因果图： 通常的设计方法就是一个表的方法，我称为一表法。但是七个因子，表格就会非常的长，让人望而却步！2^7=128，那么长的表是一般人不能做到的，在Excel里面都感觉版面不够，要是拿来考试怎么办？所以这里提供两表法。1、2、3、4只与11及21有关，可以使用一个表先处理。然后11、5、6、7有可以作为一个表。 1、列出表一 合并表一： 黄色背景的项说明了他们可以合并，合并后得到： 2、列出表二 首先去掉由于约束而无效的项，然后再进行合并，得到下面的表： 3、把两个表合并成一个表 由11因子的中介作用，合并的表二的每一个因子都对应一个表一的所有与之相同值的项，如表二中的列1就对应表一的1、9、13、16，如此对应，可生成下面的表格： 由于上表中有一些相似的项，可以考虑他们是否可以合并，所有先在Excel中把相似的项复制在一起，得到下面的表： 这样就可以生成测试用例了。其实真正的用例就在表中，只是还是要写成连菜鸟也要看得懂的文字而已。下面是用例： 用例1：如果在棋盘上，构成日字，并且不是自己方棋子，落点方向的邻近交叉点没有棋子，落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。 用例2：如果在棋盘上，构成日字，并且不是自己方棋子，落点方向的邻近交叉点没有棋子，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子。 用例3：如果在棋盘上，构成日字，并且不是自己方棋子，落点方向的邻近交叉点没有棋子，且落点处无棋子，则移动棋子。 用例4：如果落点不在棋盘上，直接不移动棋子。 用例5：如果落点在棋盘上，不构成日字，则不移动棋子。 用例6：如果落点在棋盘上，构成日字，是自己方棋子，不移动棋子。 用例7：如果落点在棋盘上，构成日字，不是自己方棋子，落点方向的邻近交叉点上有棋子，则不移动棋子。 最新内容请见作者的GitHub页：http://qaseven.github.io/

边界值分析法测试用例设计实例 边界值分析法是黑盒测试的重要方法，本文以一道数位DP算法题为例，自主测试黑盒测试用例，并采用JUnit5完成单元测试。
python接口自动化（三）--如何设计接口测试用例（详解） 上篇我们已经介绍了什么是接口测试和接口测试的意义。在开始接口测试之前，我们来想一下，如何进行接口测试的准备工作。或者说，接口测试的流程是什么？有些人就很好奇，接口测试要流程干嘛？不就是拿着接口文档直接利用接口 测试工具测试嘛。其实，如果只是三五个接口，你可以这么做一个临时的接口测试。但是，如果是上百个接口，或者，你们公司的这个项目，第一次做接口测试，那么，我们还是很有必要严格遵守接口测试的流程。
正交试验测试用例设计及工具推荐 在科研和生产实践中，人们往往要做许多次实验来进行某项研究。实验条件一般包括很多因素，当因素的值不同时，实验的结果也不一样。如果想把每个因素的每个值都要实验一遍，总实验数就等于各因素的值的个数的乘积，而这个数往往很大，超过了可接受的成本。 例如，假设某个实验由A,B,C,D四个因素，每个因素都有10个不同的取值，那么如果想把每个因素都考虑到，我们需要做 10*10*10*10=10000次实验。 为了减少实验数目，我们必须选出那些最有代表性的例子。于是，就要用到了正交表法(Orthogonal Array Testing Strategy)。
【软件测试】测试用例的设计方法 测试用例写的过于简单，则可能失去了测试用例的意义，设计过于简单的测试用例其实并没有真正的进行设计，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已，测试用例设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试