品質保証（QA）とは。定義の三大流派と定義揺れの弊害 - 千里霧中
近年のソフトウェア業界では、テスト関連活動を担うエンジニアを「QAエンジニア」と呼ぶようになっています。ただQA（品質保証）という言葉は、旧来から二つの定義が共存しているほか、業界内の通例で更に別の意味付けが行われた結果、定義が曖昧になり誤解を生みがちな状態となっています。 そこで今回は、日本語圏で、QA（品質保証）の言葉がどのように定義されているか、整理して解説します（結論からいうと三流派あります） 国際標準規格での定義：品質マネジメントシステムの実証 IEEEやISOといった国際的な標準規格、およびそれに準拠した知識体系や標準では、古くから体系立てて品質マネジメント、品質保証、品質管理の定義を行っています。 有力な文献として、品質マネジメントの標準規格である、ISO 9000：2015の定義を紹介します。 まずISO 9000では、品質保証の前提として品質マネジメントという用語を使って
モダンなテストレベル設計（ユニットテスト～システムテスト等をどう設計するか）の原則 - 千里霧中
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 （Vモデルが必須と明言しているわけではなく、極端な例ですが）例え
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
MacやLinuxでPICTを使う - 千里霧中
組合せテストツールのPICTの解説で、表題についてよく聞かれるのでメモ。 PICTについては、専用のバイナリファイルで配布されていたこともあり、今までWindowsで使用されてきた。 ただ去年からGithubでオープンソース化され、gccやclangで自由にビルドできるようになった。それに伴い、MacやLinuxでもWindowsと同じぐらい手軽に利用できるようになっている。 あえて言うまでもないかもしれないが、導入方法は以下の通り。最近のgccやclangが使え、makeできる環境であれば、OSは問わない。 「https://github.com/Microsoft/pict」にて、Download ZIPからファイルダウンロード、解凍 解答したディレクトリで「make」実行。同ディレクトリにバイナリpictができる。 使用例 このディレクトリに、例えば以下のようなファイルsample.
clang/gccに組み込まれたAddressSanitizer/LeakSanitizerでメモリエラーを捕捉する - 千里霧中
C/C++でのユニットテストによるメモリリーク検出 - 千里霧中の補足。 メモリエラーの検出方法についてだけれど、最近のclangやgccだと、AddressSanitizerという動的解析ツールが組み込まれており、それを活用できる。 使用する場合はコンパイラオプション「-fsanitize=address」「-fsanitize=leak」等を指定する。 題材 例えば以下のコードを対象にする。 //main.c #include <stdio.h> #include <stdlib.h> void hoge(void) { int *a_buff = (int *)malloc(5 * sizeof(int)); a_buff[10] = 8; } int main(void) { printf("test\n"); hoge(); return 0; } これを普通にコンパイルして実行
gdbでのマルチスレッド処理のデバッグや制御について - 千里霧中
マルチスレッド処理のデバッグや解析において、gdbで各スレッドの実行・停止を制御する操作についてメモ。 なお今回は解説で以下のサンプルコードを使用する。ここでは３つのスレッドがそれぞれ「m_count 」「t1_count 」「t2_count 」の３つの変数をインクリメントしている。 //main.c #include <stdio.h> #include <unistd.h> #include <pthread.h> static unsigned int m_count = 0, t1_count = 0, t2_count = 0; void *thread1(void *args) { while (1) { t1_count++; } return NULL; } void *thread2(void *args) { while (1) { t2_count++; } ret
実行中でのコールスタックの取得と表示 - 千里霧中
メモ用。デバッグ等で有用なコールスタックはgdbなどの各種デバッガで取得できるけれど、実行中にアプリケーション内で取得したい場合がある。 それはglibcが使えるならbacktrace()、backtrace_symbols()で実現できる。 例えば下記のコード： #include <stdio.h> #include <execinfo.h> void hoge1(void) { size_t i; void *trace[128]; char **ss_trace; size_t size = backtrace(trace, sizeof(trace) / sizeof(trace[0])); ss_trace = backtrace_symbols(trace, size); if (ss_trace == NULL) { /*Failure*/ return; } /*例えば表示
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
