タグ

テストに関するteruoksのブックマーク (13)

  • Winium - Windows向けソフトウェアでもSeleniumでテストしよう

    MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました ソフトウェアのテストは幾つかの種類がありますが、実際にデモでソフトウェアを操作して行うテストとして有名なのがSeleniumです。当初はWebアプリケーション向けの仕組みでしたが、Appiumによってスマートフォンアプリのテストも行えるようになっています。 さらに今回紹介するのはWiniumです。名前からも分かる通り、Windowsアプリの自動操作テストに使えるSelenium系ソフトウェアです。 Winiumの使い方 Winiumの使い方は次のようになります。こちらはRubyで書いた場合のコードです。 require 'selenium-webdriver' capabilities = {app: 'c:\windows\system32\notepad.exe'} drive

    Winium - Windows向けソフトウェアでもSeleniumでテストしよう
  • 【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ~「テスト」という工程が必要な理由 | きのこる庭

    前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ

    【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ~「テスト」という工程が必要な理由 | きのこる庭
  • テスト駆動開発/振る舞い駆動開発を始めるための基礎知識

    連載目次 2000年代初期に開発手法として確立された「テスト駆動開発」(Test Driven Development、以下「TDD」)は、その後10年もの間で普及が進み、今や珍しくない開発スタイルの1つとなっています。国内でも「アジャイルアカデミー」「TDD Boot Camp」などによる推進・普及活動が各地で活発化し、認知が広がってきました。 なおTDDは誕生からこれまでの間に、さまざまな工夫や実践上のノウハウが提唱されてきました。またTDDの普及に影響を受け、他のさまざまな「テストファースト」手法も台頭してきています。 稿では、そうしたTDDの発展や、振る舞い駆動開発(Behavior Driven Development、以下「BDD」)など他のテストファースト手法への展開についても解説します。 ※編集部注:ソフトウェアの「テスト」そのものの概要や種類について知りたい方は記事「J

    テスト駆動開発/振る舞い駆動開発を始めるための基礎知識
  • Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記

    テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ

    Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
  • バグのないプログラムを作るための技術 - eomole blog 4 くらい

    2015/12/10 追記: バグを気で無くしたい方はこんな良く辺鄙なブログなんて見ずにソフトウェアエンジニアリング系の国際学会に行くなり、そこの論文を読むなりするといいと思います。ICSEなんかは日語の勉強会資料もあってとっつきやすいでしょう。 バグのないプログラムを作る方法について色々聞きかじったことを, 脈絡なく訳の分からない説明でつらつらと書きならべます. テスト 割と古典的な方法ですね. プログラミングコンテストでもお馴染みの方式です. Java だと JUnit (4) みたいなのを使います. 手作りケース とりあえず試してみるケース コーナーケース ミスの発生しやすそうなところを突くためのケース ランダムケース ランダムに爆撃するためのケース みたいなものを作って, 仕様とマッチするか確認します. 当たり前ですが, 基的には下手な鉄砲も数撃ちゃ当たる方式なので, 運が悪

    バグのないプログラムを作るための技術 - eomole blog 4 くらい
  • テスト駆動開発チートシート - やさしいデスマーチ

    TDD(テスト駆動開発)のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ(OmniGraffle)が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記2 このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。

    テスト駆動開発チートシート - やさしいデスマーチ
  • 単体テストを“神速”化するQuick JUnitとMockito

    単体テストを“神速”化するQuick JUnitMockito:ユカイ、ツーカイ、カイハツ環境!(16) Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション(CI)によるテストの自動化や、テスト駆動開発(TDD)の普及などにより、ユニットテスト(単体テスト)のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修

    単体テストを“神速”化するQuick JUnitとMockito
  • JPF

  • 書籍「基本から学ぶソフトウェアテスト」を元にした講義資料 — ありえるえりあ

    対象読者 ソフトウェアテストを勉強したい人 を読むのが面倒で、手っ取り早くポイントだけ知りたい人 アリエル固有のことは書いていないので、テスト技術者の教育担当者は、講義資料として使ってください 1. テストの進め方 テストの前に対象ソフトウェアを理解すること バグ1件ごとにバグ報告を書くこと(複数のバグを同じレポート内に書かないこと) 正しく動かないはず、と思ってテストすること 境界条件を意識すること 最小限の再現条件を探す努力をすること 普通の使い方(正常系)でまともに動作しない場合、テストの中断も考慮すること(時間の無駄かもしれないので) wontfix(修正しない)の返答に対して、その判断を無批判に受け入れないこと(プログラマはwontfixの判断をよく間違えるので) リリース間際の場合、修正しない判断には高度に政治的な背景があるかもしれないので、こだわりすぎないこと 格言:優秀な

  • あなたのテスト、単なる動作確認になっていませんか?

    EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

    あなたのテスト、単なる動作確認になっていませんか?
  • 第6回 テストケースの作成 | gihyo.jp

    前回は、TestLinkの基操作のうち、テストプロジェクト開始時に必要な操作について説明しました。続いて今回は、テストケースを作成していきます。 はじめに 図1にあるように実際にテストケースを作成していく、テスト設計・テスト実装という工程を対象とします。また、実際のテストプロセスではその前にテスト分析(仕様分析)という作業が必要となることも多いでしょう。 TestLinkは、あくまで管理のためのツールですので、分析・設計の作業はほかのツールを活用しておこなうことになります。これらの作業を省いて、テストケースの元となる仕様書などの資料(テストベース)から直接TestLinkにテストケースを入力していくことはあまりお勧めできません。あくまでテスト分析・テスト設計の結果をテストケースに落としていく時(テスト実装)の記述先がTestLinkになるということです。 テスト分析・設計の方法は、gih

    第6回 テストケースの作成 | gihyo.jp
  • ソフトウェアテスト基本テクニック 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    ソフトウェアテスト基本テクニック 記事一覧 | gihyo.jp
  • 新人注目! テストを極める最初の一歩 記事一覧 | gihyo.jp

    第3回コピー&ペーストでテスト仕様書を作っていませんか? 鈴木三紀夫,池田暁 2008-07-14

    新人注目! テストを極める最初の一歩 記事一覧 | gihyo.jp
  • 1