はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
ネットワークテスト自動化ツール「NEEDLEWORK」のWindowsアプリケーション版（EXE版）にて「ネットワーク負荷テスト」提供開始
「NEEDLEWORK」のWindowsアプリケーション版における「ネットワーク負荷テスト」では、大量のトラフィックを生成し通信網に負荷をかける「スループットテスト機能」と、大量のセッションを確立することでテスト対象機器に負荷をかける「セッションテスト機能」の、2種類に対応している。 「セッションテスト」は、大量のセッションを確立・保持することで、テスト対象機器に負荷をかけられる。また、テスト対象機器がフェールオーバした際のセッション引継ぎ確認にも利用できる。 「スループットテスト」では、大量のトラフィックを発生させることで、テスト対象機器に負荷をかけることが可能なほか、生成するパケットに任意の値でマーキングできるので、優先制御の確認にも使える。 「QoS／マーキング」では、シナリオごとにIP Precedence／DSCPを設定可能なため、サービスごとの通信品質をチェックできる。 「NE
ITエンジニアの仕事をすると障害はつきものです。 障害は情報セキュリティの３要素である、機密性、完全性、可用性 のいずれかが、確保できない状態だと捉えられます。 なかでもダントツに多いのが、可用性の事故です。 可用性とは許可された者が、必要な時に必要な情報にアクセスできることを確実にすることです。 可用性を損ねる要因として多いのは、ネットワークの不調やサーバー機器のリソース不足など、インフラに起因したものがほとんどです。これらは突発的に起きることもありますが、システムの稼働当初から起きることも多くあります。本当はシステムを構築する段階で、可用性に関わる検証をしておくのが望ましいのですが、実際はそういう工程を経るプロジェクトは少ないと思います。 わたしが構築したシステムではじめて障害を起こしたのは、入社二年目の 1992年 です。それ以降も、直接的、間接的に関わらず、何度も障害を経験してます
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方
棚卸を効率化するためにシステムの可用性を損ねた思い出 - 叡智の三猿