Java 测试合并排序中的合并情况

是否有任何边缘情况或只是一般情况下，我需要测试这个功能。我能想到的唯一一件事是合并的数组中是否有一个是空的。是否有其他的测试用例需要考虑？

< p>对于任何类型，我考虑这些情况：

• 空名单
• 已排序的列表
• 反向排序的列表
• 一个列表，由整个列表中的相同元素组成
• 包含重复项的列表

---

这不仅是为了证明算法，也是为了提高性能。

考虑代码中的每个

if

语句和循环条件，并尝试找到使条件为真/假的测试用例。如果您发布代码，我们可以讨论可能的测试用例。

更多：

• 考虑每个数组中的元素数： 两个数组都有偶数个元素 一个数组的元素数为偶数，而另一个数组的元素数为奇数 一个数组中的元素数大于另一个数组中的元素数

也考虑数组中元素的范围 一个数组中的最大元素小于第二个数组中的最小元素 一个数组具有重复项 两个数组都有相同的元素集，例如（A1:2,4,6,8和A2:2,4,6,8）

---

基本上，在合并我用来测试合并排序代码的以下情况时，这些方法能够很好地捕获for循环中的一次性错误。我想这涵盖了大多数情况。您可以直接复制C代码并将其用于测试

//int arr[] = {12, 15, 23, 4 , 6, 10, 35, 28}; //Even number of element
//int arr[]={}; //Empty list 
int *arr = NULL; //Null pointer
//int arr[] = {4, 6, 10, 12, 15, 23, 28, 35}; //already sorted array
//int arr[] = {12, 15, 23, 4 , 6, 10, 35}; //odd length array
//int arr[] = {35, 28, 23, 15, 12, 10, 6, 4}; //descending sorted array input
//int arr[] = {12};//one element
//int arr[] = {12, 4}; // two elements
//int arr[] = {12, 15, 23, 4 , 6, 10, 35, 28, 100, 130, 500, 1000, 235, 554, 75, 345, 800, 222, 333, 888, 444, 111, 666, 777, 60};//large list of elements 
//int arr[] = {12, 15, -23, -4 , 6, 10, -35, 28}; //negative elements
int arr[] = {12, 12, 23, 4 , 6, 6, 10, -35, 28}; //duplicate elements
int arr[] = {12, 12, 12, 12, 12}; //Same element

---

当然，总有一种极端的情况，就是没有理智的人来处理，那就是当有那么多文件要合并时，你不能同时打开它们。@OldCurmudgeon谁在谈论文件合并？这是@OldCurmudgeon的

合并

部分，好的点文件排序常常被遗忘。事实上，无论是文件排序还是数据排序，通常都是根据比较/移动开销选择排序算法的起点。