コード読み取りテストケースの共有

現在のネットワークはzookeeperを使用してタスクIDの保存を行い、失敗した場合にリカバリを行う.zookeeper自体のクライアントはカスケード削除ノードをサポートしていません.ディレクトリの下のノードを1つずつ削除してからディレクトリを削除する必要があります(簡単に理解できます).zookeeperのノードを維持するために、zookeeperのインタフェースを呼び出すことで、ディレクトリと次のノードを再帰的に削除できるツールが開発されました.
通常のテスト方法では、テストシーン分析、テスト例設計を行うことができます.その後zk環境を構築し、テスト実行します.しかし、このようなコード量の少ない小道具に対して、その欠陥をより迅速に発見できるだろうか.
ツールの使用シーンは簡単なので、脳でシーンやツールの使用状況を確認することができます.脳の中でツールの設計とコードの考え方を考えてみましょう.コードを直接読み取り、より効率的ですか?
実際のコードウォークスルーにより,4つの問題が発見され,そのうち1つの深刻な問題,1つの一般的な問題,2つのヒント問題が発見された.同時に後続の手作業テストの的確性と注目点にも指導がある.
 
手順1:プログラムの基本構造(DeleteDir.java)を決定する:
Main関数はdeleteRecursiveを呼び出してノードを1つずつ削除します.deleteRecursiveはlistSubTreeBFSで削除するノードのリストを取得します(ディレクトリは親ノードとみなされます)

public static void main(String[] args) {
… …
DeleteDir.deleteRecursive(zookeeper, pathRoot,number);
… …
}
 
public static void deleteRecursive(ZooKeeper zookeeper, String pathRoot,int number){
… …
zookeeper.delete(tree.get(i), -1);
… …
}
public static List listSubTreeBFS(ZooKeeper zookeeper, String pathRoot,int number){
… …
}

ステップ2:各破壊
手順3:再度全体を点検し、全面的に考える
1.ツールが同時に使用できないことは明らかです.(パラレル実行の必要性はありませんが、明確にする必要があります)
2.Delete関数は削除ノードの詳細を印刷していません.
3.本格的な削除は呼び出しのzookeeperのインタフェースであり、協力と大量の操作の効率を考慮しなければならない.
コードの読み取りはテストの補助方法であり、特にシステムの実現がはっきりしていない場合、読み取りコードはテスト者がシステムの実現を理解するのに役立ちます.その後のテストの構想の拡張に良い指導作用がある.オープンソースシステムの大量導入に伴い、コードの読み取り能力は徐々にテスト者の比較技能となっている. 
最後に、コードの読み取りは本当の実行に代わることはできません.まだ実際にテストを実行する必要があります.
1、複数のZKアドレスを入力し、一つのzkアドレスが到達できない場合、zkに接続できず、操作に失敗する
2、実行時にlog 4 jの構成が必要
3、アーカイブのdeleteDirs.sh実行可能権限が不足し、実行できません
質問リスト:
見出し
重大度レベル
手段を発見する.
複数のブランチがあるディレクトリの場合、入力した削除ノード数がディレクトリに追いつく可能性があり、失敗します.
ひどい
コードウォーク
入力パラメータが検証されていません:ipポート、zkディレクトリ、削除数など
一般
コードウォーク
入力エラー時、usage情報の印刷が不鮮明で、正規ではありません
ヒント
コードウォーク
Deleteメッセージ提示位置が正しくなく、本当にアクションを削除する位置に置くべきです
ヒント
コードウォーク
複数のZKアドレスを入力し、1つのzkアドレスが到達できない場合、zkに接続できず、操作に失敗する
一般
手動テスト
実行時にlog 4 jの構成が必要であることを示す
ヒント
手動テスト
アーカイブされたdeleteDirs.sh実行可能権限が不足し、実行できません
ヒント
手動テスト