眼下唯一的问题就是delta调试的测试函数多少有些
它要先在原代码中更新补丁后,编译,运行测试,反复地进行这个过程
一次一次又一次,也就是说你的构建活动一定要是自动的,当然
你的版本控制系统也需要能够生成
不同版本之间,精细、明确、细微的差别。
甚至在某个版本控制系统里面就应该已经内置好这么一个模式了。
就是git啦。它的命令 git bisect会准确地告诉你两个版本之间差别,
只要存于git,在这里只关注老版本没问题,新版本出事故的的情形。
9
00:00:43,000 --> 00:00:48,000
所以,它其实做了和delta调试差不多的事情--找出起因,
是什么引起失败的出现。
现在,来个小测,假设delta调试告诉你了一个引起错误的变更,
你现在撤销变更,恢复到前一版本,
即将delta调试返回的这些地方的代码恢复原状后。
它有什么结果呢?是程序正常,失败不再出现?
是问题已经被修复?
到你选了。
The only problem with delta debugging is that the test function is somewhat elaborate.
It first must apply the patches to the code, then build the code, then run the test, and this again
and again and again, which implies that your build facility must be automatic and of course,
your version control system should also be able to produce
exact and small differences between versions.
There's even a version control system where such a scheme is already built-in.
This is called git and the command git bisect will give you the exact change between two versions
stored in git such that the old version will not have the failure and the new version will have the failure.
So this does something very similar to delta debugging--pointing out the culprit,
which has been changed such that the failure occurs.
And now, for a quiz, assume that delta debugging gives you a failure-inducing change
and you now go and undo the change that is revert to the previous version
for these locations as returned by delta debugging.
What is the effect--is it that the program builds normally, the failure no longer occurs,
or is it that the problem is properly fixed.
Check all that apply.
差分デバッグの問題はtest関数が複雑ということです
まずパッチをコードに適用させコードをビルドします
そしてテストの実行を繰り返し行うのです
つまりビルド機能が自動化されていなければならず
もちろんバージョン管理システムでも
バージョン間の違いを把握する必要があります
このような枠組みを持つ
バージョン管理システムも存在します
それはGitと呼ばれgit bisectコマンドを使うと
バージョン間の変更内容が確実に分かります
前は失敗しなかったのに
新しいバージョンでは失敗したといった情報です
問題が分かるという意味では
差分デバッグと似ているかもしれません
不具合を起こした変更点が明らかになるのです
では小テストです
差分デバッグにより
どこで不具合を起こしたか分かったので
その問題の部分を
以前のバージョンに戻したいと考えています
どんな効果がありますか?
プログラムをビルドできること?
不具合が起きないこと?
問題が適切に修復できたこと?
正しい答えをすべて選びましょう