タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜Webエンジニアのキャリアを考える！
「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 ソフトウェアのテストにおいて、最初のフェーズである単体テスト。若手Webエンジニアの中には、いきなり単体テストを任されて戸惑った方もいるでしょう。仕方なく現場で踏襲されているやり方に従っているだけ、ということもあるのではないでしょうか？ 今回は、単体テストの定義から手法、未来の展望までを、日本におけるソフトウェアテストの第一人者・高橋寿一さんが解説します。 単体テストとは（各社ばらばらな単体テストの定義を再定義） コードベースの単体テスト 命令網羅（C0カバレッジ） 分岐網羅（C1カバレッジ） よくある（コードベースの）単体テストの間違い 機能単位の単体テスト 例：複雑なソート機能のテス
複数条件の組み合わせによるテストケース数爆発と戦うPairwise(ペアワイズ)法とそれを支えるツール「PICT」 | DevelopersIO
ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか？という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は本当に有効なのか？組み合わせテスト技法と上手に付き合う方法 ｜ DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか？条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I
良いテストケースの作成手法を学ぶ - 「はじめて学ぶソフトウェアのテスト技法」を読んだ - $shibayu36->blog;
ソフトウェアテストに関する知識をもう少し言語化したいなと思い、「はじめて学ぶソフトウェアのテスト技法」を読んだ。 はじめて学ぶソフトウェアのテスト技法 作者:リー コープランド日経BPAmazon この本では主に良いテストケースの作成手法について学べた。良いテストケースとは「最小の時間と労力でほとんどのエラーを検出する可能性がもっとも高くなるようなテストケース」のこと。これにできる限り近づけられるようにテストケースを工夫する。 良いテストケースを作るためにどういう技法があるかをこの本はいくつも教えてくれる。自分がこれまでテストを書いていると「こういうテストの方がなんとなくベターだよな...?」みたいに感覚的に考えていたところを、言葉として定義してくれることで構造化できるのはありがたかった。たとえば 同値クラステスト 同じグループのテストが、以下を満たせば同値クラスを形成する 同じ機能をテス
という考えにたどり着いたので、考えのスナップショットをとっておく。 Go言語における、テスト関数名とサブテストのname引数の値を「テストケースの名前」・「テスト名」と呼ぶことにしている。 (*testing.T).Run(name string, f func(t *testing.T)) bool テスト名に近いものとして、(*testing.T).Errorや(*testing.T).Logの引数がある。これらはテスト実行時の出力に含まれるが、テストケースを分かつものではない。あくまで、特定のテストケース内の情報を増やすものだ。対するテスト名は、（通常は）テストケースを分割できる最小単位である。 テストケースがテスト名の単位で存在するということは、テスト名はそのテストケースを十分に表現できていたほうがよいということだ。さもなくば、検証・変更しようとする仕様に対応するテストケースや、実
はじめに みなさん、テストケースマネジメントしてますか？ テストケースマネジメントのツールといえば TestRail や PractiTest 、あるいはRedmineやJIRAなどのプラグインを使うことが多いと思います。 ですが、基本的に商用、それもテスターが大勢いるようなQA組織向けのツールが主で、スタートアップなどでQA体制が未成熟なところにフィットする選択肢って少ないですよね。 そんな中、Qaseというツールを見つけたのでご紹介します。 Startup Plan というまさしく上記の悩みにドンピシャなプランが用意されており、複雑な設定が不要であれば無料で利用できるようです。 また、2019/09現在パブリックベータとして公開されており、有償プランの機能も自由に利用できるようです。 https://qase.io/pricing 試さない理由がないですね！ というわけでレビューしてい
こんにちは。 テストエンジニアからサービス開発エンジニアにロールチェンジした、茂呂一子です。 先日リリースしました、iOSクックパッドアプリのリニューアルプロジェクトに参加し、サービス開発エンジニアとしての第一歩を踏み出しました。 今回は、アプリのリニューアルをすすめていく中で、試してみたことについて、お話しします。 アプリリニューアルの内容やそのデザイン意図については、13年続いた「つくれぽ」をリニューアルした話｜Misaki Kubosaka｜noteが詳しいので、こちらをお読みください。 リニューアルプロジェクト第1フェーズの問題点 iOSアプリのリニューアルプロジェクトは、とても大きく、機能を段階的にリリースするため、3つのフェーズに分けて開発していくことが決まっていました。 そのため、開発チームはメンバーの追加をしつつ、複数回の開発サイクル(仕様決定、設計、実装、検証)を繰り返す
Notion AIを用いて機能仕様書からテストケースを自動で作成した話 - Commune Engineer Blog
はじめに コミューンでQAをしています金丸です。 最近QA界隈でAIを用いたソフトウェア開発が注目を集めています。 www.kzsuzuki.com 多くはChatGPTを用いたものですがちょうど先月にNotion AIがリリースされたので今回Notion AIがソフトウェア開発のテスト部分に対して有用に使うことができるかについて記事を書いていきたいと思います。 結論から言うと、実用としての運用は未だ難しいがQAの補佐的な位置付けとしては十分な働きをしてくれることがわかりました。 はじめに NotionAIとは 機能仕様から同値分割・境界値分析・フローチャートを自動で作成 機能仕様の修正もNotionAIにやっていただいた 終わりに NotionAIとは NotionAIは、Notion Labs, Inc.によって開発された人工知能モデルです。個人や仕事に関するタスクの作成、整理、管理を
入社1ヶ月目でやったこと 〜ソフトウェアテストプロセスに基づいたテストケース作成を行ってみた〜 - ブロッコリーのブログ
はじめに この記事は10X 創業6周年アドベントカレンダーの15日目の記事になります。 昨日はアプリケーション開発部のjojoさん*1が、「10Xに入社した、そして4ヶ月後…」という記事を公開しています。 本記事では2023年5月に10Xに入社した私が、入社1ヶ月目に実際に行った、ソフトウェアテストプロセス（以下、テストプロセスと表記）に基づいたテストケース作成についてお話しします。 目次 はじめに 目次 テストプロセスに基づいたテストケース作成を行おうとしたきっかけ 前提：プロセスとは何か？ プロセスの例 テストプロセスを考えよう 今回定義したテストプロセス テスト分析 テスト対象分析 テスト要求分析 テスト設計技法の選択 テスト設計 テスト実装 記事冒頭の例が分かりづらかった理由 実際に適用した例 レビュー内容 今後の展望 おわりに テストプロセスに基づいたテストケース作成を行おうとし
テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities
以下のイベントの投影資料です。 https://d-cube.connpass.com/event/187308/ お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料内にあるURL】 ▽P2：書籍『Agile Testing Condensed』 https://leanpub.com/agiletesting-condensed-japanese-edition ▽P36：書籍『A Practical Guide to Testing in DevOps』 https://leanpub.com/testingindevops ▽P55：プランニングポーカーかんたんガイド https://www.slideshare.net/Ryuzee/ss-11644359/4 ▽P69：Agile Testingのエッセンス #scrumosaka h
この記事はモバイルファクトリー Advent Calendar 2020 7日目の記事です。 こんにちは、ブロックチェーンチームのソフトウェアエンジニア id:odan3240 です。湯船に浸かるのが楽しい季節になってきました。 以前テストに関するこの記事が話題になっていて、読んだときに最後の部分が目に留まりました。 blog.sushi.money テストを先に書いてから実装を書くか、先に書いた実装のテストをあとから書いているか、という場合でも違いが出てきそう。 以前までの自分は先に実装を書いてからテストを書くことがほとんどでした。理由としては、性格的にコードを書くのが好きで、頭の中にあるコードを急いで書き出したくなるため、作業に入ると先に実装を書いていました。 しかし、開発時に実装より先にテストケースから書き始めるとうまく実装が進むことに気付いたので、共有します。 割り算を行う関数 d
Goのテーブル駆動テストではテストケースの定義位置を知りたいのでライブラリを書いた - 詩と創作・思索のひろば
Go言語でテストを書く際のベストプラクティスとして、テーブル駆動テスト（Table dirven tests） というのが推奨されている。ようはデータとふるまいを分離しましょうという話で、正直わざわざ名前をつけるようなものでもなかろうという気持ちもないではないが、まあ話がはやくていいね。 けどみんなほんとにこれで満足してるの？ と疑問に思うところはある。テストが落ちたときに表示される行番号がテストケースによらず一定で、どのテストが落ちたのかを探すのに一手間かかってしまう。 たとえば以下のコードをテストする際、 package eg import "testing" func TestExample(t *testing.T) { testcases := []struct { name string a, b int sum int }{ {"1+1", 1, 1, 99}, {"2+2"
LINEが定期的に開催する、Kotlinをテーマにした技術者向けのミートアップ「LINE Developer Meetup for Kotlin」。今回は「LINEにおけるServer Side Kotlinの導入事例と開発裏話」をテーマに開催します。ここで登壇したのは、「Messaging API」のサーバーサイドを開発している川田裕貴氏。システムの改善における取り組みについて発表しました。全2回。後半は、「Messaging API」のテスト環境について。前回はこちら。 End to EndでテストができるテストケースをKotlinで書いている 川田裕貴氏：前半はMessaging APIの話をしてきましたが、後半はちょっと話を変えます。Messaging APIの中ではテストをいろいろ動かしているのですが、テストケースも全部Kotlinで書いています。普通のユニットテストではなく、E
pytest でテストケース毎に DB を自動的に初期化して、テスト開発体験を向上させる - SalesNow Tech Blog
概要 Web バックエンドのテストコードを書く場合、その多くは DB に依存していることが多いです。 DB 関連のテストは、テストデータの準備やテストケース毎の DB 処理化を適切に行うことが重要ですが、手間がかかる場合あるため、Mock で擬似的にテストしてしまうことも多いかと思います。 ただ、Mock を使ったテストは本質的な問題を検知できない意味のないテストになってしまう可能性があり、可能な限り DB の Mock を行わずに、実際の DB を使用してテストすることが望ましいと考えています。 本記事では、pytest、sqlalchemy、PostgreSQL を使った場合に、テストケース毎に DB を簡単に初期化しつつ、テストケース毎の前提データ登録も簡単うことでテスト開発体験を向上させる方法を紹介します。 前提環境 本記事では、以下の環境を前提として説明いたします。 python
はじめに 本記事は、ソフトウェアテストの小ネタ Advent Calendar 2022の19日目の記事です*1。 本記事では、テストケース*2で具体的な代表値を使うときに気をつけている「2以外の一意の素数を使う」という方針について書きます。なお、この方針は私の個人的経験及び主観に基づいたものです。「必ずしもこのやり方が正しい」と主張したい訳ではないことをご了承ください。 記事では、この方針をさらに「2を使わない」「一意の数を使う」「素数を使う」の3つに分割して説明します。 目次 はじめに 目次 テストケースの具体的な代表値に2を使うのを避ける テストケースの具体的な代表値は一意の数を用いる テストケースの具体的な代表値に素数を用いる 注意：今回の考えはあくまでも代表値の場合の話です おわりに 補足：厳密な素数を選ぶわけではない 1. 「691」という数字が素数であるか判断が難しいため 2
はじめに 炭山水です。こんばんわ。 テストって必ずする or 必ずテストコードは書くと思いますが、身近な例で「JUnitの使い方とかPHPUnitの使い方とかはわかってもいざテストケースってどんなのやったらいいかよくわからない」という声をききまして筆を執りました。 ガチなテスト論は専門書に譲るとして、本記事ではその触りというかイントロダクション的なことをお話ししようと思います。 ちなみにQiita初投稿です。本日参加したTech::Survivorのもくもく会で「Qiitaを何かしら1記事投稿すること」が課題だったのでそれ用に書いたものですｗ TECH::Survivor エンジニアに成長機会を提供することを目的に作られたオンラインコミュニティの勉強会アカウントです。 https://techsurvivor.connpass.com/participation/ 対象読者とお話しする範囲
ホワイトボックステストにおけるカバレッジとテストケース(C0, C1, C2, CDC, MC/DC, MCC) - ろぐれこーど
ホワイトボックステストでよく用いられる網羅率(coverage)について、違いがよくわかっていなかったためまとめてみました。間違いあれば更新します。 網羅率(coverage, カバレッジ)とは カバレッジ基準 命令網羅 : statement coverage (C0) 判定条件網羅 : decision coverage(C1) 条件網羅 : condition coverage(C2) 判定条件/条件網羅 : condition / decision coverage(DC/CC, CDC) 改良条件判定網羅 : modified condition/decision coverage(MC/DC) 複合条件網羅 : multiple condition coverage(MCC) 経路組み合わせ網羅 : path coverage まとめ 参考 網羅率(coverage, カバレッ
以上をまとめると、ユニットテストなどのいろんな種類のテストについて、正常系と異常系をもとにテストの手順を書いていくのがテストケース、ということになります。 なぜテストケースを作るのかそもそも、なぜテストケースを作る必要があるのでしょうか？テストケースの設計に初めて携わる方は、その必要性が分かりづらいかもしれません。 テストケースは、「それをもとにテストを行う」という手順書になるのはもちろんそうなのですが、品質という意味でも次の3つの目的があります。 必要なテストを漏れなく実施するため不要なテストを削除するため誰が行っても同じテストにするためこの3つについて説明します。 1. 必要なテストを漏れなく実施するためソフトウェアが正しく動作するかどうかは、テストを通して確認します。言い換えると、テストケースが足りない場合、ソフトウェアが正しく動作しないかもしれません。例えばバグがあると、ソフトウェ
ソフトウエアテストにおけるテスト設計で作成するテストケースは、ソフトウエア品質を高める重要な要素の1つ。テストケースの出来が悪ければ、確認すべき項目の抜け漏れが発生し、ソフトウエアの欠陥（バグ）が見逃されてしまう。テストケースの記述の仕方を少し工夫するだけで、トラブルリスクを低減できる。 「なぜこの値を入力するのか」を明確にする テストケースには、テスト対象の項目、テスト条件、テスト手順などを記載する。このうち、テスト条件の書き方に、その後の工程をスムーズに進めるための心得がある。テスト条件の欄に「なぜこの値を入力するのか」を明記しておくのだ。 例えば、ECサイトのテストで商品購入の機能をチェックするとしよう。商品を選択したうえで購入ボタンを押したとき、きちんと在庫チェック機能が動くかを試す、といった趣旨のテストである。 このときのテスト条件に「購入する商品：商品A」としか書かれていないこ
Google Chrome+QualityForwardでテストケースを多言語化 - ANDPAD Tech Blog
ごあいさつ アンドパッドのQualityControlの冨士川です。 入社して2年半経過し、現在はQCチームのリーダーやっています。 道の駅をめぐることにハマっていて写真は千葉県館山市の道の駅「“渚の駅” たてやま」の「さかなクンギャラリー」で撮った写真です。魚魚魚～！ ※QualityControlについては弊社のTech Blogをお読みください この記事の目的 皆さん、海外メンバーと開発する時にテストケースの翻訳はどうしていますか？ 「Google Chrome」とテスト管理ツール「QualityForward」を組み合わせて使ったところ、 簡単にテストケースを多言語化できたのでご紹介します。 テストケースを多言語化した背景 弊社はベトナムにグループ会社「アンドパッドベトナム」があり、ベトナムメンバーと連携してQC活動を行っています。 日本メンバーがテストケースを作成し、ベトナムメン
ソフトウェアテスト・ 品質保証 セキュリティ UI/UX DX カスタマーサクセス コンサルティング Our Services サービス ソフトウェアテスト・品質保証
きっかけ あるとき、○○ちゃんに、「SQLの単体テストケースってどうやって考えればよいの？」と問われ、「うっ」となりました。 SQLの単体テストケースの考え方 そんなことも答えられないのに、「網羅的なテストぉー！」だとか、「カバレッジはどのくらいを狙っているの？」などと偉そうに言ってきましたが、なんとなくを整理して、改めて理解してみます。 どこから手を付けるか？ テスト対象はDDLなのか、DMLなのか。日常よく使うSELECT文を単体テストケースの考え方の対象とします。SELECT文を概念的に(内部実装は置いといて)、「1.構成する要素(○○句)と実行順序」、「2.その要素の挙動」に整理、理解して、「3.単体テストケース」を考えます。 調査 書籍「プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに」をメインにSELECT文の実行順序と挙動を調査。 SELECT文の挙動調査元ネ
QualityForwardというクラウドベースのテストケース管理システムをサポートしています。その関係もあって、オープンソースのテストケース管理システムを調べてみました。無償で、自分で立てるという選択を選ぶ場合の参考にしてください。 利用できる、利用できそうなソフトウェア 少なくとも3年より前に更新されているソフトウェアです。また、公式サイトがちゃんと立ち上がっていて更新されているものに限定しています。 TestLink オープンソースのテスト管理と言えばTestLinkを思い浮かべる方が多いのではないでしょうか。開発言語はPHPとなっています。現在はGitHubにコードを移しているようです。今年リリースされた1.9系が最新版です。 TestLink download | SourceForge.net TestManagerForTracPlugin – Trac Hacks Trac
Gradle経由でのテスト実行時、コンソールに失敗したテストケースの情報を出力する - たごもりすメモ
`./gradlew test`とか`./gradlew build`とかしたときに失敗したテストの情報はこの`index.html`を見てね! っていうのがめんどくさくて、なんでデフォルトで失敗したテストの情報を出してくれないんだっけ、と思っている人、主に俺の問題を解決する。 ていうかデフォルトでそうしてくれればCIサービスの設定時にテスト結果の保存とかを個別にやらないと何が失敗したかもわかんなくなってて困る、みたいな状態にならなくてすむのにね。 調べてたら「とにかくコンソールに全部出したい!」みたいなのがいっぱいひっかかるけどそうじゃないんだよなー、そういうのはtoo muchなんだよ。 で、これ。 stackoverflow.com のうち一番下の回答(TestLoggingを使う)が簡単に調整できそうだったので、手元プロジェクトで以下のようにした。Kotlin DSL使ってるんで`
APIテスティングツールに必要なのはテストケースごとのIDなのではないか #cicd_test_night - Copy/Cut/Paste/Hatena
先日、機会をいただきましてCI/CD Test Night #7でAPIテスティングツール*1を開発している中で考えていることをお話しさせていただきました。 testnight.connpass.com 詳細はスライドをご覧ください。 speakerdeck.com APIテストはスモールテストと比べて効果は大きいがコストも大きい 私はAPIテストの一番の課題はこれだと思っています。 APIテストは、「APIに対してリクエストを投げてそのままテストする」というわかりやすさがあります。 また、テストあたりにおけるカバレッジの広さというメリットもあります。 なので、できればデメリットであるコストの大きさをなんとかしたいわけです。 この課題の解決には2つの方法があります。 コストを小さくする 範囲を広げて効果を大きくする 先に、範囲を広げる方法について考えると 作ったテストをそのまま負荷テストに
テストケースの作成 - Qiita
よくある失敗 1. 不必要なテストパターンが多すぎる 「全ての組み合わせを網羅しなくては」と考えてしまうあまり、意味のないテストケースをたくさん作り込んでしまうタイプです。先ほどの例で示したように、組み合わせが多くなるとあっという間に天文学的なパターン数になってしまいます。 2. 異常系テストが足りていない 「数値の項目にカタカナを入力したら」、「データベースに接続出来なくなったら」のような、異常なパターンのテストがそもそも足りていないタイプです。実際のシステム運用では、想定していない事態は頻繁に起こります。異常系テストが足りていないと、そのような時にすぐ壊れる脆弱なアプリケーションになってしまいます。 テストケース4つの考え方 1. 正常系と異常系 正常系とは、「その対象が想定している入力に対して期待どおりの出力を行なうかどうか」という考え方です。 対して異常系は、「その対象が想定してい
こんにちは。株式会社プラハCEOの松原です TL;DR デキる人は完成形を見せてから詳細を進めていく 30%ぐらい完成したタイミングで完成イメージを一度見せて、齟齬がないことを確認すると良い コードも完成イメージを一度レビューしてもらってから細部を実装した方が良いのではないか テストケースだけ先に見てもらうと良いんじゃない？ 仕事がデキる人はなぜ〇〇なのか 「仕事がデキる人はなぜ〇〇なのか」みたいなビジネス書によく書いてあるテクニックがあります。それは 頼まれた仕事は30%ぐらい完成したタイミングで一度依頼主に見せて、認識齟齬がないことを確認すること よく出てくるのがプレゼンの例です： 仕事がデキないパターン 上司「今度の企画案を部長に説明するためのプレゼンを作っておいてくれ。プレゼンは1週間後ね」 部下「わかりました！」 〜1週間後〜 部下「できました！」 上司「なにこれ！全然思ってたの
RSpecでは、before do ... endを使うことで、各テストケースの前に共通して行う処理を記述できる。これを使ってテストデータを投入する処理などを書いておくと、テストケースが書きやすくなる。 しかし、例えばデータが1件もない状態での挙動をテストしたいときなど、一部のケースではbeforeをスキップしたいという場合もある。そのための直接の機能はRSpecにはないが、以下のようにすると実現させることができる。 describe 'test_case' do before do |example| unless example.metadata[:skip_before] ... end end context 'condition A' do it 'needs before procedure' do # beforeが実行される ... end it 'not need bef
概要 cypressを初めて使う筆者が cognitoを認証基盤に利用するwebアプリに ログインするテストケースを作った際にハマったポイントまとめ 先に結論 ここのコードに解決策が全部入ってるからこれ見ればok https://gist.github.com/vittorio-nardone/a9b388ff7388a4ae7343cd6a2758bc4b 背景 最初、cypressをcognitoに使った事例探したらクラメソさんの記事があって、 https://dev.classmethod.jp/articles/amplify-console-cypress/ 助かったー、と思いつつ参考にして実践してみたがだめだったので、色々と試行錯誤した軌跡 ハマったポイント セレクタで入力フォームを取得できない ログイン画面を表示させて、inputタグに入力すべくセレクタで指定したが、見つから
【QAチームブログリレー4日目】 こんにちは！ エムスリーエンジニアリンググループ QAチームの城本（@yuki_shiro_823）です。普段は担当しているBIR（Business Intelligence and Research）チームで品質向上のためにあれこれしています。 今回はE2Eテスト自動化サービスmablを利用してテストケースを作成・運用していく際に、レビュールールを作った話を紹介します。 前提 ルールの必要性 ルールの作成プロセス ルールの詳細解説 命名規則 作成上のルール レビューフローのルール ルールの運用と効果 まとめ We're hiring！ 最近撮った雨の日のアジサイ。スマホカメラにしてはうまく撮れて気に入ってます 前提 エムスリーではテスト自動化にローコード自動化サービスmablを利用しています。 mablとはブラウザの操作を記録することにより、ローコードで
ことの発端 新卒2か月目にして、早速開発者テストで考慮漏れを発生させた私。 「顧客が組んだ計算式の動作を担保するUT（ユニットテスト）を書く」という防止策の対応が急務でした。 無限に増えていくテストケースとの格闘、PICTやテスト手法の学習等、色々あった結果、全ての網羅は出来ないという結論にたどり着きました。 最低限担保する部分を決めてテストケースを出してみると46,000件になりました。 46,000件のテストケースを実行しなければならない 今回のテストケースとしては、実行する式、取りうる引数の値、期待する計算結果の3つを保持しておく必要がありました。 保持する方法としては、以下の2つを考えた結果 protobufを使用する方法 golangコードを生成する方法 binaryファイルにすると型情報が欠落してしまい上手くテストケースを表せなかったことから、golangコードを自動生成する方
本記事は 【Advent Calendar 2023】 19日目の記事です。 🎄 18日目 ▶▶ 本記事 ▶▶ 20日目 🎅 こんにちは。社会人2年目、新米エンジニアの國弘です。 配属後から今日まで、開発業務として一番時間を費やした工程はずばり テスト だ、と言っても過言ではないと思っています。 開発の検証作業としてかかせないテストですが、テストケース作成のポイントとして、 「だれにでも『わかりやすい』記載であること」 が挙げられます。 今回は、自身の経験を踏まえて、テストケース作成について『わかりやすい』記載という観点で気を付けたいポイントをまとめてみました。 『わかりやすい』記載に求められる2つのポイント 1.打鍵者が迷いなく実施できること 2.確認ポイント・方法が明確であること テストの目的が『わかりやすい』か？ 3.テストの目的を読み取れること まとめ 『わかりやすい』記載に求
脱エクセル管理！？テストケース設計とテストケース自動生成ツールKTestCaseDSLを作りました。 (コアコンセプト編) | DevelopersIO
脱エクセル管理！？テストケース設計とテストケース自動生成ツールKTestCaseDSLを作りました。 (コアコンセプト編) まずモノをみてもらう テストケース設計を記述するDSLをKotlinで作りました。 KTestCaseDSL 以下のようなコードでテストケース設計ができます。 サンプルはこちら testSuite("ログイン画面") { case("ログインできること") { preCondition { condition("未ログイン状態であること") } step("https://xxxxx.com にアクセスする") step("ユーザ名を「Kamedon」と入力する") step("パスワードを「Password」と入力する") step("ログインをクリックする") verify("「ログインしました」とトースト通知されること") postCondition { con
テストケースを変えない工夫 | 品質向上ブログ
※本稿はソフトウェアテスト Advent Calendar 2020 24日目の記事です。 こんにちは、Magic Podの開発をしている脇坂です。好きなものは単体テストとリファクタリングとテニスです。 さて、今日はリグレッションテスト、機能テストの文脈で話をします。テストケースを変えない工夫というのは、継続的にテストケースを実行する上で必要不可欠なテクニックです。このテクニックは自動テストの文脈で語られることが多いですが、手動テストにおいても応用可能だったりします。 話すこと テストケースを変えるべきではない理由テストケースを変えずに済ませる工夫 話さないこと フレーキーテスト問題に対するシルバーブレッド非機能要件のテスト 目次 背景テストケースの変更単体テストの場合Web/Mobile E2Eテストの場合Webは詳細手動テストの場合Web/Mobile E2Eテスト自動化サービスの場合
AtCoder のテストケース - AtCoder
AtCoder 公式コンテストのテストケースは、今後すべて https://www.dropbox.com/sh/nx3tnilzqz7df8a/AAAYlTq2tiEHl5hsESw6-yfLa?dl=0 にアップロードされる予定です。
方針を決めないから失敗する 考えなしのテストケース作成
テスト設計のメイン工程ともいえるテストケースの作成では、典型的な“駄目なテスト”のパターンがある。どのようにテストケースを作成すべきかを検討せずに作り始めてしまう、といったものだ。テストケースの作り方を担当者の判断任せにすると、テスト条件やテスト観点が曖昧で不具合摘出が不十分なままテストが終わってしまう恐れがある。 テストケース作成前に「テストケースをどのように作成すべきか」を検討する必要がある。また、検討した内容は資料にして残しておくべきである。これらを実施しないと“駄目なテスト”を引き起こす。 1つめはバラツキのあるテストケースを作成してしまう問題。いきなりテストケースの作成を開始すると、テスト設計の担当者ごとに記載粒度がばらつく。テスト実行の担当者が混乱するし、不具合摘出が不十分なままテストが終わってしまう原因にもなりかねない。 2つめはテストケースを再利用しにくい問題。資料が不十分
テストケース自動生成器をつくる
はじめに プログラムから自動的にテストケースを生成するテストケース生成器を作ってみます． プログラミング言語は Scheme, 処理系は Gauche を使います。 プログラムの構文 プログラムの構文は次のようにします。S式です。 変数は整数型だけとします。 文は5種類用意します： skip (set! 変数 式) (if 条件 文 文) (while 条件 文) (block 文 ...) 式は前置記法で、次の演算子を用意します： and or not = > < >= <= + - div しくみ 基本的な考え方： if 文の条件に着目する プログラムからテストケースを作るときは，if 文に着目して，その条件が成り立つ場合と成り立たない場合をそれぞれテストケースとします． この条件を，プログラムの入口の方に向かって変換していって，プログラムの先頭で成り立つべき条件が得られれば，それがテ
こんにちは。QAチームのmiyagiです。 QAで最近導入したTestRailというツールについて、導入の背景や、スプレッドシートからこのツールに乗り換えて変わったことについて書いていきたいと思います。 TestRailとは TestRailは、主にテストケースの作成・更新やテストの進捗管理ができるテスト管理ツールです。 ツールの開発元はドイツのGurock社で、日本ではテクマトリックス株式会社が販売代理店となっており、同社から日本語でサポートも受けられます。 テスト管理ツールを導入した背景 テスト管理ツールを導入した理由は大きく分けて2点あります。 1点目はテストケースのデータベース化を実現するためです。具体的には以下の内容を行うためのツールが必要でした。 テストケースのマスタを作る テストケースのマスタから実行するテストケースのセットを条件に合わせて抽出する TestRailへの移行と
DMM meetup #14 ( https://dmm.connpass.com/event/152326/ ) での資料です。 レガシーコードを実環境の動作をログ化することでテストケースに変換。 それらのテストケースを活用してリファクタリングを行う技術の紹介をしました。 そしてDMMのプラットフォームチームとは何かについて。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストケースの名前には条件と結果を含めた方が良い - 感情を込める
![さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b5961cfe7e9736ef0e88bc0290b1599481d2626/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20240319%2F20240319125826.jpg)
スタートアップや小規模チームのテストケース管理には「Qase」がいいかもしれない - Qiita
テストケース作成を仕様詳細化の手段とする実験 - クックパッド開発者ブログ
テストケース、仕様を書くか実装に合わせて書くか - Mobile Factory Tech Blog
なぜLINEは600以上のテストケースをKotlinで書くのか？ “とにかく便利なテスト”を実現する、kotestのお役立ち機能
テストケースの具体的な代表値には2以外の一意の素数を使おう - ブロッコリーのブログ
テストコードの書き方はわかったけどテストケースってどうやって挙げたらいいの？ - Qiita
テストケースの作り方・書き方の例【項目の洗い出し】
これは危険！バグをスルーしてしまうテストケースの見抜き方
テストケースとは？書き方や満たすべき要件について解説｜ソフトウェアテストのSHIFT
SQLの単体テストケースって、どうやって考えるの？ - Qiita
自分で立てる、オープンソースのテストケース管理システムをまとめてみた - Qiita
盛大な手戻りを防ぐため、先にテストケースだけレビューしてもらう開発手法
【Rails】RSpecで特定のテストケースだけbeforeをスキップする - りんごとバナナ
CypressでCognitoにログインするテストケースを通すのに苦労したポイント - Qiita
E2Eテスト自動化サービスmablでテストケースを作成する際のルールを作った話 - エムスリーテックブログ
46,000件のテストケースでgo testのビルドを高速化する - Qiita
わかりやすいテストケース作成のために気を付けたいポイント - NRIネットコムBlog
テストケースの管理をスプレッドシートから「TestRail」に移行した - Gunosy Tech Blog
巨大なレガシーコードをビッグデータでテストケースに変換する
automaton-media.com
approach.yahoo.co.jp
jxiv.jst.go.jp
www.mlit.go.jp
www.bs11.jp
www.wwdjapan.com